Sustaining Free and Open Source Software
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61673 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Software maintenanceOpen sourceSoftware maintenanceSelf-organizationComputer programming
00:34
SoftwareMereologyDependent and independent variablesTwitterSoftware maintenanceSpacetimeData conversionOpen sourceBitFamilyDivisorProjective planeBuildingShared memoryReal numberResultantOpen setSelf-organizationMultiplication signComputer animation
04:02
Frame problemWave packetSoftware maintenanceRight angleContext awarenessData conversionBitGoodness of fitOpen setSource codeComputer animation
05:07
Software maintenanceEvent horizonTraffic reportingBitProjective planeTwitterOpen sourceLibrary (computing)PlanningData conversionMultiplication signTerm (mathematics)WhiteboardOpen setDiagramEndliche ModelltheorieStrategy gamePanel painting
08:35
Open sourceTouchscreenPlanningTerm (mathematics)Projective planeView (database)Software maintenanceOpen sourceCore dumpBuildingComputer animation
09:21
Selectivity (electronic)Multiplication signComputer programmingProjective planeTerm (mathematics)Software maintenanceSet (mathematics)Different (Kate Ryan album)PlanningMereologyObservational study
11:05
Menu (computing)Computer programmingBit rateSlide ruleRoundness (object)PlanningProjective planeMultiplication signOpen sourceProcess (computing)Open setArithmetic meanDot productComputer animation
13:25
PlanningOpen sourceOpen setEmailOrder (biology)Game theorySoftware maintenanceMultiplication signSlide ruleHand fanCircleRight angleSoftware maintenanceType theoryEndliche ModelltheorieProjective planeOpen sourceMultiplicationSystem administratorService (economics)TwitterGroup actionStack (abstract data type)Product (business)MereologyQuicksortSelectivity (electronic)2 (number)Online help3 (number)Cartesian coordinate systemPlanningCore dumpBit1 (number)Decision theorySoftware developerStreaming mediaOrder (biology)Electronic mailing listTerm (mathematics)
20:01
Software maintenanceSoftware developerDemo (music)CodeIntegrated development environmentProduct (business)Staff (military)GradientInformation technology consultingEvent horizonTwitterIntegrated development environmentMereologySoftwareOpen sourceInformationData conversionBitSoftware maintenancePlastikkarteLink (knot theory)Inheritance (object-oriented programming)Endliche ModelltheorieMultilaterationProjective planeCodeSoftware developerLine (geometry)Open setMultiplication signComputer programmingPlanningDifferent (Kate Ryan album)Point cloudSoftware testingTelecommunicationService (economics)Core dumpRight angleMobile appExistential quantificationComputer animation
26:37
EmailOpen sourceOpen setCodeReduction of orderMobile appSoftware maintenanceProduct (business)NP-hardAndroid (robot)Computing platformGroup actionDifferent (Kate Ryan album)Process (computing)FrequencyGoodness of fitDisk read-and-write headPoint (geometry)Business modelTouch typing1 (number)Projective planeRule of inferenceMultiplication signCore dumpServer (computing)CausalityComputer animation
32:38
Projective planeDynamical systemOpen sourceSurvival analysisWordEndliche ModelltheorieBitData conversionMultiplication signOpen setSoftware maintenanceInternet service providerBusiness modelCASE <Informatik>FeedbackGoodness of fitComputer programmingData managementSelf-organizationDifferent (Kate Ryan album)Flow separationGoogolLink (knot theory)Computer animation
38:38
Computer animationProgram flowchart
Transcript: English(auto-generated)
00:05
So yeah, today I'm going to be talking to you about sustaining free and open source software, exploring community, financial, and technical practices. I was trying to go for the longest title possible. Do you think it's long enough? Probably could have gone longer.
00:21
So my name's Abby. I do run open source maintainer programs at GitHub. I'm also an organizer for Sustain OSS. And I care lots about maintainers, about the open source ecosystem. So I'm really excited to talk to you about that today. So before I dive in, I do want to say thank you to all of these names, all these handles. About a week ago, I tweeted and tweeted about this talk,
00:44
but also just asking for examples of sustainable open source. And all of you really came through. There was a lot of responses, a lot of things to think about. And yeah, it really changed how I was thinking of this talk. So it actually gave me more work, but I think it was worth it. So you'll get to hear some insights from all
01:00
of these people today. So thanks, especially if your name's up here. You're the best. So here's what we're talking about today. So it is my first time at FOSTM. So yeah, thank you so much to the organizers for having me here. Yeah, it's been really fun. I've really been enjoying this conference. Everyone told me it was going to be really cold.
01:20
But I think they forgot that I'm Canadian. And this is really nice weather. So it's great here. So I don't know what everyone's talking about. But yeah, so I do want to share a little bit about myself, my background, and why I care so much about FOSS. And then we'll go into sustaining FOSS. And spoiler alert, I do think maintainers are a huge part of this. And then from there, we'll look at those three lenses
01:41
around how we can be sustainable through community, through financial, and through technical practices. So first, some background. It's a picture of me and my grandma, my Lola. Also, my little brother's there. There are pictures of me and just my grandma, but I really liked this one, even though my brother's stealing the show. I don't know, it's fun. And I like how big my eyes look with my glasses.
02:03
It's cute. But I started my career writing open source software at the Ontario Institute for Cancer Research. So this was really meaningful work for me, because my grandmother, my Lola, she had passed away from cancer. So this idea that I was helping someone else's grandma, someone else's Lola, was really powerful.
02:20
And it was really, yeah, really meaningful work. But the longer I was in academia, the more I realized how often scientists maybe fudge their data a little bit or not share parts of their data, just that they can get published or they can get the best results and get tenure or get that funding. And this was all happening at the expense of real innovation. So I was really outraged at that.
02:42
That's when I got really into open science, especially using open source and open data to help us find the best innovations. So I do think if we're sharing and we're building upon each other's work, that's how we'll do the best in the world. So since then, my career has gone from maintaining open science tools to teaching open source best practices.
03:01
And now at GitHub, I'm supporting the maintainers. In this new role, I started about six months ago, so I'm still a bit new. Actually, seven months, I counted the other day, yeah. So I'm gonna be sharing some of these experiences as we go through the talk. All right, so now sustaining FOSS. Again, supporting maintainers. So I did frame this talk about sustainability,
03:21
around sustainability. I do like, I think there's a lot of conversation happening in that space. I do think it's important. But after that tweet and the responses I was getting there, I realized I care a lot about project resilience and how projects are able to survive over time. So a slight shift, but I think it helped me
03:41
really think about how are projects resilient and strong and able to withstand troubles that come their way. So to me, the biggest factor that affects software's ability to continue is maintenance. In this changing tech landscape, if something isn't maintained for a while, it will really quickly become outdated.
04:01
So I really like this quote from Toby Langel. He's an open ecosystem strategist. And this quote says, in open source, the maintainers working on the source code are the scarce resource that needs to be protected and nurtured. And we're missing a bit of context where he's talking about the commons. And I'm a little bit too jet-lagged to have a commons and public good conversation right now.
04:22
But I do think this is an important framing. I think it's important to be thinking about maintainers. I know Nadia Agbal in her book, Working in Public, she also frames this problem as the resource is the maintainer's attention and trying to get their time. But I really like this framing around the person itself of a maintainer. And really, what can we be doing to support maintainers
04:42
so then we are best supporting resilient open source? So this aligns a lot with what I've seen in movement building, where there's a lot of investment in raising up new leaders so that the movements can continue. And we also see this in corporations where people are always like, there's a lot of leadership training. Leaders are really important in communities
05:01
and it's the same for open source. Maintainers are really important for these communities. So if we look at supporting maintainers, we're gonna look at these three lenses. And you don't have to address your project with all three of those lenses at once. I think that's why I made an event diagram. But we're gonna look at these three. So the first is on the community lens
05:21
with succession planning. This one might not be as intuitive, so I'm gonna dive into that a little bit more soon. The next one in pink is the financial side, so paying maintainers. And this is what we've heard a lot about lately, getting money to them. And the third one in blue is on the technical side, making it just easy to use and get started. So really supporting maintainers
05:40
by taking away some of the maintainer burden. But also if a project is suddenly unmaintained, making it easy for someone to just take it and then run with it. And then, yeah, just looking at the overlap pieces. Say you have like the pink and the blue, you have the financial piece and the technical piece, but you don't have that community piece.
06:02
That's often like corporate open source, especially if they're not really investing in the community. And I think that's still valid and it's still fine. And this way it's okay because they can just pay new maintainers to come on board usually. So you don't really need all three of them to be completely sustainable. And then if you have just the green and the blue, so the community side and the technical side,
06:22
but not that financial piece, that's like maybe a hobby project. I also really like how the open source archetypes, they have one, this is a report that was put out by Open Tech Strategies in Mozilla. They have a archetype called single maintainer houseplant. So if you're just like a maintainer by yourself,
06:41
just like watering your little plant, you don't really need funding. Funding might actually just hurt the project. But if it doesn't need that much maintenance, that's also fine. And then the last piece there, where you have the pink and the green, so you have the financial piece, you have the community piece, but really it's technically, like it's just hard to get started, hard to use.
07:01
That's often specialty libraries where you need like a really deep expertise in something to get involved. So those communities tend to have like very few maintainers that are very specialized and they're still able to sustain over time. So it's, but they have other pieces to help with that. And you can probably survive with just one of these three, but I didn't map out all of them.
07:22
It's a lot of things to map. All right, so the first one we're gonna dive into is that succession planning. It's the community practices. So I did take this term from the corporate world. So companies often like look at succession planning to make sure that their companies will survive over long periods of time. And I'll say, you don't need to have this
07:42
in open source, like BDFL is a model that we've seen many successful open source projects with BDFLs. But I do think that like tech is relatively new and open source is even newer than that. We're only starting to see people retire or we're starting to see people like get tired of maintaining packages and just delete them all. So I think we'll be thinking more
08:02
about succession planning as we're seeing this natural churn of people go through the ecosystem. And I did have a conversation after that too. I am really glad I tweeted about this talk. I forgot to say, I set a goal earlier at the end of last year. It's a tweet every day. I just wanted to push myself to do something.
08:21
And I would not have tweeted that if I didn't have that goal. I like to just sort of work on things on my own. But I'm glad I did that. So I'm working a little bit more open. But I did have a conversation with Deb Goodkin. She's the executive director of FreeBSD. And she pointed me towards this quote from Kirk McKusick. He's one of the original core maintainers for FreeBSD.
08:41
But he says, a successful project has to be able to change the leadership. Otherwise, leadership becomes dead wood, which leaves the project rudderless. Right, and that was Kirk writing this. So it's really small on my screen. He's writing just a piece on building and running an open source community, the FreeBSD project.
09:03
But I do think this view of succession planning is helpful when thinking about the community. And it's really helpful for large communities where it can be really overwhelming working with everyone. But if you're prioritizing succession planning, then you know where you can have the most impact for your community in the long term.
09:21
So an example I'll talk about, I think the easiest way to bring in succession planning is when you're selecting who to mentor in your project. So I like to suggest these three criteria so that you're selecting people who are most likely to become leaders within your project. So first is mission aligned,
09:42
that they actually care about this work and want it to succeed. So I know you've probably seen many people come to your project that are more extractive. They don't care as much about the mission, but they just want something from the project. They just wanna get something out of it. They're still good to have in the community. You can still welcome them. I just wouldn't invest a ton of time in them if you're mentoring people.
10:01
So first, make sure they're mission aligned, they're there, because they actually want the project to be there long term. Second, available. Do they actually have the time and resources to contribute? And it's great that we have these mentorship programs where they can get paid for their time, so this does open the door for more people. But if someone really wants to be part of this project,
10:22
but then they don't have the time, I wouldn't also invest that time into mentorship unless they get that time, or unless you get the funding to help support their time or whatever's needed there. And then the third one there is willing to learn from whoever's mentoring them. So you might notice I didn't put skills needed. I know some projects will add skills
10:41
as a different set of criteria, but I think it's much easier to find someone who's just willing to learn those skills that they need. And there'll be a lot of project knowledge that you'll need to transfer on to them as a new maintainer. Yeah, but I would add anything that really can't be taught you can put there.
11:02
Yes, I think that's what I had for this slide. All right, so I'm gonna look at this case study. So this is work that I did at Mozilla, and I was running Mozilla Open Leaders. And each of these dots is a project that went through our training process. And yeah, so it was a mentorship program. So when they entered, they had to apply, and we would give them questions based on that criteria I shared before.
11:22
So the mission for this program was really about strengthening open projects and communities around the world. So we'd ask them questions around like, what does openness mean to you? Or why do you wanna work open to see if they were mission aligned? Or did they just come to get some training? We asked questions around like, what do you hope to learn from a mentor?
11:41
How do you learn best? And then also made sure that they understood like, hey, we want 10 hours of your week each time. And really setting those expectations. So by setting those expectations, we set quite a high bar for people coming through. But I think if we hadn't set that and we were just getting people who maybe wanted to be mentored,
12:02
they may not have been willing to give that 10 hours, but setting them up front, like lifted that bar. So you got more people that were really excited about the mission and like wanted to help. Yeah, oh yeah, so then doing that really helps with some incredibly high retention rates. So especially at the beginning,
12:21
you'll see the orange dots are the people that came back and mentored others. So they actually did become leaders within the community. So our retention rate was as high as 85% in the early days. It gets lower as you scale because it is harder to keep that quality up over time. And then even after the program finished, so we did spin down this program.
12:41
We spent one more round decentralizing it and just working with past graduates to run 10 community-led projects. And many of those are still running today and they continue to mentor hundreds of students, not students, projects a year. And when I last checked, they've collectively raised over a million dollars from funders like NASA and the Chan Zuckerberg Institute.
13:03
And I haven't checked in about a year, so it might be more now. But it's exciting just to see, even though I wasn't running this anymore, this mission was still going on. There's people still learning about open source in their fields. And I was gonna make one more slide with all the people doing this, but I was very tired today when I was making slides,
13:22
so I didn't make one for that. Okay, all right, so succession planning. So just a couple of notes. Adding a selection step and criteria will really help you prioritize who you're gonna invest time in. And you just can't mentor everyone. There's a lot of people that will want your attention in an open source project,
13:41
but this is a nice way to sort of filter so that you're prioritizing for the long-term success of your project. Another place where succession planning can be helpful is when you're thinking about faucets incubated at a company, like corporate open source. So if, especially if there's open source happening
14:00
at a company that's not part of the core business, it might be time to think about where that project will go next in terms of succession planning. So a couple examples, maybe that will still spin out into foundation. So an example is the Rust project. So that was at Mozilla for a very long time, but they spun out another at the Rust foundation. Or partner with other companies for shared governance.
14:23
So the example I put there was Kubernetes, which was at Google, but now it's part of the shared infrastructure. So a lot of the big tech companies yeah, have this shared governance over this shared infrastructure that they all use. Okay, next circle was the pink one. Pay maintainers, yay.
14:41
So some financial practices. Oh yeah, I'm a huge fan of GitHub. I work at GitHub. But a lot of times when a project joins a foundation, you won't necessarily get money directly to the maintainers. You'll get a lot of support and ecosystem support, but I am so glad that there's companies like this
15:01
and products like this, like GitHub sponsors, like Thanks Dev, they're here, yay. Stack Aid, Open Source Collective, Tidelift. There's so many different groups just helping money get directly to maintainers, which is amazing. And I'm glad we're seeing so many of them. I actually saw this tweet from Justin Dorfman this morning when I was still making my slides.
15:22
He wrote, if you told me 10 years ago, we would have multiple businesses building services to help sustain open source projects, I would have been skeptical. Can't imagine the next 10. So I completely agree with Justin. It's great seeing so many of these. So just to share a little bit more about GitHub sponsors, there's this explore page.
15:41
So if you go there, you'll see the projects that your account depends on and which ones are eligible for sponsorship just to make it a little bit easier for you to sponsor projects. And one of the first projects that I worked on when I joined GitHub was this maintainer month sponsorship where we had half a million dollars and we distributed that across all of our dependencies,
16:01
just evenly across everyone who had sponsors turned on. So it was really fun seeing everyone get there like 500 bucks as part of maintainer month. And that's gonna be part of the actual product soon. So bulk sponsorships are coming out. So it'll be much easier for you to just upload a list of maintainers that you wanna give money to and then it'll spread it out.
16:22
And then just a little bit more about paying maintainers. The funding landscape has changed dramatically in this past year or so. There's far more money available in open source. So the Open Source Collective saw a 30% increase in payment to maintainers. And there's a lot more emphasis on securing the supply chain, especially after the Biden administration's announcement
16:41
with that executive order on improving the nation's cybersecurity. And then this is an NSF grant and the pathways to enable open source ecosystem. There's just so much more money going into open source. I only highlighted like two of them there. There's a lot. So it's great that money's there, but how do we actually set projects up
17:01
in a way that will give ongoing support to maintainers? And this is a really complicated question, especially if there's multiple maintainers on a project, like how do we do this equitably? Which maintainers get paid? I'm not gonna answer that here. Again, I'm far too jet-lagged for that, but we do have some models that I think we can follow and we can learn from
17:24
that seem to work for supporting certain types of open source projects. I am really excited for the GitHub Accelerator. I think they're gearing up for their first cohort right now. Applications closed at the end of last year. But talking to Nathie, she's really interested in just seeing these new models arise. But I'm gonna talk about just three models
17:42
that we have today. I grouped a few things. I don't know if you can tell, but I'm a really big fan of the rule of three, so I will tell you things in threes. But the first is tips and donations. So this can be going to an individual, or the donations can be going to a foundation. The second's getting hired at a company
18:00
to do open source. And this is when the project is not governed by that company, it's governed outside. But they're paying you to do open source. And then the third one is that the company actually does open source and they're governing it. And then you're part of helping that. So I'm gonna go through these three and talk about some examples, and some times when it works really well and maybe doesn't.
18:21
So the first one with the tips and donations, yeah, again, it can be to a foundation or an individual. This works really well for visible projects. Vue is an example that's gotten a lot of sponsorship and donations. But I've been used really good at that marketing. And Vue is a project that many developers use.
18:41
It's very top of the stack. It's not really hidden. So people make the cognitive decision to use Vue, which helps make them make a decision to sponsor Vue. The second is content creators. Caleb Poresdio has written a lot about how he's able to sustain a career just on GitHub sponsors donations. And a lot of that is he's creating content
19:02
around the open source that he's building. So it's more of that Twitch stream model where people are excited, and he's a really good marketer, I think. So it's great that people are able to work like that. I also don't think that an open source maintainer has to also be a marketer. There has to be a way that we can get money
19:21
to those people that don't naturally have Caleb's gift for marketing. And then the third is maintainers in lower cost of living areas. So I actually interviewed Covid Goyle. I'll go to the next slide. So here's a little clip. So I interviewed Covid Goyle and Carlos Becker. Covid maintains Caliber and Carlos maintains GoReleaser.
19:42
Yousaf Victor was also in this panel, but he didn't talk about this topic, so I didn't. He's there, but if you watch it, you can see him. But both of them agreed that the strength of the US dollar really helped. So Carlos is in Brazil, Covid's in India. And Covid was saying, like, by moving from the US to India,
20:01
he was actually able to sustain himself full time on the open source donations. He actually has a really cool story. He talked about how when he was in grad school, his parents would give him some pizza money. And then something happened with a credit card and it stopped working. So he was like, oh, what if I just turn on sponsorships? This was before sponsors existed. So he just turned on like a little PayPal donate button
20:22
on Caliber and he started getting sponsorships and people started donating. And then he was able to have that pizza money and they grew to be a little bit more than pizza money. And then when it came time, when he and his wife both finished grad school and they were thinking about what to do next, Covid was like, oh, maybe I can just do this full time because they were gonna move back to India
20:41
and he was able to. So I think that's a really cool story just how certain projects are able to survive off of donations. But I'll say it's a little tricky. All right, the second one is getting hired at a company to do free and open source software. So this is a great way for a company to have a direct line to the project
21:01
where they actually are paying for a maintainer to work on it. And it's great for the project to just have maintainers stably employed. So the example I put here was, this is Keely Hammond, she works at Slack and she's an Electron maintainer. And I like this read me project piece on her. So I encourage you to go read it. But she just talks about being an Electron maintainer
21:21
and like working at Slack and just how she's bringing in more of these non-code contributions. And we see this model happen a lot. I think Electron is the one that I'm highlighting here. But you do have to depend on that company to continually be sponsoring these folks. And the third one is that the company does free and open source software on their own.
21:43
So there's a few ways. This is a very sparse slide, I'm just realizing. So if it's part of their core business model, I think Next.js and Vercel is a great example of this, where Vercel sells the hosting services so that it's just really easy for you to deploy your Next.js apps. And then I also grouped consulting services
22:02
as part of this company does FOSS. I know some people consult individually. A lot of people set up a company to do the consulting. So companies will hire you for your expertise on that project. And then you can sustain yourself that way. So again from the Twitter thread, the Janus or Janus, I didn't learn how to pronounce that,
22:21
the WebRTC server, they're able to sustain themselves through this consulting business. And that works when you're, again when you're high enough on the stack that people will realize they're using you. All right, so yeah, just an overview of what we talked about.
22:40
These are the three models that I think work today, but I still think we need more models. I know talking to Nei3 with that GitHub accelerator, she likes to ask that question, where's the Etsy model for open source? Where are the people who just create and then are able to get paid for doing that?
23:01
It's hard with open source because software isn't a thing that you can just take. But I'm hoping that this accelerator will help us explore that question and maybe try to figure out a nice model for that. All right, and that third lens was the technical practices. Just make it easy to use and get started with your project technically. Again, this helps the maintainer burden.
23:21
Maintainers won't have to walk you through getting your environment set up and everything. But also, yeah, if the project is suddenly unmaintained, ideally someone can just pick it up and go. So a few things, best practices. The first three I actually took, I was consulting with the UNICEF Venture Fund.
23:42
And this is actually a requirement for people to graduate from their incubator. They need to have documentation for everything. They need to have greater than 80% code coverage for tests and have CI CD involved. And then the cloud developer environment, just making it easy for people to get started without having to figure out their local machine,
24:02
I think makes a big difference. Okay, so we're gonna go through each of these again. With documentation, I know I already quoted Kirk McKusick, but when I asked, I asked Deb, what did FreeBSD do really well early on that led to where it is today?
24:21
And Kirk's response, he gave me a huge list, but one of them was emphasize documentation from the start. So making sure you're documenting things, really important. The next piece for testing in CI CD, again, it's just so much easier for people to come in and contribute to your code if there are tests. They can realize when something's broken.
24:42
It's easier for you as a maintainer to know when you can merge something in or when you shouldn't. And then this is just a little GIF showing how nice it is to have this all integrated using GitHub Actions, where everything's just all there together with your code. And then the last one, that cloud developer environment. I think Codespaces has been really nice for this.
25:03
And you can just use the green button. We missed it in the animation. But then it launches this cloud IDE, and then you're just writing the code right away. And now that Codespaces is offering 60 hours free every month for each individual, this is a great way for people to start coming into your project.
25:20
And I was gonna bring some of these business cards so you can talk to Craig. So Craig, he loves open source. Again, I am jet-lagged, and I forgot these business cards at this event venue for later today. But you can take a picture of this if you wanna talk to Craig. That's the link. And he's more than willing to help you
25:41
get Codespaces set up so that individuals can just come to your project and get started quickly. All right, so just an overview. Supporting maintainers through these three lenses. From the community side, there's succession planning. From the financial side, paying them. From the technical side, making it really easy to use and get started.
26:01
So if you are interested in any of these conversations, at Sustain, I am one of the Sustain OSS organizers, we do have a conversation every other Friday where we talk about topics like this. So a lot of the information I got was from those conversations. So you can go to Sustain's discourse over there. But I also, I run GitHub's open source
26:22
maintainer program, so if you wanna talk about this with other maintainers, we do have a private maintainer community that we're just relaunching some new programming. So if you go there, you can request an invitation to the community and get involved. So huge thanks to everyone, I really appreciate being here.
26:40
You can find me, I'm abbycabs on GitHub and Twitter, I'm also on Mastodon, and yeah, thank you so much for having me. I'll now take questions. Thank you, Abigail. If you have questions for Abigail,
27:02
just raise up your hands so I can get the mic to work for you. Thank you. As I was preparing, I was like, oh, this'll be easier if I have a long question period. But now I'm realizing I'm really tired, so please be nice to me with your questions. Hi. Hi. Thanks for the talk.
27:21
So you were talking about ways to become a maintainer. There is another way that you don't talk about, which is working at a company and then convincing your CEO to open source your, for example, your core business. And so if I was CEO of a company,
27:45
how would you convince me to switch to open source? Oh, all right, yeah, so you're saying that the other way to survive as open source project is to convince your company to run an open source business. Indeed. Yeah, so I think there's a lot of advantages
28:01
to working open. I've talked about them before, I don't have them all written here. But big ones is like better products when you have a diverse community contributing, especially if your company isn't representing the diversity of the audience that you're working for or serving. Having that, that's good. Reduce production costs, if you're sharing it across a big group.
28:23
And also reduce like support costs. Often if your company is, if your community is like answering each other's support questions, that's another way for reducing costs. And what's the other one? Oh, also if you wanna be like a defacto standard or if you want to like be a platform
28:41
by giving something away for free, more people adopt it, and then you can become that platform. So we see that with like Android. So those are a few of the reasonings I'd give off the top of my head too, but it would depend a lot on like what company I'm talking to and like what their priorities are. And it's tricky to find a good business model
29:02
that works with open source, but when you do, it's beautiful. Thanks a lot. What would you answer to someone saying, I'm not going to open source my code because I fear that people will be stealing it. Sorry, could you repeat?
29:20
You don't wanna open source your code because? People would be stealing it and copying basically your product. Oh, cause you don't want it to be copied? Yeah, exactly. You don't want to be stolen? Yeah, that is a tricky one. You could license it less permissively. So that if someone copies it, they'll have to license it the same way.
29:42
You're answering really tough, you're asking tough questions. I asked for easy ones. But no, this is important. I say, yeah, you have to structure your business in a way where it doesn't matter if someone takes your code. So like the example I gave with Next.js and Vercel.
30:00
Like Next.js anyone can take that, anyone can run it and do it theirselves, but they're selling the server time and that computing time. So it doesn't matter to them if it gets copied. But I don't know, copying stuff, that's more innovation. It's better for the world often. So thank you.
30:20
Thanks for that. Any easier questions? There's a couple, you're next. Hi, do you think GitHub itself will be open source in future? Do I think GitHub itself will be open source
30:41
in the future? I know that, is this recorded? Yes, it is. Yeah, I know, I'm sure it's fine if I say this. I know with Thomas Domke, he's the CEO of GitHub, he said in the past like, what's stopping us if we open source GitHub right now, we just wouldn't be able to handle all the contributions and all the community coming in.
31:01
I think that's one of the big reasons why they're not doing it. I wouldn't rule it out, maybe eventually. But yeah, our business model doesn't really, yeah, the code itself, it's not there. It's more the hosting and like the CI CD code spaces, things like that where they're generating the revenue. Oh, and like copilot now, yeah.
31:20
Okay, thank you. Thanks. Hard questions again. I hope it's okay, I'm sure no one will report me. Oh, this person was next. Okay, after that. Okay, hi. Thanks for the talk. What would be your approach of sustaining a conference app like the Fostum one, which is only available
31:43
for a weekend and then people do other things over the year and yeah, like how do you go about this? How would I go about sustaining a conference like Fostum? I think Fostum has done a really good job sustaining itself, it's grown so much, 8,000 people, it's just amazing to see the community
32:03
come together and people get really excited about it. I don't know if I'd do anything that much differently. I think if, from what you said with how it happens only once a year, are you thinking about like getting, keeping people engaged through the year? Then I might think start doing like more online things
32:21
in between as touch points or having more local things so people can have like their Fostum in their city, the local meetups, just to keep people engaged over time. But I don't know, Fostum seems to be going really strong unless there's something I don't know.
32:45
Thank you so much for a great talk. I was a little bit surprised when you mentioned in the discussion about how to sustain a project financially that there was a case example of a person that moved to India and was able to sustain itself
33:02
by working on Fostum, which is fantastic. But you used the word surviving. Which seemed a little, yeah, it just surprised me because I think everybody can agree that people that maintain full-time Fost projects, which is the infrastructure of a lot of the world,
33:21
of IT really, should be, well we all hope that one day we'll be able to pay these people a reasonable salary for their efforts and not just surviving. Now with that said, like you say, it's tricky to find business models that can financially sustain these projects. And GitHub is a company that has done so much
33:42
for open source and plays such an important role. And it also has enabled a lot of funding to start to arrive to maintainers. Now, do you think that GitHub is now done finding new ways to find new models to sustain developers? Or is the conversation with GitHub still open
34:01
where we could provide further feedback and provide novel ideas to tackle the business model of how to tackle the problem? Is GitHub open to new ideas? Yes, GitHub is open to new ideas. Actually, join that private maintainers group. I think that would be a really interesting avenue to have those kinds of conversations.
34:21
And I think a lot of those, one of the big reasons why the GitHub Accelerator was set up was to help us try to find these models and better ways to pay people. Because like you said, I probably shouldn't have used the word surviving. But it's nice that COVID was able to do that. But like that shouldn't have to be the norm. Like there's no way we could make all the open source maintainers live in India.
34:42
I'm sure it's nice there. But yeah, there has to be a better way that we can actually sustain these people. So I think there's still a missing link. So I think you've identified there's still this missing piece. And I don't really know the answer. There are people having these conversations and we're definitely open to hearing your thoughts. Thank you very much.
35:02
I have a question. Oh, yeah. Yeah, you did talk about, I'll just have, my question will be a follow up, like similar to what he just said about the financial maintenance of open source practitioners. So like, do you guys have a mechanism? How do you determine, how do you reward somebody that is doing,
35:21
like that is maintaining an open source platform? Like how do you determine how much he should be rewarded? Sorry, what was the question? Like how do you determine how much should someone be rewarded? Oh, how to determine how much someone is worth? Yeah, how he's rewarded, like for his involvement in an open source project?
35:41
Yeah, yeah. Because like, for example, you might think like, you have two people from different locations, all contributing the same amount of hours, but then end up getting, receiving different paycheck at the end of the month. Yeah, yeah, no. And I think just the question for everyone, how do you, like if you have multiple maintainers,
36:01
how do you know how much money should go to each person? And I think that's a really big question today. And I wasn't prepared to answer that in this talk. But I think, no, I've definitely heard of some projects where like one person is maybe in India, the other person's in North America, and then if they pay them evenly, the cost of living is so different.
36:20
It just causes issues. Or like if one person started the project and they're still getting paid but they're not an active maintainer anymore, like what happens there? There's a lot of open questions like that. And I think that really depends on the project. It really depends on the project governance and dynamic. It's really, that's a human problem, yeah. But I agree, that is a big problem today.
36:40
And it's a big problem for open source. How much time do we have? Okay. So this might be the last question, I think, yeah. I'll come here. Hi, I'm a member of several organizations. And we are dealing with, in all of them, we are dealing with the same problem.
37:00
We have new members coming in every year, and there is nobody to give them orders, basically. They would be very happy to help, but nobody tells them how. How can we get these people who are basically acting as middle managers for these organizations? Oh man, yeah. So if you're in an organization, you have new people coming in, but then no one is telling them what to do or how to help.
37:21
I think that's where establishing mentors is really important and just finding people in your community already that's willing to onboard others. So that's why I really like programs like GSOC, Google Summer of Code, because it's good for bringing in the newcomers, but it's also good at finding mentors in the community.
37:42
And this might be the first time they're stepping up in leadership. So that's a nice incentive, because they get a little bit of a kickback from Google also for mentoring. And they get the Mentor Summit and things like that. So yeah, I would think about it that way. What can you do to encourage mentors? It might be making a role for it.
38:00
It might be giving them special titles and giving them some fancy thing. I don't know, a special dinner. Depends on what your community likes. Thank you. Cool. I think that's all for time. I'm around, so you can come chat with me. I did bring stickers and buttons, so you're welcome to come up here and get some. I have slightly less than I had for my talk this morning,
38:23
where I accidentally gave far too much away. But this is how much is here. So thanks, everyone. It was great chatting with you.