It's always version 3 :-(. Version 0 claws its way past its contenders, version 1 adds a bit of polish and stability, version 2 adds some really sweet features, version 3 they try to use as a free ride for something that should really be version 0 again.―Paul Harrison
It's a bit shocking to realise, but that's right, isn't it... Gnome, Ubuntu, KDE 4, Gimp...
- Gnome — literally with GNOME 3 and the Gnome shell, breaking all the plug-ins and panel applets and all the other things that people have written to work with it.
- Ubuntu — not numbered like that, but after six years of solid improvements and increasing stability, the distribution switched to Unity, a software package that was at version 0.2.46 only six months previously and whose overall maturity matched that number (its version number was bizarrely incremented to 3.8.10 in those six months). The interface itself may be better or worse, but the 0.3-level maturity was a real problem.
- KDE — managed to dodge the bullet with version 3, but KDE 4 is famously the "break everything" release. Users who relied on the reliability of KDE 2 and 3 were left high and dry. Some components were even worse, delaying the break until a later "minor" release, as with KMail 4.7 and its "lose all e-mail" migration. At the same time, an e-mail client is network-facing code, so staying with an unsupported version is not really feasible.
- Gimp — currently at 2.6, it's gearing up for a 3.0 break-everything disaster with GEGL. This library, currently version 0.1.6, will be used as the new core for Gimp over the next few releases.
Given the pattern, it's hard to blame the individual participants; it's probably something about the way we develop institutions around open source projects that leads to the Version 3 Effect. In any case, it's better to focus on the future than on the past. What can we do to improve the situation?
Paul points out that it's fundamentally based in a form of exclusion. By the time of version 3, the development team is no longer sufficiently representative of users, leading to these new interfaces that are decisively breaking the deal between the two. Perhaps improving the openness and inclusivity would help.
To some extent I think it may be the standard problem with all organisations — it's really hard to wind one down even when that's the desirable outcome. Switching a project to maintenance only mode would entail quite a substantial winding down from the full-ahead development mode for which the project organisational structures were built, and which was all the project organisation has ever known, so it's hard. There isn't even really any societal expectation that that's what will happen, the only projects ever to have such a policy were Metafont and TeX (and that's mostly considered a joke or at least odd). Yet in some ways the Metafont numbering scheme, with its ever-decreasing version increments, is exactly what's needed. Plan for success.
The proper role of the organisations in question is to be the custodians of the name and reputation, and they're betraying that trust by using that name and reputation for a new, only vaguely related project. Traditionally we have relied on forking to rein in rogue custodians, but forking does nothing to protect the name and little to protect the reputation.
At the very least, we need an expectation that when such a major re-engineering takes place, a new name should be used. Rather than completely re-engineering Gimp under the hood while everybody is expecting 2.x-series stability, fork it under a new name but under the aegis of the Gimp organisation, with the Gimp 2.x series declared stable forever and the new project starting with 0.x version numbers. That way, people who rely on it for their daily bread can switch when it's ready and when they're ready; when the stability and maturity reaches acceptable levels and maybe when there's a lull in business so they have time to become comfortable with the new system. Moreover, if it has a new name, they can install both and use each for its strengths, switching gradually rather than all at once. To some extent, distributions could use a new name where the project fails to do so, even if it's just "gimp3".
So, what do we have?
- Improve openness and inclusivity of FOSS development teams and organisations.
- Commit to avoiding the problem and taking the custodian role seriously.
- Use new names when such changes take place, with distributions compensating for any lapses.
Comments, observations, suggestions?
⇦ What's it like to be an expert? | ⇨ bzr split and garbage collection |
11 April 2012, 4:44 UTCcomment by sabik
As someone pointed out at the SyPy meeting, Zope 3.0 also exhibited this effect.
Comments disabled on account of spam.
