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 a little bit longer.
Okay, 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 about this talk, 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.
You'll get to hear some insights from all 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 FOSSTEM, 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, 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 I'm talking about,
but yeah, so I do want to share a little bit about myself, my background, and why I care
so much about FOSSTEM, and then we'll go into sustaining FOSSTEM, and spoiler alert, I do
think maintainers are a huge part of this, and then from there we'll look at those three
lenses 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 brothers there.
There are pictures of me and just my grandma, but I really liked this one, even though my
brother is stealing the show, I don't know, it's fun, and I like how big my eyes look
with my glasses, 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, 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, that's when I got really into open science, especially using open source
and open data to help us find the best innovations, because 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, and now at GitHub, I'm supporting the maintainers in this new world.
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 going to 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, 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 like 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 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.
So I really like this quote from Toby Longel.
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, but I do think
this is an important framing, and I think it's important to be thinking about maintainers.
I know Nadia Agbaal 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, 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, and it's the same for open source.
Maintainers are really important for these communities.
So if we look at supporting maintainers, we're going to look at these three lenses, and you
don't have to address your project with all three of those lenses at once, and that's
why I made an event diagram, but we're going to look at these three.
So the first is on the community lens with succession planning.
This one might not be as intuitive, so I'm going to 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 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 just looking at the overlap pieces, say you have the pink and the blue, you have
the financial piece and the technical piece, but you don't have that community piece.
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 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, 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
up by Open Tech Strategies in Mozilla, they have an archetype called single maintainer
houseplant.
So if you're just like a maintainer by yourself, 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.
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, 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, it's a lot of things to map.
All right, so the first one we're going to 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 also you don't need to have this 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, and 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 about succession planning as we're seeing this natural churn
of people go through the ecosystem.
And I did have a conversation after that, I am really glad I tweeted about this talk.
I should have said 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, 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 McCusick, he's one of the original core
maintainers for FreeBSD, but he says, a successful project has to be able to change the leadership,
otherwise leadership becomes dead wood, which leaves the project rudderless.
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.
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 long term.
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, 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 want to 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.
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, 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 is needed there.
And then the third one there is willing to learn from whoever is mentoring them.
So you might notice I didn't put skills needed, I know some projects will add skills 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 will 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.
Yes, I think that's what I had for this side.
All right, so I'm going to 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.
So the mission for this program was really about strengthening open projects and communities
around the world.
So you'd ask some questions around what does openness mean to you, or why do you want to
work open to see if they were mission aligned, or did they just come to get some training?
We asked questions around what do you hope to learn from a mentor, how do you learn best?
And then also made sure that they understood, 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, they may not have been willing to give that 10 hours.
But setting them up front lifted that bar.
So we got more people that were really excited about the mission and wanted to help.
Yeah.
Oh, yeah, so then doing that really helped with some incredibly high retention rates.
So especially at the beginning, 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, 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 C.C. Chanzakaburg Institute.
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 going to make one more slide with all the people doing this, but I was very
tired today when I was making slides, 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 going
to 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, 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, or like corporate open source.
So if, especially if there's open source happening 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 REST project, so that was at Mozilla for a very long time, but they
spent out now they're at the REST foundation, or partner with other companies for shared
governance.
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 have this shared governance
over this shared infrastructure that they all use.
Okay.
Their circle was the pink one, PayMaintainers, yay.
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, like ecosystem support, but I am so glad that there's companies
like this and products like this, like GitHub sponsors, like Thanks Dev, they're here, yay.
StackAid, 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 Dorfin this morning when I was still making my slides.
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.
So if you go there, you'll see the projects that your account depends on, and which ones
are eligible for sponsorship 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 to across
all of our dependencies, just evenly across everyone who had sponsors turned on.
So it's really fun seeing everyone get their 500 bucks as part of maintainer month.
And that's going to 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 want to give money to, and then it will spread it out.
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 with that executive order on improving the nation's cyber security.
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 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 going to 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 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 Nathan, she's really interested in just seeing these new models arise.
But I'm going to talk about just three models 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 is getting hired at a company 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 going to go through these three and talk about some examples, and sometimes when
it works really well and maybe doesn't.
So the first one with the tips and donations, again, it can be to a foundation or an individual.
This works really well for visible projects.
View is an example that's gotten a lot of sponsorship and donations, but I haven't used
really good at that marketing, and view is a project that many developers use.
It's very top of the stack.
It's not really hidden.
So people make a cognitive decision to use view, which helps make a decision to sponsor
view.
The second is content creators, Caleb 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
around the open source that he's building.
So it's more of a Twitch stream model where people are excited to see, 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 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 a go-releaser.
Yusuf Victor was also in this panel, but he didn't talk about this topic, so 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, by moving from the US to India, 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,
well, what if I just turn on sponsorships, this is before sponsors existed.
So he just turned on like a little PayPal donate button on caliber, and he started getting
sponsorships, and people started donating.
And then he was able to have that pizza money, 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 going to move back to India.
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, 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 Keeley 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 and 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.
So if 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 as part of this company does FOS.
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,
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 to overview of what we talked about, these are the three models
that I think work today.
But I still think we need more models.
I know talking to Nathan with that GitHub accelerator, she likes to ask that question,
where is the Etsy model for open source?
Where are the people who just create and then are able to get paid for doing that?
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.
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, the best practices.
The first three I actually took, I was consulting with the UNICEF venture fund, 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 the cloud developer environment, just making it easy for people to get started without
having to figure out their local machine, I think, makes a big difference.
Okay, so we're going to go through each of these again.
With documentation, I know I already coded Kirk McCusick, but when I asked Deb, like,
what did FreeBSD do really well early on that led to where it is today?
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 is broken.
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 gift showing how nice it is to have this all integrated
using GitHub actions where everything is 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.
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 right in 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.
And I was going to 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 want to talk to Craig.
That's the link.
And he's more than willing to help you 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, for
the community side, their succession planning, from the financial side, paying them, from
the technical side, making it really easy to use and get started.
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 run GitHub's open source maintainer program, so if you want to talk about this
with other maintainers, we do have a private maintainer community that we are 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.
You can find me, I'm AbbeyCabs 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.
We have questions for Abigail.
Just raise up your hands so I can get the mic over to you.
Thank you.
As I was preparing, I was like, oh, this will 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.
Thanks for the talk.
So you are 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, 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 there's a lot of advantages 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.
And also reduce support costs.
And if your community is answering each other support questions, that's another way for
reducing costs.
And what's the other one?
Also, if you want to be a de facto standard or if you want to be a platform by giving
something away for free, more people will adopt it and then you can become that platform.
So we see that with Android.
So those are a few of the reasons I'd give off the top of my head, too, but it would
depend a lot on what company I'm talking to and what their priorities are.
And it's tricky to find a good business model 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, can you repeat?
You don't want to open source your code because...
People would be stealing it and copying basically your product.
Oh, because you don't want to be copied?
Yeah, exactly.
You don't want to be stolen?
Yeah, that is a tricky one.
You could license it less permissively, instead of someone copies it, they'll have to license
it the same way.
You're answering really...
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, like Next.js, anyone can take that,
anyone can run it and do it themselves, 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.
Thanks a lot.
Any easier questions?
There's a couple.
You're next.
Hi.
Do you think GitHub itself will be open source in the future?
Do I think GitHub itself will be open source 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.
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 the CI CD code spaces, things like that, where they're generating
the revenue.
Oh, and co-pilot now, yeah.
Okay.
Thank you.
Thanks.
Hard questions again.
I hope it's okay.
I said that.
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 FOSSTEM one, which
is only available 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 FOSSTEM?
I think FOSSTEM has done a really good job sustaining itself.
It's grown so much, 8,000 people.
It's just amazing to see the community come together and people get really excited about
it.
I don't know if I 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 more online things in between as touch points or having more local things so people
can have like their FOSSTEM in their city, the local meetups, just to keep people engaged
over time.
But I don't know, FOSSTEM seems to be going really strong unless there's something I don't
know.
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 the case example of a person that moved to India and was able
to sustain itself by working on FOSST, 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 FOSST projects, which is
the infrastructure of a lot of the world, 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 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 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 really interesting avenue to have those kinds of conversations.
And I think one of the big reasons why the GitHub Accelerator was set up was to help
us try to find these models in 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 that shouldn't have to be the norm.
There's no way we could make all the open source maintainers live in India.
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.
I have a question.
Oh, yeah?
Yeah, you did talk about, I'll just have, my question would 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, 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.
Yeah, 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 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,
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.
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, human problem.
Yeah.
But I agree.
That is a big problem today.
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.
Yeah.
Hi.
I'm a member of several organizations.
And we are dealing with, in all of them, we are dealing with the same problem.
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.
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.
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.
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.
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.
Yep.
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, where I accidentally gave far
too much away.
But this is how much is here.
So thanks, everyone.
It was great chatting with you.
Thank you.