Heron's not so hardy after all

Is Ubuntu's Hardy Heron resting on its laurels? Ubuntu 8.04LTS - for Long Term Support - was widely expected to continue the platform's long, steady march towards impeccable reliability and usability. But instead of a shot on goal, it's looking more like a foul each day.

Our first impression of 8.04 was good - but we had enough trouble during the review that we couldn't recommend it for enterprise deployment. Since then, more problems have emerged. Take Six Annoyances In Hardy Heron, a blog post from a solid Ubuntu fan that details a number of places where the new distribution is notably worse than its predecessor. Some are trivial, some serious, but all are clearly mistakes. He also links to numerous other users who have their own concerns: this is part of a rising murmur of discontent from the Ubuntu heartlands that will carry on growing until the problems are acknowledged.

In fact, it's just one problem. 8.04LTS wasn't ready. Decisions had been made that weren't good decisions, mistakes had been made that weren't fixed, assumptions were assumed that weren't true. That's par for the course for any big project, and in something that relies on quite so many disparate parts as a Linux distribution, it's only surprising that there weren't more.

But one of the key benefits of open source is that it should be easier, not harder, to sort such issues out. You don't have to operate behind a cloak of commercial secrecy: the discussions, the decisions and their consequences are all on show and can be remedied far more effectively than if you launch them all at once on an unsuspecting world.

Mark Shuttleworth is trying to get the suppliers of Ubuntu's major components to adopt a common release cycle, which would on the face of it help with things like 8.04 having to choose between the reliable Firefox 2.0 or the late-beta version 3 that it actually shipped with - a choice that's looking like a mistake.

I think that wish is hopeless, if not actively harmful. While the commercial imperative to hit a shipping date is very strong with proprietary software - the tyranny of the quarterly cycle creates enormous financial pressure - it is far less so when you have the freedom to decide when something's good enough. Your stakeholders aren't looking for guaranteed revenue on the books by the end of Q2: they're looking for quality.

It is important to have long-term support for a product; it is less so to anoint that product in April, come what may. Trying to impose a commercial cycle on entire swathes of open source development risks importing many of the commercial model's problems and losing a lot of the freedom of choice that makes open source unique.

A better model for LTS versions of Ubuntu would be to have a far more relaxed schedule. Given a three- or five-year window of support for LTS versions, then it's important to have the successor up and in the market before the expiration of that window. But why limit the window to a fixed term? That's dangerous, even for highly controlled companies such as Microsoft.

Better to guarantee a minimum period of support for LTS, to be wound down when the next LTS-worthy version has been tested in the wild for long enough to prove its worth. With a nominal six-month upgrade cycle, you can even leave that particular target a year wide. When, and only when, a version is found to be satisfactory, trigger the changeover.

That leaves plenty of opportunity to change bad decisions, adopt good, stable versions of the components when they become available, and lets the users become confident that the new LTS is safe to adopt. Sure, it blurs the alpha-beta-RC-release lines - but rewriting the rules of software development is rather the point.