Open Source Sustainability

Open source software underpins nearly every modern application, including frameworks powering the most popular websites, to the libraries securing financial backend systems. However, while open source drives collaboration and innovation at a global scale, it also faces deep challenges in sustainability, community health, and long-term maintenance. Many of the world’s most critical dependencies are still maintained by just a handful of volunteers. Abby Cabunoc Mayes https://x.com/abbycabs leads Open Source Maintainer Programs at GitHub https://github.com/, and Brian Muenzenmeyer https://www.linkedin.com/in/brian-muenzenmeyer-91a77554 is a Principal Engineer, Node.js https://nodejs.org/ maintainer, and author of the book, Approachable Open Source. Abby and Brian join Josh Goldberg to talk about what it means to build and sustain healthy open source projects, how maintainers can foster inclusive communities, the evolving role of open source in the workplace, and how AI is reshaping the way we collaborate. Josh Goldberg is an independent full time open source developer in the TypeScript ecosystem. He works on projects that help developers write better TypeScript more easily, most notably on typescript-eslint: the tooling that enables ESLint and Prettier to run on TypeScript code. Josh regularly contributes to open source projects in the ecosystem such as ESLint and TypeScript. Josh is a Microsoft MVP for developer technologies and the author of the acclaimed Learning TypeScript https://www.learningtypescript.com/ (O’Reilly), a cherished resource for any developer seeking to learn TypeScript without any prior experience outside of JavaScript. Josh regularly presents talks and workshops at bootcamps, conferences, and meetups to share knowledge on TypeScript, static analysis, open source, and general frontend and web development. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/03/SED1891-Open-Source-Sustainability.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Open Source Sustainability https://softwareengineeringdaily.com/podcasts/open-source-sustainability/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Open source software underpins nearly every modern application, including frameworks powering the most popular websites to the libraries securing financial backend systems. However, while open source drives collaboration and innovation at a global scale, it also faces deep challenges in sustainability, community health, and long-term maintenance. Many of the world's most critical dependencies are still maintained by just a handful of volunteers. Abby Kabunak-Mayes leads open source maintainer programs at GitHub, and Brian Muenzenmeyer is a principal engineer, Node.js maintainer, and author of the book Approachable Open Source. Abby and Brian join Josh Goldberg to talk about what it means to build and sustain

• 0:45Speaker 00

  healthy open source projects, how maintainers can foster inclusive communities, the evolving role of open source in the workplace, and how AI is reshaping the way we collaborate. This episode is hosted by Josh Goldberg, an independent, full-time, open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES-Lint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling.

• 1:26Speaker 00

  Find Josh on Blue Sky, Fostadon, and dot com as Joshua K. Goldberg.

• 1:44Speaker 01

  With me today are Abby Kabunak-Mays, who runs the open source maintainer programs at GitHub, and Brian Muenzenmeyer, principal engineer, Node.js maintainer, and author of Approachable Open Source. Abby and Brian, welcome to Software Engineering Daily.

• 1:56Speaker 02

  Hey, thanks for having us.

• 1:57Speaker 03

  Thank you.

• 1:58Speaker 01

  I'm excited to talk to you two about open source and books GitHub. Abby, can you start off telling us who you are, how you came to lead the OS maintainer programs at GitHub?

• 2:07Speaker 02

  Yeah, so hi, my name's Abby. I live in Toronto, Canada. Go Jays, go. A little bit sad, but I actually started my career writing cancer research software. And it was really meaningful work for me. My grandmother had passed away from cancer, so I felt like my work was really helping other people's grandmothers. And that's when I really saw the power of open source. Like, the software I was using enabled these researchers in Japan to collaborate with data scientists in the UK. And like, this is how we do real innovation and how we really solve the world's biggest problems. So that's when I shifted to thinking about how can I help more scientists do open source? So I joined Mozilla Science Lab when they launched.

• 2:47Speaker 02

  And for a long time, I was like, just helping the open science community just collaborate better and do more open source. Slowly, my role shifted to be more about open source generally. And that's when I joined GitHub, because I think this is the best place to be to really help the open source community during this critical time, especially with sustainability, we'll be talking about soon. But how can this community really thrive? And lead to a strong ecosystem where we can actually rely on open source together as a global world and just have the best innovation that we need. So yeah, that brought me there. I'm also on the board of the OpenJS Foundation. And I'm one of the organizers for Sustain OSS, so I care a lot about this topic. And yeah, thanks for having me, Josh.

• 3:26Speaker 01

  Clearly, it's a topic that all three of us are very passionate about. Brian, how about you?

• 3:30Speaker 03

  Hey, thanks for having me, Josh. My name is Brian Muenzenmeyer. My journey into open source started probably like a lot of folks with consuming open source software to do my day job as a web developer, messing around with jQuery and jQuery Mobile and maybe dating myself there. But inevitably, I found a bug or like a missing thing in some documentation. I think I got my feet wet there. But what really, I guess, exposed me to more and more of the community and the patterns was when I got involved in the kind of like early component and design system language toolset. I worked with Brad Frost.

• 4:08Speaker 03

  On Pattern Lab for years and I actually forked Dave Olson's really fantastic PHP work into Node JS, mostly because I was just some punk who didn't really know PHP at the time and I had trouble running it on Windows and I just didn't know better. But that exposed me to so many interesting challenges and patterns over the years and becoming a maintainer of a larger and larger project as people start using it for their own careers and their own sources of income was just kind of enlightening and frightening all at the same time. That open source work eventually led to my current employer actually using it and inviting me to see how they use it, which is really, really exciting. And that turned into a job offer and like moving my family to a different state and all that fun stuff.

• 4:54Speaker 03

  Much like Abby, my work has evolved over time to care about the actual work, but also kind of changing to this meta level of caring about open source as a practice or as an ecosystem and industry. When all these things kind of in total equal this book that I ended up writing and releasing last year. And now going on tour a little bit and talking about across the nation. So it's been an interesting journey so far.

• 5:19Speaker 01

  And Abby, your name is on the book as well. You're on the back cover.

• 5:22Speaker 02

  I'm on the back cover? Oh, I am. I forgot about that. I have the book right here. I'm holding it. No, it's a great book. Very happy to be a little bit involved. And I actually met Brian when I was at Mozilla. He went through Mozilla Open Leaders, this program that I was running around. This open source leadership and just I wanted to see more people doing open source really well and learning best practice and sharing with each other. So it's great to see Brian continuing this work. And yeah, writing a book.

• 5:48Speaker 03

  Thanks. Abby is also interviewed in the last chapter of the book too. So we might get to that, but her part in this was not just back jacket blurb. Your insight was super helpful along the way.

• 5:59Speaker 02

  Yeah, thanks, Brian.

• 6:01Speaker 01

  All right. Well, let's dig in. I'd like to hear from each of you. What is your perception of the definition of open source? There is a literal definition and then of course there's the practical definition and the implications of it. So let's start with you, Brian. What is open source to you and in the industry?

• 6:14Speaker 03

  If someone asked me that, I'd probably say it's free code governed by some kind of license. And that is like the shortest, shortest version, but one of the things I tried to establish early on is that it has transcended that kind of very terse definition over the years. And now I'd also mix in community as something that is In its highest, most mature form, really on equal footing, right? As the source code or as the license, it really has the use cases at all, right? That we're creating spaces where people are actually working together on solving problems. And that's truly an equal part of modern open source software development to me is that community aspect.

• 6:57Speaker 03

  So that's my hopefully short version of what it is.

• 7:00Speaker 02

  Yeah, I completely agree with you, Brian. I think there's the technical definition, the legal definition that the OSI stewards are like using one of these licenses. But then I think, yeah, open source is a movement. And I keep coming back, I think especially now at the rise of AI. I think open source truly is about people collaborating together. It's like people finding a group that they want to work with and write code together. And even back to when I was doing that cancer research software, like it was about these researchers coming together from different parts of the world and just making something that they couldn't have done on their own. So I think that's the beauty of open source that's enabled by that legal definition and why it's so powerful.

• 7:39Speaker 03

  Right, finding your people, right? Finding people that care about the same thing you do, right? Is such a huge unlock. And I, I can remember this moment, maybe many moments for me, when I was working as basically a team of one UI UX developer in like small town Wisconsin and then finding through the internet that there are other people that really sweat the small stuff of design or typography or whatever. Like there's obviously like tons of people who care about this, but if you're very separated geographically from those folks, like this is such a obvious manifestation of collaboration at scale, right? And we're able to connect with one another now. It's so great.

• 8:20Speaker 01

  We've talked about the beauty of it, but open source, of course, is not all fun and games. There's a famous XKCD comic, which is in fact referenced in the book. Abby, do you know which comic I'm talking about? Do you want to explain why it's so pervasive in discourse around open source?

• 8:34Speaker 02

  Yeah, I actually know someone who got it tattooed. Shout out to Justin Dorfman.

• 8:40Speaker 02

  But it's it's a comic where it's like this precarious block standing on top of each other. And it's like this huge structure. And then there's like this tiny one little piece that's holding the whole thing up. And it's people call it the Nebraska problem. They're saying the entire open source infrastructure. And then this one tiny piece is maintained by a solo developer in Nebraska. I think that's the comic you're referring to, Josh.

• 9:04Speaker 03

  Dependence.

• 9:04Speaker 01

  Absolutely. But that does really happen quite a lot. We've talked about community, but there are also quite a few projects where it's one person in Nebraska, perhaps named Nick Nisi, or it's a couple of people here and there who trade off ownership. So how do we have that balance in open source between we have these lovely community efforts which really draw people together, then you also have that isolation? Like, how does that develop?

• 9:26Speaker 03

  I almost want to ignore your question and actually refute the brilliant XKCD that I think it's almost like a required reading or required visual in every open source talk at some point. Recently, at All Things Open, I actually took that and turned it on its head with a brand new image. And we'll see how well this comes across. But the picture that Abby painted of this like precarious tower that could fall at any moment, I think is actually not the complete picture of what open source software actually looks like. Because if you zoom out and you think about, oh, that one block might be brittle

• 10:07Speaker 03

  or be in threat of replacement. One of the things that seems to always happen when the community encounters a problem, is that the community steps in and fixes it as well. And together, we create an even larger composite. And the image that I've kind of crafted is of not of this tower, but more of this like masonry wall, right? Or this masonry, maybe potentially equally as confusing for folks. But there's resilience in all of that composition. And that's where I like to actually change the conversation and say, like, we're not nearly as precarious as we think we are, because we always find a way to work around

• 10:50Speaker 03

  or support one another when those weaknesses are discovered, right? So I don't even remember what your first question was. But I kind of like to use this as a nice sounding board for like, people like to doom, or like, what's the right word? Be, someone help me, right? We try to come up with like a

• 11:09Speaker 01

  Naysay?

• 11:10Speaker 03

  Just a, yeah, like a very negative connotation about this Nebraska problem, right? And I think it's actually, there's more nuance to it than just like these precarious towers.

• 11:20Speaker 02

  Yeah, I love this image that you painted, Brian, and I'm gonna have to check out your All Things Open talks. That's really nice, because I do think, yes, there are quite a few single maintainer projects out there in the world, especially in the JavaScript ecosystem. But they still exist in a community, like different people use them. You still have users, you still have like a whole ecosystem of software around what you're doing. And people will step in and help. It's not quite as solo as it seems from that, but no, that was beautiful, Brian.

• 11:49Speaker 03

  Maybe it's like a squeaky wheel gets the grease kind of thing, right? But I've observed conversations where people are like, well, this is still working, so I'm not going to step in. And, you know, I don't know if folks are waiting for failure before they come in and support. So maybe that's where there's still room for lots of improvement, right? Because we can be making those brittle towers stronger before they collapse, right? Like, we don't need to wait for the Jenga tower to fall over before we start to make it stronger. And hopefully, we can figure out how to do that. And I think there's a lot of experimentation going on all the time to, to advance that idea.

• 12:25Speaker 01

  I love that. That really is a heartwarming perspective. Thank you for, in a very positive sense, refuting and partially ignoring the original question. I agree with where you took it. Let's talk a little bit about that engagement then. A lot of open source projects have certain, you know, guidelines for how to contribute. They have different levels of users, you know, the people who just use it without looking at the source code, all the way through to the maintainers. Abby, could you tell us, what do you see as kind of this different spectrums or levels or ways that folks, in your experience at GitHub, tend to interact with projects?

• 12:56Speaker 02

  Yeah, I do see it as, there's a couple of frameworks I've used to talk about this. That people talk about like contributor funnel, Mike McQuaid had a great blog post about that. I like to think about the mountain of engagement, usually that's a little bit later on. But yeah, yeah, people who just know about the project, maybe they've never used it. Maybe they use it a bit, they've interacted a bit, maybe they start it on GitHub. And then you can go slower and slower down that funnel to like, maybe they start contributing. They open an issue, they join the Discord, and they've sustained contribution. Maybe they make a couple pull requests, they stick around in that community. And then eventually you want them to like take on some leadership roles. So now they're starting to review some other pull requests, they're helping onboard new contributors. They're starting to run the project.

• 13:42Speaker 02

  So there's a large spectrum of how people can interact. And ideally as a maintainer, I think what we want to be doing is like helping people move down that spectrum. Not everyone's going to become a maintainer, but making it as easy as possible for people to see that next step. And being in a space where you can identify people who could be great maintainers and just like holding their hand through that pathway.

• 14:05Speaker 01

  It's interesting you bring up Mike McQuaid's very excellent blog post about the open source contributor funnel. In traditional tech industry user work, there is the concept of the user funnel. You know, how people discover your app and then the little attrition points and on the way. And there, it's a kind of incredible how many parallels there are between getting someone to contribute or even maintain an open source project and getting a new user onto a product.

• 14:26Speaker 02

  Yeah, well, I think both of them have to deal with like human behavior, but also a bit of like just removing barriers to help people go down that funnel and go through. I know before the podcast, we were talking a little bit about Disney, but I used to use Disney as an example of like, where's a place that you felt really welcome and what did they do to do that? And Disney is like super good at that. They lay things out so that things are really welcoming. You have like the map there, you turn a corner, then there's the big castle and you're all wowed. But like, what can you be doing with your project just to make people feel welcome? And think about that hospitality and how people will want to be engaged and then like stay engaged and keep going. So there's a lot of parallels with like marketing and hospitality and all of these things.

• 15:10Speaker 02

  Not to think of like your contributors as just numbers going through, but thinking about them as people and like, how can we make them feel welcome and want to stick around in your project?

• 15:20Speaker 03

  I wanted to say too, and this is creating like point number two of two where I'm like, this is all wrong, but I'm concerned that like the mountain of engagement idea, the funnel idea kind of like distills people down into this like they must grow in their role in order to be useful, right? Or in order to have an impact. And when I think about the spectrum of engagement, or I think about casual contributions, I think projects really need to be creating those outlets for people who have a particular skillset that they want to bring to that project and maybe only that skillset, right? And I see this on the Node project a lot, right? We have excellent web developer contributors

• 16:05Speaker 03

  who sustain the website and care deeply about that, but they might not care about the core runtime whatsoever, right? We have a whole bunch of people who help translate the content that we provide to, and like they're offering their skills in a way that makes sense to them in that current arrangement. And I think projects that can identify those things and maybe not necessarily like you don't have to funnel them into a leadership role, right? To me, that's a huge unlock too, because it creates a lot of expectation on both ends, right? To try to keep identifying these like future maintainers, but also to someone who's trying to casually contribute or improve their mastery of a

• 16:47Speaker 03

  certain skillset. They don't have to be as invested in the totality of the project. They might just be excellent at a particular thing and we want to court them and support them in that task as well.

• 17:00Speaker 02

  No, a hundred percent. I think for casual contributions, especially things like you mentioned localization, but like release testing, that's another good one for casual contributors. Definitely you don't want everyone to become the maintainer, especially the lead maintainer of your project. But what I like about these frameworks is it helps you identify the people who you should be investing more time in to become a future leader in your project. So you can be a little bit more strategic around who you mentor and what you do, but definitely don't forget about all those casual contributors. They contribute so much to projects. Definitely agree.

• 17:35Speaker 01

  If anything, it's healthy to have a spread of contributors. People who come in with that fresh perspective of, "Oh, I'm just here for a little bit. I don't have the full context," making sure that they are able to contribute. That's a healthy part of maintenance, right? All right, well, let's talk about that a little bit. Brian, your book, let's move on to the next chapter or two. You have a chapter called "The Four Files of Any Open Source Project." First of all, well done on making that chapter four itself. Second of all, what are those four files? And how do they help in this context?

• 18:04Speaker 03

  Yeah, and there's a whole host of potential files to choose from. And I tried to distill or choose if I had to force rank, like what matters most at the beginning of a project. So those files are a readme, a license, a changelog, and a code of conduct. Right? And if we want to walk through each, we certainly can. Like a notable omission is like a contributing file, right? And there's probably others too, right? You could talk about like a funding file or some projects do like a notice file. It really probably depends on your language or your ecosystem, maybe. But this is where we started. I think the readme goes without saying is like something that should be the entry point into any project.

• 18:45Speaker 03

  It probably has a lot of different stakeholders to balance all at once. And there's a little bit of art and science to trying to find the right fidelity of information when that's the front door of an entire project. And that's where like, when you're starting out, you can easily add your contributing guidelines there. You can add your entire API surface. There's projects that do it all the time, and it's fine. And then as you grow, you might want to evaluate, "Oh, do I need an entire website to cover this?" Right? It's probably a lot easier to localize and index on a website as you add more and more files, right? But for smaller projects, GitHub rendering, awesome, right? Why wouldn't you want to just use a readme or something like that?

• 19:26Speaker 03

  And then, you know, we move on to a license, which is a part of that like legal definition that you must have. And that's probably the best way to distribute your intentions and to communicate how someone can use something, of course. And using implies that people need to know how things change when they change.

• 19:45Speaker 03

  Change log and we can go into some of that detail if we want to, but I definitely want to emphasize the code of conduct, kind of back to the initial thematic new definition of open source for us is like, it's about community. It's about how we interact with one another and how we can do that constructively and civilly. So a code of conduct to me is a must for a project as well, any size.

• 20:08Speaker 01

  Brian, I would like you to, for a third time now, shut me down. Why do we need a code of conduct? Why is that important?

• 20:14Speaker 03

  Well, I think it's important because not everyone has the same definition of what is acceptable behavior or not. And it doesn't take a lot to go awry if we don't have that set of shared expectations upfront, right? And like, pretty much any public place you go has some notion of what is acceptable conduct or not. And open source communities should be no different, right? And the best open source projects not only have a code of conduct, but also governance and like a incident response plan,

• 20:52Speaker 03

  like an entire moderation team that can help enforce that code of conduct and actually provide thoughtful, careful, I guess, enforcement of that code of conduct. So it's not enough just to have one on file, you need to be prepared to enact it as well.

• 21:07Speaker 01

  Abby, I'm curious, you've done quite a lot of work in leading communities, both in direct open source and then areas that use open source, like the scientific community. How have you seen kind of the role of community or how engagement in those open source project change over time? Do you feel that as we've developed and understood things like the code of conduct file practices have kind of evolved and if so, in a good way, I hope?

• 21:29Speaker 02

  Yeah, no, I think it's definitely been good for the community to have these codes of conduct. I think with the rise of the internet, something I've noticed is it's very easy to spin up a quick community. Like you can get people excited about something and they'll all jump to your project or they'll all jump on that issue. But then it's not always a lasting community, like the first disagreement that community might like fall apart. Thinking of, there was like the March for Science. It was very exciting. People came together. They did a big march for science, but then we didn't hear too much about it afterwards. Like it didn't last very long. And I think what things like the code of conduct and just any structure for that community helps with is just making sure the community is a bit more resilient to this.

• 22:13Speaker 02

  So not just code of conduct, but also things like governance, just like how does a group make decisions? How do you work together? How do you work through hard decisions? Code of Conduct is very helpful. So having these best practices like Code of Conduct's governance can make sure that your open source project lasts longer term. It isn't just a flash in the pan of people who get excited, jump in. And then as soon as there's like a rift in the community, you have a fork or, or the community just implodes. But yeah, it's just the kind of guardrails you need to keep something longer term.

• 22:47Speaker 01

  Let's say that I've got a burgeoning new open source project and I'm starting to get people interested in it and I'm very excited about this. I have no idea how to build a community. All I wanted to do was write code and now I have to manage people yelling at each other. What do I do?

• 23:02Speaker 03

  I think that you should allow yourself on some level to let users interact without your involvement. Like give yourself a little bit of grace to say that you don't always have to be the person in the middle, the benevolent dictator for life, right? And like, it's easy to say that, right? And it's almost like a refutation of what we were just talking about with codes of conduct. But I think it's essential for your own survival sometimes to be able to walk away and not get emotionally attached or engaged in conversation. So that's my first bit of advice, but it's of course easier and that's a little bit contingent on having other people that you can trust.

• 23:45Speaker 03

  More maintainers to share the load or rotate out responsibilities as you go. But you know, it's a great problem to have when you have users or people coming to your project and starting to have differing opinions. Knowing what your project values are, what you're willing to compromise on or not. Like on a technical level, that's easier than when people disagree because of culture or age or differing use cases that they care about, right? It can get complicated. But I guess I want to start from a position of, especially when you're early, early on, I don't think that you have to have it all figured out right away.

• 24:25Speaker 02

  Yeah, and I'd say it's hard for new maintainers who have never managed a community before. So I'd say find other maintainers where you can talk about these problems. Do you have maintainers github.com? Just a little shout out to my day job. If you want to talk to some other maintainers. But if people are yelling at each other in your project, that means they care and they want to see this succeed. So often, I think like Brian was saying, like figuring out what is it that you're all working towards? Like having that clear vision or mission of what you're doing can help with a lot of these things. And then from that, figuring out just a general roadmap so you know what you're not compromising on what you are. Like this is what our plan is. Anything outside of this isn't part of it. So just to make it a little bit clearer and something to point to.

• 25:10Speaker 02

  But yeah, find other maintainers, I'd say is my biggest piece of advice because it is tough to do that on your own.

• 25:17Speaker 01

  I'd like to drill into that, actually. As a maintainer myself, I've found that one of the downsides of my independent work is that it's so difficult to find other people. And even when I do find them, none of us are working for the same company. There's no HR or manager or some such unifying guest. So let's say that I've got a few maintainers. What do I do with this contact? Or how do I build a community around myself in this kind of space?

• 25:39Speaker 02

  With other maintainers or like with your open source project community?

• 25:42Speaker 01

  Let's say either or both.

• 25:44Speaker 02

  I'd say with other maintainers, it's like, there's this like lean coffee framework that I think started with founders. Just like founders coming together and sharing their struggles and then learning from each other. Taking something simple like that. It's like, hey, we're all maintainers, like what's going well with your project? What are you struggling with right now? And then after you hear what everyone's struggling with, like what advice do you have? And you can just go around. I find something like that's the easiest way to get value out of like the maintainer to maintainer conversation. But yeah, I'm curious to hear what Brian has to say for this answer.

• 26:19Speaker 03

  I was thinking about this in the lens of foundations, right? What I mean by that is like the OpenJS Foundation, the Linux Foundation, CNCF, right? Like Apache, all of these exist to advance all kinds of things, but they do create communities of communities, right? And what's really great about that is then you are kind of swimming in the same territory as people who are managing projects as well. And a lot of them have these meta governance level groups. And even if like your project isn't at that incubation level or impact level of some kind of major project, I can almost guarantee that you can find those very public like

• 27:00Speaker 03

  foundation level Slack channels or Discords or online spaces that you would be able to find people that have the same kinds of problems that you do or challenges that you're looking to overcome.

• 27:13Speaker 02

  Yeah, I should have shouted out OpenJS Foundation. So thanks for that, Brian. But like, that's nice because it's all like JavaScript project, TypeScript projects. So there's, you have that shared experience, so it's good.

• 27:26Speaker 01

  I would also like to shout them out. I was embroiled in a conflict at one point and the OpenJS folks, because it was on one of their projects, did come in and help us. They had kind of a mediator come in, try to figure out the perspectives of all the sides involved. It was very nice to have that. So thanks, much appreciated.

• 27:42Speaker 01

  Great. Well, let's move on to the next chapter. We're getting to sort of the end, the last couple in the book, and I want to talk about two more monetarily oriented parts of it. One is the workplace. So Brian, open source in the workplace is a very broad chapter title. What does that mean to you at first gut instinct?

• 27:59Speaker 03

  Yeah. I mean, you know, I think the, a large central theory of the book is to equip people with enough knowledge about where they fit within the open source ecosystem. And just like we talked about that XKCD, about dependencies, in any recent open source talk, there's this Harvard Business School quotation that's like $8.8 trillion of demand side open source value, right? Trillion with a T. And then there's also kind of like complementary stats about how ninety some percent of all production software is of open source origin, right? So when we talk about open source in the workplace, it's almost a guarantee that people are using it daily to accomplish their their jobs.

• 28:44Speaker 03

  And that could be an end user using, you know, software or hardware that they're working with. It could be a software engineer or some kind of technologist actually, you know, interacting with programs and libraries. Really, what I try to impart, especially in this chapter, but throughout the entire book, is that you don't need permission to do your job, right? We're consuming all this open source software. And that's not a one way door. It's not a one way path, right? We can be participatory in this ecosystem as users, as maintainers, as contributors, as mentors, kind of all along the spectrum of engagement, whatever it might be.

• 29:25Speaker 03

  Because like, you're not insulated from the changes within the ecosystem anyways. So wouldn't it be nice to actually influence it as well? So this chapter also covers like, how to do that? How do you start? How can you experiment, right? How can you, as Abby reminded me before the call, instead of like paying someone with like a cup of coffee or a tiny little donation, you could invest a cup of coffee's worth of time into a project that you use at work and read their issue log or, you know, corroborate a report that someone else had. You could, you know, test their their recent release and see if you can upgrade in your own codebase, right?

• 30:07Speaker 03

  You can do all these kinds of things, try to make a little bit of a dent or impact on this thing that we all are a part of, even if we don't realize that we are.

• 30:17Speaker 02

  And I do think we need more people contributing to open source during their work hours. So whatever little thing you can do, I think makes sense. And it's something I've been thinking about, like how to help people justify their open source work at work. Because it's often overlooked in terms of like promotions and your impact, where the real impact is so huge. So that's something I've been thinking about, don't have good answers. But if people have suggestions of what we could do, just to help people show their impact in the open source world to their bosses, I would love to help enable that.

• 30:52Speaker 01

  It's an interesting aspect of what you, your role at GitHub and open source maintainer programs encompasses. You're not just here for the independent kind of hobby side maintainers. It's also for the people doing it for work, or even for when there's a project, like say TypeScript, that's founded and funded by a company, or something like, no, that's a huge foundation on its own. Have you found that the ways that people need support across these very different types of project types have similarities or differences that have come up?

• 31:19Speaker 02

  Yeah, well, they're very different, especially when thinking about open source sustainability. Like what one project needs or what model that could work for them doesn't apply at all to a different project. But I think across all of them, what I am seeing is that open source is a human problem. Like it's about the people working on these problems together. And it's not necessarily solved by like throwing money at it. Because it's not money that's reviewing pull requests or making a commit. It's people doing this and like money doesn't always take, it helps a lot often, but doesn't always take away the different blockers people have, especially in workplaces. So yeah, I think that's a similarity I've seen where it's still about enabling the person,

• 32:02Speaker 02

  no matter if they're an independent contributor or they're part of a giant corporation.

• 32:07Speaker 01

  We were talking about parallels with product work, so I've broken another parallel and asked you to do this. If you had a magic wand and could wait and make one thing better to support people doing open source in the workplace, what would it be and why and how?

• 32:22Speaker 03

  Yeah, I think, I don't know if this is, if this counts as like a material magic wand, you know, output, but I wish that people had more confidence to just try it and be able to go brag to their team about what they learned and be able to more tangibly point to that stuff and have it, have it stick, right? And I think that maybe it's just kind of Pollyanna-ish to like, think, oh, like, if we just try it, it'll work, you know? But it's true that like, the work that you do, or the, the things that you're exposed to have this like osmosis level effect or imprint level on like your awareness of what people are doing in the industry, you know, beyond your four walls, right? And

• 33:07Speaker 03

  like, people need to have enough confidence to communicate that and say, oh, I just spent two hours doing not my story, you know, not the thing that's on the backlog, right? And look what I learned. And to me, that takes a little bit of courage, especially in a tough environment, but that's what has, in my mind, the most, the biggest magical chance of like, changing hearts and minds over time.

• 33:36Speaker 02

  Yeah, I think for me, magic wand is nice because I think this would require like real systematic change, which would be really difficult and tough to come about, but like more corporate support for open source, whether it's money or, or incind, especially in these lean years where there's like so many layoffs and budgets are being cut. We're really seeing that it often feels like a very extractive relationship with corporations, um, just taking a lot of open source, using a lot of open source and not always giving back. And they're not always incentivized to do so. So magic wand would be they all suddenly realize, like, oh, I need to contribute to open source. I'm using so much. I need to contribute back to it. How to do that is what I spend a lot of my days thinking

• 34:19Speaker 02

  about, but magic wand would be great.

• 34:23Speaker 03

  Yeah, you helped me maybe get to a more concrete magic wand answer, and that is... Equipping open source program offices with a data set that marries their production usage of whatever dependencies they're using with open SSF criticality data. There's a public data set that is, it's like so big, you can't even put it in Git. I've tried, it's huge, right? But if you can create that intersection of, oh, boy, we use Kubernetes for everything, right? If the health of Kubernetes degrades, it degrades our business. Arming people with that kind of information speaks the language of business, which is risk and risk management.

• 35:08Speaker 03

  That, I think, is something that has been on my backlog for a long, long time and is like, I'm not equipped as a front-end engineer to build that. Like, I need, like, data science power. I need people who can, like, you know, do that together and then make an executive summary report that is on the desk of every CTO that says, dang, you're using all this open source software. It better keep working. And this is how you can help upstream in kind with time, with money, et cetera.

• 35:37Speaker 02

  No, I really like that. And I think with the GitHub Secure Open Source Fund, which they get a lot of funds from various funders, from various companies often, one thing that they noticed was because of this narrative around security, they were able to unlock a lot of CISO budgets. Whereas before, and a lot of these open source foundations, they're taking from marketing budgets, sometimes engineering, but security is where, like, this has an actual effect. So, yeah, I like your answer, Brian. Let's use that magic wand. We'll combine our two together.

• 36:07Speaker 03

  Love it.

• 36:08Speaker 01

  It's a big ask. We'll need two wands for this one.

• 36:10Speaker 02

  Yes.

• 36:11Speaker 01

  I'd like to be devil's advocate. Any one company does not directly benefit from funding its open source software from a security perspective all the time. Perhaps there are small tickets that they want funded that they can sponsor, but any one company, let's say, donated to Kubernetes, if it's a smaller company without a huge budget, might not be able to really influence the project. So it's almost, I see it as kind of a tragedy of the commons where if you don't get direct applicable tie-ins from sponsoring, it's kind of hard to advocate it for it. So why sponsor in the first place?

• 36:45Speaker 02

  And that's why I think about this problem all the time. They don't have good solutions.

• 36:50Speaker 03

  It's almost like a litmus test for like people's propensity for socialism. Right. Or like altruism or something like that. I think of open source as like an aquifer. Right. Like if you drill deep enough, it is an extractive set of technology or resources that you can just take and take and take and take, right? But it's not going to replenish from you doing that. Right. And like, there needs to be ways that if someone's doing that at the scale of, you know, a scary, scary manufacturer that's just bottling up all of the the open source water that we have. Right. Like, it'd be nice if we knew that. And it'd be nice if we could offset that with, I don't know, we're getting into like all kinds of torched analogies about

• 37:36Speaker 03

  climate change and carbon offsets and stuff, but like, it'd be nice if we could offset that extractive behavior with ways in which that water cycle could, you know, actually sustain itself.

• 37:47Speaker 01

  There's an interesting delineation you just made between true socialism or market socialism as described and altruism, where neither truly incentivizes companies economically to do this, but they both come out of from different sides of trying to find ways to do it.

• 38:03Speaker 03

  And I'm gonna name drop Chad Whitaker from.

• 38:06Speaker 02

  Open Source Pledge.

• 38:07Speaker 03

  Yeah, Open Source Pledge. And then he's also done Open Path Podcast, or it's like a video series, right? And at one point, he interviews an accountant and they spend a lot of time trying to describe to the accountant why a company would ever, ever support this. And it's, it's almost like logic breaking, like we don't have the right terminology in business to even describe the work that we're all doing here in the open source ecosystem. And that's, it's a really interesting perspective on it. So I encourage people to check that out.

• 38:40Speaker 01

  For the sake of our listeners, what is the Open Source Pledge?

• 38:44Speaker 02

  I think the details is the company pledges to give 2,000 a year per engineering employee that they have as a minimum. So there's several companies that have signed up. I think it's great. We need more people giving more money to open source. I think it's, this doesn't quite solve that incentive problem. I think it's, again, it's a bit more altruistic, which is why I want to see more. More things in this space just to help with getting money to open source.

• 39:11Speaker 01

  Sure. And you also made the point earlier that money is not the be all and end all to to solve these issues. There are the real human issues in open source sustainability that we have to address as well. I've always thought it would be nice if we had some sort of restaurant health grade system where you could very definitively say this company donates, you know, a B level or a D level to open source and have that be part of their employee branding and marketing efforts.

• 39:34Speaker 03

  Yeah, that'd be great. And I know that some companies have very, very public, you know, community give back style parts of their mission, right, or of their total outreach into communities. But it's like physical communities that they might be, you know, present in, right? And they're also a part of digital communities that, you know, maybe they can be more expansive in their definition of how they show up.

• 39:56Speaker 01

  I'd like to have one last technical area of discussion for us. It's hard to have a podcast in 2025 or 2026 without some mention of AI. How is AI starting to impact, affect positively or negatively open source maintainers, programs, sustainability and so on? And I'll start with you, Abby, because GitHub's had quite a lot to do with open source and AI recently.

• 40:18Speaker 02

  Yes, I think AI is it's pervasive. It's everywhere. We see generative AI for everything. I know you were asking ChatGPT things before this interview started. And I think what I'm seeing is that, like, maintainers especially, they see both the opportunity and the challenges of AI. Like, it is very helpful when you're writing code just to have or just helping with frameworks and getting started. They see the value there, but then they're also feeling the brunt of the the downsides. They're seeing the AI slop, a lot of spam coming through. And the lowered barriers is making it easier for people to just generate more spam, I guess. So, yeah, it's changing the landscape. I think it's. I think we need to find a way to use AI, but also mitigate a lot of the challenges that are there

• 41:03Speaker 02

  because I don't think it's going away. So I am encouraged by things like using AI to detect AI spam and AI slop. I know a few of maintainers have done that and are using that. It seems to be helpful. But like, how can we leverage this tool that is very helpful while not taking away from the human part of open source? Because I think it is still about like humans coming together and collaborating. I don't think AI can replace that, but AI can just help enable that a bit better. So I love seeing examples where people like start a pull request where AI takes it 80% of the way, and then it leaves space for contributors to come in and just finish that off. So it's still about people collaborating, and I think AI can help with that.

• 41:48Speaker 02

  But there is a lot of slop out there right now, so pros and cons.

• 41:53Speaker 03

  To build on that, I think I've been a recipient of AI slop, but I've also been, yeah, I've seen people use it to help communicate better because English isn't their first language, right? And like, that's, it's another tool in the toolbox that helps people connect in one way or another. I've used the GitHub like agentic tool myself on a project where someone reported a feature request, and I like clicked the button, like, oh, hey, Copilot, can you try your hand at this? And it like totally knocked it out of the park, right? It took like 11 minutes, and I could see everything it was doing, and it like updated the tests and updated the readme and updated the environment variables that we needed in the GitHub action that it was.

• 42:37Speaker 03

  And like, it did all this cool stuff. And like, I couldn't have written it in 11 minutes, right? And it was enough for me to take a feature request to a proposal on how to fix it in just mere minutes, right? And like, what a cool unlock for people who are busy, right? And like, every project, every product team on the planet has a backlog that is longer than their ability to actually address it. So that's where I think there's a lot of potential for AI to help accelerate teams, not replace them, you know? And it's really easy to

• 43:17Speaker 03

  Probably focus on on bad news that we hear and not not think about all the ways in which it is working out for us.

• 43:24Speaker 01

  It is very tempting to hate on AI, but especially the increased ability for people to communicate. I've also found it's it's really lovely to watch something like Copilot in action when it tackles a good first issue, to see it as it goes through your contributing and development guides and kind of reads through and understands it the way a junior developer might. I found it to be rather helpful to figure out what needs to be addressed in those guides.

• 43:46Speaker 03

  If it gets stuck, right, that probably means humans are too.

• 43:49Speaker 02

  No, yeah, I've seen people really clean up their documentation because of Copilot because it gives them so much better results. I think that's a good side.

• 43:57Speaker 01

  When you think about it, many, perhaps all the things that make for a good AI source or context in a repo, such as good documentation, a type system and so on and so forth, also just help humans. And humans and AIs are reading a lot of the same sources of information. So it's kind of hard to optimize for one without also helping the other.

• 44:15Speaker 02

  Yeah, I think the Octaverse report just came out where TypeScript surpassed Python. And one of the big reasons that our analysts thought was because AI does a lot better with typed systems. So TypeScript just made a better choice.

• 44:29Speaker 03

  Yeah, I was gonna say that for years, there's been this like really great Microsoft like accessibility PDF that goes around about like the different kinds of accessible challenges that people might have, like if they're temporary or situational or whatever. And like the overall, I guess, gist is that like accessibility benefits everyone, not just people that are, you know, differently abled, right? Because you might be holding a baby with one hand while you're doing something or whatever, right? So I think in the same way that accessibility benefits everyone, you know, AI can kind of be this this window or lens into benefiting projects too.

• 45:04Speaker 01

  One of my favorite little pieces of trivia is about the origin of the term curb cut and subsequent electronic curb cuts. The concept of a curb cut, it's a little ramp in a sidewalk to make it easier for people who are, say, in a wheelchair. And that's just fantastic for everyone, you know, so you don't trip. So if you're carrying a lot of stuff, you don't hit the sidewalk. Now we have this curb cut effect that we're seeing, not just with accessibility, where, say, better color contrast on a page makes for a more readable page for everyone, but also for AI, where better documented repos make for a better documented flow for humans as well. It's kind of lovely to see.

• 45:36Speaker 02

  Yeah, I didn't know about that curb cut story. Yeah, thanks.

• 45:39Speaker 01

  Cool. Well, we're running short on time. Is there anything else either of you, I'll start with you, Brian, would like to add about open source or sustainability or the workplace or any of the topics we've talked about so far?

• 45:50Speaker 03

  So something that I think about a lot and maybe this kind of like kumbaya mode of, you know, like there's a place for all of us here is this notion of paste layers. I've talked about it a couple of times and it's not something I came up with, but it's a man named Stuart Brand has this like really great like infographic about concentric circles and like call it kind of gravity or paste being different where at deeper, lower levels, things move slower. And he's modeling like all of civilization when he talks about this. And you think about like nature and glaciers and like really slow things, right? And all the way up to like governments and commerce and buildings and fashion like being really fast, like fast fashion and like trends and fads, right?

• 46:35Speaker 03

  I have a blog post somewhere where I talk a little bit about this applied to open source software and how we need all those layers to be in contention with one another or in compliment with one another. And it's a worldview that allows us to never really like be in conflict. Because if a new framework comes along, a new paradigm, something, you know, we want to explore a new way to do something, AI is a great like disruptive example, right? Like we're figuring out things at a pace that is just like almost impossible to sustain or to keep track of. But that's okay, because the best of those ideas will start to be pushed down layers

• 47:17Speaker 03

  into more and more kind of solidified pieces of how, how we do things, right? And why that excites me is because it allows you to find your layer within the ecosystem that we are a part of. And if you care deeply about, you know, API stability or specifications, like we need people thinking about that resilient, you know, standing the test of time kind of work. As much as we need people thinking about runtimes and frameworks and libraries. And playing around with new things too, because we can't really have one without the other. And there's no like flame wars or churn that you need to like concern yourself with.

• 48:00Speaker 03

  It's more about finding the outlets and the energy sources that resonate with you. And then, you know, showing up there. So it's a part of a perspective I try to impart on other people. And if I had written this book today, instead of a year or so ago, I would be talking about paste layers and finding oneself in them.

• 48:21Speaker 01

  I really love that way of thinking about how the ecosystem evolves and how lessons drill deep and get more stabilized over time, that the stuff that stands the test of time, that that really is applicable and tested, gets used more and more. It's a nice way of thinking about it.

• 48:37Speaker 02

  For me, yeah, one thing I've been spending a lot of time is is thinking about the next generation of contributors, especially with the the rise of AI. And I think I'm seeing a lot of concerns of like over reliance on AI. And maybe the next generation of contributors like won't have a CS degree. And I think, yeah, I don't really have a CTA for that, but I do think we need to be thinking about like younger contributors coming into your project and making sure that it's, we are seeing this graying of open source where maintainers are like getting older and we're not being replaced by younger maintainers. And like, how can we be positioning our projects in a way that appeals to the next generation?

• 49:19Speaker 02

  So like, why would people want to join your project? Because again, I think it comes back to people coming together. Like, what's the purpose you're trying to solve together? What's this cool thing that we're building together? And just making it, yeah, easy for younger contributors to come in.

• 49:32Speaker 01

  This is a great tie in. Abby recently had a blog post on the GitHub blog, Open Source Who Will Maintain the Future? That actually mentions this. So thank you. That's a good resource to link to. All right. Well, I've got one question for each of you left. Abby, can you tell us about karaoke?

• 49:49Speaker 02

  I love karaoke. I'm Filipino. It's in my blood. I grew up with karaoke machines and karaoke parties. Yeah, I think it's a great way to get people together and get people like loose and just having fun. And that's really what open source is. If we're gonna tie this back to open source, just getting people together. And it's a great way to bond with others. So I love pulling out, I don't know, some 90s hits, some like Backstreet Boys, some Spice Girls, just to, just to kick off the night, be a little bit silly so that people realize like, oh, I can also be silly. And it makes for a great night.

• 50:25Speaker 01

  Being silly is fantastic in many senses and contexts. A lot of people, I think, feel more comfortable contributing to open source or being in a friend group or a hangout. When there's, you know, the people who might be very intimidating, you know, director of this, author of that, or are, you know, melted out, Backstreet's back, all right, type stuff.

• 50:43Speaker 02

  Yeah, there's a lot to say for being vulnerable. That's how you build trust, by just showing a little bit of your personality, just opening up a little bit. So yeah, karaoke, if you see me at a conference, please invite me to karaoke. I will definitely come.

• 50:57Speaker 03

  I love that, too. I mean, everything's so serious. And like, I'm very guilty of that, too. And like, having resting Brian face of like, worrying about something all the time, right? And so maybe I need to be inspired to do some karaoke, too.

• 51:13Speaker 02

  Yeah. We've never done karaoke together, Brian.

• 51:17Speaker 03

  I don't think we've ever met in person, but maybe.

• 51:20Speaker 02

  That's true, actually.

• 51:22Speaker 01

  The magic of open source. Brian, the last question is for you. Last real question. Can you tell us about MLS crests, what they are, why they're important, how they've come to be?

• 51:31Speaker 03

  Oh, man, I don't know if I have a super great origin story around them, but I got really involved in MLS since moving into the Minneapolis area. The local team is Minnesota United, Go Loons. We're in the playoffs right now. And it's been a great way to just connect with like, a generational way with my dad and then my sons who play soccer as well. So most recently, this.

• 51:57Speaker 03

  Spring, my second oldest son actually needed like season ending leg surgery. And he like couldn't do anything for six months. So we like bought the MLS season pass and we're watching, you know, like Premier League soccer. And I started looking like squinting at all these MLS logos, right? Like the patches they wear on their jerseys, right? And like, some of them are instantly recognizable in this kind of beautiful UX design way. And some of them are just like horrible adventures and like typography gone wrong and things like that. So me and my son spent some time like ranking them and thinking about them across a bunch of different dimensions. And published that on my blog for people to, I guess, argue about in some way.

• 52:41Speaker 03

  He taught me about tier lists, which is like a video game kind of meme like way to like rank things. So we did the whole thing and it was, it was a good time. And we got like a nice standard deviation of, you know, good looking soccer logos and not so much. And it was a fun way to pass the time while he was recovering.

• 53:00Speaker 02

  What logos are S tier? Do you remember?

• 53:02Speaker 03

  Oh yeah, I do.

• 53:04Speaker 03

  I'm glad you, you got the lingo like right there. So my criteria is usually as little lettering as possible, not too much color. And then of course, having a meaning to the location that they happen to, you know, call home. So there's three that come to mind when I think about those dimensions. And that's the Seattle Sounders and their crest is like a shield with the space needle on it. And like, you wouldn't even know it's soccer if you didn't, you didn't know better. The Chicago Fire have really nice like red and blue circular crest with like the same Chicago colors and the same like star of Chicago. So it's like tied to Chicago, but it also looks kind of like a fire department type thing. And then the last one is the Portland Timbers.

• 53:46Speaker 03

  And as the name suggests, it's just like big axe, like it's just a gigantic axe. And like, none of them really scream soccer. And that's what kind of helps like with their identity in my mind, because they, they become a symbol of their community. Maybe there's something open sourcey in there, right? There's no soccer balls involved, nothing like that. But yeah, they find a way. To create belonging within their spaces too, which is really cool.

• 54:10Speaker 01

  Not to tie this too explicitly back to work topics, but having a good logo is actually quite beneficial for larger open source projects, building that community, getting that brand, making people excited and proud to be a user. It's huge.

• 54:23Speaker 03

  Yeah, yeah, you're right. I mean, I have this like silly kind of JavaScript pennant on my wall. I think it's important that we don't become like raving fans for one thing or another, you know, like tribes, but it does help to have something that you can be proud of associating with 100%.

• 54:40Speaker 02

  Yeah, and branding and brand recognition goes a long way when it comes to like things like fundraising. We're talking about sustainability. So that's also why a lot of the like higher level projects get more funding because they're just so recognizable. But yeah, brand yourself well. It makes a difference.

• 54:56Speaker 01

  Really does. The Boston TypeScript meetup, we have a tank top that we sell, like a sports tank top that says strongly typed, that has a little icon of the TypeScript logo with muscle arms. And that's been our best seller. And it's actually raised a non-trivial amount of money for the meetup.

• 55:09Speaker 03

  Nice.

• 55:10Speaker 02

  I love that.

• 55:12Speaker 01

  All right. Well, the actual final questions will be for each of you. First of all, thank you so much for spending time with me talking about open sources. It's been an absolute delight. If people wanted to find you or your work on the internet, where do they find you? Abby, I'll start with you. How do people find your stuff on the internet?

• 55:26Speaker 02

  Yeah, I'm Abby Cabs, most places, A B B Y C A B S. Find me on GitHub and then I think I linked everything else there.

• 55:34Speaker 03

  My name is not nearly as nice as yours for like trying to pronounce it. So usually it's just like B Muenzenmeyer across the internet. If you search for some semblance of my name, Brian Muenzenmeyer, you'll probably find just me and I'm on LinkedIn, GitHub, websites, et cetera. So good luck.

• 55:54Speaker 01

  Good luck.

• 55:56Speaker 03

  Good luck finding me. I mean, it shouldn't be hard, right? That's the goal.

• 56:00Speaker 01

  Well, you two are, you have quite good SEO for your GitHub profiles, so it shouldn't be too difficult. Anyway, Brian, Abby, thank you again. This was an absolute blast for Software Engineering Daily. This has been Abby, Josh and Brian. Thanks for listening, everyone. Cheers.