The open source world is currently debating the merits – if any – of synchronising the release schedules of several of the bigger, key projects that make up a Linux distribution. The discussion was started by Canonical’s Mark Shuttleworth, and continued as a back and forth between the Ubuntu leader and KDE’s Aaron Seigo, but of course other members of the community discussed right along on blogs and other venues. Sander, developer of Coccinella (an open-source Jabber client) provides some insights into the whole discussion.
“What do Stevenotes and Windows launch events have in common?” Sander wonders, “Yes, they both result into a flood of publicity. When Steve Jobs speaks, pregnant women’s magazines write about it. When Microsoft spends a little money, the television journal will show us impressive fireworks that make New Year’s Eve look like a non-event. All media eagerly report about these happenings!” I can personally attest for the amount of power these events have, which go far beyond a mere mention on the news. In The Netherlands, the quite popular early evening talkshow De Wereld Draait Door became the centre of the Windows Vista marketing blitz, and with that, the centre of a minor controversy. The show was more or less a company presentation by Microsoft, which is rather unusual for Dutch public television (for a quick rundown of The Netherlands’ intricate media landscape, read this entry on my personal weblog).
This caused quite the stir, since the Dutch media, and the tax-funded ones in particular, are bound by certain rules and regulations to ensure tax money isn’t wasted. It was said that the show in question about Vista had broken these rules, but the government body overseeing the media landscape, in the end, decided this wasn’t the case, and didn’t impose any penalties.
Still, it is clear that Firefox, Ubuntu, Apache, or whatever other volunteer-based open-source project is not going to be able to use Dutch television, or any other country’s television for that matter, as a platform for such a product presentation. According to Sander, the open source world shouldn’t strive for that – it should leverage its strongest asset: the community. By synchronising release schedules, the open-source world can create a sort of publicity wave among the web.
Community is in what we excel; our key strategic advantage. To repeat the marketing success of Apple and Microsoft we need to leverage the community. Massive synchronized releasing is the perfect tool to achieve this leverage. By synchronizing, release related marketing efforts of multiple communities are focused at the same moment and can leverage each other. The rhythm of so much projects doing their marketing efforts at the same moment will shake the Internet. I’m sure the pregnant women’s magazine and the television journal will feel these shakes…
Beating Apple and Microsoft, marketing-wise, on their own turf is going to be quite difficult. Microsoft’s pockets are always deeper, and the open source world doesn’t (seem to) have a Steve Jobs and a devoted clapping crowd. As such, it makes perfect sense to focus on what you do have: a technically adept community with lots of blogs, IM friends, irc access, and so on. What do you think?
I don’t particularly care for the publicity factor of synchronizing releases like that. What i’m after is the result of doing so, because as it is right now, most distros ship with way too much alpha quality software, just because they cant seem to hit the sweet spot that very often.
Suppose one project is unquestionably ready on the date, and the other project is not, for example of the issues Fedora 9 has with KDE 4. Should Fedora have delayed however long it took for KDE 4.1 to be ready? or should KDE 4.1 have been “given” more resources by Mr. Shuttleworth (or someone at the Fedora project) in order to meet Fedora’s deadline? What would serious coordination mean in this world?
So this strikes me as a really bad idea. Maybe this is not what he is getting at, but artificial deadlines seem to be part of the problem with Windows; some wit on this website remarked a while back that at the time Vista was released, all of its promised major features was present in each major OS except Vista. Having rollouts may be fun and enjoyable and leave everyone with good feelings for a week or so, but in the long run the current model is much, much better.
This goes on now, and what happens is the first project takes what it has, applies some quick and dirty patches to get it more or less working, then shoves it out the door. Very common practice, what ends up happening is distro specific issues and bugs.
Slackware is one of the few that doesn’t do this (note that pat still hasn’t released slack with kde 4), and actually (gasp) waits until a project is ready for prime time before releasing it.
If projects at least aimed for a regular, synchronized release cycle, it would make the distros life easier. I mean, even if a project isn’t ready, it could hardly be worse then the situation is now.
KDE, in this case, should say, with plenty of warning, that they won’t make the deadline and Fedora should then plan to make their next release without the latest KDE version.
Let’s say that software projects chooses the 1st week of April and 1st week of October as their release dates and distors 3rd week of April and October (distros projects wouldn’t need to release every 6 month of course and could skip a date if they felt the need) . Then all the distros would know by March and September what software they would be including. And they would also know that they will have at least two weeks for testing and integrating the final version of each project before release.
I don’t think that two weeks is enough time to do proper testing. Why not do a Ubuntu-style release schedule that closely follows GNOME about a month after the release of a new version of GNOME? GNOME release in March and September and then Ubuntu releases in April and October so I guess they already do what you are asking. Surely Ubuntu takes longer than two weeks for their release. I personally would prefer they wait for the 2.x.1 version in order to fix anything that may have been initially missed.
Currently KDE is on a January/July release schedule.
Well I’m assuming the distros are closely following the daily snapshot/beta/RC progress of the packages in question so most of the problems should get taken care of continuously at those stages. The two weeks will be the time they’ll have to test the final version of the software and to catch anything they missed or has changed since the final RC.
I have no interest in the political advantages of a patch tuesday or a Distro April. Delaying or rushing a project too meet someone’s political mandate just seem slike a poor idea.
What does interest me is technical merits. If such a community wide release schedual provides me with a higher quality base platform to start with plus the ongoing daily updates we enjoy now; I’m more interested.
All in all, I’m still undecided as I’m only effected by the end user benifits. The developers who have to work within the framework will need to discuss that side of it which seems to be what they are doing now.
Lets face it, as far as most end users are concerned the only ‘real’ update to a distro is either the Kernal or DE being updated.
An upgrade must be something tangiable to the end user. Try to think of it as if it was a new version of windows or osx.
Firefox reaching v.3 != Fedora 10, for example
I would recommend release cyles based on DE
KDE 4.0 = new version
KDE 4.1 = new version
The drawback of this is of course that v10 kde may not be release the same time as v10 gnome. This would encourage distros to be DE specific. Is that good or bad? Thats a new thread :-p
Perhaps a select number of release dates could be chosen for everybody to shuffle about a little to meet. A compromise as it were.
Have January, April, July & October as standardised release months, and have everybody shuffle up or down a month or two so that everybody benefits from a larger number of releases occurring at the same time, rather than a month or two apart, and thus slipping past a DE release (*ahem*Firefox3*ahem*).
If both Ubuntu & Firefox had chosen a standardised July release instead of barely just apart, they could have shipped together.
That will only lead to halfbaked apps being rushed out in order to meet a release date or things being left out.
Can’t those people learn from microsoft how you don’t do things.
One of the great advantages of free software is that it is decentralized and now this is supposed to be replaced by a central release commitee run by whom?
…as opposed to half baked apps getting a few quick and dirty patches and rolled into a distros release cycle?
Yeah. Is failure to release on a schedule a good release policy? Or poor release planning? Good release planning starts when the feature set is determined, and before the first patch goes into the dev repository. Resistance to a project schedule is often a sign that the project devs have a poor level of discipline.
synchronizing all those teams for marketing reasons?
I think it will slow down development. A lot of energy will go to synchronizing all the different releases. There are some typical organization that do this kind of big bang synchronizations: MS, Apple (osx delay?), …
If open source development is taking this route, they are competing more and more on the terms of the commercial organizations. The chaos inherent in the heterogeneous and smaller organizations will need to be “ordered”. In nature the more ordered the more energy it costs. I think that is just the same here.
bye
roel
Edited 2008-06-30 16:10 UTC
I think so.
Having the different distro’s release on different dates in IMHO a good thing. You get effectively a system of continuous improvement. If distro A find a problem in package, Distro B can put the fix into their release and so on.
Now, if we think of the problems that ISP’s are going to put in the way of the huge increase in Torrents is the likes of Ubuntu, Fedora, SUSE & Mandiva (to name just a few) all release on the same day. How much throttling will they apply to downloaders?
Having the releases appear at different times means that people can try out a new release of a different distro at regular intervals without having to decide between the latest & greatest release of Fedora, SUSE etc and then waiting possibly days for the download to complete.
I don’t see why it has to be “one way” or nothing? What if you could, say, have 4 synchronizations a year, so that whatever distro want to release at such a time can do so at their own choosing.
There is no need to shove this down the throat of developers that don’t want to be a part of this, but it could help stabilize the majority of the open source eco system.
Personally, I think Ubuntu should switch to a release branch and a stable branch of their dev tree. The release branch would stick hardcore to the main version of the big apps / kernels it was released with. The stable branch would allow for updates of items like xorg or KDE 4.0 -> 4.1 or firefox 2 -> 3, etc…
This way they can do their release cycles and still allow for larger items being upgraded.
Probably means more testing on their part and maybe it’s a political thing since they want to force the major releases on people.
Maybe ubuntu should do 3 trees instead and call them Stable, Testing and Unstable?
Ubuntu is pretty much a second testing tree of debian as they go for the latest packages rather being a 2nd etch.
I think that KDE and GNOME should synchronize their release cycles to occur in the same month. Currently GNOME releases in September and March and KDE releases in July and January. It would be helpful if they released at the same time I believe as it would enable more collaboration on their part. Are there disadvantages to having them release in the same month that I’m just not seeing? Would collaboration and standardization (FreeDesktop.org and LSB) be better or worse with a same-month DE release synchronization? Are there any good opinions about why they should or should not be synchronized?
Edit: Accidentally posted early!
Edited 2008-06-30 17:30 UTC
In what sense would synchronizing development releases be helpful? And helpful to whom?
There is a risk here that it would be most helpful to the marketing department, which would naturally like to take a fairly complex product and reduce it to “The Blingtastic Latest and Greatest”. Because that’s easy to sell and failures of the strategy can be blamed on upstream – we can only sell what the devs give us by date x, etc.
I’m not arguing against synchronization, just pointing out that there are commercial pressures here that aren’t all that healthy. Thus do marketing folks get further and further through the door of what developers actually develop.
As someone has wisely already said, “ready for release” and ready for prime time are not the same thing at all. The first can easily be twisted into a marketing call. The second means sticking your rep and judgement on the line. It also means sticking up for your users. It’s quite hard to say, with some recent distros, that inflicting, say, Pulse Audio in its present state on your users is really giving them something that’s ready for prime time rather than going with marketing and “ready for release”.
Helpful to users and projects.
Synchronised release cycles allow people to plan.
Users can plan upgrades. Users can plan on having certain hardware support or other functionality available.
Businesses can plan rollout and release cycles. They can plan for training, etc.
Other developers can plan on depending on certain functionality being available because they know X is available in Y on Z date.
I don’t know why the “open source” world thinks they are somehow exempt from the last 50 years or so of software engineering and release principles.
Every major commercial successful product launch involves a lot of planning.
Given Ubuntu’s success, it should be obvious how great of a benefit release planning can bring.
The problem isn’t with synchronized releases, it’s with synchronized non-releases – the dead spot in between major pushes of user-facing software puts less pressure on companies to keep the ‘latest and greatest’ going (like fedora 9’s pressuring ubuntu on more than a few technical fronts.) Yes, the development is still going on behind the scenes, but it’s harder to ‘point to’ what features users might find important for the next release, if no mainstream distro has it.
make a system thats robust enough to have major parts upgraded without having to basically build the house of cards all over again…
and the simplest way to do that? have the ability to install multiple versions of libs side by side…
when you have that you can pop in a new DE side by side with the old, use apps from the old until a replacement comes along that works with the new DE, and then clean house.
that housecleaning bit is what most os get wrong when they have the multiple lib versions right. end result? leftover libs and other files that no-one knows where belongs…
“…nd the open source world doesn’t (seem to) have a Steve Jobs and a devoted clapping crowd.”
No, but what about Ubuntu’s Mark Shuttleworth? He’s not Steve today, but he’s got some charismatic features, and maybe he’ll get better.
(Steve Jobs wasn’t always the talented presenter he is today, people improve.)