Book Review: Producing Open Source Software

      Comments Off on Book Review: Producing Open Source Software

As much as I'd love to, I'm not going to name any leaders in the various PHP communities. Many are impressive and inspiring while others just get stuff done consistently and successfully, but I know I would forget a few and offend someone. If you're a group leader, please identify your group in the comments.

When I originally picked up Karl Fogel's "Producing Open Source Software" (not an affiliate link!), it was mid-2007 and I had not run a single unconference, web2project didn't exist, and I had not even heard of a hackathon, let alone participated in one. By the time I finished the book a few months later, it rocked my professional world and I couldn't wait to jump into the community fully and completely.

To be clear, Karl's book is about the difficulties and challenges of building a team to build a project, but almost all of it is relevant in the building communities in general…

Karl starts off talking about the beginning an Open Source project and the things – both community and technical – required to get things rolling. If you're participated in an even moderately active/successful open source project, none of this will be surprising, but having all of it enumerated clearly never hurts. If you go with something like SourceForge, Github, Google Code, Launchpad, or Microsoft's CodePlex, you'll have version control, forums, some release management and bug tracking immediately. As much as we'd like to believe otherwise, those are the easy parts. The hard part is the people.

First of all, he talks about basic Political and Social Structure of the team itself. While he lays out some general principles, the more important and valuable stuff are the specifics like:

  • How are important decisions made;
  • The proper traits of a Benevolent Dictator and how that control can evolve into a Consensus-based Democracy;
  • How community members become team members;
  • What roles and responsibilities does a team member have over a random community member?
  • And the benefit of documenting the decisions and goals.

As much as we'd like to think otherwise, in projects and communities in general at some point decisions need to be made. If it's not handled properly, a angst-ridden situation can become explosive with everyone choosing sides. Projects and communities can't afford those difficulties.

Next, in Communications, he talks about all the day-to-day things we have to deal with. Difficult users, the proper tone, how to diffuse arguments, and generally how to try to focus discussions towards the necessary topics. Does it all work all the time? No, but some of it definitely might work some of the time.

His most common concern is probably the most common problem online: Rudeness. Granted, we can usually remember that terse != rude but sometimes people get fired up and are looking for a fight. Throw in a few cultural differences and it could be explosive. I saw a perfect example of this at PHP Benelux this past January. The Americans and Brits spoke up and asked questions whether they were supposed to or not. The Germans were very direct and to the point but never interrupted a speaker. The rest of the audience was often quietly listening but for them that was engaged. In mostly American conferences, the distinctions are harder to see but they're still visible.

Finally, Karl goes into a detailed discussion of Managing Volunteers. This is where the vast majority of projects have problems and the reason is obvious. Very few developers – no matter how sharp they are – know how to motivate people, engage a community, and delegate tasks. Most of us confuse communications and evangelism with marketing… which – especially if evangelism is done poorly – can essentially the same. Throw in a few considerations like how money can distort priorities, goals, and intentions and how motivation can come from the silliest things, and it gets interesting.

Case in point: When I first read the book in 2007, I was with a startup with a simple policy. Whoever broke a production-destined build had to use a special hat as they Skype icon until someone else broke the build. When that happened, the old hat "wearer" passed it onto the new hat "wearer." And despite being a silly little icon that realistically was more peer pressure than anything, it kept people focused and convinced people to try a little harder. 

So overall, almost every single idea struck me as both blindingly obvious and often missed. And the single best part about this entire book… about 90% of it applies to any project or technical community. Yes, I don't care if you're working on an Open Source project, an internal project, or a commercial shrink-wrapped application. You can use almost any idea from this book and apply it immediately.

Since reading this book, I've used many of the concepts, principles, and his experiences to shape my own thoughts about what a project community can and should be. So when we put together the Vision and plan for web2project, I set out to take the best ideas from the book, combine them with other participants' ideas, and figure out how to apply them to everyone.

Overall, I give it a 10.

By the way, all of "Producing Open Source Software" is available under a Creative Commons license at

About Keith Casey

This should be something about myself. I've had suggestions that it should be "useful information" but I'm not sure about that.