Even though the idea behind Open Source software has been around since before the Internet or even the ARPANET, only in recent years has it received significant attention from the business community. Open Source was riding high just a few years ago, but is less in favor now that the Internet bubble has burst. Questions about whether Open Source software is a viable business model will almost certainly continue for years to come. In the mean time, managers will want to be informed on how or whether Open Source can work in their organizations. Managing Open Source Projects aims to provide this information.
The book begins with some background, covering a history of the Internet and Open Source in general. Most of this is pretty good, but I think the author misses the mark on several key points. This is important information for an Open Source manager to understand, so my recommendation for a prospective reader who needs this background would be to read Hafner and Lyon's Where Wizards Stay Up Late and Raymond's The Cathedral and the Bazaar directly, rather than count on the summary presented here.
The second chapter is, in my opinion, the most intriguing. The author discusses the large scale projects and the Open Source phenomena, and relates it to traditional software engineering methodology. He raises some very interesting questions, such as how we can reconcile that a large Open Source team can efficiently fulfill Linus Torvalds' observation that, "Given enough eyeballs, all bugs are shallow," with Fred Brooks' maxim that, "Adding more men then lengthens, not shortens, the schedule." The problem is that while these, and other interesting questions are raised, Sandred doesn't answer them. In fact, he's awfully short on answers, direct suggestions, or even criteria by which one might make a decision.
The book goes on to cover topics such as Network Organizations, customers as partners, and the dynamics of a virtual software team. In my experience, most of these issues are not Open Source specific. Many software projects these days have geographically distributed programming teams, and many of the most talented professional software engineers already choose their current project based on their interest in it rather than on compensation or acquiescence to any management hierarchy. Sandred then goes on to spend a considerable amount of time covering Open Source packages, specifically in the areas of groupware, knowledge base systems, version handling, etc.. These pieces of software are important for any software engineering team, but despite Open Source packages being covered here, I believe that the choice of which package a team ought to use is tangental to the management of that team, so I don't understand its relevance here.
The book concludes with some anecdotes about real-life Open Source projects, including information about Netscape's Mozilla project and discussing the popularity of Open Source solutions in the third world. There are great lessons to be learned from the Mozilla project, but Sandred gives them a very superficial treatment, and I'm not sure what the other anecdotes have to do with managing Open Source projects at all.
The book is very repetitive. We hear about network organizations several times. We hear about the importance of groupware, but so what? What does this really have to do with managing an Open Source rather than any other kind of project? Some intriguing ideas are touched on but not explored. Finally, I think Sandred really gets some of the few on-topic issues he does raise quite wrong. Honestly, it fills me with a bit of dread to think that an IT manager with no Open Source experience may turn to this book to learn about this topic. I firmly believe that they'd be better off not reading this book. I cannot recommend it.
While covering an interesting topic, Sandred's book is repetitive and rarely on point. The few times he does raise issues that might be of a concern to managers of Open Source project he either fails to consider interesting aspects in depth, or he covers them in the same manner that they would warrant in a book on managing a geographically distributed software engineering team. If one wants to develop an understanding of the Open Source phenomenon, Eric Raymond's The Cathedral and the Bazaar is a better choice.
Click here to return to the index of reviews.