Started: 27 February 2012, 8:29 UTC
Finished: 26 April 2012, 3:11 UTC

The Version 3 Effect

Keywords: FOSS, version3

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...

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?

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.