Off the Beat: Bruce Byfield's Blog

Following the Mir vs. Wayland controversy over the last six months, my first reaction is: this wouldn't be happening if upstream development was kept upstream.

The controversy began when Mark Shuttleworth announced that Ubuntu planned to replace the aging X Window System with an in-house project called Mir.

Since other distros were already developing Wayland as a replacement, this announcement was controversial enough by itself. However, the controversy was compounded by the fact that two years earlier, Shuttleworth had announced that Ubuntu was supporting Wayland.

Nor was the discussion helped when KDE and Wayland developers questioned the rationales for Mir, or whether Ubuntu and its commercial arm Canonical had the in-house expertise to build Mir. Shuttleworth responded by calling his critics the "Open Source Tea Party," although he later apologized.

As I write, the controversy has spilled over to Slashdot and a number of blogs, and shows no signs of ending. The topic may be new, but the animosities are not; in 2012, Shuttleworth stopped funding Kubuntu, the KDE version of Ubuntu, while at least one of his critics, KDE's Aaron Seigo, has constantly questioned Shuttleworth's proposals and decisions over the years (and in the process consistently demonstrated more knowledge of both the technology and the community).

Ubuntu's In-House Experiment
Mir is only the latest project that Canonical and Ubuntu have developed in-house. Ever since the transition from GNOME to Unity interface, in-house development has been Ubuntu's prefered method of developing new technologies or policies.

When Unity was first developed, a few people objected to this change. Developing inside a distribution, they said, upset the standard relationships between distributions as software packagers and upstream projects as developers of software.

They were right, of course, but at the time I thought this observation was just the voice of tradition objecting to change. Who cares, I thought, where the software was made, so long as it was available for installation? In-house development might flounder because of lack of resources, but what counted in the long run was getting more free software into the hands of users. Perhaps working in-house would even accelerate development, since there would be fewer differences of opinion.

Four years later, Ubuntu's history suggests that I couldn't have been more wrong. Unity is by far the least popular aspect of Ubuntu, rarely the interface of choice for derivative distributions, and unpopular among the major distributions. Similarly, Upstart has been recently been abandoned in favor of supporting systemd as Ubuntu's init replacement, just as everyone else is doing. Other Ubuntu projects, like Project Harmony, have died for lack of outside interest.

Now, Mir appears to be similarly isolated. Ubuntu has no allies in its insistence on Mir rather than Wayland, and little likelihood of finding any, considering how everyone has invested so much effort in Wayland. Meanwhile, the announcement that Mir may not be used in Ubuntu until 2016 creates the impression that the distribution is finding progress much harder than Canonical's decision makers expected.

House Limits
This history suggests several important points about in-house development. The first is that, by remaining in-house, you may have to struggle to find the resources for large scale projects. In the last few years, Ubuntu has frequently announced that new volunteers are welcome, but has consistently taken longer than expected to bring projects to general release. Despite the free-licenses, in-house projects are apparently regarded by outsiders as being of limited interest.

Secondly, although in-house development may allow for faster decisions, that advantage transforms into a disadvantage if the decisions made are rash ones.

Multiple viewpoints may mean an Ent-like slowness in charting a course, but they may also reduce the likelihood of poor decisions that represent a single group of stakeholders. For instance, Unity's online search on the dash may benefit Canonical's ambition to be profitable, but goes against the interests of the majority of users - most of whom only want to find an application, not to get sidetracked by purchasing something online.

Finally, while cooperating in upstream projects does not by any means eliminate arguments, it does tend to make the arguments more focused, and more likely to be about technical possibilities than personalities. However slowly, arguments in upstream projects involve hammering out compromises and evolving plans to move forward, because everyone has a stake in moving the project along.

By contrast, in-house development seems to provoke arguments that often have little to do with technical challenges. Instead of discussing the technical challenges, Shuttleworth is reduced to cheerleading his own projects, insulting critics while insisting disingenuously, "I can tell you what the agenda of the Mir team is: speed, quality, reliability, efficiency. That’s it." In response, his critics undermine their own comments by expressing their resentment, accusing him of libel, and even challenging him to debates that they could predict that he will never accept. 

The result is no one's finest moment. The only results are duplicated efforts and flame wars, both of which fritter away the limited resources.

Upstream development can, of course, sometimes get bogged down in much the same way. They are by no means utopic.

Yet by definition, upstream projects imply people working outside of their comfort zone, and coming together to settle differences of opinion in the name of shared interests. The trouble with in-house development is that it seems to encourage  defensiveness -- a siege mentality that reduces the possibility of anyone learning to cooperate with other interests and makes enemies of those who in a sane world would be allies.