The making of GitHub Sponsors

Devon, you came to GitHub specifically to tackle the sustainability, what became GitHub Sponsors. We'd love to hear the story of what brought you to GitHub and how that all went down.

The real answer is housing policy, which sounds like a little bit of a non sequitur… But I've been a software engineer for a while, since I graduated college, but in my free time I was doing a lot of housing policy work in San Francisco, trying to get us to build more. And I will hold off on ranting about that now, but the long story short is I met Nat Friedman through what's called IMBY activism, which is trying to get San Francisco to build more, and loosen certain building restrictions… And I got to know the guy through that context. We actually didn't really talk about software almost at all for almost the first year that we knew each other. I didn't really know that he had a super-technical open source background, or anything like that.

I really respected him and all the work that he did, and I know he had great values… And when I saw the news last June (I guess) that Microsoft had acquired GitHub, I was just like "Oh, that's interesting. Hm…" And then, right under the headline, I saw that Nat would be the CEO. It said "Nat Friedman will be the CEO of GitHub", and I said "Oh… That's interesting."

Hm, the plot thickens…

Yeah. So I reached out to him, we started talking, and I had all these ideas about what GitHub should do; I sent him an email, being like "GitHub should help open source maintainers." They should do all these things for communities, they should build better tools… And he sort of boomeranged it back to me and was like "Yeah, I agree. How about you come join us? How about you come do it?" And because I had had that experience working in some non-profits with him, I knew that he was both a really effective person, but also a really good person, and I just jumped at the opportunity to work with him.

When I sent the email with all of my ideas I didn't really expect him to have that response; I was not looking for a job. But as soon as he framed it that way, I was like "Oh, that's a great idea. I have to take this opportunity, working one of my favorite people on one of my favorite problems, and on one of my favorite products."

Awesome. So you arrive at GitHub with this huge opportunity, and a chance to make a big impact. Now, we all know, we're looking back at what GitHub Sponsors is now, but when you arrived there, it was probably just a bunch of ideas, and there were so many different routes to go…

[04:09] And opinions.

Yeah, exactly.

Oh, yeah.

I would be kind of scared to tackle such a problem, because things can go wrong… Why is this a problem that you were specifically interested in, and what part of your background – I mean, I know you mentioned your activism in your local government, but what else makes sustainability and maintainers something you're like "I would quit what I'm currently doing and go to work on this", and then what kind of ideas did you have about it?

This is gonna get a little abstract for a moment, but the kinds of problems I'm really interested in are what I call coordination problems… If you remember from your ECON101 years, there's prisoner's dilemmas, and tragedies of the commons, and those sorts of things… And the thing that they all have in common is that there's a lot of individuals who are operating on their own best interests and trying to do the right thing, but the result is that they all sort of fail.

The classic example of this is climate change, where no one wants the planet to melt and to burn to a crisp, but everyone individually benefits a little bit more from taking that longer shower, or driving to work instead of biking… So the result is that everybody ends up worse off if they're not able to coordinate for the greater good there.

So housing policy has this shape too, where nobody really wants buildings to live in their backyard, they don't want a big skyscraper, but at the same time people do want housing to be affordable across the city, they just don't want it to be in their backyard. So that's sort of a coordination problem.

Bringing this to open source, we all want amazing open source software, we all want this infrastructure that we can build on top of, but it's sort of hard for any one of us to pay for it. It's hard to justify why you are the one person who shells out ten bucks a month to support open source that everyone else is just using for free. Wikipedia is also an instance of this, where millions and millions of people use it every single day - probably even more than that, actually, I don't know; tons of people use Wikipedia, and everyone benefits from it… If it disappeared, the world would definitely be a worse place; we would have less access to information. But the vast majority of Wikipedia users don't pay for it.

That shape of problem really frustrates me and makes me sad, and I thought that GitHub was really the only place that could significantly change that equation for open source… Because it's the home where all open source developers live, and GitHub ultimately is built on top of open source, and depends on these communities… So the company has a really strong motivation, I think, to try to solve this problem for everybody.

Can you peel back the layers to how you think about a problem like this? Do you think about it from the – I heard this term recently, the three-year plan/problem… Where instead of thinking about what you're gonna do today as "I've gotta succeed tomorrow", it's more like "I've gotta succeed three years from now." How do you peel back the layers of this very deep, very hard problem, and solve it iteratively over time? How do you approach it?

Iteratively is absolutely the way we have to approach it. The paradigm that we've been building open source in for a long time has had some great strengths, and it also has some clear weaknesses in my view, where we aren't funding the work that needs to happen… And right now we're at point A, and we wanna go to point B, but if we immediately jump to point B, that could actually shake up the paradigm that's actually working pretty well, and you end up sort of worse in both situations.

So we're working iteratively to put small changes out at a time, make sure they're actually working, testing them, and then moving that edge a little bit further out towards point B. So concretely, what this means is in May we launched the beta of GitHub Sponsors… And we could have, in theory, just said "Everyone can join at any point", but because this was such a new thing for GitHub, we wanted to take it slowly, make sure we had feedback before we rolled it out across the entire community. Because frankly, this stuff is really serious, so we could have really messed it up.

[08:21] Yeah.

So it's now out of beta for 30 countries; we've rolled it out now to a vast majority of countries. That was just a few weeks ago that that happened. And the thing that gave us more confidence was that we were getting a lot of positive feedback from users. We did make some adjustments to make sure that things worked better for people before rolling it out… And we plan to continue taking what's really an incremental approach, where we do one small thing at a time, as opposed to totally changing it.

And one final thing I'll say about that is what we've done so far - I'm really proud of the work of the whole team, but we have a lot more to do. If we stop here where we are, then I don't think we've actually solved the funding problem… But it is a key foundational building block, and we're gonna keep putting more blocks on top of that.

Yeah, congrats on that announcement, too. I was very impressed with the video you put out, too. I think that your focus on a smaller group played out well in that video, where there's even several faces and names we've had on this show, and who collaborate with us here at Changelog, from Feross Aboukhadijeh, to - what's his name from cURL? Gosh, his name is blanking me right now.

Daniel.

Daniel Stenberg. Yeah, thank you… And many others. I was like "That's really awesome." I love that video, the way it captures sort of this community feel… But these are people that you sort of have seen struggling over the years on how to make their individual efforts into open source possible through funding.

Yeah… I've gotta say, I'm not really a crier, but I teared up a little bit when I saw the first cut… Because these people are my heroes too, right? So it was so cool to see that something that I'm working on building was also useful to them. I mean, cURL, for example - I've used that since I've first started programming, like all of us, right? Anyone who's done web programming has interacted with cURL, whether they know it or not…

Yeah.

So first of all, just seeing Daniel's face the first time, when I first met him, I was like "Wow! This is a real person. It's not just like a god who handed this down from the heavens." And then seeing the IMBY part of the video was especially cool.

Yeah, meeting Daniel for me was awesome as well. I very much was in the place where tools that pre-exist my experience to programming in the web, and all that - you just kind of assume they've always existed… You know, you don't think about who wrote AWK, for instance, and what's that story. And cURL was one of those staples of my toolkit that you just didn't even think about if there's a person behind this thing; you just think about the thing.

I remember there was actually a tweet one point where someone realized that Daniel Stenberg – like, "I realized that the guy who wrote cURL is still alive!" [laughter] And Daniel retweeted, he's like "Yes, I'm still here." [laughter] And it is one of those things… So as a person who – I concern myself a lot with execution… How do you actually get a thing done? You come to GitHub, you settled in, and you are tasked with this thing. Now, we know iteration has been part of the recipe, but what are the first things that you do? Do you research? What's step one down the path to get you to GitHub Sponsors?

Okay, so actually I didn't execute for a little while. I made a really strong point of making sure that I had space to research the problem and talk to a lot of users. And actually, initially my job title was not product manager, it was researcher, when I first joined. And I basically traveled the world and spoke to a bunch of different developers; I went from Singapore, to Paris, to London, to New York…

Very cool.

[11:53] All over the place. It was really awesome. There's GitHub users everywhere… And the hypothesis that I went with was something that I got from Nadia Eghbal's Roads and Bridges report that she published in 2016, where basically she pointed out this whole coordination problem that we've been talking about. That's the report that originally got me interested in the problem… But that was about the extent to which I had really concrete ideas about what GitHub should do. I was like "GitHub should do something here, but I don't know what it is."

So I had calls or coffee or lunch with hundreds of open source developers, and sort of asked them "What are the key missing pieces?" And I think that was actually very key to our team being able to be effective within GitHub, where I came in – when I did say "Okay, I have some ideas about what we should do with the product, and how github.com itself should change", I had a lot of credibility within the company as someone who had spoken to maybe more open source developers than maybe almost anyone who was still there, just because I had spent the last four months just doing that. So there was just tons of user interview evidence that people want this, people are just waiting for GitHub to do it.

For me, it felt like really what happened was there were all these predecessors in front of me, like Nadia, like Mike McQuaid at GitHub… A lot of people who planted all of these seeds and started growing these fruit trees, and I just kind of came at the right time and plucked all that fruit right when it was ready to be plucked. So it was really actually low-hanging fruit by the time I got there, I think.

There's benefits to arriving when it's harvest time…

That's right.

Yes, exactly. It was time, it was ready. And I don't think it was always ready; I don't think that this would have happened smoothly three or four years ago. Open source sustainability, open source funding were still new topics on people's mind, and I think people hadn't formulated the question quite right, both at GitHub and outside… So coming in and being one of the people who saw all of these pieces, and then – I just felt like I was the one that put the pieces together, ultimately.

I mean, even when you rewind back three years, we're still talking about the early days of it being discussed. You mentioned Nadia - we worked with her and Mikeal Rogers on a series… I guess it's a podcast, but it's more of a podcast series called Request for Commits, that spanned 20 episodes. The final episode was its finale, sort of lookback retrospective of where it went, and what it had uncovered, and where the conversations should continue… But you're right. I mean, three years ago I don't think that it would have been – I think the topic needed to mature. There's a lot of things that have propped up even around that time, since Open Collective, or CodeFund, and a couple others that are out there, to enable this… And it just wasn't mature yet, or it just wasn't critical mass time. Now it's time to enable that.

You mentioned giving people an effective way to give, and what do you think the core goal, or even today's iteration's core goal is for GitHub Sponsors? Is it to just enable en-masse anybody to give, or is it aimed at a certain type of individual or organization to give? How does in work?

I think the key thing that GitHub Sponsors as it stands right now adds is basically distribution. At the moment –

You mean awareness around that, or how do you mean distribution?

Before GitHub Sponsors existed, if you wanted to donate to or sponsor a project, you had to go outside of your usual workflow and go find them. This meant that it really benefitted people with really big Twitter followings, or someone who had a newsletter or a podcast already… And there's a lot of amazing people for whom that's true, but for most open source developers - they don't have that kind of distribution. So for us it was key to just be putting this in the repository, or on your readme, on your profile page from the get-go.

[16:09] Now there's a lot of times where I'll use an open source project, and I'd never heard of the developer before, but I really depend on it. So then I click that heart button and I sponsor them. For example, there's this open source note-taking tool I use called Joplin. I really like it, and I've started contributing more to it recently too actually, and I had never heard of the maintainer; I think it's pronounced Laurent, but it's French, and I'm bad with pronouncing French words. But Laurent - I'd never come across his Twitter or anything like that before, but I use this tool all the time… So it was just so natural; the last time I looked at documentation I was like "Oh, I guess I should sponsor this guy."

So it definitely brings it right top-level, right there next to the star, or the fork button, so primo real estate for knowing that this is a person who you can sponsor, and I agree that probably of the winds that GitHub brings, that's the major one in terms of just awareness.

Now, as Adam mentioned, there are other groups, firms, companies who are trying to address the sustainability problem in different ways. Do you think GitHub Sponsors is a threat to those efforts, or additive?

I think it's very additive. I think that we have really furthered the conversation about sustainability in a way that honestly I think GitHub had a responsibility to do, and hadn't done for a while… And then also only GitHub could do. So I think it's very additive. We've also been really working with those partners as much as possible to bring them into the loop.

One of the key features that we launched at the same time as GitHub Sponsors is the Funding button at the top of the repo, which - you can include sponsors, but if you have an Open Collective, if you have a Patreon, if you have a Ko-Fi, you can fund people through that.

It was very important for us to include that in the launch, so that it wasn't saying "GitHub is just gonna solve this problem now." No, no, no. We want a diversity of options.

The other thing I'd say is just last week - wow, it was only a week ago. It feels like a lifetime… But just last week we launched GitHub Sponsors for projects. The first iteration for individuals, and now you can fund your entire team through GitHub Sponsors. We partnered with groups like Open Collective and Community Bridge from the Linux Foundation to make it really easy to onboard groups of people.

The way we see it - we sort of help with the distribution and visibility side of the problem, and we created a portal straight into the accounting and transparency tools that's something like Open Collective would offer. And frankly, it wouldn't really work without them, because you need a bank account to sign up as a group, and GitHub doesn't support that. Open Collective has great tools to support that, and so we've been really happy that the whole ecosystem is working together to solve this problem.

One of the things you said when you announced that project support at - was it at Universe last week, in the announcement post? I'm not sure you wrote this, or if it was somebody else… But they said "We're keeping in mind that an influx of funds can raise new, unanticipated challenges for a team", which is something that many maintainers have found over time… It's like, you trade in one problem for a new problem, which is almost - I wouldn't say it's the worst problem, but maybe it's a less straightforward solution. When you don't have any money, the straightforward solution is "Get some money."

Now, how you do that, of course, is challenging, but once you have some money, especially in a group - it's not a solo person, it's a team - you do have challenges that come up. So you said "We're taking extra care in our early stages to encourage transparency and share insights with contributors on how funding decisions are made." So I'm just curious how you're going about encouraging that transparency, and what you think the fruit of that will be, and maybe the Open Collective integration is a part of that.

[20:13] Yeah… So Open Collective has really good tools for this, so I've been really excited to see people taking that up a lot more, and showing where the funds are spent… One of the key things we're doing right now – well, there's two key things. One is when an organization signs up for the waitlist, we have a pretty extensive application form. When I think "pretty extensive" I think having really good answers to all that is a small project in and of itself; it's not something you just casually tie up. And the reason we put that there is sort of a theoretical reason.

One of the models that I created during my research was this recognition that because it is so easy to start a new open source project, which is again, one of the biggest strengths of it; anyone can just go and create a repo and start sharing their code… But it often means that people haven't put much thought into how to govern the project, who is the owner of the project, which stakeholders get to be part of the decision?

To sort of go back to the city planning metaphor… If you were creating a physical infrastructure project, you would have to answer all of those questions before you were even allowed to get started. If I want to build a new freeway, I don't get to just go start building a new freeway whenever I want. I have to get permits from the city, I have to raise funding, I have to create a charter, I have to create a business plan… And then maybe I get to start building my highway. Open source doesn't have that, which is a great blessing, but it means that when these projects do get funding, they often haven't really thought about those implications. So with the waitlist questions, we're sort of prompting those questions to be like "Hey, do you have answers to these? If you haven't, maybe you should consider them before you start accepting funding as a group."

One thing I'm personally doing is I'm really through all of those applications and giving feedback to the organization, saying "Hey, I think there's some gaps here that you didn't answer" or "I could see how this particular thing that you explained is one of your policies could create some problems…" I'm not using this as a strict filter; if they stand by what they wanna do, then that's fine… But it just creates sort of an outside counsel of sorts for me.

And then the second thing we're doing is just by starting it as a beta, we again are letting out rope really slowly, because these are really big changes in the open source ecosystem, and we don't want to mess things up. So we're starting small, we're learning from it. While I am serving as an advisor for as many of these projects as they want, I also don't know all the answers either, so it's sort of like learning from experience and seeing what seems to work for people is just crucial for us.

It kind of reminds me of marriage counseling, Jerod… Prior to getting married, one of the cool things and useful things to do is to have some counseling, because you kind of get on the same page about what you intend for your marriage… In this case it's more like founding counseling. "How might it be best to get funding? How might it be best to organize this repo/project that has matured over time, or is still immature, and has some areas to refine itself, and be better positioned to take on funding?"

[23:46] That's a great metaphor. I really like that a lot. And even if I don't end up going in and actually giving advice, just having the team write down what their goals are with the money and how they plan to share it I think is just a great exercise for really any team to do at any point. But we want to encourage them to do that especially at this point, if they haven't done so already.

Yeah, that's really wise. I mean, how to spend money is very personal in some cases, and then when you start to organize people that are - as you'd mentioned before, going to Singapore and to New York and to other places - in a diversity of geolocation… That means monetary, that means currency, and potentially maybe even cultural changes that may impact the way you feel about using money towards your project.

Absolutely, yeah.

So there are an endless number of things that GitHub could do. You said you came there because GitHub is the best positioned organization to solve (or at least help solve) this particular problem. We tend to agree with you, that's why everybody was like "Oh, GitHub's finally doing something", because there's kind of been calls from the developer community for a long time… Like "GitHub, do something." So that explains why you're there, Devon, because you liked that problem, the coordination, and the challenge, and you saw the value… I don't know if you can speak for GitHub the corporation, or the for-profit entity, but with all these endless opportunities to chase down, GitHub is very well positioned not just for GitHub Sponsors, but for lots of things… So why do you think this one's important?

I think you mentioned off-hand that it had kind of been too long, in your opinion, that it hasn't been addressed…? What's changed – was it Nat Friedman, was it Microsoft, was it just the timing? From your perspective of course; you don't have to speak for them, but… Why this problem, and why now?

I'll start with why this problem. I think GitHub would be nothing without open source. Open source is what makes the community strong and valuable, and it's the reason why people go to GitHub. It's frankly the thing that makes GitHub not a commodity; the community of developers is something that is irreplaceable, so GitHub without them would basically just be a place to store your code, right? And I think an analogy that's useful here - it has limits, this analogy, but I think it's useful in this context… You can think of open source maintainers as kind of like Twitch streamers or YouTube creators, where if you look at the ratio of the overall user base to the number of people making content on the site, it's this tiny, tiny fraction of users who are actually open source maintainers or developers. Same with Twitch streamers, same with YouTube creators.

I think all of these platforms, GitHub included - it's really in all of our best interest to really focus on these people who are creating the value for everybody else… And it's really a high-leverage opportunity, because they're such a small group. It's actually feasible for me to maybe know almost all of the names of the maintainers on GitHub. I actually don't know exactly what the number is, but I could in theory know a little bit about every single one of them, whereas there's no way that's gonna happen across all 40 million users.

And do you think it's like 1%? Do you think it's less than 1%, if you had to guess?

Oh, I think it's less than 1%.

When you say "these maintainers", what do you mean by that? Like big project maintainers, or like regularly maintaining, or…?

I would say maintainers being like the lead on a given project, that is actually used by someone who is not on the project.

Gotcha.

That's still sort of a loose definition, but that's the one that I roughly work with. And I think these are just the most valuable people on the platform, again, both for GitHub and for the whole community. There's just amazing alignment there, and it's a place where we can have a lot of impact on the quality of the overall community.

[27:52] As for timing, I think there's two answers to the question. One is that I think it may have been too early any time sooner. Like we were talking about before, three years ago this was still a pretty new topic on people's minds… Or at least the rendition of the conversation that we're having now.

I think the other piece was that while there had been a lot of conversation at GitHub for a really long time, and a lot of really thoughtful people had thought about it, no one had been the person to own it and to say "We're gonna actually solve this now" and say "You know what, we feel like we actually have enough information to make a good step forward." Because this is really high stakes. GitHub can completely change the way open source works here for the worse, if we're not careful… So I think people were being very cautious. But then it got to the point where enough expertise had built up that the company felt "You know what - we're ready to go now."

Devon, you mentioned the button on the repo, you mentioned the FUNDING.yml and how you can specify how you like to take funding, you mentioned you added project support… Why don't you give the quick rundown of exactly as it exists today, how GitHub Sponsors works, and what people see and what they do with the feature.

So earlier we were talking about Daniel Stenberg, the maintainer of cURL, and I imagine that a lot of the people listening to this have used cURL before, so you can imagine you want to fund his work… And you might find the sponsor button to give him that money either through your day-to-day workflow, if you are opening pull requests on any of his projects… You could also find it on the top of the cURL project, on the repo, there's a little Sponsor button, and you can also find it on Daniel's profile page.

When you click that sponsor button, you would be taken to Daniel's sponsorship profile, where he surfaces to you a number of different tiers that you can offer. I don't remember what his tiers are off the top of my head, but the sorts of things that maintainers usually offer are things like support hours, or sometimes there's actually no reward at all, or they'll send you stickers… Really whatever it is that they think maintainers might want.

Just last week we made it possible for projects to receive funding, too. So if you would prefer to give to cURL, the project, as opposed to Daniel, the lead maintainer, you can also do that. It's a very similar process. We intentionally kept those two experiences as similar as possible, because really we want sponsors to just be able to fund whatever work that they care about, without having to really make a [unintelligible 00:31:46.16] decision between the two paths that they could go down.

[31:53] What about organizations? I'm thinking of like a Plataformatec, who has the Elixir project, they have the Ecto project, and I'm sure they have other Elixir-related things… Can I say "I wanna fund this organization on a monthly recurring basis", or it's just projects and individuals?

So you can definitely fund that organization on a monthly recurring basis. One of the things that I was really excited about when we launched the ability to fund organizations was that it can be recursive. So you could have an organization that has projects, that has developers, and it kind of lets you build up to whatever level of complexity of organization as you want.

A concrete example of an organization I think is super-cool, and that I've found during my research, is this thing called Clojurists Together. Basically, the model is that they accept funding on behalf of really the whole Clojure ecosystem. Developers and companies will give them funds, and then they have like an application process where different projects in the Clojure ecosystem can come in and say "Hey, we would love this grant for the next quarter", and then [unintelligible 00:33:04.25] So they could technically be funded through sponsorship organizations, even though they themselves are not an open source project per se.

That is cool.

What's interesting about Daniel as the example though is that Daniel himself has his own sponsor page, cURL the organization has a sponsor page, and then cURL/cURL the repo decided to use a FUNDING.yml file to specify other ways to fund them, and they're actually using an external link to Open Collective. So Daniel and the organization is using GitHub Sponsors, and cURL/cURL the repo is using Open Collective. So it's interesting to see that you can actually - as you mentioned before, being additive, that it's not an end-all-be-all, GitHub Sponsors world. You can decide as an organization and even at a repo level where to get or source your funding.

Yeah, and I think that keeping that diversity in the funding ecosystem and continuing to grow it is really crucial. All open source projects are different, all open source developers are different and have different goals with what they're building. Something I often say is that saying that a project is open source is about as descripting as saying that a company has a business model… Which does tell you something, but it doesn't tell you really how it's structured, how decisions are made, where money goes, or anything like that.

So what I'd really like is for us as a whole ecosystem to keep offering new options for people, and I think that the most successful ones will just sort of rise to the top and become clear best practices. But the ecosystem is so young still that I think we're still very much in an exploratory phase, and I just wanna see people try as many crazy new business models as possible… And I do expect probably most of them won't work out, but we will learn as a community over the next few years.

You mentioned you're in beta now… So how many beta users/maintainers or people in GitHub Sponsors are currently in there now? Just a rough estimate.

So it's a little bit confusing… We are currently out of beta for 30 countries for individual developers. So anyone from the U.S, the U.K, Slovenia, Slovakia… I'm not gonna list all 30 right now, but…

Come on…

…30 countries can join. And if you fill out the application, I'll accept you by today or tomorrow, or the next time I go through all the applications. Then we're in beta still for sponsored developers in other countries, but we're working really hard to expand that list. And then sponsored organizations is in beta right now for all countries. And I forgot what your question was… Can you remind me?

[35:58] The numbers on how many folks are involved, right?

Yeah, kind of teeing it up… So trying to get a census of who's (I guess) giving you feedback. So my question was kind of driving towards what is – I guess you kind of have three different customer types. You've got individuals, you've got organizations, and you've got repositories… And they can all be one and the same, but they sometimes are not always. So you end up actually having a very diverse set of needs or desires for a funding model or sponsors model… So I guess my question was driving more towards what are the core things you're being asked for when it comes to getting funding? Is it tax-deductible donations or sponsorship opportunities? Is it more larger donations from corporations that use my open source project? Having an Instagram model, for example, where they get a billion dollars from Facebook, but [unintelligible 00:36:49.04] giving back to open source…? That was actually an example given by Nadia way back when she initially released some of her research around this subject… So I'm just kind of curious what are some of the core things you're being asked for, or core things that are needs for GitHub Sponsors? …but it's kind of diverse.

The answer to all of the above is yes.

Yes, okay… [laughs]

Everyone wants all those things. I think we would like to do basically everything you've mentioned, I think, ultimately. Actually, if your organization is already tax-deductible, then you already may have tax-deductible sponsorships right now, if that's possible… So that's more a question of the entity that's receiving the funds, as opposed to sponsors itself.

I think people are really asking for new, different types of business models. Right now we only support recurring donations, but we would really like to expand that to different types of billing. We started with recurring, just because that was the thing that maintainers asked for the most when we were first building it… And when we asked for feedback, people said that that was the most important thing. Now that we have that, we are starting to explore what would one-time donations maybe look like, or other sorts of things that look a little bit more diverse.

At the same time, I think I have a small fear that maybe if we did one-time donations, it could potentially cannibalize funding from the recurring donations. I'm not sure; that's something we need to test.

How do you mean?

So there's two stories I think you could tell here. There's one story where you say "If you only have recurring donations, then there's a lot of people who aren't gonna give, even though they would like to, because a recurring donation is really a major commitment." So that sort of says there's less money going to open source maintainers than there could be… Which is not the world that I'd like to live in, and I would prefer to put one-time donations in.

On the other hand, you could say there are people who would have given recurring donations, but because we have one-time donations possible, they just put that in, and it's a much less stable source of revenue for maintainers. So either the total amount of funding actually goes down, because there's people who might have been willing to do recurring, or maybe the total amount doesn't go down, but it turns a lot spikier, where maybe you get suddenly like a $500 lump sum donation today, but you don't know if it's gonna be there again in a year.

I'm actually pretty torn from a product perspective as to what to do… I generally bias towards giving people the options that they're asking for, unless I have a really, really good argument against it… But it's something that we wanna be very thoughtful about before we dive in. It's something that I've been having a lot of conversations with the designers on our team, and talking to as many users as possible as we make these choices.

[39:56] So that's sort of drilling down into one of the things you were asking about, but we're kind of thinking about the implications of all of these different pieces and trying to calibrate it appropriately.

What's pretty interesting is something you've mentioned there, talking to the designers at GitHub about this, is that these choices manifest into infinite complexity when it comes to hierarchy on a web page or a design… And I guess ultimately the software behind it is empowered, but gosh, I'm primarily an interface kind of person, and so I think about user experience all the time, and I actually was in the nonprofit business for a while, where we were doing recurring donations and single donations, and it was very difficult to sort of give people a well-ironed path that they can easily go down without having to give them so many user experience-fatiguing opportunities throughout the process, because you wanted to give them infinite opportunities to give, because hey, people are generous… "Help me give the way I want to give, because I'm the user I wanna do." And I actually asked this question to you before in the notes we sent you about what we might ask you… Because I actually almost gave somebody some money recently through a sponsorship, and I wanted to give them a one-time – it wasn't a long-time sponsorship opportunity for me, and I couldn't give them a one-time donation… I was like "Hm. Okay."

But now, hearing the other side of this, of how that might change or cannibalize recurring, I can see how in the name of sustainability, part of that is stability… So you wanna give somebody (an organization, an individual) an opportunity to understand what their revenue or what their income might be for that project, so they can plan accordingly. If you have spikes up and down, it could be difficult… And obviously, cannibalizing some of your recurring opportunities would be a pretty bad thing.

Yeah, and the point you raised about complexity is so key. I actually should have mentioned that, too… There's also a version where you have an excited potential sponsor and then you offer them a thousand different options, and a page of all these different things, and maybe they don't know the conventions, what it means, and… I don't know about you, but I get certain types of social anxiety when I don't know how to interact with a particular web page that is part of a social network.

For example – I mean, I know the norms of GitHub Sponsors, because I've been working on it, but you could imagine… I remember the first time I went to Patreon a few years ago, and I'd never sponsored anyone before, and on Patreon the person described what they expect from different people in different tiers… And I don't remember exactly what the phrasing was, but it was something like "If you're a student, you can do one dollar. If you're a professional who has a job, I would love for you to do this etc." And I wanted to go on a higher tier than the description that the person had put for me, and it made me anxious; I was like "Are they gonna think I'm a different person?" It's hard to articulate exactly the feeling, but it was this feeling of uncertainty that I was doing the right thing, and doing the right social interaction there, when I was just trying to help them.

So we think a lot about trying to make it so that this is a really nice way to connect with people in your community and connect with the developers you depend on, as opposed to a source of even more friction and anxiety about how to relate with each other. But I think part of it too is setting those conventions and helping spread that understanding, and just developing those practices over time. So maybe it's just a question of waiting and people will become more comfortable.

[43:43] Well, I think there's certainly something to be gained from the simplicity of one type of model, although I think over time you could be pressured into doing one-time donations or one-time sponsorships… But even the words collide - donations, sponsorships… Because this isn't called Donations, it's called GitHub Sponsors. You want people to sponsor an organization, an individual or a project to enable it to do its thing in the future. It's not a donation platform, it's a sponsorship platform.

There's one (I think) pretty clear place where you could stay inside of the current use case and extend, which is you can now sponsor an organization, a project, an individual, but you can't sponsor an issue. So I think where one-off sponsorships make sense single-time is in a bounty-style system. I know I've had a situation where I said "If I could just pay money to get this thing fixed, I would. I'd happily pay this. But it's been sitting open for X months and I don't have the skills or the time to do it myself, and I'm not gonna nag the person and beg them to do it, because I understand where they're coming from as a maintainer… But if I could give them $500 or $100 or whatever it is, I would happily do that."

And I know that people have asked you all for bounties, because Devon, you and I were staying next to each other at the Open Core Summit, and a fella asked about bounties… So surely, this is something you've thought about… Is issue sponsorship a thing that might happen, or are bounties off the table? What are your thoughts on that?

Bounties are definitely a suggestion we get a lot. I think that bounties work really, really well for low-context issues. The place we've seen the most success with bounties is with pentesting, and security researchers. And the reason for that in my mind is because to be an effective security researcher, you actually want to have zero context on the project, as if you were a black hat hacker. And then what you're trying to do is you're trying to see what would someone with no context be able to do with this project, right?

So if you have a spectrum of low context to high context, security research is on the very low end. On the very high end is maintainer leadership, and setting the vision for a project, and making sure people are working on things that they're excited about, but also actually aligned with what you wanna do. That's the sort of thing that I think is a lot harder to put a bounty on. You can't say "I'm gonna put a bounty of $1,000 on someone having a great idea for the next open source project, or for doing general community work."

Sure.

Being a maintainer is kind of like being a manager of a team, in that your job is to be the glue that holds everything else together, and oftentimes it's not a single task that you can put a price tag on; it's sort of a bundle of work that has to be taken all at once. So this is the long way of saying I think that bounties can work really great for certain problems. I would be really surprised if they worked well for other types of problems… And right now we're – at GitHub Sponsors we're a lot more interested in the high context problems, and motivating maintainers, who are the glue for their whole project, to keep working on that and make it possible… But that is not to say that something like a bounty would never happen. I'm not opposed to GitHub trying something, but I think it just doesn't solve the problem that we're currently tackling.

Yeah. I can see it from Jerod's perspective in one way, because I can see him – he's pretty insightful; Jerod, you are pretty insightful…

Thanks, Adam.

…and he often sees problems in things that maintainers actually would see value in solving, but they may not always have visibility into it, or even awareness that a user - which is Jerod, or even us - has with their source code, their project. They wanna solve problems for their users, but they're just not aware of it… And as Jerod said, he doesn't wanna seek them out and nag them (in his words) to get them to solve his problems. A paid issue could be an easy way.

I could see how it's valuable to the maintainer, but then also, like you said, a low-context issue, where you wanna focus on higher-level concerns they have, rather than something that's a bit more obscure, like this might be. And also, it could be an opportunity for abuse.

Yeah. I think it also opens other questions… Let's say someone puts a bounty on an issue, and Jerod is the maintainer, and I come in as a developer and I close the issue. Should I get all the money? Should Jerod get the money because he's the maintainer, and created the potential for that value to be created in the first place? I think the idea answer is probably something like I get two thirds of the money and he gets one third, or something like that…

Or it could go up one more level, where you said you gave the counseling to the organization or the project, they've defined how they distribute money… It goes back to that policy, potentially. But again, it gets very complex, right? It does get very complex. Like, how does it work? Who gets the money?

Exactly, exactly. And I think these are all questions that I would love answers to, and if I could clone myself, I would definitely do some way deeper research on that, and potentially build something into GitHub if we thought it was the right call. I think in the short to medium-term roadmap we have a lot of other things that we wanna get to… But I would love to see more experiments with bounties. I think that they're something that will solve a lot of important problems in open source.

And I think there are people out there doing those experiments. The more that I think about bounties, the more I think – I think this is a problem worth addressing. I think it's different enough that it's almost not a GitHub Sponsors thing. Maybe it would be a different team, or a different product inside of GitHub, if GitHub tackled it first-party, but… I think it's like, let the marketplace shake it out a little bit and see what works. Because as we started to discuss here in just the last five minutes, it's incredibly complex to do that well and to do that right. And while I do think it is a simple way of saying "Here's recurring sponsorships, and then here's an opportunity for a one-time sponsorship", it solves that particular UX issue, of recurring versus one-time, and it introduces a whole host of other issues.

So we've been talking about sponsors, and Adam, you mentioned they don't want people to donate, they want them to sponsor, and that got me thinking, like "What's in the name?", and the answer is "Everything is in the name…"

Right…

So GitHub Sponsors - I'm just curious, Devon, how much time was put into… Like, was that the obvious name for this project, was it a thing you mulled over, was there debate, were there other names that didn't quite make the cut?

Oh, gosh… [laughter] So we've definitely thought about it a lot, and I think I considered probably a thousand other names. And to be totally honest, I think Sponsors is a pretty good name, and it fits with GitHub's history of picking pretty straightforward – like, "GitHub Actions", "GitHub Issues", "GitHub Projects." Not these abstract things…

Right.

So it fit nicely with that. I feel like there's still a more perfect name that we could have found out there, and there will always be that tiny, tiny bit of doubt in the back of my head… But we've probably spent at least thousands of hours thinking about it, and I couldn't think of something better. So I'm not totally over the moon with the name we've picked, but I think it's good, and I think it basically explains what it does.

I happen to know somebody who's amazing at naming things, and he's right here.

Oh, yeah?

Are you talking about yourself in the third person?

[laughs] No, never. That's crazy.

I should have called you up, oh no.

Well, so it's called JS Party because Jerod named it that; it's called Go Time because Jerod named it that. I'm speaking of two of our podcasts in our network… So I would say Jerod is pretty good at naming things. I'm also good at it as well, but he seems to have overtaken me, considering our show count and named shows, so there you go… [laughter] It's called Backstage because he called it Backstage…

Well, that's obvious…

We've retired Spotlight. I called it Spotlight, so he's winning right now, for a lack of better terms… He's winning. So do you have a better name, Jerod?

[52:10] Oh, all the pressure right now… I'll just say Devon drilled it with GitHub Sponsors; of course, I didn't think about it nearly as much as she and the team did, but… No, I like it. I like it.

There you go, Devon. You're good to go then.

[laughs] Well, thanks.

You've picked a winner.

Next time I have to name something I will definitely call you up. It sounds like Adam just volunteered you do so.

There you go.

I'll have to do that. No, but I strongly agree - names really matter. In addition to being really interested in cities, I am also really interested in linguistics. I don't know if you've heard of the Sapir–Whorf hypothesis… It's this idea that if a word is not – there's two versions of it. There's a strong version and a weak version. The strong version is if a word doesn't exist in your language, then you basically can't have thought about it… Which I think is a little bit too extreme.

But I do think that if your vocabulary or if your grammar don't make it easy to talk about something, then you will think about it less than you otherwise would. It's very similar to programming languages. If you have a construct in a programming language that makes it really hard to do loops, or something like that, you're gonna figure out ways – you might avoid doing loops a little bit more, and you might end up mapping, or something like that.

That's why memes are so effective. Memes are so effective because they encompass so much in one phrase, one gif, one something. It encapsulates such depth of meaning in one thing. That's why memes are so successful, and that's why naming things to tame them, as they might say on Brain Science, the other show we have… Because once you have a definition or some sort of nomenclature to go by, it gets a lot easier to hand that ID to somebody else and to depend their thinking around that idea.

Yeah, it's like putting a handle on a pot; it just kind of gives you a way to grab… And I think that's actually where the word "handle" comes from; you know, screen names are handles… I always thought that that was like – the handle makes it easier for you to grab someone's identity and pick it up.

Hm… I never thought about why screen names are called handles. I never thought about that.

But yeah, names really matter, which is why I grueled over, trying to think of a better name… But it is GitHub Sponsors now, and probably it won't change at this point.

So when it comes to discovery, Devon, around open source, if I'm not knee-deep in it, like Jerod and I tend to be when it comes to the Changelog and things we do around here at Changelog Media, if I'm not in the position of me or Jerod and I'm just wanting to give to open source, it's kind of difficult, I would say, to find out what might be interesting… So what do you have in plans for discovery of open source that needs to be sponsored? Like, if I wanted to give to open source, what might the future look like around discovery?

This is a major theme that we plan to work on in the coming months. Right now the places you can find out about discovery are if you know the specific developer, you can go to their profile. If you are working with them in the context of an issue or a pull request and you hover over their avatar, then you will see a little sponsor button there… And then also there's the Sponsor button at the top of repositories and organizations that will send you there. But those are all kind of not super in-your-face, and maybe you miss them entirely, especially for projects where you're not going to the readme all the time.

We did that intentionally in the beginning, because the theme through this conversation has been "We wanna let the rope out slowly and understand what we're doing before we dive right in." But I think we're at the point now where we'd like sponsorship to show up in more places in GitHub, in more places in people's workflow, give people better tools for it… You know, there's a lot of people who say "I want to support open source, I just don't know which projects I should fund."

So we're looking into things that we could do around maybe your dependency graph; we have all that information, so maybe we could create a little tool to say "What are all of the sponsorable projects that are in my transitive dependency graph?" We're not building a specific thing for that right this second, but we've started talking about that stuff as a team, to be like "What would that look like?"

We've also gotten a lot of really exciting input from companies too, that they would really like to sponsor open source. They tend to have even less concrete knowledge about which projects their developers are using. A CTO might reach out and be like "We wanna sponsor open source, but we don't actually know what our developers are using every day."

So this is a major question that we're thinking about right now, and we would love ideas. If anyone ever has them, feel free to reach out.

[01:00:15.02] Well, there's BackYourStack.com… Is that what it is, Jerod?

BackYourStack, yeah.

BackYourStack.com, which is discover the open source projects with an asterisk of your organization used, that needs financial support. This is from our friends over at Open Collective; they've done this for a while, and that's a great way to do it, and to actually use GitHub profiles obviously to do that, because you just plug in your handle, organization, whatever… And out the other side comes this dependency graph, essentially, that says "Hey, this is what you can give to", which seems to be the easiest way.

I think that's a great tool, yeah. I've spoken with Pia from Open Collective a little bit about this, and I want more people to use that thing. I think it's a great step forward in that direction. I think it has some downsides, like any solution, and this is not really a critique of it, but just more of a pointing of "We'll need other tools for funding other projects."

For instance, one of the most important dependencies I use is my text editor. I used to use Sublime Text, and now I use VS Code, and those are absolutely key to my development. If you took VS Code away from me, I would be very sad. But it does not show up anywhere in my dependency graph, and so figuring out other ways to recommend it to people, like "Maybe you should fund–" VS Code is not a good example, because it's funded by Microsoft…

I was gonna say… [laughter]

But maybe you're using another open source text editor that needs funding.

Well, the example of it not being in the graph is on point, right?

Yeah.

That's the thing…

Tools.

But to be clear, I think any tool that's gonna surface information about funding is gonna have some sort of blind spot there, so I think BackYourStack is still a huge step in the right direction… But I also wanna just think about like "What are the things that it won't show us?", so that we also remember to keep those in mind, and that we remember to build tools around that stuff, too.

It still requires somebody to be – and I guess that kind of just speaks to who would be motivated to sponsor open source. It wouldn't be just some random person, "Hey, let me give money to a cause of open source." They don't think that. General, every day people don't probably think that. It's usually somebody who's steeped in this culture, often in a business that relies upon software, which is most, but specifically people that have engineering departments, or they create their own software and maintain their own software, whether it's a website or an application or not…

But it's gonna be something like that, that's gonna be steeped in dev culture, for a lack of better terms, to give to these reasons, because they don't want their dependency graph to be obliterated by lack of support or sustainability. They wanna give to it. Is that kind of where it's at right now, that kind of person, or everyday people aren't giving to open source?

I would put it in two major categories. One of them is what you've described, where it's more people who need the open source to be maintained long-term, because they depend on it for their job; if you just think about how much less productive every developer would be if they couldn't use open source - it's a great lever. So that's one bucket, is people who say "I need this for my job, and my company needs this."

On the other hand, there's also people who do it for – I used the Twitch and YouTube creators analogy earlier, and said that there were some limits to that analogy, but I would say that this is another place where you can extend it, where a lot of people follow open source developers just because they're really inspired by their work. They think that what they're doing is cool, they feel like they learned from them… We have a number of open source developers on GitHub Sponsors who have actual Twitch streams; you can watch them live-code, and learn from them that way.

[01:04:10.10] So there's two different major personas or users using this. One is people who say "This is just a smart business decision, because we need this software to keep working." On the other hand, it's people who say "You know what, I'm a student. Maybe I just care about what this person is doing, I admire them, so I'm gonna fund their work." An example of that, Henry Zhu is a good friend of mine, and I actually – I mean, I'm not a developer anymore, so I don't really depend on his code directly, except for side projects of mine… But I think his podcast, Hope in Source - which is a cute name…

[laughs] Yes.

…and his blog and so on really mean a lot to me. I've learned a lot by listening to that, and by sponsoring him; I'm also subscribed to his email newsletter where I get updates about his day-to-day life… Which usually don't even pertain to software, but I just – he's such a cool guy. Oh, and for some context, Henry is the maintainer of Babel; I think I didn't mention that.

So while he's doing a lot of amazing open source work, and I'd love for him to keep doing that, I'm mostly sponsoring him because I just really admire him. So I think there's those two categories - people who are doing it for a business sense, and people who are doing it because they just want to show support to someone who they think is really cool.

That often happens – you kind of mentioned that, to some degree, with the corporate example, where "Hey, we wanna sponsor open source [unintelligible 01:05:45.02] using developers that are in our company." And then there's some companies that just wanna give to open source - or they're even asked to; so somebody may be doing a fundraising round, or some supporter round, or whatever it might be, and they'll get a lot of pushback of like "Well, we can't really sponsor as a company." You know, like a donate kind of thing. How do you solve that problem for (I guess) corporations, or businesses, or whatever it might be, that wanna give to open source but find it kind of hard? Is part of GitHub Sponsors solving that problem as well?

Something I've been really thrilled about is – initially, what we've launched is basically just for individuals to be sponsors, and it doesn't offer great tools for companies… And yet, companies are already using GitHub Sponsors to support developers that they depend on and projects that they depend on… And this is cool to see, because it means they're taking this thing that wasn't exactly meant for that use case, but they wanna do it so badly that they're doing it anyways…

So we've been talking to some of these companies that have done that, to be like "How can we make this easier for you? What can we do to make it so that it's as trivial as possible?" We're thinking about this really deeply, and looking into – maybe there's different business models that make more sense. Maybe people need contracts in place, maybe they don't; maybe they just want certain guarantees… So we're working with companies to decide what some of those features might be right now.At the moment, I don't think GitHub Sponsors is a great solution for it, and yet companies are actually still already starting to use that…

Ultimately, I really wanna end up making it so that it's super-easy for companies to give through GitHub sponsors, because ultimately it's companies where the monies are at. Money is at companies, and also, companies are the single biggest users of open source, because they actually have money and they're actually benefitting from it directly financially, and they depend on it. It's just such a clear alignment for me…

[01:08:02.19] One of the things that I've seen from talking to a lot of open source communities and companies who depend on that open source is that companies are really looking for ways to fund open source, and I think there's a bit of a meme in the open source community that companies don't wanna fund it… But I think the problem is that there's just a disconnect, where it's hard to do so right now. But companies do actually spend a lot of money on swag and sponsoring conferences, and while everyone likes swag, and while everyone likes a good conference, I think everyone who does that kind of understands that it's just the best way that they have right now to sponsor open source… But if they had a better way to more directly get money to fund development and maintenance, I think that they would take that option.

So the role that I see GitHub playing here is sort of bringing those puzzle pieces together and being like "These companies wanna fund the development. These developers want to develop and get paid for it. So let's bring them together."

The thing that I think has been missing so far is just that they don't have sort of a nice spot where they can all come together and make that happen easily. Usually, it's sort of like a one-off conversation and they all have to connect with each other. So it's a long way of saying that I think GitHub Sponsors can potentially be that place that sort of brings these companies and these developers together to get that transaction to actually happen for the benefit of both parties.

It seems like companies often want something in return, whether it's advertisement, or influence, or direct access to developers, or support… Are these things that can be built into the tier system, or is it flexible enough to handle a developer offering such things to companies, or would those things be tangential or outside of the system?

Those are definitely possible within the tier system. My hypothesis though is that actually there's a lot of low-hanging fruit that is just waiting to be plucked, because there are companies that would actually just give, with no quid pro quo in return… And I don't think this is gonna solve the funding problem, but I think there's a lot of companies out there that just wish that they had an easier way to just give the money.

So I'm sort of thinking of this as a ladder, where what I first wanna do is make it easier for those companies to give, with things like invoices, and better billing integrated, and so on. And just by making it easier, that will unlock some money that hasn't moved… But then for the companies that want a little bit more than that, and it's not just about it being too hard to give right now, but also they want some benefits, like the marketing, like the support hours, or whatever - maintainers can define that within their tiers if they wish.

So yeah, I think that just making it easier is the most important thing we can do right now, but tiers will also help expand the size of that market even more.

Yeah, I think there's a difference between kind of the petty cash, and then like the big investment… And I think on the petty cash side there's lots of wiggle room for companies who see the value; if it was just easy, then those kinds of things would happen.

Yeah.

The reason why I started thinking about the value-driven stuff is because when you talked about conference sponsorships, the bigger conferences - you could spend 10k, you could spend $50,000 on a booth at a large conference… And I started thinking "Well, if we could redirect some of that money directly to some maintainers, suddenly that's making huge impacts."

Yes, yeah.

And I'm wondering if those are the kind of investments we need to have from organizations to really move the needle, or if we think the smaller, more ad-hoc, petty cash style is enough to at least raise the sea level.

[01:12:02.16] I'd say both. I would really like to continue having – I think the really big cash amounts are important to make that really big investment. It's hard to pay a full salary just on a bunch of small donations. At the same time, the small donations bring a certain level of stability that one really big benefactor won't bring…

If I were trying to fund open source work for myself, what I would aim for was to have something on the order of like 50% of it paid for with really big chunks from companies, and the other 50% trying to come from a bunch of small developers… So that if that one company pulled out, I wouldn't be totally toast.

Yeah. Talk about influence… At that point you're beholden to that one large donor.

Right.

We have this situation with nonprofits already, and it gets to be very sticky and unfortunate at times.

Exactly. So I think a healthy ecosystem strikes a balance between those two things. And it's not to say that developers going farther than 50% on one hand or the other is bad; they can do what they want, but there are certainly trade-offs there… So it's been important for us to enable both of those, and actually we wanted to start with the small donations from developers, because it's ultimately about making it so the community can decide where things go, as opposed to just a few big companies.

I'm sure this is answered in the FAQs, or a blog post, or somewhere very clearly, but just to put it on record in here on this show, what is the business model of GitHub Sponsors? Is it meant to make GitHub money? Does 100% go to the open source maintainers? How does the flow of money work? Is this going to be something where you plan to make money from it?

We have no plan to make money from it. In fact…

You're losing money.

We're losing money on it, yeah. And I think it's actually a strategic decision. As we were talking about, open source maintainers are a small portion of all of the developers on GitHub, but if we make them 10% happier or 10% better at writing open source software, all of the GitHub community is better off, and then more people wanna be on GitHub.

So our business model is basically to make the open source communities much healthier and much happier with us, and they stay on GitHub. So it's like a roundabout way of saying the way we make money is by supporting the rest of the business.

GitHub Sponsors by itself loses a lot of money. Actually, I should not say that; it does not lose a lot of money. Because of this really interesting pyramid effect, where a very small number of developers are actually maintainers, there aren't that many fees that we end up having to pay in the first place, because there just aren't that many people. So we are actually able to keep the costs quite low, because the ratio of developers on the whole platform to maintainers is really quite high.

Well, since you brought the YouTuber analogy again, I've got to ask you a question then on this… We see interesting things happen in the Twitch and YouTuber space, where people will try to find ways to give very creative people money just to do cool stuff on Twitch or YouTube. Do we see that happening in the future with GitHub, when it comes to maintainers? Do we see more creative ways for larger pools of money or interesting funding possibilities to happen for maintainers?

Yeah. I think the whole open source ecosystem has been really creative here. There's things like bounty source, or Zerocoin, and all these sorts of things that are really testing the boundaries of what it means to fund open source. And while I'm sure that not everything will succeed in the end, and they're all very exploratory, some really great learnings will definitely come out of there. Some of them will succeed, and I don't know which ones they will be. I'm really excited to be in this space for the next few years. It's gonna just change so much.

[01:16:08.25] At GitHub we're pretty focused on the sponsorship model as it is at the moment, just because honestly there's still so much to do. We want to really nail it and make sure that what we're providing is great for people worldwide. As a quick tangent, one of the really important things for us is to make this available to all GitHub developers all around the world, everywhere where GitHub does business… Because ultimately, this is about expanding opportunities for people.

One of our really big focuses right now besides the discoverability stuff is that it really matters to us that we keep rolling out to more and more countries over the next few months, really as quickly as we possibly can.

That's the long way of saying that GitHub Sponsors has a lot of stuff we need to nail down right now, just from an operational standpoint, and we're trying not to spread ourselves really thin… But I am in full support of people trying new business models and all of us learning as a community from them.

Aside from that, is there any other low-hanging fruit or things that are obviously missing from the product that are just clear and present things that will be happening in the next 6-12 months? Or anything you can talk about with regard to roadmap, or things that you just can't wait to – I know you can't pre-announce things necessarily, but what's obviously missing?

I think the company aspect is obviously missing, and I guess it's clearly not missing enough, because people are starting to do it already… But we really wanna make that experience a lot better, and we're thinking hard about what that would look like, and talking to as many customers as possible, as many users who are companies who have started already giving through the platform… Finding those who would like to, but just find it too darn hard right now… So if anyone has feedback, or if you run a company or you're a manager of an engineering team or something, please reach out to me with your ideas.

All of our ideas ultimately come from the community and from conversations that we have with GitHub users… So as we're thinking about that, I would just love to hear everyone's feedback.

What response would you want the community to do? Is the easy answer "Sign up for GitHub Sponsors" or is it if you're a software developer, you hang out on GitHub and you consider yourself part of the ecosystem, but you're not a maintainer, somebody who doesn't need to raise support, how can the community at large support you in these efforts?

At the beginning of the conversation we spoke a lot about how the time was not necessarily right a few years ago, because the understanding of the sustainability and funding problems had not really permeated through software and developer culture yet… I think we reached a tipping point in the last 12 months that really made a major change. There's still more to do though…

I think there's still a lot of people who don't understand that this is a problem, who don't really think about where the open source they use comes from… I mean, I am embarrassed to admit this, but when I first started programming, I didn't think about where open source came from at all. I was like "This stuff is just free, and it's there, and I just get it, right?" I grew up in that era of "Everything on the internet is free by default. Of course it is, there's no label behind this…" That is wrong. Everything you get for free, someone made for you… And just sort of reminding people of that is really useful, and telling more developer stories, talking more about what is the process for creating the software and building an understanding of that stuff.

[01:20:01.06] I think that if we get there, understanding that all of the software we depend on had to be created by a human at some point, and that that human needs to pay their rent - that will keep this ball rolling and keep that idea spreading throughout the community… And to really raise that understanding that this is something that we should actually be investing in as a community.

When you look back at your efforts, maybe 3-5 years from now, how would you measure success? Would it be based on numbers, of how much money has been sponsored, or do you have metrics that you guys are tracking that says "Yes, we did a great job" or "We could be improving"? Or is it all based on qualitative analysis?

Yeah, I'd say it's probably in the 3-5 year range… I would say that it's how many developers are able to work full-time doing this. And that's not to say that people working on this not full-time are not important. That's also key. But back to conversation we had about context and how we're more focused on high-context work versus low-context work - [unintelligible 01:21:06.02] high-context work is when someone is working on something full-time, and really thinking about a problem deeply, and pulling together the whole team.

I'd say in the 10-15 year range, or 20 year range, what I would really like is if you have three 12-year-olds hanging out, and one of them is like "I wanna be a firefighter", another one's like "I wanna be a lawyer", I want one of them to say "I wanna be an open source developer." I think that should be a really appreciated career path that kids actually aspire to when they grow up… Whereas now I don't think that any kid says that they wanna be an open source maintainer, and they probably don't even know what it is.

Well, in the place of open source maintainer it's YouTube or Twitch streamer.

Right. That's another extension of the analogy. Okay, maybe I'm getting more bang for my buck for this analogy than I thought…

Yeah, that is pretty spot on, for me at least…

Yeah. It's sort of like how we have full-time jobs, where people take care of our other infrastructure. We have train operators who do great work every day keeping people safe, and making sure that the trains run on time, you have construction people who go out and fix the roads, and the freeways… Those are respected jobs that people understand have to get done, otherwise our infrastructure will crumble. And I think that it's just so not really understood when it comes to our digital infrastructure… In part because it's less visible; you don't see them out on the road doing that work. But also partially because it's just newer, so people don't have this mental model of how it gets made and maintained.

Since we're looking at the future, I guess, to some degree, when it comes to where we might go, what success might be in this future, I'm always curious about the data that comes along with that, and what insights we might be able to gather from that data… And I'm curious if there's been any conversations from you or others around the dataset that might come from this, the insights that you all might learn from it, but more importantly, will any of that be shared in unique ways? An open dataset, for example, to learn from this, or do some interesting things from it… I'm just curious what your thoughts are.

It's a great question. To be honest, I haven't thought about it super-hard. We've had our heads down building it so much that we haven't thought in those terms… But I think I would love to see GitHub sharing this stuff, including it maybe in the next Octoverse report, or something like that… That's not a guarantee. I'd have to actually ask the person who runs the Octoverse report to make sure that it gets in there… But I think it would be very cool to share more of this data with the whole community.

Ultimately, this is the heart of open source, right? …to get a lot of eyes on the same information, on the same code, and people will have ideas about how to solve more problems… So it's something we should definitely talk about, but we haven't had any detailed conversations yet.

Well, Devon, it's been a blast talking with you. Thank you so much for your passion for this. I think we need somebody like you in this position you're in to volunteer yourself into this job you're into; you essentially didn't even ask for it, but you were given it, and boom - you're knocking it out. We need somebody passionate about this problem to really do a lot of what you said, to be 10, 15 years down the road and look back at this as a successful thing that makes somebody wanna say "I wanna be an open source maintainer." That's cool.

Well, thanks.

Thank you, Devon.

Thank you. This has been a really fun conversation.