Synching the open source release schedule

Introduction

Both Mark Shuttleworth and myself have discussed this idea before. Because Mark brought it up again in a recent interview, I feel compelled to developer this idea further.

The main concept is that Linux distributions, and open source in general, have a lot to gain by synchronizing their release schedules.

Positive impact on the image of open source

Can you imagine the news articles that would be written if Ubuntu, Fedora, and OpenSuse all released a new version on the same day? Every six months, the world would see that open source has successfully delivered a new version on schedule. Mark Shuttleworth made a great point when he stated:

"We know when the next LTS will be probably with better confidence than we know when Windows 7 will ship. I would take that bet."

Once the distro releases become synchronized, it would create a huge incentive for upstream projects to synchronize on the same schedule.

Currently, we have upstream releases happening all over the calendar. For example, the newest version of Ubuntu includes a beta version of Firefox 3. It also includes OpenOffice 2.4, which is soon to be replaced by OpenOffice 3.0. With the power of a synchronized release, these upstream projects would work hard to get their newest versions into the distributions so that their users can start using the code sooner.

Creates efficiencies in software development

Open source is a very unique software development model, in that the code is freely shared between anyone who wants to work on it. This usually leads to great productivity from the worldwide development team that is formed.

However, there are some friction points in this model. Specifically, this friction happens when Linux distributions are working on different versions of an open source application at the same time. Mark addressed this point in his interview:

"Timing your releases drives a whole bunch of things. It means a greater ability to collaborate on bug fixes. If we are on the same versions of the Linux kernel, it is a lot easier for us to say, 'Hey, here is this patch to make this device work. Do you know any reason why we shouldn't put it in?'

You could just get so much more done at an engineering level between the teams. My engineers regularly collaborate with Novell and Red Hat and, of course, Debian. Barriers to that sort of collaboration are sometimes ideological but, in most cases, are just practical things. We are just on a different version so someone else's patch isn't going to apply. There's a bit of friction there."

How do we accomplish this?

I agree with Mark's short answer to this question. Simply set a hard date and modify your goals to make that release date. That greatly oversimplifies things, but it demonstrates that the long-term benefits of a regular release schedule greatly outweigh any negatives caused by postponing a feature into the next release.

In reality, there are a number of questions that need to be answered before this can happen.

1. On what date will the releases happen? Does it have to follow the current Ubuntu schedule of releasing every April and October?

Mark answered this question in his interview:

"We would be quite willing to revisit the elements of our release schedule in order to make that synchronicity possible, if the fact that we happen to do April and October wouldn't work for the majority of the distros. We would be flexible in that regard."

2. What amount of time should there be between regular releases?

Periodic releases every six months has worked very well for Ubuntu, but not all distributions are currently following that schedule. Six months also works great from a marketing perspective, because the release would always happen in the same months every year. Lastly, the open source motto is to "release early, release often". Six months is an attainable goal that balances the need for incorporating new features with the need for stability and quality assurance.

Call for civility

I understand that a post like this could lead to a distro war in the comment section. Please keep your comments civil and always show respect for other people's ideas. Hopefully, we can come up with some great ideas on how to improve open source software!