This is a thought that has been troubling me for some time, but the upcoming release of 10.04, the next long term support (LTS) version of Kubuntu (and the Kubuntu Gnome Edition ) makes this post pretty timely. The LTS release is in effect the enterprise-class version, with a support window long enough to make its testing, installation and management feasible in a large scale desktop setup. An aside, but I differ as to where the need for long term support is strongest; while servers are individually more important, you can far more easily, cheaply, and effectively test and upgrade your server fleet than you can your desktops and laptops. Your desktop and laptop fleet (unless your organisation is both well-managed and very, very rich) will be far more complex to deal with, with many bits of hardware, and with individual needs dictating many combinations of software to test against.
But I'm not sure that 10.04 will be enterprise ready, at least not for most organisations of any size and not for any intending to purchase support from Canonical. Don't get me wrong, I'm sure that Kubuntu 10.04 will be a great piece of desktop software, just as 9.10 is. I'm using the latter to type this on my work laptop, run it on my work desktop and netbook and we have a number of non-technical users migrated or migrating to it. Kubuntu 10.04 will come with some great core software (although we could still do with Kivio being sorted out - anyone?), with a brilliant underlying architecture, a beautiful and highly (end-user) customisable interface and the capability of doing most any job an organisation or individual might need.
The issue is this: an organisation with a big end user fleet needs some stability for planning with; hence the LTS requirement, with five years in which to test, deploy and maintain, before entering the testing phase of the replacement desktop OS. But what they don't need is for the complete desktop eco-system to be locked-in to a point in time; uniform across the OS and apps. In fact that is the last thing they want - the testing cycle becomes long and intense with many factors to consider or potentially overlook and with many changes for people to need support with; where the desktop OS itself might well be good for 5 years or more, some or all of the applications and associated plugins are likely to benefit from updating both more frequently and in unrelated cycles.
Moreover, one of the (many ) advantages of adopting open source solutions should be that open source software updates are more often evolutionary than revolutionary; short testing cycles, quick and easy deployment, minimal training requirements. But the jump from one deployed LTS to the next will be 4 or so years worth of application releases; and some of the applications you would still have in use would be out of support from the original creator's perspective. Sure another advantage of open source is that the lack of support from the originators of the application is not a killer blow, but it does mean Kubuntu developers having to maintain software unnecessarily; I know I'd rather they worked on core improvements and new applications than spent time bug fixing end of life apps.
A further issue is this: right now, if I chose to deploy 10.04 and another organisation chose Windows 7, in 4 years time when we are all looking at our next desktop OS, they will be just looking at their OS and not their apps. Worse, if our only difference was in the choice of desktop, in 4 years time they will be using the latest and greatest versions of applications such as OpenOffice, Firefox, Inkscape and Krita, and we would be stuck on 4+ year old versions. Worse still from our perspective, this would mean we would be lagging in our support of open standards such as ODF, HTML et al, SVG, etc..
Before you start writing comments to the effect that it is possible to install the latest versions of applications mentioned (and others) by adding third party repositories, download third party debs and rpms, or compiling from source, I know, and occasionally I do just that. But then I am self-supporting. In the enterprise support is important; going out of the distribution means withdrawal of support, potentially not just for the updated application but for your entire desktop install. Just not acceptable in a large deployment.
So I have a solution to propose: a separation of the core OS and the mainstream userland applications. In the latter grouping I would put a relatively small number of apps like OpenOffice, the KDE desktop suite, GIMP, Inkscape, Scribus, Firefox, etc., and annually make available the latest version of those packages for all currently supported core OS releases. Anyone using a non-LTS would probably get one update of applications, LTS users would benefit from the choice of 3 or 4.
Maybe this service should only be made available to subscribers on the basis it mostly advantages enterprises, as individual users currently get the new applications by upgrading their entire desktop. Maybe it should be a service FoC; I guess the cost of achieving and maintaining this split should determine whether it is charged for. The related updater should have a simple per application tickbox (and conf file) acceptance of the use of new versions, to allow the enterprise IS management to easily control how and when new versions of applications are deployed.
This is just my solution to the problem identified. Others may have alternative solutions. Some may believe that this complete freeze is a good thing, or application updates should be in the LTS point releases. I'm pretty sure the complete freeze is a problem, and that it needs a supported solution that gives easy control over application update timings. The latter of course makes the former a choice while I feel the current approach restricts choice. Choice is the Linux advantage, isn't it?