The Changelog: Software Development, Open Source - Returning to GitHub to lead Sponsors (Interview)

Episode Date: December 2, 2021

Today we're joined by Jessica Lord, talking about the origins of Electron and her boomerang back to GitHub to lead GitHub Sponsors. We cover the early days of Electron before Electron was Electron, how she advocated to turn it into a product and make it a framework, how it's used today, why she boomeranged back to GitHub to lead Sponsors, what's next in funding open source creators, and we attempt to answer the question "what happens to open source once it's funded?"

All right, welcome back. This is the Change Law. We feature the hackers, the leaders, and the innovators of the software world. On today's show, we're joined by Jessica Lord, talking about the origins of Electron and her boomerang back to GitHub to lead GitHub sponsors. We cover the early days of Electron before Electron was Electron, how Jessica advocated a trend to a product and make it a framework, how it's used today, why she boomeranged back to GitHub to lead sponsors,

what's next in funding open source creators, and we attempt to answer the question, what happens to open source once it's funded? Big thanks to our partners, Linode, Fastly, and LaunchDarkly. We love Linode. They keep it fast and they keep it simple. Check them out and get $100,000 credit at leno.com. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags, Powered by LaunchDarkly.

Get a demo at launchdarkly.com. This episode is brought to you by Influx Data, the makers of InfluxDB, a time series platform for building and operating time series applications. and monitoring software. It's purpose-built to handle massive volumes and countless sources of timestamped data produced by sensors, applications, and infrastructure. Learn about the wide range of use cases of InfluxDB at influxdata.com slash solutions, network monitoring, IoT monitoring, infrastructure and application monitoring. To get started, head to influxdata.com slash changelog and click get InfluxDB. Again, that's influxdata.com slash changelog and click Get InfluxDB.

Again, that's influxdata.com slash changelog. 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 leading the charge and that's you. And so I immediately DM'd you and said, hey, we have to talk when it's good timing. And 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 the show? have you been a listener for long i have listened to i do one off episodes when i see them on twitter i'm podcast wise i'm strictly a tutor history

we're not offended by any means don't worry crime hey that's a big category oh true crime yeah i know a lot of people into true crime and so that that's funny. A small tangent to the beginning of the show. My wife was hanging out with friends one day and she says, 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 she does a dirty podcast. Oh.

So it tells you what that one 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 Jared. She must have been so upset when she found out. Well, she was asking more questions. She was like, hey, you know, 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 podcast apparently are pretty cool. We're in the wrong business, Jared. On a parallel timeline, Adam, maybe you could have done a dirty podcast. Who knows? Hey, you know, there might be another Adam out there doing 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 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 sort of just like was still early in software engineering, wanted to see what else was out there. And so then worked as an engineer for a bit more at a couple other places. I wrote Go 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. And I was there

for two years and ultimately was like engineering director there, sort of also doing product and everything was sort of 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 short list 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 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. And I was specifically looking to focus on product full time because I'd been sort of splitting my time at my previous job doing, you know, leading Inge 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 like focus on product? Like, what do you do to do that? So I, I focus on, 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 like 2012, is that it doesn't matter how clever your code is, or how cool the thing you built is, if people don't know how to use it, if they don't know it exists, and if it doesn't, you know, 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 sort of dipped my toes in that was the last thing I worked on at GitHub before I originally left was Electron and starting that team. And it was very, it was kind of a rogue mission at the time.

And I was wearing a lot of hats and 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. Gotcha. Did 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 front-ender,

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 like 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. And I think 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 and practice and reading the book and learning sort of the more day-to-day terminology and practices and deliverables and things like that came through doing the work and reading books. For me, it was like 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 laura hogan of course and yeah a couple of things around that front that weren't necessarily like 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 there's a 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 you know doing what you do every single day showing up and doing your best you know it's a different responsibility that comes into play whether it's self-elected or not you know it's it just 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 how did did, what was the early days of Electron? There was the term nucleus in there. It's a term, obviously, atoms around now. Help us understand, like, what was then, what was happening then, and then how that shook out in terms of you helping to lead.

Yeah. So way back when, I guess it was 2016. Could be off by one year. But at that point, Adam 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.com and various other micro sites at GitHub for three years or so, almost at that point. I had done a lot of work on.com and various other like microsites at GitHub. And I've always written JavaScript. I've been really involved with Node and love JavaScript. And that was not really what I was doing at GitHub. I was doing more

front-end stuff and then a bunch of Node and JavaScript and my like 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 onboarded, 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 sort of became a pest about it. Whenever we had our mini summits and team meetings, I'd bring up, well, this needs to happen for Adam 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'd sort of presented what I thought should be a roadmap for it and what needed to be done. And so it started from that in the little roadmap that I'd written. And then eventually I got like 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 we, yeah, we were this little offshoot of the Atom team, which was an offshoot of like the desktop team, which was an offshoot of the desktop team, which was an offshoot of.com.

And we were lucky in that way because we had the distance to kind of do what we wanted to do. What was it in Atom Shell that made you believe so strongly? What technologically, what future did you see for developers that made you think, okay, Adam's Shell should be Electron. I'm sure at some point there was a name announced, or maybe you named it, I don't know. There was a roadmap or whatever. The team named it, yeah. Give us more of the details there. What did you see foresight-wise to put together a roadmap? Obviously, you care deeply about JavaScript. You want to get back into writing that. But like what specifically around the tech got you excited about what it provided to add in the editor? for, right? It's the ability to use web technology to build desktop apps that are cross-platform,

but also specifically, you know, joining that team, I learned the backstory 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 like mostly Chromium and like 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, you know, Adam needed it done and so that was the impetus for building adam shell and so sort of learning more about that history learning more about that space and what was lacking in that space and and the gap that adam shell filled i just really felt like this is like this is not just a dependency. We just leave in, you know, in a, in a stack of a hundred repos that it should really be its own thing and get, um, and get a team behind it. Was it hard to convince people of that? Initially it, I mean, it was, there was like, I mean, well, so Adam had been

the vision, you know, 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, but I can't. It's interesting thinking about that desire to focus on Adam, given the eventual acquisition of Microsoft and then obviously the rise of VS Code. The importance of what an editor, 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, I think that just played out that way. That's pretty interesting to think about. I just sort of had that thought while you were talking there. Built on Electron. Yeah.

Yeah, that's true too. That's interesting too, even like 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 sort of this ability to do full time on what was Electron or what became Electron, I have in quotes, there should be an Electron in it. You said no. What's the backstory 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 now. 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. And so, 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, well, what are they using? How does it work? You know?

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 Why does that matter to me as, you know, a front end web developer? And so I thought a lot about how I explained Electron and how I had people on board into Electron. And, um, and so there's a, you know, there's a lot of rails at GitHub and rails and like in other frameworks, there's an init. And I felt like while inits are great for certain things, and it's also, you know, fill up your, 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. And so, and 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 a knit is going, you know, like, what are we going to recommend to people when they can do any of those things? And 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 user land, 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 like, this was kicking off Electron. I was sort of resource conscious of like, what can we afford to maintain ourselves while we're sort of 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. Like 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 sort of, you know, show 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 like a scaffolding. What would you say if you went back and thought about it? Surely there's no univariant 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? Yeah. Brand new apps. We're at an Electron every single day. What do you think caused that success?

I mean, I think that there was a need for this. And I mean, in the way that there's always a need to simplify your tasks, right? Engineers always want to simplify things, have less to maintain. And, you know, Electron lets you do more with fewer people with fewer code bases. And I think it empowers people too. I think, you know, web developers and designers who maybe didn't think this was within their reach, all of a sudden they have, you know, 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 empowers them to make more.

In particular, recently I had a conversation with Simon Wilson, who is the steward of many open source projects, but one in particular is Datasette. D-A-T-A-S-E-T-T-E, as in like cassette, but Datasette. The 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 dataset. They've got to do so many things that require you to be a software developer to some degree on the command line and like dev environments and just to some degree, some minutiae stuff that not everybody's willing to put the work in that they can get the benefit of dataset. I'm not sure what the state of it is now. This is a couple months back I talked to him, but over the weekend he built an Electron app that was the app for Dataset. 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 have been, you know, spinning his wheels how to create a native app for macOS or for Windows and other platforms. You know, 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 like building web apps, but just less fluent in them on the daily. I think that's super awesome. Like where you can give that kind of power to somebody in a weekend who wouldn't otherwise be like,

I'm never going to write a windows app and a macOS app and this app and whatever it just take, there's just too much to learn that they can now just do electron and deliver a data set up to, to, to gain 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 Dataset will know how to do. Yeah. Yes. And 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 wasn't entirely new concept too. And I, I mean,

I standardized 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, you know, each file was called and how it got kicked off and, and, and tried to challenge myself really. And like, how can I just keep explaining this better? 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 realized 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 like 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 I, when the first criticism started coming in, I was like, we've made it.

There you go. We have haters. But I mean, their criticisms are legit, right? Like, it'd be great if electron apps were smaller. Wish that were possible you know um but to me i have felt like 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 you know where 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. And so, I mean, I don't want people to come at me on Twitter. 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. We rebroadcasted on the changelog because it was just that popular. So a lot of great opinions shared there.

Two of the team members from 1Password sharing why they believe in the web stack. I would say that 1Password does not believe that Electron is a stepping stone. You know, they think it's their future. Well, yeah, but I mean, besides like banks in America, who's banking on using any software for 20 years? Like how do you define future? Yeah, on a time scale, all this stuff is going away.

So is there something being worked? Do you know something we don't know? Is there an Electron killer? Define future. Yeah. On a time scale, all this stuff is going away. Right. There's a shelf life for everything. So is there something being worked? 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 just been my, that's what keeps me from getting too worried about things.

Right. Is I just think that this is the stepping stone, you know? And I mean, I think a similar thing happened with jQuery, right? And like, you know, people got upset that people were using all of jQuery for, you know, one method and things like that. And jQuery had its time and place. And so, and maybe, and maybe people feel like it was for too long or it was for forever. Um, but yeah, it's like, how long is like, how, like how, how long is a company in 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. They're always reinventing themselves. Sometimes you're just refactoring, but sometimes you're replacing 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. Right. Now, do I think that one

passenger will be on Electron for five years? Probably. Ten 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 do i mean i 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 you know it's maybe easy to move to i don't not easy easy but it's a good stepping stone once a stepping stone is is easy to get to that's the whole reason it's a stepping stone i think when i had to frame clearly why i said they think it's their futures because they're not intending to like move to something they don't have their next stepping stone insight right based upon current conversation of course five ten years from now probably maybe not who knows but they're not seeing it as a 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 i mean

yeah the reason why their adoption made such a big splash is because one password is historically a very much native app to mac os which moved to you know android and and web and all these things and it was kind of like a reaction to like moving away from mac os 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 2017.

Jessica, when did you, when did this whole thing get started? Yeah, I think 2015 might've been first commit to Electron because I mean, it existed, you know, before anyone knew about it, before any of like that, before any of the Adam code, you know, was public or launched. Right. So. Yeah. Well, we first did a show on it in 2017 with Zeke Siciliano, surely a coworker of yours. And in fact, I happened to find he, he quoted you on that episode of the changelog.'s 2.16. 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. Describe this as, this is the promised land. Was that one of your early selling, your taglines? I like that. This is the promised land. Do you remember saying that? I don't remember saying that.

I feel like I would say it was a game changer that's like what i felt like i kept saying at that time and maybe you had multiple things you were saying or maybe editorialized yeah well in true pm fashion though you know that's what you do right you 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 true pm does is is they lead and inspire and you you did just that yes hopefully 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 that the program 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, 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. This episode is brought to you by LaunchDarkly. Fundamentally change how you deliver software, innovate faster, deploy

fearlessly, and take control of your software so you can ship value to customers faster and get feedback sooner. LaunchDarkly is built for developers but empowers the entire organization. Get started for free and get a demo at LaunchDarkly.com. Again, LaunchDarkly.com. so as we said Jessica you boomeranged. You went back to GitHub. 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 didn't you go back to the Electron team? Why did you dovetail and choose sponsors as your next big thing um well i i mean electron is just one of many things i love and i also love open source and i i care deeply it's almost like what's a more pressing issue right like when i was first working on electron it felt like a very pressing issue and then i sort sort of feel like I'm Mary Poppins out of there of like, okay, like I've got Electron to the point where it's okay and I feel good And a place that I feel like is a pressing issue that needs attention is open source sustainability.

And so to me, it was just a very bright beacon of like, 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 Devin Zugal, whom we had on the show November 2019, talking about the future of GitHub sponsors. I guess this is the future of GitHub sponsors. Back to the future.

Back to the future. There you go, Jared. Thank you for getting my back there. Yeah, sponsors is about two and a half years old now. Yeah. But you got that crossover of urban planning. You mentioned just the, I don't know if that's worth mentioning deeply, but like, 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.

And I'm just, that's just interesting that the both of you have that history. Yeah, was that a prereq on the job description? I know, it still seems like a strange coincidence, but also it seems very, it makes a lot of sense. Like, I mean, we're talking um i mean we're talking about communities we're talking about infrastructure we're talking about how ideas spread yeah yeah and you know one of the products i 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. And 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 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 the 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 so, yeah, I made that PowerPoint.

Cool. So now GitHub sponsors, we're two years in-ish. I mean, 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 Change Law talking about maybe Raspberry Pis 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. Like if he does a, um, like a test suite for how fast the RAID may perform on Raspberry Pi or how fast the SATA, you know, interface works, et cetera, versus SD, you know, all those kinds of things. He open 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, I see the impact there, but beyond that, Jared 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. You know, 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 you know, I'm not sure how that fits in for us. So we are not players in the GitHub sponsors game, so to speak. So we're more of observers. So take us deep into this world. What's happening? What did Devin 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. 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, communicate 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. Yeah. And so we are working on building that infrastructure right now. And that is really important for me as the next phase for us, for sponsors. And so Devin and the team kicked that off into beta. And so 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 sort of

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. And it says they get access to some sort of dashboard with deeper insights, essentially, which is unclear from the outset, since I'm not that large organization giving this large amount of money. So I can only presume what 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. What else, I suppose?

Does this kind of go into like a bank of trust, so to speak, a GitHub bank of trust kind of thing? Is it like in an escrow or some sort, and they can just like dole it out? Like, 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 sure to this easy button to push. Yes. I'm trying to make that easy button for them. And there's, 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 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 like a bit of sort of white glove treatment of, OK, 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 sort of making it up the best they can right now, because there's not a lot of prior art, you know, for how to give back as a company. Sentry just did a really great blog post a couple of weeks ago ago and they really detailed exactly how they thought through what to give back to open source and how not only like how much to give back to open source but exactly which ways to funnel it and so it's it's things like that that are we're starting to see just come out now where companies are really thinking about this and and sharing how they're thinking about it. Yeah. Shout out to Chad Whitaker, a friend from the past. 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. Or something to give us. we get. Lately it's been fewer. So that's a good thing. But shout out to Chad. This post he had and this big idea title of 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. So, and especially to see him working like this at Sentry. And I know that they have this heart, you know, despite them being BSL and having, you know, license change,

all these things that happen in open source that sort of happens at a 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 this drive from the company level coming back to using how can we give large amounts yeah and what's interesting too is how they want to pick projects because you know the no-brainer is back your stack like uh you know 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 underrepresented groups or projects that are around a theme they care about.

And so another thing for us to work on on the sponsor side is this whole area of discovery of how do you how do people find out about projects how do projects get themselves known to people out there who are looking you know to fund things outside of their dependencies well you need a social network i'm not i'm not even kidding when i say that yeah i know you do and there's so that's 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 like, 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 slash 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 like littering my activity feed, there's not a lot of like 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 Devin, 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, Jared, you probably remember this. He was like, I want to do more because Ben's thing with, with Lightstream is that it's open source, but not open to contributions. And that was sort of a, you know, provocative thing to say. And so

we had him on the show, talk deeply about that. And he still needs support though. It's still open source while he's not asking the 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? If it's about distribution. The distribution is sort of solved. GitHub when it comes to GitHub sponsors? If it's about distribution.

The distribution is sort of solved. I mean, depending on how you define distribution, right? I think it's discovery, I think, is the bigger, is the unsolved piece. Because GitHub lets you distribute, right? Okay, that's true. So you need 100 people. If 100 people find your repo, it will, 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're thinking on. We have a great researcher who's doing research. I've talked to some maintainers about this and thinking around, you know, how do you, 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, like it's a flurry of commits and you're trying to get, you know, to your 1.0 and you're trying to build interesting features. But if you're Babel, like you don't want to disrupt, you know, 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 um right now we have a place where you can see your dependency tree basically but i think i think that that's the first step and that we go further and um help projects surface themselves. It's more of a, a dependencies tree is a, is a great thing for awareness, but it doesn't,

it's not something you come back to like, oh, I got to go check out 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, the habit loop gets broken. The reward is no longer there. You're not going to keep coming back to that dependency. So you're thinking, who can I give to today? It's got to be a meaningful narrative, right? 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 like 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. Like that's a fact. The story is 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 yeah and but that may not even be your problem to solve though right if i at a certain point the maintainer tells the story you know 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 get the more sponsorship and the less savvy get the less sponsorship. 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 like how do i present myself what i do the value i'm bringing and then the

tears is like a big thing because it's flexible which is great but it's flexible which is terrible because i mean we had caleb porzi on show. Who's like killing it with GitHub sponsors. I'm sure you know. Yeah. He made that famous post about how he made a hundred grand a year. This was probably, he's probably doing double that now. Who knows? But he had this brilliant idea about how he actually structures his tears 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 like who you are, like if you're a freelancer, if you're a corporation and like, this is what he

requires and that paid huge dividends for him. I'm sure there's probably somewhere where these people talk and his best practice is, Hey, go check out Caleb's and copy that. But help us understand Jessica, are there ways that 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 out, 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? You know, and I've gotten feedback from companies that are like, these people create tiers that go up to $5. Like, we, you know, X big company, we can't go give $5. And so we have suggested tiers now. So when

you're on your tiers page, you can get suggestions of how to set them up. We have, we've recently shipped welcome messages that help you say something immediately to the people at each tier that have sponsored you. And so that's specifically an area we're trying to build features in is how to help people represent themselves the best and how to communicate what they're doing. 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 maintainers to make it easy. So would you say that the maintainers who have sponsor pages, so it's their profile slash sponsor, right? Is that, is that what the URL is? Yeah, no, it's,

it's github.com slash 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, page my my profile for example can i tell my story there can i put like updates and stuff like that there rather than like this static page that really is just pretty static you know what i mean we have heard that and thought about that it's rattling around there yeah okay yeah and people have definitely run out of space on their sponsor's 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 financial, their motivation is financially sustaining themselves or their processes and their daily objectives and the things they do to create and give. I'd imagine that that's the case. So we have a friend, Matt Reier, who works with us on GoTime. Since you write Go, Jessica, you may know Matt Reier For one year I wrote Go That's enough

I like his profile or his sponsor page because he goes 2, 4 8, 16, 32, 64 128, 256 512 and 1012 in terms of his tiers and they're in, in typical Matt.

And they're ridiculous, aren't they? Well, they're just like tip of the hat. And then I think $64 a month is, um, a couple of pizzas, one hot,

one cold for breakfast the next day. It's just like typical Matt humor. Right. And then the, uh, well, one was like two tips of the hat or one hit or one tip of two hats. You know,

yeah. Ridiculous things. My tips of the hat or one tip of two hats. That's right. Yeah, ridiculous things. My favorite is the most expensive one, though, is 1024 a month is a bit creepy now. You're getting creepy. A bit creepy now. So I love that you get this opportunity to share who you are. If you don't know Matt, you can probably read this page or at least read the tiers and get a bit of Matt's humor. And then you hear him on GoTime or then you meet him in person. You hear a talk.

You meet him in the hallway at a conference whenever there's a 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, yeah. And I think that's what we're in the position to do uniquely.

You know, like we are where the code is and where the developers are. And so I think that is our task to do. And to also expand it to more developers, because that's part of the other big thing that we need to do. It's like we need to enable companies to participate and 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 uh you may know more about that but if that is countries it's up six from we had devon on which was a few years back so clarify that for me is that regions regions or countries? Do you know? Does it matter? I believe it's countries. 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 to reach more developers, that's how you do it. You reach more in 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 trade and 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. Gotcha. Yeah. You mentioned you have a researcher, which you were quite excited about. 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 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 the research-led process in your hand. They are not battles. We have an amazing researcher and a team that values research. And so it's a part of every decision we make,

really. And, you know, we work together nearly every day. this episode is brought to you by our friends at Teleport. With Teleport Access Plane, you can quickly access any computing resource anywhere. Engineers and security teams can unify access to SSH servers, Kubernetes clusters, web applications, and databases across all environments. Teleport is open core, which you can use for free. And it's supported by their cloud-hosted version, which lets you forget about configuring, updating, or managing Teleport. The Teleport team does all that for you. Your team can focus on your projects and spend less time worrying about infrastructure access.

Try Teleport today in the cloud, self-hosted, or open source. Head to goteleport.com to learn more and get started. Again, goteleport.com. And by our friends at Square. Square is the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today's business needs. And I'm here with Shannon Skipper, Head of Developer Relations at Square. Shannon, can you share some details about the opportunity for developers on the Square platform? Absolutely. So we have millions of sellers who have unique needs.

And Square has apps like our point of sale app, like our restaurants app. But there are so many different sellers, tuxedo shops, florists who need specific solutions for their domain. And so we have a Node SDK written in TypeScript that allows you to access all of the backend APIs and SDKs that we use to power the billions of transactions that we do annually. And so there's this massive market of sellers who need help from developers. They either need a bespoke solution built for themselves on their own node stack, where they are working with Square Dashboard, working with Square Hardware, or with the Ecom,

you know, what you see is what you get builder, And they need one more thing. They need an additional build. And then finally, we have that marketplace where you can make a node app and then distribute it so it can get in front of millions of sellers and be an option for them to adopt. Very cool. All right. If you want to learn more, head to developer.squareup.com to dive into the docs, APIs, SDKs, and to create your Square Developer account. Start developing on the platform sellers trust.

Again, that's developer.squareup.com. so when it comes to financial sustainability of open source to me it seems like sponsors might just be one rung on a multi-rung wheel, or forgive 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, and there's these different models, OpenCore, 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 like some sort of relationship with a donation attached. But there are other ways of value transfer. Have you considered expanding a sponsor's reach into bug bounties some sort of a marketplace like other ways that aren't merely please give me money on a on a one-time or recurring basis yeah yeah that was bounties is a research item coming up and we did some initial research um a month or so ago and bounties was just part of it. So we really only scratched the surface on it because there's, 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? Who, who solutions get gets picked. And so there's lots of tricky elements to it to do it well um but that is something we're thinking about and and doing research around something else that's interesting to me is and you mentioned caleb earlier i know like c Caleb makes enough money to pay other people to 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 you know often i mean

obviously it's different you mentioned the person earlier who's you know 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 lightstream may so i know i reached out with support for uh arm 64 on pot on raspberry pod because i was using lightstream with sql light doing something i was tinkering with it and at the time i couldn't it, so it wasn't supported. You know, 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 XYZ, you know, maybe it's something where there's a tier that gets that to there. So, like, these are unique ways that isn isn't simply like in Matt's fun regard. Give me some pizzas, get me some coffee or get a little creepy depending upon how deep pockets you've got. Yeah. It's a way for them to essentially define products. Yeah. To a community.

Yeah. So we have one time tiers rather there's recurring tiers and then one-time tiers. And so you could get really creative with your one-time tiers and say like, okay, it's a hundred dollars one time. And you get, you know, office hours for an hour with me. And one of the things we've been thinking about is around like having a tier with a cap on it so that you can say, okay, I'm going to do office hours, you know, but obviously time is finite. And so I'm going to put a cap on this tier, you know, 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 sort of 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 repository 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 like tiers are a place where we can create a primitive like that, that people can use. And like Caleb ran a one day conference using a GitHub sponsors profile, which I think is another great example. Very inventive. Yeah, of like, 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 microsite kind of thing like it's got enough function is it all fine being in dot com oh it's all fine being in dot com i mean i'm not on engineering anymore but i do see our engineers every day and it seems like i mean mean, there's, there's a system. I mean, everyone's, 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 Corey Wilkerson about Codespaces recently and he talked about, you know, the massive push, obviously the Codespaces was, and that, you know, 800 of the000 engineers at GitHub are on.com so they're all on Codespaces so all.com developers that commit to.com are using Codespaces and 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 code space. 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.

When I mentioned Codespaces, I was really meaning just how many get to commit to.com. The massive technical talent that you have committing to that dot com space, you know, not that get up sponsors are so unique and so uniquely different that it can remain in the space that, you know, my concern is like maybe, you know, if you get socially or network or whatever, you want to attach to it with whatever sponsors becomes as it grows. Will it always does it always fit in the.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 have i'm assuming maybe at some point there is some networking stuff like if you have a destination does it make sense to have that sort of like feed or activity space you go to be three segments deep for example you know does it is it somebody's profile do i now have my own that's what you're saying personal destination to go to like it gets weird where like the main thing you go to GitHub potentially for is 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.

And 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 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, because that's, I mean, I mean, part of it's we're shipping to learn, right? Yeah. We want to get stuff out there and see what problems people are having. 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 pose this question. At least you did. And I agree with it.

So I nodded. So I'm going to assume some of the ownership of this question. You know, what happens to open source once it's funded? You know, what changes? What dynamics change? How do maintainers' lives change? Theoretical small business owners, basically, at that point. How do lives change once we have enough funding in the pool?

I think that's super interesting because I feel like if we do the stuff we're doing right now, which we're doing a lot of different things. We're still building features, but obviously, like the sponsors for companies and expanding, if all of that goes well, which you know, it should, then we basically create this new world where open source is sustainable. And so what is that? What's that future look like? Because we haven't been there before we haven't answered haven't had to answer that question. And so I think that there will be a few different things that shake out that not everybody will want to become a small business owner, right? Which is one obvious path of like, great. I've, you know, I've started earning enough money from sponsors that I can hire people and host an event and whatnot, right?

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, you know, and have that as their job. And then there's going to be projects like Babbel 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.

And what if you can be an open source contributor and make a living that way? We had a conversation recently with Robbie 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 set up a new Mac. And, you know, 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. Yeah. And so like the conversation, the reason I bring that up is because we actually had this conversation with Robbie,

just reminding him what an equity that lies within the Omai ZSH code base and opportunity for the community. Because to me, it's like a must install. And it doesn't show up in your dependency tree. Right. And so the distribution and the awareness is somewhat challenging, but like, 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 Robbie who weren't in the dependency tree, maybe personal dependency tree. Maybe I can go into like – maybe I do a homebrew list, for example, instead and find my dependency as a dev environment to give to. But, you know, I think for Robbie,

hearing this conversation with you now, I wish I hadn't known some of what we're going to talk about then because I would have suggested more deeply like, okay, cool stuff is happening with 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, you know,

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 Jared Wood, he's going to be a ZSH convert here soon. He's leaving Bash. He's leaving Bash. You know, how do we then direct those dollars to oh my zsh for example i think it has sponsors is the is the best conduit to do that because it's on the platform already yeah exactly and and there are there are things we're doing to you know sort of calling them like gentle nudges to remind people that the project they're

looking at is sponsorable. So we just shipped like 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, you know it is an exposure to, and then normalization. or like author in the actual issue box or comment box itself, adding sponsor to just normalize it and put it out there that, you know, people are giving to this project. This project is one that people see fit or worthy, you know, to sponsor and hoping that all of this helps in small ways to normalize this and and surface it that hmm 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 whatever it's going to say sponsor where it would have said first kind contributor or is that what you're talking about it's going to say that I'm a sponsor of this project? Yeah. 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 of, you know, like issues is a fire hose. How can they, even just like the smallest 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 so that's a thing and we and we did research on that it's not it's not a thing you can turn off issues completely that's been around right for a while um and we did research around that and the trick is that you know

some contributions are good some some are some are bug reports some are your friends and so it gets really like messy of like why well i want like not random people to open an issue but i still want my friends to be able to open an issue too and i don't want my friends to have to sponsor me so it just and to me it felt like well let's we need to get down to like 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, right? And so, like, 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. You know, if making issues something you have to pay for, is that make open source pay to play? You know, how does that change the landscape of things? And so some of these are big questions. I think if I were you, what I would err on is the side of giving the maintainer control. Yeah. Control of their output and their interaction with the community they desire to cultivate. You may, 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 permissively licensed

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 or whatever it might be you know if it 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 yeah and if they legitimize that then that's that's on them yeah 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 you you know, in or out of bounds, so to speak. But I think if GitHub can can err on the side of giving the right tools to maintainers to do what they want to 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. And I think you're right, too, that, you know, that it wouldn't be for everybody. That was something we we went through. And 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 there's lots of lots of levels to it then there was also the question of well okay if an issue costs five dollars it doesn't cost five dollars of my time to answer this right there's a whole there's a whole range of things so it it it turned into a pretty a meaty uh i don't know meaty is not the right word but a pretty gnarly topic. And so we have

our research, everything's still sort of clanking around in our heads. And the thing we did as more like obvious solutions were that nudge on issues to sponsor and then trying to surface, you know know 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 in the platform that you're in and so every change must be considered and reconsidered because once you put it out there, what if that feature went GitHub viral and every maintainer was like, sweet, pay me to open an issue.

Why wouldn't you turn that on? You do change open source. Sure, it was the community that chose that, but sometimes it's hard to push that lever back in the other position. I mean, sure, it was the community that chose that, but sometimes it's hard to pull that and push that lever back in the other position. And then people were still like, but I don't want my friends to have to pay to open an issue.

Right. Now you have a list of people. So then you need a list of friends on GitHub. Hey, it's a social network. So it does seem like people, was that a feature that existed and got taken away? 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 API 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 the cowpats thing. Are you watching what 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 pads thing is, are you watching what people are trying to do

and saying, okay, here's where they're bumping up against the edges and, you know, we're, 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 like sponsor wear basically and um and basically having to off people into things themselves and and maintain lists of who their sponsors are and so yes definitely the cow paths and and and listening to what people are already doing in a very painful way well i feel like i'm talking to a couple of 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 like the product roadmap of GitHub sponsors and like kind of bike shedding, you know, feature by feature. It is fun to do, but we never really opened up very well this question of what it looks like. Jessica, you said question of what it looks like. 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. And we've already embarrassed Caleb Horzio 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 to 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's there. It's not being distributed.

Well, no, in your hypothetical, it's there, 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 is just it's one of the ways i think like any economics if you want to work well for you got to work it you know i mean like if you want to work the economics openness so has the same opportunity as caleb right i'm not saying they don't i'm just saying the facts of the circumstances right so he's killing it and they're not no offense open the ssl 52 is nothing right? I'm not saying they don't. I'm just saying the facts of the circumstances. Right. So then I think that... He's killing it and they're not.

No offense. Open the SSL. 52 is nothing to balk at. Right. So then it comes down to, is that GitHub sponsors' role to play? Right? Well, I think to some degree, yeah.

To enable the distribution better, to more evenly distribute something so critical, potentially. Or just make a bigger pot of money so that the smaller side is still good enough. But yeah, discovery is part of it. Yeah, because how many people don't know how much

how important OpenSSL is to their lives versus they see tweets and courses and you know. Every time a heart bleeds an OpenSSL gets a sponsor been too long since heartbleed probably a lot of us don't even remember it now we do we do need to be reminded about that and that's yeah that's uh yeah I don't know well here's kind

of a cynical look at the future if there's so 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 hand their grubby hands on money without making awesome software I mean there's gonna be a lot more noise there's already more noise in open source than there ever has been and by noise I just mean like people doing things and saying things and I don't know the if we saw a graph of like repos created per day over the last decade, Jessica, it would probably be like a hockey stick, right? Yes, yes. So that's like one thing that we will have to deal with when there's gold in them hills, right?

There's people, there's gold diggers trying to get the gold out. And so maybe a potential downside of having like this great future, which we all want, where like financial requirements for open source community are taken care of, is like more people will pour in that aren't necessarily providing value and that's probably gonna be one of your challenges down the road is like not letting them game github sponsors yeah i mean we have people who look for people gaming this is they're already gaming it don't tell us where the games they are because don't give me light 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 jared 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 brand new startup, you know, what the overlap is to the sponsors for companies and those who have OPPOs, OSPOS, sorry, 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, one of the things that will change, right? As 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 like how developers have been successful, right? Sharing the stories so that people, it helps. 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, think this is this is the cusp of everything and so sometimes it's the budget is coming from the marketing team because they see this as marketing which call it it is Jessica nothing wrong with that hey marketing is great you know people need to hear more stories that's what marketing is yeah it's not selling it stories I 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. But 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 talked to all of these people and I think that it will start to normalize more. And part of what they ask me is, well well what are other people doing what should we do and so 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 want to 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 you know the dude did you rant max out the ramp whatever you know You want to know what your buddies did. 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. They're like, oh, man, we got to put in twice as much. Yeah, exactly. That's a good problem, too, though. I think any amount is a good amount. And sure, you can always increase it if it needs to be and i would even say like maybe i don't want to like carte blanche put this out but

you know if if a company decides to give even a small amount it's a good start yes you know it's a good start even if it's not enough you know don't like bash them or call them out about it encourage them about their other needs and whatnot, if that's the case. And, you know, normalize just giving from a corporate level, because that's the conduit, how to get the money from procurement to the hands of would-be creators, maintainers, content creators, whomever's leveraging GitHub sponsors for the good of open source. That's, that's the challenge. How do we, how do we decrease that friction? Yeah. Cause sometimes it takes companies months and by months, I mean, eight months. Too long. Too long. So long as the person who initiated it doesn't work there anymore.

Well, where does this money go? I don't know. Yeah, yeah. And I think, so if we go all the way back again, actually, to me rejoining GitHub at this time and with sponsors, you know, part of it was because I was very interested in open source sustainability and being a 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, you know, it's a big, it's a big issue, or there's a lot of moving parts, you know, the taxes of every single country in the world and things like that. And so we have the resources. And I think it makes me excited to be in this position of like, we are really trying to make this change. We are in the position to make this change happen. And, you know, we're working with these companies in a way that we are able to do at our scale. 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 sort of like 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 dun all right 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 uh 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 have the ear, if you haven't already had the ear of them, this joins the fight, that joins the triumph, whatever, however terminology you want to use. You know, what is it that is the next thing that

can get people excited about developers getting involved in sponsors? If they're not already involved, I mean, teams getting involved and then the companies, what's, what's, 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 Taylor saw with those different people. 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, Jared, from Zeke that he had said? No. Can we just leer that he had said? No. Can we just layer that back on? This is the promised land, y'all. It's the promised land.

Get on board. And I really do think it is. I'm excited that, and, you know, this is why I wanted to have this conversation. I think it's great that you're creating an easy button for, you know, $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're boomerang 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.

That's it for this episode. Thanks for tuning in. What excites you most about GitHub sponsors and Electron? Let us know in the comments. If you haven't yet, check out ChangeLog++. Support us directly and make the ads disappear on all our shows check it out at changelog.com slash plus plus up next is dev discuss from dev right here on the changelog jared and i guested their launch episode for season seven so we're bringing that here for you thanks again to our partners leno'd

fastly and launched darkly also thanks to breakmaster cylinder for making all of our So we're bringing that here for you. Thanks again to our partners, Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. And of course, thank you to you for listening. If you enjoyed this show, do us a favor. Share it on Twitter, Reddit, Hacker News, anywhere that works for you. Word of mouth is by far the best way to help us grow this show. And of course, the Galaxy brand move is to subscribe to our master feed that will get you all of our podcasts in one single feed. Check it out at changelog.com

slash master. All right, that's it. This show's done. Thanks for tuning in. We will see you next time. Thank you. Game on.