I’ve been following the progress of a continuous integration build manager called DamageControl for over two years now. DamageControl is a Ruby on Rails based framework for triggering builds of software, whenever there is a check-in to the source control system. Essentially it fulfils the same job as CruiseControl and Mozilla Tinderbox – detecting when a build has been broken by a bad check-in, but with an attractive web-front end and some nice configuration features. DamageControl interfaces very nicely to a variety of source control systems through the RSCM (Ruby Source Code Management) library.
I’ve ‘lurked’ on the DamageControl developers and user mailing lists long enough to get a feel for how the project is progessing. However, I’ve been disappointed that although DamageControl has gone through many version increments – I came in at DC 0.3, we’re currently around 0.6 there has never been anything approximating a stable release.
Now I know as much as the next open-source contributor how difficult it is to remain committed to a project, but lack of committment doesn’t seem to be the problem here. If DamageControl were a commercial offering, it condition would be diagnosed as ‘inability to ship’. DamageControl is perpetually undergoing, the next big refactoring, which it is promised will lead to a ‘stable version’. As any experienced developer knows, software is never ‘finished’ and it is nearly always beneficial to re-write or refactor. However, every project has to break out of this loop at some point, if only temporality, to stabilize the code and benefit user feedback and bug reports from a specific version.
However today, after checking back at the DC site after six months I have given up hope, DamageControl has the following message on its site:
DAMAGECONTROL HAS HIBERNATED
It’s currently not under active development.
It’s not completely abandoned – development may pick up again once I …. get more time to work on it.
The first lesson is that not everything created atop Ruby on Rails will be rip-roaring success. The second lesson I take from this, for my own projects, is that there is enormous value in creating something that works and that is incrementally useful, even if it is merely the Simplest Thing That Could Possibly Work. The third lesson is that providing something that is easy to install and start actually using, hugely increases the probability of a project being successful; having to extract specific revisions from Subversion, and run them against very stringent Ruby, Rails and other package versions is a severe hindrance. Creating a community of motivated users around the product is fundamental to success. Rather this, than a sense of unrequited expectation amongst a group of potential users who find it difficult to get involved because the code train is never moving slowly enough to leap aboard.