Safe as Milk

Flashback to 2007: “GNOME will be a platform or a big tent”

I was more than a little amused when (in a vanity exercise) I re-read Joe Brockmeier’s 2007 profile of me while I was OpenWengo community manager. Among the topics we talked about was where I saw GNOME going, and I said this:

Neary says he thinks GNOME will either grow into different projects — such as a One Laptop Per Child (OLPC) GNOME, a Home and Small Office GNOME, and Enterprise GNOME — or the project will shrink to the GNOME development platform, “which will then be re-used by third parties to build the interfaces they’re interested in on top of it.

“We have already started to see this trend. Distributors cherry-pick the applications they are interested in for their own desktop projects, which are then themed and targeted for their core audience. The variety of platforms and human interfaces being built upon the GNOME platform is dazzling. These go from small-form-factor interfaces like the Nokia N800 and the Maemo application framework and OpenMoko and GPE through to innovative interfaces like Sugar from OLPC, which is totally unfamiliar to someone used to the GNOME desktop, but which is undeniably GNOME-based.”

It isn’t just the embedded or odd form-factor devices that are customizing GNOME, says Neary. “Even the major distributions have modified the GNOME interface to suit their needs. The openSUSE, Red Hat Enterprise, and Ubuntu desktops all behave in different ways, and have different target audiences.”

From memory, I don’t recall mentioning Home & Small Office or Enterprise GNOME, but I certainly remember saying that I thought we should adopt Sugar as “GNOME Education”, maybe Maemo as “GNOME Mobile”, moblin as “GNOME Netbook”, etc.

So it looks like the latter scenario has started to come to pass. The GNOME project is concentrating on defining the core platform and distributors are building usecase-specific or brand-differentiating user interfaces on top. Is it too late for GNOME to embrace this trend, or have we become technology suppliers only?

A modest proposal re. Unity

Having slept on it since writing my initial reactions yesterday I now have a proposal for Canonical & GNOME, which I hope the people concerned will consider.

Yesterday, I said “the best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so”. So my proposal is this: let’s have a bake-off, Unity vs GNOME Shell, under the big tent of the GNOME project.

What needs to happen? Unity would have to agree to sync to the GNOME release schedule. Canonical will need to drop their copyright assignment requirement for Unity, and should ideally commit to using some of GNOME’s infrastructure. How much will need to be discussed. I’m sure that the Unity developers will want to continue to use Launchpad for bug tracking and bzr for source control, but perhaps the development mailing list could move to gnome.org, and the Unity website could be gnome.org/projects/unity or unity.gnome.org instead of unity.ubuntu.com?

GNOME will have to accept Launchpad as a platform for the development of GNOME software – there are potential integration issues, it is a headache using Launchpad & Bugzilla, co-ordinating Rosetta & upstream translation teams, and so on. But right now there is a general feeling that gnome.org is for “official” GNOME software, and Launchpad is for Ubuntu. We need to change that perception if we hope to be inclusive of Canonical and the greater Ubuntu developer community in GNOME. In fact, broadening the definition of what we call GNOME software was a key plank in the release team platform for 3.0 – resolving this question (and the equivalent question for projects hosted on Google Code and Sourceforge) will go a long way to growing the big tent. The GNOME project should also work to make it easy to switch from one shell to the other.

Developers who feel drawn to one philosophy or the other should work to make sure that their vision is the best it can be by September 2011. And at that point, presumably at the Desktop Summit in Berlin, GNOME, as a project, should choose one of the two, and put our full weight behind it.

This is potentially naïve on my part. Over the years, we have allowed a lot of animosity to build up between Canonical and Red Hat, among others. As a community, we’ve stood passively by while this has happened. Some will point to efforts to engage which were rebuffed. Others will point to a lack of real commitment to engage.

In situations like this, no-one is 100% right, no-one is 100% wrong. All we can do is look at the current situation, and ask ourselves: how do we get to where we want to go, from where we are? We have two choices – we can, like the Mayoman asked for directions to Galway by tourists, respond “If I was going to Galway I wouldn’t start from here at all”, or we can roll up our sleeves and try to make things a little better.

So – how about it? Is this a non-starter, or is it worth starting some conversations about it?

Ubuntu to move to Unity as default desktop for 11.04

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.

Oracle, OpenOffice.org, LibreOffice

There has been a lot of commentary in recent days about the OpenOffice.org community council decision to ask people who have aligned themselves with The Document Foundation (TDF) to resign their seats on the council. So, of course, what we need is a little bit more commentary.

First, when reading the minutes, it’s worth noting that this was not a voted decision. At 21:50, Louis Suarez-Potts proposed “that the TDF members of the CC consider the points those of us who have not joined TDF have made about conflict of interest and confusion [and] resign their offices, so as to remove the apparent conflict of interest their current representational roles produce”. He then proposed a deadline of Tuesday “to deal with this” – by emergency meeting of the council. So there was no decision to expel anyone, Louis made a proposal which did not obtain a consensus decision. That said, reading the minutes, there is clear alignment between supporters of TDF on one side and the rest of the council on the other side. And “the rest of the council” is Louis Suarez-Potts, Andreas Bartel, Eike Rathke, Juergen Schmidt, Matthias Huetsch and Martin Hollmichel on behalf of Stefan Taxhet – all Oracle employees.

Second, let’s put this in perspective. Louis is the OpenOffice.org community manager, and has been for several years. Andreas, Eike, Juergen, Matthias and Stefan are all former Sun employees, and as best as I can tell, also former StarDivision employees. So this is hardly an Oracle corporate decree. It is a group of long-time contributors to OpenOffice.org taking a position on the community council vis à vis LibreOffice. I have been telling people for years that corporations don’t get to be members of free software communities – although their employees might. Let’s apply that same standard when commenting on actions by individuals, and assume less cloak-and-dagger. “Oracle” have not decided anything here.

That said, looking at the council structure, it’s clear that it has been set up so as to make it very difficult for Oracle/Sun employees to ever find themselves in a minority on the council, if they do decide to act as a block.

Third, let’s look at the substance of the discussion itself. The Document Foundation defines itself as “an independent self-governing meritocratic Foundation, created by leading members of the OpenOffice.org Community”. Implicit in this is a criticism of OpenOffice.org: the project is not independent, self-governing or meritocratic. Calls for OpenOffice.org to be managed by an independent not-for-profit are not new – in fact, I was one of those calling for it over the past few years. So clearly, the creation of The Document Foundation is a reaction to perceived and actual dysfunction in the operation of OpenOffice.org. In fact, in its initial communications, The Document Foundation clearly stated that the name LibreOffice was provisional, and that they hoped that Oracle would allow the foundation to use the traditional OpenOffice.org name – in other words, TDF wants LibreOffice to supersede OpenOffice.org as a project.

How, then, can people who have aligned themselves with the new initiative keep a straight face and say they are not trying to undermine OpenOffice.org? Traditional contributors to OpenOffice.org are now faced with a choice: will I update my source code daily from OOo, or from LibreOffice? I have met project volunteers who had no prior knowledge of the split who are now torn between two groups. They feel like they have to decide. For the instigators of the revolution to pretend otherwise is disingenuous.

I’ve been told that I’m conflating “OpenOffice.org” the project, and the OpenOffice.org community council, which was created to represent “the OpenOffice.org community” – and that all of the non-Oracle community representatives feel it’s in the best interests of the OOo community to align with TDF, and as such it is Oracle representatives on the council who are in conflict of interest with what is best for the community they are representing. That may be the case, I’ll leave you to decide. It seems to me that supporting LibreOffice implies withdrawing support for OpenOffice.org, and thus forfeiting any mandate you might have to represent the OpenOffice.org community. Individual community members will surely make up their own mind.

A fork is like a schoolyard football game. Tommy brings a ball to school, and gets to be captain of a team every time, picks the best players for himself, because if he doesn’t, he threatens to take his ball away. After a few weeks of this, the other players get annoyed, and everyone chips in to buy a ball for the group. At this point, Tommy has lost all power – he still has his ball, but he’s not team captain any more. He gets left standing against the wall till the very end to teach him a lesson in humility. So he sits out the games for a while in protest, starts a competing game at the other end of the yard with his ball and his rules. All the best players go to the other game, though, and some of the kids make fun of “Tommy’s” game – invitations to give up his game & join the new one seem more like taunts than honest efforts to include him. After a while, he realises that playing football with others is more fun, and more important, than playing with his football.

I welcome the creation of The Document Foundation. I believe that it will be good for office software on the free desktop. I would prefer supporters of TDF to be dignified and forthright during the split, and to come straight out and say “we think TDF offers a better future for OOo than OOo does – so come join us”. Let the dust settle, and maybe in 6 months or a year, when the functionality gap between LO and OOo has widened a little, propose once more that Oracle and IBM engage with the foundation. At that point, such a proposal will seem like an honest effort at reconciliation. Right now, it feels more like rubbing Tommy’s nose in it.

Updated to reflect feedback, 11:30, 2010-10-21