Get out of the zeros!

Thursday 3 February 2005This is more than 18 years old. Be careful.

I love open source software. I use a lot of open source software. But there’s something that really bugs me about it: zeros. You know the ones I mean: the major version number. What is the problem people have with declaring a piece of software to be 1.0?

Look, your software isn’t done, we all know that. Software is never done. That’s one of the great things about it. If you write a book, at some point you have to walk away from it and hand it to the printer. You generally don’t get to tweak it some more, fix problems in it, add new content. Sure, some books will go through multiple editions or revisions, but for the most part, writing text is a finite process.

But software is never done. You’ll always find bugs to fix, features you want to add, improvements to make, and so on. That’s what version 2 is for!

Look at some of the Python packages I have installed:

These are all great pieces of software. Some of them have been publically released for years. Just what is this 1.0 nirvana we’re waiting for? Is the goal for the author to press the final Enter key on his deathbed? Here’s an idea: what if we just throw a factor of ten into all of the version numbers above? Then I’d be running version 9.2 of Pyana. Cool!

I don’t mean to snipe. I’ve been there: you have ideas in your head, great ideas that will make your software even better (more featureful, performant, robust, etc). You don’t want to give up on the thought that those great ideas will see the light of day in the future. Keeping a zero version number is a way of saying, “This is a work in progress. Soon it will be even cooler. Come back in a little while and see what I’ve done to it.”

But the zero is also a way of saying, “Don’t take this too seriously. I was only kidding. I haven’t done the final pieces to make it a real piece of software.” At least that’s the impression it gives.

In the commercial world, it’s important to put a good face on a piece of software, and shipping milestones are more formal than in much of the open source world. This makes it easier to decide when to call something 1.0. But the ease of releasing open source software shouldn’t keep us chained to the amateurish zeros.

Own your work! Declare it to the world! Stand up and say, “This is good. It’s real. I think you should use it.”

If you have a piece of software that you think is useful enough to release into the wild, call it 1.0. Then later we can talk about how to decide when it’s 2.0...


Hackers are perfectionists. Considering any given piece of software to be incomplete is merely a symptom of this. There's always one more feature to add or one more bugfix to apply.
A version number of 0.x might not 'look' professional, but often open source software of version 0.8 has a higher level of quality and stability than 'professional' software of version 4.6...
OSS people don't just want to pretend that their software is stable and dependable (that's what 1.0 usually means - not that it is finished) -- they want to do it.
Not sure if I would really like this kind of 'professional' attitude in the OSS world... There are in fact some projects that use a more 'professional' versioning system - most of which I know of seem to use it to make higher promises that they can keep (typo3 comes to my mind...).

Another thing is that V1.0 does in fact mean: 'this is not work in progress anymore'. As long as you stay 0.x you can always change your mind, completely redesign the software/API without worrying about backward compatibility (you may, but you told them not to rely on it). Most people don't like the idea of carrying around (and supporting) some of their early mistakes...

Anyway - measuring the quality of some piece of code is pretty difficult, so you should take the number too serious at all.
I said something similar here:

"Too many Open Source projects treat Version 1.0 as some kind of Holy Grail that can only be reached when the project is perfect. I find that highly annoying, because it makes it really, really difficult to tell a sketchy alpha from production code that is just still in pre-1.0 because the author wants it to do everything."
I completely agree. 1.0 should be the first stable and complete version that works in production. It does not have to have all the bells and whistles that you can think of.
Haha, it's funny when I think back some of production code I've seen that used modules that were at 0.2 or something. The code was perfectly stable, mind you.

The way I see it, there's kind of a "put up or shut up" attitude associated with commercial software releases, whereas someone writing a library in their spare time might see the less aggressive versioning as way doing things on their own terms, when they have time.
If one of the reasons to stay in the zeros is so that you can change your mind and break customers' work, then that's all the more reason to get a 1.0 version number!
One package I released (the font Malvern) was published as version 1.0, and eventually I seem to have got as far as 1.2.

Another, TclHTML, first went public at version 5.1 or 5.2 or something -- an indication of how many earlier versions never even got fleshed out enough to be worth publishing at all.

The first time I stumbled across GNU Emacs, it was version 18.55, which makes or whatever look a little feeble! :-)
API stability is a big part of a humble developer's fear of going 1.0. With 0.x you kind of say "well, maybe I'll change things, and you should expect that if you use this maybe you'll have to change things along with me."

To me, that's the difference between 0.x and 1.0, not quality. Something can be high quality before 1.0, and it can be crappy quality at 1.0, and both are valid. Stability and commitment to an API and backward compatibility are what 1.0 means to me.

If I'm writing commercial software I have to put in the effort for that kind of support; that's what people pay for. But with open source there's far less motivation, and backward compatibility can feel like an albatross. Of course, you might paint yourself in that corner whether you like it or not, if you use your own libraries for things that go into production. But developers are hopeful, and dream of green fields where they need accept no compromises, so they'll sometimes delude themselves with 0.x even if the project is more mature and has more legacy cruft they need to support than they will admit.
Perhaps programmers are just used to count from zero onwards?
May be the real problem in OSS 0.x is either a lack of commitment to an API, or the lack of acknowledgement from the developpers that such commitment isn't planned at all (which can make sense if you follow an scrum-like process, for example, where everything is planned by sprint).

Such development process should used release deployment using version-code number or date, which will more easily represent their development process, instead of release numbers, which will probably never have a real meaning for them.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.