By Jonathan Corbet
June 14, 2010
Your editor had the pleasure of giving a keynote talk at the 2010 LinuxTag,
immediately prior to Mark Shuttleworth's keynote - a position described by
more than one person as being Mark's warmup act. That role must have been
successfully carried out; Mark's talk was, indeed, well received from the
start. Topics ranged from the familiar (cadence) to issues like quality,
with a look at upcoming Ubuntu design features as well.
Mark described his (and Ubuntu's) job as taking the great work done by the
development community and getting it out there where people can use it.
There has been a lot of progress on the development front, resulting in a
great deal of top-quality software. But that's not where the job stops;
getting that software to users, Mark says, is "a whole new level of
awesome." Achieving this new level is his objective.
"Cadence" - the regularity and frequency of releases - has been one of
Mark's talking points for a while. The conclusion that he has come to is
that releases are important, they have value in and of themselves. It is,
he says, more important to get a release out than to have any specific
feature included in the release.
Why is that? Releases draw attention to the project and generate
enthusiasm among users. Releases also can help to keep the entire
community busy. Developers can run with something like a 100% duty cycle;
there's always stuff to hack on. But other community members - packagers,
documentation writers, artists, translators, marketing people, etc. -
really need a release to focus their energies around. Regular, frequent
releases thus keep the whole community engaged in the project. They are
also something which free software is uniquely capable of doing:
proprietary software releases are much more feature-driven and cannot be
done with the same kind of regular cadence.
For a while now, Mark has been pushing the idea of a coordinated cadence
across multiple projects. Quite a few projects, he says, are headed toward
something like six-month release cycles; why not try to coordinate them so
that distributors can all focus on the same specific releases? That kind
of coordination could help projects focus their work knowing that a certain
release will be picked up and widely distributed, and it should help
distributors to minimize duplicated effort and get the best of what the
development community has to offer. In terms of progress, Mark says that
Ubuntu is getting closer to proper release cycle coordination with Debian,
but no further details were offered.
Quality is another theme that Mark's talk covered; he urges the community
to start thinking differently about the quality of its code. When the
focus is on "hero developers," he says, quality tends to take a back seat.
He would like to see a stronger focus on everyday quality in development
projects, starting with broader use of automated test suites which, he
says, are "made of awesome." The core rule for these projects is that the
development trunk should pass the test suite after every commit.
This kind of discipline may not sit well with all developers. But there is
a key advantage to a "pristine trunk" which always reaches a minimal
quality bar: it encourages users to run and test development code. Ubuntu
has been increasing its building of bleeding-edge packages for a number of
projects; the result has been a "ten to one-hundred times increase" in the
number of people testing those programs. A good set of regression tests
also makes it more likely that a project will take patches from unknown
developers; passing all the tests gives a level of assurance that the patch
cannot break things too badly.
Mark also touched on automatic crash reporting as a highly useful tool for
distributors and developers. The crash reporting tool can gather all of
the relevant information and ship it off to the people who are best
equipped to interpret it and, hopefully, fix the problem. Code review was
also favorably mentioned, with the tools provided by Launchpad getting
special attention. Such tools, he says, broaden participation in the
development process and help to create a wider conversation about what's
acceptable in a code patch. That, in turn, helps new developers to get
started with a project.
Finally, Mark is pushing to see more attention paid to design in free
software. Proper design makes the software more appealing to "ordinary
users," and thus will increase their number. It can also increase pride
among developers. But doing design right is a challenging task; it's not
something that can always be done by developers. Mark talked a bit about
the design elements which have gone into the Ubuntu Notebook Edition,
including the infamously moved window icons, the creation of notifications
which don't take up screen space, "category indicators" which can indicate
status (and provide controls) for a number of related applications, etc.
The result of all this work is a lot of new code which, he hopes, the GNOME
community will be willing to accept into its mainline.
The next release is Maverick Meerkat, which Mark suggested is the "Don't
panic" release. Why? Well, it seems that they've moved the release date
forward slightly to October 10, which has the effect of balancing out
the year's two development cycles a bit. But the binary 10/10/10 release
date has appeal to hacker types, especially when one realizes that
0b101010 = 42.
Looking toward the future, Mark put up the famous chasm
diagram by Geoffrey Moore. This diagram is a bell-shaped curve showing
product adoption over time; there is, however, a gap between the "early
adopters" and the majority of users. Getting across that gap ("chasm") can
require changes in how a project is developed and marketed. Mark says that
Linux as a whole still needs to cross that chasm, though specific
components (the kernel in particular) have already done it.
What does Linux have to do to get to the other side? Preinstallation was
at the top of Mark's list; users need to get devices which have Linux
already installed on them. He also says that "obvious things should just
work," where things like codecs are considered to be "obvious." We need to
provide these features, but we cannot stop caring about freedom in the
process. As a
result of its efforts, Mark says, Ubuntu will be shipping preinstalled on
five million machines this year.
Some of those machines, most likely, will be running Ubuntu Light; this is
a stripped-down distribution meant to run as an "instant on" alternative on
Windows machines. Ubuntu Light can get a user into a web browser within
seven seconds of the power being turned on - useful when checking a web
page is all that the user wants to do. To get there, Ubuntu Light has very
few applications and no real file management. But it is a place for users
to start, to discover a bit of Linux, and, hopefully, develop an appetite
to delve into it more deeply later on.
Another area of interest is ARM processors. To Mark's surprise, the
ARM-oriented sessions at the Ubuntu Developer Summit were packed; there is
a lot of interest in this architecture. The Linaro initiative was mentioned
as an effort to make Linux work better on ARM-based systems. There is
also, evidently, a growing level of interest in ARM-based servers; that
should be interesting to watch.
There was also a brief mention of cloud-oriented endeavors. "Ensemble," a
way of packaging and deploying cloud-based servers, was mentioned. Also,
evidently, Ubuntu is working on a project using LXC containers to run containerized
systems on Amazon EC2 guests. This second level of virtualization,
evidently, is useful for people wanting to run a number of services while
buying only a single virtual host system.
After the end of the talk, a member of the audience asked Mark about when
(if ever) Canonical might
open-source the Ubuntu One server
software. Mark answered that he doesn't "have an answer on how to do it
and make it all work." One gets the sense that this release will not
happen anytime soon. Mark did try to point out that freedom has been
designed into Ubuntu One, even if the code is not free. In particular,
Ubuntu One doesn't just make sure that users can get their data out; all
data is stored locally as well from the outset. So users should not worry
that they can be trapped in the service.
At that point, the standing-room-only session came to a close.
(
Log in to post comments)