Recently, I realized that despite talking about Karl Fogel's book – “Producing Open Source Software” – numerous times over the past year[1][2][3], I've never written a review of it. So without further ado, here we go.
I originally picked up my copy in mid-2007. It took me a couple months to get to it, but once I did, it rocked my professional world. To be clear, Karl Fogel is an early (founding?) member of the Subversion Version Control System.
Karl starts off talking about the beginning an Open Source project and the things – both community and technical – that are 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, Google Code, Launchpad, or Microsoft's CodePlex, you'll have version control, forums, some release management and bug tracking immediately. Honestly, getting the technical infrastructure setup is just plain simple.
The more important portion to me was the other “half” of the book where he discusses the team dynamics side of things.
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 is in his specifics. How are important decisions made? How do community members become team members? What roles and responsibilities does a team member have over a random community member?
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 keep things on topic are all covered. Does it all work? Nope, not all the time. But some of it definitely might work some of the time. Regardless, it's a good overview of tips and tactics interspersed with real world examples from the Subversion project.
Finally, there is 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 realistically, I guess they are the same. Doh.
This was highlighted for me last fall at ZendCon when one person asked a panel “Do you think it's appropriate for a project to ask their users to go vote in [technical] polls?” If a project's leadership isn't supposed to engage and occasionally direct their community towards goals complementary with the project, I'm not sure what the point is.
So overall, almost every single idea struck me as both blindly obvious, incredibly powerful, and almost always 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.
When I started reading this book, I was active in DCPHP, working with a startup, and on the verge of leaving dotProject. This book crystallized many of my concerns and thoughts about what a community and project could and should be, so I set out to take the best ideas from the book and apply them to each of the communities that I participate in. It's been one of my primary motivators in unconference organizing and web2project and I don't hesitate to recommend this one to anyone who needs to make their project successful.
Overall, I give it a 10.
By the way, all of “Producing Open Source Software” is available under a Creative Commons license at ProducingOSS.com.