← Software Engineering Daily
Software Engineering Daily
Open Source Sustainability
00:58:43
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 sca...
Loading summary
Transcript107 lines
- [00:01]
Josh Goldberg
Open source software underpins nearly every modern application, including frameworks powering the most popular websites to the library, 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 Mays leads open source maintainer programs at GitHub, and Brian Munzenmeier 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 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 eSlint, 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. Find Josh on bluesky, Fostodon and dot com as Joshua Kgoldberg.
- [01:44]
With me today are Abby Kabanak Maes, who runs the open source maintainer programs at GitHub, and Brian Munzenmeier, principal engineer, Node JS maintainer and author of Approachable Open Source. Abby and Brian, welcome to Software Engineering Daily.
- [01:57]
Abby Kabunak Mays
Hey, thanks for having us.
- [01:58]
Brian Munzenmeier
Thank you.
- [01:59]
Josh Goldberg
I'm excited to Talk to you two about open source and books at GitHub. Abby, can you start off telling us who you are, how you came to lead the OS maintainer programs at GitHub?
- [02:07]
Abby Kabunak Mays
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. The software I was using enabled these researchers in Japan to collaborate with data scientists in the uk and 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 and for a long time I was 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? Yeah, that brought me there. I'm also on the board of the OpenJS foundation and I'm one of the organizers for SustainOSS. So I care a lot about this topic. And yeah, thanks for having me, Josh.
- [03:26]
Josh Goldberg
Clearly it's a topic that all three of us are very passionate about. Brian, how about you?
- [03:31]
Brian Munzenmeier
Hey, thanks for having me, Josh. My name is Brian Munzenmeier. 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 tool set. I worked with Brad Frost 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 was really, really exciting. And that turned into job offer and like moving my family to a different state and all that fun stuff. 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 a ecosystem and industry and 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.
- [05:19]
Josh Goldberg
And Abby, your name is on the book as well. You're on the back cover.
- [05:22]
Abby Kabunak Mays
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, just open source leadership. And just I wanted to see more people doing open source really well and learning best practices and sharing with each other. So it's great to see Brian continuing this work and, yeah, writing a book.
- [05:49]
Brian Munzenmeier
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.
- [06:00]
Abby Kabunak Mays
Yeah, thanks, Brian.
- [06:01]
Josh Goldberg
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, if someone asked
- [06:16]
Brian Munzenmeier
me that, I'd probably say it's free code governed by some kind of license as 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 really as the use cases at all. Right. 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. So that's my, hopefully short version of what it is.
- [07:01]
Abby Kabunak Mays
Yeah, I completely agree with you, Brian. I think there's the technical definition, the legal definition that the OSI stewards 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, 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.
- [07:40]
Brian Munzenmeier
Right. Finding your people. Right. Finding people that care about the same thing you do. Right. Is such a huge unlock. And 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 an obvious manifestation of collaboration at scale. Right. And we're able to connect with one another now. So great.
- [08:20]
Josh Goldberg
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?
- [08:35]
Abby Kabunak Mays
Yeah, I actually know someone who got it tattooed. Shout out to Justin Dorfman. But 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 this tiny one little piece that's holding the whole thing up. And 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.
- [09:04]
Brian Munzenmeier
Dependency.
- [09:05]
Josh Goldberg
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. How does that develop?
- [09:26]
Brian Munzenmeier
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. 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 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 a. 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 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 there. We try to come up with like a naysay, just a yeah. Or 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:21]
Abby Kabunak Mays
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. Different people use them. You still have users, you still have 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:49]
Brian Munzenmeier
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 advance that idea.
- [12:25]
Josh Goldberg
Love that. That really is a heartwarming perspective. Thank you for, in a very positive sense of 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:56]
Abby Kabunak Mays
Yeah, I do see it as. There's a couple of frameworks I've used to talk about this. 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, you have 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, then you can go slower and slower down that funnel too. Maybe they start contributing, they open an issue, they join the discord and they sustain contribution. Maybe they make a couple pull requests, they stick around in that community and then eventually you want them to 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. 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 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:05]
Josh Goldberg
It's interesting you bring up Mike McQuid'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 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:27]
Abby Kabunak Mays
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's 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 stay engaged and keep going. So there's a lot of parallels with marketing and hospitality and all of these things. Not to think of your contributors as just numbers going through, but thinking about them as people. And how can we make them feel welcome and want to stick around in your project?
- [15:21]
Brian Munzenmeier
I wanted to say too, and this is creating 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 skill set that they want to bring to that project and maybe only that skill set. Right. And I see this on the Node project a lot. Right. We have excellent web developer contributors 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 future maintainers, but also to someone who's trying to casually contribute or improve their mastery of a certain skill set. 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:00]
Abby Kabunak Mays
No, 100%. I think for casual contributions, especially things like you mentioned localization. But 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. I definitely agree.
- [17:36]
Josh Goldberg
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:04]
Brian Munzenmeier
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 as like something that should be the entry point into any project. 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 that 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? 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 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, it's 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, of any size. If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger data creators of TimescaleDB takes a different approach. We extend Postgres with hybrid row and columnar storage, so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%. Continuous aggregates keep dashboards live without bash jobs, and it scales to petabytes without you Re architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo, and Flowco run production workloads on Tiger Data today. No stale data, no second system to operate, just Postgres managed for you. Ready for the workload you're building toward? Try it free@tigerdata.com Turbopuffer is how companies like Anthropic, Cursor, Notion, Atlassian, and Ramp ship their most ambitious search features. TurboPuffer is a serverless vector and full text search engine built on object storage. It's up to 95% cheaper than traditional
- [21:08]
Josh Goldberg
search databases and just as fast.
- [21:10]
Brian Munzenmeier
With TurboPuffer you can index and search 50 million documents at 10 millisecond P90 query latency for less than $100 per month. Head to turbopuffer.com sed to get your first month free.
- [21:24]
Josh Goldberg
You know Fidelity is a financial services leader, but did you know that inside Fidelity is a community of technologists working together to shape the future of finance and tech. Fidelity is always investing in tomorrow, from emerging tech to cutting edge tools that will transform what comes next. Their technologists are encouraged to keep learning so they can expand their skill sets, explore new ground, and stay ahead of this rapidly evolving industry. And right now, Fidelity is hiring technologists to join their team. Fidelity technologists get the best of both worlds Startup energy that's grounded in the stability of a financial institution. That means support, resources and amazing benefits. Bring your skills to a culture where you're empowered to dream big and build the tech that drives an organization and makes A real impact on people's lives. Find out more@tech.fidelitycareers.com that's tech.fidelitycareers.com Fidelity is an equal opportunity employer.
- [22:25]
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?
- [22:31]
Brian Munzenmeier
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. 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, 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.
- [23:23]
Josh Goldberg
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 projects 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.
- [23:46]
Abby Kabunak Mays
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. 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. The first disagreement that community might fall apart thinking of it 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. 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. 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, governance can make sure that your open source project lasts longer term and isn't just a flash in the pan of people who get excited jump in and then as soon as there's a rift in the community, you have a fork or the community just implodes. But yeah, it's just the kind of guardrails you need to keep something longer term.
- [25:04]
Josh Goldberg
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?
- [25:19]
Brian Munzenmeier
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, 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.
- [26:42]
Abby Kabunak Mays
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. We do 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 it is 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 and what you are like, this is what our plan is. Anything outside of this isn't part of it. Just to make it a little bit clearer and something to point to. But yeah, find other maintainers, I'd say is my biggest piece of advice because it is tough to do that on your own.
- [27:34]
Josh Goldberg
I'd like to drill into that. Actually, as a maintainer myself, I 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 email unifying Gus. 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?
- [27:55]
Abby Kabunak Mays
With other maintainers or with your open source project community?
- [27:59]
Josh Goldberg
Let's say either or both.
- [28:01]
Abby Kabunak Mays
I'd say with other maintainers, it's like there's this lean coffee framework that I think started with founders, just 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. What's going well with your project? What are you struggling with right now? And then after you hear what everyone's struggling with, 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 the maintainer to maintainer conversation. But yeah, I'm curious to hear what Brian has to say for this answer.
- [28:35]
Brian Munzenmeier
I was thinking about this in the lens of foundations. 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 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.
- [29:30]
Abby Kabunak Mays
Yeah, I should have shouted out OpenJS Foundation. So thanks for that Brian. But that's nice because it's all like JavaScript project typescript projects, so you have that shared experience. So it's good.
- [29:43]
Josh Goldberg
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.
- [29:59]
Great.
- [29:59]
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 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.
- [30:16]
Brian Munzenmeier
Yeah, I think a large central theory of the book is to equip people with enough knowledge about where they fit within the open source ecosystem. 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 complimentary stats about how 90 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 jobs. And that could be an end user using software or hardware that they're working with. It could be a software engineer or some kind of technologist actually 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, that's not a one, 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, because 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 corroborate a report that someone else had. You could test their recent release and see if you can upgrade in your own code base. Right. 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 part of, even if we don't realize that we are.
- [32:34]
Abby Kabunak Mays
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 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, would love to help enable that.
- [33:09]
Josh Goldberg
It's an interesting aspect of what Your role at GitHub 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 Node 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?
- [33:36]
Abby Kabunak Mays
Yeah, well, they're very different, especially when thinking about open source sustainability, like what one project needs or one 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. It's about the people working on these problems together. And it's not necessarily solved by throwing money at it, because it's not money that's reviewing pull requests or making a commit, it's people doing this. And 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, no matter if they're an independent contributor or they're part of a giant corporation.
- [34:24]
Josh Goldberg
We were talking about parallels with product work, so I'll bring in another parallel and ask each of you this. If you had a magic wand, you could wait and make one thing better to support people doing open source in the workplace. What would it be and why and how?
- [34:39]
Brian Munzenmeier
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 Pollyannish 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 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 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 biggest magical chance of changing hearts and minds over time.
- [35:53]
Abby Kabunak Mays
Yeah. I think for me, Magic Wand is nice because I think this would require real systematic change, which would be really difficult and tough to come about, but more corporate support for open source, whether it's money or in kind, especially in these lean years where there's so many layoffs and budgets are being cut, we're really seeing that it often feels like a very extractive relationship with corporations 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, 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 about. But Magic Wand would be great.
- [36:39]
Brian Munzenmeier
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. 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. I need like data science power. I need people who can do that together and then make an executive summary report that is on the desk of every CTO that says, bang, 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.
- [37:54]
Abby Kabunak Mays
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 this has an actual effect. So yeah, I like your answer, Brian. Let's use that magic wand. We'll combine our two together.
- [38:25]
Brian Munzenmeier
Love it.
- [38:25]
Josh Goldberg
It's a big ask. We'll need two wands for this one.
- [38:27]
Abby Kabunak Mays
Yes.
- [38:29]
Josh Goldberg
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 donating 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?
- [39:02]
Abby Kabunak Mays
And that's why I think about this problem all the time.
- [39:07]
Brian Munzenmeier
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, all 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, you know, I don't know, getting into like all kinds of torched analogies about 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.
- [40:04]
Josh Goldberg
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 at it from different sides of the trying to find ways to do it.
- [40:20]
Brian Munzenmeier
And I'm going to name drop Chad Whitaker from Open Source Pledge. Yeah, Open Source Pledge. And then he's also done Open Path Podcast. 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 support this. And 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 a really interesting perspective on it. So I encourage people to check that
- [40:57]
Josh Goldberg
out for the sake of our listeners. What is the Open Source pledge?
- [41:01]
Abby Kabunak Mays
I think the details is a 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 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 things in this space just to help with getting money to open source. Sure.
- [41:28]
Josh Goldberg
And you also made the point earlier that money is not the be all and end all to solve these issues. They're 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.
- [41:50]
Brian Munzenmeier
Yeah, that'd be great. 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.
- [42:13]
Josh Goldberg
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.
- [42:35]
Abby Kabunak Mays
Yes, I think AI is 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 maintainers especially, they see both the opportunity and the challenges of AI. It is very helpful when you're writing code 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 we need to find a way to use AI, but also mitigate a lot of the challenges that are there because I don't think it's going away. So I am encouraged by things like using AI to detect AI spam and AI slob. I know a few maintainers have done that and are using that. It seems to be helpful. But how can we leverage this tool that is very helpful while not taking away the human part of open source? Because I think it is still about humans coming together and collaborating. I don't think AI can replace that, but AI can just help enable that a bit better. I love seeing examples where people 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, but there is a lot of slop out there right now.
- [44:07]
Brian Munzenmeier
So pros and cons to build on that, I think. I've been a recipient of AI slop, but I've also been. 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 click 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. 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. And it's really easy to probably focus on bad news that we hear and not think about all the ways in which it is working out for us.
- [45:41]
Josh Goldberg
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 to be rather helpful to figuring out what needs to be addressed in those guides.
- [46:03]
Brian Munzenmeier
If it gets stuck. Right, that probably means humans are too, no? Yeah.
- [46:06]
Abby Kabunak Mays
I've seen people really clean up their documentation because of Copilot, because it's gives them so much better results. I think that's a good side when
- [46:15]
Josh Goldberg
you think about it. Many, perhaps all of 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.
- [46:32]
Abby Kabunak Mays
Yeah, I think the Octoverse 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.
- [46:46]
Brian Munzenmeier
Yeah, I was going to say that. For years there's been this really great Microsoft Accessibility PDF that goes around about the different kinds of accessible challenges that people might have if they're temporary or situational or whatever. And the overall gist is that accessibility benefits everyone, not just people that are 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.
- [47:21]
Josh Goldberg
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 the sidewalk to make it easier for people, people who are, say, in a wheelchair. And that's just fantastic for everyone, 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.
- [47:53]
Abby Kabunak Mays
Yeah, I didn't know about that curb cut story. Yeah, thanks. Cool.
- [47:56]
Josh Goldberg
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, about open source or sustainability or the workplace or any of the topics we've talked about so far.
- [48:07]
Brian Munzenmeier
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 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 all of civilization when he talks about this. And you think about nature and glaciers and really slow things and all the way up to governments and commerce and buildings and fashion being really fast, fast fashion and trends and fads. 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 complement with one another. And it's a worldview that allows us to never really be in conflict because if a new framework comes along, a new paradigm, something we want to explore, a new way to do something, AI is a great disruptive example. 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 into more and more kind of solidified pieces of 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. 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 pace layers and finding oneself in them.
- [50:38]
Josh Goldberg
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 really is applicable and tested, gets used more and more. It's a nice way of thinking about it.
- [50:54]
Abby Kabunak Mays
For me, one thing I've been spending a lot of time is thinking about the next generation of contributors, especially with the rise of AI. And I think I'm seeing a lot of concerns of overreliance on AI. And maybe the next generation of contributors 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 younger contributors coming into your project and making sure that we are seeing this graying of open source where maintainers are getting older and we're not being replaced by younger maintainers. How can we be positioning our projects in a way that appeals to the next generation? Why would people want to join your project? 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.
- [51:49]
Josh Goldberg
This is a great tie in. Abby, you 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?
- [52:06]
Abby Kabunak Mays
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 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 dunno, some 90s hits, some like Backstreet Boys, some Spice Girls, 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.
- [52:42]
Josh Goldberg
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, belting out backstreets back all right type stuff.
- [53:00]
Abby Kabunak Mays
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.
- [53:14]
Brian Munzenmeier
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.
- [53:30]
Abby Kabunak Mays
Yeah. We've never done karaoke together. Brian, we should.
- [53:34]
Brian Munzenmeier
I don't think we've ever met in person, but maybe, maybe someday actually.
- [53:39]
Josh Goldberg
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.
- [53:48]
Brian Munzenmeier
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, 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 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 were 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 in 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. 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.
- [55:17]
Abby Kabunak Mays
What logos are S tier, do you remember?
- [55:18]
Brian Munzenmeier
Oh yeah, I do. I'm glad 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 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 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. And as the name suggests, it's just a big axe. Like it's just a gigantic ax. 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.
- [56:27]
Josh Goldberg
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. That's huge.
- [56:40]
Brian Munzenmeier
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%.
- [56:57]
Abby Kabunak Mays
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 higher level projects get more funding, because they're just so recognizable. But yeah, brand yourself. Well, it makes a difference.
- [57:13]
Josh Goldberg
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.
- [57:26]
Brian Munzenmeier
Nice.
- [57:26]
Abby Kabunak Mays
I love that.
- [57:29]
Josh Goldberg
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 source. This has been an absolute delight. If people wanted to find you or your work on the Internet, where would they find you? Abbie, I'll start with you. How do people find your stuff on the Internet?
- [57:43]
Abby Kabunak Mays
Yeah, I'm AbbyCabs. Most places. A, B, B, Y, C, A, B, S, you find me on GitHub and then I think I link to everything else there.
- [57:51]
Brian Munzenmeier
My name is not nearly as nice as yours for trying to pronounce it. So usually it's just like B. Munsenmayer. Across the Internet, if you search for some semblance of my name, Brian Munsenmaier, you'll probably find just me. And I'm on LinkedIn, GitHub, websites, etc. So good luck, Good luck, good luck finding me. I mean, it shouldn't be hard, right? That's the goal.
- [58:17]
Josh Goldberg
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.