Personally, the AudioMan project is a way for a software process geek like myself to test the means rather than the end. It would be nice if AudioMan was useful to people -- and the features it has and will have are mostly useful to me -- but that is not my most important goal, which is to understand agile processes and quality.

So far AudioMan has kind of been a mish-mash of stuff, which was a result of it being programming driven rather than process driven. Some of it was good and some of it was bad. This is OK in the open source world, where you just brute force a good product out the door at your own pace given enough eyeballs. But in any kind of business environment, it would be too inefficient.

Instead I'm going to focus on working the process to my advantage and try to establish it transparently on this blog so everyone can learn from the mistakes I make. While I'm a fan of the ideas of extreme programming, it doesn't work well on open source projects. I can get into the reasons why on another post, but it mostly has to do with communication overhead and the lack of a clearly sustainable pace. Extreme programming doesn't have these two issues because everyone is in the same room with no cubicle walls and they work 40 hours a week.

Because everyone working on an open source project isn't in the same room, all of the methods of communication are written. Some of it takes the form of email, web site news, newsgroups which is dynamic in the sense that you can't just pick it up and understand the project. The topics change as people run into new problems. You have to know the project to understand the context.

Then there are the documents: a functional specification, technical specification, help files and such. These documents, if written well, can dramatically reduce traffic on the dynamic channels, freeing developers to work on more important tasks instead of support issues.

A lot of open source projects do not have these documents and unfortunately they are the ones that developers like writing the least, mostly because they are a pain to update as the software changes. This is just a reality of making software though, because if you want a lot of users they will need help using and understanding the software. You don't want to give this help to them personally because you'd rather be using the little spare time you have to hack on new features.

Which brings me to a role that very few open source projects distinguish from the lead developer: the project manager. This guy makes sure everything is on track, sees inefficiencies in the process and fixes them. Collects metrics, sees a need for additional communication with users and fills it. He maybe doesn't hack much at all but frees the technical people up to do their best work.

I've seen this role done by the same person as the lead developer role on a lot of projects, and I can see that making open source projects frustratingly hard to keep up -- there's too much management for this one person to handle and he can't get any work done. The one person gets bogged down in process and doesn't have the motivation to continue the project. Since open source projects are done with free time, having motivation is critical. A project manager can enable developers to work with less friction, and work on stuff that motivates them without having to deal with administrative headaches.

So to that end I'm going to establish a specific process for the AudioMan project. The goal of the process is to be sufficiently heavy on the project management end to collect data, interpret it and create documents. It also has to be light on the development side, enabling developers to do their best work while staying inside the process that enables management to enable their light process.

The next post will go into some thoughts on this process, and the tools that will enable it.