Finale, thank you!

So we’re here for the finale episode – and it’s just a bummer to say that, but it is the real thing…

Bittersweet… Bittersweet.

Yeah, bittersweet… Of this great show. This show began – I don’t even know the date, Jerod, but the very first time we talked to Nadia, which you found 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 was 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 the long-time listeners of RFC, y’all probably remember some of this history. After we had Nadia on the Changelog, we had a great time, it 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, “You know, Nadia, we’d love to hear you on the podcast, having conversations, that you’re probably having to do these long-form essays on Medium… We’d love to hear the behind-the-scenes of this.” That’s essentially the rough recipe we began with.

Then you went away for several months. We released the show, it was great, all that good stuff; you continued on your path, and then I think around four or so months later you came back and like “Hey, I’ve evolved this idea, I’ve talked to my buddy, Mikeal (which was also a friend of ours as well)” and then it became this idea for this podcast we’re talking about right now.

So here we are, this will be episode 20 of Request for Commits… A couple of years later, Nadia and Mikeal, we are winding down here and calling this not just the season’s 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 gonna end up showering Nadia with compliments about her stuff, so why don’t we… [laughter]

Lols…

I think it’ll work better if you go first.

Alright, Nadia, you go first.

Alright. Yeah, I think the decision came kind of in a good way in just talking to Mikeal, and both of us realizing that when we started this show a few years ago - yeah, I originally talked to you folks at Changelog - no one was really thinking or talking about this very much on a broader scale… There were sort of like one-off conversations and blog posts and things from open source maintainers, 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 sustained focus or attention on it.

A couple of years down the line, as we were thinking about what would a season three look like, or who else do we wanna bring onto the show, I’m kind of feeling like a lot of these stories are out there now - not just on RFC, but just all over the place… 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.

[03:37] 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. I remember having so many conversations with people that were just like “Yeah, open source is great, and everything is going really well. People like working on this stuff without any sort of recognition or sustained attention on their work”, and now I feel like I never have those conversations anymore, because we’ve kind of moved past it and now it’s a little bit more of people that are really excited about creating solutions, and bringing more conversations around this stuff, and… Yeah, there’s just like multiple people working on different aspects of the problem. I think from that perspective 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, Mikeal, shower with praise.

Don’t…! [laughter]

So I’ve been in open source for a really, really long time, and I’ve been trying to talk about the GitHub generation open source for quite a while; I’ve written about it, I’ve given talks about it, and still, the moment 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 any of the kind of institutional support, I was always starting from point zero… And you can’t get five minutes into one of those conversations without somebody talking about free software, software freedom, we’re going into 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 – not even re-educate somebody, because they think that they already know everything, but literally try to recontextualize 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.

After Nadia’s work came out – and really, 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. 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. People didn’t use the words ‘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, Roads and Bridges. And then everybody who sort of added things to that and wanted to continue the sustainability story in new open source would link back to that and quote it and all that kind of stuff.

Now I feel like there’s been a very, very big shift in what we look at for open source sustainability and how we talk about it. 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 educate the general public that this is just like much more complicated than what we’ve talked about before, and there’s gonna be a lot of models and there’s a lot of different kinds of people that have different needs… And I feel like we don’t really need to do that anymore. I don’t know if Nadia feels the same way. I think Nadia already fixed this, so… [laughs]

I did not fix it, but yeah, I think it’s stuff like this – I think the focus early on was just exposing as many stories as possible… Especially for me, coming into this space and being new to it, and not having a long background… My start 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.”

Yeah, I think that was a big part of making the case, being like “Here are all the stories”, and at some point you can’t really deny that it’s a problem, when you’re hearing it from lots of ecosystems and lots of different types of people in all these different ways.

[07:52] It’s interesting too, because your perspective was from a venture-backed scenario; 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? How is this not on the forefront of people’s concerns?”, because you’ve got – I don’t know if Heartbleed happened after or before us discovering you and the work you’ve done and all that good stuff… Does anybody know when Heartbleed happened, can you recall the timeframe?

It might have been right before we talked…

Okay.

It was after your initial article, though.

Yeah.

Because your initial article was 13th January, 2016, and I’m gonna fastly –

April 2014 was Heartbleed, but…

Okay, so 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 timeframe of that post… But you know, these things were happening, you were just pointing to case studies, essentially; these scenarios where there have been issues of unsupported - and when you say unsupported, it doesn’t exactly mean like money, right? We’ve learned through this series that money isn’t the problem.

It’s a lot of things.

Right?

It’s more complicated than that, I guess.

Right. People think “If I just had money…”, but we’ve 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, now I’ve got money to deal with.”

Money problems.

Yeah. Well, I think 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.” If the government is messed up and you can’t make decisions and you dump money on that structure, it’s just gonna make everything worse.

Yeah. Our conversations, more than anything else, I think your perspective, Mikeal, 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 brought in more into sustainability, which is partly about money, partly about community, partly about governance… Lots of different things. But yeah, I feel like you broadened that really, especially from everything with Node, of just how important the governance aspect is, of thinking about how to structure projects.

Can you take us back to maybe some of the topics you covered, or maybe some of the a-ha 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 conversations you had…

Yeah. Man, that was so long ago. The structure around – I remember you had this one post, Mikeal, “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 comparing the imbalance of maintainers and specifically the technical council, which was I think more specific to Node, but the idea of just having some core governance structure; then you have your broader subset of contributors, and a broader subset of users, and just like thinking about how those things work with each other, what does it get out of balance when you have only a few maintainers but tons and tons of users, who are all sort of like asking something back from you, and then how do you bring that into the balance of having more and more people contributing or supporting, so that all that burden doesn’t fall on just a couple of people. That was a really important framing the Mikeal brought in.

That, and then we talked about the role of contribution policies and theories, and I think that was also another really big moment for me… Because I think from talking to the maintainers, I got this one perspective of single maintainers saying “I’m really overburdened and I don’t know how to manage all my issues”, and that’s a very immediate pain point of saying “I don’t know how to handle all this as one person.”

I think in my conversations with Mikeal helped me understand this aspirational of “Well, maybe it doesn’t all need to fall on one person.” That’s a really great thing about open source - 1) you can always walk away, you don’t have to carry all that burden, and 2) just thinking about how much can you push off to other people and not take on all that stuff yourself.

[12:24] I think we do have slightly different philosophies on some of this stuff, and that’s also why I think we’re very complementary when we talk about this stuff. I think I’m still really interested in single-maintainer projects as something markedly different from – most of the open source projects that make it into very public conversations are the really big ones, like Linux-sized, or Apache-sized, or whatever, and I think a huge thing that’s been missing from the conversation, and it’s still not talked about enough, is the situation of more single-maintainer projects.

I went really back and forth on this. At first I was like really like “Champion the maintainer!” and then I was like “Well, maybe there’s a way to broaden it and bring in more contributors, so it’s not so much work just for the maintainer, and you’re off-loading some of that.” I think I’ve come back to the maintainer side of things of - in the end, there are gonna 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. That’s different from “How do we get every contributor to get compensated or paid 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 like for the people that are really carrying the burden on the projects and how we support them.

This is kind of interesting… I’m actually 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; 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 well for a big project.

For smaller projects, all those that had these 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. Like Nadia just mentioned, 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.

I’ve dealt with this with some of my projects, and I’ve gone towards this really aggressive tooling model where all of the releases are automated, and there’s 100% test coverage… All of these things that just make it really automatic for anybody that contributes, so that I don’t have to involve myself everytime 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 like the next round of sustainability work, which is all of the 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 at work all the time… For GitHub as a platform, how can we take – like, there’s some work that just no human should be doing, period, and it’s not about off-loading that to contributors, it’s just about improving how your project is structured, and yeah, I think that’s a really big part of the conversation.

[16:11] I remember talking to you, Mikeal, about – everytime 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 different tooling you have to automate this stuff… Can you share a bit – does it 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 is 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 this commit metadata that says “Is there a new feature, or a fix, or a breaking change?” that kind of stuff, and it’s just a much better model for – not having to manual-release, for 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. Tap already has code coverage integrated; I have some code on top of Puppeteer, which is like a headless Chrome testing utility… My tooling is called Cappadonna, and that basically adds the coverage into the browser sections. But there’s new work that I just saw Ben Coe push up a PR for it to get code coverage directly into Puppeteer.

But anyway, once you have 100% code coverage, you’re just 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. When you have these kinds of intermittent tests that may actually gloss over a section, but still show us passed - those end up showing up. There’s just a lot of really nice things that 100% code coverage gets 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 Request, that’s been there for years, it’s basically impossible to go and get 100% code coverage. It’s 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 like “I know this is a lot of work, but I’m doing this upfront, so that I have sort of a framework or best practices I follow I start a new project, so that if I need to hand it off or I wanna come back six months later, it’s a little easier to jump back in because there’s a way I’ve done things.”

Going back, Nadia, to that article you’ve mentioned of Mikeal’s, which was called “Healthy open source” (we’ll link this up), I’m just scrolling it as you and Mikeal were talking and I just see highlight after highlight, and they all say Nadia. [laughter] That was kind of funny. Then there was one other one that wasn’t you, and that was Dan Abramov, so… Good company.

Well, that’s based on people that you follow.

Oh, is it? Okay, so it’s not all highlights… Okay. [laughter]

That’s still totally creepy; I think I highlighted most of that article.

I don’t follow many people on Medium; maybe there’s more highlights. I was just like “She’s the only one highlighting, this is awesome! [laughter] Now I can read just her 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… Now people are creeping on my highlights on Medium. [laughter]

That would make me self-conscious about highlighting stuff, if I knew that–

I know! Well sometimes when I highlight weird…[laughter]

It’s like a red herring… To lead us off your trail, you highlight something worthless…

Misinformation, yes.

That’s right. Now that I know people are looking, yeah…

Head games.

[20:01] Oh, boy… It’s reminding me of a book; I won’t say it, but it was pretty cool. Anyways… Let’s talk about the state of sustainability in terms of open source.

Yeah.

On this show I know we’ve talked about several ways of 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, Nadia, you’ve changed your tone in terms of 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 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 big areas that come to mind for me, or just things that other people will suggest. One is around community dynamics and governance stuff, and contribution policies and how do you structure your project in a way that’s really easy for someone to come in… And that leads to another related area, which is stuff like documentation and tooling and automation, and sort of like what are the required things that you should have in your projects, or what’s 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. I think all that stuff is a big, important part of the sustainability conversation.

Diving more into 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 compared to before, it’s a lot more.

I think there’s a lot of interesting debate in that space, just because of this tension between “Are you supporting maintainers? Are you supporting contributors? Any old contributor, paying them out…? 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. There are a lot of smaller – you know, if you pay out a couple dollars to anyone who commits a certain number of lines of code, 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 game. I still find all those dynamics very interesting, and thinking about whether funding models are actually viable or not. The question is certainly like “Well, what are people paying for? What’s worth paying for?” and I see it break down into people that are sponsoring your projects as 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… About like “Can you use a license to encourage someone to pay?” It’s just kind of interesting… I wanna be like “Meh, who knows…?”, but it’s very persistent, so who knows what will happen in that space.

Then the other big area I see is support and services, of “Yeah, can we guarantee some level of quality or responsiveness, or have your issues prioritized”, or something like that… And you’d have that kind of like be the third area of something worth paying for. So yeah, those are the areas I’m seeing a lot of experimentation in.

Yeah. I think that that’s a good way to categorize them. I will say that I’ve been very surprised by both the success and 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. 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.

[24:28] The odd thing is that almost universally these people are employed by these big companies, so they have the most – all of the unofficial relationships and all the background influence is really prevalent in all of these older projects and older 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 – we interviewed a couple people that did Open Collective stuff, and we interviewed Evan You, who did Patreon, right? And what we heard from these people was the opposite of what I thought that we would hear. So you would have people that are funding the project, and then you’d 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… But what we saw what 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; he wants to bring in new people and create a really big community, but also, he’s stable enough with his relationship to that sustainability… 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.

I’m actually using Vue now for a couple things, and I think it’s one of the most interesting – and as popular as it is right now, and as much as people are talking about it, I think it’s one of the most understudied open source projects out there in terms of sustainability. If we were still doing the show, I would probably dig in a lot more into that project, because it’s really interesting.

That interview totally blew my mind. That was actually probably one of the biggest insights I got from this entire show - the idea of “Do you fund projects or do you fund people?” I think that’s one of the biggest cultural shifts maybe, defining 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.

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?” - yeah, that completely change 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 one might play out though, because funding a person doesn’t prevent them from burning out. Just because you give me enough money to keep doing what I’m doing doesn’t mean that I’m not gonna get burnout. Does it even matter, I guess? I mean, obviously it matters, but from the sense of funding or supporting - does supporting somebody as an individual, does that inhibit your or does that stop you from concerning yourself that you’re gonna burn out, or you’re just like “They’ll do what they want”?

[27:48] 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 1) we actually have a community of people to talk about it in, whereas when you’re just like 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, we need to talk about why people are being negative; 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 deal with that negativity? One, how do they make their project not such a source of or target for that negativity, but two, just how to brush it off? It’s okay to ban people when they’re dicks, just go and do it… [laughs] 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, 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. If you were getting paid for something – I mean, I think it’s the same as any other job, where you might just kind of at some point be like “Eh, I wanna move on from this.” Within the area of community dynamics, that’s the other really big focus in sustainability conversations - just having people feel comfortable saying no to things or closing issues. The idea of closing issues is still emotionally horrifying to a lot of maintainers, I’ve learned, because they’re just really worried about like “What is the reaction gonna be if I close someone’s issue?” versus thinking about like “Well, if it’s not gonna get worked on, it’s not gonna get worked on, and it’ll make my life better just to close it out.”

But yeah, that sense of like being able to advocate for yourself and say “I’m gonna 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 I think they get exaggerated in open source… But yeah, we’re only human, we’re gonna have a finite level of interest in things sometimes, and I don’t think it’s realistic saying that someone’s gonna work on something for the next 80 years, or something.

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 the original author might not be the person maintaining it actively, but if that original author gets 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 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 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…

Right, in theory, but if people don’t know about it…

Right.

If that original author or maintainer is not transparent about how much work they’re actually doing, then… Yeah.

Oh, I see. Makes sense.

I feel like in general a topic that I’d like to see a lot more conference talks about and a lot more discussion about is how to leave, how to walk away from something responsibly. It’s actually better for the project for you to be less involved, most of the time; the more you kind of hover around, the less that other people can take on that responsibility from you… And it’s not good for you, and it’s not good for them.

[32:09] It’s actually better just to 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 gonna be in this meeting, or that?” and I’m like “No. No, absolutely not.”

That’s funny.

No, like, why am I gonna be there and just like – just being there sort of undermines the people trying to take on the work that I was doing, right? It gives a channel for everybody who’s dissatisfied with any decision to just go like “Well, I’m gonna go talk to Mikeal and do what he thinks.” Nobody wants that, 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. Andrey Petrov, who maintained a project called Urllib3, has done several transitions and he recently published a blog post about this, and I was like “Wow, I never see content about how to strategically practical tips on how to hand off a project”, so I was really happy to see that.

Well, at some point the end happens - this show, for one, and then projects, people’s term. The term is serviced, so to speak. If you’re involved in something, I don’t think you should have to commit for life; you can commit for a term - one year, six months, two years, or whatever makes sense for you and your life. I think that we should all go into something knowing that. Jerod and I, when we think about spinning up new podcasts, we don’t think “Well, these people have to commit their lives to this show.” No, maybe they’ve got three months they can give us, or 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 podcaster and the ending of a show, you know? “What will people think when 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 actually end it.

To actually end it well, yeah.

Well, let’s Seinfeld this. People ask us “How did this show do?” I think this show was really successful. I think this show did really well for not being in our main feed; it brought its own audience, and over time it did really well. I think that’s kind of how we’re ending it. I also say that we’re not ending it; sure, this is a finale episode to sort of give a nice end cap to this series, so when you go to Changelog.com/rfc or to the feed in any sort of podcast app, you see a welcome message saying “Hey, we’re gracefully closing down what we have here” and the conversation is gonna continue… So maybe this is a good opportunity to share where those conversations are happening, and maybe set some expectations that while this may be a finale to RFC, the conversation does continue on our main show, the Changelog.

So you can go to changelog.com/podcast to pick that up, or just search in any podcast app for the Changelog and you’ll find it. We have this conversation on that show, too; that’s where this original conversation with Nadia happened. This was a focused channel for exploring different perspectives in open source sustainability, so it doesn’t mean that it’s ending, but – maybe somebody takes the floor… Where else is this conversation happening, aside from this podcast was or the Changelog? Where else is this conversation taking place?

We should plug the Sustain OSS conference. The Open Collective folks put that on together, and the last one was one of the best events that I’ve been to in terms of – I mean, it was like an 8-hour version of RFC, with a lot of people in the room that you would wanna have as guests… It was a really, really good group of people and we got to talk about a lot of really good stuff.

[36:01] My worry with it was always that it was gonna be too prescriptive, but it really wasn’t. It was about everybody talking about the things that had worked for them and why. That’s a way to learn and to create a lot of new leaders in open source.

Yeah, definitely Sustain OSS. GitHub also does an event series called Maintainerati, which is maintainers getting together to talk about their shared challenges and things that they’re facing… So that’s another good channel if you’re a maintainer.

Also Nadia’s Medium highlights is another place that this is conversation continues… [laughter]

…plus some weird stuff thrown in there, but yeah. [laughter]

And I guess me and Nadia might come back on the Changelog to interview people from time to time, so… There’s a couple people that we didn’t get to that I would like to have on. If we don’t at some point interview Sean Larkin I think I’ll be upset.

Well, he got interviewed on the Changelog, right?

Right, but that was a couple years ago now, and he’s definitely –

Things have changed.

We did talk about – I think they had just launched Open Collective and it was getting steam, but it’s the kind of… I mean, Webpack is a stand-out project in many ways, and different than other projects in many ways as well, and perhaps exemplary in certain ways, and in my opinion in certain ways it misleads other projects into thinking that they can be just like Webpack… But point being, there’s tons to talk about there, and Sean’s a great guest, so absolutely having him back and having you two interviewing him on the Changelog would be awesome.

We don’t just do– we have several guests back several times. I think Mike Perham was the first fourth time guest…

Yup.

…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 and the projects change, whether it’s new maintainers or a new direction, or a conference finally, or something… Who knows. But we welcome the revisits. Those are actually sometimes a lot more fun.

This Friday we’re gonna release a show with David Heinemeier Hansson on Stimulus, and we’ve talked to him before about 10+ years of Rails, but that doesn’t mean we couldn’t have him back on. The second time around I know I was a bit more comfortable, because I felt like David’s a buddy now, versus like “Oh, DHH…” Anyways.

Let’s end by saying thanks… I mean, I know personally – I’ve personally benefitted from knowing both of you, and then playing the behind-the-scenes role I personally have in this show’s creating and execution and production, so it’s been a lot of fun 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. Mikeal, I know you’ll compliment Nadia, and you’ll back me up at least on this - your prior show notes are amazing; they should be published on their own, although I know they’re not exactly public stuff. Not that they’re bad or good, just that it’s not a cohesive end-to-end document. For people like us, it really makes a lot of sense. So those are really appreciated.

[39:11] I learned a lot of stuff from both of you, but all that to say thank you so much for working with us and caring about the community so much to put your time and effort into it, and then obviously to come back on as a finale to give a nice ending to a show like this, so thank you very much.

Thanks.

I feel really grateful also, so thanks to all of you. Having a space to talk things out - I feel like from the first conversation with Mikeal we just really hit it off and had just enough shared and different views that just having a dedicated time and space to talk about this stuff just helped us go a lot deeper and solidify our theories.

I think I told you guys this - I think Changelog was the first podcast interview I ever did. I also never listened to podcasts ever, and now coming out of RFC, not only did I actually listen to a couple RFC episodes myself, but I’m actually really into podcasts…

Yay…!

So the experience of even like recording a podcast was just a really great meta experience of being like “Wow, this is a really great format for hearing people’s stories, exploring with someone else…” Yeah, you’ve totally converted me to podcasts, which is pretty great.

That’s awesome. Anything from you, Jerod?

I will just echo whatever you’re 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. To the listeners out there who have listened to this from the beginning, thank you so much for your kind thoughts. Your time and your attention mean the world to us, so we really thank you for that, and… Go maintainers! Thank you.