OLS: Shuttleworth on free software development

In the third keynote given at this year's Ottawa Linux Symposium (OLS), Mark Shuttleworth spoke about "The Joy of Synchronicity". In his speech, he discussed his idea of synchronizing releases between major distributions but he also advocated time-based, rather than feature-based, releases for free software in general. He believes that a release has value in and of itself; by doing them on a regular schedule, a project will get into a kind of cadence that is useful for both developers, testers, and users.

Before starting, Shuttleworth was subjected to the traditional introduction by the previous year's keynote speaker—James Bottomley, in this case. Bottomley looked at Shuttleworth's postings to newsgroups over the years, noting three year-long valleys in the graph where there were no postings. It turns out these corresponded to events in Shuttleworth's life. The first is when he received a substantial amount for selling Thawte to Verisign: "when someone is being productive on the mailing list, never give them half a billion dollars," Bottomley said. For the second, he has a pretty good excuse as he was not on planet earth; the last corresponds to starting Ubuntu.

In a nod to Bottomley and the other kernel hackers, Shuttleworth mentioned that he had been working on his slides up until close to the start of his speech, while doing some unrelated things in the background—like updating his system. That picked up a new kernel as well and he did a suspend to RAM when he was done; only later in the cab ride to the Congress Centre did he think: "maybe that was a mistake". It turned out to work just fine, which is a testament to both the kernel and to distribution update mechanisms.

The alliterative theme of the speech was that free software development should be guided by "cadence, collaboration, and customers". The cadence is a regular schedule for releases, similar to what GNOME—who pioneered this technique, according to Shuttleworth—and the Linux kernel do. This gets a project into a rhythm that makes it more predictable, which enables all interested people to schedule themselves around it. He compared this to various development methodologies such as "Agile" and "Lean".

Industries are governed by rules, so if you want to change an industry, you "have to find which rules are only in our heads". Cross-project collaboration is one of those rules. "Nowhere is it written that projects can't collaborate." It is harder to do that if each distribution is working with different versions of the various base-level tools: the kernel, X.org, GNOME/KDE, OpenOffice.org, Mozilla, and so on.

Shuttleworth contends that it is releases, rather than features, that bring attention to Linux. In answer to critics who believe that distributions should compete with each other, he says that is just "an opportunity to create friction." Free software companies don't compete on versions, but rather on philosophies and what things they focus on. He likens it to food courts or automobile sales malls where there are many choices in one location which serves to increase the sales of all.

For major transitions, Shuttleworth is a fan of establishing meta-cycles, the idea that every N releases is a major release, which may result in breaking some backwards compatibility or introducing completely new functionality, along the lines of KDE 4 or GNOME 3.0. As an example, he used a six month release cycle where every fourth or sixth was a major release. For a distribution, that might be a long-term support release, rather than a major change.

One of the key requirements that Shuttleworth sees is the need to "keep the trunk pristine", by doing integration on the trunk and feature development on branches. Along with this is the need for more and better tests. While not necessarily believing in test-driven development, he certainly leans that way. In any case, all the tests should pass before committing to the trunk.

Many projects do not yet have an extensive test suite, but this needs to change. He quoted a Chinese proverb that "the best time to plant a tree is 20 years ago, the second best time is today". He mentioned that he is working on a robot that controls the trunk of a development tree. Developers will request it to merge from a branch, so the robot merges the branch and runs all the tests. If the tests pass, it commits, otherwise it gets kicked back to the developer.

He sees distributions as "an effective conduit of upstream to users," to that end he believes that agreeing on versions of vital infrastructure can only help. Bugs that users find will be more likely to be fixed; those versions will also get better testing which will help developers. It is a conversation that free software should be having because it is a "very exciting idea" that won't work for every project but should be attempted and experimented with.

In answer to criticism about Ubuntu not contributing as much as other distributions would in his proposed synchronized release, Shuttleworth was adamant that it was not true. He hates to see the antagonism and vitriol between distributions. "We have much bigger fish to fry and they are probably not here today."

If all of the distributions were to standardize on a particular version of some project for their next release, what happens if that project falls behind? There are risks associated with that, Shuttleworth admits, but if it were happening, more resources would be available to help the project catch up. In the worst case, perhaps falling back to the previous version would have to happen. "Being tightly coupled has risks."

This is clearly an idea that Shuttleworth feels strongly about, not necessarily that it be adopted fully, but that it be discussed and considered. Certainly some of his ideas have a great deal of merit. We will have to wait and see whether the grander vision will ever be implemented.