Managing Open Source Projects
author Jan Sandred
publisher John Wiley & Sons
reviewer Stephanie Black
summary A HOWTO on putting the principles and advantages of Open Source
programming to work.
There is a word for this book: SWEEEET!
It’s short, too, but before you grumble about paying nearly 30 bucks
for something that’s less than 200 pages, you might want to look at the
concept of quality. It’s worth every blessed dime, plus taxes (if
Managing Open Source Projects opens with a history of the movement, thus
providing background information and context to prospective or actual
managers of Open Source projects. In this sense alone, Sandred has set
himself apart from numerous other authors on the subject, providing an
overview of a movement which has been over 30 years in the making, and
whose restructuring of the “old-economy” is just beginning.
The development of the browser wars is dealt with in this history, a
subject not everyone is familiar with. What it amounts to is a lesson in
‘instant karma’ that Netscape Inc. learned after doing a lot of damage
to the Mosaic browser, (“mozilla” comes from “Mosaic killer”), and
subsequently having the same done unto them by the Redmond Contingent™.
Sandred sort of implies that this lesson had more than a cursory role in
the 1998 opening of the Mozilla source code, which staggered the
industry all round. Obviously, Netscape learned several somethings from
The author moves on to discuss the relevance of open source to business.
(You knew *that* was coming, didn’t you?). Sandred raises the common
assumption of business known as Brooks’ Law (‘the performance of
programming teams does not scale so as to increase the productivity of
the team’), and then uses the history of Linux development to illustrate
the inadequacy of this model in describing the open source development
process. In sum, Sandred asserts that the differentiating factor is what
he calls the “political attitude” of the open source model, which breeds
a different leadership style. The “administrative overhead” required by
each member of a development team may increase with each new developer,
but without the geographic restrictions posed by a code farm, there is a
wider base of “administrators” to choose from. (Now you know what to
tell your boss.).
Chapters 8-10 cover a variety of tools useful (and commonly used) in
building open source works, and methodologies used to set up the project
(including the team). You’ve heard of Sourceforge, right? CVS? Or maybe
“The Slashdot Effect”?
There are some portions of Managing Open Source Projects that are
guaranteed “feel good” items which remind any open source developer of
why we do what we do.
In his discussion of open source philosophy, Sandred points out that
the viability of the open source model is not restricted to software:
“With computers, perfect copies of a digital work can easily be made,
modified, and distributed by others, with no loss to the original work.
Individuals interact and share informa- tion,and then react and build
upon it; this is not only natural, it is also the only way for
individuals to succeed in a commu- nity. In essence, the idea of open
source is basic to the natural propagation of digital information among
humans in a society. This is why the traditional notion of copyright
does not really make sense on the Internet.” (p. 52)
He points out that the United Nations has adopted an open source
approach to distributed assets, including (especially) information. The
link between democracy and freedom of information is clear, and iterated
not only by Sandred, but by UN Secretary-General Kofi Annan, and Dr. Gro
Harlem Brundtland, Secretary-General of the World Health Organization.
It’s not “just” a software development model anymore.
There are some small issues this writer has to take with Mr. Sandred’s
pronouncements, among them the following:
“All software cannot be developed open source. Open source software
tends to concentrate on infrastructural design and back-end software.
Open source benefits from incremental de- sign, which means back-end
systems. End-user applications are hard to write. These applications
deal with graphical user interfaces, which are very complex to write,
almost always customized, and comprise other skills like graphical
inter- face design.” (p.160)
This writer would, upon reflection, argue with pretty much everything
in this paragraph, save for the self-evident last statement. Both the
GNOME and KDE projects are about providing desktop applications, and the
managers to go with them. Most window managers provide applications to
go with their “suites”. There are productivity software suites in
Ah, well, it’s one bad moment of two in the entire book.
Mr. Sandred makes an unwitting gaffe in his discussion of “Five Open
Source Commandments” in Chapter 12: the last of these reads ‘Join a
project rather than starting your own.’ While joining another project is
helpful, even useful, it does not replace the “developer’s personal
itch” that Sandred quotes from Eric Raymond’s 19 lessons (Cathedral and
the Bazaar, O’Reilly, 1999), in Chapter 2. Do both!
Don’t just sit there – go get the book, even if you’re not currently
involved in, or planning on, managing an open source project. The
information is timely, the pace is lively, and Sandred has provided a
wealth of insight into the open source movement’s past, present and
future. While some of his work has perceptual errors, these are few. The
rest of it is pure gold.
Please log in or register to post a reply.