Forgot your password?
typodupeerror
Programming Books Media Book Reviews IT Technology

Managing Open Source Projects 94

Posted by timothy
from the no-whips-no-bullhorns dept.
Stephanie Black contributes this review of a book which might be nice to have around if someone suggests that Open Source is "not for business use." Managing Open Source Projects is one of a class of books that will probably expand hugely in the next few years.
Managing Open Source Projects
author Jan Sandred
pages 189
publisher John Wiley & Sons
rating 9
reviewer Stephanie Black
ISBN 0-471-40396-2
summary A HOWTO on putting the principles and advantages of Open Source programming to work.

First Impressions

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 applicable).

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(TM). 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 experience.

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"?

Highlights

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.

Imperfections

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 progress.

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!

Conclusion

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.


You can purchase this book at Fatbrain.

This discussion has been archived. No new comments can be posted.

Managing Open Source Projects

Comments Filter:
  • $18.50 (Score:1, Interesting)

    by 3ryon (415000) on Tuesday September 18, 2001 @10:55AM (#2314572)
    Check out Bookpool [bookpool.com] for 40% off cover price. They always have great prices. No, IANAS (I Am Not A Spokesperson).
  • by Genoaschild (452944) on Tuesday September 18, 2001 @11:03AM (#2314618) Homepage
    The only time Linux has ever crashed on me is when I'm accessing low-level parts of the hardware. I can run Linux for years as a server without problems. It makes an excellent server. Ten times better then win2k. More versatile. It is also cheaper and more compatible then other versions of Linux. The payoff is excellent.
  • by Taurine (15678) on Tuesday September 18, 2001 @12:10PM (#2315108)
    Its often said that the best way to break into an open source project is to find an application you like, and add to it a feature that you would find useful.

    The problem I have found with this is that few projects have any online design documents, to help someone new to the project find their way around. This is also frequently true in the commercial/closed source world of development, but in that setting you can always wander over to the lead developer's pod and ask him for some clues. Now I know you can email the maintainer, but you don't always feel comfortable taking up their time when you know they are very busy and doing this on their own time.

    Why are design docs, in particular things like class diagrams, interaction diagrams, flow charts, whatever, so rarely available? Is it because the projects aren't created from design documents in the first place, or is it more a lack of a sensible way to share designs in a digital form? Are there any decent free software reverse engineering tools to create 'how it is' design documents from the sources?

    <flamesuit>Is it a consequence of the kind of people heading up the individual project? I am aware that some of the most successful open source projects are run by experienced software engineers (apache being a classic example). But many of the smaller projects are run by teenagers who have recently learned to program. Is it simply that much open source software is produced by people who are not yet aware of the benefits and methods of design documentation?</flamesuit>
  • by dantes (89932) on Tuesday September 18, 2001 @12:37PM (#2315277)
    I think your missing the point of the book. This is not a propaganda piece intended to persuade corporate IT to use OSS. Rather, it is pointing out that the processes behind the development of open source software may be applied within traditionally closed source institutions.

    Case in point. I work for a software company as a consultant/field-engineer. Our product is very broad and offers an impressive API on which to build extensions. Many of our consultants have identified opportunities to build upon our software which don't necessarily fit within marketing's "product road-map", but address important customer needs/wants.

    Our solution has been to organize and implement an open source style development community within our organization. Consultants can suggest and develop utilities and extensions for our software which the core engineering team could not (or will not) tackle. The results thus far have been very positive, and we expect to release many advanced features to our customers, at low, or no cost.

    In addition, it gives our consultants an opportunity to grow their software development skills in ways that wouldn't otherwise be available to them. Most customers wouldn't attempt to develop the complex extensions that we are working on due to a lack of in-house skills and cost. As such, we do a lot of redundant work for our customers, which limits our growth as software engineers.

    In short, this book addresses exactly the type of problems we are facing right now, and I can't wait to give it a read.

"It ain't so much the things we don't know that get us in trouble. It's the things we know that ain't so." -- Artemus Ward aka Charles Farrar Brown

Working...