In the course of working on the new book about my time working for WordPress.com, I’ve been reading various books on open source projects and how they’re managed. The most useful book by far has been Fogel’s Producing Open Source Software.  There’s plenty of good advice for all managers of software development no matter what philosophy is used.

Fogel does a fantastic job of taking the core challenges head on, from what culture and community are, how to grow them, dealing with conflict and the roles leaders have to play for healthy cultures to grow. Some of the book does focus on tools, which I didn’t need, but that let me read the entire book in a single enjoyable sitting.

A second edition is underway and you can contribute to the kickstarter project to make sure it happens. I did. The 2nd edition is slated to come out this fall.  The current edition is available online for free here to read right away while you wait for the update.

 

Choice quotes from the book include:

Try not to let humans do what machines could do instead. As a rule of thumb, automating a common task is worth at least 10 times the effort a developer would spend doing that task manually one time. For very frequent or very complex tasks, that ratio could easily go up to 20 or even higher.

On the faith in fancy projects and heroes:

The most well-known organizational models of getting things done—whether it’s building a house, producing a motion picture, or writing software—tend to concern the prediction of and commitment to specific outcomes, mitigating risk to the plan, and correcting surprises along the way. In such models, innovation is seen to happen at the moment of inspiration of the idea—and the remaining 99% of the effort is perspiration, to paraphrase Edison. Say it along with me: “Yeah, right.” This view looks at innovation as a very solitary sport; we want to talk about Steve Jobs as the guy behind the iPod, rather than the mix of good engineers and product marketing types who collaborated with Steve to find the right sweet-spot combination of features and fashion.

On the myths and realities of crowdsourcing:

Without descending into hand-waving generalizations like “the group is always smarter than the individual” (we’ve all met enough groups to know better), it must be acknowledged that there are certain activities at which groups excel. Massive peer review is one of them; generating large numbers of ideas quickly is another. The quality of the ideas depends on the quality of the thinking that went into them, of course, but you won’t know what kinds of thinkers are out there until you stimulate them with a challenging problem.

And on managing releases out the door:

Thus, the process of stabilizing a release is mostly about creating mechanisms for saying “no.” The trick for open source projects, in particular, is to come up with ways of saying “no” that won’t result in too many hurt feelings or disappointed developers, and also won’t prevent deserving changes from getting into the release.