When Mark Shuttleworth talks, the free and open source software (FOSS) world listens.
As founder of Ubuntu and its commercial arm Canonical, he heads the most popular Linux distribution in the world. Even more importantly, he is an articulate and innovative thinker. For these reasons, he was a logical choice for the closing keynote at the first LinuxCon a couple of weeks ago, and his view of what free software needs have been widely reported.
However, what few people seem to have done is analyze his keynote for accuracy, or to ask what interests his vision represents.
I am not referring here to the sexism in Shuttleworth’s speech, in particular the remark about “explaining to girls what we actually do.” The implied exclusion in the remark is a legitimate concern — which I share — but the issue has already been dissected at length.
All I can add is that I am disappointed that Shuttleworth refused to apologize, but I feel that he partly redeems himself by the fact that Canonical CTO Matt Zimmerman can publicly disapprove of his comments without facing any retribution.
Instead, I would like to focus on the topic of Shuttleworth’s keynote. For the most part, Shuttleworth repeated the ideas that he has articulated on his blog over the last few years, with some of the details updated. In order for free software to grow, Shuttleworth says, it requires improvement in three areas: Cadence, or the coordination of releases from major projects; Quality, in particular the coordination of rigorous testing and quality assurance, and Design or human usability.
Shuttleworth gives technical suggestions about how free software can improve in these areas, and emphasizes that improvements in these areas will attract both developers and users to free software. You can read more detailed summaries of the keynote by Carla Schroder and Brian Proffitt.
On the surface, Shuttleworth’s suggestions are hard to dispute. However, as I analyze his keynote more closely, I wonder whether a couple of his suggestions may not be in the interests of free software, even though he clearly meant them that way. Still others seem to be more in the interests of particular sections of the community than those of free software as a whole.
Conditions of software development
Over a dozen years or so, I have worked with some fifty companies as a consultant on software projects. This experience has left me with a strong sense about what works and what doesn’t — and a couple of Shuttleworth’s comments, while meant to improve free software development, seem likely to create as many problems than they solve.
One of Shuttleworth’s arguments in favor of regular releases over a short period is that releases “energize” a project. He says that, in addition to exposing the software to far more users, a release is the time when documenters and translators begin to work.
In fact, technical writers will tell you that the time of the release is the very worst time to begin their work. Starting to document or translate with a release means that the work is under pressure to be completed as soon as possible. It also means that those doing the work may have a hard time finding developers to answer questions, because, their work being finished, they are taking time off.
Both quality and usability — Shuttleworth’s other concerns — are generally better served when documenters and translators begin their work with the alpha release or sooner.
Similarly, Shuttleworth talks throughout the keynote as though attracting more people to a project is an unmitigated advantage. However, anyone who has worked on a software project can tell you that an increase in the size of the team does not automatically translate into more getting done.
In fact, more people can actually decrease a team’s efficiency, especially in the short term, as others take time from their own responsibilities to bring the newcomers up to speed and the newcomers gradually find their place on the team. The insularity of smaller projects is not always just a matter of poor social skills — often, it can be the most efficient way to work. If everyone on a team is experienced, then you need less communication and coordination is easier.
In both these cases, Shuttleworth seems to be viewing increased participation as a desirable end in itself. However, the situation is more complicated. When and how more people get involved can be even more important than the mere fact of their involvement.
Linux for whom?
Throughout his keynote, Shuttleworth talks about Linux as a whole. However, when you think for a moment, his views are those of a particular segment of the FOSS community — naturally, the ones to which he, Ubuntu and Canonical belong.
The first clue to Shuttleworth’s perspective is that all his examples are based on projects that are conglomerations of many projects — either distributions like Ubuntu or desktops like GNOME or KDE. He is talking about large projects that are sub-divided into many little ones. I have to wonder, though, whether smaller projects or less diverse ones like OpenOffice.org would benefit from cadence as much as other distributions.
The second clue is Shuttleworth’s emphasis on cadence. This is a subject that would almost certainly seem less important to a community developer. Commercial developers see an obvious advantage to regular releases because they make bringing a product to market easier. By contrast, community developers are less likely to see the need.
Community developers may even worry that keeping to a regular release schedule can conflict with quality. That is why the most community-oriented distributions, like Debian or Fedora, either resist cadence or quickly let it slip when problems emerge.
By contrast, an attitude of “I don’t want it good, I want it Thursday” is all too easy to fall into if you a commercial developer. Everything from shipping to marketing and publicity depends on the software being ready in time.
In fact, Shuttleworth’s speech is riddled with words that indicate that his main concern is business. The name of the keynote is “Coordinated Software Releases, the Linux Ecosystem, and the Impact on the Global Marketplace.”
Moreover, several times he uses managerial and marketing buzzwords. For instance, while he talks about “the free software process” of development, he makes it synonymous with “crowd-sourcing,” a related phenomenon, but one that tends to be more controlled from the top down. He talks, too, of the need to “go from good to great,” echoing the title of a business best-seller released a few years ago, and refers to “taking free software to a larger consumer audience,” a goal that might surprise those who think that the goal is users’ control of their own computing.
All these points are obvious once you start to analyze the keynote. However, what is important to notice is that little except the title — which tends to get lost — emphasizes the perspective. Instead, Shuttleworth talks throughout as if what he is advocating will aid the whole of free software, a viewpoint that is at the very least debatable.
Making up your mind
Nothing is innately wrong with Shuttleworth’s perspective. Nor should Shuttleworth be attacked for promoting his own interests or accused of attempting to mislead the free software community. His sincerity is not in question, even if some of the details of his vision may be.
However, because of Shuttleworth’s position and talents, his views tend to be reported without being challenged. Moreover, because he is clear-thinking and knows what he wants, people may move to implement his vision without examining it, regardless of the fact that some points of it may be less desirable than he suggests.
If you support his managerial, commercial perspective, you may see no reason to question that cadence, quality, and design are the keys to free software’s future. But, if you have a different perspective on free software — especially a community one or an activist one — you might want to be more cautious.
Is cadence necessary? Does it conflict with quality? Is design already receiving sufficient attention? Is greater participation an unalloyed good? Such questions are all worth pondering.
Then, if you do decide that you support Shuttleworth’s vision, you can do so with more confidence for having examined it. Alternatively, if Shuttleworth’s vision of free software is not yours, you might want to modify it, or even suggest another view of the future altogether. The future of free software is too important to leave any one person, regardless of their contributions or talents.