The Changelog: Software Development, Open Source - The making of GitHub Sponsors (Interview)

Episode Date: December 1, 2019

Devon Zuegel is an Open Source Product Manager at GitHub. She's also one of the key people responsible for making GitHub Sponsors a thing. We talk with Devon about how she came to GitHub to develop GitHub Sponsors, the months of research she did to learn how to best solve the sustainability problem of open source, why GitHub is now addressing this issue, the various ways and models of addressing maintainers' financial needs, and Devon also shared what's in store for the future of GitHub Sponsors.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. It's so easy to get started with Linode.

Servers start at just five bucks a month for your big ideas. Head to Linode.com slash changelog. Choose your flavor of Linux that works for you. Then pick a location that's right for you. London, Tokyo, Dallas, and many other places in the world. They've got you covered. Go from having that amazing shower idea to a hosted website in just minutes. Start small.

Expand as your idea blossoms into a huge hit. And we trust Linode because they keep it fast. They keep it simple. Check them out at leno.com slash changelog. What's up, everyone? Welcome back. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog.

On today's show, we're talking with Devin Zugal, Open Source Product Manager at GitHub, and one of the key people responsible for making GitHub sponsors a thing. We talk about how Devin came to GitHub to develop GitHub sponsors, the months of research he did to learn how to best solve this problem, why GitHub is now addressing this issue, the various ways and models of addressing maintainers' financial needs, and Devin also share what's in store for the future of GitHub sponsors.

So Devin, you came to GitHub specifically to tackle the sustainability problem. What became GitHub sponsors? We'd love to hear the story of what brought you to GitHub and how that all went down. So 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 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 that I met Nat Friedman through some what's called YIMBY

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. And we actually didn't really talk about software almost at all for the first year that we knew each other. I didn't really know that he had like a super technical open source background, anything like that. Um, and, uh, so I, I really respected him and all the work that he did. And I know he had had great values. And when I saw the news last June, was it, I guess that Microsoft had acquired GitHub. Um, I was just news last June, was it, I guess, that Microsoft had acquired GitHub. I was just like, oh, that's interesting. 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 was like, oh, that's interesting. The plot thickens. Yeah. So I reached out to him and 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 nonprofits 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. I think when I sent the email, I did with all my ideas, I didn't really expect him to have that response. That was not I was not looking for a job. But as soon as he sort of framed it that way, I was like, Oh, that's a great idea. I have to I have to take this opportunity. Working with 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 arrive there, it was probably just a bunch of ideas. And there's so many different routes to go. First of all, why? And opinions. Yeah, exactly. Oh, yeah.

And 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? What part of your background? I mean, I know you mentioned your kind of your activism in your local government, but what else makes like 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? So this is going to 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 econ 101 years, there's like prisoners dilemmas and tragedies of the commons and those sorts of things where basically the thing that they all have in common is that there's a lot of individuals who are operating on their own best interest and

trying to do the right thing. But the result is that they all sort of fail. So the classic example of this is like climate change, where no one wants the planet to melt and burn to a crisp. But everyone individually benefits a little bit more from taking that longer shower or driving to work instead of biking. And so the result is that everybody ends up worse off. And if they're not able to coordinate for sort of the greater good there. And 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. And so that's sort of a coordination problem. And so 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 $10 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. So 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. And 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, essentially, the three-year problem,

where instead of thinking about what you're going to do today as I've got to succeed tomorrow, it's more like I've got to succeed three years from now. How do you sort of peel back the layers of this very deep, very hard problem and solve it, I guess, 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. 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 want to 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 sort of 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. And 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 this really 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 going to 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 the show and who collaborate with us here at ChangeLog from Firas Aboukdijeh to, what's his name from Curl? Gosh, his name is blank.

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 see have seen struggling over the years on how to make their individual efforts into open source possible through funding yeah i i 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 like my heroes too right so it was it was so cool

to see that something that i'm working on building was also useful to them i mean like, like Curl, for example, I've used that since I 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 person is a real person. Yeah. It's not just like a god who handed this down from the heavens. And then seeing him be 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 always existed. 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 there's a person behind this thing, you just think about the thing. And I remember there was actually a tweet one point where someone realized that Daniel Stenberg, I realized that the guy who wrote Curl is still alive.

And Daniel retweeted and he's like, yes, still here. And it is one of those things so as a person who I concern myself a lot with execution like how do you actually get a thing done you come to GitHub you've settled in okay and you are tasked with this thing

now we know iteration has been part of the recipe but what are the first things do you do do you research what's step one down the path to get you to GitHub sponsors? Yeah, 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 went around. I traveled the world and spoke to a bunch of different developers. I went from Singapore to Paris to London to New York, 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 Eggball'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. And 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. And so I had calls or coffee or lunch with hundreds of open source developers and sort of all asked them,

like, 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, more open source developers than maybe almost anyone who was still there. And just because I had spent the last like four months just doing that. And so there's just tons of, you know, user interview evidence of like people want this.

People are just like waiting for GitHub to do it. So for me, it felt like really what happened was there was all, there were all of these predecessors in front of me like Nadia, like Mike McQuaid at GitHub, like a lot of people who had planted all of these predecessors in front of me, like Nadia, like Mike McQuaid at GitHub, like a lot of people who had planted all of these seeds and started growing these fruit trees. And I just kind of came at the right time and plucked all the 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 a benefit to arriving when it's harvest time. That's right.

Yes, exactly. It was time. It was ready. And I mean, I don't think it was always, 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. And so coming in and being one of the people who sort of saw all of these pieces, and then I just felt like I was the one who 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 Michael Rogers on

a series. I guess it's a podcast, but it's more of a podcast series called Request for Commits. It spanned 20 episodes. The final episode was its finale, sort of look back retrospective of where it went and what it had uncovered and where the conversation 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. You know, there's a lot of things that have propped up even around that time since open collective or code fund, um, 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. And now it's now sort of time to enable that. But you mentioned giving people an effective way to give. And what do you think the core goal or core, even today's iterations 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 it work? Yeah.

So I think the key thing that GitHub sponsors as it stands right now adds is basically distribution. At the moment, I should say... Awareness around that or distribution? How do you mean distribution? So as in 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 benefited people with really big Twitter followings or someone who had a newsletter or 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.

And so for us, it was key to just be putting this in the repository or on your readme on on your profile page from the get go. So now, I mean, there's a lot of times where I'll use an open source project. And I'd never heard of a developer before, but I'd super I really depend on it. And so then I click that heart button. And I sponsor them. Like 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. And so it was just so natural.

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. I agree that that's probably like of the wins that GitHub brings. That's like 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 responsibility to do and hadn't done for a while.

And then also only GitHub could do. So I think it's very additive. I mean, we've also been really working with those partners as much as possible to to bring them into the loop so one of the key things one of the key features we have um 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 because if you have an open collective if you have a patreon if you have a ko-fi you, you can fund people through that. And it was very important for us to include that in the launch so that it wasn't saying, you know, GitHub's just going to solve this problem now. No, no, no. We want like 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. So the first iteration was for individuals. Now you can fund your entire team through github sponsors and we partnered with groups like open collective and community bridge from the linux foundation to make it really easy to onboard groups of people um so what the way we see it is that we sort of help with the distribution and 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 if you wrote this or 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. You trade in one problem for a new problem, which is almost, I wouldn't say it's a worse problem, but maybe it's a less straightforward solution. When you don't have any money,

the straightforward solution is like get some money. How do 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 other challenges that come up. And 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.

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 wait list, we have a pretty extensive application form. When I say 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. It often means that people haven't put much thought into how to govern the project. Who is the owner of the project? Who gets to say? Which stakeholders get to be part of the decision. And it's to sort of go back to the city planning metaphor. It's, if you're, 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, right? Like, 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 of like how all this stuff, 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. And one thing I'm

personally doing is I'm reading 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, um, this particular thing that you explained is one of your policies could create some, some problems. And, um, I'm not using this as a strict filter. Like if they stand by what they want to do, then that's fine. But it just creates an sort of an outside council 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 that 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. Kind of reminds me of marriage counseling, Jared, where 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 funding counseling. How might it be best to get funding? You know, how might it be best to organize this repo that or this project has that has matured over time or is still immature and has some areas to kind of refine itself and be more positioned better to take on funding. That's a great metaphor. I really like that a lot. And even if I don't end up going

in and actually like giving advice, just I think having the team write down like 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 mentioned before, going to Singapore and to New York and to other places. You've got a diversity of geolocation. That means monetary, that means currency 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 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 been calls from the developer community for a long time, like GitHub, do something. That explains why you're there, Devin, because you liked that time, like GitHub, do something. So that explains why you're there, Devin, 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, like GitHub's very well positioned, not just for GitHub sponsors, but for lots of things. And so why do you think this one is important? You said, I think you mentioned offhand 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. It's that 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 it's useful, I think, in this context, is 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 like tiny, tiny, tiny fraction of users who are actually open source maintainers or developers. Same with Twitch streamers, same with YouTube creators. And so I think all of these platforms, GitHub included, like 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 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 like actually feasible for me to maybe know almost all the names of the maintainers on GitHub. Like I actually don't know exactly what the number is, but I could in theory like know a little bit about every single one of them. Whereas there's no way that's going to happen across all 40 million users. Meanwhile, if I make all of them, do you think it's like 1%? Do you

think it's like less than 1%? If you had a guess? Oh, I think it's I think it's less than 1%. When you say these maintainers, what do you mean by that? And like, big project maintainers are like regularly maintaining or? I would say maintainers being like the lead on a given project um that is actually used by someone who's not on the project um that's that's still sort of a loose definition yeah but that's like the one that i roughly work with um and i think like these are the just most most valuable people on the platform again both for github but for the whole community and so there's just amazing alignment there um and it's a place where we can have a lot new topic on people's minds, or at least the rendition of the conversation that we're having now. And I think the other piece was that there is something that while there

had been a lot of conversation in GitHub for a really long time, and a lot of really thoughtful people had thought about it um no one had sort of been the person to own it and and to say like we're going to 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 right like github can completely change the way open source works here um and for the worst, if we're not careful. So I think people were being very cautious. But then it got to the point where there enough expertise had built up that the company company felt, you know what, we're ready to go now. This episode is brought to you by GitPrime. GitPrime helps software teams accelerate their velocity and release products faster by turning historical Git data

into easy-to-understand insights and reports. Because past performance predicts future performance, GitPrime can examine your Git data to identify bottlenecks, compare sprints and releases over time, and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Get started at gitprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog.

Again, gitprime.com slash changelog. So Devin, you mentioned the button on the repo. You mentioned the funding.yaml 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 today, 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. And 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. And 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 is actually no reward at all, or they'll send you stickers,

really whatever it is that they think maintainers might want. And 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, just the lead maintainer, you can also do that. And 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 really crisp decision between the two paths that they can go down. What about organizations?

So I'm thinking of like a Plataformatech who has the Elixir project. They have the Ecto project. I'm sure they have other Elixir-related things. Can I say I want to fund this organization on a monthly recurring basis, or just projects and individuals? So it's you can, you can definitely fund that organization on a monthly recurring basis. One of the things that I was really excited about when we when we launched the ability to fund organizations was that it's 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. So a concrete example of an organization I think is super cool and that I found during my research is this thing called closureists together and basically the model is that they they accept funding on behalf of really the whole closure ecosystem and the developers and companies will give them funds and then they have like an application process where different projects in the closure ecosystem can come in and hey, we would love this grant for the next quarter. And then Clojure gives it to them. So they could technically be funded through sponsors for organizations,

even though they themselves are not an open source project per se. That is cool. What's interesting about Daniel is the example, though, is that Daniel himself has his own sponsor page Curl the organization has a sponsor page and then CurlCurl the repo decided to use a I guess

funding.yaml file to specify other ways to fund them and they're actually using an external link to OpenCollective so they're using Daniel and the organization is using GitHub sponsors and CurlCurl the repo is using OpenCollective so So they're using Daniel and the organization is using GitHub Sponsors and Curl Curl, the repo is using Open Collective. So that's kind of 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 where

it's, you know, 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. And something I often say is that saying that a project is open source is about as descriptive as saying that a company

has a business model, which like, you know, it 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. And so what I'd really like is for us to keep 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 want to 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. So you mentioned you're in beta now. So how many beta users, how many beta 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 uk slovenia slovakia like i'm not gonna list all 30 right now but come on 30 countries can join and um if you if you fill out the application i'll sit i'll accept you by today or tomorrow next time i go through all the applications. Then we're in beta still for sponsored developers in other countries, but we are working really hard to expand that list. And then sponsored organizations is in beta right now

for all countries. And I forget what your question was. Can you remind me? No question, really. 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 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, you know, 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 kind of be one of the same, but they sometimes are not always. And so you end up actually having needs, a very diverse set of needs or desires for a funding model or a sponsor's 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

that's having an Instagram model, for example, where they get a billion dollars from Facebook, but very little given back to open source? That was actually an example given by Nadia way back when she initially released some of her research around the subject. So I'm just kind of curious, what are some of the core things you're being asked for,

core things that are needs of GitHub sponsors, but it's kind of diverse. The answer to all of the above is yes. Everyone wants all those things. I think we like to do basically everything you mentioned, I think, ultimately, and actually, like if your organization is already tax deductible, then you may already be there, 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. Yeah, 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. And 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. But 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? By which I mean, like, there might be people.

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 going to give, even though they would like to, because just a recurring donation is a really major commitment, right? And 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. And so either the total amount of funding actually goes down because there's people who might've 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 going to be there again in a year. So 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 want to be very thoughtful about before we dive in. So it's something that we want to be very thoughtful about before we dive in.

So 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. 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 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 to power it, 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, you know, fatiguing, you know, user experience, fatiguing off 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. Cause I'm the user I want to do. And I actually almost, I actually asked this question to you before in our, in the notes we sent you about what we might

ask you. And cause I actually almost gave somebody some money recently through a sponsorship. And I was like, I wanted to give them one time. Cause it was just a, it wasn't a long-term sponsorship opportunity for me. And I couldn't give them a one-time donation. And I was like, oh, okay. But now hearing the other side of this, of, of you know, how that might change or cannibalize recurring, I can see how in the name of sustainability, you know, part of that is stability, right? So you want to give somebody an opportunity to have an organization, individual, whatever, an opportunity to understand what their revenue or their income might be for that project so they can plan accordingly. If you have spikes, ups and downs, it could be difficult and i guess obviously

cannibalizing some of your recurring opportunities would be a pretty bad thing yeah and the point you raise about complexity is so key i actually should have mentioned that too where there's also a version where you have an excited potential sponsor and then you offer them like a thousand different options and and like a page of like all these different things and maybe they don't know the conventions like what it means and i don't know about you but like i get kind of certain types of social anxiety when i like don't know how to interact with a particular web page that is like part of a social network so for example i mean i know the norms of github sponsors because i've been working on it. But like, you could imagine, I remember the first time I went to Patreon, maybe, I don't know, a few years ago, and I never sponsored something like, if you're a student, you can do $1. If you're a professional who has a job, I would love for you to do this. 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 going to think I'm a different person? It's hard to articulate exactly the feeling, but like, it was this feeling of uncertainty that I was doing the right thing and like doing the right social interaction there when I was just trying to help them, you know? So we think a lot about trying to make it so that this is a really nice way to connect with people in the, in your community and connect with the developers you depend on, um, 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 like setting, setting those conventions and helping sort of spread, uh, spread that understanding and just developing those practices over time. So maybe it's just a question of like waiting and people will become more comfortable.

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, sponsors, because this isn't called get-up donations. It's called get called GitHub sponsors. You want people to sponsor an organization, individual, or 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 where 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. I'm not going to 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. I know that people have asked you all for bounties because Devin, you and I were staying next to each other at OpenCore Summit and a fellow 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. And I think that bounties work really, really well for low-context issues. So the place we've seen the most success with bounties is with like pen testing, right? 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 like, what would someone with no context be able to do with this project, right? On the other end of, so if you have a spectrum of like low context to high context, security research is on the very low end. On the very high end is like 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 align with what you want to do. And that's the sort of thing that I think is a lot harder to put a bounty on. You can't say, like, I'm going to put a bounty of $1,000 on someone having a great idea for the next open source project or for, for, um, you know, doing generally general community work. Like, you know, I think that being a maintainer is kind of like being a manager of a, of a team

in that, uh, your job is to sort of be the glue that holds everything else together. And oftentimes that's not like a single task that you can put a price tag on. It's like sort of a bundle of work that has to be sort of taken all at once. And so this is a long way of saying, like, I'm, I think that balances could work really great for certain problems. I, I would be really surprised if they worked well for other types of problems. And right now we're, we're, 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 Jared's perspective in one way because I can see him. He's pretty insightful. Jared, 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 Jared or even us, has with their source code, their project. They want to solve problems for their users, but they're just not aware of it.

And as Jared said, he doesn't want to seek them out and nag them, in his words, to get them to solve his problems. And an issue, a paid issue might be like, hey, that could be an easy way. But I can see how it's valuable to the maintainer, but then also, like you said, a low-context issue where you want to focus on higher level concerns they have rather than something that's a bit more obscure like this might be. And also could be an opportunity for abuse. Yeah, I mean, I think it also opens other questions like, you know, let's say someone puts a bounty on an issue and Jared is the maintainer and I come in as a developer and I close the issue. Should I get all the money? Should Jared get all the money? Because he's the maintainer

and created the potential for that value to be created in the first place. And I think the ideal answer is probably something like I get two thirds of the money and he gets one third or something like that. But I do get open to it. said you gave the counseling to the organization or the project. They've defined how they distribute money goes back to that policy potentially. But again, it gets very complex, right? It does get complex. Like how does it work? Who gets the money?

Exactly. Exactly. And I think like these are all questions that I would love answers to. And like 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 just in the short to medium term roadmap, we have a lot of other things that we want to 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 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. It introduces a whole host of other issues. So we've been talking about sponsors, and Adam, you mentioned that they don't want people to donate,

they want them to sponsor. And that got me thinking, what's in a name? And the answer is, everything is in a name. So GitHub sponsors. I'm just curious, Devin, 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 so we definitely thought about it a lot and um we we i think i considered probably a thousand other names and um you know to be totally honest i think sponsor is a pretty good name and it fits with

with uh sort of github's history of picking pretty straightforward like you know github actions github issues github projects like they're not these like abstract things so it fit nicely with that i think like i feel like there's still a more perfect name that we could have found out there and and you know there will always be some like that tiny tiny bit of doubt in the back of my head um but we probably spent I don't know at least dozens of hours thinking about it and I couldn't think of something better so I'm not like totally over the moon with the name we picked, but I think it is. 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. You're talking about yourself? I'm talking about you. You're talking about yourself in that very person? No, never. I should have called you up. Oh, no.

Well, so it's called JS Party because Jared named it that it's called Go Time because Jared named it that I'm speaking of two of our podcasts on our network so Jared I would say he's pretty good at naming things

I'm also good at as well but he's he seems to have overtaken me considering our show count and named shows

so there you go it's called Backstage because he called it Backstage we retired Spotlight I called it Spotlight so he's winning right now for called Backstage because he called it Backstage. We retired Spotlight. I called it Spotlight. So he's winning right now for lack of better terms. He's winning. So do you have a better name, Jared? Oh, all the pressure right now. I'm going to say Devin

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. There you go, Devin. You're good to go then. You've picked a winner. Next time I have to name something, I will definitely. I like it. There you go. You're good to go then. 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, so I will have to do that. Yeah, no, but I strongly agree. Names really matter. Like in addition to being really interested in cities, I am also really interested in linguistics and um i don't know if you've heard of like the sapir wharf hypothesis it's like this idea that uh you know if if a word is not in a there's sort of two versions of it there's a strong version and a weak version the strong version is like if a word doesn't exist in your language then you basically can't have a thought about it which i think is a little bit too extreme but i do think that if if your vocabulary or if your grammar don't sort of

encourage you or don't don't make it easy to talk about something um then you will think about it less than you otherwise would like it's very similar to programming languages right like if you have a construct in a programming language um that like makes it really really really hard to do loops or something like that. You're going to 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 idea to somebody else and to deepen their thinking around that idea. Yeah. It's like, it's like putting a handle on a pot. Like it just kind of gives you a way to grab. And I mean, I think that's actually where the word handle comes from

when, you know, screen names are handles. I always thought that that was like, the handle makes it easier for you to like grab someone's identity and like pick it up. 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 I think it is GitHub sponsors now and probably won't change at this point. How often do you think about internal tooling? I'm talking about the back office apps, the tool the customer service team uses to access your databases, the S3 uploader you built last year for the marketing team, that quick Firebase admin panel that lets you monitor key KPIs, and maybe even the tool that your data science team had together so they could provide custom ad spend insights.

Literally every line of business relies upon internal tooling. But if I'm being honest, I don't know many engineers out there who enjoy building internal tools, let alone getting them excited about maintaining or even supporting them. And this is where Retool comes in. Companies like DoorDash, Brex, Plaid and even Amazon, they use Retool to build internal tooling super fast. The idea is that almost all

internal tools look the same. They're made of tables, dropdowns, buttons, text inputs, and Retool gives you a point, click, drag and drop interface that makes it super simple to build these types of interfaces in hours, not days. Retool connects to any database or API, for example, to pull data from Postgres. just write a sequel query and drag and drop a table onto the canvas and if you want to search across those fields add a search input bar and update your query save it share it it's too easy retool is built by engineers explicitly for engineers and for those concerned about data security retool can even be set up on-premise in about 15 minutes using Docker, Kubernetes, or Heroku.

Learn more and try it free at retool.com slash changelog. Again, retool.com slash changelog. And by our friends at Square, we're helping them to announce their new developer YouTube channel. Head to youtube.com slash square dev to learn more and subscribe. Here's a preview of their first episode of The Sandbox Show, where Shannon Skipper and Richard Mute deep dive into the concept of item potency. Welcome to the pilot episode of The Sandbox Show. A show where we'll- Well, a YouTube show. Where we'll deep dive into subjects

that developers find interesting. Don't worry, there will be plenty of live coding. I'm Shannon and this is Richard, and we're going to cover a broad range of topics as the show evolves. But for today, what are we going to be covering? On this first episode, we're going to be covering item potency. We had talked to people in our community and the thing that

people seem to be really confused by is this concept of item potency and how does it relate to interacting with an API. Right. And so I didn't do some Googling on this beforehand, but I know that you did. I did. So the definition of item potency comes from item and potent. So item being same and potent power or potency. So it's the same potency.

All right. Check out this full-length show and more on their YouTube channel at youtube.com slash squaredev or search for Square Developer. Again, youtube.com slash squaredev. so when it comes to discovery devon around open source if i'm not knee deep in it like like jared and i tend to be when it comes to the changelog and things we do around here changelog media if i'm not in the position of me or jared 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 face, then you'll, you're over their avatar. Then you will see a little sponsor button there.

And then also there's a 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 if especially for projects where um you know you're not going to the read me all the time we did that intentionally in the beginning because sort of the theme through this conversation right has been we want to let the rope out slowly and understand what we're doing before we 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,

more places in people's workflow, give people better tools for, 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. And so we're looking into things that we could do around, you know, maybe your dependency graph. We have, you know, all that information. So maybe we could do around, you know, maybe your, your dependency graph, we have,

you know, all that information. So maybe we could create a little tool to say, you know, what are all of the sponsorable projects that are in my transitive dependency graph. And I think, like, we don't have, we are not building a specific thing for that right the second, but we've started talking about that stuff as a team to be like, what would that look like? And we've also gotten a lot of really exciting input from companies too, that they would really like to sponsor open source. And they tend to have even less concrete knowledge

about which projects their developers are using. Like a CTO might reach out and be like, we want to sponsor open source, but we don't actually know what our developers are using. Like a CTO might reach out and be like, we want to 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'd love ideas if anyone ever has them, feel free to reach out. Well, there's backyourstack.com. Is that what it is, Jared? Backyourstack.com? Or is it back, it is backyourstack.com, which is discover the open source projects with an asterisk of your organization used that need financial support.

So 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 they 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 think I, I, I've spoken with Pia from open collective a little bit about this and I want more people to use the thing. I think it's a great step forward in that direction. I think it has some, some, 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. Where, like for instance, one of the most important dependencies I use is my text editor. Like I used to use Spline Text, I now use VS Code, and those are absolutely key to my development if you took VS Code away from me

I would be very sad that does not show up anywhere in my dependency graph and so figuring out other ways to recommend to people like maybe you should fund well VS Code is not a good example because it's funded by Microsoft but you know

maybe you're using another open source text editor um well the example of of it not being in a graph is is on point yeah like but then that's the thing yeah but to be clear i think like any tool that's going to surface information about funding is going to have some sort of blind spot there and so i think back your stack is still a huge step in the right direction. But I also want to 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 speaks to who would be motivated

to sponsor open source, right? It wouldn't be just some random person, hey, let me give money to a cause of open source. They don't think that. Like general, everyday 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 or maintain their own software, whether it's a website or an application or not. But it's going to be something like that that's going to be steeped in dev culture, for 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 want to give to it. Is that kind of where it's at right now, that kind of person? Or are we everyday people aren't giving to open source? I would put it in two major categories. One of them is what you described where it's more people who need the open source to be maintained long term because they depend on it for their job. Like 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, you know, I need this for my job, and my company needs this. On the other hand, there's also people who do it from I sort of, I use 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 are doing is cool.

They feel like they learn from them. We have a number of open source developers on GitHub sponsors who have actual Twitch streams that you can you can watch them live code and learn from them that way. And so there's this sort of difference. And there's two different major personas or like users using this one is sort of people who say, you know, this is just like a smart business decision, because we need the software to keep working. On the other hand, there's people who say, you know what, I'm a student. I mean, maybe I just like care about what this person is doing. I admire them. And so I'm going to fund their work.

So like an example of that is 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, and also that's Hope in Source, which I think is a cute name. Yes. And his blog and so on really mean a lot to me. I've learned a lot by listening to that and by subscribing as by sponsoring him. I'm also subscribed to his email newsletter, where I get updates about his day to day life, which like 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. And 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. And so I think there's like those two categories, people who are doing it for 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 at, you kind of mentioned that to some degree with the kind of corporate example where, hey, we want to sponsor open source. What are we using developers that are in our company? And then there's some companies that just want to give to open source and, or they're even asked to. So somebody may be doing a fundraising round of, 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 want to give to open source,

but find it kind of hard? Is part of GitHub Sponsors solving that problem as well? So 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 it doesn't offer great tools for companies. And yet companies are already using Kibb sponsors to to support developers that they depend on and projects that they depend on. And this is cool to see because it means that they're sort of like taking a thing that wasn't exactly meant for that use case, but they want to do it so badly that they're doing it anyways. And 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 sort of, you know, make it so that it's as trivial as possible. And we're, we're thinking about this really deeply and like looking into maybe there's different business models that make more sense.

Maybe people need contracts in place. Maybe they don't, maybe they want more certain more guarantees. And so we're, we're working with companies to decide what some of those features might be right now. Um, but at the moment I don't think GitHub sponsors is a great solution for it, but it, and yet companies are actually still already, already starting, starting to use that.

Um, so, I mean, ultimately I think that I really want to end up making it so that it's super easy to get for companies to give through GitHub sponsors because ultimately it's companies where the mon is at, and also companies are the single biggest users of open source. So because they actually have money and they're actually benefiting from it directly financially and they depend on it, it's just such a clear alignment for me.

And 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 want to fund it. But I think the problem is that there's more, it's just a disconnect where it's, it's hard to do so right now. But companies do actually spend a lot of money on swag and sponsoring conferences. And while, while I do, while everyone likes swag and everyone likes a good conference, I think everyone who does that kind of understands that this is just, it's 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 want to fund the development, these developers want to develop and get paid for it. So let's bring them together. And 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, I think GitHub sponsors can potentially be that place conversation and they all have to connect with each other so um it's a long way of saying i think github sponsors can potentially be that place that sort of brings these companies and these developers together to sort of get that transaction to actually happen for for the benefit of both parties 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?

Are these things that are like, is it flexible enough to handle developer offering such things to companies? Or are those things kind of would 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 where there's there are companies that would actually just give with no no quid pro quo in return. And I don't think this is going to solve the funding problem. But I think there's a lot of companies out there that

like, just wish that they had an easier way to just give them money. And so I'm sort of thinking of this as like a ladder where what I first want to do is just make it easier for those companies to give with things like invoices, better billing integrated and so on. And just by making it easier, that will unlock some money that has been like, hasn't moved. But then for the companies that want a little bit more than that, 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 like, I think that just making it easier is the most important thing we can do right now, but, uh, tiers will also help, um, expand the size of

that market even more. Yeah. I think there's a difference between like the kind of the petty cash and then like the big investment. And I think on the petty cash side, like there's lots of wiggle room for companies who see the value. If it was just easy, then those kind of things would happen. The reason why I started thinking about the value-driven stuff is because when you start talking about conference sponsorships, I mean, the bigger conferences, you could spend $10,000, $20,000, 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. 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 really raise, at least raise the C-level. 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.

And 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. So my, my, I like,

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, I don't know, 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. Um,

yeah, yeah. But at the same time, at that point you're basically like you're beholden to that one large donor i mean we have the situation with non-profits 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 that's not to say that developers going, you know, farther than 50% on one hand or the other is bad, like 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 sort of 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 and here in the show, what is the business model of GitHub sponsors? Is it meant to make GitHub money? Does it 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, we're actually losing money on it. And I think it's actually a strategic decision.

So as we were talking about, open source maintainers are a small portion of all the developers on GitHub. But if we make them 10% happier, 10% better at writing open source software, like all of the GitHub community is better off, and then more people want to be on GitHub. So our business model is basically it makes the open source communities much healthier, and much happier with us and makes day on github and so it's like a roundabout way of saying like the way we make money is by supporting the rest of the business um and um so yeah github sponsors by itself loses a lot of money but actually

actually i should not say that it does not lose a lot of money because um because of this really interesting pyramid effect where a very 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 um because the the the balance the ratio of developers on the whole platform to maintainers is really quite high. Well, since you brought the YouTuber analogy again, I 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, you know, like 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 not sure, like, I'm sure that not everything will succeed in the end. And,

you know, they're all very exploratory. Some really great learnings will definitely come out of there. And some of them will succeed. And I don't know which ones they will be. And I'm really excited to be in this space for the next few years. It's going to just change so much. I get how 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. Actually, like, as a quick tangent, like 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. And so like 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 as really as quickly as we possibly can. So that that's a long way of saying that like GitHub sponsors has a lot of stuff we need to nail down right now, just from like 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 want to 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, you know, sign up for sponsors, GitHub sponsors? Or is it, you know, if you're, you know, a software developer, you hang out on GitHub,

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 our conversation, we spoke a lot about how the time was not necessarily right a few years ago, because sort of the understanding of the sustainability and funding problems had not really permeated through software 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. Like 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 like didn't think about where open source came from at all. Like, I was just like, this stuff's

just free and it's there and I just get it. Right. Um, I grew up sort of in that, in, in the era of, uh, you know, it's just everything on the internet is free by default, right? Of course it is. There's no, there's no labor behind this. Um, that is wrong there. Everything, 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 sort of what is the process for creating the software and building an understanding of that stuff. And 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 I think 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 three years, five years from now, how would you measure success? Would it be based on numbers of like how much money's 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 three to five 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 not working on working on this not full time are not important.

That's also key. But sort of back to the conversation we had about context and how we're more focused on high context work versus low context work. The ultimate high context work is when someone is working on something with full-time and really thinking about a problem deeply and pulling together the whole team. I'd say in the like 10 to 15 year range or 20 year range, what I would really like is, is for if you have like three 12 year olds hanging out and one of them's like, I want to be a firefighter. Another one's like,

I want to be a lawyer. I want one of them to say, I want to be an open source developer. I think that should be a really appreciated career path that kids actually aspire to as when they grow up. Whereas now I don't think that any kid, any kid says that they want to 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 YouTuber or Twitch streamer, right? Yeah. That's another extension of the analogy. Okay. Maybe I'm getting more bang for my buck for this analogy than I thought.

Yeah. Yeah. It's pretty spot on for me at least. Yeah. It's, it's sort of like how it's sort of like how, you know, we have full time jobs where people take care of our other infrastructure. We have, you know, train operators who do great work every day, keeping people safe and making sure that the trains run on time. You have people who, you know, go out, construction people who go out and

like fix the roads and the freeways. And like, those are respected jobs that people understand have to get done. Otherwise, our infrastructure will crumble. And I think that it's just still 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 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 like the data set 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 to, you know, an open data set, for example, to learn from this or do some interesting things from it? 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 we, I would love to see GitHub sharing this stuff, including it maybe in like the next Octoverse report or something like that. That's not a guarantee. I'd have to actually ask the person like 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, very cool to share more of this data with the whole community. And I mean, ultimately, this is like the heart of open source, right, is 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 something we should definitely talk about, but we haven't had any detailed conversations yet. Well, Devin, 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, you know, volunteer yourself into this, this job you're into. You, you essentially didn't even ask for it, but you were given it and boom, you've, you're knocking it out. You just, we need somebody passionate about this, this problem to really do a lot of what you said, like to, to be 10, 15 years down the road and look back at this as a successful thing that makes somebody want to say, I want to be an open source maintainer. That's cool. Well, thanks. Thank you, Devin. Thank you. It's been, this has been really fun conversation. All right. Thank you for tuning into this episode of the ChangeLog. Hey, guess what? We have

discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple Podcasts. If you use Overcast,

give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner rollbar our monitoring service and linode our cloud server of choice this episode is hosted

by myself adam stachowiak and jared santo and our music is done by breakmaster cylinder if you want to hear more episodes like this subscribe to our master feed at changelog.com slash master or go into your podcast app and search for changelog master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Bye.