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
-
First Release Candidate for Linux Kernel 6.14 Now Available
Linus Torvalds has officially released the first release candidate for kernel 6.14 and it includes over 500,000 lines of modified code, making for a small release.
-
System76 Refreshes Meerkat Mini PC
If you're looking for a small form factor PC powered by Linux, System76 has exactly what you need in the Meerkat mini PC.
-
Gnome 48 Alpha Ready for Testing
The latest Gnome desktop alpha is now available with plenty of new features and improvements.
-
Wine 10 Includes Plenty to Excite Users
With its latest release, Wine has the usual crop of bug fixes and improvements, along with some exciting new features.
-
Linux Kernel 6.13 Offers Improvements for AMD/Apple Users
The latest Linux kernel is now available, and it includes plenty of improvements, especially for those who use AMD or Apple-based systems.
-
Gnome 48 Debuts New Audio Player
To date, the audio player found within the Gnome desktop has been meh at best, but with the upcoming release that all changes.
-
Plasma 6.3 Ready for Public Beta Testing
Plasma 6.3 will ship with KDE Gear 24.12.1 and KDE Frameworks 6.10, along with some new and exciting features.
-
Budgie 10.10 Scheduled for Q1 2025 with a Surprising Desktop Update
If Budgie is your desktop environment of choice, 2025 is going to be a great year for you.
-
Firefox 134 Offers Improvements for Linux Version
Fans of Linux and Firefox rejoice, as there's a new version available that includes some handy updates.
-
Serpent OS Arrives with a New Alpha Release
After months of silence, Ikey Doherty has released a new alpha for his Serpent OS.