Timeline: It’s 2009… and they have a plan

Note: This post is part seven of a series of thoughts on the relationship between Canonical and GNOME.


The GNOME User Experience Hackfest of October 2008 spawned a science project to build a new user experience — GNOME Shell — and based on striking similarity in design, appears to have inspired Canonical’s private work on a “messaging menu” stack for persistent notifications.

By early December, too late for the GNOME 2.26 module proposal period, a plan existed to ship the messaging menu in the next Ubuntu release. Both Mark Shuttleworth and Ted Gould subsequently blogged about the design, but no code existed in the public sphere.


January 5, 2009: Ted Gould writes about application indicators — a step beyond just having persistent notifications in the messaging menu:

One thing that kept bothering me in the GNOME UI Hackfest was how little data applications export out to the desktop. [...]

What I’d like to put forward is the idea of little flags that applications can hold up to say what they’re thinking or doing, which I’m going to call indicators. [...]

First off I want to build something simple (start small, think big), the messaging indicator, which will mostly consist of a GNOME panel applet.

January 8, 2009: In a surprisingly highly-anticipated event at CES Las Vegas, Palm announces the Prē smartphone and its new mobile operating system, webOS. In later reviews, the notification system is widely praised as better than those found in Android and iOS.

February 18, 2009: That code exists for Canonical’s fancy new messaging menu and notification concepts is first revealed with their upload to the “Jaunty Jackalope” development branch. Design and architecture specs for Notify OSD are published on the Ubuntu wiki.

February 21, 2009: Mark Shuttleworth announces that the new work is available in Ubuntu:

Together with notify-osd, we’ve uploaded a new panel indicator which is used to provide a way to respond to messaging events, such as email and IRC pings.

A commenter asks, “Will canonical/ubuntu help on the new gnome-shell proyect [sic]?”

Yes, we helped by sending most of our user experience team to the user experience sprints, and have folks at the UI hackfests. We’re working on notifications in a way that will fit with both GNOME and KDE, and will contribute that at freedesktop.org. And we’re working on the panel and other pieces. We’ll package up the new gnome-shell in due course, but will wait to see what the best defaults for Ubuntu are.

Later in the comments, Mark points out that, “There will be a lot of new work coming from this team, though, and the best place to get it will be Ubuntu ;-)”

March 2, 2009: The GNOME 2.28 development series and module proposal period begin. Neither notify-osd or libindicate/indicator-applet are proposed for inclusion.

March 10, 2009: Mark Shuttleworth files a wishlist bug on Empathy to suggest it use Ubuntu’s new persistent notifications. Empathy developer Dafydd Harries replies:

I don’t know what a “messaging indicator” is. Is there any documentation on what libnotify does and how to use it? A quick search doesn’t turn up anything useful.

Mark helpfully ropes in Ted Gould to answer any questions:

libindicate (not libnotify) is a library for indicators, and the messaging indicator is the first of those. Ted Gould would be the best person to speak with. He says there’s some documentation in the package in 9.04, not much more to go on, sorry.

Sjoerd Simons tries to be encouraging under the circumstances:

We’re always happy to try and improve empathy’s user experience. The information you’ve given is a bit limited though. [...]

Maybe you or Ted could explain how libindicate/indicators would improve things for Empathy? Screenshots/documentations/mockups/examples are appreciated, patches even more so :)

Also is libindicate something more gnome applications might start using in the near future? Or would it be an external dependency for gnome just for empathy’s benefit?

To which Ted replies with some links and documentation, but the bug chatter ends.

March 18, 2009: GNOME 2.26 is released.

March 31, 2009: A design specification for the messaging menu is published on the Ubuntu wiki.

April 2, 2009: Without a lot of forward movement since July (GUADEC) or October (Boston Summit and UX Hackfest), the release team decide to shake things up with a wide-ranging proposed plan for GNOME 3.0, written in release manager Vincent Untz’s signature franglish:

So let’s go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on:

As already mentioned, this is an ambitious plan and it will only be realized if everybody comes out and helps.

In terms of schedule, the release team are bullish but realistic:

Of course, we should be prepared to consider the fact that GNOME 2.30 might not be good enough for us to call it 3.0. [...] That being said, we want the community to try as hard as possible to make GNOME 2.30 = GNOME 3.0 a success.

There is an immense amount of discussion, as you’d expect for a significant, project-wide release, revamp and rejuvenation plan.

April 5, 2009: Almost one month after Mark Shuttleworth suggested Empathy support Ubuntu’s new persistent notifications, James Westby provides a patch. Some less-than-diplomatic complaints are raised about the platform-specific nature of libindicate –it’s not even based on a freedesktop.org specification yet!

Xavier Claessens (not generally known for subtlety or a calm demeanour) asks:

Is there a discussion somewhere to propose libindicate as external dep of GNOME 2.28? I think it’s the very first step, I don’t think it’s wise to accept such patch before getting feedback from the GNOME community.

Ted Gould corrects Xav’s mistake, knowing full well that optional dependencies are fine:

My understanding of the GNOME release process is that the release team prefers to see a library used as a configure time option of several projects before accepting it as a dependency. This removes the “I built a library that sounds good but no one really uses” problem of adding libraries to the platform. For instance, libnotify has been used by many programs before it was a blessed dependency for 2.26.

After some reasonable chatter about the design motivation for Ubuntu’s messaging menu, persistent notifications, and applicable freedesktop.org specs, the discussion trails off.

April 15, 2009: Jon McCann’s first post to the GNOME Shell mailing list. Bryan Clark joins the list and offers some suggestions, including:

You probably don’t want me trying to arrange this stuff for you, but I’d recommend gathering the existing docs and blog posts you have into something more consumable.

Jon McCann replies, “I’m a bit out of the loop too but here’s some background.” It is his first post to the mailing list, and based on the responses from active contributors, Jon’s ideas about GNOME Shell are pretty firmly stuck in October 2008.

April 17, 2009: Mark Shuttleworth blogs about “meta-cycles” across FLOSS projects, clearly aware of the significant — and potentially risky — plans for GNOME 3.0 and the continuing work on GNOME Shell:

On the other side of the fence, GNOME is now more aware of the limitations of indefinite regular releases. I’m very excited by the zest and spirit with which the “user experience MATTERS” campaign is being taken up in Gnome, there’s a real desire to deliver breakthrough changes. This kicked off at the excellent Gnome usability summit last year, which I enjoyed and which quite a few of the Canonical usability and design folks participated in, and the fruits of that are shaping up in things like the new Activities shell.

But it’s become clear that a change like this represents a definitive break with the past, and might take more than a single six month release to achieve. And most important of all, that this is an opportunity to make other, significant, distinctive changes. A break with the past. A big bold move. And so there’s been a series of conversations about how to [...] break with the tradition of incremental change, in order to make this vision possible.

April 22, 2009: Canonical’s Ayatana project is announced as an umbrella for the DX team’s various projects, beginning with notify-osd and indicator-applet. The desktop experience and design teams have grown since they were announced in mid-to-late 2008.

April 23, 2009: Ubuntu 9.04 ships with Canonical’s fancy new notifications (notify-osd) and the messaging menu (libindicate/indicator-applet) as features worthy of mention in the official press release.

May 18, 2009: The GNOME 2.28 module proposal period closes. Despite being shipped in Ubuntu 9.04 a month earlier, neither notify-osd or libindicate/indicator-applet were proposed for inclusion.

Late May, 2009: Jon McCann moves from internal projects to Owen Taylor’s section of the Red Hat desktop team — the group assigned in 2008 to work on the results of the UX Hackfest, which became GNOME Shell.

May 25-29, 2009: Ubuntu Developer Summit in Barcelona. The desktop team discuss the plan for GNOME 3.0 in Karmic Koala:

Ubuntu is a GNOME based distribution, having the new versions and components available early will benefit the distribution, users and GNOME.

Users will want to try the new GNOME components and be able to test GNOME3, it will be easy to do so from Ubuntu.

May 25, 2009: Ted Gould submits a talk about the messaging menu for presentation at the Gran Canaria Desktop Summit.

June 15, 2009: Jon McCann blogs about pulling together the design work already done on GNOME Shell, and encourages participation in daily IRC discussions about the design.

July 3-11, 2009: Gran Canaria Desktop Summit.

Ted Gould presents messaging menus.

Jon McCann publishes the GNOME Shell design bible, expanding on design concepts first introduced at the UX Hackfest in 2008.

Owen Taylor presents the latest work on GNOME Shell, including an entirely new design for notifications. While the central location for notifications, and separation between system indicators and notifications from 2008 still exists

This is not an area that is variously called the Notification Area or System Tray and should not be used by applications (foreground or background) to indicate their status.

… the drop-down panel menu “stack” is replaced with an idea clearly inspired by Palm’s webOS: the message tray.

GNOME Shell appears to be coming together well, so the Release Team recommit to the goal of shipping it with GNOME 3.0… if it’s accepted for inclusion, that is! The team plans to conduct a review, prior to the next release cycle, to decide whether the project is ready to ship 3.0 in March 2010.

August 8, 2009: KDE hackers begin work on a KNotificationItem-based spec for status icons, hoping to encourage a more flexible cross-desktop replacement for the old-school XEmbed-based “system tray” icons used by GNOME and KDE:

This is a draft standard for the management of visual items, usually icons used for reporting the status of an application to the user or provide a quick access to common actions performed by that application. It is intended to be complementary but not directly related with the Freedesktop’s Desktop Notifications specification and is aimed as a replacement to the Freedestop Systemtray specification.

August 10, 2009: The GNOME 2.30 development series and module proposal period begin. libindicate/indicator-applet are again not proposed for inclusion in this series.

August 22, 2009: indicator-applet is split into three: libindicate, libindicator and indicator-applet. The libindicate client library still uses a custom DBus protocol to talk to the indicator host user interface, despite using the org.freedesktop.indicator namespace.

(The org.freedesktop.indicator namespace has never been mentioned on a freedesktop.org mailing list, let alone the XDG specification collaboration list. libindicate has been raised once, in May 2010, in a completely different context.)

September 5, 2009: The KNotificationItem specification is first raised on the XDG list:

In the past few months in KDE we worked on a new way to represent the systemtray icons to overcome the following limitations…

September 23, 2009: Aurélien Gâteau raises his work on Ayatana notifications for Plasma on KDE’s Plasma development mailing list:

I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma.

Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more “personal” way rather than you discovering it in a blog post or a Kubuntu review.

A lengthy discussion follows, during which some familiar concerns are raised. From the pen of Aaron Seigo:

it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so.

now, whether anyone else outside of Canonical thinks it is better or worse seems to really not matter. any discussion on it is therefore a waste of time. and i’d prefer not to waste our time on this list.

… to which Celeste Lyn Paul replies:

Canonical did a really bad job involving upstreams in the design process and are now trying to make up for it by keeping upstreams aware of what is going on. It may be too little too late, but if we (KDE) can at least humor them, then they will be more willing to listen how they can make their software work better with KDE (even if it doesn’t follow what KDE wants to do) instead of just forcing Kubuntu to ship whatever they produce.

September 24, 2009: GNOME 2.28 ships.

October 13-15, 2009: Canonical developers quietly begin early development on a replacement for libindicate called… libappindicator. A “quicklauncher” prototype is blessed as the starting point for a new project called… Unity.

October 29, 2009: Ubuntu 9.10 ships with the libindicate-based messaging menu and “me” menu, which replaces the old FUSA applet.

November 3, 2009: The release team gathers feedback from teams throughout the community to determine if GNOME 3.0 should ship in March 2010, as planned, or be delayed until September 2010.

At this point, we’ve reached the beginning of the libappindicator story, though as you can tell, there was quite a bit of history behind it! Aside from the occasional crucial event in the timeline, I will avoid repeating the details of that saga in this and future posts.

December 17, 2009: Mark Shuttleworth announces that from March 2010, he will focus on “product design, partnerships and customers” and hand over the CEO’s reins to long-time COO, Jane Silber.

I’ve become very passionate about design and quality, and want to spend more time figuring out how we harness the collaborative process to build better, more insightful products. I can’t think of a more interesting challenge, and luckily I couldn’t think of a better person to take over my formal management and leadership responsibilities at Canonical than Jane.

Concerned that the transition might be misunderstood, I leave an encouraging comment on Mark’s blog:

For those who don’t know Jane — as she doesn’t have the most public profile among the stars of Ubuntu and Canonical — be assured that she is all kinds of awesome, far beyond the capacity of English to describe. This is a fantastic transition for Canonical (it’s great that Mark has someone so awesome to hand the reins to), which will in turn be fantastic for Ubuntu.

… and totally cool that Mark will have more time to focus on the stuff he finds fun and satisfying. Further arse-kicking will ensue. :-)

Wonderful news all ’round, congratulations both!

Such… optimism.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Moving the needle in GNOME

Note: This post is part six of a series of thoughts on the relationship between Canonical and GNOME.

I was incredibly tempted to entitle this post, “Pushing your turds into GNOME’s immaculate and exalted vessel”, but thought it might be taken seriously. After all, everyone knows GNOME developers believe they’re inviolably perfect, right? :-)

All Changes Great and Small

Software development is an immature branch of the discipline known as “change management”. The weapons are different, but the war is the same: Improvement generally requires change, but change involves investment and risk. So we invent convoluted schemes, tools and rituals to make change easy, but not dangerous.

FLOSS projects in particular must make change easy, because people are their most valuable resource, and change is the process through which new contributors become familiar with a project and subsequently — hopefully! — become involved.

It’s pretty simple: Contributors are your participants. If there is nothing to contribute, you have no participants. If you have no participants, you barely even have a project, let alone co-development! For FLOSS projects, change has an incentive beyond improving the software.

Readability is the key to creating code that others will use. Because in the end? We can scale silicon, but carbon? People are much harder to scale.

— Brian Aker, Drizzle goes GA, From “What If”, to “What has”

Small Changes

By small, I don’t mean insignificant. A one-line patch can fix a crasher, resolve a terribly hard-to-find heisenbug, or launch a project-wide flame-war over its correctness. By small I refer to the risk/reward ratio, which will affect how easy it is to make a decision — with both social and technical influence — about the change.

Bug fixes: In the olden days, new contributors would file a bug and attach their patch, or send a patch to the project mailing list. In modern times, a new contributor would raise a merge request in the code review system from their own distributed revision control branch. The maintainer usually has a straightforward decision as to whether the bug fix is correct and appropriate… or not.

(Despite using distributed revision control, GNOME still mostly lives in the olden days, so patches are sometimes left to rot without review.)

Features: A larger change, adding functionality or behaviour. Most of the time these are best discussed with the project maintainer before starting work, as they’re likely to have a good idea about how they’d prefer it to be implemented, or may not want the feature at all.

In GNOME, the maintainer of a module is almost always the “architect” or “manager” of that code, and is responsible for making these decisions. If the maintainer is sceptical of your feature, then you’ll have to do some convincing. Co-development is as much a social endeavour as it is technical!

Settings: What if you want the software to behave one way, but your friend wants it to behave differently? Surely that’s reason enough to add a switch to choose between them? After all, software can do anything, and computers should adapt to our needs, right?

Most GNOME developers will look at this problem differently. You may occasionally hear the phrase “options are bad”, but that’s shorthand for a deeper philosophy: What if we could make that problem simply disappear, rendering the choice itself meaningless?

Switches like this increase the complexity of the code and the “surface area” of software machinery exposed to users. If we, as software developers (and UX designers), think a bit harder about the problem before foisting it on users, perhaps we can solve it… and if we get it wrong, it’s easy to fix.

That’s why “adding an option” involves more friction in the GNOME community that you are likely to find elsewhere. Of course, some developers hate that approach. Some users hate that approach. But others find it truly inspiring.

Applications or utilities: If you want to contribute an entirely new piece of software to GNOME, it must go through the Release Team’s module proposal process. As long as you meet the long list of conventions and standards upheld by the GNOME community, and your software is relevant, you’re pretty likely to get in. As of GNOME 3.0, it’s even easier, because the Release Team has split out recommended applications from the core components of the desktop user experience — panels, window manager, file manager, etc.

Large Changes

Cross-module changes: Sometimes you can’t surface a feature within the scope of a single module, so you have to convince a number of maintainers to not only accept the feature, but if required, agree on a way of sharing necessary information between their modules, and accepting the maintenance load of making sure cross-module integration continues to work.

A good example of this kind of change is the list of folders that are remembered and shown throughout your GNOME experience — in the “Places” menu in the panel, the sidebar of the file manager, in standard file dialogues, etc.

New APIs: Providing a new capability throughout GNOME, and perhaps to third party developers, usually means adding a function to an existing platform library, or for more involved capabilities, you might even need to write your own shared library and convince developers to use it.

Lots of mistakes can be made when it comes to APIs and shared libraries, and because the GNOME community wishes to provide a consistent, reliable platform, it is an area that involves a lot of rules and policies. Number one on that list is the commitment to API/ABI compatibility throughout GTK+ and GNOME’s major version releases. GTK+ 3.x involves the first significant, platform-wide API/ABI break in 8 years!

New APIs will often be adopted as copy’n’paste code from incubator modules like libegg. So rather than make new library developers worry about API/ABI compatibility during development, users of the new API can just copy the code. Once everyone’s happy, it can be deployed into an existing platform library (such as GTK+), or a new shared library.

Proposing a new shared library can be arduous. For the last 8 years, developers have been naturally wary of expanding the (sprawling) surface area of the developer platform, so your library would have to be incredibly convincing to begin with… even then, perhaps the new API would make more sense in an existing platform library.

Plus, it won’t land in the API/ABI stable developer platform or external dependency list straight away: That’s a very serious commitment. The community will need a chance to get comfy with the new API before taking any marriage vows!

User experience changes: Making GNOME itself — the fundamental user experience of the product — look or work differently can be the most challenging proposal of all.

On one hand, it’s an intensely social process, because you’ll probably find yourself trying to convince the entire project to accept your change. On the other hand, it is a technical issue, but very different to fixing a bug or adopting a library: Now you’re invoking huge questions about user experience, acceptance testing, user stories, who GNOME is for… if you don’t have the technical skills to make good decisions on all of those fronts, you’re in for a rough ride.

You just thought it might be nice to have two panels instead of one. Then everyone got all existential. Welcome to GNOME. :-)

The Inevitable Linux Kernel Comparison

All of that sounds terribly difficult. “Why can’t GNOME be more like the Linux kernel?”

They’re not really that different. Two big ones: Linux ships as a single tarball, GNOME’s user interface has quite a different audience profile.

Linux still has plenty of components and subsystems, maintained by different people. A hardware driver might be a nicely contained chunk of work, but if you want to change the SCSI subsystem, you’ll have to convince a few people along the way. Want to make a big change? Ask for advice (a “Request For Comments”) before carpet-bombing lkml with your patch-set. Thoroughly unsurprising stuff for large-scale co-development.

Believe it or not, kernel maintainers are getting the “options are bad” religion. Yes, even in the kernel, settings and magic numbers can increase complexity of code and the “surface area” of software machinery for users — systems administrators — to deal with. Years after calling my friends and I “interface nazis”, Linus questions whether or not big chunks of the Linux kernel can “just work”. :-)

You’ll definitely hear some developers whine that Linux doesn’t have stable internal APIs (one clear advantage to working in a flexible, monolithic codebase), but don’t get caught breaking the userland API/ABI…!

“We’re not so different, you and I.”

Technical Leadership

Every now and then, and quite a bit over the last week, someone will offer up the prize furphy that GNOME does not have technical leadership. This is poppycock, pure and simple.

It might not be immediately obvious. It might not be particularly efficient. It might not be convenient. But you know it exists… if only because trying to sneak past it will cause all hell to break loose.

What is it? A meritocracy, where legitimacy and influence is derived from contribution.

Becoming a Leader

Training and growing technical leaders in GNOME is not unlike other open, meritocratic, co-developing FLOSS projects.

You send a little patch, perhaps to fix a bug, and the maintainer accepts and commits the change. Encouraged, you fix more bugs, implement some minor features and send a patch for each change.

Eventually, you send enough good stuff that the maintainer wants you to commit directly (the lazy maintainer principle in action). You request an account, and the maintainer backs you up. Now you can commit to all the things!

Your changes still have to be accepted by the maintainer, but now she can ask you to commit directly instead of sending patches or merge requests.

(You submit a few changes elsewhere, and the other maintainers trust you that little bit more, because you already have an account on the GNOME revision control platform!)

After a while, the maintainer sees that you have a good understanding of the code, and in a moment of brilliant laziness says, “Hey, you don’t need me to review your changes now, I trust you.” Of course, you still talk about more controversial or difficult changes prior to committing.

Eventually you work well enough as a team, you’re blessed as a co-maintainer, and five minutes later the original maintainer announces she’s travelling around the world on a donkey. So now it’s up to you, co-maintainer for five whole minutes. Time to find some more contributors…


If there were an Arthurian round table of technical leadership in GNOME, it would be the motley group of developers who maintain all the modules in the various release sets: The Maintainers (it’s not a band).

But there are a few round tables — maintainers of the developer platform, the core user experience, the language bindings, etc. Each has more sway in certain decisions: Should libfoo be in the platform? Should gnome-baz be integrated into the default desktop UX? These are project-wide decisions for which maintainers often wield increased influence.

Day-to-day, a maintainer’s influence is generally limited to their own software module, defining the vision and architectural approach, deciding which patches to accept, etc.

GNOME Foundation

Founded in 2000, the GNOME Foundation was designed to serve the project by doing all the boring things — keep money, manage relationships, etc. It was also granted the task of defining GNOME as a product, largely because there were arguments about it at the time, and the big companies joining the community desired… clarity and stability.

Today, the democratically elected directors of the GNOME Foundation essentially form a community council. The power to “set the technical direction” was delegated to a newly-defined Release Team in 2001. But if you want to “deal with GNOME”, you speak to the Foundation. If there is a disagreement in the community, you go to the Foundation Board for mediation.

The GNOME Foundation Board of Directors is still called upon when big problems need solving, but does not play a role in the day-to-day technical decisions of the project.

Release Team

The Release Team maintains GNOME’s six-month time-based release process, and is responsible for defining the product in a broad sense, and ensuring that it continues to meet community-defined maintenance policies (stuff like API/ABI compatibility, where work is done, etc).

Like the maintainers of individual modules, it is not a democratically elected group. If a member should leave, the team will choose a successor — amusingly, this has often been done by following the advice of the departing member!

It may not be a democratically representative group, but because the Release Team is delegated by the GNOME Foundation to serve the project — not the other way around! –the developer community could easily overturn a bad decision by the Release Team. If the situation warranted it, the community could even ask the GNOME Foundation to replace the Release Team!

I can’t quite imagine that ever happening though, because members of the Release Team know that they serve the desires of the community, and practically every decision is made on the basis that it properly represents those desires.

Difficult Decisions

Sometimes the GNOME community has found itself unable to make a particular decision at all. This is less of a reflection of GNOME’s decision-making capacity in general — or lack of technical leadership to do so — than it is of the impossible decisions themselves.

For instance, despite the many years of flame-wars and criticism, there has never been a clear answer about Mono. The GNOME community doesn’t “support” it, but in large part, doesn’t want to shun it, either.

That was an impossible decision because it meant telling members of the community — friends! brothers and sisters in freedom! — that they were not wanted. For all the legal and technical arguments in the world, the haters never understood this simple problem.

Mono is still a special case. It’s still in limbo. Some decisions are impossible to make.


How does the decision to take on a huge new release effort happen in a community that supposedly “has no technical leadership”?

What happens after that decision is made is an entirely different question — a whole community of individuals contributes a huge amount of work! — but what about the decision to make it happen in the first place?

A meritocratic project doesn’t make a decision like that at the drop of a hat. It would require lots of agitation and convincing, plenty of groundwork, heaps of preparation.

Remember, the GNOME community had been talking about GNOME 3.0 as a concept since at least 2005!

I believe we can credit much of that agitation, groundwork and preparation to the sheer dedication of a single person. It was, without a doubt, an incredible expression of open, meritocratic, technical leadership. It moved the needle.

He began, like everyone, without any involvement in GNOME at all. Today, he is what I would describe as the architect and father of GNOME 3.0.

He would ever so predictably deflect that praise on to the entire community who rallied around him.

Thank you, Vincent Untz.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Timeline: The Greatest Show on Earth

Note: This post is part five of a series of thoughts on the relationship between Canonical and GNOME.

Every now and then, the inexorable passage of time is rudely interrupted, and the natural path of history is changed before our very eyes. It is incredibly rare, I grant you, and most often involves a weapon of some description, but it happens.

In our story, that “moment” is the week starting Monday October 6, 2008.

Those of you who invest in the stock market will probably double-take, and believe I’m referring to Black Week, the stock market crash of 2008. Thankfully, no.

By curious coincidence, one of the most defining weeks in the entire history of GNOME — and a turning point for Canonical’s relationship with the project — happened to take place during a week-long stock market catastrophe.

But there’s a little prehistory to cover before we get there…


May 30, 2005: My presentation about GNOME 3.0 at GUADEC, now infamous for the attempt to recast growing discussion about GNOME 3.0 as Project Topaz — Three Point Zero — in order to avoid thinking in terms of version numbers, and… 10×10. :-)

December 23, 2006: Conversation about GNOME 3.0 continues, to the point that a clarification is required: “There are no plans for a GNOME 3.0 release at this time.”

January 15-20, 2007: linux.conf.au 2007 in Sydney. The hottest piece of hardware at the conference is the OLPC XO. The Collabora guys run full-screen video chats between their OLPCs and laptops! The conference bag, designed in late 2006, is smaller than a laptop bag, but — just quietly — the perfect fit for a 12″ laptop.

June 7, 2007: Clearly inspired by the low-cost OLPC, ASUS announces the EeePC 701 at COMPUTEX. It is immediately blessed as “revolutionary”. It ships in October 2007 and as every other vendor follows, the EeePC defines the “netbook” market. All 800 lca2007 attendees look at their conference bag with fresh eyes… and fetch their credit cards. :-)

April 15, 2008: Having facilitated a successful GTK+ hackfest, the GNOME Foundation Board decides this is a highly productive use of funds, and asks for more hackfest ideas.

June 3, 2008: Nine months after the EeePC ships, Canonical announces the Ubuntu Netbook Remix user interface and custom distribution for OEMs. Mark Shuttleworth writes about the release and says, “directly or indirectly Canonical will help to bring that innovation to KDE and GNOME and hence to the wider Linux ecosystem.”

Permit me, for a moment, to effusively praise UNR. Although the design was not wildly different to other netbook user interfaces shipping at the time, the simple composition and execution were brilliant.

One standard GNOME Panel at the top of the screen. In the top left corner, a button to hide everything and show the full-screen launcher. Next to it was a window switching applet which made your windows look and work like tabs. Application windows were automagically maximised. Very little vertical space wasted.

From a GNOME perspective, the UI changes were tightly contained: Two new panel applets, a full-screen launcher, and a little daemon to do the windows maximisation.

I absolutely loved it back then (the screenshot below is from July 2008), and I still use some components of UNR on my laptops to this day!

Sadly, UNR was also Canonical’s first major upstream collaboration blunder.

None of the UNR components were proposed for inclusion in GNOME. No Canonical developer approached the GNOME community to say, “Hey, we built this cool netbook stuff, maybe it could form the basis of a new UI profile for GNOME!”

The UNR UX was built by Canonical in private, largely because it was commissioned by a third party. Most Open Source communities prefer that feature design be done “out in the open”. Bit of a problem there, but not insurmountable.

GNOME developers have a long history of dealing with corporate contributors and commercial realities such as this, so a quick explanation of the situation and a plan to transition to a community-developed model would most likely sort things out.

After all, the individual UNR components were small, simple, tightly defined and easily consumable. They weren’t libraries, they didn’t require API changes. Put together with standard GNOME components, they redefined the user experience… and beautifully so!

None of it happened.

June 11, 2008: Greg Kroah-Hartman gives a Google TechTalk during which he claims that “Canonical does not give back to the community”.

Late June, 2008: The “Desktop Experience” team is created within Canonical, with Ted Gould and Mirco Mueller as the first members. The changes are more official as of July 3.

July 7-12, 2008: GUADEC in Istanbul, Turkey. Federico Mena-Quintero introduces Document-centric GNOME to much excitement and interest. A seed is planted for the future…

Recognising the growing desire to renew the GNOME developer platform by accepting the first API/ABI break in 6 years, and to encourage long term planning for future changes, the release team announce that the regular March 2010 release would simply be blessed as GNOME 3.0. The news is famously revealed as GNOME 2.30 = GNOME 3.0.

Vincent Untz, Federico Mena-Quintero and Owen Taylor approach the Foundation Board to suggest hosting a GNOME user experience hackfest.

July 30, 2008: Ted Gould blogs about putting a menu at the top right of the screen (replacing the big “off” button in Ubuntu’s panel), with IM presence, user switching and session management items in it. Work on a modified fast-user-switch-applet (FUSA) had already started privately in early July.

August 27, 2008: The modified FUSA package arrives in the Ubuntu development release, Intrepid.

September 10, 2008: Mark Shuttleworth announces the formation of the Canonical design and user experience team, saying:

We focus most of our effort on integration. Our competitors turn that into “Canonical doesn’t contribute” but it’s more accurate to say we measure our contribution in the effectiveness with which we get the latest stable work of upstream, with security maintenance, to the widest possible audience for testing and love. To my mind, that’s a huge contribution.

Increasingly, though, Canonical is in a position to drive real change in the software that is part of Ubuntu. If we just showed up with pictures and prototypes and asked people to shape their projects differently, I can’t imagine that being well received! So we are also hiring a team who will work on X, OpenGL, Gtk, Qt, GNOME and KDE, with a view to doing some of the heavy lifting required to turn those desktop experience ideas into reality.

Mark’s post does not go unnoticed. Although the GNOME community is understandably wary, it is widely regarded as an indication that Canonical would build their capacity to contribute upstream, particularly due to the reference to Greg K-H’s criticism that “Canonical doesn’t contribute”. The GNOME dudes employed by Canonical are as excited by the prospect as everyone else.

The very first commenter asks if Canonical would learn from the mistakes of the past, and opt to work closely with upstream projects. Mark responds, concluding with:

One can’t be an effective core contributor in hundreds of projects, so in a real sense it is “us and upstream”, as you describe it. The question is whether we can build a productive relationship, not whether we can be totally absorbed.

The commenter is… not totally convinced by Mark’s answer. He gets no response.

September 17, 2008: Greg Kroah-Hartman launches what can only be described as an ambush on Canonical during his keynote at the Linux Plumbers Conference. An entire hour is dedicated to support his conclusion that:

Canonical does not contribute to Linux plumbing. Companies who rely on Linux must contribute, or they are at the whim of others. Developers who are not allowed to contribute to Linux should change jobs.

This time, Matt Zimmerman replies, noting that while Ubuntu has lots of users, it simply does not have a lot of developers working on the kernel, let alone contributing upstream! He concludes:

To present his commentary in this way is indefensible.  LPC is promoted as a productive community event aimed at solving problems, and Greg has used his voice as a speaker to promote a much less honorable agenda.

(My view: Greg was wrong to present his concerns the way he did. His expectations were incredibly high for a four-year-old company with no kernel engineers. Yes, it would have been nice if Canonical contributed more, but if they don’t have the capacity to do so? One aspect of Greg’s criticism that was 100% spot-on was his implied concern about the free-rider problem.)

Update: So if you think these posts are just about me being anti-Canonical, know that in this section, I have been too fair… worse, I ought to know that Canonical had kernel engineers in 2008, because it did before I left in mid-2006! Thanks to Greg K-H for pulling me up in the comments.

That said, the kernel engineers were doing pretty much the same what Canonical was doing with GNOME prior to the DX team: Pulling together a kernel for each release, fixing bugs, minor integration work, etc. Greg’s expectation that Canonical contribute by way of major module maintenance and new code does not align with the company strategy, for better or worse.

September 18, 2008: Ted Gould blogs about the ongoing modified FUSA work in Right side status.

September 24, 2008: GNOME 2.24 ships. The new development series and module proposal period begins. Even though there are some technical barriers to contributing the modified FUSA directly, no attempt is made to bring those changes to the GNOME community in any form.

Had Canonical’s FUSA work been done upstream from the beginning, Ubuntu may not have had to swallow the GDM version skew it required. Ubuntu didn’t adopt the “new” GDM until Ubuntu 9.10.

(I half remember other issues delaying adoption of the new GDM as well, perhaps things like LTSP, but couldn’t find any documentation to jog my memory.)

October 1, 2008: Based on the announcement of the Canonical Desktop Experience Team, Vincent Untz reaches out to Mark Shuttleworth to invite Canonical to participate directly in GNOME 3.0 development.

The GNOME User Experience Hackfest 2008

October 6-10, 2008: A small group of GNOME technical and design leaders meet prior to the annual Boston Summit, to fundamentally re-imagine the GNOME user experience. It is arranged and led by Owen Taylor, Federico Mena-Quintero and Vincent Untz.

Key GNOME designers and developers are invited, including volunteers and employees of most contributing organisations. A couple of people decide to invite themselves. There is only one non-designer, non-developer, non-GNOME-participant, company CEO present.

I will point out the peculiar circumstance of Red Hat’s desktop team. They just wound up the failed Online Desktop initiative. Remember Mugshot and Big Board?

They were Red Hat designed and developed projects, with some intent to be relevant to GNOME, but… even documented and developed on GNOME infrastructure, they… well, just weren’t.

By October 2008, the Red Hat desktop team had realised that their approach to planting the seeds of open innovation was not working. Closed ideation and design didn’t lead to community adoption. Such an ambitious project needed broad buy-in from the beginning.

Besides, GNOME clearly needed love, and was particularly receptive thanks to Vincent Untz’s leadership on GNOME 3.0. The Red Hat desktop team decided to refocus, spend time on GNOME itself, and hopefully by doing so, encourage other stakeholders.

Everyone has ideas. No one arrives with a fully conceived plan, intending to impose their singular vision on GNOME. The open, group-defined agenda doesn’t suit such a dastardly plan, anyway.

The first two days are dedicated to “idea generation”, general discussion, and mind-expanding presentations. The rest of the week is dedicated to polishing the ideas, and turning them into something useful to GNOME. Vincent Untz writes on the final day:

So, since Wednesday, we’re working on the three topics that emerged during the first day: desktop shell, access to documents, and adding effects/animation to the desktop experience.

The output is fantastic. Each group produces a wiki page describing their discussions, all of which are detailed, thoughtful, and met with excitement:

It is understood that Red Hat will contribute developers to the effort. Other stakeholder companies are encouraged to invest resources.

Reports & Reactions

Neil Patel posts mockups of the desktop shell to the wiki page which describes the design.

Vincent Untz reports at length on the desktop shell sessions, saying:

I’m convinced that we should start prototyping those ideas so we can play with them, and see what feels good and what feels wrong. It will need testing. We will make errors. And maybe it’s a dead-end. But many people really liked this and I believe we reached consensus during the hackfest that we wanted to see this in action.

Federico Mena-Quintero writes about the file management sessions, concluding with a note that Seif Lotfy had been working on a journal in Mayanna, a maintained fork of the abandoned Gimmie project… “Seif and I have been talking about how to proceed.” By the end of October, the GNOME Journal project is born. Today it is known as Zeitgeist. :-)

Jon McCann is excited about the outcome, and gives credit to Ted Gould and “the Ubuntu folks” for ideas such as showing presence, user switching and session termination actions in a panel menu (the modified FUSA applet work). He posts some of the sketches he drew during the hackfest.

Mark Shuttleworth writes, “The GNOME user experience hackfest in Boston was a great way to spend the worst week in Wall St history!”

Though there wasn’t a lot of hacking, there was a LOT of discussion, and we covered a lot of ground. There were at least 7 Canonical folks there, so it was a bit of a mini-sprint and a nice opportunity to meet the team at the same time. We had great participation from a number of organisations and free spirits, there’s a widespread desire to see GNOME stay on the forefront of usability.

He concludes by emphasising the file management discussions, “At the end of the day, bling is less transformational than a fundamental shift in content management. Kudos to the folks who are driving this!”

After the Show

October 29, 2008: Early private development begins on libindicate, a client library and applet for displaying persistent notifications in the form of a menu. No freedesktop.org specification exists for doing this in a cross-desktop manner.

October 30, 2008: On the cusp of the Ubuntu 8.10 release, Mark Shuttleworth blogs about user switching, presence and session termination in the new FUSA menu. He says:

This work was discussed at UDS in Prague with a number of members of the GNOME community. I was also very glad to see that there’s a lot of support for a tighter, simpler panel at the GNOME hackfest, an idea that we’ve championed.

In Jaunty, we’ll likely do some more work on the GNOME panel, building on the GNOME user experience discussions. There was a lot of discussion about locking down the panel more tightly, which we may pursue.

Ubuntu 8.10 ships later that day. At the time of release, both the System menu and FUSA menu display the session termination items. Had this work been done upstream…

October 31, 2008: Owen Taylor tells desktop-devel-list that the first code for the new “gnome-shell” has landed in Subversion:

OK, a little bit of code for gnome-shell now has hit SVN. It doesn’t do anything that interesting yet …. it’s just about caught up to gnome-0.9 or so: a gray rectangle with a clock.

The new project has a wiki page, IRC channel, mailing list and code repo. It’s a thing!

November 10, 2008: A DBus protocol is conceived for communication between the libindicate client library and the applet which displays the menus. It is not based on a freedesktop.org specification.

November 20, 2008: Private development begins on Notify OSD (codename: alsdorf), a replacement for notification-daemon which displays notification “bubbles” based on an unpublished Canonical design specification.

November 24, 2008: The GNOME 2.26 module proposal period closes.

December 5, 2008: Early private development begins on what will ultimately become the messaging and “me” menus, based on libindicate.

December 8-12, 2008: Ubuntu Developer Summit in Mountain View. The notification changes are discussed simply as a matter of integrating the DX team’s work. KDE doesn’t support the (Galago!) freedesktop.org notification spec, which will require more work.

December 11, 2008: Ted Gould writes about showing persistent notifications, without the clutter of notification icons. It is written in the form of an introduction to a new idea:

I think that a reasonable approach is to consolidate them into what I’m coining as a “messaging indicator.” The goal of the messaging indicator is provide a simple and clean way for messaging apps to provide the notification to the user that other people are trying to talk them while not having to put something in the notification area.

Here we’re seeing a IM message coming in. The notification disappears into the messaging icon and the message can be found underneath that icon. Nothing complex, but it allows the user to know that all of their messages are a single tidy place and there is only one graphic required on the panel for all messaging.

Sounds… familiar. :-)

December 22, 2008: Mark Shuttleworth shares a flash demo of “proposals Canonical’s user experience design and desktop experience engineering teams” introduced at the Ubuntu Developer Summit: Notifications, indicators and alerts, saying:

Experiments are just that – experiments. They may succeed and they may fail. We should judge them carefully, after we have data. We are putting new ideas into the free desktop without ego.

The best ideas, and the best code, will ultimately form part of the digital free software commons and be shared by GNOME, KDE and every distribution.

So, for those folks who were upset that we might ship something other than a GNOME or KDE default, I would ask for your patience and support – we want to contribute new ideas and new code, and that means having some delta which can be used as a basis for discussions about the future direction of upstream.

None of this work is ever contributed upstream.


Since at least July 2010, Mark has made a number of claims about the User Experience Hackfest. They are all roughly of this form:

We had described the work we wanted to do (cleaning up the panel, turning panel icons into menus) to the Gnome Shell designers at the 2008 UX hackfest. McCann denies knowledge today, but it was a clear decision on our part to talk about this work with him at the time, it was reported to me that the conversation had happened, and that we’d received the assurance that such work would be “a valued contribution to the shell”.

My answer to this is very simple: It doesn’t matter in the slightest whether or not this discussion happened. As Mark has said while making similar accusations: code talks.

Lots of people come to FLOSS projects and excitedly promise to work on something. The promise is irrelevant. Good communication? Sure. But ultimately, what really matters is whether or not they deliver. I know this intimately because I have been on the giving and receiving end of it.

Only three Canonical-related modules have ever been proposed for inclusion in a GNOME release: evolution-couchdb (for 2.30), simple-scan (3.0) and libappindicator (3.0). Only one of those was related to panel menus — the libappindicator client library, proposed in February 2010, 16 months after Mark’s “commitment” — and it didn’t even include the relevant user interface components!

Each of the chunks of work we’ve taken on: notifications, indicators, the menus, and all the rest, could be valuable to GNOME and has been done with the intent that it be useful to GNOME. Our feeling is that base politics are playing a bigger role in the final decisions than they should, and we’re disgusted that that be the case.

Base politics? Disgusted? None of these things, in a useful form, were ever proposed for inclusion in GNOME. The facts simply do not support Mark’s extraordinary accusations.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Love flies under the radar

Note: This post is part four of a series of thoughts on the relationship between Canonical and GNOME.

Tempers will occasionally flare in large communities with many stakeholders. There will always be a delta between the goals, strategies and assumptions of different groups and individuals. Unless we achieve perfect transparency and communication, circumstances like this are sure to arise.

Open communication is challenging in a highly distributed environment, of course, but when a disparate network must interact with clusters of comparatively more efficient communicators (co-workers in the same office, for example), a special kind of friction is created.

This is not unique to Open Source, either. Consider the Nokia experience: Years of vicious internal warfare, infighting between and even within divisions, and for what? If Nokia were a squabbling family around the Christmas lunch table, Stephen Elop was the aloof uncle who left to enjoy Christmas Day on a park bench with the local wino instead.

So the sky is not falling. This is not the end of Software Freedom, GNOME, Canonical, the “Linux desktop” or anything else. The cure is communication, and finding better ways of working together.

There’s a very important thing to remember at times like this: Every day, volunteer and paid developers, from around the world and every contributing organisation, are quietly cooperating in their work on GNOME.

It’s not sexy. It’s not political. It’s getting the job done. Filing and fixing bugs, landing all the little changes in a long transition, coordinating releases, and sharing knowledge that will benefit everyone.

This particular brouhaha may be about a single company, but when you read about tensions between Canonical and GNOME, keep in mind that Canonical developers working in the trenches are unlikely to be at fault, and may well be unhappy with the situation too.

They, along with developers from Red Hat, Novell, Intel — and all the others, because there are too many to name — are still very much our brothers and sisters in GNOME.

They’re not involved in the politics. They’re flying under the radar. Spreading the love.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

The libappindicator Story

Note: This post is part three of a series of thoughts on the relationship between Canonical and GNOME.

Tensions rose this week as claims were made and refuted — mostly as comments on blog posts about entirely different issues! — about the collaboration and relationship between Canonical and GNOME.

After actively participating in much of that discussion, Mark Shuttleworth (founder of Canonical and Ubuntu) responded in a strongly-worded blog post on Thursday morning.

He made a range of claims, but in this part of the series I will focus on his response to the release team’s stated reasons for the rejection of libappindicator:

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

Now, I can tell you that I was pretty disgusted with this result.

Please read Mark’s entire post to get a full appreciation for the depth, breadth and consequence of his criticism.


The history of “indicators” is quite long, but as that will be covered in the timeline for part four of this series, I will fast-forward to the introduction of libappindicator itself, during the Ubuntu Developer Summit for Lucid Lynx (UDS-Lucid).

November 18, 2009: Application Indicators are discussed at UDS, aiming to replace the notification area and present a single set of menus on the panel for consistency. The KNotificationItem specification is chosen as a basis for the protocol, but “the addition that we’ll need is the ability to define a menu”.

Actions include “develop the application library”, despite the fact that libappindicator development had already begun, privately, one month earlier (first commit: October 13, 2009). To be fair, it was still pretty raw immediately prior to UDS, but work had clearly begun.

December 3, 2009: The Ubuntu DX team’s ApplicationIndicators wiki page is created. One week later it is updated to include a very thorough set of use cases, architecture documents and a porting guide.

December 16, 2009: Canonical developer Ted Gould blogs about libappindicator, links to the StatusNotifier specification.

December 17, 2009: On the XDG mailing list, Canonical developer Aurélien Gâteau proposes the StatusNotifier specification, a reworking of the KNotificationItem spec first introduced as a draft on September 5, 2009.

January 13, 2010: Ted Gould emails GNOME’s desktop-developer-list (DDL) to request feedback on StatusNotifier. This is the first time libappindicator is raised on a GNOME mailing list. It is already too late to propose for inclusion in GNOME 2.30.

A few technical questions are asked about Canonical’s plan to port applications. Concluding the thread, Dan Winship states: “Anyway, we want a menubar-like tray for GNOME Shell too, and the new spec seems like a good plan.”

January 18, 2010: Dan Winship responds to the StatusNotifier proposal, raising his concerns about the specification, spawning a discussion almost exclusively with Aaron Seigo (which I will cover in another post).

(So rereading this, it comes across as kinda harsh, but it wasn’t supposed to be, so just add a “:-)” to the end of every line or something. :-)

February 6-17, 2010: Canonical developers blog about Application Indicators — including Jorge Castro’s Application Indicator Update, Jono Bacon’s KDE Application Indicators in GNOME and (contractor) Jan Arne Petersen’s Application Indicators — all of which note that patches for application support are already being submitted upstream, ie. GNOME’s Bugzilla.

February 15, 2010: The new module proposals period opens for GNOME 3.0.

February 18, 2010: Colin Walters, a Red Hat developer working on GNOME Shell, raises Canonical’s application indicators work for discussion on DDL.

First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here.

His questions revolve around how applications should use it, how it might fit in with the design plans for GNOME Shell, and suggests that it would make sense for the API to live in GTK+ rather than a separate library.

Ted Gould and Jorge Castro participate in the resulting 11 post thread (there was another subthread, but irrelevant to the proposal itself). Matthias Clasen contributes two grumpy points about Canonical’s approach to collaboration (not designing in the open and asking GNOME developers to discuss API issues on the Ayatana list).

Roughly 6 hours after his last post in that thread, Ted Gould proposes libappindicator as an external dependency for GNOME 3.0, strongly emphasising that the discussion focus only on its inclusion as an external dependency. He includes the key question about the library, raised earlier: “Does this fit the the design goals for GNOME Shell?”

Olav Vitters of the release team suggests that question must be answered before the release team can make a decision. Ted replies, “Obviously that’s a question that I can’t answer. Though, one that I’d love an answer and a discussion about.”

A concern is raised about copyright assignment, and there’s a silly little subthread about versions of the GPL (much less likely to be a problem than the CLA).

The meat of the thread is a discussion about libappindicator’s use of GTK+ menu APIs, with suggestions from GTK+ developers for how to improve the libappindicator API.

Discussion peters out, without answers to the fundamental questions, with Ted Gould having sent a total of 5 emails to a 17 post thread. (Cody Russell also contributed, but not about technical issues.)

March & April, 2010: Two and a half months (Feb 19–May 6) pass without a single discussion about libappindicator on any GNOME mailing list.

Intermission! Let’s take a moment to recall Mark Shuttleworth’s comments about why GNOME developers rejected libappindicator:

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

Intermission over.

May 6, 2010: Last call for comments on module proposals. Dan Winship, a Red Hat developer working on GNOME Shell, replies to the libappindicator proposal with the final word on its relevance to the new shell:

The system status area needs numerous features that aren’t available in libappindicator [...] so libappindicator will not be useful here.

As for the trayicons in the message tray [...] the StatusNotifier protocol that the appindicator work is built on is just… designed to solve some problem other than ours. I still think we don’t want libappindicator.

So while Dan doesn’t think libappindicator fits with GNOME Shell’s system status or notification goals, he doesn’t close the door entirely to StatusNotifier/dbusmenu (the XDG protocol guts wrapped by libappindicator):

And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now.

Ted Gould replies, “Not to criticize your decision, but just to correct a couple of factual details in your e-mail”, noting that dbusmenu is included in KDE and the StatusNotifier spec, and that libappindicator would be ported to gdbus soon. He doesn’t object to Dan’s decision. There is no further discussion.

May 10, 2010: Mark Shuttleworth reveals the Unity netbook user experience to the world during his opening “keynote” at UDS Maverick, and writes about it later that day:

Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

May 16, 2010: The GNOME release team meets, and based on the feedback received, decides to reject libappindicator for GNOME 3.0.

June 2, 2010: The release team announces new module decisions for GNOME 3.0, stating the reasons why libappindicator is rejected as an external dependency.

No Canonical developers reply.

Excluding vala-list discussions about wrapping the API, there is a grand total of five pages of Google results for “libappindicator” in the GNOME list archives.

Understanding the decision

Mark is not a day-to-day participant in the GNOME community (he does run a company, after all), so it’s easy to understand why he has so misunderstood the process and motivations of the community — through the lens of the release team’s rejection reasons.

Let’s go through them:

  • it doesn’t integrate with gnome-shell

I hope I have demonstrated absolutely clearly in the timeline above that libappindicator was not rejected due to a sense of “competition” between Unity and GNOME Shell: The key advice to the release team was given four days before Unity was unveiled.

  • probably depends on GtkApplication, and would need integration in GTK+ itself

Unfortunately, this point is badly written, but it’s related to the suggestion that the API should actually be in GTK+ rather than a separate library. It demonstrates that while the library — conceived and designed without technical or strategic advice from the GNOME community — was rejected, the ideas behind it were not. Mailing list discussions reflected the same view, as shown above.

It’s important to recognise that this is not the behaviour you would expect of those who would discriminate against Canonical, or who had already made up their minds a long time ago.

  • we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

Mark’s response to this was, “We made the proposal, it was rejected.” Well, yes… but keep in mind that he is quoting the rejection itself! :-)

I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”.

I believe the timeline above clearly demonstrates that Canonical did not do “what was required”. Unpaid volunteers regularly do more to get their work into GNOME than Canonical did in this case. I can barely describe how little effort was invested pursuing this proposal.

Ted Gould is not at fault, by the way. If Canonical wanted it done, it could have assigned different people to the task, more people to the task, or anyone at all during March and April.

The flip side to this is that Aurélien Gâteau engaged with the KDE community early and often in his work to update specifications to reflect Canonical requirements, bring in dbusmenu support, etc. I don’t believe the key difference here is between GNOME and KDE, it is in Canonical’s approach to engagement, and its commitment of developers to the task.

  • there’s nothing in GNOME needing it.

Mark’s response:

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”.

This is a simple misunderstanding: No process exists to “pre-approve APIs”. So that’s not the process libappindicator was submitted to… or rejected by.

Any GNOME module can add an optional (or “soft”) build dependency at any time. Jorge, Jono and Jan even blogged about libappindicator support patches being sent upstream… prior to the proposal!

An “external dependency” in GNOME release parlance describes a particular version of a library that is not maintained by the GNOME community, but acceptable as a required (or “hard”) dependency. DBus is a good example: it’s not a GNOME project, but we can rely on a particular version’s API, ABI and protocol being consistent.

The irony is: libappindicator did not need to be listed as an external dependency for Mark to have achieved his goals. Canonical needn’t have engaged at all! (Sure, that would have created all sorts of different problems…)


Mark’s extraordinary criticisms were made without understanding the process, without understanding the quotes he was using as evidence, and frankly, without understanding the GNOME community’s motivations or intentions.

Key points:

  • Canonical barely made an effort to have libappindicator “accepted into GNOME” (which, in the context of his criticism, Mark believed was important or necessary)
  • It did not even need to go through this process anyway, because it did not need to be an “external dependency” in order to achieve Mark’s stated goals (ie. application adoption of the API)
  • So the rejection of libappindicator, for all the sturm und drang, is essentially meaningless — it had no bearing on the opportunity for collaboration between Canonical and GNOME
  • Unity did not exist in the public sphere when libappindicator was declared irrelevant to GNOME Shell, and was not ever the reason why: (a) there wasn’t much interest in libappindicator, or (b) GNOME Shell developers decided they were on a different path
  • Not proven in this part of the series, but worth noting: the person Mark specifically chose to attack, Jon McCann, did not decide to exclude libappindicator because — being a design contributor to GNOME Shell — he felt threatened by Unity. In fact, he had no part in the decision, and didn’t know Unity existed!

But libappindicator is just one chapter in a much longer story… see you in part four! :-)

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Thoughts on GNOME

Note: This post is part two of a series of thoughts on the relationship between Canonical and GNOME.

When you think about the huge mainstays of the Open Source world, GNOME is right up there with the likes of Mozilla, Apache, KDE, the Linux kernel and Debian.

These are the titans of Software Freedom. Massive teams of co-developers, who regard themselves as a family… including the occasional creepy uncle. Individual volunteers work alongside paid contributors with corporate affiliations. Structures are formed to deal with differences of opinion, and facilitate productive collaboration between different kinds of contributors — individuals, corporate stakeholders, hackers, designers. Small teams grow within the larger project. Conferences are established to bring everyone together. Eventually, you’ll even find cliques.

Such communities carry immense history beyond code, such as development tools and processes, community conventions, and as with any large team, the (“we should really document that”) unwritten wisdom of experience. And in-jokes. Always with the in-jokes.

It’s easy to find fault with GNOME. It is, after all, a massive, lumbering project.

Who leads GNOME? Originally, Miguel de Icaza founded and led the project as a benevolent dictator, with maintainers of individual pieces as trusted lieutenants. As GNOME transitioned from science project to core infrastructure, growth in stakeholders demanded more structured decision-making, which eventually led to the GNOME Foundation and then the Release Team.

Today, as in 2000, the Foundation supports the goals of the project, but does not provide technical leadership. Mostly it manages the resources available to the project, maintains relationships with organisational stakeholders and provides a venue to resolve disputes. It may intervene when the project is unable to make a decision or move forward — the most notable cases of that happening include the formation of the GNOME 2.0 release team in 2001, and instigation of a plan for GNOME 3 in 2008 and 2009.

The release team is delegated with a fairly narrow set of technical leadership responsibilities: what to ship and when. Everything else is up to the maintainers of individual GNOME components, and a lot — a lot — of negotiation on the unwieldy general discussion mailing lists. :-)

GNOME has always been terrible at flag-posting places to pitch in. It’s difficult to figure out where and how to get involved, especially if you just “want to help”. Documentation of bite-sized, easy-fixes for new contributors is reliably miserable. Even with the rigorous release process, few developers write down their agenda for the next cycle, which makes it hard to know what they care about and how you might help.

The GNOME community is absolutely shithouse at mentoring and motivation. It takes a lot of perseverance and banging on doors to bring big new ideas to fruition, and most of it has to be done under your own motivational steam. Much of the time, this is is the result of process over people. The words GNOME people use to describe what’s “in” and “out”, “accepted” and “rejected” sound terrible.

There is a deep irony here, because GNOME was founded by the greatest Open Source motivator of all time, Miguel de Icaza. You could send Miguel a completely misguided and broken patch and he’d rewrite the whole damn thing, explain why (in the most encouraging of terms), tell you how much you rocked for contributing, and then… after all of that… he’d praise you effusively in the credits of the next release! Yes, I wish GNOME were more like its father. :-)

There are people in GNOME who are difficult to approach. There are people in GNOME who are of a grumpy or abrasive disposition. There are people in GNOME who are jerks. But throw a brick at any large group of people and there’s a good chance you’ll hit a fuckwit. Of course, there are great people in GNOME too, as well as procedures to deal with problems.

Ideas that were once bold and terrifying have become assumptions, seeping into the DNA of the project. An example: Ten years ago the idea of a six-month, time-based release schedule was wildly controversial. Who doesn’t have a time-based release schedule today, and what are they smoking? GNOME is actually behind the curve now, because the wide adoption of time-based schedules and rise of agile development means “six months” sounds grandfatherly!

Since the beginning, most GNOME developers have regarded their creation as a coherent whole, in two pieces: a desktop user experience and a developer platform. This was practically written in stone during the process of creating GNOME 2.0, when we defined the separate “desktop” and “platform” release sets. GNOME is not a miscellany of parts, occasionally thrown over the fence — it is intended to be an integrated, considered stack. More than the sum of its parts. Decisions are made on this basis, which may sometimes be confusing to new contributors.

Since 2.0, a particular angle on usability took hold, which is loudly criticised as often as it is misunderstood. I don’t feel the need to defend it here, but must note the impact it has on recruitment and approachability. GNOME developers are more likely to reject a new option or feature (different things!) on the grounds of usability, applicability to vision, or consistency across broader goals than many other projects. Not only can that be difficult for contributors to understand, it can be challenging for GNOME developers to describe!

GNOME developers are more likely to take a long term view of improving infrastructure from the ground up than to accept a quick fix hack. Consider the range improvements to the entire Linux desktop network stack spawned by Network Manager. This is why, for much the same reason, Havoc Pennington founded FreeDesktop.org way back in 2000: To promote practical cross-desktop interoperability.

The funny thing is, despite external commentators suggesting that the GNOME community is unaware of or does not accept its faults, GNOME participants are painfully aware of them all. Conversations along these lines were rife long before and long after I was actively involved in the project. Some of these problems are merely a matter of manpower. Some of them involve big decisions being made. Some of them are the fundamental challenges of volunteer-driven and leaderless societies.

Assumptions calcify. Processes calcify. Code calcifies. You can fix a hardening of ideas, but it takes people to do so. Individuals or a small team. Getting involved. Defining a vision. Making decisions. Communicating and compromising. Pushing the needle. That’s how you get things done.

It’s hard work being a contributor, and GNOME sure has its fair share of quirks, but it’s not especially different to any other large FLOSS project with thousands of stakeholders, and most importantly, it’s an open, independent, meritocratic, co-development community.

GNOME is People.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

On the relationship between Canonical and GNOME

I can’t count the number of times over the last three years (!) that I have written and deleted a post about Canonical’s worsening relationship with GNOME. Having worked for Canonical and held a leadership role in GNOME, I’ve felt a weight of responsibility (probably unfounded) to contribute to this ongoing debate — and do so constructively.

My hope in finally publishing my thoughts is to raise the tone of the discussion, document what has happened over the last few years, illustrate why we’ve reached this low point in the relationship between Canonical and GNOME, and consider the options for resolution and next steps.

Unfortunately, what began as a short clarification has grown into a research project over the last few days, and is bordering on the length of a novel. So rather than deliver a single, epic post about everything — in dangerous TL;DR territory — I have decided to split my comments into a series of posts:

  1. On the relationship between Canonical and GNOME (a series)
  2. Thoughts on GNOME
  3. The libappindicator Story (timeline)
  4. Love flies under the radar
  5. The Greatest Show on Earth (timeline)
  6. Moving the needle in GNOME
  7. It’s 2009… and they have a plan (timeline)
  8. The timeline continues…
  9. … TBD (still have to figure out how to split the rest of it!)


Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

How to mount a VirtualBox VDI image

Don’t believe the hype! It is entirely possible to mount a VirtualBox VDI image, just like a loopback filesystem… all you need are the right tools and know-how. Allow me to illustrate.

My apologies, that was the wrong illustration. Onward!

Before we start, it should be noted that you don’t want to do this while your disk image is already in use. That is to say, if you’re running a virtualised host using this image, GTFO.

First, install the QEMU tools. In Ubuntu, you’ll find them in the qemu-kvm package. Whatever package your distribution ships which contains the qemu-nbd binary should be fine.

Load the nbd kernel module. Yes, I’m serious, the network block device module! (Note: All of the following commands require superuser permissions, so escalate your privileges in whatever way makes you most comfortable.)

modprobe nbd

Then run qemu-nbd, which is a user space loopback block device server for QEMU-supported disk images. Basically, it knows all about weird disk image formats, and presents them to the kernel via nbd, and ultimately to the rest of the system as if they were a normal disk.

qemu-nbd -c /dev/nbd0 <vdi-file>

That command will expose the entire image as a block device named /dev/nbd0, and the partitions within it as subdevices. For example, the first partition in the image will appear as /dev/nbd0p1.

Now you could, for instance, run cfdisk on the block device, but you will most likely want to mount an individual partition.

mount /dev/nbd0p1 /mnt

Gadzooks! Now you can muck around inside the filesystem to your heart’s content. Go ahead and copy stuff in or out, or if you’re feeling fruity, have some chrooty: chroot /mnt.

When you’re done, unmount the filesystem and shut down the qemu-nbd service.

umount /mnt
qemu-nbd -d /dev/nbd0

Franklin Street Statement PDF

The Franklin Street Statement can be found on the web in the form of a fairly ugly blog post, which does not befit a document of such importance… and for that matter, neither does the printed form of that page.

I wanted a nice paper copy of the statement to put in a prominent position on my desk, and figured it would make sense to share my rendering. It may be an interesting thing to hand out at developer conferences or Software Freedom Day events.

The document is set in Free typefaces, Liberation Serif and League Gothic — appropriate, given that League is a wonderful Free alternative to Franklin Gothic! I know, I know, you see what I did there. Now… Download the Franklin Street Statement PDF!

Note: I wish the source ODF had survived the wrath of OpenOffice.org’s “eat my document” crash recovery feature, but at least the resulting PDF is fairly easy to edit. :-)

Ubuntu’s Bleeding Edge, an act of niche journalism

I’ve been struggling to write anything of consequence at all recently… but apparently the best way to get back on the horse is to write what you know, so I have embarked on what might be described as an act of niche journalism.

Ubuntu’s Bleeding Edge is a new blog about the action, intrigue and occasional romance of the Ubuntu development branch, for everyone who thinks Release Day parties are only meant to celebrate the start of a new release cycle. It’s an easy way to keep up-to-date about the goings-on of Maverick Meerkat… particularly if the idea of running an ever-changing, alpha-quality operating system scares the bejesus out of you.

The story so far…

It’s a nice way to tackle a problem in bite-sized chunks, have a ready excuse to write regularly, and recall how much I used to enjoy those six month roller-coaster release cycles. It sure helps to have an enjoyable subject that I know pretty well, too!

Check it out, and subscribe to the feed if you’re keen to keep up with the ups and downs of Maverick.

Update: My latest devel branch update covers the removal of aptitude from the default desktop install and the switch to building for i686, both of which have become minor controversies.