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.

5 thoughts on “The magical, mystical “1.0””

  1. I couldn’t agree more. Once you’ve presented your “product” to the general public it should have a 1.0 label. In fact I think having a 1.0 version number more clearly conveys the state of the product. Less than 1.0 seems unclear as to if it should be used at all, while 1.0 says hey it’s ready to go but it’s new so expect to see more improvements over time.

  2. There is a problem with breaking backward compatability. Which I think is one big problem.
    Beyond that, there is the discrepency between what I see in my head and what I have in my hand 🙂

  3. I’m a programmer, I count from zero. Really I should start at and count up to and so forth.

    In my experience, the stable interface thing kind of creeps up on you, and only later do you realize you’re stuck.

  4. While there may be a discrepancy between what your vision is and what you have, if what you have can already provide value to people and not make them miserable because of bugs, then I think it’s ready to be 1.0.

    Look at how many people are using Rails in different capacities. Rails hasn’t been dubbed 1.0, but I’m certain that DHH considered backwards compatibility when making changes.

    And I still contend that backwards compatibility is not *that* hard, particularly in dynamic languages. Python and Java have evolved *a lot* over the last 10 years with very little in the way of backwards incompatibilities.

  5. Like Taz says, once people are using it you’re going to have to keep backward compatible anyway so that’s that. Calling it less than 1.0 might make you feel more comfortable, but it doesn’t change the fact that you’re basically locked in.

Comments are closed.