Mir vs. Wayland show why upstream projects matter
![](/var/linux_magazin/storage/images/online/blogs/off-the-beat-bruce-byfield-s-blog/318120-13-eng-US/Off-the-Beat-Bruce-Byfield-s-Blog.png)
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.
![Learn More](https://www.linux-magazine.com/var/linux_magazin/storage/images/media/linux-magazine-eng-us/images/misc/learn-more/834592-1-eng-US/Learn-More_medium.png)
News
-
NVIDIA Released Driver for Upcoming NVIDIA 560 GPU for Linux
Not only has NVIDIA released the driver for its upcoming CPU series, it's the first release that defaults to using open-source GPU kernel modules.
-
OpenMandriva Lx 24.07 Released
If you’re into rolling release Linux distributions, OpenMandriva ROME has a new snapshot with a new kernel.
-
Kernel 6.10 Available for General Usage
Linus Torvalds has released the 6.10 kernel and it includes significant performance increases for Intel Core hybrid systems and more.
-
TUXEDO Computers Releases InfinityBook Pro 14 Gen9 Laptop
Sporting either AMD or Intel CPUs, the TUXEDO InfinityBook Pro 14 is an extremely compact, lightweight, sturdy powerhouse.
-
Google Extends Support for Linux Kernels Used for Android
Because the LTS Linux kernel releases are so important to Android, Google has decided to extend the support period beyond that offered by the kernel development team.
-
Linux Mint 22 Stable Delayed
If you're anxious about getting your hands on the stable release of Linux Mint 22, it looks as if you're going to have to wait a bit longer.
-
Nitrux 3.5.1 Available for Install
The latest version of the immutable, systemd-free distribution includes an updated kernel and NVIDIA driver.
-
Debian 12.6 Released with Plenty of Bug Fixes and Updates
The sixth update to Debian "Bookworm" is all about security mitigations and making adjustments for some "serious problems."
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.