 So welcome everyone to sustaining open source software. Yay. Glad to have you here. Thank you for clapping for me. I appreciate it. So yeah, huge thanks to organizers for having me. It's such an honor to be here. I really wish I could be participating in more of this track. I've been stuck at the GitHub booth if you want to say hi at any other time during the conference. But hi, my name's Abby. I run open source maintainer programs at GitHub. So it's been great being here and just talking to so many of the maintainers I've been like slacking with or GitHub issuing with. There should be a verb for that. I'm seeing so many of you in person. I'm an organizer for Sustain OSS, which is a big reason why I'm talking about sustaining open source software today. Hi Justin, I see you here. And I'm on the board of the OpenJS Foundation, which has been a huge pleasure, just re-elected. So really happy to be here with all of you. So before we start, I just wanted to list all these contributors. So thanks to everyone. I tuted and tweeted back in February. I'm asking for examples of different ways that open source projects have become sustainable over time. And you all came through. So many people answered this. It gave me a lot to think about and really changed the direction of this talk. So thanks everyone for weighing in. I didn't have blue sky yet. So just tooting and tweeting. So here's what we're covering today. So first, I'm just going to introduce this idea of sustaining open source software as supporting maintainers and how that's really, I think it's really the key and a really helpful lens of thinking about sustainability. And then going through these three areas with community around succession planning, financial around paying maintainers and the technical side just making it easy to use and get started. And just quick plug, it is maintainer month. So please tweet about that. It's one of my metrics. Okay, so first sustaining open source. I did frame this talk around sustainability. I think there's a lot of conversation I wanted to tap into there. But especially after going through all those tweets and toots, I think what I'm really interested in is the resilience of a project over time. How do projects really survive all the troubles that open source goes through? So I do think that the biggest factor that affects software's ability to run longer term is maintenance. Just with tech changing so quickly, unmaintained software really becomes out of date super fast. So I do really like this quote from Toby Langelle. Many of you know him from the OpenJS cross-project council. But he said, in open source, the maintainers working on the source code are the scarce resource that needs to be protected and nurtured. He thought I was taking this out of context from his tweet. But I do think it is a nice way to think about just nurturing these open source maintainers to protect open source long term. We've seen this idea, like Nadia Egbal's book on working in public. She talks about maintainers' attention being that scarce resource. I do like this framing of the person being important and needing to really support them. And this really aligns with what I've been seeing in movement-building communities in theory, where people really invest in those leaders so that the movement can stay long term. So yeah, this whole talk, we're gonna be talking about how to help maintainers so that open source can thrive. So here are the three areas. And I will say not all of these areas are needed for a successful long term project. So often you just need one or two of them. For the three areas we're gonna dive into today, first there's community with succession planning, which I think it's just a nice way to prioritize who you work with in the community and who you're investing time with. Next one is on the financial side, how do you pay maintainers, big topic. And then third on the technical side, just make it easy to use and get started. So for example, if you are like a specialty library, oftentimes it is harder to get started, but that's just because it's like so technical, you need a very specialized knowledge there. So you can survive long term if you have that financial payment of maintainers and you have new contributors coming in and becoming maintainers, that's a nice way. And then the other side, the corporate open source, where it's between the financial and the technical. I think especially if you're a company, it's much easier just to hire new maintainers. You have the capacity to do that and onboard them. And then at the very bottom, I really like open source archetypes that the open tech strategies group put together. They have an archetype called single maintainer house plant, which I'm sure many of you have seen, those open source projects, or it's just someone's little hobby, they're just watering it every now and then. They're totally fine doing that. So they don't really need that financial aspect, but they do need a plan to what to do after when they're done watering their plant. And they do need some of that technical and easy to use and get started. Hey, so we're gonna go into all three of those. So first, succession planning. So in the corporate world, a lot of people think about this as part of their longer term strategies for the company. We have seen a lot of successful projects run as BDFLs, but tech is relatively new compared to many other things. So we are starting to see people who are retiring. We have seen maintainers who just wanna stop maintaining. And I think we're gonna see more and more of that as time goes by. So I think it will be really important to think about succession planning. And a fun example that was tutored at me, yeah, this one was tutored, yeah. It was about the FreeBSD project. So Deb Goodkin's the executive director there. There's a quote from Kirk McCusick, who has been a developer and committer for that project since 1993. So he says, a successful project has to be able to change the leadership, otherwise leadership becomes dead wood, which leaves the project rudderless. And yeah, it is a helpful view when you're thinking about, especially if your project has like so many people wanting to contribute, how do you decide who you wanna mentor? Who are you gonna invest in? And I'd recommend investing in people who you think could take over the project longer term. Let me get some water. So yeah, I put it on the slide. Be intentional when succession planning, about succession planning when selecting mentees. So especially if you have a demanding project where so many contributors are coming along, I like to apply some criteria just for selecting who you're gonna mentor. And just at the bare minimum, I like to recommend these three. I find if a project is especially technical or needs some extra skills, they'll add a fourth or a fifth one. But at minimum, first is just being mission aligned, that people are coming to your project because they're excited about what it's doing. A lot of times you'll find people coming for more extractive reasons, which is fine. And you can still help them and still work with them, but maybe don't invest as much time with them. So make sure they actually want that project to succeed for its mission. Next is that they're available. They actually have time to contribute. A lot of people are excited and wanna help, but then they just like, they're super busy. That's also fine. So just like prioritize people who actually have time to help you out. And then third, that they're willing to learn from myself or whoever's mentoring them. Often there's like a ton of knowledge exchange between the mentor and mentee. So making sure that they actually wanna listen to you just makes things a lot smoother. So I like to look at these three if you need like a specific technical skill, add that as another criteria if you don't wanna teach that. But doing that I think can really help you invest in the emerging leaders early on and just have a longer term vision for your project. So the case study at Mozilla Iran Open Leaders, which is a mentorship and training program on open source. And the vision for this project is really to strengthen open projects and communities around the world. So project leaders would apply for mentorship and we'd use selection criteria based on those three things I said before. Around that being mission aligned, that they actually have the time to spend. I put 10 hours a week on this and that they're willing to learn from their mentor. So this helped us have as high as 85% retention rate where people who went through the program would come back and mentor others. So you can see the orange ones are like the people who mentored new folks. So it really helped us scale the program because mentors were coming in. We were able to delegate a lot of that work. So it wasn't just me mentoring everyone. That was the first couple of rounds was just like me mentoring people. And then even after the program finished, so you'll see that last row it looks like no one came back as a mentor. That's cause we didn't run it another time afterwards. But this did decentralize into 10 community run mentorship programs. So there's open life science, open scapes, open hardware makers, peer review. But today they've mentored hundreds of more projects and they've raised over a million dollars from funders like CZI and NASA. So because we were selecting specifically for folks who wanted to continue this mission going forward, yeah they were able to continue it even after I stopped running this program and after Mozilla stopped that program. So yeah, just take away for succession planning. You can't mentor everyone. Your time is limited as a maintainer. But add that selection criteria, add some sort of selection step. And that will help you prioritize investing in the future maintainers and people who you can actually delegate to longer term. Well the second part is paying maintainers. So talking about some financial practices. There are a lot of options today. So I'm a big fan of GitHub sponsors. There's also Thanks Dev, Stackade, Open Source Collective, Tidelift. And Justin, here's your tweet. But Justin tweeted, if you told me 10 years ago you'd have multiple businesses building services to help sustain open source projects, I would have been skeptical. Can't imagine the next 10. And it is really exciting just to see more and more money going into this ecosystem. So with GitHub sponsors, just a quick plug, last month they launched GitHub sponsors for organizations. I know the team has done a lot of work making it easy for companies to give money to open source. And so we've seen a big increase. I don't have the numbers right now of people doing that. And bulk sponsorships is also available. So one of the first things I worked on when I joined GitHub was actually their maintainer month sponsorship last year. It's maintainer month again, in case you forgot. But we had half a million dollars and we just distributed equally across all our dependencies. So now that's built into GitHub sponsors. So if you go to your explore page, you can see all of your dependencies that have sponsors enabled and then you can do a bulk sponsorship across all of them. So we're really trying our best to make it as easy as possible for companies to give money to open source. So the funding landscape, it has changed dramatically over the past couple of years. There is a ton more money available. So with open source collective, they saw a 30% increase in payment directly to maintainers, which is huge. And there's a lot more focus on securing the supply chain. So we saw that executive order on improving the nation's cybersecurity. And there are things like this NSF grant for pathways of open source ecosystems. Also GitHub is currently running their first GitHub accelerator, where they're really thinking about this question, like how can we set up projects in a way that has ongoing support for maintainers? And I do think we need more business models that will work for maintainers. There's only a few right now. And I'll talk through what we have now. But I really am excited to see what happens with this first batch of accelerator graduates. So some models that can work today, and this is just super illustrative and generalized, not meant to be comprehensive. But I do see three main ways that projects are getting money to maintainers. So first is like that tips and donations piece. Second, getting hired at a company to work on an external open source project. And then third, the company builds and maintains an open source project. And the third one includes like the consulting services that we've started to see more too. Gonna go through each of those. So tips and donations, this can be to a foundation or to an individual. This works really well, I find for academics and nonprofits who are really used to getting grant funding, and they're happy with those one time large donations. I find a lot of people in industry, a lot of people like not in academia or don't find that stable at all. But for a lot of people that works really well. So Jupiter is a nice example coming out of academia with a Fernando Perez. Next is a membership model with like CNCF, OpenJS has us too. That works really well just having companies pay money to be a member. I do think sometimes that money doesn't always go to the maintainers, but it does give a lot of great ecosystem support that can be super helpful. This also works super well for a visible projects like Vue. So if you're like one of the top of the stack projects where developers are like consciously using your project, it's much easier to get donations compared to if you're super low down on the stack. Content creators, people like Caleb Porizio have done a great job just sort of monetizing their open source by creating content around that. And then another one I thought was interesting was maintainers in lower cost of living areas. So I interviewed COVID Goyal, he maintains caliber. And yeah, here's the slide for that. So at GitHub University, we had a panel on expanding GitHub sponsors globally and both COVID and Carlos, Becker on the panel. We also interviewed Yusuf, but he didn't mention this. But they both said that the strength of the US dollar really helped. There are like those donations go far. So COVID was actually able to go full-time open source after moving from the US to India, where in the US he had, he was just aiming for pizza money. He just wanted a little pizza party every now and then for his friends. But then moving to India, he was able to like make a living out of that and more people were donating. But yeah, caliber is a cool project. I don't know if you've used that for like the e-books. Okay, the next model I see is like getting hired at a company to work on external open source. So this is great for companies who wanna have that direct line to a project. So this is just one example. Keeley Hammond, she works at Slack to work on Microsoft, sorry, she works on Slack to work on Electron. But Electron also has maintainers that aren't Microsoft. That's what I meant to say. And there are many other examples. But I do think this is a nice way if you can convince a company to do that or to want that direct line with you. And then third one is like a company builds and maintains an open source software project. It works especially well when it's part of their core business models. You see that with Versailles, where they sell the hosted services for Next.js. We've also seen quite a few, I've seen more and more of this consulting services where projects are able to maintain themselves by just selling consulting services or adding features. I find this works well if you don't care about scaling, because again, you're selling a pretty finite resource. And I know some people are really interested in selling like just an hour to chat with me as a maintainer. That's also pretty, it's a nice way to bridge funding if you're looking to scale or a nice way to just sustain you and your family and not try to get like that VC funding. Okay, so those are my three super broad overviews of ways I've seen like funding get to maintainers. Again, not exhaustive, but I just wanted to kick off the conversation here. And then third, just an easy to use and get started, making sure that you're doing that for your project on the technical practices. So a few things here, there's documentation, making sure it's well documented, testing, CI CD, CI CD, yeah, and cloud developer environments. So all these things reduce that maintainer burden. It helps onboard new maintainers and ensures that the code could live on if suddenly left un-maintained. If you have this infrastructure there, it helps with some of that longevity. So just first up with documentation, another quote from Kirk and Cusick. When I asked him what did FreeBSD do really well early on that led to where it is today and he said emphasize documentation from the start. And we've seen this also with like Tailwind was talking about this too recently. Yeah, the next one for testing and CI CD. Here's a little demo of GitHub Actions where it's really nice just in the platform. But when I was mentoring that with the Unicef Venture Fund, we required over 80% code coverage for all of the projects there just to make sure that it is easy for others to contribute to and there is some stability for that project longer term. And then having a cloud developer environment, I think CodeSpaces has been great for this. And it's been fun working with a web pack to get this enabled. But now you can have up to 63 hours of CodeSpaces for all users every month. And it's a great way to onboard new contributors quickly which is a great beginning of that pathway to becoming a maintainer. And here's a picture of Craig. He's a PM for CodeSpaces. If you want to talk to him, there's a QR code. But he, yeah, he's really, he's really good at helping these open source projects sort of get started with CodeSpaces and get things going. So quick summary. These are the three areas that I talked about for the succession planning with the community, paying maintainers for the financial fees and then making sure it's easy to use and get started. If you're interested in these, we do have these sustained together conversations every other Friday. So next one is next week, but at noon Eastern or nine Pacific. But you can check that out at Discourse.SustainOSS.org. So it's a fun, we just talk about these things. It's pretty casual and it's just a nice, it's a nice way to see what's going on in the world around sustaining open source software. We also have a private maintainer community on GitHub, so maintainers.github.com. You can request an invitation there. And it's a great place just to talk to other maintainers and to see what they're doing. And I've been running a series of workshops with this group just to document best practices in open source that we can share that with the broader maintainer community. Just so people can be doing better open source overall. And did I tell you that it's maintainer month? I don't know if I mentioned that yet. But no, yeah. But we do have a booth in the sponsors hall. So please come. There's a wall there where you can thank maintainers. You can get your selfie taken. We also brought in the ChangeLog podcast and they're live recording maintainer stories. So if you have a cool story as a maintainer, we do wanna amplify what you're going through. We do wanna bring more visibility to what maintainers do. Yeah, chat with them. They're recording things. Say hi, they're cool folks. All right, so I did wanna leave a lot of time for questions and comments. This was meant to be more of like a discussion starter. But you can find me on the internet. I'm Abby Kebs in those places. I just got blue sky. I don't have invites. Please don't ask me for any. But that's where I am. So yeah, thanks everyone. Any questions? Yeah. Could you just, oh thank you. Could you just like probably share your thoughts on like what mechanisms might exist for projects that like actually be able to like pay contributors, not necessarily like on a full time basis, but you know, if projects will be able to like have like bounties or something for some of the issues, you know, people like me, especially living in a place where again the US currency is stronger, then I would just spend a whole day just going through different projects and seeing, you know, what I could help out with getting things done because you get some kind of financial benefit out of it as well. So could you just like share your thoughts on that? What exists? For paying contributors. There are a couple of projects that I think do this really well. Avenue with View, they have a great program where they like dole out money to contributors. Also Webpack is talking to them last week about it. They also have the measure, they actually look at the metrics of the project and surface the contributors who they wanna sort of give money back to and then they pay them out. But they wanted to do it in a way that's not gamified. So it would be a little harder in your case if you're like trying to find things to look at and contribute to. I know there's bug bounties are huge. So that might be a better way for if you wanna specifically invest your time in something that you can get money from. But yeah, I definitely think paying contributors is really important. And I know not all projects are at the space where they can actually do that yet. They still can't even pay their maintainers. But it's great to see, yeah, View and Webpack especially have been doing a great job there. Yeah, but I do like, I know the sponsors team has also been thinking about sponsored issues. That idea of like, oh, I'll fix this issue if you give me money, which is a little bit similar to that. But yeah, that's not implemented at all. It was working. I was wondering if you could talk a little bit about how groups working on projects can organize starting to take funding. Because I've had a few conversations in some projects that I've worked with where there was at least one dissenting voice. And if there's any dissenting voice that it becomes very hard because then if that person doesn't want to take money, then like, but they're important in the project or doing the work, then other people do. It seems like quite unfair and maybe there's some mismatches. So I was wondering if you had any thoughts on how to best approach that topic. Yeah, no, I've definitely seen that also with projects. I think that's why governance is so important when you have a project. Just making sure you have a clear set of who makes the decisions, how decisions are made so that there's no questions. So if you have one dissenting voice, what will you do about this? Are you a consensus model? Are you like majority vote? Just have that documented so that you know how to handle it if that comes across. But yeah, it's really tricky. I've also heard like, if you have maintainers in different parts of the world, how do you do that? That's also very contentious. But I think that's why governance is so important. Do you know of any of the example projects which it has raised to the governance and had to be resolved? Probably. I will think about this. Yeah. Yeah, yeah. But I think, no, it's definitely tricky with projects. It's also a danger if a project gets a sudden windfall and they weren't expecting it. What do you do with that? And it was interesting with view. They were on the sustained podcast a while ago and I think they were just sort of saving up money for a long time. They didn't really know what to do with it. And then they decided to, oh, let's pay the contributors. And that's how they started doing that. I think some other projects also start paying their dependencies. So just passing that money on forward, which is really nice. But I do think not even just raising it to governance, but knowing how you're making decisions as a project is really important before you get money. Yeah. Yeah, Michael. Thanks. Yeah, I just wonder, sometimes I hear the concern like, no, we shouldn't pay developers because that's going to like disincentivize other people. Do you know how to overcome that concern? Because that's like, you know, that's something where I think we should be paying or figuring that out, but that's a concern that's often raised to me. Yeah, I think someone to talk to who's thinking about this a lot, like last week I was just talking with Sean Larkin on the Webpack project. And they were really thinking intentionally about their metrics and keeping it hidden. So people aren't gaming the system, but rewarding the kind of actions that they want to see. So also taking an account like spam, but looking at like how much someone's done and is this sustained over time? Is this a flash in the pan? Is this hacktoberfest? Like looking at different things like that, I think they've done a good job of being thoughtful about it. But yeah, I'd talk to Sean. Thanks. Cool. Well, that's it. I'll be around. You can find me at the maintainer month booth if you want to say anything. But yeah, it was lovely being here. Thank you all so much.