Its Tool Time

Add open-source methodologies to your tool set, and empower your development teams.

Whether youre part of the opensource movement or not, youd be wise to check out some of its development methods.

Simply put, the open-source movement has proven beyond a shadow of a doubt that you can develop great software with dozens of developers using collaborative work techniques. From the world-beating by programs like Apache, Linux and Perl to less well-known, but still important software like OpenSSH (Secure Shell for rlogin, telnet and ftp connections) and Bugzilla (bug tracking), open source is driving much of tomorrows software.

Not a Miracle Worker Certainly, much of open sources success lies in its underlying philosophy. For more on that, we point you to the online seminal works of Eric S. Raymond ( For those who prefer print, check out The Cathedral & the Bazaar; Brian Behlendorfs Open Source as a Business Strategy (; and OReilly & Associates compilation of open-source documents, Open Sources: Voices from the Open Source Revolution.

The mechanics behind open source can be useful, even if youd rather die than publish software under the Free Software Foundations GNU Public License. Traditionally, writing software usually involved a few programmer geniuses or massive teams driven by unforgiving deadlines—which involved writing x number of lines of code per day.

Open sources methodology pointed out a different way. Most people think that hundreds of developers work on the typical open-source program. Not really. Sure, thousands of people fiddle with open source. But it usually takes no more than 20 developers to do the vast bulk of the actual development work. Additional programmers usually contribute a few lines of code and are invaluable for quality assurance and bug finding. But without a single leader (say, Linus Torvalds) or a core team such as the Perl Porters, an open-source project will flounder just like any other.

There are key differences between open-source projects and proprietary development methods. Many, if not most, proprietary projects rely on nontechnical managers to run software development. In open source, where hierarchies tend to be flat, and peer-to-peer, the top people who lead the charge usually have more technical expertise than management skills.

Regardless of whos in charge, open-source development methods cant free you from management foibles. The lessons of Fred Brooks software project management classic, The Mythical Man Month, remain as true as ever. For instance, throwing more programmers at a late project will just make it later. As the unofficial delays in the release of Linux 2.4 showed, thats still true—with or without open source.