Reading: Producing Open Source Software, Chapter 2 – Getting Started
So this week was Chapter 2 of Producing Open Source Software and, true to form, I stayed up late the night before to get the reading done. Not my proudest habit, but hey, it got me reading, and that’s the whole point of joining a book club, right? And honestly, once I sat down with it, I found myself really interested. This stuff is about open source, about community, and even though I’m not a developer, it feels like exactly the kind of work I should be learning about. My day job is partnerships and community in the WordPress ecosystem, so yeah, this is community work.
I’ve got to give credit where it’s due; Aaron Jobin did a great job leading the group this week. He gave us some structure and nudges to participate, and that made it easier for everyone to jump in. I had a few highlights saved from the chapter (side note: discovered a neat Safari trick, if you highlight text in Safari, you can send it straight to the “Quick Notes” folder in Apple Notes, which is kind of hidden but really useful). That made it easier to come into the discussion with actual notes instead of half-remembered scribbles.
One section that stuck out to me was about naming a project. The advice was basically “look around first.” Maybe what you’re trying to build already exists, or maybe it fits better as an addition to an existing project. In WordPress, that often means a plugin or a contribution to core instead of spinning up something brand new. I thought that was timely. With AI changing things so fast, and with the reality that WordPress needs younger people coming into the community, there’s something powerful about channeling energy into existing projects instead of scattering it into the wind.
Another highlight: Fogel points out that even in projects designed for non-technical users, some percentage of those users are future developers. That clicked for me. You’ve basically got two audiences at all times: the everyday end user and the people who might roll up their sleeves and become contributors. My marketing brain went off here: that’s segmentation, right? Different messages, different documentation, different entry points. In business, we’d call it marketing, but in open source it sometimes gets treated as a dirty word. I’m not saying “sell out,” just that maybe we can borrow ideas from the business world, test them, adapt them, see what sticks.
There was also this part about how no project starts perfectly. In a dream world you’d launch with perfect docs, a user manual, cross-platform support, all of it. But in reality? That’s impossible. People hope others will fill in the gaps later. And that’s where I laughed to myself because I usually hate the phrase “hope is not a strategy.” It’s one of those eye-roll business clichés. But here, it kind of fits. Hope is at least a half-plan. The question for me is whether AI could step in here. Could we use it to accelerate documentation, compatibility notes, or early roadmaps? Not as a magic fix, but as a tool. The trick, of course, is being specific about what AI can actually do and setting up some kind of system that multiple projects could use.
Then there was the section about flaws. Fogel says: In open source, you list your shortcomings openly. No need to exaggerate, just be scrupulous and matter-of-fact. That’s a little brutal, honestly. It’s tough to admit what’s broken in something you care about. But it makes sense. Everyone sees the issues anyway. Pretending they’re not there just makes you look less trustworthy. The caveat is security; some things really do need to stay private, but outside of that, transparency wins.
We got a laugh out of the part about “naïve newcomers.” Every project has them. Sometimes they’re the next star contributor, sometimes they stay naïve forever. The tension is in how much time and grace to give people. And this is where it gets tricky, because open source doesn’t hire and fire. Anyone can show up, anyone can participate, which is both amazing and, let’s be real, chaotic. WordPress plugins are a perfect analogy: it’s great that anyone can build one, and it’s also… not so great that anyone can build one. That’s where codes of conduct come in. They’re a way to set boundaries in a space where there aren’t bosses and paychecks to manage behavior. It’s not easy, but it’s necessary.
That led us into one of the most fascinating parts of the chapter: codes of conduct for organizations. I hadn’t thought about this before. We all know about individual CoCs, but what about commercial actors in open source? The Arches Project has a really thoughtful example, guidelines for companies that participate. Stuff like: don’t replace community infrastructure, make sure your offerings are clearly labeled, contribute to shared documentation, don’t siphon conversations into private spaces. Reading that, I couldn’t help but think about WordPress. We’ve got sponsors, agencies, hosting companies, product makers, all of them commercial entities shaping the project. Instead of pretending they’re not there, why not have a set of guidelines? Something that says: yes, you can bring your commercial interests, but here’s how to do it in a way that strengthens the community.
We also circled around the point that open source depends on public conversations. Decisions made behind closed doors erode trust. Security discussions are one of the few exceptions. But otherwise, transparency is oxygen. And of course, we had to bring up Gutenberg. When it was introduced, the decision felt very top-down, very closed-door, and we’re still living with the ripples of that moment. Gutenberg, aka the block editor, is in a good place now, but the way it was introduced left scars. It’s a reminder of how fragile trust can be when discussions happen in private.
By the end of the conversation, I was struck by how much of open source is about people, not code. Grace, forgiveness, patience, transparency, all of those values are hard to live up to, especially when conflicts arise. But that’s the point. Open source isn’t just a job. It’s not just code. It’s community. It’s messy, it’s human, and it requires a different mindset than a paycheck-driven project.
So that’s week two. I’m still very much learning, still feeling like a bit of an outsider, but I’m glad to be part of this. The group is great. The book is better than I expected. And even if I only get the reading done at the last minute, I’m getting a lot out of it.
Wanna read a take from someone who is deep in the work? Check out Jeff Paul’s status updates of the book here.