A #tbldownunder tip jar for Pia

Update: Cool, now there’s a more official way to contribute back to the #tbldownunder project! The 6% of donations raised by this tip jar will be transferred over soon. Thanks so much for your help! :-)

A year ago, when Pia thought it might be cool to bring Tim Berners-Lee to Australia for linux.conf.au 2013, she didn’t foresee quite how much work the project would involve.

Interesting and prominent public figures like TBL attract rather large fees for speaking appearances, so Pia rallied together a group of sponsors to help out. You can see the list of (awesome) sponsors and the (impressive) list of Tim’s appearances on the TBL Down Under tour information page.

Pia has volunteered hundreds of hours of her time to pull together the project; wrangle sponsors, minders and media requests; and assist with the tour as TBL has travelled through New Zealand and Australia.

But in addition to her time and energy, Pia also put up a large sum of her own money to see the project through, hoping that late sponsorship agreements would cover her risk.

Please thank Pia for bringing Tim Berners-Lee to Australia and New Zealand by making a quick donation to help cover her financial contribution to the project.

Posted in General | Tagged , , | 4 Comments

A Sexual Awakening

Posted in General | Tagged | 3 Comments

QotD: Jon Corbet on linux.conf.au and Linux Australia

In summary, LCA remains unique in its combination of strongly technical talks, freedom-oriented and hands-on orientation, wide variety of topics covered, and infectious Australian humor. There is a reason some of us seem to end up there every year despite the painful air-travel experiences required. Linux Australia has put together a structure that allows the conference to be handed off to a new team in a new city every year, bringing a fresh view while upholding the standards set in the previous years.

– LWN’s Jon Corbet on linux.conf.au, An LCA 2012 Summary

Posted in Quote of the Day | Tagged , , , | Leave a comment

Depression, and the fight of my life

I’ve never really been sure how to say “I have depression”. It’s not like I have it. It comes and it goes, and usually it has me, not the other way around. I’d say, “I’m depressed”, but right now I’m not. Do I say, “I’m prone to depression”? The word “prone” seems appropriate on a number of levels, but no.

Today, I’m fighting depression. And winning.

Every experience of depression is different, but for what it’s worth, you might find this story worth reading. I hope it helps you fight depression in your life, be it yours or that of someone close to you.

When you’ve got to feel it in your bones

Some people refer to feelings associated with depression as anthropomorphic avatars, such as their black dog, stalking shadow, or dark passenger (hopefully without the Dexter connotation). For me, it has always been an insidious evil, a cancer within, and rather like my arthritis — both conditions arrived at about the same time, with roughly the same effect.

One night in my late teens, I awoke to the most intense pain I had yet experienced. My left knee and ankle were roaring emergency signals back to my brain with such ferocity, I couldn’t even tell you if it was dull or sharp. Tears were spurting from my eyes, and I didn’t have enough breath to scream. Unable to move, I banged as hard as I could on the wall behind my head.

Soon enough, my father and stepmother woke and came downstairs to my room. Dad was asking questions, but I still couldn’t speak. My knuckles were white, face contorted, right leg out straight to the toes, left leg raised and bent at the knee. I pointed at my left knee and let out a whimper.

My stepmother decided to take control of the situation. She bent down to forcefully straighten my left leg, completely smashing my record for the most intense pain I had yet experienced.

I had the classic fairytale stepmother: Jealous, duplicitous, manipulative, evil. I don’t say that lightly. By comparison, my stepfather was merely a violent alcoholic. (So now you’re beginning to see some contributing family circumstances…)

I have had a few acute arthritis attacks like this over the years, but more recently it is just an inconvenience. I have to be careful not to provoke it. Sometimes get the vague sense that I should take an umbrella.

The first cut is the deepest

My first experience with depression was similar. During my last two years at school, I felt a growing, previously unimaginable, newly inconsolable sadness. There wasn’t any one reason that I put my finger on. Plenty of correlation, very little causation.

I was well off, went to a good private school, had lots of friends and things that I loved to do: What right did I have to be unhappy?

As it got worse, friends would say, “Why are you so quiet?” and “You’re no fun to be around” and “You should just snap out of it”. But it’s true: I wasn’t fun to be around. I was a morose motherfucker. I went to fewer and fewer gatherings, and received fewer and fewer invitations.

Then I stopped going to school altogether. For weeks. Months. No one called. Not even the school, which prided itself on “pastoral care”.

One day, during the trial HSC exams, I got a phone call from one of my friends. Had I heard the news? One of our classmates had taken his life. Was I okay? I got another call, and then another. Suddenly, with one student gone for months and another gone forever, the “school community” was taking notice.

I wasn’t close to Lucas Wood. We didn’t share a circle of friends, but knew each other through cadets and music. It seems almost absurd to say that Lucas “saved” me, but right at that time I was closer to giving up than I have ever been since, and his actions prompted the intervention. In part, I am here because Lucas isn’t, and that’s hard to forget.

I returned to school for the rest of the year, mostly to shoot and edit the Year 12 leaving video and visit the counselor. There wasn’t much to say to my friends. I was charitably invited to a post-school getaway, which was fun, but we didn’t stay in touch.

This experience (plus a massive, negative culture shift with an awful new principal and head of music) is why I rarely talk about my age, or where I went to school. Few of my friends know at all, let alone first hand. Not talking about it eventually became a habit.

But things are changing: I went to Barker College, graduated in 1996, and I’m 32 years old.

I don’t care if it hurts, I want to have control

Since my first experience of depression, I’ve had some fantastic ups and awful downs, and managed to achieve some great things despite periods of nothingness. But I functioned, performed and achieved only at its mercy.

Instead of fighting, I declared surrender, ceded authority, and allowed it to define my choices. I don’t say that to lay the blame for my actions (or, more often, inaction) on depression as an external force. It is part of me, and I was complicit. My worst failure was to let depression (and contributing factors) become habitual.

Watch your thoughts, for they become words.
Watch your words, for they become actions.
Watch your actions, for they become habits.
Watch your habits, for they become character.
Watch your character, for it becomes your destiny.

After a long bout of truly awful depression, becoming seriously non-functional in the process, things are looking up. The change began in the middle of last year, as pinholes of light in the darkness. I finally kicked open the door in April.

The key, for me, was two words: “I can”. I can fight this. I can adopt better habits to fight it long term, and stop it from owning me again. I can feel better. I can sleep better. I can eat better. I can lose weight. I can talk to people. I can beat this.

So, step-by-step, I did.

I started waking up at the same time every morning. Making the bed. Going for a walk. Having a shower. Getting dressed. Eating breakfast. Maintaining a to-do list. Getting out of the house at least once a day. Cooking dinner. Not looking at computer or TV screens late at night. Going to bed at a sensible time.

If that sounds ridiculous to you, then imagine how bad it was before. Most of the time I didn’t want to get out of bed. I’d rather sleep than hurt all day. If I did, I wouldn’t dress. I’d distract myself with things that might have felt slightly productive. I’d eat total crap. I’d go to bed only when absolutely exhausted, usually in the early morning, because laying awake in bed meant letting my brain run without distraction.

I didn’t give up, and it started working.

Months later, I exercise every morning, keep my apartment neat and tidy, have a wonderful morning routine and a proper place for everything (using my mild OCD for good, not evil).

I cut sugar out of my diet (almost entirely by not consuming huge energy drinks, which come with all kinds of other problems). I eat breakfast and keep to sensible portions most of the time. I drink lots of water.

I’m 30kg lighter. I’m wearing 36″ jeans, down from 42″. I threw away my old belt, and have already moved a belt-hole down on my new one. I’m wearing clothes I haven’t for years.

I’m slowly apologising to the people I failed while I was very deeply depressed over the last few years. This is probably the most “12 step” part of the journey, but it’s important to me. It means I’m taking responsibility for what happened, and taking responsibility for not letting it happen again.

I am even deriving satisfaction and enjoyment from activities and people. That was a distant memory and unlikely fantasy only 6-12 months ago.

Not to mention that I moved to Sydney for a great job, which I pretty much asked to be created for me. “I’d like to save you a recruiting fee: Let me tell you more about why I’d be good for your company” are not the words of a man in the depths of depression!

Now it’s not so much “I can”, as it is “Holy shit, I fucking am!”

Show me your teeth

I’ve hinted at the social anxiety involved in my depression, but here’s an appropriately ludicrous example: my teeth.

Until a few weeks ago, I had large, visible holes on two of my right teeth. I felt hideously self-conscious about them. So every time I’d smile, cue the internal monologue.

Have they noticed them, or are they just being polite? Maybe they hadn’t seen me recently and just thought it was a piece of spinach. But if they saw me this week, then they’d know it wasn’t spinach. But I can’t do anything about it because I’m worried about going to the dentist, and I don’t have enough money, and what else will need to be done? Why can’t I pay for some stupid holes to be fixed? Why can’t I provide for my family, and why can’t I deal with this shit, and why am I so useless?

Immediate un-smile. That’s a crazy negative feedback loop for a half-second smile.

But for $350 and an hour sitting down, now I just smile… and I’ve returned to the dentist since. :-)


Not having much faith in the institution of marriage, it surprised me when I decided I wanted to make that commitment. The risk of my depression breaking things meant I had avoided all kinds of commitments over the years. So should it be a surprise that depression was a contributing factor to the end of our marriage?

I don’t think it’s particularly respectful to discuss the end of a marriage publicly, but there’s two things to say which relate to my depression:

While I’m profoundly sad (and, frankly, embarrassed) about our marriage ending, the grief isn’t all-consuming. It almost was, but my own changes have given me room and strength for compartmentalisation. I can weather grief and sadness without depression. That’s a new thing. It’s pretty amazing, all things considered.

If you see me, and I appear happier than you’ve seen for some time, it’s because of what I’ve found, not what I’ve lost. Please don’t confuse the high of rediscovering my strength for the faux freedom offered by the end of a relationship. It would not offer due respect to either situation.


Though I’ve been planning and writing this post in my head for a while, one of the reasons I chose to post it today is R U OK? Day: “It’s so simple. In the time it takes to have a coffee, you can start a conversation that could change a life.”

Asking is a big deal, even if you don’t get an entirely truthful answer. Merely having the concern and taking the time to reach out might be significant and helpful in itself.

I’ll try to answer any questions in the comments.

Posted in General | Tagged , , | 40 Comments

However vast the darkness, we must supply our own light

Playboy: If life is so purposeless, do you feel that it’s worth living?

Kubrick: Yes, for those of us who manage somehow to cope with our mortality. The very meaninglessness of life forces man to create his own meaning.

Children, of course, begin life with an untarnished sense of wonder, a capacity to experience total joy at something as simple as the greenness of a leaf; but as they grow older, the awareness of death and decay begins to impinge on their consciousness and subtly erode their joie de vivre, their idealism — and their assumption of immortality.

As a child matures, he sees death and pain everywhere about him, and begins to lose faith in the ultimate goodness of man. But if he’s reasonably strong — and lucky — he can emerge from this twilight of the soul into a rebirth of life’s élan.

Both because of and in spite of his awareness of the meaninglessness of life, he can forge a fresh sense of purpose and affirmation. He may not recapture the same pure sense of wonder he was born with, but he can shape something far more enduring and sustaining.

The most terrifying fact of the universe is not that it is hostile but that it is indifferent; but if we can come to terms with this indifference and accept the challenges of life within the boundaries of death — however mutable man may be able to make them — our existence as a species can have genuine meaning and fulfillment.

However vast the darkness, we must supply our own light.

– Stanley Kubrick, Playboy Interview with Eric Nordern, September 1968

Posted in Quote of the Day | Tagged , | Leave a comment

Parting ways

After nine years together, Pia and I are separating. This is a mutual and amicable decision, and we wanted everyone to know that we’re both okay. Pia has also written about it.

Although it’s a rough time in many ways, and both of us will greatly appreciate the support and company of our friends as a result, there are some silver linings.

One is that Pia and I are still great friends, and unless we royally screw up this process, we have every opportunity to continue being the very best of friends. That’s certainly what we’re aiming for, anyway.

Another is that I’ll be moving to Sydney relatively soon, and will have more opportunities to catch up with all my friends there. Yass has been wonderful, but a bit lonely at times. Pia is planning to stick around the Canberra area for the foreseeable future.

Ultimately, we’re doing okay. There’s pain, of course, but not much weirdness. Time has and will heal those wounds. As Pia says, you can still invite us to the same parties. :-)

Posted in General | Comments Off

Trying to will a world into existence

From James Cameron’s introduction to an early scriptment of Strange Days:

At the beginning of any writing project is the agonizing period in which nebulous ideas dance before the mind’s eye like memories of a dream, and vaporous vague shapes take on human form and begin to answer to their names.

Trying to will a world into existence. I circle around it, nibbling at the edges, writing notes about the social infrastructure and expounding to no one in particular about the themes of the thing.

Then slowly a change happens. Without warning, it becomes easier to write a scene than to write notes about the scene. I start sticking words in the mouths of characters who are still mannequins, forcing them to move and to walk. Slowly their movements become more human.

The curve inflects upward, the pace increases. The characters begin to say things in their own words. By the end of this period I’m writing ten pages a day. The last day becomes endless, often stretching round the clock to the following noon. The curve becomes almost vertical as the thing seems to come alive. I become a witness only, a court reporter getting it down as fast as I can.

Posted in General | Tagged , , , | Leave a comment

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.

Posted in General | Tagged , , , , | 39 Comments

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.

Posted in General | Tagged , , , , | 19 Comments

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.

Posted in General | Tagged , , , , | 163 Comments