February 23, 2019

Mark Shuttleworth's Radical Vision

Insane Persistence

  • October 1, 2009
  • By Carla Schroder
Mark Shuttleworth's Linuxcon keynote has gotten a lot of attention. Some for being the big Linux celebrity, some for making some unfortunate comments, and a small bit for his actual message. I'm going to report on his actual message because it is visionary and important. I recommend that anyone who is serious about devoting their time and talents to Linux/FOSS, in whatever capacity-- coder, designer, artist, documenter, translator, advocate, whatever-- watch this talk for yourself. Thanks to the generosity of Linux Pro Magazine and the Linux Foundation it is available online. You can also download it for local streaming: $ wget http://techcast.com/events/linuxcon/shuttleworth/shuttleworth.flv

Cadence, Quality, Design

Mr. Shuttleworth's three points are Cadence, Quality, Design, and they are all part of coordinated vision for the future of Linux development. It is a very different vision from how it's done now. The current state is very developer-centric. Software developers start and maintain projects, and the quality, responsiveness, and direction of projects are mainly controlled by the developers. Mark's vision is broader and more ambitious:

"People often ask me why I'm so fascinated by Free software , and why I put so much time, energy, and money into Ubuntu...I really believe the Free software process is the right way to build software. Not only that, but there is the potential, if we raise our game... that we could end up defining the experience that the average person has whenever they turn on a computer."

Ok, sounds good, so how do we get there? Cadence, the popular new buzzword, is about the value of timed releases:

"The release itself is enormously energizing...the release is the beginning of the journey for many other parts of the community and for our users. When you make a release it has all sorts of other benefits. It broadens the base of people who can participate...think of all the other people in the community who want to be helping you get your software out to the world: documenters, translators, artists, advocates...their job begins once you commit to making a release.

"It also generates a tremendous amount of testing...for every one person who is running a development version of Ubuntu, there will be ten people who download and try and work with the beta release. And then there will be a hundred people who actually use the final release...Short interations, shorter cycles mean more testing. They also mean better prioritization and planning...if you give yourself a shorter amount of time you say to yourself "What are the most important things for us to get done?

"A release brings publicity...we're doing amazing stuff. A release is an opportunity to get out there and talk about that..it brings more contributors, participants, users."

He used the example of a Web development team that has a monthly release cycle. The Linux kernel is on a three-month release cycle "which is magical...it is energizing." Gnome and KDE are on six-month cycles.

Cadence is also about coordinating with upstream and other projects. There is some progress in coordinating the next Ubuntu LTS release so that it will have the same base kernel and other key base packages as Debian. They're not quite holding hands and singing songs yet, but it's a start. He thinks that coordinating major releases will make life easier for users and distribution maintainers because there won't be so many different package versions floating around, and it will reduce the perennial conflict of who is responsible for a particular bug. (Users love reporting bugs only to be told 'Not our problem, report it to upstream/downstream/sidewaystream/anyone but us')

It will also help developers by reducing the numbers of distros to try to support, and enabling better collaboration and planning.


This is a potentially sticky subject to address because FOSS development is open and personal. The developer's name and code are there for all to see. Which theoretically leads to better software because devs are more accountable, have more reason to take pride in their work, and anyone (theoretically) can contribute.

He thinks that test plans and automated testing are good tools for quality control, and says there is a clear difference between projects that use them and projects that don't. Another benefit is opening doors to new developers:

"...a lot of upstream projects take the form of a couple of guys who know each other really well...it's really hard to cross the chasm from being somebody who is interested, and shows up and wants to talk about it, and maybe has some code to contribute, versus getting to the point where you're one of those guys...

"Maybe for some people it's part of the fun, you have this cabal effect. But I think it's hugely damaging to our ability to grow projects. Only people who are insanely persistent can cross that chasm. Whereas if you're more open to code that's coming in from people you don't know then it's really exciting for those guys, they get to contribute code...and it energizes them to do more."

Automated testing reduces conflicts and saves face because "You can't argue with the robot." It finds problems without pointing fingers.

Code review improves code quality and is another mechanism for bringing new developers on board, and there are programs for remote collaboration so they don't have to be in the same physical location.

He goes into a bit of detail on source control management, automated processes, checkins and checkouts, having a stable trunk, and other nuts-and-bolts aspects of software project management.

Most Popular LinuxPlanet Stories