Synchronized Releases and Greg Kroah-Hartman

Credit: TiggerT, License: by-nc-nd

O'Reilly interviewed Greg Kroah-Hartman (log), the Linux kernel developer who founded the Linux Driver Project. The interview explains how the Linux Driver Project can support the weirdest Japanese USB devices, how Linux is being developed, why binary only kernel drivers are illegal, how a time-based release schedule benefits Linux, and how Greg thinks about synchronized releases. Although all these topics are interesting to read, I will restrict this blog post to the latter 2 of them.

Time-Based Release Schedule

Since 2.6, the Linux kernel has a time-based release schedule. As you can see, Greg really favours this development model (we also do):

• It is working very well.
• It is very predictable.
• It increased our rate of developers, our number of companies participating, our number of developers participating.
• There is better feedback.
• We've got more people testing it out that way. People will only test when a release comes out.
• The traditional "If it ain't broke, don't fix it" software engineering model is obsolete: the world changes, so we have to change in regards to that. Linus's famous quote is Linux is not intelligent design; it's evolution. We evolved the kernel.
• Contributors plan their contributions: it's all volunteer-based. If you say "Here is when the timeframe is going to be" everybody knows that if they want to get something done they have to get it in by then. Otherwise, they'll work on it at their own pace.

Synchronized Releases

Even though we both agree that time-based release schedules are a good thing, Greg has a different idea about synchronized releases. Maybe I can change his mind by debunking some myths about synchronized releases:

I think Mark is asking other people to do his job for him. He has a very small number of developers; he has a very limited development staff. [..] If you look, wanting to rely on other people to stabilize that integration is a great thing. If other people can do your work for you that's a wonderful thing to get them to do; I don't think that's going to happen.

• Myth 1: Mark invented synchronized releases to free ride on the community.

  Wrong -- Mark did not invented this. The Eclipse Foundation did. Not because they wanted to free ride on the community, but because they wanted to spur adoption by providing more value for their users.

• Myth 2: Mark wants this because he has not enough employees.

  Wrong -- One of the issues of the open source community is that the same integration work needs to be done over and over again by different people in different projects. Synchronized releasing has the potential to increase the overall productivity of the whole community by reducing duplicate integration work. Hence, more can be done with the same number of people.

• Myth 3: Nobody will ever synchronize their releases.

  Wrong -- Gnome and Ubuntu are doing so, Eclipse is synchronizing (you really should read their goal!), we are doing synchronized releases at Coccinella, Midgard CMS is synchronized, and possibly others.

Trying to line up Red Hat and Novell and Ubuntu--just business model and internal business concern with each other is not fair to ask of a way of companies that compete against each other.

We have a very weird environment at Linux in the fact that there's these different companies that at the management level and the marketing level are competing. They're competitive companies. Red Hat and Novell go after the same customers, the same install base, and they're very, very competitive yet they have the exact same engineering staff. Red Hat is Novell's engineering staff and Novell is Red Hat's engineering staff. You can't do stuff to make that upset. It's a very, very weird model but just trying to align the business model and their timeframe of what they wish to do and trying to tell the Open Source community that you're going to line up with these businesses at the moment in time is a very unfair thing to ask.

• Myth 4: Synchronized releases involve competitors which is not possible as they can't collaborate.

  Wrong -- Strategic alliance is the business concept for companies working together. Yes, even competitors. There exists research about this.