Recently the issue of synchronizing open-source software releases has come up quite frequently. Stories are being written about it. Shuttleworth (founder of Ubuntu) has stated his opinion on the topic. Seigo (from KDE) has also given his input. Basically, the topic is becoming a point of a lot of discussion and controversy.

Before I launch into my ideas on the topic, what is the whole synchronization idea? (Feel free to skip this part if you already know.) The idea of synchronizing open-source software is that all the Linux distributions will release their new versions on the same day and upstream projects (projects whose code goes into Linux distributions) will time their releases according to the distribution schedule.

Now onto my ideas: The debate seems to come down to a single major issue. There may be side topics, but the core issue seems to be time-based releases versus feature-based releases. Time-based releases, as you may know, are releases based on a set time schedule. For example, Ubuntu does time-based releases, because they release a new version every 6 months. Feature-based releases, as you may also know, are where the software is not released until all the features have been implemented.

The advantage of time-based releases is that they offer predictability for businesses and software developers, goals to force the developers working on the software to keep moving, and easier scheduling of how long support for each version will last. On the other hand, though, time-based releases may discourage major new features and allow bugs to slip through the cracks and make it into the final release. As you can see, there is no clear best option.

So how is this related to synchronization? Synchronization would force projects into a time-based release schedule. This seems, at least to me, to be the biggest issue surrounding synchronizing releases.

Personally, although I don’t have a strong opinion, I think time-based releases are the best way to go because they make it easy to see that development is progressing steadily and encourage steady development. Also, with good management and the help of version control software, it should be possible to still introduce new features and keep bugs out.

Even though I prefer time-based releases, I recognize that it may not be the right choice for some projects. Initially, I made the argument that if the features were not ready in a piece of software or there were still bugs, that piece of software would just skip that release date and release at the next date. The problem is that a piece of software might finish with months left before the next release date. That is why I think optional OSS (open-source software) synchronization is the right way to go.

What I mean by optional OSS synchronization is that the projects that already use time-based releases would all synchronize, while feature-based release projects would continue with their way of doing things and their code would be incorporated as needed when it it possible. This would allow a major synchronization effort, without stopping the projects for whom feature-based releases work better.

Additionally, I suspect (correct me if you think I am wrong) that most of the projects that are serious about getting mainstream adoption will go with time-based releases, because of its appeal to businesses.

For all these reasons, I think optional OSS synchronization–having the projects that already use time-based releases synchronize while the others remain as they are now–is the best solution to the synchronization question.

This entry was posted on Wednesday, May 21st, 2008 at 10:32 pm and is filed under Bussiness, Development, Distros, Future of Linux, Opinion, Ubuntu. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.