oreilly.comSafari Books Online.Conferences.


What Corporate Projects Should Learn from Open Source
Pages: 1, 2, 3, 4, 5

A good example of an open source team sticking to its rules happened recently (at the time of this writing) in the Firefox project. Several serious security holes were discovered in version 1.5, which had only been out for a little over a month. Security holes can be embarrassing and potentially very damaging to a popular browser, and there was enormous pressure on the team to fix them quickly. It certainly must have been tempting to try to slap together "quick" patches to seal up these problems. Yet they carefully followed their review requirements. Each defect was entered into Bugzilla, reproduced, repaired, regressed, and verified, all in a way that is completely transparent. What they did not do was apply a hotfix directly which had not been verified and reviewed--something that corporate teams do all the time. The Firefox team released the new version only after all of the defects went through their process. Maybe this is why Firefox is one of the most widely used and depended-upon pieces of software available--because it has a reputation for good security and high quality.

One important lesson corporate teams can learn from this is that the teams themselves need to be involved in setting the goals and rules around which they will work. In a company that does that, asking the team to deviate from the most efficient work processes is the same as asking them to throw away their own principles and ideas. This often serves as an effective balance against the urge to acquiesce to time pressure.

So Is There Anything Open Source Projects Can Learn from Corporate Projects?

There is a lot that corporate projects can learn from their open source counterparts. But is there anything that open source project teams can learn from the way corporate projects are structured and run?

Certainly. Plenty of successful software is built by corporate teams, and some of that software is even good! That's actually an important distinction: successful software is not necessarily good software, and good software is not always successful. This seems contradictory, but it's actually pretty easy to understand.

One important shortcoming of open source projects is that oftentimes they are just done on a programmer's whim. On the other hand, the problem with many corporate projects is that they're just done on a vice president's whim. The best projects--in both worlds--are the ones that actually fulfill real needs of real users, and aren't just someone's pet project. In the open source world, this happens most often when the programmers' needs coincide with those of many other users. Apache, Firefox, Linux, Gnome, GnuCash, GIMP--these are all projects that their programmers needed, but they are also products that many non-programmers found useful. When the needs of the programmers overlap the needs of other users, it works out very well for everyone.

Unfortunately, there are few open source requirements gathering efforts. There are no open source demographic research departments or marketing teams. The fact that corporations have to go to investors or shareholders to explain how they are doing requires that they justify their projects in terms of actual user appeal. In other words, successful corporate projects must fill real needs in order to get funding. If a user has a need, he will always choose the poorly engineered, difficult-to-use, low-quality product that actually fills the need over the beautifully engineered, highly usable, stable product that doesn't. But software teams don't have to make the choice between software that's well-engineered and software that's useful. By taking the best practices from both corporate and open source worlds, it should be possible to build products that achieve both.

Andrew Stellman comes from a programming background, and has managed teams of requirements analysts, designers, and developers. He and Jennifer Greene formed Stellman & Greene Consulting in 2003, with a focus on project management, software development, management consulting, and software process improvement.

Jennifer Greene has spent the past 15 years or so building software for many different kinds of companies. She's built software test teams and helped lots of companies diagnose and deal with habitual process problems so that they could build better software. Jennifer founded Stellman & Greene Consulting with Andrew Stellman in 2003. For more information about Jennifer, Andrew Stellman, and their books, visit

Return to

Sponsored by: