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!

Comments

  1. I really like this idea. We had an Ubuntu installfest today at school, but Fedora 9's coming out next week. It's tradition that our installfests are the day after Ubuntu releases. We want to have them immediately so that people around town know that as soon as it's out, my school's got an army of geeks ready to help. Fedora just went to a 6-month deal too, so right now they are very close to Ubuntu's release schedule as well, but being a week off means we couldn't have it at the installfest.

    I don't think the internet could take it though. Parts of the internet (certain geographic areas) couldn't handle Hardy's release, according to Seveas. Canonical's infrastructure and Ubuntu's worldwide mirrors haven't been able to handle any of the 4 releases I've seen. I know torrents are an answer to the hammering the servers take, but they weren't even listed as an option on the main download page, let alone promoted as the best way to get it. On the forums, all the mods put in our sigs notices saying to use the torrents, and that's what was being said on IRC, but IRC and forums are where new users go *after* they've managed to retrieve an install disk.

    I'm sure people would take notice of how much bandwidth had suddenly disappeared from the 30,000,000 (according to Novell) Linux users out there all downloading updates and ISOs simultaneously though.

    ReplyDelete
  2. > I understand that a post like this could lead to a distro war in the comment section.

    I don't think so.
    I think you will have a "war" distributions and upstream projects.
    If Ubuntu want to sync upstream release with their releases, then Ubuntu should contribute upstream.

    All the hard work is done upstream, not in distributions.

    Upstream first, then distribution.

    ReplyDelete
  3. Re: Anonymous

    IIRC the main reason Ubuntu's release dates are when they are is because they are linked into Gnome's release dates.

    So they're already doing what you suggest.

    ReplyDelete
  4. I agree that a synchronized release would be a good thing. If Ubuntu wants to take the iniative it could synchronize its release with Fedora's, as the delta is small. That is only a starting point and afterwards try a fruitful collaboration.

    ReplyDelete
  5. It would be great! I've always tought something like this because cooperation is the most important thing in the open source world.

    At least X.org, Gnome and KDE should have the same release schedule of Ubuntu, Fedora and openSUSE.

    ReplyDelete
  6. > It would be great!

    Yes, Fedora 9 will have KDE 4. It can be really cool for KDE (and Kubuntu) if Ubuntu is sync with Fedora.

    ReplyDelete
  7. Have we considered the lack of publicity the smaller distros would get? Even opensuse and fedora would probaby be overshadowed by ubuntu's release, that sounds bad for linux in general.

    ReplyDelete
  8. kiwi made a good point.

    ReplyDelete
  9. > Have we considered the lack of publicity the smaller distros would get?

    It's a win-lose.
    Ubuntu have a great image. Good communication, great community, etc.
    Syncing all (or most) distribution mean : we are all the same, but Ubuntu is fun and the other are boring. Now lets chose...

    ReplyDelete
  10. TBH, it makes no sense to sync distros in general.
    Fedora, OpenSuSE and some others are targeting the non paying users of linux, which is good, RH and Novell/SuSE are targeting paying customers, which is good. Canonical/Ubuntu is targeting non-paying users also (support) paying customers, which is good.

    Fedora, OpenSuSE, Ubuntu (to make them the three big global, known players) are targeting for a commercial environment, as we all know.
    So why should a company want to sync with another distro of competitor?

    At least, that all the major linux distributors have finally found a general release cycle is very professional, and companies and users who are deploying Linux in a professional environment can count on that. So, no matter which distro you use, you know exactly when they hit the world..which is good.
    You can't even force other companies to a special time based release, because their system works differently then the other.

    IMHO it's enough to know, that there is something like a time based release scheme for linux distros and that other people and companies can rely on the release schedule in general. So, for them, there is a good timeframe to plan uprades etc.

    ReplyDelete
  11. Hmm,

    i think LTS releases should be after Fedora and Suse releases cause that helps getting more bugs fixed ( Hardy is sadly not really that bug free ).
    I think it would have been a good idea to make LTS .06 releases. That way firefox wouldnt have been beta etc. And it would have given Canonical time to release release candidates for 2 month. I think a LTS should get that kind of attention. Flooding users with updates like we will likely see in the next months isnt really a confidence buiding measure. Releasing before Fedora and Suse maybe adds to traction and hype .. but Ubuntu hardly lacks those. The real problem is meeting exspectations now .. and more RCs would have really helped.( Trust me .. I installed Hardy on 3 machines already and it wasnt as trouble free as it could been.) I really hope there wont be anymore .04 LTS releases in the future.

    ReplyDelete
  12. A perfect release schedule would be IMHO:
    january, july - Linux kernel (stable), gcc, qt, gtk, other basic stuff
    february, august - X.org, sane, cups, other userspace hardware related stuff
    march, september - desktop environments, openoffice, firefox, thunderbird, other apps
    april, october - major distros, eventually unstable kernel
    may, november - derivative distros (mint, pclinuxos, etc)
    The starting point could be of course adjusted.

    ReplyDelete
  13. disclaimer: I'm on the Fedora Project Board. I also work for Dell who sells Ubuntu on a number of desktop and notebook systems. However, I only speak for myself.

    Ubuntu and Fedora's schedules are pretty closely aligned already, both having aligned with the GNOME release schedule. Fedora targets May Day (i.e. May 1) and Halloween (i.e. October 31), and adjusts slightly to try to release on the Tuesday closest to that. (Why Tuesday? We've found this gives our mirror admins sufficient time, if the gold master images are done by Thursday of the week before, to get the bits onto the mirrors before the onslaught of downloaders. Having the weekend helps too as there are fewer corporate internet users which speeds up getting the bits synced.)

    Fedora has also adopted a feature planning model, whereby proposed features are targeted for a release, but under very few circumstances will they be allowed to "hold up" the release. If they're not ready, they aren't included; the next window is soon enough at only 6 months away. Like Ubuntu, the release schedule is published well in advance so it's no surprise to anyone.

    Unlike Ubuntu, Fedora leaves the builder systems alive throughout the life of a given release. Where Ubuntu freezes the package set at release, and only provides a very limited number of backported fixes or package updates (security fixes, critical bugs), Fedora allows new packages into the release trees throughout that lifetime, as long as they don't break the rest of the release. This helps get features into the hands of users even faster.

    ReplyDelete
  14. Thats my biggest complain with ubuntu, i have to wait to get the newest versions of the packages, or get into dependency hell and build them my self, thats what im currently doing, i'd switch to fedora just for that reason, but thats just me.
    Synched releases would be great, but i think it would limite the freedom of the smaller open source projects, lets not forget that a lot of them depend on the developers time, and he usually has to feed a family first.

    ReplyDelete
  15. I personally like this idea. If it really gets implemented then it will mean lots of knowledge sharing, better and faster bug fixes and collective feedback from bet testers.
    This will be spcifically useful to packages like X, bluetooth stack, multimedia, PIM tools etc.

    I hope this starts as soon as possible.

    ReplyDelete
  16. Anonymous: Working on upstream projects is great, but that is not the primary purpose of Linux distributions. Upstream focuses on creating software, and distributions focus on packaging the thousands of upstream projects and melding them together into a cohesive unit.

    Matt: Thanks for sharing that information, I am going to read more about Fedora's release process. Perhaps we can compromise and release together on April 30th and October 31st?

    Ubuntu does have a backport repository, and I agree that it doesn't include a lot of packages.

    However, I would argue that freezing versions during the life of a release is a good thing. Most importantly, it reduces the amount of work to maintain the released distributions. This allows for more work to be put into the future release, which is where our resources are best spent. Another benefit of this freeze is the stability that can be achieved from not changing things all the time.

    Of course the downside is that you have to wait 6-months to get your updated software. Is that really a problem? If it is, then please run the alpha and beta versions of Ubuntu. You will get the newest, freshest software available and also contribute to the development of the new release!

    ReplyDelete
  17. > Anonymous: Working on upstream projects is great, but that is not the primary purpose of Linux distributions.

    It's the primary purpose of Fedora (or it seams).

    http://fedoraproject.org/wiki/Objectives
    -"To do as much of the development work as possible directly in the upstream packages."

    http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
    - "Fedora Project has a strong focus on not deviating from upstream as much as possible in all the different software it includes in the repository. The following is a general set of best practice guidelines on why this is a good idea, tips for sending your patches upstream, and the potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts."

    http://fedoraproject.org/wiki/Features/Transifex
    - "translators can use Fedora Web-based tools to contribute directly to any upstream project"

    Ubuntu should think upstream and then all distributions are sync.

    ReplyDelete
  18. Ubuntu does forward stuff back upstream. The rule for "can I get a package into Ubuntu?" is "get it into Debian first, then we'll talk." When I submitted a patch to Ubuntu, it was immediately forwarded to GNOME upstream.

    ReplyDelete
  19. I don't think packages should be on the 'same' schedule they should be on the opposite six months. That way that can be well debugged by early adopters before going mainstream. I'm tired of 'stable' releases being full of buggy beta's.

    ReplyDelete
  20. of course the way gentoo works this doesn't really matter.

    ReplyDelete
  21. "Anonymous: Working on upstream projects is great, but that is not the primary purpose of Linux distributions"

    This is the kind of thinking that makes Ubuntu the distribution that contributes least amoung the mainstream distributions. Change that before you try to change the world. While you are at it, open source launchpad and landscape and then let's talk.

    ReplyDelete
  22. The major mirrors (kernel.org, anl.gov, etc.) don't really appreciate several major distributions releasing in the same week - it's pretty hard on them. This round, if Fedora hadn't been forced to slip 2 weeks, Ubuntu 8.04 would have been released on a Thursday, and Fedora the following Tuesday. I wouldn't want to try to align them to exactly the same day, much less the same week; within 2-4 weeks would be sufficient.

    ReplyDelete
  23. Not great, this means that all of the limelight for linux releases happens at one time, Its better to have releases happening year round in order to keep linux (in general) in the press year round.

    Also If people want to try different distros they either do it all at the same time (not a good way to get to know the ins and outs of a single system) or use one distro while its new, with the possibility of keeping it current, then trying others with the disadvantage that they are (possibly) no longer up to date.

    ReplyDelete
  24. Mark Shuttleworth and *I*. Myself is a reflexive word for use when someone or something is referring to themself or itself.

    This ridiculous overuse of myself when I or me is the appropriate word has proliferated to such an extent, almost no-one understands how to use it any more.

    If it was computer code you wouldn't be able to get away with just randomly writing this wrong instruction, so why get things so badly wrong in English?

    ReplyDelete
  25. Against!! Why? Let's see:

    1. Much as Shuttleworth wants it, Linux and Open Source is not all about Ubuntu 'we would be prepared to revise our schedule'. Muchos cojones my friend.
    2. The Ubuntu 6 months release cycle affects quality in a negative way. The first bug reports for Hardy have been demolishing. Things are happening that should have been ironed out.
    3. The Ubuntu 6 months release cycle hinders development. KDE have been able to create a landslide with KDE4, made possible because of the absence of a stranglehold on their release cycle.
    4. A 6 month release cycle is killing for the Linux image. Businesses do not want new versions every 6 months. They want ongoing, rolling improvements. In the current Ubuntu scenario, you are either obliged to refresh every 6 months (unthinkable in business) or install a (not so stable) LTS and forget about functionality improvement for the next 3 years. Companies that install Hardy will e.g. not be able to get OOo 3.0 which supports Office 2007 formats

    ReplyDelete
  26. Thank you Anonymous! Together, we can eradicate the 'myself' obsession epidemic.

    Personally, I'm against the global sync for two reasons: because projects should be free to choose their own release cycle, as it suits them, and because synchronising everything would be very boring. Very boring indeed.

    ReplyDelete
  27. At Coccinella ( http://coccinella.im/ ) we switched to synchronized release cycles more than half a year ago.

    This is how we do it:
    1) We synchronize with the major Gnome releases which happen every 6 months.
    2) As only 2 major releases a year is too few for us, we also have 1 or 2 releases in between.
    3) The release dates of the 1 or 2 Coccinella releases in between are very flexible.
    4) On average we do a release every 3 months (well, a bit less than 3 months actually).

    In the end we create value for different types of users by providing different kinds of releases:
    1) Fixed and predictable 6-month releases for business users and downstream distributions who would like to include Coccinella in their distributions.
    2) Releases in between (3-month) for people who can't wait 6 months for new features.
    3) Daily builds of the development tree for people who want to try the newest stuff or who would like to do some bug hunting.
    4) cvs for developers, hardcore bug hunters, and geeks who can't live without last-minute updates.

    In the end I back synchronized release cycles. If the open-source movement can slow down the Internet, people will actually realize how big we are. Compare it with the dinosaurs in Jurasic Park 1: the big dinosaur footsteps are synchronized releases, the footsteps of small dinosaurs are what normal people currently hear (nothing). Big dinosaur footsteps will shake the world and all people will hear and feel this. This is what we need. Massive Synchronized release cycles have the potential to make Mac OS X and Windows huge release campaigns look small...

    ReplyDelete
  28. I am a gentoo user and personally do not see a point for release scheduals at all. The package manager system handles when any new projects get updated. What is your 'version'? a large part is what kernel you are on. Come on linux users, BUILD your own kernel, its not that hard, and takes no more than a few min of your time every now and again. You have the freedom to update what you want when you want it. I personally have gnome kde and enlightenment installed on my box. What 'release schedule' should I be on? Put an option to compile into you package manager system for the things you want that are not compiled yet, and always be up to date with what you want. This is the beauty of open source and the internet. You do not have to be on a windows like release schedule, ever. It is a thing of the past

    ReplyDelete
  29. I don't think its a good idea and its not likely to happen.

    1. As already mentioned it reduces transient network loads.

    2. There is no upstream advantage as each distro will often use different releases of upstream apps because their acceptance criteria is different. Corporate customers need predictable cycles and stability while home users' needs often vary according to the package. For critical packages like the kernel if it works on the targeted hardware then stability is all that matters (newer versions shouldn't get worse). If it doesn't then the user is more likely to accept a higher level of risk to get it working. For non-critical apps like games the user is more likely to prefer features over stability. One particular problem are games with online servers. If the servers are updated and no longer backwards-compatible then the user expects to be able to update their client immediately instead of waiting until the next major distro release. This is how it works on Windows - just get the latest setup.exe and run it (just like with malware). Configure/make/make install is not equivalent to setup.exe. Having more servers with various versions is not the answer because of the small number of Linux game players it is difficult to find others to play with let alone spliting the player base further with servers of various game versions.

    3. It promotes homogeneous code which pushes the market back towards the situation that exists with the proprietary vendors. With the current variety, if a end user finds that a certain distro doesn't meet their needs due to a bug they can always try another one that may not have the bug due to different package versions.

    4. It reduces risk. A distro with a full deployment of an earlier release of a package may encounter a intermittent bug that can be more easily diagnosed due to a larger user base. This can then be fixed upstream which benefits distros in the future. Likewise the former benefits from previous bug fixes. This effectively spreads bug risks out. All distros will still have bugs but they will be less inhibiting for any specific release.

    5. Having distros handle bugs before reporting them upstream helps filter out invalid reports and distro-specific faults that would otherwise easily overwhelm upstream maintainers. This does mean that some duplicates may be reported that have already been fixed upstream but there are not that many and the distro's maintainers can backport fixes if needed.

    ReplyDelete
  30. I think it's a shame that some oppose the idea simply because it comes from the Ubuntu camp. If the lead of Fedora, Debian, etc etc had promoted this idea there would probably be less backlash.

    Although I don't think there should be a fixed release for all projects (freedome dictates as much), I agree that the publicity for open-source would be good. The people who say that releases all over the calendar are better seem to regard the OSS Press (such as distrowatch) as 'mainstream'.

    As it stands, Ubuntu, OpenOffice & Firefox are the closest to getting mainstream press when they release. Most else gets left aside. Having an annual or semi-annual mega-release week would help everyone else.

    ReplyDelete
  31. "As it stands, Ubuntu, OpenOffice & Firefox are the closest to getting mainstream press when they release. Most else gets left aside. Having an annual or semi-annual mega-release week would help everyone else."

    You are quite wrong. Syncing Ubuntu and Fedora and Suse would make things much *worse* for everyone else. Everyone, including the mainstream press, will be too busy gagaing and blogspewing over the new releases of the big distros to pay attention to the lone email in their inbox announcing release X of poor old, say, Ark linux.

    Their only chance is to release at a differing cycle, when Linux news is relatively slim.

    ReplyDelete
  32. > Anonymous said : "I think it's a shame that some oppose the idea simply because it comes from the Ubuntu camp."


    Is it possible to you to consider that sometime Ubuntu can be wrong ?
    Can you imagine another path than "you are with us or agains us" ?

    ReplyDelete
  33. As a unbias reader it appears to me there is allot of Ubuntu resentment.

    Outside the problems of slowing down the Internet and/or distrobution servers, I think syncing is a great idea. Distro release schedules, in my opinion, should be delayed behind the upstream projects. This would allow the distros to put the upstream projects in their beta products and allow the beta testers time to identify bugs and give the upstream time to fix said bugs. Once the distros are ready to finalize their products, the upstreams will have had time to fix bugs and provide a more stable product.

    A common concern is the overshadowing of one distro over another distro. Isn't one of the goals of the opensource community is to be the best of breed? Whether best of breed means better then M$ or between different distros/upstream projects? Opensource is making marketing inroads where M$ has been the monopoly for years. Opensource has made these inroads not by being concerned who is more popular, Opensource has done this by being best of breed.

    Opensource is also about freedom of choice. Everyone has the right to choose, which distro is correct for him/her. For those of you who complain that a schedule release is too stringent and does not allow for the new upstream projects to be made available fast enough; you have the freedom to choose a distro that has a faster implementation schedule.

    This may not be a new idea, but we as a community also have the freedom to create a repository that would create and/or store compiled upstream projects for the different distros. This would allow users using distros with long term support, to download the latest and greatest upstream versions. Thus, giving the distro developers time to work on the next release, giving the upstream the visability and availability they deserve, and ultimately giving the end user a more rounded and stable product to use.

    ReplyDelete
  34. Hi I've just wanted to let You know about new Ubuntu promotional website http://www.ubuntustory.com .

    Some time ago I've got an idea to add my small brick to Ubuntu wall doing what I can do best - by designing. I've prepared with my friend a website where people can read about Ubuntu and share their stories how they are using it.

    It would be perfect if You could mention about it on Your blog and of course share Your story by telling why are You using Ubuntu.

    Thanks in advance!

    ReplyDelete

Post a Comment

Popular posts from this blog

Using the Cisco console in Linux

What it takes to make Ubuntu ready for use

Reminder: Physical access = Root access