KDE and a periodic release cycle [Update]

I just watched Mark Shuttleworth’s Keynote on aKademy. The discussion afterwards was mainly dominated by his suggestion to switch KDE’s development cycle to a 6 month release cycle. Here is a closer look at what Mark said – and what KDE did in the past.

What Mark said

It is important to point out what Mark said exactly:

If you guys articulate it and make a commitment to shipping something round about the same time as Gnome did, we would made a converse commitment and that is we’ll ship your stuff very shortly after you do.

It is a promise in vapor ware on both side: the KDE team would promise to ship the next KDE version no matter what it costs, and the same is true for Kubuntu. In this regard the priorities must also be clear:

It boils down to this: No single feature is more important than the release.

It would mean that only these features are included which are really stable enough at that time – everything else would have to wait another release cycle to be included with the next KDE upstream version.

Of course, this would have several advantages and disadvantages:

Advantages

The biggest advantage would be that a recent KDE would be included in each new Kubuntu release: this would give the users a much better experience and it would also mean much faster feedback for the KDE developers. Also, the drumbeat resulting from this release commitment would be enormous: K/Ubuntu, Gnome, KDE, the kernel and maybe even OpenOffice all releasing in the same time frame would create a rhythm hard to ignore. Also, it is likely that other distributions would pick up this release cycle: in these days many of the distributions try to keep a periodic release cycle. And it makes sense for all desktop oriented distributions to take over the release cycle of the main desktop environment. Ubuntu does it, Fedora just stated that they are going to do the same.
It would be easier for the distributions to plan and organize releases, and it would enable them to ship the newest technology available all the time.

Disadvantages

There are mainly two reasons against such a cycle I can think of at the moment: first of all the developers would have to get used to this kind of pressure and rhythm, and they would have to adopt it. New features would have to be coordinated quite exact and new, complex features depending on each other would become quite difficult. This is possible, but requires for example a very balanced and thoughtful release coordination team.
The second reason is press: With the current situation there are Open Source news all the time. But when all projects start to sync suddenly there would be just too much information all 6 month with much less notable events in between. Just imagine the news when KDE and Gnome would release new versions in the same week: “KDE vs Gnome”, etc.
Also, smaller projects would have it difficult to gain enough attention if they would adopt the release cycle (although they would get more if they would a-sync their release cycle).

I’m not sure how the press thing would work out for the different projects – maybe it would hurt them, maybe not. Maybe it would even lead to more attention by broader media (evening news and so on).

What KDE actually did

The question is now if KDE could even adopt such a release cycle. Would the project be able to do such a thing? Or would it be so alien that it could hurt the project?
To answer that question I had a look at the KDE 3 releases:

KDE 3 releases over the time
release number	release date	time difference to previous release	time difference between major releases
4.0 (expected)	23 October 2007	154 days	that doesn’t count – but: 693 days, roughly 23 months
3.5.7 released	22 May 2007	117 days	–
3.5.6 released	25 January 2007	106 days	–
3.5.5 released	11 October 2006	70 days	–
3.5.4 released	02 August 2006	63 days	–
3.5.3 released	31 May 2006	64 days	–
3.5.2 released	28 March 2006	56 days	–
3.5.1 released	31 January 2006	63 days	–
3.5 released	29 November 2005	47 days	258 days, roughly 8 1/2 months
3.4.3 released	13 October 2005	78 days	–
3.4.2 released	27 July 2005	57 days	–
3.4.1 released	31 May 2005	76 days	–
3.4 released	16 March 2005	98 days	209 days, roughly 7 months
3.3.2 released	8 December 2004	57 days	–
3.3.1 released	12 October 2004	54 days	–
3.3 released	19 August 2004	71 days	198 days, roughly 6 1/2 months
3.2.3 released	9 June 2004	51 days	–
3.2.2 released	19 April 2004	41 days	–
3.2.1 released	9 March 2004	34 days	–
3.2 released	3 February 2004	20 days	371 days, roughly 12 months
3.1.5 released	14 January 2004	120 days	–
3.1.4 released	16 September 2003	49 days	–
3.1.3 released	29 July 2003	71 days	–
3.1.2 released	19 May 2003	40 days	–
3.1.1a released	9 April 2003	20 days	–
3.1.1 released	20 March 2003	51 days	–
3.1 released	28 January 2003	38 days	300 days, roughly 10 months
3.0.5a released	21 December 2002	33 days	–
3.0.5 released	18 November 2002	40 days	–
3.0.4 released	9 October 2002	51 days	–
3.0.3 released	19 August 2002	48 days	–
3.0.2 released	2 July 2002	41 days	–
3.0.1 released	22 May 2002	49 days	–
3.0 released	3 April 2002	–	–

As you can see the time differences between the major releases (3.x) do vary around 8 months. Industry partners need an at least rough release plan, and users are expecting something new every once in a while.
The minor versions where a bit more periodic, but also with huge gaps. However, you could say that there was a minor version every second month.
The major releases vary up to a certain point, but if you only take 3.2 till 3.5 you have a mean of 7.3 months with a standard deviation of 1.32. That is of course not comparable to a fixed release cycle with 6 months, but also not that bad. Neglecting some gaps the minor version also had a release every second months.
Just for comparison: Gnome has a major release every six months. The minor releases seem not to be bound to a fixed date: there were 28 days between 2.18.0 and .1, but 49 days between .1 and .2.

So according to these numbers a switch to a 6 month release cycle would be something totally new for KDE!

Worth a try

Although such a drastic change in preparing releases would mean a lot of change for KDE I think it is worth a try. KDE should work on better release politics anyway to get at least some sort of stability.
Lookin (now) at these numbers it turns out that a switch to a fixed release cycle would require some changes – but not that drastic ones. So from that regard a switch to a periodic release cycle looks at least possible.
There are other possible advantages: it is much easier to talk to corporate users, ISVs and distributors if they can predict the next releases. And KDE has matured enough to listen also to corporate users. And of course: it would be more fun for the users: having a major release in a regular time frame would be more fun to follow. Last but not least it might even attract new developers.

So there are two questions: first, will KDE switch to a fixed release cycle, and second, will KDE switch to a 6 month cycle? But that is up to the developers, they will have the last word. Until now now one spoke out – except Sebastian Kügler, who is opposed to that idea I’m anxious to hear other comments about that topic.

Update:
Kurt Pfeile thankfully spotted a small but important mistake: in the calculations I missed the KDE 3.4 release and calculated the difference between 3.3 and 3.5. This changes the view on the release cycle. The parts in the text are corrected. I’m very sorry for this mistake and the inconvenience it might has caused. I will have an extra look next time I calculate such important dates and time frames. Thanks again Kurt for your remark about that.