 Cool. All right. Hey everyone. Thanks for coming into our talk titled Scaling and Open Source Sponsorship Program. Today we're going to be talking about just that, particularly in a corporate setting. Sharing some lessons learned, some tactics from running our own open source program at Stripe. Starting our own sponsorship program and pulling in some insights and lessons learned stories from other companies that we've heard along the way. I'm Mike Fix. I'm a software engineer at Stripe. I've been working there for about four years now in various roles. And I also am the head of our virtual Ospo, our open source program office. Been running that for about three years as well now. Hey everyone. My name is Carol. I'm the technical program manager for a DevRel team at Stripe. I've worked there for almost three years now and kind of worked on a variety of things, from like developer marketing, developer advocacy, now DevRel. But I've always been a part of our volunteer open source team. Just to give you like a little brief overview of what we're going to be talking about, we'll sort of start off just laying the stage for what the stages of a corporate open source project sponsorship program can look like. Sort of based on our experience, a lot of our experience and interviews with colleagues that will mention then sort of how you might kick off and launch something, how you might grow. But then what we'll really get into is the tactics for operating at scale, both from our lessons learned and just sort of things that we wished we had done along the way or that we knew afterwards. And then we'll actually finish up with a little bit of sort of blue sky opportunities for where we hope slash dream open source sponsorship could go. If we have any questions, feel free to raise your hand at any point along the way for clarification for just wondering where we're going with something. I think this is a decent enough group. We could probably get through all that, but you can also come up afterwards. Thank you so much for having me here. Happy to chat. Yeah, so just delay the ground work. What's the problem here? We all know this very well. The open source ecosystem needs further monetary investment if we're going to sustain it in the long term. This is the status quo. We all know this and we talk a lot this week about sustainability in that. The companies also now know that they want to invest in open source, but it's just been difficult historically to pitch that throughout the company, managing upwards, managing outwards. And so today we're going to talk about how to make a truly sustainable open source sponsorship program. And by sustainable, what I mean is that in the ideal case, it doesn't go away no matter what happens. So yeah, given the status quo is that many, many projects are in need of funding. The first step is to come up with a set of principles by which you are going to navigate that wide slew of projects, narrowing it down to the ones that you can invest in and align that with a funding strategy. So yeah, first step for establishing a sponsorship program is coming up with a set of investment principles. You can think about this as an investment thesis or something if you're familiar with venture capital. For us, that was a few things. For one, we wanted to be impact-driven, so provide enough money to make a tangible impact on the maintainer's lives. Since the ultimate goal is to keep the project running and growing, we knew that investing too little in any one project would mean that was basically throwing away money, or it wouldn't make a meaningful enough impact for them to make a change in their life to dedicate more time or the right amount of time to their project. Along that, we wanted to be maintainers first. So in picking that amount, we went and asked our initial maintainers how much would make a meaningful impact in your life? What's a good amount for investment month to month? And we landed on, for our initial pilot, $3,000 a month. That would make a meaningful enough contribution so that they would be able to invest more time in the projects that they wanted to build themselves. And then, yeah, with that self-sustaining. So in the ideal case, none of our investments should end. They should be reoccurring and return enough investment back to our company in a measurable way so that we can keep sponsoring every project on a month-to-month basis indefinitely. In the ideal case. Yeah, these are the main principles by which we went about making our selections for an initial pilot. So yeah, that's how we went about starting off the program. And so that was setting the groundwork for eventually establishing our sponsorship program. The first stage of this is a pilot. This is all about testing a hypothesis. And then from there, launching multiple cohorts, cohorts one, two, three, and basically just repeating the process as you go. And then setting the stage for ultimately creating a platform, a platform by which other teams within your company or organization can leverage open source to accomplish their own goals. That's the direction we wanted to head in. So yeah, kicking off. On day one, this is roughly three years ago at Stripe, we were just thinking very altruistically, like looking outward and saying, like, hey, our goal is to give money to the open source ecosystem. And when we went to our CTO, we said, hey, we want to give money to our open source ecosystem. And he agreed. He was like, yeah, I want to give money to the open source ecosystem too. Even with that alignment, it was not eight months from there is when we launched the initial pilot. So even when leadership and folks on the ground are aligned, thinking just purely altruistically is difficult in establishing a sponsorship program because at the end of the day, your boss has to pitch to their boss. And they have to prove that they're doing right by the business. And so without measurable ROI, it's very difficult to say, like, hey, we just want to do this out of the goodness of our hearts. So after we hit a wall there, we went in the direction of being completely self-serving. So we looked internally and we're like, hey, what are the most dependencies that we're using the most, like doing all the regular scans that a lot of companies fall into, figuring out which projects we use the most, asking people like, hey, what would you sponsor if you could sponsor a project? And the pitfall we fall into there is that we end up in the trap of only sponsoring the most visible projects. And those projects already tend to get a lot of attention and sponsorship. So you end up not being able to invest in the projects that need it the most. And that makes it more difficult to measure your impact. Given that they're already saturated, the dollars that you invest in those projects won't go as far. And so ultimately in our third approach, what we're calling the symbiotic approach, we like to think about this as like a recursive approach, looking outward but also looking inward, seeing how we can align our business needs with the needs of the maintainers in our community. Thinking about it this way, it's like self-reinforcing. So if we can measure ROI dollars coming back into our business, then we know that like, hey, if we're making more money from this investment than the money we're putting out, then we can continue to sustain projects on a reoccurring basis indefinitely. But it also is evidence to expand the program. If the first one went well and it made more money than we invested, then like it's just logical sense to do that in more cases throughout the business. And I tend to think about this as dual power. Like we're existing in a world where we need to pitch upwards and prove our worth to the company, but while moving in the direction of that altruistic approach of simply giving money to open source because that is the right thing to do. And then what this ends up leading to is funding the long tail of open source investment. So funding all those small projects that we know add up to the massive open source ecosystem that we're trying to support. And yeah, taking this symbiotic approach ends up making it so that your dollars go further. And because it tends to be, by definition, those projects are under invested in, typically you can be the first sponsor in their project. By being the first sponsor they tend to pay attention to you not only from like the monetary standpoint, but building relationships. You can impact roadmaps and not just from a selfish perspective either. A lot of times they want to know feedback from their largest users in order to build the features that real users are relying upon. So yeah, with the pilot, it's all about testing a hypothesis. The first round is always based on a belief. And so once you've established those set of principles, you can now go about picking some projects that align with those principles. And besides principles, you want to set what does success look like before launching the program. So establishing that with leadership and your executive sponsorship upfront. What does success look like? Because you know before you run this program you don't know how things are going to go. So you want to basically run this like the scientific method. Like have a hypothesis, figure out what success looks like, and launch your first initial investments aligning with that. I want to say too that like before launching, try and have some sort of, even if it's a best guess, even if it's an estimation, a measurable set of criteria is against that success. So for us, we had actual charts that measured US dollars coming into our business and examined that against the sponsorship round that we gave for these projects. Now it's easy because we're a payments company, so it's a lot easier for us to do those sorts of measurements. It's not always the same, but we can talk, we'll talk more later about how you might measure cost savings or risk savings, that sort of thing. And finally, like having this measurable ROI doesn't make it just easy when things are going well. It's critical when things are going poorly. So in an economic downturn, having that ROI to point to makes it simple to argue for keeping your program around. So we know that like lots of companies gone through layoffs in the last six months, including our company as well. But despite that, our sponsorship program has remained strong, stable even, because we've proven that the ROI is positive throughout that time period. So once you have a model in place that's proven results with leadership buy-in, a mechanism for mapping out your decisions with that outcome, kind of the only thing left to do often is just to repeat that process with more projects, continuing again to measure each project against your success criteria. Yeah, so for Stripe, that meant adding new cohorts to projects. Whenever they met our investment criteria, our principles and our sourcing criteria. For other companies we've heard, this meant like repeating that process on a monthly or quarterly basis. For us, we just did it whenever we found a cohort of projects that met that strict criteria and we wanted to add them to the program because we knew that that would lead to positive ROI. And for many programs, like many organizations, this is the extended program, which is totally okay. Just repeat a known process. You iterate by tweaking for performance for every quarter. Indefinitely, you kind of wash, rinse, and repeat. And I'm curious kind of you in the room, I'm assuming a lot of you are at Ospo's. Yes, nods. Great. Are you at the stage of having a sponsorship model? No. So we're kind of trying to start it up. Is anyone already at the point of having one? All right, we got some people. Okay, so kind of what we're going to go over next is to really talk about ways to scale a program to make it truly sustainable. But if you're kind of even just at the point of not even having gotten started yet, I would say think a lot about your investment principles. Think a lot about where you want to go with all of this because especially at a smaller company, you already kind of know that implicitly, but somewhere down the line, a CFO is going to ask you to make it explicit. And if you have that already, then you can say, this is how everything has gone in that direction. So kind of next we're going to talk about how to scale in an expansive way. So it's well positioned to kind of keep running as long as possible, sort of with or without you, which is kind of what we're hoping to talk about in terms of sustainability. So we talked about testing your hypothesis and one other possible way to do this is to expand within your company of other hypotheses that you could try out. So it's essentially thinking about what other pain points are there that OS sponsorship can ease. So if you're a developer product, if you're a Google's developer first company, like DX might be a big thing for you and maybe that's owned by DevRel, maybe that's owned by a different team at Stripe like developer experience is obviously something that we're always thinking about and it's something that a lot of teams think about. So that's an easy one. But if your company is maybe at a stage of needing to push product development to the next level or kind of do these like make it or break it deals for you to sort of like get to a point of having good numbers, like see if supporting an open source project needs and especially like if you hear your colleagues are being pushed for edge output but they don't have the headcount, can you essentially make an open source project in arm of your team? You'll notice when you look at all of these that potentially like support of the same project could serve many, all or some of these business goals because the downstream impact of supporting one project can be huge. So which does your company think are worth it and thus which can you present in the best way to guarantee support for your program down the line? Yeah, so now we've been discussing a lot of things broadly at this point. We're going to start diving more into specific tactics for operating at this scaling point of a sponsorship program. A first example that for us led to this ability to scale was coming up with a sponsorship menu. So for ours this meant establishing new models for investment that let other teams participate in our sponsorship program and sort of decentralized the process. So we started off with pillar one, grow revenue. This is our measuring ROI based on project growth from the companies, from the projects that we're sponsoring in. And so we measured the ROI based on more dollars coming into our business. But we also added a second pillar which is saving costs. For us this is a pilot. We're exploring what ROI means in this realm. But for example you can measure how much AWS cost savings certain changes lead to. And then you can map that to like hey, how many engineering hours do you think improving this project will lead to? And you can sort of map estimated cost savings in that way and in aggregate if you say like hey, we're estimating saving 50 hours per month. Then like sponsoring a project could be like one tenth of the estimated ROI there. And so that even if it's a squishy number it could be worth it for your company to go down that route. And then finally and what we've seen is like the most successful pillar was actually just bring your own budget. Now this was always a possibility but just putting it on the menu quote unquote led to a bunch of teams reaching out to us saying hey like we have these business goals and we want to sponsor these open source projects to build a relationship to unblock certain contracts even to move the needle in their org. And these are obviously hypotheses that we couldn't have come up with on our own in the open source team. But they came to us with that business need and we said like hey if you come to us with a need and a budget we can execute on all the administrative burden of handling the open source sponsorship program open source sponsorship of those projects and they can focus on building the relationship with those maintainers. So this is what we talk about when we call it like a platform. We're becoming like a product or platform for other teams across the company to leverage for their own needs. So one of our biggest challenges and which honestly continues to be a big challenge is how to scale the relationship management piece of this because ideally you're not just auto paying these maintainers every month and never talking to them like you could that's already a great goal but you kind of really want to be able to have a relationship with them and if you're trying to scale up a program that can often be very difficult. So I'm just going to walk you through a little bit of the experience that we went through and if you're still very early stage like you might recognize some of these things if you're at a later stage it's good to know we're all having the same problems. So kind of phase one is often just the person who pays them is the person who talks to them. That's just the default and makes sense and you kind of even if you have a rotating roster of maintainers that you're supporting you still have that one person who's responsible for talking to them all and this can totally work but you can easily see how quickly this is not scalable or sustainable and if that one person leaves you lose all of those relationships and I would say in our case this didn't work out because we were already too big. So almost no one employee yet striped knows the complexities of every single product out there. I say almost no because we have some very talented technical solutions engineers that I think would be astounding in how much they know but for everyone else this became a choke point because basically like somebody a maintainer would like come talk to me they'd ask me about something and I would have to try to figure out like number one what product are we even talking about what team is that like how do I map this out to who I'm supposed to be talking to and we were just kind of lacking the expertise or the buy in from those teams to necessarily make these questions a priority so sort of what we shifted to phase two and about I think 2021 was we brought them all into a program and this was our equivalent of a champions program we called it community developer experts and in that case they could reach out to multiple people that they knew and they often knew a lot of people already and it was often through a lot of varied channels you know Twitter, Twitter DMs, Discord private channels but as long as they referenced like hey I'm in this program hopefully within Stripe people would like funnel it to the right place so in this sense we took the burden off of one person triaging everything it allowed our maintainers to talk to us where they wanted to because there was no one platform that everybody was on even GitHub so we could kind of meet them where they are and rather than like one person like me trying to find different teams you kind of had different teams hopefully all funneling to the right place and this actually I would say worked alright for a bit probably about a year at this stage though I'd say one of the downsides was that we didn't have an actual like full developer CRM yet so we often had a lot of people like comparing notes or not comparing notes about what was happening like who had talked to who and it was easy for things to fall between the cracks of one person forgot about something so kind of what I would maybe call stage like to be is as we grew we wanted to try and see if we could give these maintainers some more personalized contact so we still had the champions program running and that sat within developer advocacy and we tried to assign certain maintainers to certain developer advocates or DA's so our volunteer mentors based on their areas of expertise this is kind of like if you're familiar with sales it's like an account manager model like each project would have their own dedicated point of contact who is hopefully an expert within their particular language or area or what not and I think our main challenge here was one we had to make sure that these points of contact were still talking to each other we wanted to make sure they're surfacing pain points so that we could learn if something is a problem for one maintainer it actually was for multiple ones and should be escalated more and we wanted them to be sharing knowledge more and so I would say that this worked out in some ways and not so much in other ways maybe partially because of the way we went about it so like I mentioned earlier we had some who were with DA's with DevRel and we had some who were just like product team like volunteer mentors essentially and so DevRel and DA because this is their job they knew how to be literally an advocate for their pain points and because as a team we're always needing to be prepared for what's coming down the line generally we had a pretty good visibility of sort of what's happening what's right and we could help them figure out a little bit like what should they work on next or is there something big coming down the line they need to worry about on the flip side volunteer mentors are really good about the fact that they were in their specific product team so they had great subject matter expertise they could answer like a question about billing like in a second because they worked on it they know how it works and they could also directly monitor the progress of any feedback which is always hard within a company right that feedback loop falls somewhere along the line you tell somebody something doesn't actually go anywhere they don't know but while these product team volunteers had really great subject matter expertise they didn't have DevRel expertise which we just I think failed in realizing that DevRel is also a subject matter that you need expertise in and so I think if we could go back we would have given them a little bit more structure and maybe just the crash course and how to literally be a developer advocate you know how do you advocate for team points how do you check in on their project management how do you provide support on like maybe what they should be doing next and around I think maybe 2022 we kind of wound down the mentorship program and just another aspect of why we had to wind this down was we just didn't have as many DAs anymore because we lost a team we lost a lot of team members in 2022 so kind of the state that we're at now that we're also still trying to figure out is can we move towards something that's kind of like one intake you know as I mentioned earlier some people DM does some people pinged us on discord we even still had a forum going sometimes even email so like due to a convergence of factors that's right we kind of ended up settling on discord and that's this I have to say is just very much what worked for us that's just where a lot of them tended to talk to us not everybody still is on discord and we try to remember that but that had the benefit of sort of dispersing the taking on of responsibilities because we could have a ton of people in there and as long as somebody was making sure that somebody got answered by somebody within some reasonable amount of time it was working so to be honest we're still working this out we don't want it to be something as formal as like on call or like assigned responders but we want to make sure that we're still getting their questions answered cool so moving right along with more rapid-fire tactics budget renewal can be your friend it's basically a forcing function for legitimizing your sponsored program but also is an opportunity for you to ask for more money on a regular cadence to talk upwards managing outwards and sharing like the ROI of your program thus far which is hopefully evidence for you to expand it to more projects going forward we've heard this being a very critical moment in time from our peer companies when looking into how they've used it we've even heard stories from another Ospo who got creative with this process and towards the end of the year there was I think a marketing team that was looking to do some spend to meet to fill up their budget before the end of the year and they got creative and sponsored an open source foundation or team using that marketing budget basically the Ospo can function in this middle ground of figuring out how to map money to maintainers in need a lot of the work of running an open source sponsorship program is actually just operations it's admin it takes a lot of your time and the best thing that we learned here was treat your sponsorship platforms like regular vendors you know get them in the system there's no reason for them to have a different money flow just because it's money being spent in a different way and the reason this helps is because it legitimizes what you're doing in the eyes of the company you know onboard your sponsorship platform through the normal vendor processes even though it can be often very painful I can talk about that a lot but it allows your finance orgs to engage with you on the terms that they're familiar with you know they understand purchase orders they understand invoicing they have the flow that everything goes through but this also allows you to have regular budget review like we talked about to get those reports and visibility into your expenses and there's also just less month-to-month operational burden for you even if it takes a lot more to set it up up front for example you might be submitting expenses every month at one point we had somebody submitting expense reports for like five figures every month that always got kicked back by the team being like what is this what are you trying to do with your P card so for us personally we use github sponsors github has worked really well for us and it's a great resource for companies because it does invoice billing which is very very key for finance teams it tells them what you're spending this money on in a way they understand and it has typical procedures like purchase orders if your company is at a point of needing to do PO's I'm sorry so are we but if you're not at that point yet it still has all of these other things because these are things that your procurement team your accounts payable they will understand how this works and I want to emphasize with all of this that while this is where we're at now do what works for you at your stage you know P card works totally well at the beginning for sure but remember that this might not scale with your program and just remember to revisit it regularly as we do with all of the other processes within your open source program sponsorship just make sure to go down a route that legitimizes your goals because it will just make your life so much easier down the road I just want to mention that without establishing these procurement under onboarding we could never have run the bring your own budget pillar of our program because we want to attribute those sponsorships to different cost centers in our org and running it off a P card just wouldn't work that way so it really unblocked the growth of our program just by doing that simple administrative task of onboarding a vendor and we've heard from other companies that that has done the same thing for them for us, yeah GitHub was a major partner there we saw how great it was for individuals but also in partnership with Open Collective it can be great for teams too Open Collective is another platform we use for a few sponsorships and we tended to let them pick between these depending on if they were an individual maintainer or a team really like the needs of their team and how they want to split up expenses and the money coming in there we also had one sponsored through Patreon which is a because the maintainer wasn't a country that wasn't supported by these platforms and so this is just a reminder that Open Source is global in fact when we looked into our last video that recently we were sponsoring something like 13 maintainers across 11 or so projects from like this they were in 11 countries so because we're on the internet this is a global problem of moving money to these folks so we ended up with these three platforms and they've worked really well for us but more importantly they've worked well for the maintainers we're sponsoring but it's not just those three platforms like Open Source Economy is growing and they're starting to be more platforms services companies cropping up that help unblock this problem and I think more importantly a lot of these companies are looking for other companies to take advantage of their services to unblock their business needs in the same way we're trying to do internally at Stripe so hopefully we move towards a future of the Open Source Economy it's just the software economy we use certain services to contract through Open Source certain services to do bug bounties certain services to do sponsorship and hopefully platforms like this grow to meet the needs of everything in the software economy yeah and so we've kind of covered a lot of these different ways that you can support your maintainers and to be clear money is king that is what they have told us all to them but we wanted to end this talk on a hopeful forward thinking note so there's a lot of different additional ways for impact that we wanted to think about and we'd love to hear more ideas from you but for example like healthcare at least in the US I realize now that we're in Canada but at least in the US it is very difficult to do as an individual who's not employed by a corporation that has a group plan with somebody Open Source Collective if you actually google this it's a really cool thing with this around how they can help do these employment payroll benefits things other things that you could think about is do you have a lot of experience doing product management or project management because maybe you could help your maintainers sort through tickets to prioritize or figure out time commitments because a lot of the times an engineer will start an Open Source project to fix the problem that's what engineers do but they did not sign up to be a PM they did not sign up to suddenly manage a project that now has people asking them for features to fix all these things they want to do different things with it so you could potentially help with that are you in a different country or do you sort of have other subject matter expertise on something legal or financial you can't give official financial advice but you could probably give a little bit of guidance on this and especially at Stripe just because of the people who work here are very interested in financial systems a lot of them are familiar with how money flows work how financial systems work that might be very opaque to others in a different country so you know share the knowledge that you have another thing that we thought about is sharing in kind infrastructure you know you probably have a lot of processes set up for testing for code quality for CI for translations maybe platforms for documentation if you already have maybe a subscription or some tooling setup can you share this with them as an arm of your team how can you extend these team resources to them so they can be as efficient as the people that you know you're fully hiring and anything else like these are just a couple things that we thought of that you could potentially offer on top of your sponsorships we highly encourage you to talk to your maintainers and just ask them how can you sponsor them and support them the best in the hope and the dream together that you know we can build the future of sustainable open source one random idea that just came to mind was that one of our maintainers also was running businesses on Stripe and he was interested in discussing basically like cost saving exercises through our platform and so that could be like an interesting way like use the leverages leverage of your business to help the maintainers out in the ways that they need but yeah thanks for attending our talk love to answer any questions that you have and yeah please come up and chat with us afterwards if you want so far that's been good enough and measuring success but I'm really struggling with this so do you have something to show the money givers here this is not just nice it's this is the impact that yeah do you want to repeat the question for people? yeah repeat the question concrete examples of how we measure ROI in order to make it easier for us to pitch upwards and ask for Money First Launcher program the ones that have worked for us the first case was measuring business growth for us we are an API platform so when people use our platform we can measure the dollars that are attached to those various API calls if you're familiar and then we can measure the actual ROI of using the various for our users measuring the various open source projects that we're investing in so we just look at the analytics of those users using the products that we've sponsored and then we correlate that back to dollars we've earned off of those users another way you can look at that is like hey there's like how many users are using those projects and then look at the amount of money those users are making you out of business and you can correlate it that way we're also looking at things like we have a rough estimate about how much engineering hours you should invest in to save on AWS costs so let's say like hey like if you can spend one hour here and save five hours per month of AWS costs you should like do that instantly we have like recommendations for engineers that way so you can roughly correlate like cost savings on your infrastructure side with time spent on the engineering side and so for us we've established a program to let teams say hey we think that like fixing or investing in this open source dependency could save us on aggregate like 40 engineering hours per month and so we can see like roughly how much cost that will save going forward now with that one that leads to less of a reoccurring nature because once you fix those problems potentially there's less cost to be saved or the other way around with ROI investment for tracking revenue growth that ideally like will last forever because those projects can like grow indefinitely so the cost saving one potentially is more attuned to sort of an open source grant like give the money make sure that these particular problems that we're facing get solved and we know that that will lead to the amount of the cost saving in engineering hours that we are hoping to fix and then the other one that's come to mind for us is unblocking sales opportunities so we've heard you could like if you're like in a sales driven company then unblocking particular sales cycles could be massively advantageous just helping spend one sale in a year could be enough to like you know fund your open source software program depending on the size of sales your company makes and so especially in a software company like Stripe figuring out how to get involved in those projects and see what things are missing like maybe a user needs a particular mobile SDK that is missing in your supply software supply chain if you will figuring out how to unblock that with open source solutions building trust there saying like hey we don't have this solution internally but we have direct relationships with these maintainers that have built this third party solution and we basically are vouching for it as a safe solution for integrating with your platform and that could be enough to like unblock the trust there needing to land a sale like that those are things that we think about day to day but then again because we want to be a platform we like to think about like other teams deciding what our line means to them too we're going to come up with our line models for ourselves to try and scale the program internally but we want other teams to tell us like hey this is what our line means for us we care a lot about this number growing or reaching more of this type of user or something like that so they can tell us how to measure that success for them I think it's almost lunchtime at least that's what my stomach tells me but feel free to come up and say hi thank you