decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Book Review of Karl Fogel's "Producing Open Source Software"
Thursday, January 05 2006 @ 01:08 AM EST

Steve McInerney has read another book he feels enthusiastic enough about to want to share with you. It's "Producing Open Source Software," by Karl Fogel.

By the way, if you're a Groklaw member and you find a book you think others would enjoy knowing about, feel free to contact me about doing a review. We have a nice system for making sure we know about articles and papers with News Picks, but it's nice to know about books that might be of interest to everyone.


Karl Fogel's “Producing Open Source Software”
~ reviewed by Steve McInerney

Producing Open Source Software
How to Run a Successful Free Software Project
By Karl Fogel
First Edition October 2005 ISBN: 0-596-00759-0

I chose to purchase this book as a bit of a wild card in my most recent technical-book-buying splurge. Additionally, as someone with three active GPL'd projects and bits 'n' pieces in others, I figured it might have something useful to say. Something useful it certainly does!

The subtitle pretty much sums up the target of the book, which is to provide advice, and lots of it, on the running of, and participating in, Open Source Projects.

One could expect that the book would focus on technical issues: Choose one of these mail list servers, this tracking system, that Version Control system and so on. And these are areas that are briefly touched upon, but they are not the core of the book. These technical areas only take up only a single chapter: Chapter 3, Technical Infrastructure.

The majority of the book is about dealing with people. One could even call it a guide to Open Source Net-etiquette. What helps draw and retain the reader into such a potentially tedious topic is the highly judicious use of pointed examples that Karl intersperses throughout.

This is where the book shines strongest in my humble opinion.

These are real world examples that have really happened and demonstrate how someone solved a particularly difficult problem. That sort of experience and illumination is pure gold!

Groklaw regulars may feel some familiarity in the situation described in this quote from Chapter 6:

“The really difficult cases are people who are not overtly rude, but who manipulate or abuse the project's processes in a way that ends up costing other people time and energy, yet do not bring any benefit to the project. Such people often look for wedge points in the project's procedures, to give themselves more influence than they might otherwise have. This is much more insidious than mere rudeness, because neither the behavior nor the damage it causes is apparent to casual observers.”

The other major positive about this book is that, despite the title and subtitle, there is a lot in this book that is of huge benefit to anyone participating in any form in an Open Source project, not just running one. It was only with the benefit of reflecting back on the book while writing this review that I additionally realised just what a great introduction and explanation to and of Open Source culture and community it contained.

Unfortunately I did feel that the book somewhat missed one goal. The book is mainly geared towards the larger projects, the Subversion's, the KDE's, the Geeklog's and so on. It's not really aimed, directly, at the smaller one-person-shop projects like two of my three projects. This lack was my second biggest disappointment. I was left with the impression that the book was aimed more at companies which are considering Open Sourcing a product of theirs than J. Random Hacker scratching that software writing itch.

This quote from early in Chapter 2:

“Free software distribution is a twofold task. The software needs to acquire users, and to acquire developers.”
That is a sample of this probably unintended bias. It assumes motivation(s) that align with one or both of those goals.

Incidentally and aside, the biggest disappointment I suffered was the lack of a nice animal pencil sketch on the front cover. The much loved traditional O'Reilly book cover. Shame O'Reilly. Shame on you. ;-)

I've mentioned one type of people problem a project might experience. There are plenty of others, even when applied to a less traditional Open Source project like Groklaw. It was fascinating seeing how much of Karl's advice we/Groklaw already do anyway, subconsciously or not. I'll save the more detailed observations for private emails with Pamela though. :-)

“Producing Open Source Software” is available online at under a Creative Commons license. But rather than download and read the book that way, I'd strongly suggest buying a copy instead. At around 1 cm thick, it fits nicely into that awkward gap on your bookshelf left by all those one inch thick monster references we all seem to have and need so many of.

Karl has written a superb book and I doubt my communication skills to gush effusively enough about it. Read it!

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )