Managing Open Source Projects

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.

OSS _is_ not for business use!

[Anonymous Coward]

Not as long the cost-benefit balance is so incredibly bad compared to closed source commercial products, like for instance this analyis shows:

Let's have a close look at the costs involved when running a Linux system.

An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.

Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.

The upcoming 'solution' to this, EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.

Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".

The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.

I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.

Mozilla ?

[tmark]

I find it amazing to think that a book about the supposed virtues of OSS - especially in a business setting - should bring up the browser war issue. As far as I'm concerned, the open-sourcing of Netscape and the Mozilla project points to nearly everything that can be wrong with an OSS approach - look how long it has taken to bring something to the desktop that is remotely useable, for instance. One might have expected that if OSS were all it is sometimes said to be we might have had useable product a year or more ago. Now, somehow I expect that this book touches little on Mozilla's considerable problems (while presumably talking up the failures of non-OSS Netscape), so I have to wonder how convincing an informed reader will find (at least this portion) of the book's argument ?

Sure, there are OSS successes, but I can't believe the author makes a definitive argument for OSS in business as a core part of a company's business plan - there are just too few examples of real solid successes and fewer still of money-making, solvent OSS-based companies.

Non-coder involvement - a necessity?

[MikeCamel]

I'll certainly be buying a copy, as this is a subject that I find very interesting. There are a whole bunch of people out there with skills in running projects - whether they are money-generating or not - who the community could be using better. That's not to blame the community - these people have to put themselves forward, and show how they can add value to a project. They also need to understand how the community, and the community's philosophy, works. I've been flamed before for suggesting that non-coders should be allowed to be involved in OSS projects, with the suggestion that if you're not good enough to code, you're not good enough to be involved. I don't think that this is right - and there are people out there (including me) who have coded, but realise that their skills lie elsewhere, and that the way they can best further the projects that they care about is to offer the skills that they do have. It's not as if we tell the documentation teams that they shouldn't be involved!

So, how do we go about doing this? There are places where projects hang out - sourceforge, for instance - but I'm not sure that they are a good place to look for non-coders. I'd like to see projects who realise that they could use organisational help (wouldn't the code lead like to spend more time coding? Of course they would, in most cases!) looking for help - but I don't know where they should look. Functionality priorisation, tester recruitment, visibility improvement, strategic focus, project communications - all things that at least some projects could probably use.

So - how do we move forward? Maybe people like me need to make it clear how our skills may be able to help important projects, and hope that the people running them can make use of us. Maybe we need our own forum (hmm - maybe not!). I'd love to hear other suggestions.

Mozilla is a great OSS project

[pubjames]

Often Mozilla is used as an example of a failed OSS project, but I don't think it is at all, both from a business and a pure 'Open Source' perspective.

From a business perspective companies such as AOL are just beginning to exploit code generated by the Mozilla project. In Spain, AOL has just launched a product called 'AOL avant', a iMac-style box allowing web browsing and email for about $15 a month, all inclusive. They are aiming to get quarter of a million of these boxes into homes. The boxes run Linux, along with a browser that I assume is based on Mozilla. When people say that Linux isn't suitable for non-techies, then this is a great example, because AOL Avant has been designed to be used by your grandma. And quarter of a million users is a lot.

It is true that the project is taking a long time, but then complex software development does take a long time. Microsoft knows this - they spend years and years refining sub-standard products until they are sweet - that's part of the reason they are in the position they are today - they don't give up. Nor should the OSS community give up on Mozilla. It is a strategicly extremely important project in the good fight against the beast from Redmond, and the team has done a great job so far.

I use it every day and it is really stable now and packed with features. For instance, it can render XML directly from XSL style sheets, something that IE 6 cannot do (or at least I cannot get it to work). Keep up the good work Mozilla crew, your work is great and your project will turn into a great success story for the OSS community!

Running Open Source for Fun or Profit....

[qbalus]

I've had the opportuntity to work with companies that are either using open source software as a backbone for their services and for their products.

An area that I've seen in which all have many challenges with, is not in the development of their respective products and services, but in managing the environments, tools and source code.

This is not unique to open source, but this is an area where open source could really contribute. Fundamentally the tools used by the software industry to manage and publish software are 20-30 years old and have not undergone much in the way of evolution. The tools and practices used today to manage the development of software, in most cases gets in the way of productivity and quality, because they are not DESIGNED to solve todays problems, they are adapted to solve today SYMPTOMS.

If we look at all of the mainstream change control systems, they Generally don't solve todays business needs, resulting in customizations by the development teams, that generally miss the mark. They may support some engineering team needs, or some developer needs... But ask most team leads, project managers, and engineering managers and they will tell you that this is an area that causes alot of pain.

CVS based on top of RCS

Teamware based on top of SCCS

Perforce based on top RCS

Continuus based on top of RCS

ClearCase based on Apollo DSEE

Bitkeeper based on SCCS

SCCS was developed... what around 1975, RCS early 80's, ClearCase/DSEE mid 80's

Fundamentally these products are not DESIGNED to support all the different variants and product lifecycles to repsond to todays business opportunties.

Individuals and Companies have made great attempts at creating wrappers, customizations, books, and articles to attack the problems that the deisign and implementation of these solutions failed to deliver. But this is only addressing the symptoms of the design and implementation of these tools

A new look at the problem is needed, if anyone expects to see any significant improvement in the ability to deliver the right solution in the right timeframe to the right customer.

I'm not sure, based only on my exepriences up-to-this-date, that open source methodologies can make any SIGNIFICANT improvement over todays current business methodologies... I don't see any accountability in open source metholodgies. Not being able to see accountability in the methodologies, leads me to be concerned about how open source addresss businesses, support the consumers need to effectively resolve issues and concerns.

Regards,
Kramer