Before anyone accuses me of turning in my software engineering iron ring, allow me to explain the goal of the Durham project I'm getting started on.

The goal will not be to try to impose typical software engineering techniques, extreme programming practises or even best practises from industry experts on an open source project.

After watching a few successful open source projects and seeing what kinds of things work for them it will be nice to try a project of my own and see if I can capitalize on the same techniques. It was instructive seeing the AudioMan project's lack of momentum as an open source project, noted in its post-mortem.

A secondary goal of Durham will be to examine how open source techniques work, what level of quality open source software delivers (and how) and investigate if any open source development techniques may be used in closed source development.

Open source software will not only be a major business competitor to closed source software in the future, it will also be a major (and free) source of bleeding edge development techniques and idea sharing among colleagues.

It would be a big mistake to dismiss successful open source projects as a fluke or an anomaly -- they could one day cut into programmer and software engineers' livelihoods. If we pay attention to why open source succeeds we can learn, adjust and even benefit greatly from it as software professionals.

I already use several open source projects for my work and I don't know where I'd be without them.