Safe as Milk

Ubuntu to move to Unity as default desktop for 11.04

October 25, 2010 6:19 pm Dave Neary community, gnome

At this stage, most people will have heard the news: Ubuntu 11.04 will ship with Unity as the default desktop shell. This raises a few questions: what does this mean for GNOME, and the adoption of GNOME Shell? Will this further affect the relationship between Canonical developers and others working on the same problems?

First things first: what Canonical is doing here is not new, by any means. Novell developed the slab on their own, based on their user testing and to their own design, before proposing it for inclusion in GNOME once it was released in Suse Linux Enterprise Desktop. Nokia have developed custom user interfaces on top of the standard Linux desktop shell for the past 5 years, built with GNOME technologies, and have actively participated in the development of core components through the GNOME project – they are now developing a custom interface based on Qt, for smartphones, using the same standard desktop stack. OpenMoko did the same thing with the Freerunner. Intel built a custom shell for netbooks in the Moblin project, which is now the netbook interface for MeeGo. OLPC built a custom designed user interface for educational computing devices. GNOME allows and enables this kind of work, because of the great platform and infrastructure we have provided over the years to all Linux software developers.

In such illustrious company, forgive me if I think that Canonical’s management has seriously underestimated the difficulty of the task in front of them.

At the time, the slab further damaged the relationship of Novell developers and the GNOME project – Dan Winship wrote a scathing mail to a GNOME list when asked why Novell had not worked in the open on such a significant development, saying in short that it was impossible to work in the open in the project – the logical conclusion of the siege mentality bred by the negativity around Mono development and the numerous acrimonious debates at the time.

Nokia have had repeated issues coming to terms with open development, and reconciling the need to differentiate and the desire to create an open collaborative project. Their conclusion – to increase the openness of their software platform and collaborate in the MeeGo project – bears witness to the difficulties they have had over the past five years developing a high quality, innovative mobile user experience alone.

OpenMoko repeatedly ran into performance and flexibility issues, and frequently changed software strategy, to the point where the project was no longer viable. Their success was in creating a vibrant independent developer community, which has allowed their dream to live on in projects like Hackable Devices, and its distribution Hackable:1.

Intel have followed a similar path to Nokia – creating an independent vendor-let user interface project, having trouble getting a high quality product out the door, and they are now in the process of opening up and collaborating on the netbook user interface through the MeeGo project.

OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thans to a broad and vibrant developer community.

There is not one out-and-out success story of a company building a great high-quality custom user interface on the standard Linux stack, except Android, which is hardly a model of collaborative software development.

Is this because of problems in out platform? A lack of developer tools? Insufficient documentation? Perhaps – but if that’s the case, don’t all of the aforementioned have a shared interest in improving those raw materials?

There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.

So why do people do it? Because working with old code is painful. After years of use, and bug fixes, and nasty hacks, the code gets to look ugly. Really ugly. I’ve been in the situation myself – you’re working on crusty, crumbling, slow code from 10 years ago, and you say to yourself “I could write better than this in a weekend”. And you do get to a decent proof-of-concept in a few days. And then you have to harden it. And you spend months and months fixing bugs until finally it does everything the old code did, better, and a few new things, but it took you 2 years of development. And it looks just as hairy as the old code did. As Joel Spolsky wrote: “there is absolutely no reason to believe that you are going to do a better job than you did the first time”.

Astute readers might notice that I did not include Red Hat and GNOME Shell in the list of “custom user interfaces” in my list. That is because of the way this project started, and is being developed. The project grew from the ideas of the Pyro Desktop and the Online Desktop & BigBoard, both show-cased at GUADEC back in 2007 in Birmingham, the core design grew from a User Experience Hackfest in 2008 which happened during the Boston Summit, and has evolved in a public wiki. The source code has been public from the start, with a public mailing list, and a designer who has been openly communicating design thinking, and crying out for outside contributors.

I have been telling people for a while that transparency does not equal democracy, that it is possible to have a coherent design in a community-developed project – all you need is a designer that the developers trust who can communicate what is important about his design, who is not afraid to adapt his design based on feedback, but who has the last word on what gets written.

Canonical, and other vendors, do this by appointing a designer, and basically forcing developers to implement what he comes up with. But there’s no reason it can’t be done in the community – as it has been in the past (Seth Nickell’s design of the desktop file chooser, mostly implemented by Federico Mena Quintero, comes to mind).

I fear, however, that this is just another step in a pattern which has been coming for a while. Jeff Waugh said it well today on Twitter: “Unity as default shell == brand before community, differentiation before collaboration.” Canonical values the Ubuntu brand, as they should – but in recent times there has been a move to favour that brand over a better core product that all can share. Unity and Ayatana are merely the most recent in a chain of projects pointing in that direction. Canonical has long had to defend a relatively low contribution level to upstream projects, preferring to position themselves as an integrator, adding fit & finish. Even for public projects like 100 paper cuts, I have been told that there has been limited success in getting patches integrated upstream – I have heard anecdotal accounts of patches that were “evil hacks”, or fixes which were expeditiously made to Ubuntu or worked around a symptom without fixing the root cause. I can’t attest to this – a spot check of 5 paper cuts showed me one Ubuntu-specific fix, one “CLOSED INVALID”, one fix which was rejected, and two fixes integrated upstream.

Back in July, when the GNOME census came out, I commented on Jono Bacon’s blog entry on the subject:

Canonical’s strategy is to develop new features for the desktop, which have not (yet) been included in GNOME.

This is a strategy which has back-fired on a couple of people in the past – it’s not enough to work on something and then propose it for GNOME as a “take it or leave it” choice – the GNOME developers often have feedback on design decisions and request some changes which you mighht not be prepared to make in developed software, but which might be OK to make in a spec […]

One thing I really want to avoid is the creation of a siege mentality of “Canonical vs Rest of the World”, which is counter-productive to the goal of increasing the contribution of Canonical to core GNOME. It’s good to be aware that Canonical are not maintaining core modules, and look for easy ways we can help that happen. Proposing new modules is one path toward that, and contributing to the maintenance of some modules which need it is another.

Unfortunately, this choice of Unity as the desktop user interface, instead of supporting the steadily progressing GNOME Shell project and trying to influence the direction of that project, is another step on the path to the siege mentality. This move will inevitably garner some support from within Ubuntu, and much criticism from the rest of the GNOME ecosystem, further isolating Canonical and the Ubuntu community from the rest of the free desktop development community.

The best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so – and at that point either GNOME will adopt Unity (if Canonical drop the copyright assignment requirement) or Canonical will adopt GNOME Shell (if, as I expect, Canonical struggle to get Unity to the quality standard their users expect). A worst case scenario would see both projects suffer from the competition, putting the free software desktop another two years behind in its quest to beat Apple & Microsoft on features & functionality.