Search

637: Approachable Open Source with Brian Muenzenmeyer

Download MP3

Brian Muenzenmeyer joins the show to talk about his book, Approachable Open Source, ways we can make open source easier to get in, important conversations around funding and supporting open source, and whether money helps maintainers deal with burnout or not?

Tags:

Guests

Brian Muenzenmeyer

Brian Muenzenmeyer

Web · Social

Author of Approachable Open Source, Principal Front End Engineer.

Time Jump Links

  • 00:41 Introducing Brian
  • 01:20 Reading Approachable Open Source
  • 02:35 What was your journey to writing this book?
  • 14:18 How do you make a project an open source thing?
  • 22:40 Would the world be a better place if more people helped in open source?
  • 27:21 Sponsor: Bluehost
  • 28:20 Learning and understanding licenses in open source
  • 37:21 Is code just commons? Should it be?
  • 39:03 Funding open source
  • 41:53 Does money help fix burnout?

Episode Sponsors 🧡

Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--off brand Bitbucket--Rupert. With me is Chris--Octocat--Coyier.

Chris Coyier: Yeah.

Dave: Hey, Chris. How ya doin' today?

Chris: Good. Good. Yeah. Chris--closing issues--Coyier. Just saying.

Dave: Ooh! Yeah.

Chris: We have a special guest on the show this week, Brian Munzenmeyer. Right? Did I say it right?

Brian Munzenmeyer: You did. You nailed it. Thank you.

Chris: You're god-dang right! Hails from my home state of Wisconsin. We're both Wisconsin boys. I'm down in Madison. You were up in, what, Manitowoc, right?

Brian: Yeah, that's right.

Chris: Yeah.

Dave: [Laughter]

Chris: I love Manitowoc Minute. You watch/listen to that guy?

Brian: Oh, yeah. We get a lot of that.

Chris: He's the best.

Brian: And it's fun to see how many people will associate to that. Maybe that's now a better association than "Making a Murderer."

Chris: Keep er' movin'. You know?

Brian: Yeah.

Chris: Oh, it's better. It's the best thing that ever happened to Manitowoc.

Brian: [Laughter]

Chris: My God. After that show, everybody probably took the long way around Manitowoc. But now you might see Charlie.

Brian: Good icebreaker, and now we're moving on to something better.

Chris: Yeah. Keep er' movin'. [Laughter] But you wrote a book. Can I buy it today as I speak (when people are listening to this show)? It's called Approachable Open-source. I forget because it's so, so fresh new. I have a copy right here in my hands that still feels warm from the printer, practically, so this is about as fresh as it gets, right?

Brian: Yeah. Yeah, thank you. Yes, it is available. It's at, yeah, eponymous name, approachableopensource.com. Anywhere fine books are sold - on my website only.

[Laughter]

Brian: It's been quite a journey to get there but--

Chris: Yeah.

Brian: Yes, available in paperback, digital.

00:02:02

Chris: It's a beautiful website, approachableopensource.com. Not everybody owns the exact title of their book dot-com, so crushing it there I'd say. And with a big purple button that allows you to add it to your cart and buy it. No screwing around there. Well done.

Brian: Yeah. It's maybe not as big as the 11ty documentation button, but that's--

Dave: Yeah, I've seen bigger.

Brian: We'll get there.

Dave: I've seen bigger. [Laughter]

Chris: Yeah.

Brian: Make it bigger.

Chris: He overdid it, though. It's like you don't even notice it's a button, practically.

All right. Let's get into this approachable open-source. What's the thrust of it? But it comes from you're an open-source guy. You had a whole journey in it. You say right in the beginning of the book; you went from not really knowing what this was all about to dipping your toes in it to becoming a maintainer of a project to forking it and even to burning out. So, you really ran the gamut of the open-source system. But say it in your own words. What happened, man?

00:03:00

Brian: Yeah. Well, I think that's a good start. But somewhere in my early career, I got bit by this notion that there's a bigger community that we're all a part of and that they're out there if you happen to look. Right?

It probably helped in the early days to go to a conference as, like, a 20-something person, like signing up for Twitter right there in the conference room. Like, "Oh, man, there are people here!"

Chris: [Laughter] Yeah.

Brian: "There are literally people here." I think my first talk ever was Ethan Marcotte's Responsive Web Design presentation. I was like, "Wow!"

Chris: Wow. Wow.

Brian: "What a primer into the community."

Chris: Yeah, it was all kind of downhill from there, unfortunately.

Brian: [Laughter] We peaked. But really, it was really, really amazing to discover other people who cared about things that I did, like good user experiences or improving the comments.

At that time, I think I was fixing bugs in the jQuery mobile documentation. You know? It's like, "Oh, there's a typo. How do I fix it? I can fix it. I have the time." Right?

A lot of things kind of led to one another. But I very much got--

Chris: You make the point in the book, too, that that's contributing to open-source. You fix a typo in some docs, you're doing it. That's the job.

Brian: Yeah, and I really want folks to understand that it's this spectrum of engagement that all adds up to it. Everyone's skillsets are different. There's no such thing as technical or nontechnical.

For a project to have a lot of longevity and resilience, you need folks from all different kinds of walks of life, skillsets to add up to something great.

Chris: Right, so what was your--? That was jQuery mobile was your very first one.

Brian: Ooh, yeah.

Chris: I happen to know that you were big into Pattern Lab for a long time. That ended up... Did that end up kind of being where you spent most of your open-source life?

00:05:04

Brian: Yeah, maybe my early life. Right? I got involved with Dan Cederholm's pairs project. If you remember all these things were proto-storybook kind of like before React was a thing and supposedly ate the world. Right?

People were really jazzed about the idea of component libraries and design systems, but they were not... They didn't permeate everyone's thought process, like, "Yeah, this is of course how we do it." Now I think we kind of take it for granted. But back then, we were still figuring it out.

Chris: Right.

Brian: I discovered Brad Frost's and Dave Olsen's Pattern Lab project, and I'd been a Windows user for most of my life.

Chris: Mm-hmm.

Brian: PHP was this completely foreign concept to me at that stage. I was like, "I don't know how to use this." It's not as--

Chris: Was PHP really... didn't play well on Windows? I didn't even know that, really.

Brian: Well, I think it might have been partly that and partly just my immaturity at the time. Right? They could certainly work and run, but it was not ergonomic.

Chris: Okay.

Brian: It didn't come with all the tools ready for you like on a Unix or Mac system.

Chris: Okay.

Brian: That was one of my first things that I did with them was, like, "Hey, I can't even run this project on Windows. If you change this XYZ thing here, it works." I did that for a bit, but then for some reason unknown to me now, I decided to fork it.

[Laughter]I was stubborn to a fault. I forked it and started rewriting it in Node.js.

Chris: Yeah, something bit you there, huh?

Brian: Yeah. Yeah, and that felt more ergonomic to me. It felt more cross-platform compatible, which I think is maybe dubious in the long run. But I brought my own flavor to it and added things like more comprehensive unit test suites, a lot of things that made sense to me to use, use Pattern Lab to continue building things, and it became much more of that maintainer relationship over time where I was self-sustaining my own interest. I was using it at work and building and building and building, which became a lot more about maintaining instead of just pushing code all day.

Chris: Yeah, about maintaining. It ends up being a big topic, doesn't it? Open-source is much less about the new and flashy. It can be at first, and then it pretty quickly evolves into just taking care of the project.

00:07:42

Brian: Yeah, I talk a little bit about that in the book around this analogy of the community garden. It's almost maybe like a labored analogy or a trope at this point. But a community garden of sufficient size, it needs fencing. It needs weeding. It needs deciding where the volunteers or the people who sign up will have their plots. It involves fundraising to get more and more resources. All of these things are tangential to the act of gardening, but they become this larger and larger spectrum of activities that all need to be present in order to be successful.

Dave: Yeah.

Chris: Right.

Dave: There's an old blog post, "How to be an open source gardener." That's one of my favorite posts ever. It just gets into this idea of, like... I think it was some... I forget the person's name, but they hopped into an 800-issue for Ruby on Rails, like the 800 issues, open issues, and they just went through, and they read every issue.

Brian: Uh-huh. Mm-hmm.

Dave: Then they went through again, started at the top, and read every single one. And then started closing or merging down, but no action on the first read through. Just had to take an inventory of what's going on. Then the second one--

Chris: That's amazing. It really is not how my brain works. I immediately need to do things.

Dave: Yeah, publish first. Publish blaster.

[Laughter]

Chris: Yeah.

Dave: But the idea was you see the whole map. See the whole territory.

Chris: Yeah. Yeah.

Dave: Then start. You can make association then, like, "Oh, these two are complaining about the same thing, so I'm going to merge that into one issue. Now I have half as many issues to care about."

It's hard. It's hard work because somebody says, "Oh, I have a problem with this," and you have to now say you have their human encoded problem and you have to kind of figure out where that is manifesting in code. It's this weird, like, you have to kind of reverse engineer their issue. And sometimes they're not... [laughter] they're crazy. They are just like, you know, they woke up weird and they thought this--

Sometimes I get emails, like, "Oh, this showed up in my Gmail. Who hacked me?" or whatever. You're like, "Sorry. Fitvids didn't hack you. [Laughter] You're confused. I don't know."

It's weird. Open-source is weird, right? It's this... You open up a portal to your life and people demand work of you, and that's labor-intensive and burnout inducing. Yeah.

00:10:44

Brian: Yeah, that's one of the things I talk about is trying to balance all of that because, as projects grow, you start to attract more and more noise or user needs, right? You might have built it for a particular use case or set of constraints. Now someone is completely turning on its head or wanting to add another dimension to. And it gets really exhausting but also exciting to try to--

If you're a toolmaker, you build things for people. You want to find that balance of making that. But it could be adding permutations to the amount of work you need to do if you just add another config file, another if/then check. It starts to weigh down the code base and weigh down your mental model of what's happening.

Some of my most formative memories from Pattern Lab was when people were doing things I had no notion that they could or should do with it because it didn't match my mental model of how I wanted to use it. I had to decide in that moment, like, "Well, do you listen to them? Do you hope that they can help maintain it over time? Do they add tests?"

I think my results at the time were kind of middling, right? There were some great successes and some things that I still look back on, like, "Oh, man. That was tough and it added a lot of complexity that wasn't worth it." That kind of stuff happens all the time and maintainers have to navigate it.

Chris: That seems extraordinarily hard to me; one of the hardest things. It's like this balance between two things. It's so great to have somebody contribute to a project, right? I'm sure you felt that in the early days - or anything.

When it's just you and all of a sudden somebody is like, "I'll help," but then their way of "I'll help" is "I'm going to add this checkbox to the settings. I'm going to add this configuration file. You're going to love it. We're going to use YAML. No problem with that, right?" - or whatever.

They make some choice that you wouldn't make, and then philosophy has to get involved. Then you have to explain yourself or codify your choices in some way and say no.

Brian: And say no. Right. Right.

Chris: That's tough.

00:13:04

Brian: That's one thing I try to be adamant about in the book is when you're in that maintainer relationship and you need to say no, you're so much better off--like you said, Chris--codifying it into linting rules in the tests, in the things that are nonnegotiable. You want that PR feedback loop or that contribution cycle to be as frictionless as possible.

If you really have some kind of redline opinion, you need to make it really, really obvious and part of that context that people can discover and adhere to come asynchronously. They shouldn't have to wait for you to review it to say, "Oh, no, no. I wanted tabs instead of spaces." Right? That kind of stuff is so, so clear.

Chris: Right. Fortunately... Are we past that one? I would hope that people aren't--

Brian: I think so. Yes.

Dave: You say that, but I have spaces right now. [Laughter] No, soft tabs.

Where does that fall into the process? Say we're starting an open-source project. Guys, we're doing it. We had an idea. I cooked up a prototype. What do I do? Do I put it online? Do I put it on GitHub? That's the next step?

Then do we need to start layering in these rules or can that happen later? Let's say I made some code in a CodePen and I want to turn it into an open-source thing. What's the next step? How do you approach--?

Brian: That's a great question. I think the way that I would approach it is probably a degree of it depends, which is our favorite answer. But I do short list--

Dave: Senior developer has logged into the chat.

Brian: Uh-huh. Yeah, you bet.

Dave: Yeah, yeah, yeah. [Laughter]

Brian: That's the best thing ever. But I do try to have an opinion around four files that people should have if they're considering open sourcing anything, and that's a read me, a change log, a contributing file, and a code of conduct. These are, in my mind, essential to building that asynchronous context and that expectations exchange that you'd want when you open-source something.

I have this maybe high road idea of open sourcing things is a contract or a relationship that you make with someone. It's not transactional, so it's not this dumpster that you just kind of throw things into and people can rummage through it as they want to.

As you build community around something, they become implicitly reliant on it or dependent on it in some capacity. Maybe it's very small if they can rip it out and use something else. But if it makes their day a little bit easier, I drive energy from that and I also see it as maybe a two-way street.

When people start using it, I want to make sure that I'm not doing them harm, and that's complicated. So, that first open sourcing act I think still needs to keep that in balance. You can start small, but you need to start with a license. You need to start with basic, basic read me on how to use the thing. You shouldn't be expecting someone to plum through the code in order to understand how to use it.

Dave: Yeah, it does seem if, I guess... Not all open-source has to be open to contributions, I guess. But if you're going down that path, it does seem like an ounce of prevention pays off ten-fold, right? Whether that's... I mean just dumping into your read me docs so that you don't get, "How do I use this?" in support tickets is huge.

Contributing is huge. Issue templates, huge. I mean, for me. An issue template where it's bug or feature request, and then on the bug it's like, "Where is your reproduceable test case?" I feel like you could almost stave off 50% to 75% of the issues from that. Like, "Here's somebody who tried it and they found their problem along the way."

Or even a feature request, it's like, "Are you willing to implement this, yes or no?" Yeah, I would. Then you're like, "Cool, I don't have to think about it."

00:17:34

Brian: Mm-hmm. Mm-hmm. Yeah, I love all that. And it's always a balance, too. One thing that the book's research highlighted is that I think a lot of our world view around open-source is tethered in some way to GitHub and other tools have the concept of templates and had the concept of code ownership, pull requests, all that. But it's kind of interesting that this social media site built on top of code is so engrained in the world. And I've tried to highlight where those things are true and where they might be strained and focused on the real foundation regardless of the tool, too.

Dave: Yeah. Yeah, I guess it's like being equated to GitHub to just open-source is a false dichotomy. But it's the majority, probably, right now.

Brian: Yeah. Yeah, and not to dwell on them for too long, but I think they've been such a net positive in accelerating so much awareness and collaboration. But there're always interesting things that come along for the ride, like people's read me kind of turn into these bumper stickers or these NASCAR-like--

Dave: Sponsorship, yeah.

Brian: All these things that they have or all the shields that they have. A lot of those things aren't even accessible. Like if you read them through a screen reader, it's just this complete garbage of server-generated image data saying what their download count is or what language they use. It's really easy to not focus on that kind of thing and think about how tied we are to something like GitHub.

00:19:41

Dave: Well, yeah. Now you're getting me into star counts and download counts, and I'm just like... I was thinking the other day. I somebody post, like, "Oh, we've been downloaded five million times," or whatever. It's like, "Yeah, how many of that is just CI?" Every time I push code, it gets a clean, freshy. Yeah.

Chris: I depends on how you set up that CI. Yeah, it is a little random. But it's something. AT least it's consistent for everybody.

Dave: But even now it's like I know for a fact people juice their star counts. You know what I mean? They go buy--

Chris: Hmm...

Dave: Just like they buy app downloads and just like they buy followers, fake followers. You know it's turned into this whole economy of popularity on top of, "Hey, dude. I just need to get my code." [Laughter] You know? Then what is the DigitalOcean hackathon where they just said, "Go commit code and get a T-shirt."

Brian: Hacktoberfest.

Dave: Yeah.

Brian: Where are they at right now? It's October.

Dave: Oh, yeah.

Chris: All these open-source libraries get these AI commits to their read me - or whatever - so they can get the T-shirt.

Dave: Yeah.

Brian: I'm not so sure about the AI wave that's going to happen. I've seen a lot of that on the Node.js project that I help maintain now. But I think Hacktoberfest and those organizers have gotten a lot better over time - if you haven't looked at it in a while - in terms of creating opportunities for non-code contribution.

It's very similar to the spectrum of engagement that I talk about in the book and celebrating that huge, huge ecosystem. They are making pathways where they can for folks to do that kind of thing.

Chris: And you want people in on this, right? That's kind of the thrust of it. It's approachable open-source. Even though you burnt out on it at one time, it's your goal, you might say, to have people contribute, to be part of this world.

00:21:46

Brian: Yeah, that's maybe the central thesis of the book is that you can't even do much of anything now without being impacted by the open-source ecosystem up and down the stack, like end user devices. You go deep in their settings; you can see all the open-source libraries and tools they use. Open-source software helped send the Mars Ingenuity Helicopter to another planet. It's just literally everywhere. Out of this world, you could even say, right?

Chris: And it's good for the world, you'd say, because it is a little bit of a tough sell. It can be hard to know where to start. Hopefully, the book helps. There can be problems with community in there. It certainly doesn't have any money going on for it, too.

I just mean the sell for it then is it's there. To some degree it's naturally there. People want to be involved in it. Most software is mostly open-source. That's amazing to me.

There's some kind of natural draw to it. But you almost want to push it a little more. Even if you're not drawn to it, maybe you should be. Is it for the good of the world? Is it because we're sending spaceships with open-source code that the world will be a better place if people took open-source more seriously and contributed?

00:23:10

Brian: I think, on some level, I have been chasing that feeling I had from a long time ago of, like, finding community and drawing energy from like minded folks or maybe diverse minded folks who are coming together to further some element of their workday or their life. A big part of what I mean by that is there's a lot of latent energy within the engineering space (the designers, the technologists) that are adjacent to open-source software that can contribute if only they feel empowered to do so.

Chris: Right.

Brian: The book tries to talk about that and also really tries to hammer home the point that this is not something you need to do on nights and weekends in a coffee shop or in the darkness with a hoodie, like a hacker or something.

Chris: [Laughter]

Brian: This is work.

Chris: Yeah.

Brian: This is work, so it should be work. Upstream contribution is really part of your day-to-day, whether you're working for an agency or a large enterprise or you're a student - whatever you want to say - because we're so intertwined with its consumption that I see it as the same, you know, a different side of the same coin to also contribute back to it in some capacity.

Chris: Yeah, it certainly is at CodePen. I'll tell you what. We've used a lot of kind of like middling size things that end up being open-source. There tends to be quite a bit of this, like, "Can it be like this?" and us taking the time to do PRs. Not me so much, but I credit my team for regularly choosing to upstream something or start it as an issue or something, and having it generally work out pretty nicely for us. I'm like, "Dang! Good thinking!"

Brian: That's great.

Chris: I've been in this industry quite a while, and my brain still quite doesn't think like that. Maybe I'm just too much of a dirty capitalist.

Brian: [Laughter]

Chris: Almost afraid of it or something. But I'm like, "Oh, but it's work for no money?"

00:25:22

Brian: You look at stuff like the product model that a lot of teams or enterprises work within. They're incentivized and optimized around the idea of getting things done fast so they can move onto the next Gira ticket or next thing in the hopper, right?

This whole mindset needs to take a little bit broader view, an upstream spirit that will affect everyone and will help everyone be successful. I've seen it happen, and it's really great when it does.

Dave: It takes effort too, right? Blasting out an issue, like, "Make my thing!" doesn't win hearts and minds on the old issue queue. So, you do kind of need to be like, "Hey, here's my problem. Here's what I've tried, and here's a proposed solution." That goes a long way.

Brian: It's that investment in time by the reporter of that issue. You're valuing the maintainer's time by filling out their template if they have one, right? Giving them a clean reproduction.

It's about reciprocity in that relationship. If you're only consuming and consuming and consuming, and you're more thinking about, like, "What have you done for me lately?" that's how we've gotten into this kind of unsustainable model (in my opinion).

Dave: Yeah. Yeah, there's a real big sense of entitlement on some issue queues. Just like, "Obviously, this project is dead because the maintainer doesn't care." It's like, "I don't know, man. I just had a kid, so that's kind of where I'm at." [Laughter] You know?

Or, "I'm in jail, so that's why I didn't do it." [Laughter] That happens. You know? Yeah.

Chris: Yeah. Good stories there. Yeah.

00:27:22

[Banjo music starts]

Chris: All right, let's be real. If you're a content creator, blogger, or an entrepreneur just starting out, the last thing you want to do is spend hours and hours and hours building a website. You've got things to do. That's where Bluehost comes in.

Their AI-powered design tool gives you pro level WordPress sites just like that - snap fingers emoji. No coding. No stress. Just type in what kind of vibe you're looking for and, boom, you've got it.

You also get added features like marketing and e-commerce tools to help you build, grow, and scale your online business like a boss. And upgrading to Bluehost Cloud keeps your site running 24/7 with ultrafast hosting, 100% uptime, always fast, never slow, so you can keep making that dough - a little rhyme.

It's seriously never been easier to build your website. With Bluehost, you've got the ideas. Now you need the platform. All you need is Bluehost. Head on over to bluehost.com/shoptalk and start building your dream website today.

Again, do you need a website fast? Bluehost AI gives you a custom built WordPress site in minutes, and the built-in marketing tools 24/7 support keeps your website growing. It's never been easier to launch your site. Go to bluehost.com/shoptalk now to launch yours today.

[Banjo music stops]

00:28:48

Chris: I like the, you know, "If you're going to do it, do it right," stuff that's in the book as well with the four files and stuff - just circling back to that for a moment. I remember when a younger version of me barely knew what GitHub was, early CSS-Tricks days, would put some repos up there.

I remember we had some kind of slider or something. I can't even remember the details of all these things were. Then somebody would want to use it, and then now knowing rightfully so, they'd ask, like, "Can you put a license on it because I can't use it at work without the license on there?" Probably younger, jerkier me was like, "I don't care. I don't care what your problem is. I don't want to learn about licensing. I don't want to get it wrong. I don't want to take. The code is right there. I don't care. Use it."

Dave: I'm still that jerk but go ahead.

Chris: Yeah.

[Laughter]

Chris: But they can't. That's one of the four, isn't it, the license?

Brian: Yeah.

Chris: Yeah.

Brian: Correct, yeah, the licenses is pretty paramount. And I will be the first to admit that it seems dry on its kind of first read. You kind of stare at it, and you kind of want to look away at the entire concept. But there are pretty huge effects.

Chris: What's the good one?

[Laughter]

Chris: Is it too "it depends"?

Dave: I mean, it's MIT unless you're fundamentally free, open-source, FOS, right? Then you use GPL. Those are your two big ones, right?

Chris: Those are the two big ones, and I still, to this day, don't really understand. I really don't. So ignorant.

Dave: Well, if you use... If anyone uses any GPL code, like if you use any part of WordPress, then you're--

Chris: Then everything else you use also has to be GPL, right?

Dave: Everything has to be open-source.

00:30:37

Brian: Yeah. The way I describe it in the book is almost like a CSS important declaration, like, "This is going to override the cascade of downstream code."

Chris: It's very helpful.

Brian: There are caveats and carveouts and different variants, so it does get a little messy. But that's a good way to start.

Chris: There's no MIT crap up in WordPress because it's just not allowed. It would infect it.

Brian: GPL maybe, right?

Dave: Yeah, MIT stands for money in transit.

[Laughter]

Dave: Then GPL stands for gonna pay lawsuits.

Brian: [Laughter]

Dave: That's my understanding.

Chris: Wow.

Dave: [Laughter]

Brian: Another topic I cover in the book, too, is there's been the advent of a bunch of new licensing out there that's trying to stop these big, big hosting companies. I don't know if I will name them, but they'll take an open-source product and stand it up as a part of their suite of cloud services. That is a direct threat to those open-source companies that are kind of trying to do the same thing with their freemium business model.

Licensing has been evolving over time to get much grayer, much more indistinct and easy to understand. I kind of hypothesize that that's okay because it mirrors the real world. These really absolutionist thoughts around open-source software has definitely fueled its success over time. But it's also threatened some of these giant, giant products and capitalism blah-blah-blah, right?

I think it's time that we are okay with some uncomfortable negotiation to make sure that the communities and the ecosystem stays healthy (even if that means we need to get some lawyers looking at things once in a while). That's okay.

Dave: More lawsuits in tech.

[Laughter]

Dave: Yeah. No, I mean to me that does seem fair. I think you're maybe hinting to the Redis AWS drama, right?

Brian: Right. Right.

Dave: AWS is just like, "We sell Redis," and Redis is like, "Oh, we also sell Redis. That stinks for us."

I do think there needs to be some exchange of money if somebody builds a monetizable product that is just your product, basically, or some wrapper around your product. But then, yeah, where does that stop? How big is the company? How big does that company have to be? How much revenue?

Brian: Yeah. Yeah, I mean it's ambiguous, and that maybe is a red line for some folks. They don't want to even entertain the ambiguity.

Dave: Mm-hmm.

Brian: But the alternative is proprietary software, right? Have you ever been at a company where they licensed the servers based on how many cores are running on the hardware?

Dave: Yeah.

Brian: It's just this completely foreign concept if you're running Linux things and you just do whatever you want.

Dave: Or font licensing. [Laughter]

Brian: Yeah.

Dave: How many computers is this going to--?

Chris: Uh, I know, but it's so tempting. There are so fewer problems with it if you just don't play this game. The problem is, you can't because you're going to be built on open-source software, so the second you make every single thing you do proprietary, you're just a damn leech, really. Ugh!

Brian: Yeah, so maybe the whole book is an exercise in saying, "It depends," right? But I do hope that it's a primer on a lot of these subjects, which oftentimes require a lot more discussion and nuance. But the framing of it is really about, like, "Here is the exposure to the concepts. Here's why it matters."

Dave: Yeah. I use WTF PL, which is basically do WTF you want to do with it. I have a few people who are very unhappy with that license. [Laughter]

Brian: Yeah, and it's usually--

Dave: But it's also called GPL compatible and MIT compatible. But it's also this... I think people have a narrow... like, they can only use this software. You know?

00:35:09

Brian: Yeah. I don't think it's out of a misalignment of their morals - in most cases. It's more about licensing jurisprudence - if I could use that kind of term. It hasn't been tested in court. The lawyer type people don't know how a dispute like that would shake out. So, that's where the ambiguity or these kind of like boutique licenses get a little strange to bring into a corporate environment, for example.

Dave: Yeah. I guess there's Apache, too, right? But that's almost like MIT.

Brian: Yeah, they're pretty similar.

Dave: Yeah.

Chris: Is one of them adherence to--? Doesn't the word open-source actually have a pretty strict definition and only one of them is actually open-source? Do I have that right?

Brian: Both Apache and MIT are open-source compliant.

Chris: Okay.

Brian: There's the OSI, which is the Open Source Initiative. They are kind of a derivative of some of the first folks that were involved with open-source software, and they maintain the definition. I think it has ten principles that go into it around, like, the freedom to look at the source code under any circumstances. I quote it all in the book, but I don't memorize it.

Chris: Right.

Brian: There's a lot in there. And what's interesting is that the entire industry is grappling with the same idea with AI. It's impossible not to talk about it probably in some capacity. Open-source AI (and the definition of what that means) is actually under review right now.

The OSI has been globetrotting to different conferences and getting feedback from experts all around to try to decide what it is that makes an AI model or large language model open-source. Is it the code? Not really. Is it the training data? Is it the weights? It gets kind of interesting pretty fast, and they're actively figuring that out right now.

Dave: Yeah. That whole part of it changes the whole discussion to me, too. We are now in a world where I don't know who made the code. I don't know where that code came from.

I don't say that ignorantly. But if I look for the for loop that just got robo barfed out, that for loop could have come from anywhere. You know what I mean?

00:37:55

Brian: Yeah. Yeah, I had this kind of funny joke the other day where a Copilot tool generated a Slack channel name for me. The Slack channel is this alpha numeric identifier, so that was someone's Slack channel, right? Or did it--?

Dave: Yeah.

Brian: [Laughter] Is that how it works?

Dave: Yeah, Copilot started adding comments with references to users and stuff in my code once, [laughter] and I was just like, "Dude, what?!" That stinks for them, but I don't know. That whole change changes the idea of comments to me.

We've had creative comments before, but is code now just comments? Is it? I don't know. Question mark. Then how do people get money and get paid for this free work they're doing because I know there are companies out there who just see it as free stuff.

Brian: Yeah. Yeah.

Dave: They are just like, "I'm just going to use free stuff and never pay a dime for a developer."

Brian: There's some great work that's being done kind of across the industry to experiment with funding models. That's one thing that I talked about at the end with Abby Cabunoc Mayes who works at GitHub and has been involved in the community for a long, long time.

But the Sovereign Tech Fund--I think they're out of Germany--is actually paying fellowships to different open-source projects where you are kind of a visiting employee of that team. For a period of a year, they'll pay you to work on your project - no strings attached. That kind of stuff is super-exciting.

There's a lot of tooling in companies that are emerging now around analyzing your dependencies and programmatically doling out donations based on how much you're using some dependency.

Chris: Yeah, I love that one. I think that's super-cool.

Brian: Yeah.

Chris: How much of your codebase is it. I don't know how it figures out what to do, but just because it's low effort. I can imagine a company being like, "Okay, it's the end of the year. This is definitely the right thing to do. We have $10,000 of our budget to do this. How are we going to do it? Oh, I can just push the button and it will figure out how to dole out that $10,000? That rules."

Brian: Yeah. Yeah, so I think that we're in a period of time right now where we're experimenting.

00:40:32

Chris: I think it's thanks.dev. Is that one of them?

Brian: That's one of them, yeah, and I also believe it's somewhat built into GitHub's sponsor feature where whatever your repos are, it will see your dependencies and (one click, two click), you can very easily add sponsors to your biggest ones.

Dave: And fund people with that?

Brian: Yeah.

Dave: That'd be cool. There's also Tide Lift, which I think is an interesting organization. I think it's like that German one you said, but it's just basically like, "Hey, we have open-source mercenaries who go in and fix stuff." [Laughter] You know? Or "We fund projects." That's kind of cool.

If you need a feature from a project, you could hire them, maybe, or something. But too, I think about the whole, like, wouldn't it be nice, like, "You have to be a paid supporter to file an issue." You know? Even if somebody does that for one month--

Chris: Oh, I love that so much.

Dave: And it cost them a buck. That feels good to me to file an issue. But at least they're invested in the project now. Or maybe it's like, to be a company committer, whatever you pay, the $500 a month to be a company committer or approver. Yeah, I don't know. Or a built-time sponsor.

It seems like GitHub could kind of do more things. I say GitHub, but any hub of code could do more things to juice people's funding; give some tools.

We haven't really addressed the burnout system, really, but that's a very real issue. I experience it all the time. I inherited an accessibility project again because of burnout. It's a very real issue, so how do we deal with that? How do we cope with it?

Money seems to solve the problem, but I'd love to know your perspective. When you burnt out--maybe you could tell us that story--would money have fixed it or what?

00:42:48

Brian: I don't know. I don't think money would have, actually, because I was making money on Patreon at the time, and it was not nothing. It wasn't paying the mortgage, but it was healthy.

What really killed the project and made me burn out was not using it daily anymore. I switched companies, and I didn't need to use it anymore. And I started to drift away from my user base and the concerns that they had.

I thought I knew what they wanted. But it became more and more conceptual. And it was just harder and harder to invest that time when I didn't have that payoff that was intrinsic to me in it.

Chris: That seems like a big one.

Brian: Maybe use the thing? Yeah, so it was a slow burn, right? But to address your overall question around burnout, I think this feels where the role of these neutral foundations like the Apache Software Foundation, like the Linux Foundation, CNCF, they all have adopted this kind of nurturing mindset of neutrality where there's no one company that can rug pull out from under them. There's no one set of maintainers that keeps it going. It creates this critical resiliency that I think is what the community needs more.

You see that with Redis. Not Redis. Was it Redis Valkey? Now I'm struggling.

Dave: Yeah. Yeah. Redis Valkey. Redis changed their kind of licensing.

Brian: Yeah.

Dave: And Valkey was like, "No!" [Laughter]

Brian: Yeah.

Dave: "We're forking the old one."

Brian: Right. The same thing happened with HashiCorp stuff that a lot of enterprises used.

Dave: Teraform and all that, yeah.

Brian: Right, Open Tofu, and that I think is a vehicle to help with burnout because those organizations are built with this in mind. They're built with governance and good practices around the organization.

They try to handle a lot of that for coders. But it's certainly not like a silver bullet because not every open-source project reaches that level of maturity and there are a lot of tactics that I mention in the book that for us small entities how you can try to manage and cope with your overnight success.

00:45:36

Dave: Yeah. Well, Evan You just launched VoidZero.

Chris: What's that?

Dave: It's got $4.5 or $6 million in funding for Vite, Vitest, Rolldown, and OXC, so a bunch of build tooling. So, it's this weird... There's money in here. People are investing. But I do think you need these strong organizations, like you're saying.

So much of open-source is this myth of the lone developer, this one dude's repo in Nebraska.

Brian: Yeah. Yeah. Yeah, that's in the book.

Dave: Yeah, and that's very true. I think Zach Leatherman is literally that person.

[Laughter]

Brian: Right.

Dave: But do you--? If you have a group, a community, and that vehicle is able to assume money to help in hard times or contract out very specific work - or something like that - that's kind of cool. That would be... I don't know. That seems very valuable. Maybe I need to think about that more. Just bigger coalitions of people co-owning projects, right?

Brian: Yeah, and I think that that's what has staying power over a lot of these VC-backed kind of flashes in the pan. There are plenty of them. You can look to something like Roam Tools, which was really exciting. "Oh, this is going to be the end all, you know, linter and formatter." I'm probably butchering the rest of what it could do.

Chris: Yeah.

Brian: But it generated a whole bunch of buzz and then kind of fizzled. Now actually Biome came out of it, which looks pretty great. But there's a cycle, right?

Chris: For sure.

Brian: When you're in this foundation aspect, I think you get a little bit more resiliency to that cycle.

00:47:43

Chris: One thing it made me think about with this, talking about burnout, a thought that stuck with me about what it is and how it happens is when you work, work, work, work, and you have little agency of that work. That you don't control when it ships, how it ships, if it ships, the direction of it. You just feel like you have little control. You have to work, but you're not even sure if you have any agency over the thing at all. That's a recipe for burnout.

But I wonder if the opposite of that is a recipe for why people get involved in open-source. Maybe if you don't have any agency at work or are looking for some in your life, generally, that open-source work can be that outlet for you. That you actually can have a little power in open source because you're building this project. Now you're the royalty of that project or you can work your way up to it and actually have a little control over something that you're doing. It's kind of the opposite of burnout. It could still cause burnout.

00:48:49

Brian: Yeah, it's almost that spark (right) that can do great work.

Chris: I can matter. And you can.

Brian: Yeah, and one thing that I really try to hammer home, I guess, is that our industry, the Web, is 30 years old - something like that. Open-source software is even younger than that. There are so few of us that we expand a single lifetime, and yet we've caused so much change within tech and within the world. Our percent impact on the industry is noticeable.

You mentioned Zach before. Singular entities can move the needle of entire movements, and that's really exciting. That gives me a lot of energy. Not to be the open-source darling, but that means that every single person who is engaged with the open-source ecosystem has that ability to do something like that. That's really what I love.

Chris: That's a nice thought. Super cool.

Brian: Yeah.

Chris: That's awesome.

Dave: Yeah. Yeah, that's cool. Well, awesome. I think that's probably a good place to end it just because I'm inspired. I don't know that I'm quite ready to open up a whole new repo, but we'll see. [Laughter] I've got stuff to put up there, but I guess, Brian, for those who aren't following you and giving you money, how can they do that?

Brian: [Laughter] Sure. So, approachableopensource.com is where you can find the book and find additional writing about the entire concept and any current events I'm going to keep up there. On LinkedIn, you can find my big, long last name pretty easily. That's, I guess, the social media of choice besides Mastodon. That's about where I am these days, just those two places, and I'd love to have the conversation with anyone who wants to.

Dave: All right. It's also... We didn't really get into it, but your book is for sale. You could buy it. But also, it used to be A Book Apart book.

Chris: A casual tee up for the demise of A Book Apart. We didn't even get all into that.

Dave: We didn't.

Chris: That sucks. I'm holding it up to the camera, which nobody can see because we don't even do anything with this video. But it's the exact size and width of A Book Apart book. Sorry about that, man. You got down that path and then, when companies shut down, there are consequences. You probably suffered among the best of them with the demise of A Book Apart.

But you grabbed the reins and made it happen anyway, goddang it, through your own grit and determination and money and time. Have self-published this thing all the way through print. Print is a whole other ballgame.

Dave: Yeah. I only call it up, not to bring up past traumas, Brian, [laughter] but to just say it's going to be a familiar look and feel and level of quality that people are probably used to, so great work.

Brian: Yeah. Yeah, thank you for that. I benefited from a lot of their great editors. Say what you want about what happened with ABA, but the folks I worked with were stellar. They helped make the manuscript what it was and really hone the message. So, yeah, I mean it's an ABA book wearing a trench coat, right?

Dave: Yeah. [Laughter] There you go. Perfect. Awesome.

Well thanks again for coming on the show. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Follow us on Mastodon. We like that one. Then join us over in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you have anything else that you would like to say?

Chris: [Laughter] ShopTalkShow.com, your local, not open-source WordPress website.