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
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.