Book Review: The Success of Open Source

For the past few weeks I’ve been wrapped up reading Steven Weber’s
The Success of Open Source. Published in 2004, it is a look at what
the open source movement is and how it works, from the perspective of a
political scientist. This is no trite look at why people would choose to
give away the fruits of their labor. His analysis is serious and well
considered. He stresses several times that his goal is to ask questions
rather than answer them, but he does offer some observations about the
open source movement as a larger social movement and how it might spread
to other parts of the culture.

Weber starts out by explaining his goal for the book, to study the
political and economic foundations of open source communities and
processes. He makes two assertions, around which the rest of the book is

1. The open source phenomenon is an important “puzzle” for social
scientists who study cooperation.
2. OSS communities have been fundamentally impacted by the internet.

Early History

The second chapter covers the basic facts of the early history of open
source, well before it was called that. From the PACT compiler project
for IBM mainframes, through the failure of Multics, and the unintended
consequence of the AT&T consent decree that lead to the original
licensing terms for Unix, he covers some details that aren’t a part of
the usual story that includes DARPA, BSD, the fragmentation of the Unix
market, and FSF and the GNU project. The writing is engaging, and I
could recommend the book on this history section alone.

How Does OSS Work?

Chapter 3 tries to answer the question, “What is Open Source and How
Does It Work?”. It covers some essential software project
characteristics such as the division of labor between “analyst” and
“programmer” and how that historically lead to problems because the
designer of software was too far removed from the end-user.

The essence of software design, like the writing of poetry, is a
creative process. The role of technology and organization is to
liberate that creativity to the greatest extent possible and to
facilitate its translation into working code. Neither new technology
nor a “better” division of labor can replace the creative essence
that drives the project.

Weber builds on Brooke’s Law to say that success of a project isn’t
just about getting more people involved, but also about how they are
organized. He points out that open source is much more about the
process than the resulting product, which is an artifact of the
organization and creative energies of the participants. He identifies
four fundamental organization schemes that repeat in open source

1. A hierarchy, where patches flow up to a more or less central
maintainer, as with Linux.
2. The concentric circles used by the BSD project, in which
maintainers closer to the center have more rights and privileges, but
within a circle they are essentially equal.
3. The pumpkin holder or token-based system used by the developers
of Perl.
4. A democratic voting system, such as used to approve changes in

One assertion Weber makes relates to the different cultures that
evolve around BSD vs. GPL-licensed projects. His claim is that core
developers in BSD-licensed projects do not depend as much on submissions
from the end user as GPL projects do. His evidence for this is the
various BSD operating systems and Linux. I think his sample size is too
small, though. I’m not convinced that the license has much to do with
“dependence” on contributions. I think the attitude of the core
developers, and their willingness to accept patches, is more important.

Evolution of Open Source

Chapter four talks about the “maturation” of three major projects
(Linux, BSD, and Apache) as they evolved in the 1990’s, the “golden age”
of open source. He covers several pivotal events during that period and
how the community identities gelled as a result of passing through
critical times like the fracturing of BSD and other Unixes, flame wars
and other crises among the Linux maintainers, and the conflict caused by
the “ideological passion” of Richard Stallman and the FSF. This chapter
was an interesting retrospective and it really pulled together a
cohesive picture of what happened that brought us to where we are today.

Motivation and Organization

Chapter five examines the microfoundations of open source made up of
the motivations of individual contributors. For example, he says that
open source developers self-select as a way to boost their egos by using
acceptance of their code as a “signal” of its quality to developers who
are not necessarily skilled enough to recognize quality on their own.

It is clearly the best programmers who have the strongest incentive
to show others just how good they are. If you are mediocre, the last
thing you want is for people to see your source code.

Ego boosting is one of 6 motivating factors he discusses, and is not
necessarily the most important for most developers.

Chapter six looks at how individual developers come together to form
groups and focus their creative energies with constructive
contributions. He studies the social and economic pressures for and
against forking a project, and comes to an interesting conclusion: The
leader of a project needs the fellow contributors more than they need
him. When a fork is created, the new leader has to convince potential
followers that the new project will be better or more popular than the
old one. So while forking may give the leader more visibility, that
only works if he is successful at attracting followers, in which case he
is just as likely to be a successful contributor to the original

The Code That Changed The World

Weber begins his final chapter by comparing the impact of OSS to the
Japanese manufacturing innovations described in The Machine That
Changed the World : The Story of Lean Production
and re-emphasizing
the importance of process over product.

The Toyota “system” was not a car, and it was not uniquely Japanese.
… Open source is not a piece of software, and it is not unique to
a group of hackers.

This leads in to the rest of the conclusion, where he brings together
observations on intellectual property rights law, the limiting factors
for specialization and division of labor and how they impact
organizational structures, and the challenges of relating hierarchical
versus network organizations. He also offers some observations about how
open source techniques and attitudes can be applied directly in other
fields such as family practice medicine and genomics.


Weber covers a lot of material, and his writing is clear, for the most
part (especially for an academic :-). I enjoyed reading the first seven
chapters, but got a little bogged down in the chapter eight. I was
disappointed at his reluctance to draw more definite conclusions in a
few cases, but by remaining neutral he was able to focus on framing
several thought-provoking social and economic questions about the open
source movement.


We have an Exchange-like mail server at work, but it doesn’t support
iCal subscriptions. Since I use a Mac, and don’t have any interest in
Outlook, that makes calendar access a pain.

After some poking around, I discovered that the server stores the
calendar information in IMAP folders, with each event in a separate ICS
file attached to a fake message. So I put together a small script read
the IMAP messages and merge the ICS files into a single output file. By
writing the output file to a folder on the web server, it is easy to set
up a subscription in iCal.

The result only works one way, of course, though it should be possible
to push fake messages into the IMAP server. I have not tried that,
because I just use the server’s web interface for adding new events to
the calendar.

The script depends on the icalendar package from, and
the Python standard library packages for IMAP and email parsing.

I have posted the script to my server: mailbox2ics.