Bagel Belly Blog

CVS archives

It seems that one of the UK's funding agencies is going to get some pretty good basic rules for software development projects soon, under the guise of an Open Source policy. I don't want to be too specific since it's still being circulated internally for comment, but one thing caught my eye.

In the draft, as well as insisting that source control systems must be used for software development, it explicitly states that archives of the source control repositories should be a deliverable along with the more traditional bundle of sources and documentation.

This isn't the first time I've seen this as a requirement - three years ago, we developed a series of internet-based games for yet another dot.com startup, and at the end of development they unexpectedly demanded a copy of our CVS archive along with the defined deliverables. We refused. The main reason was that we felt we'd have to clean up much of the archive to make it more "commercially acceptable".

I have no problem with "release early, release often", or with open development of projects within a community. I do not, however, believe that private development projects should provide CVS archives as a deliverable. How we get to the end product in a closed development environment should be of no concern to the customer, provided we meet all requirements along the way.

Why do I think this? Several reasons:

• Not everyone understands the need for a developer to work through the night when the coding bug bites. When you're on a roll, it sometimes makes more sense to just keep truckin', but commits at 2, 3, 4, or 5 in the morning do not necessarily look good when taken out of context.
• Secondly, despite the best intentions, rules, and regulations, commit messages can occasionally be inflammatory or unsuitable for public consumption.
• A third reason is "proof of concept" or trying something to see if it works - this sort of experiment can lead to some hideous ugly code that you wouldn't want to be seen as a commercial deliverable, but that are perfectly acceptable in a closed development environment.

So what is the big difference between a closed development environment and an open development community, such as that of the various Apache projects? Well, I think it's one of perception.

A "commercial" product (i.e., coming from a private company) is expected to meet and be judged by a certain set of criteria: every 'i' must be dotted, every 't' should be crossed, and it should have a gloss and a spin on it that will portray the company positively. We make mistakes, but we make them in private. The final deliverable is expected to look good, and be polished.

"Open Source" solutions have long had a reputation of being "sub-standard", or "developed by students in their free time". We all know that the reputation is unfounded, and that in fact Open Source solutions are often higher quality and developed by some of the best professionals in a given field. But, the perception and criteria by which Open Source is judged is still different: people evaluating it expect to find those unsightly blemishes, late night coding sessions, rude commit messages, and curious proofs of concept. It's accepted, and even welcomed. Heck, there's even counters for swear words in that poster child of the Open Source world, the linux kernel.

This, perhaps, explains the culture of "abandonware" - commercial companies dumping code in places like Sourceforge at the end of development, when most of the blemishes have been removed. By dumping final releases onto Sourceforge they get rid of all those embarrassing commit messages and the evidence of late-night hacking. They still get to say "look, we went Open Source", even if there's no community around it. This is also perhaps why even successful Open Source communities (such as Apache Cocoon) still see discrete chunks of functionality donated en masse, rather than being developed from day one within a public context.

A better model would be to try to do all development in a community-centric way - but really, this is just another way of saying we have to change the rules of business to make these methods and ways of working more acceptable. Do we criticise the artist who gets drunk and then creates a masterpiece at 4am? Do we criticise the journalistic hack who submits several sub-standard pieces to the editor before finally hitting gold? I guess I'm asking for programmers to be given the leeway we give creative types, rather than considering them a nine-to-five commodity. In industry, it's unlikely that someone would pop down to the forge at 4am and churn out some award-winning metalwork, but that's because of the nature of their jobs. Inspiration doesn't knock off at the end of the working day.

Hmm, I seem to have gone off on a bit of a tangent here, and lost my way a bit. I guess that's what 9 hours on a train does to me. So, what do others think? Should revision control archives be a project deliverable in commercial contexts?