Mir vs. Wayland show why upstream projects matter

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.
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.