Washington Monument

An Improved Ubuntu Release Cycle Strategy

You have two major goals in Ubuntu releases; features and stability. These are typically inversely related. Both are very important for the long term success of the distribution. Features are important for implementing the newest technology. Stability is what keeps users happy and establishes the Linux reputation, particularly in a business environment. Ubuntu needs a release scheme that blends these two goals in such a way that allows innovation without turning away users.

In the release schedule, stability should be your pulse. Everything should be based around Long Term Support(LTS) releases to make supporting them as easy as possible and to give the best user experience. A two year cycle would look like this:

Release
Stability
Feature Set
LTS
Ultra-stable
Stability Support Only
LTS+1
Stable
Maximum Technological Change
LTS+2
More Stable
Opportunistic Changes
LTS+3
Very Stable
Minimal Change

In this schedule, the feature cycle lags stability by 6 months. Stability is at its lowest at LTS+1 and increases until it peaks at the LTS of the next cycle. Feature changes are at maximum on LTS+1 and steadily decrease until LTS of the next cycle.

LTS, “Solid as a Rock” - LTS is the defacto Ubuntu release. This is the stable platform that the businesses and users desire and focus of the development. No new features, just focus on bugs and rock solid stability. Cadence with Debian, Gnome, Wine, and Open Office would be of utmost importance to achieve this goal.

LTS+1, “The Wild West” - Disruptive development should be targeted to LTS+1 to give it the longest possible testing cycle before the next LTS. If a particular technology misses it's deadline, you can retarget it for LTS+2 but no further. LTS+1 branding should also reflect the pioneering nature of the release. The naming concept should reflect its wild and woolly nature; Manic Macaw, Nutty Narwhal, etc. Something that lets people understand that it's definitely Ubuntu, but the training wheels are off. This is important to set users expectations appropriately. The concept of a technology preview should be avoided as this would give the impression of a beta release.

LTS+2, “No Bug Left Behind” - This release would reflect the technological flow of the community. LTS+2 would consist primarily of opportunistic changes to the distribution and a focus on bug resolution. A particular focus should be on old bugs. Many of these have languished for years. Some of these require big solutions, so begin here where the disruption would be less noticed. It could serve as a defacto point release for LTS+1, focusing on major issues from LTS+1 and incorporating opportunistic technology changes. Feature sets that couldn't be fully implemented in LTS+1 should be completed by LTS+2.

LTS+3, “Bring the Bling”- LTS+3 could have a particularly interesting purpose by focusing on non-programmatic feature changes to the distribution, such as graphics, themes, translations and documentation in addition to bug resolution. The graphics and sound tweaks would minimize the impact to stability and give users something tangible to grasp. The artistic community could be included by incorporating contests to judge new wallpapers, sounds etc. This media would have to be creative commons licensed and users could vote on what to include in LTS+3. Paper cuts could be expanded for this release as well.

There would be marketing potential based around this type of release cycle. You immediately have the buzz of a stable release, which will be of interest to the business environment. This will be followed 6 months later by the interest in the power users community for the technology release. LTS+2 would also appeal to the power users for the resolution of old bugs. LTS+3 would have the eye of the entire community, particularly those talented individuals that want to participate, but don't program.

The one-two-three-four punch in this release cycle concept could serve to amplify interest in the open source movement. If this concept proved successful, other distributions would likely reassess their position on community cadence. A unified community would befit from both the cadence of software development and the buzz associated with biannual “Linux Days”.

 

Blog Articles Publications Talkback About Archives
©

home Essays Publications Blog Feedback About Me