I’ve been reading books and articles about open source software since at least June 1998 – the first time the famous phrase “The cathedral and the bazaar” (*) made an appearance in Symbian’s principal internal discussion database (which was, at the time, still called “Psion Software General”). However, I remain keen to keep on testing out my thinking and understanding of open source issues.
After all, there are many different angles to this subject. There’s potential huge upside to taking full advantage of the best principles of open source methods – but there’s also many risks from applying some of these ideas in a misguided manner.
For that reason, I continue to pick up books on open source software and think hard about what they say. Recently, I accepted the advice of several of my Symbian colleagues, and started reading “Producing open source software” by Karl Fogel.
I’m very pleased that I listened to that advice. In my view, this book is in a class of its own.
It has the great merit of being an intensely practical book. It’s clear from numerous examples in the book that the author has extensive real-world experience at the heart of development teams of open source projects that are both significant and successful – including CVS and Subversion.
Some of the chapters contain ideas that have been covered before – like the history of free and open source, advice on how to choose a licence, and aspects of the technical infrastucture of open source projects. However, other chapters delve into material that (to my knowledge) has been covered much less often:
- Social and political infrastructure of successful open source projects;
- “Money”: Working in open source projects in which companies are sponsoring parts of the work;
- “Money can’t buy you love” – excellent advice on how to avoid corporate sponsorship dampening the enthusiasm of volunteer contributors;
- Communications – including how to communicate with “difficult people”;
- Packaging, releasing, and daily development – including dealing with different kinds of codeline, and the special considerations that apply to integration and to making releases;
- Managing volunteers- including the typical roles that probably need to be filled in projects.
Several times while reading a chapter, I found myself thinking: “Yes, this is highly practical material – and interesting too. But I can see there’s still another 20+ pages in this chapter. What else is there to say about this subject?” But then as I turned over more pages, I thought, “Oh yes, this is something that really belongs here too – it’s what happens in real projects!“
The writing style was pleasant and clear throughout – with an engaging mix of actual examples (both good and bad) and a discussion of the broader lessons to be drawn from these examples.
My recommendation is that project teams should regard this book as a kind of “bible” – it’s something that should be regularly dipped into, and the many salient points shared and debated in group discussion. The lessons will make sense on several levels – some apply during early phases of projects, and others as the project becomes more complex.
(Many of the same principles apply in non-open source projects too, by the way! I felt lots of resonance with my own observations over the years about successful software projects inside the “community source” world of Symbian OS development.)
Perhaps the most sobering part of the book is contained in its introduction:
Most free projects fail…
… it’s impossible to put a precise number on the failure rate. But anecdotal evidence from over a decade in open source, some casting around on SourceForge.net, and a little Googling all point to the same conclusion: the rate is extremely high, probably on the order of 90–95%. The number climbs higher if you include surviving but dysfunctional projects: those which are producing running code, but which are not pleasant places to be, or are not making progress as quickly or as dependably as they could.
Happily, the introduction continues:
This book is about avoiding failure. It examines not only how to do things right, but how to do them wrong, so you can recognize and correct problems early…
If that whets your appetite, note that you can read the entire book online, by following the links above. Alternatively, check out the reviews on Amazon.com.
(*) Footnote: The June 1998 “Psion Software General” discussion contained a link that is, sadly, now dead. I’d like to belatedly thank Symbian lead Software Engineer Joe Branton for coming to my room, on several occasions, and encouraging me to pay more attention to the ideas in The Cathedral and the Bazaar.
dw2 
Leave a Reply