I've been meaning to write about this, I just haven't had time lately. If you're a software process geek like myself, you've probably looked at open source software and wondered how the hell does that work? how do they get a quality product from this?. My interest in open source software to a large degree is the answer to this question because I believe it will usher in new ways to quickly develop effective software.

If you've read The Cathedral and the Bazaar you'll know all about "given enough eyeballs, all bugs are shallow." This is an important distinction of open source software: users at an early stage. It's a lot like having the customer onsite with Extreme Programming (XP) except with a popular and useful tool (like, say, Mozilla or the Linux kernel) you can get many many users testing very early.

These users find bugs, usability problems, missing features early. Very early. So the risk of implementing something bad goes down. If you do, your users politely (sometimes) backlash. The impact was minimal. Implicit risk management is a distinct advantage of open source projects.

Closed source shops on the other hand develop software on their own. It's tested by beta testers and quality assurance personel, but not at the volume of open source software. Neither is the testing as early as open source: once you've released beta you've pretty much feature committed, you're in no place to be adding new features even if you get great feedback from your beta testers. You just want to fix bugs. What good is customer feedback this late?

That's where XP "adopted" open source to get feedback as early as possible. This minimizes the risk of going down the wrong path, saves time and makes the project more agile (changeable).

The difference between XP and open source is the focus on quality. XP tries to instill high quality all of the time, which leads to a high respect for quality throughout the project lifecycle (see Broken Window theory). With XP, you should be able to take the contents of the source code repository (CVS) and use it at any time with the assurance that it will work properly. Unit testing for regressions has a big hand in making this possible.

Open source projects on the other hand want to attract contributors. To do this, most open source projects sacrifice quality at the beginning of an iteration in order to lower the barrier of contribution. Developers don't have to worry about testing their code, they just hack on it.

To a developer this can be a very attractive prospect -- if you write a feature that is really cool, you can get it in an open source project with all of the fun and none of the maintenance or testing. Open source project manangers often encourage this behaviour in order to accrue a greater number of new features, which in a snowball effect will attract more users and developers.

Then later on in the iteration the project stops accepting new features and stabilizes. This stabilization stage can take a while as bugs are discovered by users, debugged and fixed. Meanwhile a new development stream might be going on in parallel, introducing new features into the product while the stream before it stabilizes. This is what the Linux kernel does, except there is one development stream (2.5, soon to be 2.7) and at least 3 stable ones (2.6, 2.4 and 2.0).

In the software engineering world, we would call this the Build-It Fix-It (BIFI) methodology. It only works in open source because of the number of users that open source projects have, a few of which are developers with the inclination to create new features or even look at the open source. The rest could care less about the source code. Without these users BIFI falls flat on its face -- you would need far too many quality personnel in a closed source shop to sustain a methodology like that, which probably explains the poor quality and high failure rate of closed source BIFI projects.

So in the closed source world we have to deal with a lack of users. We compensate by carefully designing the product up front and hiring QA staff to pound on the product with scenarios (sometimes organized, sometimes not). Once you design the product like that though, you sacrifice agility for quality because everything is carefully planned. Deviating from the plan is possible but extremely painful, especially to planned schedules that managers are depending on in order to make business decisions. This in turn creates an atmosphere were no one wants to deviate from the plan, and agility problems.

Open source stays agile with little to no up front design because the users keep the quality in check in the long run. The developers are also more conscious about the quality of their code, since it can be read and critiqued by many people. Developers in these situations don't want to come off as stupid, so they put extra effort into it. They take pride in it because that is the context under which they are contributing in the first place: it's an ego thing.

So the features go in with no explicit quality barrier but even so they have a higher level of quality because of the ego factor: developers want to look smart so they write good code. This makes the stabilization period a little smoother than in closed source shops where a common policy of code ownership means that the code experiences little to no auditing, even informal.

Having said all of that, it brings me to AudioMan, my little pet project. First of all, AudioMan is not a typical open source project. The only reason that AudioMan is licensed under the GPL is so that I can talk about the code on this blog and in tools (like jcoverage, which shows code) without having to worry about people stealing it outright. Also, since this an academic exercise I thought it would be beneficial to license it under the viral GPL instead of the more "free" BSD-type licenses, so that closed source projects couldn't use the source code.

AudioMan for me then becomes a project to test software processes and tools. Once you start introducing processes or tools to an open source project, the barrier of entry increases dramatically. People don't want to contribute because they don't want to write unit or acceptance tests. They aren't concerned about software quality when they are just adding new features, like at the beginning of an iteration of an open source project. In that sense, AudioMan is not an open source project. I'm not trying to attract contributors by lowering the standards of contribution.

AudioMan is managed more like a closed-source project, in the XP-inspired style of "always green", unit and acceptance tests always passing. You can't do effective XP in an open source distributed project -- you need people in the same room to lower the communication overhead and facilitate quick decisions for agility -- so I borrowed only a few of the practises.

I'm not in a hurry to release AudioMan, so the process will often to precedence over the prooduct. This is not always true in the real world, where the process is sometimes sacrificed to get the product out the door in the short term. This is a learning experience for me, so exploring the process and tools are more important than the end result. However, I have to keep the real world realities in mind as I work.

At the same time, AudioMan will give me a good project management foundation to develop closed source projects in the future, as long as I'm aware of the differences in process style and why they exist. Developing and managing AudioMan will help me recognize these situations.