The magical, mystical “1.0”

It seems that many open source projects don’t want to put themselves at the magical “1.0” number until the software is “done”. In my opinion, software is “done” when it reaches its end of life and is being put out to pasture. That’s one of the great things about software: it’s malleable! Software is much more malleable that many other “products”.

One could start a project by declaring “SuperMegaWidget will be called 1.0 once it has found a cheap, renewable, clean energy source”. That may sound outlandish, and it is, but quite a few projects set the bar very high for 1.0.

Maybe this is some new breed of 1.0 that is different from the kind I grew up with in the ’80s. Do you remember Windows 1.0? It was not pretty or useful. It couldn’t even stack windows (they were all tiled). But, it was a starting point and it did what it said on the box.

These days, it seems like everyone coming out with an MP3 player starts it off at 0.1 saying “well, it only plays MP3s… I’ll call it 1.0 once it plays Ogg, MPEG video, protected WM files and can transparently connect to P2P networks to download other songs you might like”. That’s crazy! If you’ve bothered to package up a release at all, clearly you think there’s something cool and useful there. Give it a proper starting point. Call it 1.0.

One might make the argument that, with programming tools and libraries, you can’t just make changes willynilly after 1.0 because people are depending on the stability of the API for their own products. The fact is that after a project becomes useful and has a community, you’re already somewhat locked in to the API you’ve provided. If you’re not prepared to at least document API changes, don’t make a release. Just leave it in Subversion, which makes it really obvious that you’re likely to change anything at a moment’s notice.

1.0 doesn’t mean “changes are no longer allowed” or even that “changes are hard”. It does mean that anything that might break a user’s code should

• Preserve backward compatibility where possible (and not too heinous)
• Be documented
• Have a suitable deprecation period for things that are going away

These requirements are not too onerous. Python and Java have grown this way. They don’t grow quickly, but I think that’s partly in the nature of the tools. Different packages will be able to change at different rates. It’s especially easy to document and assist with backwards incompatible changes if you keep track of them as you implement them.

Languages like Python that offer keyword function/method parameters and duck typing make it even easier to maintain backwards compatibility while providing new features.

For TurboGears, I started it at 0.5 knowing that such a web development package could use some more outside review and validation before the APIs could be thought of “stable”. I also knew, and said that it would quickly reach 1.0. TurboGears parts were all solid and fairly mature, and it was really only the glue that needed some review.

Even I’m somewhat guilty of 1.0-itis. The forthcoming TurboGears 0.8 release could be called 1.0, assuming the requirements on that development status page are met. I knew that the sprint was coming very soon, though, so I decided that we may as well get the sprint results merged in to the final 1.0 release.

So, I say “embrace 1.0!” And then get back to work, because 1.0 is just the beginning.