Thursday 3 February 2005 — This is nearly 20 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 publicly 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...
Comments
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.
"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."
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.
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 0.0.3.9 or whatever look a little feeble! :-)
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.
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: