The Changelog: Software Development, Open Source - That's it. This is the finale! (Interview)

Episode Date: March 30, 2018

We're rebroadcasting the finale episode of the beloved Request For Commits. But don't worry, The Changelog will be back with new episodes next week. In this finale episode of Request For Commits, we regroup to discuss the podcast from its start to its finish, lessons learned, community impact, and where the conversations around open source sustainability are taking place, now and in the future. It's the end of Request For Commits, but the conversations we've had will continue on The Changelog. We also have some guest-host appearances for Nadia and Mikeal planned in the near future on this podcast. So, stay tuned.

Bandwidth for changelog is provided by Fastly. Learn more at fastly.com. Error monitoring is by Rollbar. Check them out at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. What the? Whoa, whoa, whoa, whoa, whoa.

Hang on a second. This is not requestquest for Commits. Okay, kind of it is. We're rebroadcasting the finale episode of the beloved Request for Commits right here on the Changelog. But don't worry. The Changelog will be back next week with new episodes. And in this final episode of Request for Commits, myself, Jared Santo, Nadia Ekbal, Michael Rogers, we regrouped to discuss this podcast from its start to its finish, the lessons learned, the community impact,

and where the conversations around open source sustainability are taking place now and in the future. It's the end of Request for Commits, but the conversations we've had will continue right here on the changelog. And we also have some guest host appearances for Nadia Michael planned in the near future so stay tuned to that all right let's roll that intro so we're here for the finale episode and it's just a bummer to say that, but it's the real thing. The finale episode. Bittersweet. Bittersweet. Yeah, bittersweet.

Of this great show. This show began, I don't even know the date, Jared, but the very first time we talked to Nadia, which you found that, I think, one of her first articles around open source and sustainability and just this problem, so to speak. How Nadia stumbled upon the internet's biggest blind spot? Is that what it's called, Nadia?

That's what it was. Yeah, something like that. That one caused a splash and caught my eye. And we had you come on the show. For longtime listeners of RFC, you all probably remember some of this history. But after we had Nadia on the changelog, had a great time, was a very good show. We kind of kept the door open for you to do your own thing

and focus on that conversation around the blind spot and open source infrastructure. I think we even said at the end of that show too, like, you know, Nadia, we'd love to hear you on a podcast having conversations that you're probably having to do these you know long form essays on Medium we'd love to hear the behind the scenes of this

and that's essentially the rough recipe we began with and then you went away for several months we released the show it was great all that good stuff and you continue on your path and then I think around four or so months later you came back you're like hey i've evolved this idea i've talked to my buddy michael which was also a friend of ours as well and then we became you know this this idea for

this podcast we're talking about right now so here we are it's uh this will be episode 20 of request for commits couple years later nadia and mich, we are winding down here and calling this the, not just the season finale as we've done before, but the series finale of RFC. Tell us about that decision and maybe even the path that the show went down and also that you two have gone down in the last couple of years to bring us to today. I'll let Nadia start because I'm going to end up showering Nadia with compliments about her stuff. So why don't we?

I think it'll work better if you go first. All right, Nadia, you go first. All right. Yeah, I mean, I think the decision came kind of in a good way and just like talking to Michael and both of us realizing that when we started this show a few years ago and yeah I mean when I originally talked to you folks at changelog like no one was really thinking or talking about this very much on a broader scale they were sort of like one-off conversations and blog posts and things from open source maintainers about

just talking a little bit about the issue of like, how do we keep a project going? But there wasn't really a much more like sustained focus or attention on it. And yeah, a couple of years down the line, as we were thinking about what would a season three look like or who else do we want to bring onto the show? I'm kind of feeling like a lot of these stories are out there now, not just on RFC, but all over the place. And yeah, we're kind of at a point where sustainability is a little bit more of a given that it's something really important in open source and it's something people should be paying attention to. I often have this, I just think back to early 2016 and how we still had to make a case back then that this stuff was important like I remember having so many conversations with people that were just like you know open source is great and everything is going really well and um you know people like working on this

stuff without any sort of recognition or um yeah sustained attention on on their work and now I feel like I never have those conversations anymore because we've kind of like moved past it. And now it's a little bit more of people that are really excited about creating solutions and bring more conversations around this stuff. And yeah, there's just like multiple people working on different aspects of the problem. And yeah, I think from that perspective, it was sort of like RFC did its job

and we got a lot of those interesting conversations going on the show. And now we're sort of like letting it dissolve back into the broader conversation. Okay, Michael, shower with praise. Yeah, I mean- Don't. So, I mean, I've been in open source

for a really, really long time. I've been trying to talk about GitHub generation open source for quite a while. I've written about it. I've given talks about it. And still, the moment that I got in front of anybody from an older generation of open source or anybody who can write checks from a company around open source or like any of the kind of institutional support, um, I was always starting from just kind of 0.0. Right. And you can't get five minutes into one of those conversations without somebody talking about, you know, free software and software

freedom or going into, you know, Apache model stuff or the word meritocracy will get thrown around a lot. And it's just, it was just like a constant sort of drag to try to re re like not even reeducate somebody because they think that they already know everything, but literally try to recontextualize like what they're trying to talk about in terms of sustainability with what sustainability looks like in a completely new open source model, like what we're seeing already happen. And after Nadia's work came out, and really like this started to become really obvious as we were sort of recording season two. So we kind of planned season two before this was really kind of taken for granted.

But all of that changed. Like everyone that I talked to about sustainability now, not only are we like on the same page and they're looking at it the same way, but we even have like a new vocabulary that we can talk about this kind of stuff in. Like people didn't use the word software infrastructure before. They just didn't speak about it that way. And all of that was really solidified in the work that Nadia did in her paper, Ro bridges. Um, and then everybody who sort of added things to that and wanted to continue the sustainability story into open source would, you know, link back to

that and quoted and all that kind of stuff. And now I feel like there's, there's been a very, very big shift in what we look at for open source sustainability and how we talk about it. Um, and the, the sort of like the making the case stuff, which really felt like part of what we were doing with the show was like talking to people and getting a lot of their stuff out there. And we're exploring what sustainability looks like with these people, but we're also just trying to, you know, educate the general public that this is just like much more complicated than what we've talked about before.

And there's going to be a lot of models and there's a lot of different kinds of people that have different needs. And I, I, I feel like we don't really need to do that anymore. Like, I don't know if Nadia feels the same way, but Nadia already, like, I think, fixed this. I did not fix it, but yeah, I think it's stuff like this where I think the focus early on was just exposing as many stories as possible. And especially for me, like, coming into this space and being new to it and not having a

long, a long background, just being able to like my strategy was basically just like point to all these stories I was collecting around. Like, if you don't believe me, then believe this person who's maintaining the software that you're using right now, every day at work. And yeah, I think that that was a big part of making the case was just sort of being like, here are all the stories. And at some point, like you just like can't really deny that it's a problem when you're And, yeah, I think that was a big part of making the case was just sort of being like, here are all the stories. And at some point, like, you just, like, can't really deny that it's a problem when you're hearing it from lots of different ecosystems, lots of different types of people in all these different ways.

It's interesting, too, because, like, your perspective was from a venture-backed scenario. And I don't know the full story, but you came from a different angle. You weren't really in software day to day, but you saw this larger problem and you're like, how is no one talking about this? You know, how is this not on the forefront of people's concerns? Because you've got, you know, I don't know if Heartbleed happened after or before us discovering you and, you know, the work you've done and all that good stuff. Does anybody know when Heartbleed happened? Can you recall the time frame? It might have been right before we talked.

Okay. It was after your initial article, though. Because your initial article was January 13, 2016. And I'm going to fastly... April 2014 was Heartbleed, but it had a couple years before then. So the core infrastructure initiative may have been in place from the Linux Foundation around then. I think that was just before your time frame of that post. But, you know, these things were happening.

You were just pointing to case studies, essentially. Scenarios where there have been issues of, you know, unsupported. And when you say unsupported, it doesn't exactly mean like money, right? Like we've learned through this series that money isn't the problem. It's a lot of things. Yeah. It's more complicated. Right. People think, well, if I just had money and, but we found from some people that they were like, well, I'm glad I've got money now. I don't know what to do with it. Now I've got another problem and now I've got money to deal with. Yeah. Yeah. Yeah. Well, I think like in the very initial article that you first wrote, it was framed a little

bit more financially. And I remember the first time that we spoke, you had already spoken to a lot of open source maintainers, but I was also very adamant that like, it's not a money thing. Like if the governance is messed up and you can't make decisions and you dump money on that structure, it's just going to make everything worse. Yeah. up and you can't make decisions and you dump money on that structure, it's just going to make everything worse. Our conversations, I think more than anything else, your perspective, Michael, really helped shape my view on that. At first, I think it was really just about funding specifically and then how it got kind of broadened more into

sustainability, which is partly about money, partly about community, partly about governance, lots of different things. But yeah, I feel like you brought in that really, especially from everything with note of just like how important the governance aspect is of, of thinking about how to structure projects. Can you take us back to maybe that to some of the topics you covered or maybe some of the aha moments for you, Nadia, with the first few conversations you had with Mike, I know it was sort of over coffee or lunch or something like that

like hey I've been thinking about this and obviously the conversation you had yeah man that's so long ago uh the structure around I remember Mike had this one post healthy open source is that right yeah yeah I send that to everyone all the time because there's like a really great diagram in there that's like um comparing the imbalance of like i think it's like maintainers and specifically the technical council which is i think more specific to node but the idea of just having some like core governance structure um and then you have like your broader subset of contributors and a broader subset of users and just like thinking about like how those things work with each other of, um, yeah. What does it get out of balance when you have like only a few maintainers, but like tons and tons of users

who are all sort of like asking something back from you. Um, and then how do you like bring that into balance of having like more and more people, or supporting so that all that burden doesn't fall on just a couple of people? That was, I think, a really important framing that Michael brought in. And then we talked about liberal contribution policies and theories. And I think that was also another really big moment for me of, um, cause I think like from talking to maintainers, I got like this one perspective of single maintainers saying like, I'm really like overburdened and I don't know how to manage all my issues. And like, that's a very immediate pain point of saying like, I don't, I don't know how to handle all this as one person. And I think in my conversations with Michael, like it helped me understand this sort of

like aspirational goal of, well, maybe it doesn't all need to fall on one person. And that's kind of like a really great dynamic about open sources. You should ideally be able to, I mean, one, you can always walk away. You don't have to like carry all that burden. Um, and two, just thinking about like, how much can you push off to other people, um, and not take on all that stuff yourself. And I think like we do have slightly different philosophies on some of this stuff. And that's also why I think we're very like complimentary. And when we talk about this stuff and that, like I think I'm still really interested in single maintainer projects as

something markedly different from, I think most of the open source projects that make it into like very public conversations are the really, really big ones like Linux sized or Apache sized or whatever. And, um, I think a huge thing that's been missing from the conversation and it's still not talked about enough is like the situation of like more single maintainer projects. Um, and I think I went really back and forth on this in that I think at first I was like really like championing the maintainer. And then I was like, well, maybe there's a way to sort of like broaden it and bring in more contributors. So it's not so much work just

for the maintainer and you're offloading some of that. And I think I've come back to the maintainer side of things of in the end, there are going to be a smaller subset of people who are doing the bulk of the work. And I'm mostly interested in figuring out how to allow those people to do it in a more focused manner. And that's different from, you know, how do we get every contributor to, you know, get compensated or paid or something for on an open source project, which is actually not something I'm particularly interested in. I don't think every open source contribution deserves compensation, but it's more about for the people that are really carrying the

burden on the projects, how do we support them? This is kind of interesting. I'm actually just kind of identifying this now, but when Node.js moved to this liberal contribution policy, the only projects that had done it were much, much smaller, were the kinds of projects that would have just been kind of single maintainer before then. And it worked really well with them. And there was this really big open question of like, would it work well for a big project? And if I look back now at all the smaller projects that had done it and look at Node, it's clear that it actually works best for a big project. A liberal contribution policy with a lot of people at different tiers contributing works really, really well for a big project. For smaller projects, all of those ones that had those liberal contribution policies, they had a lot of people during initial development, but now they're kind of held together by one or two people.

They look a lot closer to a single maintainer project. And like Nadia just mentioned, like, you know, the people that we talk about, the projects that we talk about are these big notable projects. And we don't talk about the vast majority of open source projects that are smaller libraries that are maintained by basically a person and should kind of be maintainable by a single person

if they maintain that scope. But it's still just a huge burden to maintain them. And there's like, I I've, I've dealt with this with just some of my projects and I've gone towards this like really aggressive tooling model where, you know, all of the releases are automated and there's a hundred percent test coverage and you know, like, like all of these things that just make it really automatic for anybody to contribute so that I don't have to involve myself every time that there's a pull request. So there's some interesting stuff happening around single maintainer projects. And a lot of the tooling that we might see helping out those maintainers is probably more important for the next round of sustainability work, which is all of these smaller projects

that basically glue everything together in the entire ecosystem. We didn't really talk enough about tooling on this show, I think. But that's something I think about a lot just at work all the time. For GitHub, as a platform, how can we take... There's some work that just no human should be doing, period. And it's not about offloading that to a contributor it's just about like yeah improving um improving how your project is structured and yeah i think that's a really big part of the conversation i remember talking to you michael about every time we we connect you're like i've got a new project i'm working on this fun thing

and it's always bleeding edge and then you're talking about the the different tooling you have to automate stuff can you share a bit it doesn't make sense in this format, to share maybe some of the key findings you found to automate? Like what particular areas? So Gregor from the Hoodie Project has really been pushing this model for a while. A lot of people in the Hoodie Project actually have been creating a bunch of tooling around this.

The big one is called semantic release, which basically it's complete release automation. So if all your tests pass every time that you accept a PR, every time that you push, you just get a new release and the version number is determined by, you know, this commit metadata that says like, you know,

as their new feature or a fix or a breaking change, that kind of stuff. And it's just a much better model for, like, not having to do manual releases, one, is amazing, but also getting everybody in that kind of habit. And then if you move to 100% code coverage, which in Node there's a lot of great tools to help you with this. So Tap already has code coverage kind of integrated.

I have some code on top of Puppeteer, which is like a headless Chrome testing utility. My tool is called Capadonna. And that basically adds the coverage into the browser sections. But there's new work that I just saw Ben Co push up a PR for to get code coverage directly into Puppeteer.

But anyway, once you have 100% code coverage, you're just much, much more confident when PRs come in with tests that they're actually testing everything. And the coverage itself becomes a test at some point. So when you have these kind of intermittent tests that may actually gloss over a section but still show as passed, those end up showing up. There's just a lot of really nice things that 100% code coverage gets to you. And it's also one of those things where when you have a small

library that you just started, it takes maybe like an hour to get to 100% code coverage. But if you have a big project, like I have requests that's been there for years, it's basically impossible to go and get to 100% code coverage. One of those things that's really easy to keep up with once you establish, but really hard to get to if you don't start with it. That's why you do it out the gate, which is what I think a lot of the conversation we had was around. I know this is a lot of work, but I'm doing this up front so that I have sort of a framework or best practices I follow

as I start new projects so that if I need to hand it off or I want to come back six months later, it's a little easier to jump back in because there's a, you know, a way I've done things. Yeah. Going back to Nadia, that article you mentioned of Michael's, which was called healthy open source.

We'll link this up. I'm just scrolling it as you and Michael were talking and I just see highlight after highlight and they all say Nadia. So that was kind of funny. And then, then there was like one other one that wasn't you and that was Dan Abramoff. So. Well, that's based on people that was Dan Abramoff. So.

Well, that's based on people that you follow. Oh, is it? So it's not all highlights. I'm totally creepy. I think I highlighted like most of that article. I kind of hate that about Medium.

I don't follow many people on Medium. I guess then maybe there's more highlights. I was just like, she's the only one highlighting. This is awesome. Like now I could just like read just her highlights and highlights and get what I need to get from it. And that's it. Yeah.

I highlighted a lot in there. There's at least 25. Thanks for counting. I definitely recommend following Nadia on Medium so that you can see her highlights. That's definitely something you should do. Oh, man. I know people are creeping on my highlights on Medium. That's what makes me self-conscious about highlighting stuff.

If I knew that, you know, maybe. Well, sometimes I want to highlight weird stuff. Like red herrings, like to the lead of us off your trail. You'd highlight something. Misinformation. Something worthless. Yeah. That's right.

Now that I know people are looking, yeah. Head games. looking yeah head games this special episode of the change log and request for commits is brought to you by our good friends at rollbar move fast and fix thingsolve errors in minutes and deploy with confidence. Head to rollbar.com slash changelog. Request a demo. Get started today. It's loved by developers, trusted by enterprises, and most of all, we use it here at Changelog. Move fast and fix things with Rollbar.

Once again, rollbar.com slash changelog. And also by our friends at DigitalOcean. Simplicity at Scale. DigitalOcean's cloud computing platform is built with simplicity in mind, so managing infrastructure is super easy. Whether your business is running one virtual machine or 10,000, DigitalOcean gets out of your way so your teams can build, deploy, scale, all that good stuff way faster and more efficiently than ever before. Sign up and deploy your app in seconds. Head to do.co slash changelog. And by the way, using that URL will get you $100 to spend over 60 days.

Once again, do.co slash changelog. let's talk about the state of sustainability in terms of open source yeah on the show i know we talked about several ways of like funding it very diverse ways of funding whether it's a grant or a platform or direct contributions whether it's a project you're funding or a person you're funding i think now you've changed your tune in terms of like focusing on the individual maintainers you said to help them focus better maybe that's something you can dive into but can we kind of talk about the the various facets maybe we have covered on the show in its past and maybe some of the ones we haven't covered and maybe where things are at in terms of like how sustainability is happening? Yeah, I think there's like a couple of big areas that kind of come to mind for me or just things that other

people will suggest. One is around community dynamics and I think governance stuff and contribution policies and how do you structure your project in a way that's really easy for someone to come in um and that leads to another related area which is stuff like documentation and tooling and automation and like sort of like what are the required things that you should have in a project um or or what's a a good standard way of setting up your projects and make it easy for people to come in and just create as little work as possible for you. So I think all that stuff is a big, important part of the sustainability conversation. Diving more into, I guess, funding models or things that have worked money-wise,

I think there's a lot of experimentation happening there right now. I think I get a new email about someone trying to tackle something in this space at least once a week right now, which I guess is not super high volume, but it feels like compared to before, it's a lot more. And I think there's a lot of interesting debate in that space just because of this tension

between are you supporting maintainers or are you supporting contributors? Like any old contributor paying them out and sort of like what's the volume of money you're trying to pay here? I think that's the hardest part about introducing money to open source is there are a lot of these sort of smaller, if you pay out a couple dollars to anyone who commits a certain number of lines of code, like, is that actually a great incentive or not? It could make things worse. If you're talking about paying someone tens of thousands of dollars or hundreds of thousands of dollars, then that's a very different kind of game. So I still find all those dynamics really interesting in thinking about what are funding models are actually viable or not. A couple of the, I guess, within that, the question is sort of like, well, what are people paying for and what's worth paying for?

And I see it break down into people that are sponsoring a project. So it's kind of like more of an open sponsorship visibility kind of thing. So like a company might want their logo on a project or something like that. That's one area of experimentation. One is around licenses. I think that conversation will probably go on forever. Can you use a license to encourage someone to pay? Which is kind of interesting. I want to be sort of like, who knows? But it's very persistent, so who knows what But it's very like persistent.

So who knows what will happen in that space? And then the other one, other big area I see is like support and services of, yeah, can we guarantee some level of quality or responsiveness or have your issues prioritized or something like that? And yeah, have that kind of like be the third area of something worth paying for. But yeah, those are the areas I'm seeing a lot of experimentation in. Yeah, yeah. I think that that's a good way to kind of categorize them. I will say that I've been very, very surprised by both the success and kind of failure cases

that we've seen. And also what the reaction of older open source people has been to these experiments. It's been almost universally negative. And I have a hard time trying to figure out why they've been so negative about it. It tends to be that they are adamant that big companies not have formal relationships in these projects whether that's through sponsorship or putting their logo up or anything they want

some kind of like plausible deniability between the contributor and the company the odd thing is that almost universally these people are employed by those big companies so they they have like the most um all of the unofficial relationships and all of the kind of like background influence universally these people are employed by those big companies. So they have the most... All of the unofficial relationships and all of the background influence is really prevalent in all of these older projects and all their open source people. And they are really adamant that that not be formalized in any way,

which is suspect to me. Really suspect. Because whether it's implicit or explicit, the influence is still there either way. Right, right. And I also think like, you know, we interviewed a couple people that did open collective stuff and we interviewed Evan Yu who did Patreon, right? And what we heard from these people was the opposite of what I thought that we would hear. So you have people that are funding the project and then you have people that are funding individuals like through Patreon.

And I thought that if you had people funding individuals, there wouldn't be as much of an incentive to bring on new contributors because you're already funding this one person. And, but what we saw was that that was actually kind of the worst when you were funding the project, because then people were fighting over kind of control of the project because that's where the funding is coming in, or they're fighting over how to dole out that money and which kind of person gets it. Whereas when you fund the individual, like when you fund Evan, you on Patreon, you're not funding Vue.js, you're funding Evan. There's an expectation already from everybody that put in money that this goes to Evan. And then Evan is part of it. I think that it's just

his personality. Like he's, he wants to bring in new people and create a really big community. But also, you know, he's, he's stable enough with his relationship to that sustainability. Like the check that is feeding his family is coming directly to him. So he doesn't have to hold his project hostage. He can always do what's best for his project and bring in a lot of new

people. And like the more that I'm actually using view now for a couple of things. And, um, I think it's one of the most interesting and, and as, as sort of popular as it is right now. And as much as people are talking about it, I think it's one of the most understudied like sustainability, like in terms of sustainability, uh, open source projects out there. Um, if, if we were still doing that, the show, I would probably like dig in a lot more to that project because it's really interesting. That interview like totally blew my mind. That was actually probably one of the biggest insights I got from this entire show is the idea of do you

fund projects or do you fund people? And I think that's like one of the biggest like cultural shifts, maybe defining this, whatever this newer generation of open source is. And it's also the source of a lot of tension and difference in values, maybe in the conversations I have with people of, I guess, if that one tension is, do you support maintainers or contributors? And the other tension is, are you funding a project or are you funding the people to work on a project? And yeah, that like completely changed my view of, I'm much more in favor now of funding

people over projects based on what we've seen. Yeah. And yeah, that like completely changed my view of, I'm much more in favor now of funding people over projects based on what we've seen. Yeah, that was a really big shift. I'm curious how that might play out though, because funding a person doesn't prevent them from burning out. Like just because you give me enough money to keep doing what I'm doing

doesn't mean that I'm not going to get burned out. How do you, does it even matter, I guess? I mean, obviously it matters, but from the sense of funding or supporting, like does, does supporting somebody as an individual, does that inhibit you or does that stop you from concerning yourself? They're going to burn out or just be just like, they'll do what they want. I mean, look, I think that people burn out outside of open source. They burn out in tech in general. I think that open source, we tend to talk about it in the open source community because, one, we actually have a community of people to talk about it in.

Whereas when you are just a person at a desk in a company, you don't have a community of people to talk about the issue of burnout with. So we end up talking about it more in open source. And I think that because of that, we think that open source is causing burnout in some manner. And I don't know that it is. I think that it's really easy when you take your passion and you allow other people to add responsibilities to it and add things to it. If you don't manage that well and you don't manage your time and your mental state well, then you are likely to burn out. But I tend to think that when we see negativity in open source, what we need to talk about is why people are being negative. And what are the things that are making people more negative in this project or this community than another?

Because those are things that we can actually fix. And we need to think about how do maintainers just kind of deal with that negativity? One, like how do they make their project not such a source of or target for that negativity, but two, just how to brush it off and how to just, you know, it's okay to ban people when they're dicks, like go and just do it. Like stuff like that. But I do feel like it's one of these topics where, I mean, I burned out before I was really involved in open source, like just working in tech and being young and not having enough of a life outside of work. So yeah, I don't know if the sustainability story and the burnout story are

as connected as we tend to think that they are. I don't know. Nadia might not agree. No, I totally agree. I mean, it's like if you were getting paid for something, I mean, I think it's the same as any other job, right? Where like you might just kind of at some point be like, I want to move on from this. I forgot. That was like, I think another within like kind of the area of community dynamics. That's the other really big focus in, in sustainable conversations is just like having people feel comfortable saying no to things or closing issues. The idea of like closing issues is still like emotionally horrifying to a lot of maintainers I've learned because they're just like really worried about like, what is like the reaction going to be if I close someone's issue versus thinking about like, well, maybe if it's not

going to get worked on, it's not going to get worked on and it will make my life better just to close it out. But yeah, just sort of like that, that if it's not going to get worked on, it's not going to get worked on and it will make my life better just to close it out. But yeah, just sort of like that, that sense of like being able to like advocate for yourself and say like, I'm going to do what I'm capable of doing versus feeling like you have to bend over backwards to everyone else. And yeah, those are kind of like human problems and they, I think they get exaggerated and open source, but I don't, I, yeah, we're only human. We're going to have finite level of interest in things sometimes.

And I don't think it's realistic to assume that someone's going to want to work on something for the next like 80 years or something. So, yeah. And I think the one dynamic that will get interesting if we focus on funding people versus projects will be what happens if someone does walk away. And because it's open source, they can sort of, you know, we see this in a lot of projects now where, you know, the original author might not be the person maintaining it actively, but if that original author gets sort of all the glamour or is most closely associated with the project and they walk away and they're not actively maintaining it, but if they're able to raise a bunch of money based on the work that they did, then like, is your money going towards the person who's actually doing most of the work?

If they walk away from the project, do they shut down their Patreon? That's sort of an open question, I think, of how do you manage when someone does leave? How do you actually transition? Yeah, I mean, you can always stop funding it, right? You can discontinue. But if people don't know about it, and if that, I guess, yeah, if that original author or maintainer is not transparent about how much work

they're actually doing, then, yeah. Makes sense. I feel like in general, a topic that I'd like to see a lot more kind of conference talks about and a lot more just discussion about is how to leave,

how to walk away from something responsibly. Both like, you know, how it's, it's actually better for the project for you to be less involved most of the time. Like the more that you kind of hover around, the less that other people can take on that responsibility from you. Um, and it's, it's not good for you and it's not good for them. It's, it's actually better just have a cleaner break a lot of the time. But people feel this kind of nagging responsibility to hover around and things like that. I've been getting this a lot over the last seven or eight months since leaving the foundation. People are like,

oh, are you going to the foundation conference? Are you going to be in this meeting or that? And I'm like, no. No, absolutely not. Why am I going to be there? And just like, just being there sort of undermines the people trying to take on the work that I was doing, right? Like, it gives a channel for everybody who's dissatisfied with any decision to just go like, well, I'm going to go talk to Michael and do what he thinks. Like, nobody wants that. Like, nobody wants to, you know, and it really makes it hard for people to take over those

leadership roles and to keep the project healthy. I agree. We don't see enough conversation on that stuff. Andrei Petrov, who maintained a project called EuroLib3, has done several transitions. And he recently published a post about this. And I was like, wow, I never see content about strategically practical tips on how to hand off a project. So I was really happy to see that. At some point, the end happens and, you know, this show for one, and then, you know, projects, people's term, you know, we, you know,

the term of service, so to speak, you know, if you're involved in something, I don't think you should have to commit for life. You can commit for a term, you know, one year, six months, two years, whatever makes sense for you in your life. Yeah. You know, I think that we should all go into something knowing that like jared and i when we think about spinning up new podcasts we don't think like well these people have to commit their lives to this show like no maybe they just you know maybe that's three months they can give us or you know

whatever so you have to come in there and think about that i was thinking about that sense of dread that nadia was mentioning with maintainers and the closing of the issue. And then the analog to the podcasters and the ending of a show. You know, what will people think with this show? You know, that's why so many of them fade out slowly, quietly into the night because we refuse to admit. It's too difficult to like actually end it. To actually end it well. Yeah.

Well, let's Seinfeld this then. I mean, I think, you know, people ask us, you know Seinfeld this then I mean I think you know people ask us you know you know how did the show do I think this show was really successful you know I think the show did really well for uh not being in our main feed it it brought its own audience you know and over time you know it did really well and so I think that's kind of how we're ending it is not so much I also say that we're not ending it. Sure, this is a finale episode to sort of give a nice end cap to the series. So when you go to changehall.com slash RFC or to the feed in any sort of podcast app, that you see a welcome message saying, hey,

we're gracefully closing down what we have here and the conversation is going to continue. And so maybe this is a good opportunity to share where those conversations are happening and maybe to set some expectations that while this may be a finale to RFC, the conversation does continue on our main show, The Change Log, so you can go to changelog.com slash podcast to pick that up or just search in any podcast app

for The Change Log and you'll find it. We have those conversations on that show too. That's where this original conversation with nadia happened so this was a focused channel for exploring different perspectives and open source sustainability so it doesn't mean that it's ending but maybe somebody else hit the floor where are where else is this conversation happening aside from where this podcast was or the change? Where else are these conversations taking place? So, I mean, we should plug the Sustain OSS conference, right? Like the Open Collective folks put that on together.

And the last one was like one of the best events that I've been to in terms of, I mean, it was like an eight hour version of RFC with a lot of people in the room that you would want to have as guests. It was a really, really good group of people and we got to talk about a lot of really, really good stuff. My worry with it was always that it was going to be too prescriptive, but it really wasn't.

It was about everybody talking about the things that have worked for them and why. That's a way to learn and to create a lot of new leaders in open source. Yep, definitely. Sustain OSS GitHub also does an event series called Maintainerati, which is maintainers getting together to talk about sort of their shared challenges and things that they're facing. So that's another good channel if you're a maintainer. Also, Nadia's Medium High highlights is another place that this is.

Plus some weird stuff thrown in there, but yeah. Yeah. Yeah. And I guess me and me and Nadia might come back on the change log to interview people from time to time. So there's a, there's a couple people that, that we didn't get to that I would like to have on.

I think we, I, I, if we don't at some point interview Sean Larkin, I think I'll be upset. Well, he got interviewed on ChangeLog, right? Right, but that was a couple of years ago now, and he's definitely...

Things have changed. We did talk about, I think they had just launched their open collective, and it was getting steam, but it's the kind of, I mean, Webpack is a standout project in many ways, and different than other projects in many ways as well. And perhaps exemplary in certain ways and maybe, in my opinion, in certain ways

it misleads other projects into thinking that they can be just like Webpack. But point being is there's tons to talk about there and Sean's a great guest. And so absolutely having him back and having you two interview him on the changelog would be awesome. We don't just do, we have several guests back several times.

I think Mike Perrin was the first four-time guest. Yep. But we've had guests back, and it's great. We'll talk to them a year later, we'll catch back up, we'll see them on the next release or the next major release or something that's pinnacle in the project's change, whether it's new maintainers or new direction or a conference finally or something.

Who knows? But we welcome the revisits. You know, those are, those are actually sometimes a lot more fun. Like we just, this Friday, we're going to release a show with David Heinemeyer Hansen on stimulus. And we've talked to him before about 10 plus years of rails that it mean we couldn't have him back on. So the second time around, I know I was a bit more comfortable because I felt like David's a buddy now versus like, Ooh, DHH. Anyway,

let's stand by saying thanks. I mean, I know personally I'm, I've personally benefited from, you know, knowing both of you and then playing, you know, the behind the scenes role i personally

have in this show's creation and execution and production so it's been a lot of fun to to coordinate things with you all but at the same time take a back seat to the content and you two totally drove this thing and michael i know you'll compliment nadia but uh and you'll back me up at least on this your show show notes, prior show notes are amazing. They should be, they should be published on their own. Although I know they're not exactly public kind of stuff, not that they're bad or good, just it's not a cohesive end to end document. It's, it's just, you know, for people like us, it really makes a lot of sense. So those are really appreciated. So I learned a lot of stuff from both of you, but all that to say,

thank you so much for, you know, working with us and caring about a community so much to put your time and effort into it. And then obviously to come back on as a finale to, to give a nice ending to a show like this. So thank you very much. Thanks.

I feel really grateful also. So thanks to, to all of you for, I mean, yeah, having a space to just talk things out with like i feel like from the first conversation with michael we just really hit it off and had just enough shared and different views that um just having a dedicated time and space to talk

about this stuff just helped us go a lot deeper and um yeah solidify our theories um and just like i mean i think i told you guys this like the i think changelog was the first podcast interview i ever did um i also never listened to podcasts ever and now coming out of out of rfc not only did i actually listen to a couple of rfc episodes myself um but i'm like actually really into podcasts so the experience of even like recording a podcast uh was just a really great meta experience too of being like even like recording a podcast, uh, was just a really great meta experience too, of, of being like, wow, this is a really great format for just hearing people's stories, exploring, yeah. Exploring with someone else. So

yeah, you're totally converted me to podcast, which is pretty great. That's awesome. I would just echo what everybody's saying. So I will say, no, nothing for me. Thanks for everybody. This was an awesome show. And I'm looking forward to these kinds of conversations continuing on the changelog. Yeah, this is not the end. This is just the beginning of something else.

And to the listeners out there who have listened to this since the beginning, thank you so much for your kind thoughts and your time and your attention means the world to us. So we really thank you for that. And go maintainers. Thank you. All right. Thank you for tuning in to this special episode of the changelog and the finale of Request for Commits.

We love that show. It was so much fun work with Nadia and Michael over the years to produce that show. And it was a blast. And just like with Nadia and Michael and this show, Request for Commits, we love to entertain some really awesome ideas. So if you've just started a podcast or you want to start a really awesome podcast and you're truly committed to working with us to create some really awesome content, get in touch. We'd love to hear your idea. Email us at editors at really awesome content. Get in touch. We'd love to hear your idea. Email us at editors at changelog.com.

Reach out, say hello. Thank you to our sponsors, Rollbar and DigitalOcean. And of course, bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things because of Rollbar. Check them out at rollly.com. We move fast and fix things because of Rollbar. Check them out at Rollbar.com. And ChangeLog.com is hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. Check them out.

Support this show. This show is hosted by myself, Adam Stachowiak, and Jared Santo. Our music is produced by Breakmaster Cylinder. And you can find more shows just like this at changelog.com or on Overcast or Apple Podcasts or wherever you get your podcasts. Go there, search for The Change Log and subscribe. That's it. It's done. We'll see you next week. Thank you.