Thanks to Aaron Jorbin’s proposal for A WordPress Book Club, I dove back into reading Karl Fogel’s “Producing Open Source Software“. I’ve picked the book up several times in the past, but got sidetracked by life and never managed to complete it though always enjoyed it and took bits away for other parts of my (work) life. This time around, with the book club group’s weekly meetup holding me accountable, I hope to complete my reading.
As part of Aaron’s prodding to folks in the book club, I’m also planning to keep this post updated with things I find interesting in the book (so look for updates here ~weekly as I progress through the book with the club). My plan is to excerpt portions I highlight as I read and, when I can recollect why, I’ll include notes as to why I felt a specific portion was meaningful.
Foreword
It’s been said that humility is the most underrated force in the world today. Successful open source leaders demonstrate this over and over by driving for consensus on major ideas, making it clear their own ideas are open to challenge, and being as transparent as possible.
Folks who’ve worked with me may have heard me remark “tell me why I’m being stupid here” to try and lighten the tone in a conversation and solicit feedback and alternative options. Pair this with Paul Saffo’s “Strong Opinions Weakly Held” (Educom Review, 1998) that I generally try to take to heart and be open to those alternate options and changing direction.
Building a sense of empowerment amongst the developers is more important than meeting ship dates with specific features, and more important than creating zero-defect software. The Apache Software Foundation, for example, believes that its first order of business is creating healthy software developer communities focused on solving common problems; good software is a simply an emergent result.
I had definitely not considered community-building as a primary goal and allowing for “good software” to follow, so this is a concept I’ll be looking to observe and test out when I can.
Among many other benefits, this rule means that leadership in an open source community comes not from leverage or control, but from finding common interests and expertly managing what is volunteered.
My experience within the WordPress project, primarily in a project / product management capacity, is definitely a lack of leverage or control and that “expertly managing what is volunteered” being the hardest bit to manage in trying to get to an ideal release date with specific features.
Open source projects don’t compete for “market share” — for dollars from the user base — because there aren’t any. Instead, they compete for developer mind share and heart share, and that’s not going to flow to a leader who’s obstinate, unresponsive to the user community, or technically unsophisticated.
Noted Karl; though we all would benefit from the “don’t be a jerk” approach to life.
Preface
I’d summarize the economics of open source: that there are organizations in whose interest it is to have certain software exist, but that they don’t need to sell copies, they just want to make sure the software is available and maintained, as a tool instead of a commodity.
source: Why Write This Book?
A quick sidebar to these organizations: please. fund. open. source.
A free software project can be started, and it can be influenced by interested parties, often quite strongly. But its assets cannot be made the property of any single owner, and as long as there are people somewhere — anywhere — interested in continuing it, it cannot be unilaterally shut down. Everyone has infinite power; everyone has no power.
source: Why Write This Book?
WordPress famously forked b2/cafelog. The infinite power/no power bit there feels like a solid open source conference t-shirt.
Free software projects have evolved a distinct culture, an ethos in which the liberty to make the software do anything one wants is a central tenet, and yet the result of this liberty is not a scattering of individuals each going their own separate way with the code, but enthusiastic collaboration. Indeed, competence at cooperation itself is one of the most highly valued skills in free software. To manage these projects is to engage in a kind of hypertrophied cooperation, where one’s ability not only to work with others but to come up with new ways of working together can result in tangible benefits to the software.
source: Why Write This Book?
Enthusiastic collaboration, a term Jorbin also highlighted and specifically utilized in the Week 1 session of the book club also stuck out to me. “Competence at cooperation” feels like a great follow-on from the “expertly managing what is volunteered” earlier, a difficult skill to learn, an even harder one to utilize, but one that a great project/product manager (maintainer?) can use to wonderful benefit of an open source project.
1. Introduction
When a free software project runs aground, it is often because the developers (or the managers) did not appreciate the unique problems of open source software development, even though they might have been quite prepared for the better-known difficulties of closed-source development.
source: Introduction
I’ve managed both open source and closed source projects, and while the complexities and difficulties of closed source development are significant, from aligning stakeholders to managing timelines and resources, open source adds an entirely different layer of challenges. You’re not just building software, you’re building consensus across distributed teams, aligning diverse motivations, and fostering a community that often extends far beyond any single organization. When it goes wrong, it can be harder to recover than in a closed environment. But when it goes right, the outcomes are remarkable: the shared ownership, unexpected innovations, and sense of collective achievement make the effort more than worth it. I love open source, its communities, its people, its software.
Next comes the fallacy that little or no project management is required in open source, or conversely, that the same management practices used for in-house development will work equally well on an open source project. Management in an open source project isn’t always very visible, but in the successful projects, it’s usually happening behind the scenes in some form or another.
source: Introduction
I think I might just copy/paste this straight into my LinkedIn profile.
The GNU General Public License (GPL) is a clever piece of legal judo: it says that the code may be copied and modified without restriction, and that both copies and derivative works (i.e., modified versions) must be distributed under the same license as the original, with no additional restrictions.
In effect, it uses copyright law to achieve an effect opposite to that of traditional copyright: instead of limiting the software’s distribution, it prevents anyone, even the author, from limiting it. For Stallman, this was better than simply putting his code into the public domain. If it were in the public domain, any particular copy of it could be incorporated into a proprietary program (as has also been known to happen to code under permissive copyright licenses). While such incorporation wouldn’t in any way diminish the original code’s continued availability, it would have meant that Stallman’s efforts could benefit the enemy — proprietary software. The GPL can be thought of as a form of protectionism for free software, because it prevents non-free software from taking full advantage of GPLed code.
source: Conscious Resistance
A really great, concise primer on the GPL for those not conversant.
It’s true that all free software is zero-cost,[6] but not all zero-cost software is free.
source: “Free” Versus “Open Source”
The might read a bit confusing, at least until you get through the next section below.
This confusion over the word “free” is due entirely to an unfortunate ambiguity in the English language. Most other tongues distinguish low prices from liberty (the distinction between gratis and libre is immediately clear to speakers of Romance languages, for example).
source: “Free” Versus “Open Source”
Raise your hand if you’re surprised the English language made things more complex than necessary. No one? Yeah, didn’t think so; way to go English. Libre Open Source Software (LOSS) perhaps as the new term to utilize? Yeah, you’re right, LOSS is not a great acronym (I’m not sure that FLOSS is any better).
In 1998, the term open source was created as an alternative to “free”, by a coalition of programmers who eventually became The Open Source Initiative (OSI).[8] The OSI felt not only that “free software” was potentially confusing, but that the word “free” was just one symptom of a general problem: that the movement needed a marketing program to pitch it to the corporate world, and that talk of morals and the social benefits of sharing would never fly in corporate boardrooms.
source: “Free” Versus “Open Source”
Convincing the corporate world about the benefits of usefulness of open source has created the most enjoyable parts of my career. So for that, thanks OSI!
Mainstream corporate CEOs and CTOs will never buy “free software.” But if we take the very same tradition, the same people, and the same free-software licenses and change the label to “open source”? That, they’ll buy.
Some hackers find this hard to believe, but that’s because they’re techies who think in concrete, substantial terms and don’t understand how important image is when you’re selling something.
source: “Free” Versus “Open Source”
I’ve been in those corporate offices and board rooms, what you might consider inconsequential semantics are often what sways decisions. Again, thanks OSI!
In marketing, appearance is reality.
source: “Free” Versus “Open Source”
Perception is reality. Perception is more important than intent.
good marketing, where “good” means “viable in the business world.”
source: “Free” Versus “Open Source”
A more simplified notion than a couple sections above; business viability of open source has likely unlocked a massive increase in investment (time and money) in open source.
But it is rare for a free software/open source developer to openly question the basic motivations of others in a project. The contribution trumps the contributor. If someone writes good code, you don’t ask them whether they do it for moral reasons, or because their employer paid them to, or because they’re building up their resumé, or whatever. You evaluate the contribution on technical grounds, and respond on technical grounds.
source: “Free” Versus “Open Source”
“The contribution trumps the contributor.” is probably another open-source conference t-shirt motto. There are some good “thought experiment” questions that come from this, so perhaps an item I’ll take back to the next WP Book Club meeting to hear what others think.
Free software is remarkable even among volunteer communities for its lightness of investment. Most of the people involved have never actually met the other participants face-to-face, and simply donate bits of time whenever they feel like it. The normal conduits by which humans bond with each other and form lasting groups are narrowed down to a tiny channel: the written word, carried over electronic wires. Because of this, it can take a long time for a cohesive and dedicated group to form.
source: The Situation Today
And because of this, having in-person events around an open source community can immensely help activate and build those community bonds. Cohesion via connection (emphasis absolutely mine) fosters trust, accelerates collaboration, and often creates the momentum that sustains contributions long after an event ends.
Conversely, it’s quite easy for a project to lose a potential volunteer in the first five minutes of acquaintanceship. If a project doesn’t make a good first impression, newcomers rarely give it a second chance.
source: The Situation Today
The new contribution experience is not easy to get right, but get it wrong and building the community will stall out faster than a project can get a chance to take off.
The transience, or rather the potential transience, of relationships is perhaps the single most daunting task facing a new project. What will persuade all these people to stick together long enough to produce something useful? The answer to that question is complex enough to occupy the rest of this book, but if it had to be expressed in one sentence, it would be this:
People should feel that their connection to a project, and influence over it, is directly proportional to their contributions.
source: The Situation Today
And getting people to get that feeling, is a key challenge for those looking to build an open source community around their beloved open source project.
No class of developers, or potential developers, should ever feel discounted or discriminated against for non-technical reasons.
source: The Situation Today
And neither should non-developers.
2. Getting Started
The standard way to do this is to put the full license text in a file called COPYING (or LICENSE), and then put a short notice at the top of each source file, naming the copyright date, holder, and license, and saying where to find the full text of the license.
source: How to Apply a License to Your Software
The GNU GPL says to put a notice like this at the top of each source file:
Copyright (C) <year> <name of author>
source: How to Apply a License to Your Software
“At the top of each source file”? I think in my work at Fueled + 10up, I cannot recall really even doing this in the main PHP file for plugins let alone each source file. I’m curious what others think, is each source file overkill or best practice?
Younger children hear the songs sung by older ones, and when they are older, they in turn will sing them in front of other younger ones. The children are not engaging in a conscious program of transmission, of course, but the reason the songs survive is nonetheless that they are transmitted regularly and repeatedly. The time scale of free software projects may not be measured in centuries (we don’t know yet), but the dynamics of transmission are much the same.
source: Setting the Tone
I definitely chuckled to myself when reading this as I imagined children singing the source code from some random WordPress plugin. 8)
If there’s no reason for it to be private, it should be public.
source: Avoid Private Discussions
This is a great motto, it likely belongs on a tech conference t-shirt.
From the very start of your project’s public existence, you should maintain a zero-tolerance policy toward rude or insulting behavior in its forums.
source: Nip Rudeness in the Bud
Zero-tolerance simply means never letting bad behavior slide by unnoticed. For example, when someone posts a technical comment mixed together with an ad hominem attack on some other developer in the project, it is imperative that your response address the ad hominem attack first, as a separate issue unto itself, and only afterward move on to the technical content.
source: Nip Rudeness in the Bud
It’s a short distance from calling someone’s technical proposal stupid to calling the person themselves stupid.
source: Nip Rudeness in the Bud
Instead, when you think you see it happening, make a post that stresses the importance of keeping the discussion friendly, without accusing anyone of being deliberately poisonous.
source: Nip Rudeness in the Bud
If you consistently call out bad behavior, but don’t demand an apology or acknowledgment from the offending party, then you leave people free to cool down and show their better side by behaving more decorously next time — and they will. One of the secrets of doing this successfully is to never make the meta-discussion the main topic. It should always be an aside, a brief preface to the main portion of your response. Point out in passing that “we don’t do things that way around here,” but then move on to the real content, so that you’re giving people something on-topic to respond to.
source: Nip Rudeness in the Bud
Fully excerpting those five segments together as a reminder really for myself for the optimal reaction in these scenarios. If others choose to follow Karl’s example here, then great.
Don’t worry that you might not find anything to comment on, or that you don’t know enough about every area of the code. There will usually be something to say about almost every commit; even where you don’t find anything to question, you may find something to praise.
source: Practice Conspicuous Code Review / Case study
One of my favorite things in code review is positivity (“great comment here!”, “really creative, simple solution!”) and not just always fix this, change that, nitpick another thing. More praise in code reviews please!
The very best thing you can do is lead by example. If you don’t see your developers answering enough newbie questions, then just telling them to answer more isn’t going to help.
source: Opening a Formerly Closed Project
The way to get them to participate is to participate yourself.
source: Opening a Formerly Closed Project
Y’all hear Karl, the best option is to “roll up our sleeves” and get into the work and a good community will hopefully follow that example.
…more to come with future WP Book Club weeks and further readings of Karl Fogel’s tome…
Update (10 SEP 2025): Added thoughts on chapter “2. Getting Started”.
This post’s featured image is “Signed copies of ‘Producing Open Source Software’” by ian weller is licensed under CC BY-SA 2.0.
