The latest release of Canonical’s innovative open source operating system, Ubuntu 12.10, maintains its twice-annual upgrade pattern. Even though the last few releases have generated a steady chorus of cries for longer release schedules, Canonical’s leadership stands by the schedule and the rationale behind it.
Canonical CEO Mark Shuttleworth certainly does not think Ubuntu’s every-six-month release schedule is part of any ill-perceived problem. During his recent Linuxcon keynote address, he praised that cycle for creating lots of excitement and keeping contributors motivated.
At least one of Canonical’s board members favors longer release intervals. Meanwhile, Shuttleworth steadfastly adheres to the mantra: Many eyes make all bugs shallow, so make releases early and often.
Contrary to the criticism, Ubuntu’s twice-yearly release cycle has a clear purpose for Canonical’s success as a major OS developer. It forms a cadence with several upsteams and other distributions, according to Adam Conrad, Ubuntu Release Engineer at Canonical. That helps the development team keep its fingers on the pulse of current open source development.
“We’ve put robust mechanisms in place to ensure quality, both with our own products and with various upstream products that we rely heavily on. Our focus on quality permeates from the platform up to the code we write upstream, and our choices of upstream components too. We require tests and gated trunks for all Canonical code bases and prefer upstreams that share the same values,” Conrad told LinuxInsider.
That explanation makes considerable sense, noted Al Hilwa, program director for applications development software at IDC. Fundamentally, it is an execution and planning issue.
“What is important is putting out a predictable schedule and a road map for when projected functionality will be integrated,” Hilwa told LinuxInsider.
Whether Ubuntu needs to adjust that cycle is the sticking point, however. The development team has to assess the nature of the code changes versus the intervals available to stabilize the code.
“In principle, most changes can be incrementalized to fit any cycle,” Hilwa suggested.
Extending the release cycle would not necessarily lead to better overall quality. Rather, it would only give people a longer goal to land the new features they really want to see, in Conrad’s view.
Another reason he disfavors a more relaxed release time is human nature. Ultimately, people will always try to get things in at the last minute.
“We do offer our LTS [Long Term Support] product on a two year cadence, and we invest significant resources into polishing our LTS releases both before and after they’re released to make sure they’ll be solid and maintainable for five years,” he explained.
A longer release schedule would have little impact on quality, Conrad added. Every release puts quality first these days. They all get used on the server and on devices.
The term of maintenance between regular and LTS might vary. Nonetheless, the company’s commitment to interim releases is just as important as it is to an LTS release, he noted.
Time may be less of a factor than management goals, offered Hilwa. The issues boil down to project management dexterity.
For example, a development team has to come to terms with the natural rhythm of evolution of its product with respect to the market requirements. Release schedules can then be worked out to accommodate these needs.
“Mature products are more easily delivered on a predictable schedule. New products with significant new investment can require irregular intervals, for example, to stabilize major changes,” Hilwa said.
Rhyme With Reason
The release cycle is often tied into the marketing plan of a Linux distro. Many Linux distributions have a regular release cycle. A few, such as Puppy Linux, only release new versions when the community has time to build in enough new features or make substantial bug fixes.
Fedora Linux follows a similar time frame to Ubuntu. A new version of Fedora releases every six months. But there is no LTS version. Maintenance for Fedora releases lasts 13 months. So users of a Fedora distro one year old needs to move on or be left behind.
So Canonical might gain traction for some personal users and lots of business adopters simply because they can coast along without orchestrating an upgrade deployment for two years when a new LTS version arrives.
Meanwhile, regular security and bug fixes are fed through the software management mechanism of the distro. Those who want the next new thing can upgrade sooner, even if they have skipped one or two release cycles.
Most of the more well-known Linux distros seem to avoid short-cycle releases. Besides Ubuntu and Fedora, the only major distro that comes close to sooner-than-later releases is OpenSUSE. That community issues a new release every 8 months.
Linux Mint uses an annual upgrade cycle, but it maintains recent generations for extended periods and preaches that upgrading is not necessary.
Red Hat Enterprise Linux, SUSE Linux Enterprise and CentOS upgrade every two to three years. Debian Stable comes out anew every three years. PCLinuxOS and Gentoo Linux follow an imprecise rolling release cycle.
Serving Two Masters
One of the big attractions of the Linux OS is its ability to play nicely with diametric user groups. The dual audience for Linux distributions pits the unpaid, community versions as a complement to the paid, subscription Linux users, according to Jay Lyman, senior analyst for enterprise software at The 451 Group.
“The dual audience seems to consist of those who want the latest and greatest features and functionality in a new version, new Linux kernel and other updated components and those seeking stability, reliability and commercial support,” Lyman told LinuxInsider.
In Ubuntu’s case the company’s regular, twice-annual releases satisfy the first group. Those are mostly developers. The LTS releases serve the second group, which includes large enterprises and service providers, he explained.
Long or Short: Is One Better?
Shorter and longer release cycles give fairly obvious quality versus shininess trade-offs, offered Conrad. Ubuntu’s developers try to balance both so as not to short-change either audience.
Ubuntu’s code-writers work hard to ensure that quality shines through on every release to give users access to the latest and greatest software and features, he said.
“Moving to even shorter cycles, while often heralded as the next best thing in software development, is not particularly realistic for a system as complex as a large Linux distribution,” said Conrad.
That would force Ubuntu’s team to spend so much working on the release processes and stabilizing inter-dependencies that the team would never actually get a chance to land many new features, he explained.
One Size Can’t Fit All
“What works well for development of smaller and self-contained software projects doesn’t necessarily translate well to releasing an entire operating system,” said Conrad.
In assessing the advantages over the disadvantages, there is no escaping the balancing act. It might require one part marketing and one part determination. In the end, the customer will walk away or stay.
“Fundamentally it is an approach that aligns the software release cycle with a faster pace of customer demand such as in a consumer cycle or to simply incrementalize software evolution in order to speed functionality to market or provide it in a more predictable way,” said Hilwa.
Fixed vs. Floating
Is such a fixed cycle necessary at all? After all, users can update or not at any time they choose. So what is the rationale behind the decision in the first place?
Fixed cycles — or, at least, fixed stable releases — are necessary for users who absolutely must have a baseline and stable system on which to develop their own solutions, according to Conrad. “For instance, being quirk-for-quirk compatible over a five-year period — in the case of LTSes — lets shops add their own internal ‘secret sauce’ to their rollouts without having to constantly update and track our development.”
On the other hand, single-desktop users can more easily follow a rolling release model, if they so choose, noted Conrad. Ubuntu is increasingly getting to the point where its development release is a product that is always in good-enough shape that even non-technical users can be confident upgrading it on a daily basis, he added.
Which Way to Go?
“We may not quite be there yet, and I’m not sure I’d recommend our development releases to people who aren’t occasionally prepared to file some bugs or deal with some oddities. But our goal is certainly to make this a viable option for people who don’t want or need stable releases,” Conrad concluded.
Generally, software product release cycles can be feature-based or schedule-based. Increasingly, Hilwa is seeing a shift to schedule-based approaches as technologies move to cloud provisioning in an attempt to provide continuous services.
Additionally, the fast pace of technology has driven many categories of software to schedule-based releases. That is especially true as more of the market shifts to the consumer side, which is governed by a distinct retail commerce cycle, said Hilwa.
Need For Speed
Clearly, the cadence of release in Linux and other open source software projects can be overwhelming for enterprises. Still, LTS and paid subscription versions of Linux provide greater longevity and less worry about updating, concluded Lyman.
“While open source software is being used more and more in the enterprise market, where you would expect longer release cycles, the overall trend in the industry is to iterate, update and release software more frequently. So I expect this duality to continue with both approaches retaining their advantages for different sets of users,” he said.
The first Unix I saw was AT&T UNIX Version 7 and BSD 4.2 in 1979. These came on 1-2 inch open reel tapes holding 140 MB each. So I know the shell and in those days had to compile from source. I worked for Sun later and supported sys admins, so I know what release cycles mean to customers who have the power to demand patches and back ports.
Many of the current Linux distros seem to be plagued by the limited vision of their designers or even a personality cult, rather than a real awareness of what kind of need is being fulfilled. This is why Microsoft in particular has a considerable advantage. I advocate Open Source with the belief that when something goes wrong I can get accurate information from the system and that I will have to do a little work to document and report a bug. I also trust that the vendor will be reasonable about stability and patching.
I know that Canonical has an engineering staff of limited size because I worked with a similar group at Sun. Someone has to decide what can be supported and not; but we had to stay in touch with our customer’s needs and not change things that had a legacy.
I have figured out why Canonical went so fast for UNITY. It was to support a GUI design that would work on small screens, on tablets and smart phones. I know that it isn’t practical to use an xterm on a small display, and it may be the case that most people won’t have desktop systems in the future, but there will still be plenty of legacy systems and servers, many headless, for years to come, so in fact even just a text login with a shell may be important for some time to come. I know first-hand that even keeping a working FORTRAN compiler was significant revenue for Sun as late as 2004. In fact it may have yielded as much income as Java.
There are several Linux and Ubuntu trends I would like changed. First is that error logs of the type that are handled by the syslog must be supported by every application, secondly that documentation be consistant, that man pages be kept up to date.
The problem I have with Ubuntu’s Update Manager is because it works like a similar tool at Microsoft and hides information from the user. The philosophy for Linux should be less information is bad, even if it is too much for the novice. Users must learn what it needed for a bug report: System version and error messages. At
Sun we had automatic tools that added the system logs to a bug submission,and quite often we could completely trouble shoot hardware failures from these alone.
Linux could take more market share on desktop systems from Microsoft but it has to be much more bulletproof than even Ubuntu is now. I would do things differently at Ubuntu. I would concentrate on a rigorous error and bug reporting system and concentrate less on sexy GUI stuff. And I wouldn’t be so agressive about being bleeding edge. The mistakes at Canonical with GUI issues and the resulting bugs has hurt both Ubuntu and Linux.
I took the trouble to get an account here when I saw the article on Ubuntu release cycles and bug fix policy. First, I have been using Ubuntu since 8.10 and having tried to upgrade from 10.10 to 11.04 I am ready to change the distro I use. The reason is that I do find that the release cycle is too fast and installs fall out of support too fast, not only did I lose functionality due to the move to UNITY and the fail back to Gnome Classic with a change to the file manager but I filed a bug on the Upgrade Manager because it failed on unsupported packages it didn’t identify, and the only feedback I’ve gotten is that my distro version is unsupported and no reply on the bug against the upgrade manager which prevents me from getting to a supported version. I feel the hype especially in the UK Linux Magazines like Linux Format is just that. I am quite angry with Canonical right now.
"Many eyes make all bugs shallow."
I can’t believe anyone can really stand by this old and broken record. It’s been debunked so many times that can only be believed as a matter of some sort of religious faith.
Moreover, it really doesn’t matter how many eyes can see the bugs, when nobody is able or willing to fix them. Check some outstanding bugs at Launchpad and Shuttleworth’s own attitude about them and see for yourself.