Returning to GitHub to lead Sponsors

So Jessica, I’ve been paying attention, obviously, to what happens in the world of open source, what happens at GitHub, and I saw recently that you went back - you boomeranged - you went back to GitHub. For good reason; GitHub Sponsors has a new person in charge, and that’s you. And so I immediately DM-ed you and said, “Hey, we have to talk. When is it good timing?” Well, I guess today is that good timing. So welcome back to GitHub, and welcome to the first time here on the Changelog. So welcome.

Thank you. It’s great to be here.

Do you listen to this show? Have you been a listener for long?

I have listened to– I do one-off episodes when I see them on Twitter. Podcast-wise, I’m strictly tuned into history. [laughter]

We’re not offended, by any means. Don’t worry.

True crime.

True crime. Hey, that’s a big category.

Oh, true crime. Yeah, I know a lot of people who are into true crime. And so that’s funny - a small tangent to the beginning of the show… My wife was hanging out with friends one day, and she says – they’re like, “What does your husband do?”, because everyone’s telling what their husband does. And my wife is like, “Well, my husband does a nerdy podcast.” And so this one girl was like, “Oh, that’s so cool.” She thought she said, “He does a dirty podcast.” [laughter]

Oh.

So it tells you what that woman was thinking about, and it tells you just generally– so as you may know, I do not do a dirty podcast. I do a nerdy podcast with Jerod, on the Changelog, so that’s a long story short.

She must have been so upset when she found out. So disappointed.

Well, she was asking more questions. She was like, “Hey, tell me about this and that”, and she’s like, “I think you misheard me. I said ‘nerdy’, not ‘dirty’.” And so everyone laughed. That’s the long story short. So true crime and dirty podcasts, apparently, are pretty cool.

Wow.

We’re in the wrong business, Jerod.

On a parallel timeline, Adam, maybe you could have done a dirty podcast, who knows. You’ve got the voice for it.

Hey, there might be another Adam out there doing a dirty podcast. You just never know.

Meanwhile, we’re here to nerd out with Jessica about GitHub Sponsors and such things. First of all, tell us that boomerang story. How did that all play out?

[04:14] Oh, yeah. So I was originally at GitHub way back when. I originally joined in 2013 as a software engineer, and I was there for three and a half years, left just like– was sort of still early in software engineering, wanted to see what else was out there… So then I worked as an engineer for a bit more at a couple other places, I wrote Go for a bit… And then I joined another company, a company called Glitch. I was there for two years and ultimately was engineering director there, also doing product… Everything was under one umbrella there.

But I have tried to stay as much as I can in this space of open source and web friendliness and web approachability. And so when I thought about the shortlist of places where you can do that, I knew that GitHub would always be on that list. And I still have some really, really great friends at GitHub, and so I talked to them. And I have some great friends that were not previously at GitHub, but are at GitHub now, and we just got to talking and seeing about what was going on there, what was available… And that’s how I found out there was this opportunity on the Sponsors team, which was just really perfect for me and what I was looking for at that time. I was specifically looking to focus on product full time, because I had been splitting my time at my previous job, leading eng. and working on product. And so I wanted specifically to work on product full time, so I could really nerd out and feel like I was doing as good of a job as I could do about changing an experience and an ecosystem, hopefully for the better.

Yeah. When you say “on product”, when you define that between engineering and on product - how does that play out to be on product, to focus on product? What do you do to do that?

I guess one of the things they say about product is building the right thing, in the right way. And that’s something I’ve thought about over the course of now being primarily in tech, I guess, since 2012, is that it doesn’t matter how clever your code is or how cool the thing you build is. If people don’t know how to use it, if they don’t know it exists, and if it doesn’t suit them and do the things that they need, then it won’t go anywhere, no matter how cool it is, how much time you spent on it. And so I feel like I saw, over the years, just how important product work is on getting something out in front of people… And the first time I really dipped my toes in that was– the last thing I worked on at GitHub before I originally left was Electron, and starting that team. It was kind of a rogue mission at the time, and I was wearing a lot of hats. My title was still software engineer, but some of the work I was doing on top of software engineering was essentially product work, and I felt like that work was really critical for getting Electron off the ground and building up a community around it. And so it’s that kind of thinking and the importance of that work that has stayed with me and has been something I’ve wanted to get enough time to focus on full time.

[08:03] Gotcha. But do you think you learned by doing when it comes to product management or product leading? Did you read any books in particular? I know when I crossed over from, primarily, a frontender/designer/user experience person into product management, I think it’s a nice parallel transition for anybody, but it’s distinctly different than what you did before… So much so that you have to understand organization, process, hierarchy. There’s a lot of things that feed into that. I’m curious what you did, aside from maybe learn by doing, to prepare for that role.

There was definitely some learn by doing, but I did read a lot. I read a product management book like twice over, and tried a lot of different ways, and talked to friends who were product managers, and that sort of thing.

So way, way back in my career, I was an urban designer, and I think that it’s very related, in that my brain thinks in a systems way, and I’ve always thought about how users experience a system. And so I think my head was kind of always able to work in that way, or already thinking that way, but then going through the motions of doing product management in practice and reading the book and learning the more day-to-day terminology and practices and deliverables and things like that came through doing the work and reading books.

Yeah for me it was, Andy Chen’s “Running Lean” I believe is what it was called, I may have read, and a couple others that were on, like Resilient Management from Lara Hogan, of course… It’s a couple of things around that front that weren’t necessarily products, some leading but also some product, because it had been the first time I’d been back into a leader-ish role, you know? And so there’s a little bit of a step, and you’re helping others do their thing, and helping them exceed and excel, not just yourself, doing what you do every single day, showing up and doing your best. It’s a different responsibility that comes into play. Whether it’s self-elected or not, the responsibility is there.

Yeah.

Interesting. So back in the day then, I would say you were fighting for Electron, from what I understand… So how did that play out then? What was the early days of Electron? There was the term ‘nucleus’ in there. Obviously, Atom’s around now… Help us understand what was then, what was happening then, and then how that shook out in terms of you helping the lead.

Yeah. So way back when, I guess, it was 2016 - I could be off by one year - but at that point, Atom was out, it was launched. It had been in development at GitHub for a couple of years at that point. And the core library that was built in order to build Atom was called Atom Shell. And I had been at GitHub for three years or so almost at that point, I had done a lot of work on dot-com and various other micro sites at GitHub… And I’d always written JavaScript. I’d been really involved with Node and loved JavaScript, and that was not really what I was doing at GitHub. I was doing more for frontend stuff and then a bunch of Node and JavaScript and my open source side projects.

And so moving on to the Atom team was really my best shot at writing more JavaScript at work, so I moved on to that team. But as I on-boarded, I became more aware of how Atom was working, and what enabled it to do what it did. And that’s when I realized that– I felt like Atom Shell was really a game-changer for the whole community of developers - for native app developers and web developers. And so I just became a pest about it. Whenever we had our mini summits and team meetings, I’d bring up, “Well, this needs to happen for Atom Shell, and we should do this.” And I persisted, and then, eventually, I got the go-ahead to spend my full time working on it, because I had presented what I thought should be a roadmap for it, and what needed to be done.

[12:18] And so it started from that in the little roadmap that I’d written, and then eventually I got one more person to scoot over to work on it with me… And then we hired someone, and we were a little team of four for a while, getting Electron to its 1.0. And so yeah, we were this little offshoot of the Atom team, which was an offshoot of the desktop team, which was an offshoot of dot-com. And we were lucky in that way, because we had the distance to do what we wanted to do.

What was it in Atom Shell that made you believe so strongly? What future did you see for developers that made you think, “Okay, Atom Shell should be Electron”? I’m sure, at some point, there was a name announced, or maybe you named it, I don’t know… But there was a roadmap or whatever, and you were like, “Okay.”

It was the team. The team named it. Yeah.

Okay. Give us more of the details there. What did you see, foresight-wise, to put together a roadmap? Obviously, you cared deeply about JavaScript and you wanted to get back into writing that… But what specifically around the tech got you excited about what it provided Atom, the editor?

I mean, it’s what Electron’s known for, right? It’s the ability to use web technology to build desktop apps that are cross-platform, but also specifically, joining that team, I’ve learned the back-story of how they even arrived at the point of writing that library, because there was– oh, my gosh, I’m blanking on the name, but it was a library that Spotify was using at the time, I think, that was mostly Chromium, and pretty bulky… And then there was NWJS at the time… And so it was this sort of goldilocks situation of none of them did– they were in the space and they were getting close, but none of them did exactly the thing that they needed to do in the way that Atom needed it done… And so that was the impetus for building Atom Shell. And so learning more about that history, learning more about that space and what was lacking in that space, and the gap that Atom Shell filled, I just really felt like, “This is not just a dependency we just leave in a stack of 100 repos”, that it should really be its own thing and get a team behind it.

Was it hard to convince people of that?

Initially, I mean, it was. Well, so Atom had been the vision for so long at that time, and so people didn’t necessarily want to take focus off of that. But in the grand scheme of things, no. I mean, maybe I’m pestered enough that I kind of like– [laughter]

Yeah. It’s interesting thinking about that desire to focus on Atom, given the eventual acquisition of Microsoft, and then, obviously, the rise of VS Code. The importance of what a strong editor would be for a developer in the hands of a GitHub platform, for example. So that’s really interesting to think about. It wasn’t Atom in the end, but it was VS Code eventually; it just played out that way. That’s pretty interesting to think about. I just had that thought while you were all talking there.

Built on Electron.

Yeah. Yeah, that’s true, too. That’s interesting too, even the layers there. Something you had said in a previous call we had prepping for this - and correct me if I’m wrong… I put it in quotes because I thought this was a quote… Someone had said in the process of you moving into this role, road-mapping and getting this ability to do full-time on what was Electron or what became Electron, I have in quotes, “There should be an Electron init.” You said no. What’s the back-story there?

Yeah, so what was really important to me when starting out the Electron project was that – at that time, it was still really early, right? This was many years ago. And so really, the only people that knew about it– like, Slack was looking at it at the time, and obviously, Microsoft was looking at it for VS Code… But they were already in that headspace. They were already trying to build a cross-platform desktop app in a better way. And so you had to already have had that problem and then gone digging through the Atom org to be like, “What are they using? How does it work?” And so I felt like one of the first things I needed to do was tell everyone else about Electron, and explain it to people, because it’s not straightforward, right? It was, “What’s it mean that Node and Chrome are in a single runtime? Why does that matter to me? Why does that matter to me as a frontend web developer?”

And so I thought a lot about how I explained Electron, and how I had people onboard into Electron. There’s a lot of rails at GitHub, and rails and in other frameworks. There was init, and I felt like while inits are great for certain things, inits also fill up your directory with folders and files that you don’t end up using and you don’t even know what they’re for. And I felt like it was so important to make Electron as clear as possible, especially for Electron. You can build anything with Electron, right? You can build a menu bar app that just tells you the time or the weather, or you can build Slack, right? There’s a huge gulf between those two. And so I felt like, what kind of init is going– what are we going to recommend to people when they can do any of those things? We’re going to end up giving people a bad experience. And I felt like there’s certain things that need to be left to userland, right?

So there’s so many different ways you can write an Electron app with all of your favorite JavaScript frameworks, and it would be really hard, and a lot of time for us internally to maintain, because I also– this was kicking off Electron. I was sort of resource-conscious of “What can we afford to maintain ourselves while we’re proving this out, and it’s not going to bring us a lot of overhead?” And I felt like the return on creating an Electron init wasn’t there. It would just be massive for us to maintain, especially if we wanted to give people options of frameworks and types of Electron apps to build.

And so instead of going that route, I went for the Electron quick-start app, which just gives you a bare-bones Electron app that opens up the console or the inspector and has one page with some text on it, so that you can very quickly see what Electron’s doing. It’s exposing its skeleton, but also showing you the face, and you can just start building from there. So it’s more of a boilerplate than, I guess, a scaffolding.

[20:00] What would you say if you went back and thought about it – surely, there’s no univariate things in life; there’s multivariates that affect things. But what would you attribute to Electron’s success? Because it was massively successful; maybe not immediately, but like you said early on, large entities were trying to use it. And I mean, it really blew up. Even to this day, here we are - how many years later? Brand new apps are written in Electron every single day. What do you think caused that success?

I mean, I think that there was a need for this, in the way that there’s always a need to simplify your tasks, right? Engineers always want to simplify things, have less to maintain. Electron lets you do more with fewer people, with fewer codebases. And I think it empowers people, too. I think web developers and designers who maybe didn’t think this was within their reach, all of a sudden, they have a new creative outlet. So I think for more experienced teams, it reduces the work and streamlines things. And then I think for more people, it’s a creative outlet and it empowers them to make more.

In particular, recently, I had a conversation with Simon Willison, who is the steward of many open source projects, but one, in particular, is Datasette, as in cassette, but Datasette.

So Python.

Yeah. And Simon, he’s like, “You know what? I’m having problems getting adoption of this idea.” And I think the reason why is because they’ve got to go do all these Python things to get that to Datasette. They’ve got to do so many things that require you to be a software developer, to some degree, on the command line and dev environments, and to some degree, some minutiae stuff that not everybody’s willing to put the work in, that can get the benefit of Datasette.

I’m not sure where the state of it is now. This is a couple of months back I talked to him. But over the weekend, he built an Electron app that was the app for Datasette. And so if it weren’t for what is Electron today and the work you’ve done and this advocacy for all the things we know about really, he would’ve been spinning his wheels on how to create a native app for macOS or for Windows and other platforms. He was able to leverage his existing known abilities, in web or layer on some new ones, because he’s primarily in Python; not so much not aware of building web apps, but just less fluent in them on the daily.

I think that’s super-awesome, where you can give that kind of power to somebody in a weekend, who would otherwise be like, “I’m never going to write a Windows app and macOS app, and this app”, and whatever. There’s just too much to learn that they can now just do Electron and deliver a dataset app… To get adoption in such a critical space, which is open source. That’s the whole point, right? If you’re fledgling, you’re seeking adoption in open source, you’ve got a great idea, you just haven’t been able to put it in somebody’s hands, and that’s the ability to put it in their hands… It’s like, “Here’s the thing. It’s an app”, rather than Python scripts and installs and Python 3 and pip and all these fun things, which a developer knows how to do, but not everybody who can use Datasette will know how to do.

Yeah. Yes. [laughs] I mean, I really nerded out on how to make Electron as comprehensible as possible, which felt like a tricky thing to do, since it was an entirely new concept, too. I mean, I standardize our docs and how we wrote our docs and how there was a single source of truth for docs… And there’s another app I built, the Electron API Demos app, that is meant to just be taken apart. And I thought about folder structure. I drew diagrams of how each file was called, and how it got kicked off… And I tried to challenge myself really in “How can I just keep explaining this better?”

[24:17] So it’s been a long time since you worked on it, but it’s still very successful, very popular. At the same time, Electron has so many haters and complainers about the way it works and what it does… Do those comments, which are still out there– I just recently kind of poked the hive and got stung just by putting out a tweet about the cognitive dissonance between people that complain about Electron, but then also love apps that are built with Electron. And yes, I realize there was not much nuance in that tweet, and you can definitely have multiple opinions, and sometimes we use things despite their underpinnings, whatever… But it was just amazing how many people reacted to that. And so there’s just strong feelings about this thing. First of all, why do you think that is? And secondly, how do you feel, or what do you think when you see those criticisms?

I mean, when the first criticism started coming in, I was like, “We’ve made it.” [laughter]

There you go. “We have haters.”

But, I mean, their criticisms are legit, right? It’d be great if Electron apps were smaller. I wish that were possible. But to me, I’ve always felt like Electron, same as any other software really, is a stepping stone, right? And that’s the thing, I don’t– it’s like, you are completely right to criticize Electron and say the things that you wish were better about Electron… But at the end of the day, it is a stepping stone, and there’s going to be something else. Electron is the thing in between now and the next thing. I mean, I don’t want people to come at me on Twitter. [laughter]

They’re going to. It happens. Let me retort to that, then. Let me retort to that, because we just had 1Password on JS Party, rebroadcasted on the Changelog, because it was just that popular, so a lot of great opinions shared there… Two of the team members from one password sharing why they believe in the web stack… I would say that 1Password does not believe that Electron is a stepping stone. They think it’s their future.

Well, yeah, but – I mean, besides banks in America, who’s banking on using any software for 20 years? How do you define the future?

Yeah. On everyone’s time scale, all the stuff is going away.

There’s a shelf life for everything.

So do you know something we don’t know? Is there an Electron killer being worked on right now in a private GitHub repo, or even a public one?

No, not that I know of.

Okay.

I promise, I don’t know of anything. But that’s what keeps me from getting too worried about things, is I just think that this is the stepping stone. I mean, I think a similar thing happened with jQuery, and people got upset that people were using all of jQuery for one method, and things like that. And jQuery had its time and place. And maybe people feel like it was for too long, or it was for forever… But yeah, it’s like, how long is a company expecting to not rewrite their software for? I mean, I don’t have the answer to that.

I think successful companies are constantly rewriting their software.

Yeah.

[27:52] They’re always reinventing themselves. Sometimes you’re just refactoring, but sometimes you’re piecing whole subsets. Other times you realize this foundation is not sound anymore, here’s a better one. I think when Adam says they say that’s their future, it’s definitely their future to today. Now, do I think that 1Password will be on Electron for five years? Probably. 10 years? Doubt it, but maybe.

That’s what’s weird. It’s like, there’s not really– we do see things pop up like, here’s an Electron-esque thing that solves the memory use, or solves X, Y, or Z bundle size. But in terms of adoption, none of those things are really being adopted yet. So I don’t know how long it’s going to last.

Yeah. And I mean, I do get their thinking too, of why you would want to bet on Electron, because it’s betting on the web, which is a good bet. And so hopefully, it means that when the next thing comes along, it’s maybe easy to move to. Not easy-easy, but…

It’s a good stepping stone. Well, a stepping stone is easy to get to. That’s the whole reason it’s a stepping stone. And I think I want to frame clearly why I said they think it’s their futures, is because they’re not intending to move to something– they don’t have their next stepping stone in sight, based upon our current conversation. Of course, 5, 10 years from now, probably, and maybe not, who knows… But they’re not seeing it as a beta stepping stone, or “We’re going to try this, and maybe it’ll work.” It’s like, “Okay, this is the way right now.”

Well, in terms of Electron, they’re kind of late adopters, right?

Yeah.

I mean, the reason why their adoption made such a big splash is because 1Password is historically a very much native–

In quotes native.

…app to macOS, which moved to Android, and web and all these things. And it was like a reaction to moving away from macOS apps to Electron, which is one of the reasons why it made such a big splash, positive or negative. But in terms of Electron - I mean, it’s been around now. It’s stable. We first did a show in 2017. Jessica, when did this whole thing get started?

I think 2015 might have been first commit to Electron, because it existed before anyone knew about it, before any of the Atom code was public or launched, right?

Yeah.

Well, we first did a show on it in 2017, with Zeke Sikelianos, really a coworker of yours. And in fact, I happened to find he quoted you on that episode of the Changelog. That’s 216. So now that we’re quoting you back to yourself, here’s one. Zeke says, “Actually, my coworker, Jessica L” - see, he kind of anonymized you; I’m assuming that was you… “She described this as ‘This promised land’”. Was that one of your early selling– your taglines?

I love it.

“Electron. This is the promised land.” Do you remember saying that?

I don’t remember saying that. [laughter] I feel like I would say it was a game-changer. That’s what I felt like I kept saying at that time.

Should we go back and edit that quote then?

Maybe you had multiple things you were saying, or maybe you editorialized.

Maybe, yeah.

Well, in true PM fashion though, that’s what you do, you lead and you inspire, right? “This is the promised land. This is the game-changer.” And you want the people working with you to believe in what you believe in. Clearly, you stepped up in those ways to get back into your JavaScript roots, to lead in those ways. And that’s what a PM does, is they lead and inspire. And you did just that.

Yeah, hopefully. [laughs]

Well, it has to feel good, regardless of the haters and the complaints. Like you said, there are legitimate criticisms of Electron. But just the impact the project has had and how many cool apps are built with Electron and how many things have been enabled, that wouldn’t exist otherwise. There’s this false dichotomy - sometimes it’s false - between developer experience and user experience… Sometimes it is related, but oftentimes it’s not, because the developer experience actually is required sometimes to create the user experience. And so you’re not sacrificing user experience, because there wouldn’t be one. A lot of Electron apps mirror– that app would not exist if Electron wasn’t there, because like Adam said, the skills aren’t there, the time isn’t there, I cannot build a cross-platform thing, I don’t have Windows skills, etc. It has to be pretty awesome having built something that so many people benefit from.

It really blows my mind, and I still find out apps I didn’t know were built on Electron were built on Electron, and I’m like, “Wow. Wow.”

So as you said, Jessica, you boomeranged, you went back to GitHub, you talked deeply about that, and now focusing on GitHub Sponsors. I’m curious, having boomeranged, and considering how you can have impact, and considering the deep love you have for Electron, why you didn’t go back to the Electron team. Why did you dovetail and choose Sponsors as your next big thing?

Well, I mean, Electron is just one of the many things I love, and I also love open source, and I care deeply– and it’s almost like what’s a more pressing issue, right? When I was first working on Electron, it felt like a very pressing issue. And then I feel like I’m Mary Poppins-ed to out of there, of like, “Okay, I’ve got Electron to the point where it’s okay and I feel good about its future, and I can go with the wind now.” And so I feel like it’s in a good place, and a place that I feel is a pressing issue that needs attention is open source sustainability. And so to me, it was just a very bright beacon of “This is absolutely something I want to try and contribute to.”

And you mentioned your background in urban planning, which is an interesting crossover with Devon Zuegel whom we had on the show November 2019, talking about the future of GitHub Sponsors. I guess this is the future of the future of GitHub Sponsors.

Back to the future.

Back to the future. There you go, Jerod. Thank you for getting my back there.

Yeah. Sponsors is about two and a half years old now.

Yeah. But you’ve got that crossover of urban planning you mentioned just the– I don’t know if that’s worth mentioning deeply, but I think it’s interesting how both of you come from this background that wasn’t necessarily… You’re obviously a software engineer, and have been, but you originated in this space. That’s just interesting, that both of you have that history, that experience.

Yeah. Was that a pre-req on the job description, was to be an urban planner?

[35:54] [laughs] I know it still seems like a strange coincidence, but also it seems very– it makes a lot of sense. I mean, we’re talking about communities, we’re talking about infrastructure, we’re talking about how idea spread.

Long term, really, right?

Yeah. One of the products I worked on as an urban designer for the city of Boston was like, I was a part of this small team in charge of figuring out how we were going to turn South Boston into an innovation district, because the mayor wanted that. And some of the things – it’s just completely the same, some of the things we talked about, about how to build a place where ideas can spread, and that people feel welcome, and it’s a place where different sizes of companies and ideas and things can fit. There’s just so much overlap in this now, and thinking about the same kind of thing of “How do ideas spread? How do people will work together? How do you onboard someone into a project and a community?” So there’s just massive overlap.

Was that project a success, the South Boston innovation idea the mayor had? Did you see that to fruition? What was the outcome there?

I mean, it is a real thing. I think it’s done well. I meet people who are like, “Oh yeah, I know about the innovation district.” And I’m like, “Yeah, I made that PowerPoint.” [laughter]

Cool. So now GitHub Sponsors, we’re two years in, -ish… We know a lot of people who use GitHub Sponsors. I know one in particular I want to call out, that I pay attention to on YouTube, Jeff Geerling, who we hope to have on a future episode of The Changelog, talking about maybe Raspberry Pi’s and fun Linux hacking and stuff like that… But he’s somebody who’s on YouTube, talking about the Edge cases of Raspberry Pi. He’s someone who I would consider more YouTuber than open sourcer, but he does give so much back in open source.

[38:10] If he does a test suite for how fast the RAID may perform on Raspberry Pi, or how fast the SATA interface works etc, versus SD, all those kind of things - he opens sources those things. And I know that I see him on Twitter all the time screenshotting people saying thank you or whatever, and then giving to his GitHub Sponsors.

So I see the impact there… But beyond that, Jerod and I don’t have a GitHub Sponsors for our org, which is a for-profit business; it feels kind of weird to do that. This is a business that we run here, so it doesn’t feel like that makes sense. While we do also have open source too, but I’m not sure how that fits in for us. So we are not players in the GitHub Sponsors game, so to speak. We’re more of observers. So take us deep into this world. What’s happening? What did Devon put down? What did that team put down that you’ve not picked up? Where are things at currently? And help us shape out where the future might be.

Yeah. So what they laid down was an incredible foundation, and the program is going great. People have changed their lives. They’re able to work on open source full time, which was really the vision, and still is the vision that we’re creating a new economy where open source can be a viable career to people. And so that’s what exists, and it’s working well for lots of people now. We are continuously developing features to help maintainers manage their projects better, intercommunicate with their sponsors more, understand who their sponsors are… But there’s also a big piece to unlock next, which is around sponsorships from companies and corporations… Because individual to individual donations are great, but really, when we’re talking about the long-term sustainability of open source, we have to talk about companies giving back to open source, companies that are making lots of money.

And so we are working on building that infrastructure right now, and that is really important for me as the next phase for Sponsors. And so Devon and the team kicked that off into beta. That program, Sponsors for Companies, has been in beta now, and we are working on getting it out to everyone.

So organizations that have some relationships with GitHub already. Some of that trust factor in place can give a large amount via invoice, things like that. I read the docs. I’m really speaking from the docs standpoint that you have for that.

Yeah, exactly. And so for large companies that have more process around budget, and for who it would be a lot easier to just say, “We want to commit this amount of money, we want to get that approved internally once, and just be invoiced once”, the Sponsors for Companies program is for them, because it’s a higher barrier for them to give back to open source if they’re going to have to go to whatever team approves it, if they’re going to have to do that for every single sponsorship that they want to do. And this way, it works as an open tab almost, as they make their commitment to open source, they get invoiced for it, and then they can work from that, and it’s much easier for them. And the easier it is for them, the more it’s going to benefit maintainers.

It sounds like they access to some sort of dashboard with deeper insights, essentially, which is unclear from the outside, since I’m not that large organization giving this large amount of money, so I can only presume how this dashboard that measures open source contributions and activity across the public projects on github.com that they’re interested in, how that works out. That’s quoted from the docs.

[42:15] What else? I suppose does this go into a bank of trust, so to speak, a GitHub bank of trust kind of thing? Is it in an Escrow or some sort, and you can just like dole it out? Since they want this one invoice, is that what it works out to be? I mean, the point really, is to get large organizations who have a great benefit from open source. It’s really a distribution mechanism to give them a way to give back, which traditionally has been fairly challenging, right? How can I, as an organization who probably desires, if not at the corporate level, at least at the individual level, to give back to open source? How do we give them an easy button to push, basically? And this is step one of making efforts for this easy button to push.

Yes, I am trying to make that easy button for them. And there’s a couple different sides of it, one being just the logistics of “An invoice is better in these situations”, and that kind of thing. So “Okay, we can make an invoice.” But then a lot of it is cultural too, because this is– it feels like the beginning of a sea change, because we have companies coming to us and saying, “We want to give back.” And part of the Sponsors for Companies program also involves a bit of white-glove treatment of “Okay, let’s talk about it, and we will help you. We can talk about different ways to run your internal open source programs, and giving back”, because everyone’s making it up the best they can right now, because there’s not a lot of prior art for how to give back as a company.

Sentry just did a really great blog post a couple of weeks ago, and they really detailed exactly how they thought through what to give back to open source, and not only how much to give back to open source, but exactly which ways to funnel it. And so it s things like that, that we’re starting to see just come out now, where companies are really thinking about this and sharing how they’re thinking about it.

Yeah. Shout out to Chad Whittaker, friend from the past. I missed Chad so much. I can’t wait to see him again or say hello again, and I’m so glad he’s at Sentry. We are big fans of Sentry. Sentry is actually one of our partners and sponsors, and we actually use Sentry every day, and we love the emails we get once a week telling us how little errors or how many errors we get.

How few errors.

Lately it’s been fewer. So that’s a good thing.

A few. Yeah.

Yeah. But shout-out to Chad, this post he had… And this big idea, “Tell the post is we just gave $154,999.89 to open source maintainers”. So that’s a cool title let alone, but I’m glad to see Chad back in the game. I’m excited to see him again, and especially to see him working like this at Sentry. And I know that they have this heart, despite them being BSL and having license change, all these things that happen in open source that happens at the company level, they still have open source, they still are for open source, and this is a way they’re doing that. “How can we give back to our dependencies? The things that should matter to us as Sentry, as our organization, what do we use as open source and how can we give back and sustain that?” So it’s pretty cool to see this drive from the company level coming back to you saying, “How can we give large amounts?”

[45:43] Yeah. And what’s interesting too is how they want to pick projects… Because the no-brainer is, “Back your sack, support your dependencies.” But people also want– and when I say people, I mean corporations and companies… They are also interested in supporting projects they may use in the future, or projects that are from under-represented groups, or projects that are around a theme they care about. And so another thing for us to work on on the Sponsors side is this whole area of discovery, of how do people find out about projects? How do projects get themselves known to people out there who are looking to fund things outside of their dependencies?

Well, you need a social network. I’m not even kidding when I say that.

We definitely have one.

Yeah, I know you do. So that’s the interesting thing. I suppose – I didn’t consider asking you about this, but there’s a lot of… I’ve heard some people talk about, “Okay, people follow me on GitHub. What does that give me as an individual?” And I assume, at some point, there could be this GitHub/LinkedIn effect where you could turn on the social side of GitHub, which really, the original roots was social coding. I follow somebody – and even to this day, aside from littering my activity feed, there’s not a lot that comes from the social aspects that GitHub gave us. So I’m curious if that’s going to play into this distribution. Because when we talked to Devon, she said the biggest thing they were doing with GitHub Sponsors at the time was this is distribution for open source creators and maintainers to put their work out there and gain awareness to be sponsored. “Here’s what I’m doing. Here’s how you can help me do more of it. And here’s what you get in return”, and there’s tiers and there’s things like that.

Then we had a conversation with Ben Johnson. I think I mentioned this to you in our pre-call a few weeks back, but when we were talking to Ben Johnson - Jerod, you probably remember this… He was like, “I want to do more”, because Ben’s thing with Litestream is that it’s open source, but not open to contributions. And that was a provocative thing to say, and so we had him on the show to talk deeply about that… And he still needs support, though. It’s still open source. While he’s not asking the community to give contributions, there’s still opportunities to support, but he has to go outside of GitHub, outside this world, and create brand new avenues, brand new products basically, to exchange value… Which is what products are - I exchange value from me to you, and you give me dollars in return, and I keep doing my thing. And so if we can empower more people like that, like Ben– but you’ve got to have a social network, or turn on the social network. What’s your plans there? It’s a long-winded question, but what’s to come from the socialness of GitHub when it comes to GitHub Sponsors? Speak to us about distribution.

The distribution is sort of solved. I mean, depending on how you define distribution, right?

Kind of. Twitter.

Discovery, I think, is the unsolved piece, because GitHub lets you distribute.

Okay. That’s true. Point taken.

So you need 100 people – if 100 people find your repo, distribution’s handled. But the problem is how do 100 people find your repo? And so I think that’s a really interesting question, and something we are thinking on. We have a great researcher, who’s doing research… I’ve talked to some maintainers about this, and thinking around “How do you say that you’re a healthy project? What does that mean?” And it’s not something you can just pull analytics on. You can’t just count commits and divide by a month, because it’s different for different projects, right? If you’re a project like Astro JS, it’s a flurry of commits, and you’re trying to get to your 1.0, and you’re trying to build interesting features… But if you’re a Babel, you don’t want to disrupt half the internet that relies on you. And so the same metrics don’t apply for health across projects, but GitHub can help surface those things. Right now we have a place where you can see your dependency tree, basically. But I think that that’s the first step, and then we go further and help projects surface themselves.

[50:25] A dependency tree is a great thing for awareness, but it’s not something you come back to, like “Oh, I’ve got to go check on my dependency tree today.” Maybe, I suppose, if you’re excited about the idea of supporting open source, you’re like that. But at some point, the habit loop gets broken, the reward is no longer there. You’re not going to keep coming back to that dependency tree thinking, “Who can I give to today?” It’s got to be a meaningful narrative. It’s got to tell a story, and I think that’s how you get people to get involved. I have this thing I’ve been saying for a while now: facts tell, stories sell. And so what gets people involved, whether it’s literally an exchange of dollars, or, “Hey, Electron’s awesome. Follow me”, and they follow you, it’s the story. It’s Jessica being excited about Electron that got people to follow you and be inspired. And it’s people who tell their story that get that conversion, not just simply, “Here’s the facts. You depend on me. Great.” That’s a fact. The story, what I think, is where we’re missing– and maybe that happens on Twitter. Maybe that happens elsewhere. Maybe it happens on podcasts. Who knows? The story piece is missing. But that may not even be your problem to solve though, right?

Well, at a certain point, the maintainer tells the story, and you do have tools for that. I think what I’ve seen is that software developers are more or less savvy at that aspect. And the more savvy–

At story telling, yeah.

…get the more sponsorship, and the less savvy get the less sponsorships. So that’s a hard problem to solve, but maybe tools supporting the less storytelling-savvy developers to help them tell their story, and to help them show their value proposition or whatever it is.

I know that a lot of the struggle and the conversations I hear maintainers having around GitHub Sponsors is, “How do I present myself, what I do, the value I’m bringing?” And then the tiers is a big thing, because it’s flexible, which is great, but it’s flexible, which is terrible because– I mean, we had Caleb Porzio on the show who’s killing it with GitHub Sponsors. I’m sure you know. He made that famous post about “How I made 100k grand a year”. He’s probably doing double that now, who knows? But he had this brilliant idea about how he actually structures his tiers and how he tells that story not based on buying him two cups of coffee versus three, which is the way that lots of us go, but actually, who you are; like, if you’re a freelancer, if you’re a corporation, and this is what he requires. And that paid huge dividends for him. I’m sure there’s probably somewhere where the people talk and his best practice is, “Hey, go check out Caleb’s and copy that.” But help us understand, Jessica, are there ways of GitHub supporting the maintainers to tell their best story or the best version of themselves?

So we actually have suggested tiers, which is something that I think gets to that… Because when tiers originally came, people didn’t know what to do. And I think there’s a certain degree of, “Well, how much am I worth? How much do I really want to say?” And I’ve gotten feedback from companies that are like, “These people create tiers that go up to $5.” You know, “X, big company - we can’t go give $5.” [laughs]

And so we have suggested tiers now. When you’re on your tiers page, you can get suggestions of how to set them up. We recently shipped welcome messages that help you say something immediately to the people at each tier that have sponsored you. So that’s specifically an area we are trying to build features in, is how to help people represent themselves the best, and how to communicate what they’re doing.

[54:12] Has there been any requests from the– I’m trying to figure out terminology. Would you call these people all maintainers? I suppose so. Let’s just call them maintainers to make it easy. So would you say that the maintainers who have sponsored pages, so it’s their profile/sponsor - is that what the URL is? Yeah. No, it’s github.com/sponsors, pluralized, slash their username. So in this case, have you gotten any requests where, “You know what? I love my profile. I love showing off what I do in open source. Can I just make my sponsors page my profile?”, for example. “Can I tell my story there? Can I put updates and stuff like that there?” rather than this static page that really –

Cool idea.

…is just pretty static, you know what I mean?

We have heard that and thought about that. It’s rattling around there. Yeah.

Okay.

May or may not be shipping soon

Yeah. And people have definitely run out of space on their Sponsors profile page.

I mean, because some people - that’s actually their purpose to be on GitHub. It’s great that they show their contribution, and that’s all part of their story too, but the reason why they are using GitHub as a platform is, one, they’re probably passionate about open source. Clearly, they’re passionate about software in some way, shape or form. But three, their motivation is financially sustaining themselves or their processes and their daily objectives and the things they do, to create and give. I would imagine that that’s the case. So we have a friend, Mat Ryer, who works with us on Go Time. Since you write Go, you may know Mat Ryer.

For one year I wrote Go. [laughs]

That’s enough. That’s enough. I like his profile for his sponsor page, because he goes $2, $4, $8, $16, $32, $64, $128, $256, $512, and $1,012 in terms of his tiers. And they’re in typical Mat–

And they’re ridiculous, aren’t they?

Well, they’re just like tip of the hat, and then I think $64 a month is a couple of pizzas, one hot, one cold for breakfast the next day… It’s just typical Mat humor, right?

[56:18] One was like two tips of the hat, or one tip of two hats.

That’s right.

Yeah. The ridiculous things that Mat’s personality

My favorite is the most expensive one, though. $1,024 a month is “A bit creepy now.”

[laughs] A bit creepy now.

So I love that you get this opportunity to share who you are. If you don’t know Mat, you can probably read this page, or at least read the tiers, and get a bit of Mat’s humor. And then you hear him on Go Time, or then you meet him in person, you hear a talk, you meet him in the hallway at a conference whenever there’s hallway conference track again, or maybe virtually, at a virtual conference, if that’s still a thing happening… But the point is, you give people this opportunity, but it kind of stops there.

Yeah.

That next step might be not just unlocking these corporate dollars, but enabling these maintainers to share their story.

Yeah. And I think that’s what we are in the position to do, uniquely. We are where the code is and where the developers are, and so I think that is our task to do.

Nice.

And to also expand it to more developers, because that’s part of the other big thing that we need to do. We need to enable companies to participate in Sponsors, and then we need Sponsors to go to more people.

So 36 regions currently. I’m not sure if that defines countries or simply regions. You may know more about that; but if that is countries, it’s up six from when we had Devon on, which was a few years back. So clarify that for me. Is that regions or countries? Do you know? Does it matter?

I believe it’s countries.

Okay.

But, yeah. So we are working on rolling out to more countries, and that’s a priority. And so that’s in the works.

Are you involved in that process currently? What’s the challenge, I’d say, from that expansion? Because if you’re trying reach more developers, that’s how you do it - you reach more and farther reaches of the world, where this provides an economic opportunity.

Yeah. Internally, we need more infrastructure on our team to support being that large of a program, basically. So we need more technical infrastructure… And there’s also legal things. I’m in lots of meetings with legal and trading compliance and tax. And then there’s also that we’re built on Stripe right now, and so we’re also limited to where Stripe works.

Where they operate. Yeah.

Gotcha. You mentioned you have a researcher, which you were quite excited about.

Yes.

That must be helpful when it comes to going to these meetings, to say, “Okay, we’ve done the research, we’ve got this data, we’ve pulled this back. Here’s where we need to go next.” Legal may reach out and say, “Okay. Here’s the limitations there”, whatever it might be. But I’m speaking to specifically the help that it might give you when going into these meetings and fighting these battles - if they are, in fact, battles - to have that research-led process in your hand.

They are not battles. We have an amazing researcher and a team that values research. So it’s a part of every decision we make, really. And we work together nearly every day.

So when it comes to financial sustainability of open source, to me it seemed like Sponsors might just be one rung on a multi-rung wheel or– I forget the analogy, but it seems like there’s more than one way to do it. And businesses struggle with this, like picking a model that makes sense for them; there’s these different models - open core, hosting, licensing, support, all these different ways you can do it. And Sponsors, it seems like when it comes to open source individuals and even orgs or groups, it seems like very much just some sort of relationship with a donation attached. But there are other ways of value transfer. Have you considered expanding Sponsors’ reach into bug bounties, some sort of a marketplace…? Other ways that aren’t merely, “Please give me money on a–

Support me.

…one time or a recurring basis”?

Yeah, yeah. The bounty is a research item coming up. And we did some initial research a month or so ago, and bounties was just part of it, so we really only scratched the surface on it… Because there’s just so many levels to bounties to figure out how to do right. So it’s like, who decides it’s the right solution? Whose solution gets picked? And so there’s lots of tricky elements to it to do it well. But that is something we’re thinking about and doing research around. Something else that’s interesting to me is– and you mentioned Caleb earlier… I know Caleb makes enough money.

[01:04:42.24] Sponsorware.

…well, to pay other people that contribute. And so I can imagine that, in this world where open source is sustained, like “Okay, what do projects do with their surplus? How do they start bringing people on to projects? How do they start using that sponsor money to give to the people helping out?” Because – I mean, obviously, it’s different. You mentioned the person earlier who’s not taking any contributions, but certainly, there are a ton of projects that are maintained by a small core, or one person, but still get really valuable contributions. And how can they reward those people?

Well, one thing that Ben might do though - and I’m speaking for him, not simply something he has said - is Litestream may… So I know I reached out with support for ARM64 on Raspberry Pi, because I was using Litestream with SQLite doing something, I was tinkering with it, and at the time I couldn’t install it, so it wasn’t supported… Through Sponsors though, he may be like, “Hey, if you want me to support this platform, this new M1 chip, or whatever it might be, the next big thing from X, Y, Z”, maybe it’s something where there’s a tier that gets that to there.

So these are unique ways that isn’t simply like, in Mat’s fun regard, “Get me some pizzas. Get me some coffee”, or “Get a little creepy”, depending upon how deep pockets you’ve got. It’s a way for them to essentially define products to a community.

Yeah. So we have one-time tiers – there’s recurring tiers, and then one-time tiers. And you could get really creative with your one-time tiers and say, “Okay, it’s a $100 one time and you get office hours for an hour with me.” And one of the things we’ve been thinking about is around having a tier with a cap on it, so that you can say, “Okay, I’m going to do office hours, but obviously, time is finite, and so I’m going to put a cap on this tier. Only 10 people can sponsor this tier.”

One of the things that’s interesting to us is this idea of primitives on GitHub, of not being super prescriptive, and building the tool in just the right way that people can use it in five other ways, right? So how can people use a repository, right? Sometimes a repositories is just the “Ask me questions”, sometimes it’s actually code, sometimes you’re just using the discussions feature, and things like that. And so that’s something that we think about a lot, and I think tiers are a place where we can create a primitive like that, that people can use. And Caleb ran a one-day conference using a GitHub Sponsors profile, which I think is another great example.

Very inventive, yeah.

Yeah, of how can the tools be flexible enough that people can get really creative to make it work for them?

In terms of technical issues, or the challenges faced - all this is on github.com. Do you face any pushback, technically, with maybe GitHub Sponsors needs to be its own micro site kind of thing? Is it all fine being in dot-com?

[01:08:15.22] Oh, it’s all fine in being dot-com. I mean, I’m not on engineering anymore, but I do see our engineers every day, and it seems like– I mean, there’s a system. I mean, there’s just so many parts of GitHub now. Everyone’s pull requests are against the main repo, and that’s just how it works.

Yeah. We talked to Cory Wilkerson about Codespaces recently, and he talked about the massive push, obviously, that Codespaces was, and that 800 of the 1,000 engineers at GitHub are on dot-com, so they’re all on Codespaces. So all dot-com developers, or that commit to dot-com, are using Codespaces. So that’s a massive technical pool of people to– sure, they don’t all get to work for GitHub Sponsors or do work there, but it’s a massive pool to pull from when it comes to talent inside GitHub to potentially leverage for moving this initiative forward.

I mean, we’re talking about Codespaces. I think it’s great for me as a PM who knows how to code, because she was an engineer. The situation where you don’t have to get dev working locally for the first time in two months, and it’s not going to work, and it’s going to take a whole day to do - I think it’s fantastic that I can just use Codespaces.

Yeah. When I mentioned Codespace, I was really meaning just how many get to commit to dot-com.

Oh, right. Yeah.

I mean, the massive technical talent that you have committing to that dot-com space; not that GitHub Sponsors is so unique and so uniquely different that it can remain in the space. My concern is maybe if you get socially or networky or whatever -y you want to attach to it with, whatever Sponsors becomes as it grows, does it always fit in the dot-com app space?

I think it does, because I think it’s an extension of the code and the project, and that they’re so closely tied.

Yeah. What do you think would give it its advantage, Adam, to pull it out?

I don’t know. I just wonder if you have– I’m assuming maybe at some point there is some networky stuff. Like if you have a destination, does it make sense to have that feed or activity space you got to be three segments deep, for example? Is it somebody’s profile? Do I now have my own personal destination to go to? It gets weird where the main thing you go to GitHub potentially for is like three segments deep, or a couple clicks deep. And then it becomes like, “Well, this really is an app of its own at some point.” I’m just curious if– sure, we’re in the early innings still yet, despite us being two years into the story. I’m just wondering if that’s ever going to be a challenge, from what you see currently in the forefront?

Not from what I see right now.

Is there API access? Because it seems like that would be something that an enterprising team could go ahead and just build their own thing around Sponsors API.

Yes. Yes, There is.

So that might be a route to that for the people who are really wanting to elevate it on their own little piece of the web.

But I mean, it’ll be interesting to see how it grows, and if there is– I mean, part of it we’re shipping to learn, right?

That’s a good problem to have.

Yeah. We want get stuff out there and see what problems people are having.

[01:11:42.07] Yeah. So when it comes to, I suppose, the ideas of open source getting funded and what’s involved in that– in our other conversation we had preparing for this, we’d posed this question; at least you did, and I agree with it, so I’m going to assume some of the ownership of this question… You know, what happens to open source once it’s funded? What changes? What dynamics change? How do maintainers’ lives change? As theoretical small business owners, basically, at that point, how do lives change once we have enough funding in the pool?

Yeah. I think that’s super-interesting, because I feel like if we do the stuff we’re doing right now, which– I mean, we’re doing a lot of different things. We’re still building features, but obviously, the Sponsors for Companies, and expanding - if all of that goes well, which it should, then we create this new world where open source is sustainable. And so what’s that future look like? Because we haven’t been there before. We haven’t had to answer that question.

I think that there will be a few different things that shake out, that not everybody will want to become a small business owner… Which is one obvious path of, “Great. I’ve started earning enough money from Sponsors that I can hire people, and host an event”, and whatnot. Some people are going to want that, but not everybody. Some people are going to want to stay, solo developer, making all the decisions themselves, and just being able to do it, and have that as their job. And then there’s going to be projects like Babel, and Homebrew, that are just core internet infrastructure, that just need to be maintained. And then projects like Astro JS, that are trying to be the next generation of software that the internet depends on. And then there’s people who want to contribute to those projects. What if you can be an open source contributor and make a living that way?

Yeah. We had a conversation recently with Robby Russell from Oh My Zsh. And like you mentioned, Homebrew– and I don’t disagree that Babel and Homebrew are core internet to the world. I would wager that Oh My Zsh is at least core to me, because I just got a new Mac, and one of the first things I did once I got to Terminal was– the very first thing I actually did was Homebrew, and then the second thing I did was Oh My Zsh. And so the reason I bring that up is because we actually had this conversation with Robby, just reminding him what an equity that lies within the Oh My Zsh codebase an opportunity for the community – because to me, it’s like a must-install. And imagine that’s the case–

And it doesn’t show up in your dependency tree.

Right. And so the distribution and the awareness is so somewhat challenging, but there’s so much to give and so much to do there, and he’s finding it challenging how to make some of these sustainable aspects of it happen. But I think that there’s an opportunity there to attract people like Robby, who aren’t in the dependency tree, maybe personal dependency tree. Maybe I can go into– maybe I do a Homebrew list for example instead, and find my dependency as a dev environment to give to.

But I think for Robby, hearing this conversation with you now, I wish I’d known some of what we’ve been talking about then, because I would’ve suggested more deeply like, “Okay, cool stuff is happening with the GitHub Sponsors, thanks to Jessica, the researcher and the team behind this thing”, because that’s the kind of person I think would be a great candidate for taking what is just a fun project for more than 10 years, very impactful, but how do you go and create a surplus of cash or value in a community? Because I love it, I’ll give to it. I’m sure Jerod would– he’s going to be an a Zsh convert soon. He’s leaving Bash. He’s leaving Bash. How do we then direct those dollars to Oh My Zsh, for example? And I think GitHub Sponsors is the best conduit to do that, because it’s on the platform already.

[01:15:55.01] Yeah, exactly. And there are things we’re doing to– sort of calling them gentle nudges to remind people that the project they’re looking at is sponsorable. So we just shipped a new issues nudge. So if you’re sponsorable, there’s always been a thing at the top menu bar saying “Sponsor”, but it’s very easy to not ever look at that. So now it’s below the issue you’re reading or creating, on the project, that says, “Hey, this project is sponsorable. We support the projects you use and can care about.” Because some of it is discovery, sure; like, how do we surface these projects that aren’t in the dependency tree, but that everyone relies on, or should rely on? And then some of it is an exposure and a normalization. So one of the other thing we’re doing is, “Do you know there can be first-time maintainer, or author in the actual issue box or comment box itself?”, adding Sponsor to just normalize it and put it out there that people are giving to this project. This project is one that people see fit or worthy to sponsor, and hoping that all of this helps in small ways to normalize this and surface it.

So let me see if I understand you correctly. If I comment on an issue - let’s say it’s Homebrew, and I’m sponsoring Homebrew, and I open an issue. Whenever I comment or on my issue, next to my avatar or whatever, it’s going to say “Sponsor”, where it would’ve said first-time contributor? Is that what you’re talking about? It’s going to say that I’m a sponsor for this project?

Yeah.

That’s so great.

That’s cool, because that actually gives me a little bit of clout, or something. When I’m opening an issue, it’s like, I’m not just a nobody, I’m somebody who’s supporting you.

And it also helps maintainers. From the research we’ve done and the meetings we’ve had with them, issues is a fire hose.

Right. Prioritize.

Even just the smallest visual cue to help them sort through the backlog.

Aren’t there some folks who are saying you can’t open an issue unless you’re a sponsor? Is that a thing, or they’re building that themselves?

So that’s a thing, and we did research on that. It’s not a thing. You can turn off issues completely. That’s been around for a while. And we did research around that, and the trick is that some contributions are good. [laughs] Some are bug reports, some are your friends, and so it gets really messy of like, “Well, I want not random people to open an issue, but I still want my friends to be able to open an issue, too. I don’t want my friends have to sponsor me.” And to me, it felt like we need to get down to what the actual problem is. The problem is not necessarily you should have to pay to open an issue, it’s that issues are unmanageable. And so how do we solve that in a different way than solving it through sponsors.

And I think another piece there is we have to think deeply about what we do, because we can change open source. If making issues something you have to pay for - does that make open source pay to play? How does that change the landscape of things? Some of these are big questions.

[01:19:35.28] I think if I were you, what I would err on is the side of giving the maintainer control; control of their output and their interaction with the community they desire to cultivate. I don’t think you would– you may change the mechanics of open source, but not change open source at large. I know you’re not saying that, but to be clear, I would say you’re changing the mechanics of how you can interact with a maintainer who maintains an open source project, not open source at large. And I think that open source doesn’t change because you do that. I think if a maintainer felt it was in their best interest of their project, which is open source, and a permissive license, and totally usable by the incumbent cloud providers to squash them if they want, or whatever it might be… If it’s open source and they desire to cultivate a community that says, “If you want to take my time away and chip away at my inbox, then you’ve got to pay to be here.” And if they legitimize that, then that’s on them. And it may be the community that pushes back and says, “Well, you’re wrong. You shouldn’t do that.” And then that’s the community putting them in or out of bound, so to speak. But I think if GitHub can err on the side of giving the right tools to maintainers to do what they want do, in the best interest of open source and their desired inputs and outputs to open source, you’re going to be on the right side of the ball.

Yeah. I think you’re right, too, that it wouldn’t be for everybody. That was something we went through in the research, was also like if this ends up being a feature that only three projects realistically ever think they would turn on, do we build it for those three projects? And so there’s lots of levels to it.

Then there was also the question of, “Well, okay, if an issue costs $5, it doesn’t lost $5 of my time to answer this.” There’s a whole range of things. So it turned into a pretty meaty– I don’t know, meaty is not the right word… But a pretty gnarly topic. And so we have our research, everything is still clanking around in our heads and the thing we did as more obvious solutions were that nudge on issues to sponsor, and then trying to surface that people are sponsors and that you’re in a sponsorable repo in more places.

Yeah. I think another way to put it is that you’re playing with rather large levers, right? You’re highly leveraged because of the position and the platform that you’re in. And so every change must be considered and reconsidered, because once you put it out there – like, what if that feature went GitHub viral and every maintainer is just like, “Sweet. Pay me to open an issue”? Because honestly, why wouldn’t you turn that on? You do change open source. I mean, sure, it was the community that chose that, but sometimes it’s hard to push that lever back in the other position. That’s taken away

And then people were still like, “But I don’t want my friends to have to pay to open an issue.”

Right.

Right. Now you have a list of people…

So then you need a list of friends on GitHub. [laughs]

Hey, it’s a social network. So it does seem like people– was that a feature that existed and got taken away, or are people implementing it themselves? Because I didn’t hear that through you. I think I’ve seen people actually doing this. And so they’re implementing it either via APIs, things that they’ve coded up, or GitHub Actions. Or maybe it’s just normative inside their little communities. That whole thing, “Pay me to open an issue”, people are doing that. Maybe it’s just one and they made a lot of noise. So one of the things is like the cow paths thing; are you watching what people are trying to do and saying “Okay, here’s where they’re bumping up against the edges and we’re limiting them and maybe we’ll implement those things”?

Yeah. Definitely, we’re looking at what people are basically already doing themselves, but through much effort, like sponsorware basically, and basically having to auth people into things themselves, and maintain lists of who their sponsors are. And so yes, definitely the cow path and listening to what people are already doing in a very painful way.

[01:24:03.01] Well, I feel like I’m talking to a couple product people, because we opened up this big future-looking thing, and then immediately - I’ll just say the two of you; I joined you, but we jumped right back into the product roadmap of GitHub Sponsors, and kind of bike-shedding feature by feature. It is fun to do, but we never really opened up very well this question of what it looks. Jessica, you said what you think it looks like, to a certain degree. There’s some people that will want to be entrepreneurial, and there’s others that will want to not be so. We’re already starting to see the future being here, but not already evenly distributed, because I’m looking at OpenSSL’s page, and they have 52 sponsors, and there’s 18 people. And we know how critical OpenSSL is. I mean, we’ve already embarrassed Caleb Porzio enough, that I’m sure he won’t mind me mentioning he has 1,182 sponsors, and he’s one person. And OpenSSL has 52 sponsors. And so there’s already a little bit of that, where it’s like there’s going be haves and have-nots in this future, I think. But if there’s enough money to go around, maybe that’s mitigated, to a certain degree, the extent that that affects people’s lives.

I think in theory, the money is there. It’s not being distributed right now.

Well, in your hypothetical it’s there, right? And that’s what we’re talking about, right?

Yeah, sorry. In the hypothetical, it’s there. And I think Caleb has found success, and he is another persona, which is someone who’s a content creator, which not everyone’s going to want to do. But some people are going to want to create tutorials and videos and courses and things like that. And I think that’s something– to me, that makes sense for maybe finding success early on, is being a content creator. But it’s one of the ways to make money in open source.

I think like any economics, if you want it to work well for you, you have to work it. You know what I mean?

Yeah.

If you want to work the economics, OpenSSL– someone has the same opportunity as Caleb, right?

I’m not saying they don’t, I’m just saying the facts of the circumstances.

Right. Right. Then I think–

But he’s killing it, and they’re not. No offense, OpenSSL. 52 is nothing to balk at

Right. So then it comes down to, “Is that GitHub Sponsors’ role to play?”

Well, I think to some degree. Yeah.

…to enable the distribution better, to more evenly distribute something so critical, potentially.

Discovery. Discovery.

Or just make a bigger pot of money so that the smaller side is still good enough maybe. But yeah, discovery is part of it.

Yeah, because how many people don’t know how important OpenSSL is to their lives, versus they see tweets and courses…

Every time a heart bleeds, OpenSSL gets a sponsor. [laughter] It’s been too long since Heartbleed. Probably, a lot of us don’t even remember it now.

Yeah.

We do need to be reminded about that. And that’s– yeah, I don’t know.

Well, here’s kind of a cynical look at the future, if there’s all this money flowing around… What I see is a lot more people probably bringing low-value stuff and trying to game the system and get their grabby hands on money without making awesome software. I mean, there’s going to be a lot more noise. There’s already more noise in open source than there ever has been. And by noise, I just mean people doing things and saying things, and– I don’t know. If we saw a graph of repos created per day over the last decade, Jessica, would probably be like a hockey stick, right?

Yeah.

Yes, yes.

So that’s one thing that we will have to deal with. When there’s gold in ‘em hills, there’s gold diggers trying to get the gold out. And so maybe a potential downside of having this great future, which we all want, where financial requirements for open source community are taken care of, is more people will pour in that aren’t necessarily providing value. And that’s probably going to be one of your challenges down the road, is not letting them game GitHub Sponsors.

Yeah. I mean, we have people who look for people gaming the system. [laughs]

They’re already gaming it. Don’t tell us what the games are, because I know that people will imitate that game.

I won’t. Yeah, no games.

[01:28:07.06] This kind of goes back a little bit, but I’m curious what the overlap might be, going back to Sponsors for Companies… Because if we’re talking about where the money comes from, there’s a lot of money from individual donors, like Jerod or I or you, or others listening to this show, giving to their favorite projects… But the large dollars that really provide the long-term sustainability is when corporations realize the value of open source and find meaningful, valuable ways to give back, which is obviously part of what you’re doing here. I’m curious what the overlap is of those organizations that are involved in the beta of Sponsors for Companies and advocating for giving that large check or that easy button to push - what the overlap is of those in comparison to those that have an open source programs office. Because that’s a sign of maturity in the company space. If you’ve gone the route of identifying an open source programs office for yourself or for your company, whether it’s large or small, whether you’re Google or a brand new startup, what the overlap is to the Sponsors for Companies and those who have OSPOS.

So right now it’s not– I mean, I don’t think it’s even half. But I think that’s one of the things that will change, because a lot of companies just don’t know how to do this right now. And the more companies who are doing it and we can share their stories - which is another thing I want to do, is just get as many stories as I can about how companies are running this internally… But alongside, also how developers have been successful. Sharing the stories so that people– it’s a part of that easy button, because I think some places just want to say, “I’ll just do what they do. Let’s just do that.” But it’s very different right now, because, like I said, I think this is the cusp of everything. And so sometimes the budget is coming from the marketing team, because they see this as marketing.

Call it what it is, Jessica. [laughter] Nothing wrong with that. Hey, marketing is great. People need to hear more stories. That’s what marketing is. It’s not selling, its stories.

I think it’s a great story to market, to say we think open source is important to give to, and to be shown to be giving to. So yeah, I think it’s a great story. So sometimes it’s coming from that budget at the company, sometimes it’s coming from the engineering budget, and sometimes that company has an open source program internally. And sometimes they don’t have an official program, they have an official person… And so it’s all over the place right now. But I talk to all of these people and I think that it will start to normalize more. And part of what they ask me is, “Well, what are other people doing? What should we do?”

Right. Social proof. “I don’t want to make a mistake. What did somebody else do?”

Yeah, exactly.

“Did that person like that shirt? I don’t like that shirt, too?” It’s the same kind of concept. “What are you buying? I want to buy it, too.

Yeah.

“Did you get the Max? Did you get the Pro? Did you max out the ram?” Whatever. You want to know what your buddies did, essentially your peers do

Yeah. And they don’t want to come out looking bad, of like “Oh, we didn’t give enough.”

Right. Capital One puts in 50 grand. They look over, Microsoft put in 100 grand, and they’re like, “Oh, man, we’ve got to put in twice as much.”

Yeah, exactly.

That’s a good problem too, though. I think–

Exactly.

[01:31:43.08] …any amount is a good amount. And sure, you can always increase it if it needs to be. And I would even say, maybe– I don’t want to carte blanche put this out, but if a company decides to give even a small amount, it’s a good start. And it’s a good start – even if it’s not enough, don’t bash or call them out about it. Encourage them about their other needs and whatnot, if that’s the case, and normalize just giving from a corporate level… Because the conduit - how to get the money from procurement to the hands of would-be creators, maintainers, content creators, whomever is leveraging GitHub Sponsors for the good of open source? That’s the challenge. How do we decrease that friction?

Yeah, because sometimes it takes companies months. And by months, I mean eight months.

Too long. Too long. So long that the person who initiated it doesn’t work there anymore. They’ve moved on. “Well, where does this money go?” “I don’t know…”

Yeah. So if we go all the way back again, actually, to me rejoining GitHub at this time, and with Sponsors, part of it was because I was very interested in open source sustainability and being a part of that future… But also part of it was knowing that GitHub and GitHub with Microsoft’s backing is in a great position to solve this, and to do this well… Because it’s a big issue, and there’s a lot of moving parts. There are the taxes of every single country in the world, and things like that. And so we have the resources, and it makes me excited to be in this position. We are really trying to make this change, we are in the position to make this change happen, and we’re working with these companies in a way that we are able to do at our skill, and that’s really exciting.

Maybe paint a picture of the horizon. What’s something less known or not very well known? Maybe not so much secret where this is the first time you’re sharing it, but what’s to come? Give us the next few months or next big things that are coming from it that you can share. And if you can’t share everything, just do your best to tease. What’s coming?

Well, definitely the next big, big things are Sponsors for Companies going GA, and then expanding to more countries. But then also new ways, new primitives for developers to create content for their sponsors.

Oh, boy. Okay. Dun-dun-da… Alright, cool. So we tease a little bit of that in our desires, so hopefully, some of those come to fruition, to some degree.

Yeah.

Cool. Okay. And if you have the ear, let’s say, of both developers and would-be companies to get involved in the GA of Sponsors for Companies, if you had the ear, if you haven’t already had the ear of them this whole entire podcast, give us something to tail off on. Give us that Jessica inspiration that gets us involved, that joins the fight, that joins the triumph, however terminology you want to use. What is the next thing that can get people excited about developers getting involved in Sponsors if they’re not already involved, maintainers getting involved, and then the companies? What’s the most exciting thing for these people to get involved? What’s the next step for them?

Oh, my gosh, one message that tailors to all of those different people…

Or both. Or both.

Well, this is the future. I mean, I honestly believe that, that this is the future; that open source in five years is going to be different than it is today… And it’s going to be different because of what is happening right now, with the changes we’re making to GitHub Sponsors, with companies realizing that they need to give back to open source. This is the beginning of the change, and I really do believe that five years from now we will think of open source completely differently than we do today.

What was that quote, Jerod, from Zeke, that he had said? Can we just layer that back in?

The promised land. [laughter]

This is the promised land, y’all.

It’s the promised land!

It’s the promised land. Get on board. And I really do think it is. I’m excited that– this is why I wanted to have this conversation. I think it’s great that you creating an easy button for $100,000 at one single time to go into the open source bucket. That is phenomenal. And to do that at large, with the size and scale of GitHub - phenomenal. And to give open source maintainers, developers, content creators, whomever is contributing to the commons that is open source, that will power the future of our humanity, to give them the opportunity to call their own shots, with their own creations, create their own communities, and come to the table and play in a way they want to play - that’s awesome. And so I’m so glad you came to share that story with us. I’m so glad you’ve boomeranged back to GitHub to get involved in this. So thank you so much for sharing all that with us here today, and thank you for being a friend and coming back to the show. Thank you.

Thank you so much for having me.