Episode 262: Brian Muenzenmeyer on Approachable Open Source  ## Metadata - Author: [[Sustain]] - Full Title: Episode 262: Brian Muenzenmeyer on Approachable Open Source - Category: #podcasts - URL: https://share.snipd.com/episode/204b7986-9bb2-42fb-adf9-a6d5079adf70 ## Document Notes ## Highlights - **Open Source Journey** - Brian Muenzenmeyer started contributing to open source by fixing a typo in jQuery Mobile's documentation. - This led him to maintain larger projects like Pattern Lab, which eventually led to both career opportunities and burnout. Transcript: Brian Muenzenmeyer And I really started like many other folks do in consuming software in some way. And I recall using jQuery mobile at an employer to make our little mobile app work the way we wanted to. And one thing led to another and I found a typo in the documentation And it was very humble beginnings of like, oh, that should be fixed. I can fix that. Or maybe can I? Really the makings of some of these theories, I guess, were even working then. And it's kind of fun because one thing leads to another and you walk around someone's source code, you want to learn a little bit more about someone does something, how they deploy it, How they test their code, what their style guide is, their voice and tone, whatever. And over time, it's gotten a little bit more sophisticated with what I'm comfortable doing. But from those, I guess, humble beginnings, I started getting more and more involved in some software that Brad Frost, who wrote Atomic Design, maintained along with Dave Olson called Pattern Lab. And I was just some punk kid with a Windows machine who didn't know how to run PHP. So I thought it'd be a great idea to fork it and rewrite the whole thing in Node. And that led me down quite the journey to maintaining a larger and larger project, building a community around it and meeting a lot of people who, you know, eventually started using It for their day job to feed their family, to pay their mortgage, that kind of stuff. And it was a lot of responsibility. I met some of the folks that I work with at Target through that project. And I also burned out on said project. So it gave me just a heap of interesting lived experiences that have carried forth today into what I like doing now and into the book. ([Time 0:02:16](https://share.snipd.com/snip/bbd7edff-7f44-4122-97a8-844f5e167c64)) - **Burnout and Community** - Burnout is a common experience in open source, stemming from feelings of guilt and inadequacy. - Designing sustainable communities and recognizing the spectrum of contributions can help mitigate this. Transcript: Richard Littauer Always feel overwhelming sense of compassion whenever I talk to anyone who's gone through the JavaScript wars, anyone who's had a project in that community and then come out the back End and like burning out and coming out and still liking open source is amazing. So I totally get where you're coming from. Thank you for sharing that background. Tell me how you arrived at the tail end of burnout to decide, I'm going to write a book about this. Brian Muenzenmeyer Gosh, that's a really great question. Somewhere in my marketing material, I say like this book's been writing itself in my head for my entire career too. And I think it's probably a combination of many things that I'm maybe being revisionist about, but I don't think that my experience was special or it wasn't much to write home about. I think lots of people dabble in it and kind of get sucked in and then they start to feel a lot of guilt around, oh, I'm not doing enough. It took a long time for me to understand that that was normal and that there were things that I could do about it to not only protect myself as an individual contributor or if I have time To do things, but also that this could be a designed outcome, that this safety in this community could be something that maintainers build for with intent. And that's been a big part of it. I think the other thing that's been really eye-opening for me is that as now a more enterprise-y corporate engineer over the course of my career, it's been really clear to me that there Isn't this dichotomy between consumption and contribution that there's really this like spectrum of activities that we can engage in. And it's those corporate engineers, it's those latent energy type folks who are consuming, like I said, it was with regard to like jQuery mobile way back then. Those are the people who have the capacity and I believe the agency to do something, to contribute upstream. It's in everyone's best interest to do so. So as I started to piece together that there was a place for me, that there were people that had like-minded interests within whatever tech it happened to be at the time, that there was Avenues for me to help out, even if it wasn't doing all the coding. ([Time 0:04:04](https://share.snipd.com/snip/41e03023-f06a-44c5-ba56-6b72f8a95ba4)) - **Pace Layers in Open Source** - The concept of "pace layers" explains the dynamic between fast-paced innovation and slower, more stable core technologies. - Open source projects, like Node.js, absorb innovations from their competitors, demonstrating this dynamic. Transcript: Brian Muenzenmeyer I had to rewrite the book, I would make mention of pace layers. And this is a concept that I guess I've seen socialized a couple of different places now. But if you think about orbital bodies surrounding something, the closer they are to it, they might be spinning slower and then farther and farther away in order for them to revolve around That body. They need to be moving faster. So there's layers of pace. We'll have to try and dig up the reference, but you can even map this to things like civilization itself. And closer to home, within the world that we have, you can see this happening all the time with innovation in the tech space. Think about CSS variables, as people call them now, and how those were internalized and made into the actual spec based on a lot of the experimentation that happened in the SaaS or the Less world. And the same could be true about things like Flash turning into Canvas. I see this more noticeably today. Most of my maintaining that I do in the open source world is in the Node.js project. Like I said before, I forked something into Node many years ago, and now I'm helping maintain the Node website. And what's been interesting to see with Node is the innovation that its competitors have pressured or put on it to make that core engine, the one that has the momentum, pull in some of Its orbital bodies. So now Node has its own test runner and you might not need Jest anymore. Node has ENV support, so you might not need.ENV. It has its own watch mode, which you might not need Watchman or any other library like that. This is pace layers and ecosystems working kind of in real time. There's innovation that's just like breakneck fast. And then there's solid institutionalized coalescence gravity around things that work. And I think that concept can be applied to JavaScript frameworks. It can be applied to the web as its core set of technologies and specs, and it can be applied to civilization as well, if we can find the reference. ([Time 0:09:32](https://share.snipd.com/snip/1b9061df-82fe-4752-9563-79543f1173e2)) - **Sustainable Open Source** - Acknowledge the harm caused by the "move fast and break things" mentality in open source. - Explore sustainable funding models like algorithmic dependency-based funding. Transcript: Richard Littauer Love the pace layers metaphor too. It's great to hear new metaphors on here. I'm looking at the table of contents for your book. So we have around seven chapters, principles and promise, the spectrum of engagement, consuming open source software, the four files of any open source project, community investment, Open source in the workplace, and open source sustainability. Obviously, number seven is the one that jumped out to me. Can you talk a bit about what's in that chapter? Brian Muenzenmeyer Yeah, I can. There's a through line with that chapter around, we've been moving fast and breaking things with tech for a long, long time. And there's a couple of examples in there of how that breaking part really does harm. Of course it does. There's examples of some folks delisting packages from the NPM registry, kind of in protest of feeling exploited and causing cascading failures across ecosystems. And there's a blog post of my own that I revisit within there called iMaintainer. It was very like Isaac Asimov-esque about like to coin some laws of open source maintenance. And that was actually really fun to retrospect on in writing the book because the laws, as I described them at first, were written when I was right in the midst of burnout with Pattern Lab. And I was trying to reaffirm or self-affirm that I was doing the right thing and that I would do right by the community, even at my own peril. Putting something out there was a contract that I could not break. I had a responsibility. And that's the genesis of a lot of open source guilt. But when I revisited that content post-burnout and in writing that, I realized that I had it exactly wrong. The whole point of trying to work within the open source ecosystem is to avoid burnout, is to work well together, is to protect yourself against all other things. And like my father will always say that I need to take care of myself before I can take care of my family, before I can take care of anything else. And like, it's fatherly wisdom, but he has to say it. And I don't know how well anyone ever listens, but that's covered in the book for a good length. I do also cover some interesting experiments that are merging with funding. If we're talking about contribution and like a spectrum of engagement, directly funding is something that I think there's a lot of really interesting work going on even right now. Abby, you've been talking about this when we were drafting this book a year or so ago on how we still haven't really cracked how to do this sustainably. But I'm really excited to see things like the Sovereign Tech Agency create some work there, the ecosystems work that passed my feed like yesterday, and some really, really cool work Around algorithmic dependency data-driven contribution. That kind of stuff is quite interesting, I think, because the more avenues we can create for corporate contribution to be like easy mode, I think the better off we are. So there's a lot of that that's in that chapter. Abby is also interviewed in that chapter and helps me make a lot of these points too. I'd love to hear if you want to add anything to that. ([Time 0:14:07](https://share.snipd.com/snip/a2f26b0d-9ab7-46e1-9ac1-a9c56f876b28)) - **Advice for Maintainers** - Avoid comparing your early-stage project to mature projects to prevent discouragement. - As your project grows, create diverse contribution avenues and integrate open source work into your job. Transcript: Brian Muenzenmeyer I do. A couple of things come to mind. I think I'll start with drawing the owl. If you understand that meme, I think if you look at a mature open source project and try to emulate it at the outset. You're going to be disappointed and you're going to feel like you're always behind. I think it's important to remember that none of those projects ever started in their fully materialized form. They started with pretty humble ambitions and maybe a community of one. I know I said before that any open source work is really giving to the community, but being self-sufficient or being oriented towards your own use cases, of course, makes sense at the Outset. As the complexity grows and as your demographics or your community grows, I think it's natural that people are going to want more of you. They're going to want translations of your documentation. They're going to want this extra flag that does one thing different than what you had envisioned. And you're right. It can really become overwhelming. So there's some like discreet advice in here around notification management and being able to walk away from things when you want to. Like you should go touch grass and have a life. And I try not to think about your project in the shower. Sometimes thinking happens there, of course, but there needs to be an outlet that isn't always this. And there's a whole lot of content and concrete advice around just the management of it. But contingent with that is with increasing interest should also be increasing avenues for contribution. I use this analogy of the community garden throughout chapter two, I believe, where no one person can really make a community garden function, right? You need to secure a site for it. You need to procure the building material. You need to map out the plots of the work so people can know where they're going to plant. You need to know what you're going to do with the yield. Maybe you've donated somewhere. Over time, people develop some specialization or maybe someone comes in and helps with just the fencing and they might not even touch dirt. They might not even do any gardening and that's okay. Successful community garden will create those opportunities for a diverse set of folks. The other thing I wanted to really hammer home and touch upon that you said before is, well, a lot of this happens on nights and weekends. I have definitely been in that camp. I've taken selfies of like holding on to my newborn while trying like program before. Right. And I thought it was cute at the time and like, maybe it was, but now I circulate a slide whenever I'm giving a presentation that just in big, bold letters says, you don't need permission To do your job. And I really try to live by that and model that behavior for the engineers around me too, because like I said before, everyone's consuming software all day long. There's nothing that really says you can't be contributing back to it as just part and parcel of your role, whatever that role might be. If you're a developer, if you're a designer, if you're a technical writer, if you're in product, in accessibility, really anything. In my opinion, and in the opinion of my allies and leadership and all that, you're already empowered to fix the things that you see broken. If it's an extremely large lift or a really huge enhancement, maybe you need to secure a little bit of your time or ask for permission, but you can do this in small ways too an experiment. Instead of buying a maintainer a coffee, spend a coffee cups amount of time looking at their issue log and seeing if you can plus one or corroborate an issue, or you can test a PR and you Can fix something that's low hanging, whatever you want to do. I can guarantee that you will find some work to do within some of those projects. And the projects that are orienting and designing for those moments are the ones that are going to be most successful. ([Time 0:20:19](https://share.snipd.com/snip/e5f03019-8ab2-404a-8554-2110492a1f78)) - **Diversity in Open Source** - Increase diversity in open source by making contributions accessible and celebrating successes of underrepresented groups. - Acknowledge the challenges of navigating diverse perspectives and promoting tolerance. Transcript: Richard Littauer So I love that. And I think that's great. You mentioned something earlier, which I kind of want to come back to, which is diversity of roles. And I'm curious about your thoughts on diversity of the ecosystem. Open source has historically been a white male educated, dominated world. And that is increasingly less the case. And it matters because things like paying maintainers is totally different if you're paying them if they live in Lagos, Nigeria, as opposed to if they live in San Francisco and have Four kids or something. And I'm just curious about your thoughts about the future of open source from that perspective. How can we get more languages involved, more underrepresented groups? And what do you think is going to change? Brian Muenzenmeyer I'll be the first to admit that I don't know how to crack this, how to solve for it. I think that making contributions as accessible and as bite-sized and as approachable in the name helps everyone be able to find the time to work on this. Last month, I was at the Node.js Collaborator Summit in Dublin, Ireland, and there were two women amongst 50 men or something like that. It's obvious and palpable and embarrassing and frustrating all at the same time. So I don't have sage advice as to how to solve for this, but I do know that encouragement and like I said, creating those opportunities and reinforcing them with a whole lot of individual Care and public celebration when it does happen is great. I work with someone who recently patched a vulnerable version of Axios, and they're in a couple underrepresented fields, demographics, and they patched this vulnerability for 9 Million people or 9 million projects, you know, and it's like, that is time well spent that I've tried to trumpet as much as possible. We have some maintainers on the Node.js site that are 17 and 18 years old. What an amazing opportunity to be exposed to a wealth of knowledge in the rest of the community and things like that. Worldwide projects are quite interesting because they're a melting pot of opinions. I certainly haven't gotten it right all the time. On the Node project, we had some pride representation that caused an extreme amount of hate and intolerance to come our way. And while that's obviously not okay, it's interesting to think about some parts of the world where that intolerance is just a part of the systems within which they work and in which they Live. And it continuously humbles me and challenges me to be better and to think about all aspects of it while also being an ally and trying to thread the needle. But I'm sure you've heard of the paradox of tolerance. It's a lot of heavy stuff. I don't have the answers to directly as one person. The book also tries not to shy away from this topic. And that was one thing that was kind of interesting about the process that this book was made is that my publisher at the time was a little reluctant to wade into these waters and they're No longer in the picture. And I tried to go a little deeper into this and find a well-rounded human perspective of what makes sense. And my position is vulnerable, evolving, and trying to continuously learn as an ally here. ([Time 0:24:54](https://share.snipd.com/snip/30628a1f-f38b-4c8d-8aa6-2b514d9cd640))