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.

This entry was posted in General and tagged , , , , . Bookmark the permalink.

163 Responses to Timeline: The Greatest Show on Earth

  1. Aaron Seigo says:

    Three clarifications (I can’t speak to the rest of the blog entry, and I won’t because I’m not in a position to do so):

    * KDE Plasma does support the Galago notification DBus service now (didn’t in 2008; i believe it was an 09 or maybe even an early ’10 development?)

    * the Galago DBus service was proposed to fd.o but really never did go through a proper vetting process and was essentially deaf to any and all external requests; one request we did make was eventually implemented (in slightly modified but equally valid form) without any warning or feedback to the rest of those implementing the spec by the gnome-shell devleopers

    * Canonical Kubuntu developers did try to upstream their KDE patches for notifications as well as the messaging menu; due to how it was developed and therefore did not mesh with upstream goals, a story very very similar to the one you tell here from the GNOME perspective, those patches were rejected. They were then offered again with no modification after a period of time, and the response was the same.

    Definitely an unfortunate period of interactions, any way you slice it.

    • Jeff Waugh says:

      Was the KDE Plasma support for Galago contributed by Canonical? And your third point is about that KNotify rewrite stuff I mentioned, right?

      • Aaron Seigo says:

        “Was the KDE Plasma support for Galago contributed by Canonical?”

        Volunteer contributors within the Plasma team did the actual coding; the decision to adopt it was taken by myself and a couple other KDE developers after discussing ways to improve the user experience when running apps from different toolkits in a Plasma desktop session. Canonical wasn’t involved.

        Note that we still have the full KNotify stack as well, and the Galago service is supported on the application side via KNotify, so KDE applications work nicely with shells with Galago. Plasma also supports Galago as a host, allowing those notifications to be shown like any other.

        We don’t yet have support for the latest change to the Galago spec; that was sprung on us by gnome-shell devs, but we are in favor of the change. It was one of the things we hoped / asked for, so while the process wasn’t good it at least turned out ok in terms of changes meeting stakeholders needs.

        Ok, that’s probably more than enough irrelevant detail 🙂

        “And your third point is about that KNotify rewrite stuff I mentioned, right?”


        The Ubuntu-style notifications and messaging app components for KDE Plasma are available as independent 3rd-party add-ons which are maintained by Canonical employees. So they are still available to users and some of them ship with Kubuntu and are enabled by default.

        • Jeff Waugh says:

          Does KDE ship anything not maintained in KDE infrastructure?

        • ScottK says:

          Kubuntu ships the same notifications as upstream KDE. For one release cycle we shipped an option (not default) for notify-osd like notifications, but default has always been the same as KDE.

          It’s now in a separate package that’s not in the default installation. The maintainer is a Canonical employee, but he does this particular project on his own time.

        • ScottK says:

          The messaging menu (which is the closest we get to an indicator in Kubuntu) is shipped by default. The patches to support it as an optional dependency are all integrated in the relevant upstream applications (Kmail, Konversation, Quassel, and Kopete). libindicate-qt is (now, but not originally) maintained in Launchpad and is an optional build-dependency for kdelibs.

      • Reconciling KDE and GNOME notifications by proposing some modifications to the Galago spec on fd.o mailing list was one of the tasks I did as a Canonical employee. I also went on and implemented the relevant changes in both libnotify and Plasma. Changes on both sides got upstreamed.

        Another tasks I did as a Canonical employee was to implement a KDE version of notify-osd, which shipped as a Plasma patch in Karmic. As Aaron said it was proposed upstream (without much hope of acceptance) and rejected.

        At UDS L, the Kubuntu devs told me they wanted to drop the Plasma notification patch in Lucid. This prompted me to create the Colibri project, a stand-alone implementation of notify-osd like notifications for Plasma. As Scott says, I created and maintain this project on my free time.

        • Jeff Waugh says:

          I really wish your Canonical/GNOME colleagues had the opportunity to work so closely with upstream! In an upcoming post, I will contrast what you were able to do compared to them. 🙂

          • ScottK says:

            Of course from the data provided the problem could be on either end (or more likely both) of the interface. Given that both KDE and Canonical are experiencing more trouble in their interaction with Gnome than in their (not untroubled) interaction with each other, I don’t think a dispassionate view of the situation would lead one to the conclusion that the troubled relationship is all, or even mostly, Canonical’s fault.

          • Jeff, are you actually suggesting that Aurelien is specifically given different guidance for collaboration with KDE than Ted was for Gnome? How bizarre.

            • Jeff Waugh says:

              I don’t know about the guidance, but the results speak for themselves. His work was done in close collaboration with upstream, while the DX team’s GNOME-based work was not.

    • Hey Aaron,

      I’ve pretty much stayed out of the conversation because it has been pretty polarizing but I would like to point to your comments of why it takes time to agree on a spec at Freedesktop. I was a developer on Galago spec and even then I knew it was the wrong spec and didn’t want it to become a blessed standard. Not that it was bad per say, it was a start, but that we had no idea what we really needed for a notification bubble spec as evidenced by the creation of KNotify and NotifyOSD. I wanted people to experiment and find out what worked and what didn’t. Too many specs were being shotgun developed with a mentality that everyone would have to implement it if it was put on Freedesktop.org. If I had my way, it would have never been a fd.o spec, but a basis for discussion on a spec we would have liked to see on fd.o. But in the end I went on to more important things and decided it wasn’t worth fighting that battle. I had no idea, and from Jeff’s write up others didn’t either, that KDE was using the spec. In fact from my hazy memory of the time KDE was pretty against the spec as they had already started KNotify. It should also be said that the people who developed Galago at first and the gnome-shell team who eventually added the extra functionality are two different teams. For all intents and purposes Galago was a stagnant project. Someone just took it and ran with it for the shell.

      One other thing to remember is D-Bus took 4 years to get to 1.0 and roughly 3.5 years since the first spec landed for KDE to accept it as a replacement for DCop. We were developing it in hopes that it would be universally accepted but we didn’t push anyone. I merely had conversations with yourself, Thiago and Zack among others. When KDE did finally confirm we pushed back the 1.0 release to address all the concerns KDE needed fixed before adoption (to be sure, there was involvement with KDE folk before this point but this marked full acceptance). That is a bit of an anecdote on how a successful collaboration on fd.o went down.

      Not that every spec should take 4 years to settle but it is important to get it right if it is going to be supported for a long time and there should be a right of any party to reject it and not have it forced upon them if it doesn’t fit there needs.

  2. On the free-rider problem, I don’t think that free software projects can have free-rider problems, because by nature their products are not “consumed” in the sense that they are finite. On the contrary, most free software projects are in fact much better off when they have lots and lots of “free riders”(!) because the increased momentum and visibility benefit the project in lots of indirect ways.

    I’m still reading the rest of this post, but good job on it so far!

    • Jeff Waugh says:

      Hmm! Been thinking about this a lot since you commented. It’s interesting stuff. What if the limited resource is developer capacity to respond to bug reports and feature requests?

      Consider Denby, my Twitter client*. When I had 4 alpha testers, it was very easy to educate them about the state of Denby, its features, known problems, etc.

      When Twitter whitelisted me for sitestreams, I was able to expand the number of alpha testers to an arbitrary number. I now have 44 alpha testers (though only some of them are regularly using it, the bastards).

      Suddenly, things got tougher. I didn’t know the people as well, I didn’t have quite so direct, personal contact with them. I had to start documenting known problems or missing features, or I would be inundated with questions.

      Now imagine Denby with thousands of users, millions of users, or at Twitter scale, hundreds of millions.

      I’d write the rest of this comment, but I have to go and change my pants.

      You see what I mean, right? The work created by one Ubuntu kernel problem might dwarf the same problem in… a distro with fewer users. I won’t name one. I might offend Greg K-H. 🙂

      * This hypothetical is sponsored by… Denby!

  3. Greg K-H says:

    Minor nit:

    > 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.

    Not true, at the time Canonical had a number of kernel engineers on staff, and had
    for many years. They were being forbidden to contribute upstream, which caused
    a number of them to quit over those 4 years, and others were hired.

    Anyway, great series of postings, keep it up!

    • Jeff Waugh says:

      Thanks Greg! I will update the post once I verify (not that I doubt it very much). 🙂

    • Hi Greg 🙂

      If you are ever interested in finding out how things really work inside Canonical, or have over the past 6-7 years, you know how to reach me.

      Canonical is far from perfect, and as an open source citizen we’ve made a lot of mistakes over the years which I’ll readily acknowledge, but your statements about Canonical policy are unfounded and untrue.

      Take care…

      • Greg K-H says:

        Huh? We talked about this very topic after my talk, and you agreed that the kernel team hadn’t been contributing upstream at that point in time and that you would work to make things better.

        My comments about “not allowed to contribute” were based on conversations I had with former Canonical kernel team members, and I thought they were independently verified at the time as well.

        I was just trying to point out that I felt Jeff’s comment about my talk was a little bit incorrect, nothing more, and trying to place it in the historical context in which he was doing so.

        • Jeff Waugh says:

          I have added an update to that section which will probably please and disappoint both of you at the same time. 🙂

          • Greg K-H says:

            Heh, nope, no objection from me, thanks for the update.

          • I’d say that your attempt to hedge in Canonical’s favour by invoking ‘company strategy’ is fairly pointless; after all, the strategy is exactly what Greg complains about. A similar point applies to your earlier, pre-edit comment that “Yes, it would have been nice if Canonical contributed more, but if they don’t have the capacity to do so?”

            The capacity isn’t something that you (as a company) magically have or magically don’t, just as your company strategy isn’t some sort of unchangeable encumbrance. You either choose to hire enough engineers to have the ‘spare capacity’ to make upstream contributions, or you don’t. You either set a company strategy / policy of encouraging upstream contributions, or you don’t. It’s a simple choice. (You can argue that there’s an angle of whether you have the financial resources to make a free choice here, but that obviously isn’t a very convincing objection in the case of a company which was founded with a business plan which relied on it being bankrolled to lose significant amounts of money for several years). The whole substance of Greg’s complaint is that Canonical chose, as a ‘company strategy’, not to have the ‘capacity’ to make significant upstream contributions. In attempting to hedge around his objections you wind up helping to make his point for him. 🙂

            In Canonical’s favour, after a year or two of criticism from Greg and others on this, Canonical have definitely changed direction here and started, as a ‘company policy’, increasing the engineering ‘capacity’ they have available for working upstream. 🙂

            • Jeff Waugh says:

              Thanks so much for rubbing it in, Adam. 😀

              • I’m helping! I’m helping!

                Seriously, though – I think it’s a point worth making as I get _really tired_ of the standard fallback excuse that $something_inconvenient ‘isn’t company policy’, which is effectively just saying ‘I’m not going to do it. Ner ner.’

      • Scott James Remnant says:

        Matt, I concur with Greg that engineers on the kernel team, and on other teams at Canonical were told directly not to spend their time contributing upstream.

        Now it’s not true this this is global, there are certainly engineers who have been allowed to or even encouraged to work on upstream problems. Sometimes this has been a narrow permission (contribute this work upstream, but no more) and other times has been more liberal.

        It would be fairer to say that Canonical’s policy is to work upstream where it most benefits Canonical. In the kernel, there was always so many others working upstream that it was in Canonical’s benefit to concentrate on the integration of the kernel into its own distribution.

        • Scott,

          Anyone with finite resources will contribute where it benefits them most. Were kernel engineers told not to upstream work that benefited Canonical and would be welcome upstream, or did concentrating “on the integration of the kernel into its own distribution” mean that the engineers were working on issues not suitable for upstream? At least for me, that would make a big difference in my opinion.

          • The early kernel team at Canonical focused purely on the distro kernel package – there simply was no room for more. As the team grew, they started to generate more and more patches to make things like hardware work. Bear in mind, we are always doing that work against a stable version of the kernel for which the merge window has typically closed. So, policy was to develop, test and put into production those patches, then send them upstream, where they would be integrated into a subsequent stable release of the kernel. Even more recently, as we’ve started to be ahead of the curve on subsystems like touch, we’ve published work for inclusion in mainter branches before it goes into Ubuntu, and taken on maintainership of things like AppArmor.

            Each of these steps is natural, logical, and predictable. Greg K-H’s commentary misses the point entirely. As Linus, and MDZ, have said here, free-riding is the point of free software – it’s what grows adoption, which leads inevitably to contribution, albeit in different forms.

            Folks here who are saying that developers at Canonical are BANNED from contributing upstream are misrepresenting the truth. Yes, we are totally disciplined about where we work, where we focus, what our process is at any given time. I’m rather proud of that discipline, it’s part of what has made Ubuntu stand out from the competition – not through selfishness, but through focus on what will make the biggest difference to users first, and the ecosystem second. Users like that, the ecosystem has benefited too.

            • Zinahe says:


              Your response obviously sounded like a lame excuse, and I’m not a kernel developer to figure that one out.

              “We are disciplined not contribute to upstream because we want to focus on our users ! ? ! ?”. Really ??

              Have you completely forgotten that 95% of what you provide to your “users” came from upstream in the first place. I don’t see how upstream contribution can possibly distract one from focusing on users. LAME.

            • jargon says:

              It’s mystifying, your talent for digging your self deeper with each post/comment.

        • I know you’re trying to help, Scott, but I think this is muddying the waters further.

          It has always been standard practice to submit upstream the code written in the course of developing Ubuntu. As the person running engineering at the time, my stance on this is pretty authoritative.

          However, I’m not surprised that people are still confused about this because there are a lot of different ideas about what it means to contribute. Some people feel that “contribute what you create” isn’t the right kind of contribution, and that companies should sponsor development which isn’t directly relevant to their business, perhaps as a philanthropic effort. Canonical historically hasn’t done much of that.

          It also happens that, particularly in the case of the earlier Ubuntu kernels, most of the work of developing Ubuntu doesn’t involve writing a lot of code. It’s a lot more curating patches from upstream, distributions and third parties to stabilize the stack.

          I hope this sets the record straight, and that I don’t need to write any more blog entries on this topic.

  4. Stefans says:

    I’ve said it often in discussions about politics, where one major party claims that the voters who chose an outsider party (but in the same political spectrum) killed their victory: Voters are not owned. It doesn’t matter if a vote might have been useless or if more votes should go to a party that has done a lot of real work in government in the past.
    The point is that if a party does not deliver the political direction that the voters want, then they will lose votes.

    I think it is quite similar with free-software:
    The first group who publishes an integrated user-interface for gimp will get my “vote”. I don’t care if all the important developments to colordepth, filter functions, plugin system and so on are made by another group. I care for a Gimp that I can actually use. And that includes, that all functions are in one maximizable window.

    Or another anecdote: When I first installed Debian on my laptop, the installer did not install X or gave the option to install X. So I, a user new to Linux, was greeted by a system that I could not use at that time. One day later I installed Ubuntu and everything worked from minute one.
    I don’t care if all the debian developers now say that they do all the hard work and Ubuntu is “free-riding”. The point is: they failed to deliver for me! Their decisions where probably perfectly reasonable. But for me, they had simply failed to give me a tool I could work with. Ubuntu did.
    And that’s all the magic there is.

    You work for Novell and think that you do all the hard work but everyone uses Ubuntu? Guess why?
    If the work that is done by Ubuntu is so unimportant or so minor, then simply do that work for your distribution and everyone will come to you!

    • Michael says:

      While I would not personnaly see “having users” as a reward, if you choose to go where people do the easy stuff to get users and let hard work to others, you just give no incentive to have people do the hard work, and shoot yourself in the foot.

  5. Hey! For what it’s worth, LTSP didn’t have an effect on the decision to stay with an older GDM. LTSP have been using SSH/LDM in Ubuntu since 2005, so it hasn’t been dependent on things like XDMCP for a long time.

    • Jeff Waugh says:

      Ahr, thanks! Funny thing: I actually added that bit as an update because I felt like it needed the benefit of the doubt… 🙂

    • bkor says:

      IIRC various distributions stayed with the old GDM for a while as not all features were ported to the new version

      • Michael says:

        Yup, Mandriva did it too, and Frederic Crozat was testing for each release if the new GDM was good enough. I think Debian also did, for similar reasons, even if I do not know exactly what was missing, maybe themes support, and stuff like that.

        • The “new” GDM was missing support for XDMCP, among other features that precluded it’s immediate adoption in Ubuntu and other distros.

          • Ray says:

            I wonder why everyone keeps saying that (you’re not the first or even probably the 10th)? As far as I remember, modulo bugs (and I’ll grant there have been more than a fair share) and some nonessential configuration, XDMCP support has been around since 2.22 and earlier. I don’t think it was ever dropped or anything. Granted 2.22 was a very long time ago, so I may be misremembering.

            A lot of things did get taken out of GDM, though:

            1) the inaccessible themed greeter that used an unspecified theme format which broke in weird ways that lead to crashes and misrendered login screens depending on which monitor you have plugged in

            2) Support for logging in a second time in a nested session (and all the associated brokeness that comes along with logging in twice with the same username, and all the associated brokenness that comes along with using Xnest or Xephyr)

            3) Support for static configuration of multiple X servers at boot (versus XDMCP which is dynamic)

            4) the horrible config matrix dialog of doom that was gdmsetup.

            5) maybe some other smaller stuff that i don’t remember off hand.

            You could certainly argue that any of the above were reasons to stay with the pre-rewrite GDM. A lot of people have made those arguments before, in fact.

            I just don’t understand where the XDMCP thing is coming from. There have been bugs, but there were XDMCP bugs in gnome 2.20, as well, and even earlier. It seems like there have historically always been bugs in XDMCP. Thankfully, through the patience of vested interests like Dave Richards (and Brian) most of those issues have been stomped out.

            I’ll also add Robert Ancell (from Canonical for those who don’t know) did quite a bit of work on GDM post-rewrite to smooth out various issues.

      • foo says:

        GDM3 is still pretty shit and from what I understand the reasons for that are intentional design decisions.

  6. Jeff, thanks for the timeline and the props for UNR. I simply don’t agree with your conclusions; if anything, your timeline supports my view that we *did* discuss the indicators work openly, and that *was* ack’d, then ultimately ignored.

    July 30, 2008: Ted Gould blogs about putting a menu at the top right of the screen
    => indicators

    September 18, 2008: Ted Gould blogs about the ongoing modified FUSA work
    => all of this code is public. You say “never contributed” but Ted went to explicit trouble to make it easy to consume as a set of distinct patches. I suspect Ted discussed landing those patches in FUSA upstream, you can draw your own conclusions as to why they did not. They were certainly not precluded from landing upstream by any Canonical policy. The upstream maintainer for GDM and FUSA would be… Jon McCann?

    October 24, 2009: Jon McCann gives credit to Ted and others for their contribution to discussions about the panel in the UX hackfest (yes, including what became the messaging menu, documented in the write-up, ultimately abandoned by Shell), when he now says that work was not discussed.

    You say “code talks”, yet don’t acknowledge that the code was available largely throughout, and certainly in usable form before alternatives were postulated elsewhere.

    I think we’ve done this the right way: we talked about the work early, we made it available as patches that were easy to consume, we *delivered* working code, we proposed it in the way it was suggested we propose it.

    Apparently, different groups of smart people can look at this timeline and draw very different conclusions. Fair enough, we’re each entitled to our perspective. But if I consider that this work was done as openly as I think it’s feasible for us to do work, then I must conclude that we can’t expect a better result in future. Rather than setting Gnome adoption as a goal, we should focus on FD.o standard setting, then deliver working code that can be adopted optionally by those who are interested in that. On the flip side, we can’t limit Ubuntu to the options presented by Gnome, if we think a broader umbrella will give users a better platform.

    Gnome is entitled to expect its participants to participate on the playing field it creates. By definition, some will not be able to do so. Unfortunately, if the only way to make an impact on Gnome excludes interesting contributions, Gnome will be poorer for the policy.

    By my reading, Gnome could have had a nice, clean, FD.o-compatible set of indicators a lot earlier, and for whatever reason, now it does not. I think it’s worth some introspection within Gnome as to whether that’s the best result, and if not, how Gnome might ensure that in future it gets the best result. To my mind, the result is a pity, but it’s the choice of the Gnome leads, and I respect it.

    • Jeff Waugh says:

      I think we’ve done this the right way: we talked about the work early, we made it available as patches that were easy to consume, we *delivered* working code, we proposed it in the way it was suggested we propose it.

      This is simply wrong. Very little code was delivered to GNOME, particularly all of the work leading up to application indicators, and even then, only the client library. No attempt was made to integrate any of your user experience changes. Your misleading argument might be easy to pursue while people don’t fully understand what libappindicator actually is… but my series is not yet complete.

      Canonical built FUSA modifications on the old GDM codebase. Of course it wasn’t upstreamable. I can’t believe you’re raising Jon McCann’s name again. It is unbecoming and unprofessional of a company head to attack the employees of his competitor, particularly in the context of an Open Source project.

      You did not participate upstream. You did not submit more than 3 modules for inclusion (with only one semi-related to this work, libappindicator, which was the first to even implement the freedesktop.org spec, and again, only the client library). Those are the most basic methods, the benchmarks, for even attempted contribution. It was not the choice of “the GNOME leads”.

      You are misleading the community.

    • Jeff Waugh says:

      You say “code talks”, yet don’t acknowledge that the code was available largely throughout, and certainly in usable form before alternatives were postulated elsewhere.

      Availability is not contribution. I fully acknowledge availability. In fact, I rigorously documented it.

      You wouldn’t have the cojones to pull this crap with Linus. Don’t pull it with GNOME.

      • Justyn says:

        Can you elaborate on “availability is not contribution” in this context?

        • Jeff Waugh says:

          Say you write a patch for the Linux kernel.

          If you have that change sitting in your git repo, it is not yet a contribution. You haven’t taken it through the conventional channels for contributing a patch to the Linux kernel.

          If you blog about it, and even if you’re absolutely sure Linus reads your blog, it is still not yet a contribution. You haven’t taken it through the conventional channels for contributing a patch to the Linux kernel.

          If you send your changeset to the Linux kernel mailing list, then you have attempted to make a contribution.

          If it’s picked up immediately, you’re a contributor! If you have a discussion about it, change it, and try again, and it’s accepted, you’re a contributor! If you submit a changeset again but it’s still not right, then hey, at least you tried.

          Canonical had a bunch of stuff. It was shipped in Ubuntu. It was not contributed to GNOME. It’s as simple as that.

          • @yjmbo says:

            So, your thesis depends on this precise definition of “contribution”. If I understand you, you are saying that code is “contributed” only when it is successfully accepted, including when acceptance requires you to change the code in directions that are not in your primary scope.

            It seems to me that Mark’s definition is different, and more in line with the standard dictionary definition of the word, in the sense of “a gift”.

            Now there is value in a community-specific jargon overloading other meanings of a word, when it leads to denser and efficient communication. But this example I don’t think it is.

            With this in mind, there are two versions of your last paragraph there :-

            * GNOME did not attempt to use well-known available working code to improve their own project
            * It was not contributed to GNOME

            • Jeff Waugh says:

              OK, then perhaps we should revert to a more useful word, “upstreamed”. Upstreaming is advantageous to both the upstream and the downstream, and it’s not laden with emotional value like “gift”. Every line of Open Source code is a gift in some sense! 🙂

              • @yjmbo says:

                Good; I agree that “upstreaming” is valuable, both as a word and a desire. The careful use of words aids communication 🙂

                Upstreaming is valuable to downstream, at least technically because they don’t have to maintain a divergent patchset as upstream evolves. But if everything a downstream consumer does is upstreamed, what does the downstream have left that differentiates them from upstream itself?

                What differentiates Ubuntu from Debian? From a generic OS presenting GNOME? What should differentiate them if not differences in their code? Perhaps a lack of upstreaming is what defines them … which is what you seem to be discussing.

                • Jeff Waugh says:

                  You have asked precisely the most difficult questions at the heart of this debate! 🙂

                  These are questions I’ll return to, but I hope you’ll think about them quite a bit in the mean time and let me know what you think.

              • yjmbo: my conclusion is fairly simple, and it’s that distros should do exactly what we’ve always vaguely said they do: integrate and polish. That does not involve intentionally differentiating significant chunks of code from upstream, note. It means building sensible versions of everything to work together, testing the whole thing works as a coherent whole, and making choices like ‘do we build with support for X’. That’s the appropriate position for a distro. Maintaining significant new or forked code is _not_ the correct position for a distro. Most longstanding distros, including Debian, Fedora and SUSE, have reached more or less this conclusion; it’s at the base of Fedora’s ‘work upstream’ principle – http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream .

                • Jeff Waugh says:

                  I don’t think “integrate and polish” is enough for the future of Software Freedom, and this is where I have quite a bit of sympathy for what Canonical is trying to do with Ubuntu.

                  If we want to take Software Freedom to the greatest number of people as possible, we have to make it awesome. Distros need to be part of that equation. In fact, distros are likely to be the key link in that equation, because they have the relationship with users. Such distros would clearly have an incentive to invest in user-positive research and development.

                  Should user experience innovation be done outside upstream co-development communities? That’s a key question. Canonical’s answer doesn’t seem particularly convincing to a lot of people who have contributed to Ubuntu’s success.

                • @yjmbo says:

                  That’s a really clear statement from Fedora; I have had a quick look but I can’t find any simple statement from Ubuntu.

                  I agree that a “customised” collection of otherwise-untouched upstream code is valuable; a complex project has many different use cases, and a distro can add significant value by pre-selecting a working set of configurations/versions.

                  I’m not entirely sure that’s what Ubuntu is trying to be; the phrase “experiment” keeps on popping up and it seems like a pretty poor experiment to just repackage existing code. Writing new stuff and seeing it it works after exposure to a large number of people is also valuable. Ubuntu gets press and eyeballs, it gets feedback that is available to everyone. Sometimes the ideas are more important than the code — after all we can’t get to the insides of an iPhone but we now have Android …

                  Stepping away from GNOME, how do you feel about the origins of Upstart and its use in other distros? Did Upstart as a project benefit from shipping in Ubuntu 6.06? Now in that example its true that Upstart isn’t really based on some other large project, so it isn’t a perfect analogy. But it is new code that Ubuntu used first …

                  • Jeff Waugh says:

                    I can’t find any simple statement from Ubuntu.

                    The old quote is something like, “Ubuntu brings together the best of what the Open Source world has to offer, every six months”. Beyond that, in terms of changes in the distribution vs. upstream, it’s up to Canonical.

              • Jeff: I should have clarified that absolutely distributors have an important role to play in doing the heavy lifting, but the point is that they shouldn’t do it (exclusively) downstream. Obviously if Developer X works for Company Foo and is the author of Some Cool Feature, there’s a big chance that it’ll land in Company Foo’s product before any other comparable product; but it shouldn’t be written there, and it should land upstream first. I know _you_ know all this, but for the wider audience 🙂

              • yjmbo: on Upstart – well, Upstart (to Canonical / Ubuntu’s credit) has a clearly identifiable existence independent of Ubuntu; it has an ‘upstream’. Even though that upstream is hosted on Canonical / Ubuntu architecture, there’s a functional separation there. Upstart development can happen independently of Ubuntu.

                As you correctly note, the situation is different for GNOME; since GNOME is an existing project with its own infrastructure, it’s not as feasible to treat a Launchpad module as ‘upstream’ for a core GNOME component, say. Since upstart is an independent project, a Launchpad module serves perfectly well as an upstream.

                Launchpad is one of the best examples of a good ‘upstream’ contribution by Canonical / Ubuntu, really.

              • Jeff

                Do you not accept that “upstreaming” requires two to tango? That getting those patches accepted would require the approval of folks that, in my view, have handled this conflict of interest poorly? Would you look into the discussions around those patches in more detail?

                I think Ted’s blog is instructive. He doesn’t say “this is in a PPA”. He says “here’s a carefully broken out set of patches with logical descriptions of each piece”. Who would be the audience for that statement? End-users? Or upstream?

                • Jeff Waugh says:

                  I do accept that upstreaming requires two to tango. Upstreaming is inherently a negotiation, and it is like that for everyone. Part and parcel of the process.

                  You speak of patches and conflict of interest, and based on the rest of your comment, I’m pretty sure you’re still referring to the FUSA changes. The answer to that is very easy: GNOME moved on with the new GDM (adopting it during the release Ted started work on FUSA), some distros stuck with the old GDM, so the FUSA changes were very much stuck in old GDM land. There’s no conflict of interest here, just an unfortunate release skew.

                  Could GNOME have managed the GDM transition better, for its distributors? Probably. Could it have maintained the two versions of GDM and all of the interfaces to them (such as FUSA) through one, perhaps two, release cycles? No, that would not be a good idea. GNOME could have delayed the introduction of the new GDM, but then I wonder how much maintainers would ever get done if the release team (or anyone else) could make that kind of decision.

                  Does any of this imply a “conflict of interest”? I don’t think so. But if it did, someone could’ve raised hell.

                  But remember, all of this was prior to Canonical’s work on libindicate, notify-osd, messaging+me menus, libappindicator or Unity. You’ve generalised this idea of patches and conflict of interest across the entire span of time, alleging political decisions on the part of the GNOME community in general and specific individuals within it. You’ve repeated those allegations since at least July 2010, but most viciously only last week.

                  History does not support your thesis, despite some terrible mistakes made on both sides.

            • Jesse says:

              I think something that is glossed over by this comment is how hard it can be to get two different pieces of code, done by different authors/teams, to work as a coherent whole. I’m not a GNOME contributor (yet!), but I am a software developer by trade, and it can take a lot of work to integrate code from different people who aren’t on the same page. So, the characterization of a “contribution” as “well-known working code” that GNOME developers simply ignored is a little simplistic. It may “work” in the context in which it was written and at the same time not make a great addition to a larger body of code without significant modifications. Carelessly throwing together different chunks can easily lead to a confusing, brittle and ugly mess.

              As to the term itself, “contribution” may be slight bit of a euphemism, but AFAICT the definition that Jeff employs has wide acceptance in the free software world.

          • nzjrs says:

            I believe hope of collaboration died when git won the DVCS wars of 2008 and Canonical kept with bzr. Thus enshrining, or cementing a path to, a corporate policy where development of upstreamable features is done apart from upstream.

            Perhaps that is too harsh, or even too charitable, ascribing technical reasons to decisions that other might see as made for more selfish reasons.

            Nevertheless, it strikes is as hypocritical for Canonical to be happy setting the rules of collaboration for projects they control (i.e. hack in bzr, CA where necessary, translations vi LP, etc) but unwilling to abide the rules of GNOME (use git, discuss on mailing lists, use bugzilla). It all seems so unprincipled.

            But once again, perhaps this is me ascribing technical reasons for what appears to be management policies.

            The comments of bratsche and Scott James Remnant on corporate policy with upstream collaboration is most troubling of all. It makes everything else Mark says seem so insincere.

            note: I left a similar comment on aseigo’s and Mark’s blog posts; no reply.

            • Jeff Waugh says:

              Those “corporate policy” points will not sound strange to anyone with experience working for Canonical. Similar policies and decisions were made during my time there from 2004-2006. It is modus operandi, not special cases. Ship it or fix it in “Ubuntu first” is not an unfamiliar refrain, either.

          • Zizzle says:

            I think this is the crux of the matter. I hope you turn this comment into a blog post.

            • Matt Vogt says:

              I absolutely agree.

              To me, the distribution of fault here lies with either Ubuntu or the relevant GNOME developers, based on whether you think that: a) Canonical did ‘enough’ to make their contribution acceptable, or b) that they failed to do ‘enough’, and thus their contribution was insufficient.

              Obviously, multiple observers will observe multiple different causes-and-subsequent-outcomes from this situation, because the rules are not as clear-cut as they apparently need to be. Observers such as Mark Shuttleworth will think they have done their part to reach an acceptable conclusion. Aaron Seigo seems to believe that the GNOME developers in question should have done more to support cross-desktop collaboration my meeting Canonical’s contribution at this midway point, and doing their best to incorporate the incomplete contribution.

              My personal viewpoint is that Canonical probably failed to push their contribution as hard as was needed in this particular case. But, this circumstance reflects negatively on GNOME, since a meaningful effort was obviously made by Canonical, and the GNOME parties did nothing to help make up where Canonical fell short. And thus, Aaron’s characterization of GNOME collaboration as less than that of an enthusiastic partner is borne out.

              • Dave Neary says:

                It must be nice to see the world in black & white. Is it necessarily true that if one party is “wrong” (for some definition of wrong) that the other party is right? Can’t both parties be wrong?

                To me, the distribution of fault here lies with either Ubuntu or the relevant GNOME developers, based on whether you think that: a) Canonical did ‘enough’ to make their contribution acceptable, or b) that they failed to do ‘enough’, and thus their contribution was insufficient.

                Here’s a hypothesis for you: Canonical did not do ‘enough’, but relevant GNOME developers did not put in enough effort to enable them to do better.

                I can point to one example of a patch-set which was submitted to GNOME Control Center, a GUI for XRandR, at a time when Ubuntu was (frankly) much nicer than stock GNOME in this regard: http://mail.gnome.org/archives/gnomecc-list/2008-April/msg00008.html

                A small number (3) of the patches got some minor comments, but as far as I can see, the patches weren’t integrated by the maintainer, or commented on. If improvements were needed, then patch review was lacking. If the patches were posted in the wrong place, guidance was lacking. There is a follow up in a separate thread to the idea of a revert dialog, suggesting that the idea is needed, but the approach might not be the right one, but no feedback on what changes might make the patch more acceptable.

                This is just one example, among others, where GNOME’s process for reviewing contributions is lacking. That said, in other situations (libappindicator definitely comes to mind) the processes which are in place were misunderstood and (to use your words) not enoughh was done to have proposals merged upstream.

                So, rather than saying “a pox on both your houses”, I prefer to say “room for improvement all round”. This is not a zero sum game.


                • Matt Vogt says:

                  It must be nice to see the world in black & white. Is it necessarily true that if one party is “wrong” (for some definition of wrong) that the other party is right? Can’t both parties be wrong?

                  Of course – I claimed as much in my concluding para. The real problem here, though, is one of process. A situation where the desired outcome is not reached, and yet no one can say conclusively where the responsibility lies – this indicates that the process governing contributions is either inadequate or not practiced. This failing has left us with a situation where reasonable people can look at the same situation and draw different conclusions on the ‘truth’ of the matter, including both unfair scenarios previously listed.

                  So, rather than saying “a pox on both your houses”, I prefer to say “room for improvement all round”. This is not a zero sum game.

                  Indeed. I would suggest a clarification of the contribution process would help all parties see where improvements should be made.

                  • Jeff Waugh says:

                    The real problem here, though, is one of process. […] This failing has left us with a situation where reasonable people can look at the same situation and draw different conclusions on the ‘truth’ of the matter, including both unfair scenarios previously listed.

                    What happens if that process clearly existed, but was never executed until the last minute? 🙂

          • Matt Vogt says:

            This is an important part of the discussion, for me:

            If you send your changeset to the Linux kernel mailing list, then you have attempted to make a contribution.

            For the linux kernel, the situation is simple: post your changes to LKML and request a merge; that is the only requirement to make an official contribution attempt. To get accepted is often much harder, but the first step involves no subjectivity.

            For GNOME, the situation is more complicated – should a change go into GLib, Gtk+, or another existing GNOME infrastructure library; should it become an external dependency; should it be an optional dependency of third-party apps? Who makes this decision, and where should this question be formally raised and answered?

            Not that the kernel process is perfect, but at least the starting point is simple!

      • IwannaStayOutOfThisBut says:

        Good point, you’re my hero today.

    • Alex H says:

      Just out of interest Mark, how would you characterise Novell’s development of gnome-main-menu or the Xgl/compiz work? Does that fall under the category of “contribution thrown away by GNOME”? Was GNOME poorer for not accepting all that stuff wholesale?

      • In the case of the main menu work, yes, and I think Dan Winship’s commentary at the time is useful.

        Xgl was a high risk infrastructure change that didn’t pan out. I think the reasons for that are not so much Gnome related, as broader ecosystem related. It’s a reasonable question whether the ecosystem made the *right* call on that, but I don’t think it was Gnome making that call.

        But I will say this: the ecosystem will be poorer if we don’t encourage folks to invest in things like Xgl. Hits are golden, misses are history. And I think it’s very hard to make a ballsy play like Xgl playing by all the complex rules this community uses to nail tall poppies.

        • Jeff Waugh says:

          The interesting thing about the context of Dan’s comments back then is that: (a) Novell and Red Hat learned from those experiences, as did GNOME by the way. (b) Doing great big changes in GNOME back then was very different to the opportunity and context of GNOME 3.0. 🙂

          Canonical came along at exactly the right time to make an impact. The DX team was constituted at exactly the right time to make an impact. Canonical didn’t do it in a way which engaged with upstream, because that’s the way you’ve chosen to do things (not learning from the mistakes of the past). A huge door was opened in October 2008. Canonical chose not to walk through that door. Multiple times, I might add.

          And in 2010-2011, you accuse specific members of the GNOME community of playing politics, and the GNOME community in general of allowing politics to be played.

          But I’m only up to December 2008 in my series. 🙂

    • Hello Mark,

      I just want to comment on your perception of Freedesktop.org which I feel is the reason why we haven’t seen the kind of successful collaboration that we saw early on. Soon after the success of D-Bus, the x.org split and a couple of other specs people started to see fd.o as a place to bypass the communities and try to force their ideas for cross desktop acceptance. Fd.o should have been a place to come together and discuss standardising and to grow trust. For some of the early participants this is exactly what it was but if people continue to see it as the starting place instead of the goal we have a long way to go before fd.o becomes useful beyond what has already been accomplished. As I said in an earlier post it took us 4 years to finally agree on D-Bus. This should be seen as a success. It happened, not because it was on fd.o or we blogged about it but because a number of stake holders got together on irc, mailing lists and in person over pints of beer to discuss concerns, hash out design and contribute code.

  7. Simon says:

    Jeff, I realise this series of articles is about getting your view of events across, but I really have to question how productive it is.

    You, Mark, and (to lesser degree) Aaron are making a lot of assertions about past events, but no matter what you say, it really doesn’t matter one bit. You’re never going to convince each other, and this ongoing fight is doing nothing for the credibility of yourselves or Gnome. Stop fighting, and get back to doing productive stuff…

    And Aaron – sniping at Gnome from over the fence doesn’t make you look all that good either.

    • Jeff Waugh says:

      Simon: I’ll get to the freedesktop.org stuff soon. It’s much less scary than what Aaron suggested, and I suspect he’ll better understand the situation once it’s explained from a GNOME point of view. Mark simply doesn’t understand what happened.

      As for whether this is productive… I go back to what I said in the very first post: To forgive and forget, we must first find acceptance and build trust. While Mark continues to mislead the community, that is not possible. So I’ll keep working on it. We simply must, in order to move forward together.

  8. Aaron Seigo says:

    @Simon: “Aaron – sniping at Gnome from over the fence doesn’t make you look all that good either.”

    should we just sweep these issues under the rug, then, and let things fall apart?

    my aim is not to snipe anyone but to address issues that are not being addressed with honest appraisal and action. yes, they are uncomfortable topics, but if we simply ignore them because they are uncomfortable then we’ll have very little chance to improve that which needs improving. the reason i tackled this issue is not because it isn’t flattering to GNOME or anyone else but because it negatively affects all of us; if it was not impacting my world and the world of F/OSS users in general, i wouldn’t’ve said a thing.

    imho, it is counterproductive to shoot the messenger in times like this, because all we’ll get are fewer messengers and a higher chance of failure as challenges go unidentified and unresolved as they arise.

    that said, i do think taking shots at individuals, particularly outside of the topic at hand really doesn’t help much, and unfortunately we have seen that happen.

    • bkor says:

      “my aim is not to snipe anyone but to address issues that are not being addressed with honest appraisal and action”

      But that is your interpretation. People who’ve actually contributed to GNOME and people who are still active have a different opinion. Further, we’re working on GNOME 3.0. It is difficult to judge from a distance.

    • Simon says:

      It’s not about shooting messengers, nor sweeping issues under the rug. But so much of the discussions lately has been endless arguing over what happened two or three years ago – one person’s memory vs another’s, and everyone pointing at blog posts and mailing list archives that support their version of events. All this constant argument over who was right and who was wrong.

      It’s stupid, destructive, and nobody wins. Supposedly Gnome 3 is only weeks away from release, and are people busy promoting it, building hype for one of the most significant open-source releases ever? No, the only publicity at the moment is of self-destructive bickering between various factions. Just what we all want, right?

      So, I’m not saying this issues should be ignored – I’m saying that those issues should actually be *fixed*. And when those issues stem mostly from poor communication between factions, we’re not going to get anywhere while those groups are fighting with each other over stuff that happened in the past. Forget about it, guys – it’s more important to worry about how you’re going to work together tomorrow than how you made a mess of it yesterday.

  9. Jimmy Smiths says:

    I wonder how often does Gnome incorporate patches from distributions? Things like security fixes, integration fixes, that sort of thing, which were developed outside gnome repos, but are of use to Gnome. I also wonder whether there are distributions whose patches are more frequently accepted than others.

    I wonder whether this could be assessed in a quantitative way from git logs. or the vcs logs of distributions, by seeing when local patches are applied and when they are removed. That would sure paint a more complete picture of the relationship between Gnome and downstream. Maybe more objective too.

    With the contradictory statements and different interpretations, people are mostly judging based on trust in who they know, and distrust in who they dislike. Having some figures would maybe clear things up.

    • bkor says:

      You’re suggesting some distributions are favoured over others. They’re not.

      However, you cannot determine that from git logs. Most contributors who also help out in a distribution do everything upstream except for distribution specific patches. Some of those are maintainers. As a result, analyzing git logs will just show that a lot of distributions do everything upstream.

      Further, a patch should be committed because the maintainer agrees with the patch. Not because it comes or doesn’t come from a distribution or certain persons.

    • Frej says:

      You can see when a patch is added upstream, it rarely makes sense to remove it.
      ‘local’ patches (distro patches?). Are by definition not seen upstream. Until they are well, sent upstream.

      The rule goes, if you wan’t to upstream changes to module X 1) ask maintainer of X 2) show code 3) get feedback. Be persistent, it’s an iterative process and has no specific order or end goals. The goals might change, because you acquire new knowledge in process, or someone comes up with a better solution, which seems like all your work is thrown away.

      This a separate process from adding new modules to Gnome, as a way to improve the overall platform for every module or better UI for users. This is much harder and even to grasp (platform vs. desktop modulset, internal vs. external).
      :(, that it wasn’t really an answer i suppose. Just me procrastinating.

  10. Scott James Remnant says:

    A quick correction on the fact that in Ubuntu 8.10 the menu items were present in both the System menu and the new FUSA applet.

    If memory serves, this had nothing to do with the patch not being upstream, in fact the developers had removed the items from the System menu. However during testing it was found that there were many upgrade paths where the new applet may not end up on the Panel.

    Since we couldn’t leave users without a way of logging out, we restored the items to the System menu until the upgrade issues were fixed in 9.04

    • Jeff Waugh says:

      If memory serves, this had nothing to do with the patch not being upstream, in fact the developers had removed the items from the System menu.

      It’s not so much that the patch wasn’t upstream, but had the development of this user experience change been pursued upstream, and not been developed exclusively as distribution patches, it would have received vastly more testing. It would more than likely be resolved much earlier, in a larger community of developers than were available to Canonical.

      Red Hat have learned this lesson. Novell have learned this lesson. Canonical eventually will too. I just wonder how many screwups it will take. 🙂

      • Scott James Remnant says:

        Not true at all; the problem wasn’t in the patch to the System menu or the FUSA applet.

        The problem was in the Ubuntu-to-Ubuntu upgrade path and code; that’s the kind of thing where upstream testing would not have helped.

        Now I’m not decrying the need to send upstream, just pointing out that this particular case is not relevant to your argument as it was entirely an Ubuntu problem.

        (Though you could probably argue that had it at least gone to Debian, upgrade issues may have been found easier :p)

  11. jry says:

    you keep saying that “Mark continues to mislead the community”, but I just don’t agree. I’ve read all of what you’ve written (nice work), i’ve been following (from a far) the gnome community for longer than i want to admit, i do understand what libappindicator is (since you claim that is central to the argument) and i still think mark’s viewpoint is completely acceptable and understandable. so i guess i have to say that i agree with mark’s comment that “Apparently, different groups of smart people can look at this timeline and draw very different conclusions.”. it seems that you don’t.

  12. I’m a volunteer contributor to both Ubuntu and Debian. I’m very willing to say that Canonical has not been as pro-active at contributing to GNOME as it should have been. In fact, sometimes I find certain decisions by Canonical very de-motivating. (Oh, anyone remember that whole Banshee thing that started this round of argument?) So why do I continue to do work on Ubuntu for free instead of only working in Debian? Well of course a big part of it is that I love the product that we produce, but there’s another aspect that keeps me involved. It’s simply much easier to contribute to Ubuntu.

    While there’s still a lot we can do to make it even easier, the Ubuntu community places a lot of importance on removing barriers to participation. We’ve been getting much better a steering new contributors through the process and providing tools to simplify the work. In general, I’ve found working in Ubuntu to be a very welcoming process.

    What does this have to do with the topic at hand? Well, a lot of thought and effort is put into harnessing drive-by and first time contributors in the Ubuntu community, and hopefully turning them into sustained contributors. If these contributors are not engaged, you lose a valuable source of future effort. GNOME should be focusing on this more as well, whether the contributor is an individual or a corporation. Canonical has expended time, money, and effort developing on top of the GNOME platform. This could be time, money, and effort spent directly befitting GNOME or only Ubuntu and its derivatives.

    Would it have been better if Canonical had worked directly upstream from day one? Of course, but it should seem clear to everyone involved by this point that they misunderstood how GNOME functions. This is not simply a matter of Canonical failing to contribute upstream but also a failure of GNOME to harness work being done by others.

    GNOME is losing potential contributions. GNOME folks could have been reaching out to Canonical, trying to engage them and show them how to best get their work incorporated. Canonical could have done much more, but if they weren’t interested in cooperation at all, why did the put all these ideas out there at the UX hack fest? Why did Ted Gould present the appindicator stuff at the Desktop Summit? If they really wanted to do everything in secret, that would never have happened.

    But when Canonical did things wrong, what did they get? Instead of folks trying to engage them and harness their contributions, they simply get people sniping about how they don’t contribute. This is a missed opportunity for GNOME.

    Maybe I’m misreading the entire situation. Maybe there really is some secret Canonical directive to not cooperated with GNOME, and Mark is outright lying. But to me it seems that Canonical made efforts, however misguided or half hearted. Maybe instead of railing on about how poorly done these contributions were, people from GNOME should step up and show them how it should be done.

    GNOME is missing out on potentially valuable work. For some reasoning, a number of high profile people in their community have decide that trying to shame Canonical rather than engage them is the best approach. Doesn’t seem to be working.

    (Sorry this got so long…)

    • Jeff Waugh says:

      Canonical could have done much more, but if they weren’t interested in cooperation at all, why did the put all these ideas out there at the UX hack fest? Why did Ted Gould present the appindicator stuff at the Desktop Summit? If they really wanted to do everything in secret, that would never have happened.

      These are all good questions.

      1) Almost all of Canonical’s user experience work began after the hackfest, and maps pretty closely to things considered there. Instead of doing this work with GNOME, it was done in private. But even after it shipped in Ubuntu, none of it was contributed to the project.

      2) Ted Gould didn’t present libappindicator at the Desktop Summit. It didn’t even exist at that point, nor did the freedesktop.org specifications which it ultimately used. What he did present was the Messaging Menu, which used a custom DBus protocol. That’s great. Sharing ideas at conferences is cool. None of the code was upstreamed. It just didn’t happen.

      The private development stuff is just an obvious blunder on Canonical’s behalf, and never helpful to collaboration with upstream (proved over and over in years gone by across many projects), but it’s not the key problem. Even if they had done that, they could have contributed the code. They could have proposed things for inclusion in GNOME. It just didn’t happen.

      Is GNOME missing out on valuable work? Potentially. 😉 I say this because much of what Canonical built would have been done differently had they actually participated. Even if you completely accept their user experience design as a fait accompli, the technology choices made would have been different. libappindicator would never have existed: It would have been in GTK+ by now!

      • “Is GNOME missing out on valuable work? Potentially. I say this because much of what Canonical built would have been done differently had they actually participated. Even if you completely accept their user experience design as a fait accompli, the technology choices made would have been different. libappindicator would never have existed: It would have been in GTK+ by now”

        By valuable work, I mean much more than the product we see now as Unity. There is certainly a value to the time, effort, and money that Canonical invests in its work. Do you want that investment to further GNOME or compete against it?

        • Jeff Waugh says:

          GNOME will continue to be relevant to Canonical while Unity and Ubuntu are built on it. If that strategy changes, then that’s entirely Canonical’s choice to make, and I don’t believe GNOME has any influence on that whatsoever. Do you really think Mark’s business strategy is built around GNOME choosing GNOME Shell or being “difficult to work with”? I don’t think he’s that… dependent. He never has been. 🙂

      • Cody Russell says:

        “Even if you completely accept their user experience design as a fait accompli, the technology choices made would have been different. libappindicator would never have existed: It would have been in GTK+ by now!”

        Maybe, or maybe not. I would probably lean towards “probably not”. Some fairly standard libraries, such as libnotify, are still not part of GTK+. Part of the reason for that may be because we didn’t have dbus support directly in GTK+ until the relatively recent addition of GDbus.

        I certainly would like if Canonical had developed all this stuff as part of GNOME, and I think they should try to do that for things in the future.. but we need to be careful with presumptions that things will instantly make it into core libraries. If we start claiming that anything cool will make it into GTK+ instantly then we set ourselves up for another dispute similar to the one that’s already taking place: Canonical (or anyone, really) develops some cool new feature and expects that it will be accepted immediately into GTK+, it isn’t accepted immediately for whatever reason, developer (Canonical or whoever) gets angry and claims that upstream is rejecting them.

        • Jeff Waugh says:

          That’s true… APIs need a place to incubate, libegg style. 😉

          “libappindicator” clouds things up a bit, though… Even though it was only raised on fd.o in very late 2009, KNotificationItem/StatusNotifier client, I’d suggest support could have landed in GTK+ by now — completely independently of libappindicator — due to two special circumstances: (1) openness to new API during the GTK+ 3.0 development process, and (2) that it was in some ways just an extension of GtkStatusIcon.

          The DBus stuff is a good point, but a dependency on DBus already existed by late 2009 / early 2010 (for gio), around the time the fd.o specification and libappindicator were proposed. (But yes, GDbus came later.)

          Crucially, minds were very open about all of this stuff during the libappindicator proposal discussion. Even in May, when Dan said libappindicator was not relevant to GNOME Shell, he still suggested that StatusNotifier/dbusmenu support might be relevant and could just go in GtkStatusIcon!

          The funny thing is, what I describe as a likely (if not guaranteed) path for StatusNotifier support in GTK+ maps almost exactly to what happened in the KDE platform around that time, although they obviously already supported KNotificationItem (progenitor to StatusNotifier), because it was originally created there.

    • Vadim P says:

      “GNOME folks could have been reaching out to Canonical, trying to engage them and show them how to best get their work incorporated.”

      I fully agree. GNOME, however, it still busy sitting on it’s hill and shouting that it’s the king of the world and all show bow to it – no efforts whatesoever to incorporate downstream changes.

      *waits for the “that’s not how upstream and downstream work! we made it first, you bow to us!” argument*

  13. Jono Bacon says:

    Hi Jeff,

    To be honest, I don’t see what you are seeking to achieve with these blog posts. As I shared with you on the phone last week, it seems pretty clear that you have an axe to grind with Canonical, and more specifically, Mark.

    If these blog entries were seeking to identify objective areas for improvement in both the GNOME and Canonical camps, I would see value, but all I am seeing is angry rhetoric and accusations of misinformation and lies.

    As I said on the phone, I don’t deny that Canonical and GNOME have both made mistakes, and I am keen to see these mistakes rectified as I believe they bring risk to Ubuntu, GNOME and Free Software adoption, but where I would love to see the kind of objective commentary I have always admired from you when you were actively involved in Ubuntu and GNOME, I am instead seeing what feels more like a hatchet job. This is not the kind of approach I would expect from the jdub I know and love. I hope this changes because I think you have tremendous wisdom to share which can help us to improve in the future.


    • Jeff Waugh says:

      I don’t have an axe to grind with Canonical or Mark. I believe Mark has made serious mistakes in strategy and communication over the last few years, but a huge mistake in communication over the last week. That must be addressed. To have any hope of a future together, that must be addressed.

      Was Mark’s Thursday blog post — not to mention his constant attacks on GNOME and Jon McCann since at least July 2010 — not a hatchet job? Is Mark’s behaviour appropriate? Are his claims misleading?

      These are things that must be resolved.

      • Jono Bacon says:


        As for Mark’s comments — I am not going to speak for him, he is his own person. What I will say though is that in my experience of working with Mark, he rarely exhibits this level of public frustration — I think he is human and feels personally connected to this topic, but I believe this is out of a care for GNOME and Ubuntu and how the projects work together.

        In my comment above I am just providing some feedback – I was under the impression that you were going to be providing an objective timeline of what happened to help those involved find solutions and next steps.

        From reading your commentary over the last four days or so you have been a man possessed on this topic! 🙂 You seem to be gathering this research, scheduling calls and writing up your multi-part blog entries, and all I am saying is that I thought you would be perfectly positioned (particularly given your absence from both projects for the last few years) to provide an objective stance and guidance for how both Canonical and GNOME can improve.

        I think we would all agree that there are areas of improvement on every side, but it concerns me that seemingly every comment you are making on this topic appears defensive and at times aggressive to Mark and Canonical. I just expected a different approach, that’s all. But heck, you are your own person, brother, and are of course more than entitled to share your view. 🙂


        • anon says:

          Can I just interject with an incredibly sexist comment here? I think every male reading this sub-thread should show it to their wives, sister, mum, etc. and ask them what Jono is doing here; because to the female mind it is all too familiar and certainly not constructive.

            • ancow says:

              I’m not female and not 100% sure this is what anon means, but I’d guess he/she/it is referring to the fact that you posts have a bit of a nagging tone… 😉

              • fukushima says:

                Nagging? Try “patronizing”, or “whiny”.

                Jono’s trying to be a diplomat, but he’s coming across as kinda puffed-up and self-righteous.

                Who cares what he “shared” in a private phone call? Who cares what he thinks about Jeff? There is a discussion going on here, and he’s just noise.

                As am I, now. Sorry.

                • anon says:

                  What I meant is that he’s using the same tactics that “mean girls” do to divert and re-frame a situation so that those who don’t share the same views become villains/screw ups/uncool. By the end of grade school, most girls can see it from a mile away. It really has no place here, nor do I think it was intended.

        • Alfred Wilburton says:


          Not to bring non-software politics into this, but you know that phrase: “Reality has a [your-political-party-here] bias”? That seems to be what we’re seeing from this timeline.

          The facts (such as they are, presented with references where available) are there. If one side or the other side sees them as offensive, should the fact collector be to blame?

          (btw, I love Severed Fifth. Rock on, brother.)

        • Jeff Waugh says:

          The timeline is pretty objective I think. I’ve gathered from all sources I could, and I’ll update them where points are missed.

          The commentary… I can understand if you don’t think it’s objective. I still use Ubuntu, I still use GNOME, I still care about both projects, and I still care about Canonical. I’m commenting because I want all of them to rock. For that to happen, some basic agreement about what went wrong must exist.

          Is Mark objective? He has made claims. I am answering those claims. Hopefully, eventually, that will result in some agreement.

    • SomeoneYouKnow says:


      Passive-aggressive personal attacks in public, from the guy who created OpenRespect? Huh.

      Trying to call Jeff’s motives into question is a really great way to make yourself look foolish and spiteful, instead of diplomatic and reasonable as you no doubt intended to come off.

      Mark took controversial positions in public. He is now defending them. No one on the outside could mistake Jeff’s posts for personal attack – he is just one participant in a valuable discussion, and arguably one of the most dedicated.

      Jeff’s posts and the subsequent discussion have been contentious but for the most part polite and well-thought-out. It is pretty apparent that he is seeking to ground the discussion by rigorously documenting timelines and connecting dots. When all parties understand the facts of what has happened and why, we can all move forward without lingering resentment and build on what we’ve learned. That is the point. He’s doing work that needs to be done.

      (Also, thanks for doing this series, Jeff. Keep keeping it accurate and correcting mistakes.)

    • Mike Tambrow says:

      I should start off by saying I am not anti-Canonical or anti-Ubuntu, I am happy they worked to made an easy-to-install Linux. I don’t belittle that as some have, I think it is a contribution to FLOSS – not just for ordinary users but for developers and sysadmins. I have wasted enough of my life mucking around with XF86config and that sort of thing, and am very happy for the work they’ve done to make my life easier. I have even sent in patches to Ubuntu, which were applied.

      That said, I have to chime in that I don’t know what was going on in Bacon’s head when he made his reply. Whether or not there is a flame or two in Jeff’s posts overall, it is obvious he is being thoughtful in his comments and is trying to be constructive. I also think it takes some gall to suggest he should not be writing any of this for public consumption and that the posts are filled with “angry rhetoric and accusations of misinformation and lies” -this after Shuttleworth just fired off a barrage of angry rhetoric and accusations a week or so ago. As Jeff pointed out in his reply. His posts are in many ways a response to the posts by Shuttleworth, if anyone has started a fire recently, it was not Jeff.

  14. Miles says:

    I’m getting the sense that the Ubuntu/Gnome situation is quickly approaching the point of no return, where there’s so much bitterness on both sides that a productive relationship between the two projects becomes essentially impossible. That would be extremely unfortunate. Perhaps it’s time to start working on solutions instead of bickering over what can’t be changed.

    • Eric Pritchett says:

      Wouldn’t you first have to identify the problems first before working on the solution? I think that’s what Jeff and everyone else is trying to do. Sometimes it’s better to move separate ways and sometimes it’s not, but I don’t think it’s come to that fork yet. Personally, I think they should both (and anyone else) should keep hammering it out and get through it. I think the problem in the past is that they didn’t hash it out like this and everyone just internalized their feelings which made things worse. Get it all out there!
      If you want a successful group you need two things, responsibility and accountability. If you have someone not doing those two things you should call them on it and hold them accountable. Hence, if someone is misleading the community and someone wants to call them on it then they should, but also do it in a responsible way and be held accountable. I think that’s exactly what is happening here, so I say get it all out!

      • Miles says:

        My read is that the problems have been hashed out and we’re now to the point that people are talking past each other. Comments by various parties are repeating what’s been said previously, only more stridently. I’m all for the airing of the grievances, but at some point there needs to be an “agree to disagree” moment and the discussion turns toward the future.

        • Justyn says:

          You said it, brother!

        • Simon says:

          Absolutely. It’s pretty clear what the problem is – that despite being one of the big players in Gnome, Canonical/Ubuntu are very much outside of the project.

          Now, I don’t know enough to judge why that is, but I’m certain that this unproductive shouting match isn’t doing anything to correct it. This is just pushing the gulf wider and wider.

    • Dave Neary says:

      The conversations this week are not changing the relationship between GNOME and Canonical, IMHO. What they are doing are exposing the plumbing of that relationship for all to see.

      We do run the risk of polarising the GNOME/Ubuntu enthusiast universe, but as I said on twitter, this issue is important, and while it might be inconvenient to air our dirty laundry in public, this is what transparency looks like.


  15. Andre says:

    We as users don’t really care about this stupid fight Canonical Vs Gnome. Or You Vs Mark, at the end of the day Ubuntu is the best distribution out there, so people at gnome should look to what users really like from Ubuntu and if it can be make upstream do it. But stop the fight.

    • Eric Pritchett says:

      I disagree. I am a user and I do care. I think it might be more appropriate to say most users have no idea about this fight or perhaps most normal users like “mom, dad, grampa, etc” don’t care, but I think you’d see a lot of users on this blog and the planets that do care.

      • John says:

        These are commercial wars. The people who are fighting are having some Money (consulting opportunity) at stake. They are trying to shame Canonical because they are jealous of its success.

        All these guys have commercial company to back them up and these wars are not going to stop!

        Linux desktop community has a history on these flame wars. They are so used to sham Microsoft. Did it help Linux desktop?

        Canonical brought some light to Linux Desktop by bringing us Ubuntu. Later Canonical learnt that Gnome is not the best for end users. Canonical should have chosen KDE. They didn’t, because Mark Shuttleworth was a long time Gnome developer. Mark, you made a wrong decision by making Ubuntu default Gnome in the first place. Had you associated with KDE, we would have got a great linux desktop which Apple and Microsoft could not even dream.

        • Jeff Waugh says:

          Mark is not a long time GNOME developer, and that’s not why he chose to ship GNOME in 2004. 🙂

        • observer says:

          Well, we have Kubuntu, which is great on my laptop. And Ubuntu, which is great as well.

          I always admired the beauty of gnome, I’ve always admired the customizability of kde.

          Ah, and although I had no problem configuring my pc’s over the year while using a vast number of distributions, I am gratefull that Kubuntu gives me the opportunity with much less work and problems than other distributions.

          Having said that, even as a huge fan of KDE, I don’t think your point that mark should have chosen kde would make everything great.

          It just makes the possibility greater, that this ends up with a lot of desktop-flamewars noise.

          This is just a sidenote. As Not-Developer watching the things around me, I really can’t help the discussion on this technical level. So perhaps I shouldn’t have posted? -but neither should you have 😉

      • Omer Akram says:

        No, if you are only a user this debate is not relevant to you at all. You just have to wait for the release and install it. thats all.

        • Eric Pritchett says:

          What if choose to go elsewhere as this unfolds. It is relevant to me. If I see a politician misleading a community and doing things wrong then by you’re logic what your saying is it’s not relevant to his/her constituents. I don’t have to wait for the release I can go elsewhere. You are very much mistaken if you think user’s don’t have a stake in all of this. User’s very much care about community and even though it may be small they still contribute to the ecosystem.

        • cwningen says:

          That’s like saying if you’re not a veterinarian or animal shelter worker, you just have to wait for products that have been tested with unnecessary live animal vivisection to be launched and use them. Everyone has the right, some would say responsibility, to try and merge their moral/ethical code with general reality as best they can. The underlying philosophies behind free software are more than just marketing spin to many peoples eyes. While I’m sure you think your attempt at censorship through bullying is helping, what is really hurting Ubuntu is your (and many others) brand of condescension that forces people who would like to see Ubuntu reach its true potential into a constant defensive mindset. Regrettably, some of us act accordingly from time to time. Apologies. It’s very hard to establish constructive dialogue when you are constantly expecting to be attacked. This is why it was so hurtful to read that Mr. Shuttleworth sees some of us as a mob with pitchforks. While understandable that it would look that way to him, it is not the case and nothing could be further from the truth. Regardless, I think my (and other non-technical persons) presence here proves the point that it is relevant to the average user.

    • cwningen says:

      Don’t speak for me. This user really likes transparency, freedom, and responsibility. If I didn’t, I wouldn’t be bothered with GNU/Linux. Perhaps this is part of the problem: Users, not temporary trend followers or friends and family, seem to have become some sort of misunderstood mythical creature to those outside the peanut gallery. Everyone should take time to consider who their audience really is.
      P.S. Reframing this cathartic exercise as Canonical/Ubuntu/Mr. Shuttleworth Vs. X is inaccurate, unfair, and ultimately damaging to all involved.

    • Michael says:

      Usually, when I do not care about something, I just do not read the article. Like I do not watch tv when there is nothing I want to see, or the same way I do not buy a book when there is nothing to buy.

      Free software is about sharing knowledge, and sharing knowledge usually implies transparency and free speech. And that’s what we are seeing to some extent.

  16. Justyn says:

    It’s clear that you have put a lot of effort into these detailed articles, thank you.

    From everything you have written it seems abundantly clear that things went wrong because there is a big difference in the approach some people in Gnome expect corporate contributors to take and the one Canonical thinks they should be taking.

    I’m looking forward to your post detailing how mend this relationship – but I’m hoping that it will not only be limited to ways you feel Canonical should change. There should be room for more than one way of doing things in this project.

    • Simon Anderson says:

      From everything you have written it seems abundantly clear that things went wrong because there is a big difference in the approach some people in Gnome expect corporate contributors to take and the one Canonical thinks they should be taking.

      Nope, it’s another in a long, long line of battles between GNOME and other parts of the community.

      And once again, Jeff Waugh is front and centre.

      • Jeff Waugh says:

        Zing! Nope, I’m just documenting it this time around. 🙂

        • Simon Anderson says:

          Zing! Nope, I’m just documenting it this time around.

          As a courtesy to Alan Cox, I’ll translate the newspeak:

          documenting – “spinning GNOMEs point of view.”

          • Jeff Waugh says:

            Happy for you to think that, but anyone who believes I have an unbending allegiance to GNOME has simply not been paying attention. 🙂

            For me, it’s hardly even a matter of primacy of allegiances, should you think it’s a black and white choice between Canonical and GNOME.

  17. Dylan says:

    It is clear now that in order for Gnome to thrive, it must become a stand-alone entity, like the Mozilla Foundation, with its own agenda and a core staff of engineers, funded by companies that directly benefit from shipping the Gnome Desktop.

    The decision-making process for G3 seems haphazard at times, and features are copied from other systems without understanding the purpose or consequences.

  18. João Pinto says:

    I really don’t understand what Mark, David, You, etc are trying to achieve with this useless loop of blogs posts. You mentioned:
    “To forgive and forget, we must first find acceptance and build trust. While Mark continues to mislead the community, that is not possible. So I’ll keep working on it. We simply must, in order to move forward together.”
    If you don’t trust on Mark and Canonical you are seeking to move forward together with who exactly ? Why do you bother keeping the attention on their mistakes.

    Most people have been commenting and presenting facts trying to demonstrate who is right or wrong, such exercise is useless and just makes future collaboration harder. If you don’t want or don’t plan to collaborate because you do not trust someone just ignore them.

    There are deceiving communication attempts from some parties. But really, those interested in this topic are capable of collecting the facts and reach their own conclusions.

    • Jeff Waugh says:

      If you don’t trust on Mark and Canonical you are seeking to move forward together with who exactly?

      Interesting question. Let’s see. I think trust has been lost, but I don’t think it’s utterly gone or hopeless. There is a relationship here that must continue out of necessity, and will hopefully continue to mean even more than that in the future. If that hope didn’t exist, I don’t think anyone would bother to engage.

  19. Alfred Wilburton says:

    Conspiracy theory: Jeff Waugh is, in fact, a shill for Ubuntu. He is being paid to write these blog posts and fan the flames of this latest slap-fight in order to detract from the release of GNOME 3.0, which happens in a few weeks. The Banshee Amazon referral scandal similarly was manufactured, by a secret payment from Canonical through a Cayman Islands hidden bank account to Novell in their purchase by Attachmate, in order muddy the waters around GNOME.

    Jon McCann is actually Mark Shuttleworth (have you ever seen them in a room together?). The infamous Ted Gould-Jon McCann conversation now makes more sense: Mark is convinced it happened even though he wasn’t physically present. Since Mark is Jon, Mark actually was physically present and can therefore relate the full contents of his discussion with Ted.

    No GNOME conspiracy is complete without the mention of Miguel de Icaza. He famously took a job interview with Microsoft as a young man and proceeded to lecture his interviewer about the great value of free software. He wrote Midnight Commander and released it under the GPL. He founded GNOME (with Federico) in order to be able to use a free desktop. He began Gnumeric to allow every cell in every spreadsheet to enjoy its freedom. Then he disappeared from the GNOME software world and began his current life of decadence.

    Has anyone read Atlas Shrugged? This next part only makes sense if you have.

    Miguel de Icaza is a real-life Francisco d’Anconia. I will hereafter refer to him as Miguel d’Icaza. He, seeing the horrid future of a world increasingly encumbered by patents, proprietary licensing, and DRM, and seeing the filthy mass of plebeian fools happy to embrace such a world without freedom, decided to fight back in the best way he knew how: he would join that plebeian mass and drive it into the ground. He would license proprietary software where before he had opposed it. He would support patents where before he had argued against them. He would develop software in support of DRM where before he had hacked around it.

    Only by destroying the software he once loved with all his heart could he hope to rebuild a world worth living in.

    Does this clear things up for anyone?

    (Apologies to Jon, Mark, Ted, and especially Miguel. No one deserves to be compared to a Rand character. If I had to be one, though, I’d definitely pick Francisco.)

    • Simon says:

      Is it worrying that your theory sounds like an improvement over the probably reality – that several leading figures really are so hung up on winning this battle that they can’t see how much damage they’re doing to themselves?

      • Alfred Wilburton says:

        Who are the “leading figures”? Mark Shuttleworth is the only person in this argument with a claim to be a leader. Jeff hasn’t been involved in GNOME for years. He was at no point in time a technical lead.

        • Jeff Waugh says:

          Left Canonical in 2006, GNOME in 2008. 🙂

          • Alfred Wilburton says:

            I understand, Jeff. I just wanted to emphasize that you are neither a leader in GNOME or Canonical. As you said in your other post, you are now an outside observer with keen insight into both organizations. When you and Mark go back and forth in blog posts, it doesn’t represent leaders from both projects arguing with each other. It represents one leader (Mark) arguing with one guy who’s compiling facts and expressing opinions.

            As an aside, thanks for garnome so many years ago 🙂 GNOME 2.0 would never have turned out as great as it did without you.

  20. Mr Nobody says:

    So the short version is basically (in no particular order):-

    1) GNOME processes aren’t entirely clear, Canonical (and apparently some module owners) thinking the “external dependency” was a requirement/hurdle that it wasn’t.

    2) Marks stated desire for Ubuntu to provide “internal competition” isn’t helped by them doing a lot of work externally to GNOME. (Indeed the proposal of libappindicator as an “external dependency” is a fairly clear indicator that it wasn’t “internal” to GNOME).

    3)Face to face conversations are important for a healthy exchange of ideas and a vibrant community but if they aren’t followed up by some sort of minutes or documentation the opportunity for misunderstanding is large.

    A lot has been written about this (and helpfully so for this interested onlooker) but I think the actual issues are quite easy to address if people are motivated to do so (and frankly they are the sort of issues that arise in all sorts of entities, there is nothing particularly extraordinary here).

    • Jeff Waugh says:

      I would disagree that GNOME’s processes aren’t entirely clear… the release process in particular is incredibly well documented on the GNOME wiki Release Planning pages.

      Also, Ted Gould (GNOME dude and Canonical developer who proposed libappindicator) actually knew very well what an external dependency was, because at least a year earlier he corrected snippy jerks about it during another attempt to convince GNOME developers to depend on Ubuntu libraries (which, again, had no relevance to GNOME). 🙂

      • Mr Nobody says:

        I did not mean that GNOME does not have clear policy, rather that it wasn’t clearly understood by all (or clearly understood the same way by all) or that the application of that policy wasn’t clear. Unfortunately having documentation doesn’t mean everybody understands it the same way!

        For example the reasons for rejection listed in the meeting minutes do not seem to obviously line up with the documented assessment criteria (which the documentation itself also admits are “subjective” allowing for pretty much any outcome to be “as documented” while still seeming “fickle”).

        It seems to me that the appearance of fickleness in a decision should be considered a problem worth trying to avoid as much as possible by the release team.

        Perhaps “rejections” could be tempered with some more positive action, such as specifically recommending that interested module owners feel free to use it as an optional dependency to assist in further evaluation and development. That would allow the release team to do their important job (keep their release target manageable and stable) but also avoid the appearance of picking winners too early with seemingly final statements “nothing in GNOME needs this” (even if the intended meaning was supposed to be more along the lines of “nothing currently in GNOME needs this” rather than “nothing in GNOME would benefit from this”).

        I am not suggesting the release team made the wrong decision, merely that the level of communication (in both directions) made the decision seem like more of a road block than necessary.

        • Jeff Waugh says:

          For example the reasons for rejection listed in the meeting minutes do not seem to obviously line up with the documented assessment criteria

          Yeah, the interesting thing about this is that libappindicator was hardly eligible to be an external dependency in the first place. That should have been mentioned in the rejection.

        • Dave Neary says:

          To be transparent about the information I sent Mark concerning external dependencies, I posted the emails in comments on his blog:


        • Dave Neary says:

          Specifically: “an external dependency is a non-GNOME module which is a dependency of a package contained in one of the GNOME module sets. And since libappindicator does not fit that definition, there is quite simply no need for it to be an external dependency.”

          And, in terms of clarifying the potential future for libappindicator:
          “In practice:
          1. If a maintainer wants to add optional (compile-time) support for a new feature that uses a library, there is nothing they have to do beyond commit the patch, and let the release team know.
          2. If a maintainer wants to add unconditional support for a feature which requires a new dependency, then they should first write the patch, then propose the dependency for inclusion in the next release.

          Traditionally, the bar for external dependencies has been low, modulus a number of conditions. There is reason to believe that the bar for libappindicator would be higher, because of the history involved. One or more maintainers arguing for the functionality would help.

          I stand by both these. libappindicator is not a dependency of anything in GNOME modulesets today, therefore it doesn’t make sense to propose it as an external dependency. It can become an optional dependency without involving the release team at all – get patches for optional support accepted by maintainers, and you’re done.


          • Dave et al

            First, and I checked with the folks who were engaging with app developers, while what you say is technically a true reflection of policy, it is also true that several app developers said that they wanted to see the outcome of Ted’s proposal before accepting even optional patches.

            You’re defining external dependencies recursively: “an external dependency is a dependency of a module…”, knowing full well that those dependencies would not get created unless they were approved in the process that we followed.

            And you’re still skirting the issue that the bar appears to have been raised far higher for the work we submitted, than anything else in memory. Why?

            I’ve seen folk saying we should have pushed harder. We pushed harder than the documented process says we should have to.

            I’ve seen folk saying that the problem was the contribution agreement. Well, CUPS has a contribution agreement assigning copyright to Apple, and I don’t see the mob with pitchforks aimed at NIH’ing that.

            I’ve seen folk saying the issue was the choice of infrastructure. And you know that most, if not all, of the external dependencies don’t use Gnome infrastructure. Seems like approving that, then arguing for it to migrate into Gnome so as not to be an external dependency, would have been a collaborative approach. Also, you would know that choice of infrastructure has political consequences, there are several modules that are *deliberately* hosted outside Gnome so as to make them palatable to other desktop projects, and given the nature of the indicators work, we thought that was a reasonable position too.


            We’ve all said all of this before. I feel like the hoops are being set higher for us than they are for others. That’s not a game anybody will play for any length of time.

            • Jeff Waugh says:

              I feel like the hoops are being set higher for us than they are for others.

              They weren’t/aren’t. That’s not why you didn’t succeed. I’m trying very hard to show you that.

            • Dave Neary says:


              You say “it is also true that several app developers said that they wanted to see the outcome of Ted’s proposal before accepting even optional patches” – indeed, Xavier Klassens asked for this for Empathy, and Ted corrected him by telling him how things had happened in the past. And he was right. Xavier was mistaken.

              You said “You’re defining external dependencies recursively” – I don’t think I am. Maintainers set the direction for their babies, and they decide what they want to depend on. But we have, in GNOME, a check & balance, because we are conscious that distributors don’t want to depend on “flavour of the month” libraries that will be unmaintained in 3 months. So we ask GNOME maintainers to be clear about what their unconditional dependencies are, and ensure that these libraries are discussed project-wide. So you don’t need to be a blessed external dependency before a GNOME module can optionally depend on you, but if that dependency is unconditional, then project approval is needed. Nothing recursive involved.

              Finally, you say “you’re still skirting the issue that the bar appears to have been raised far higher for the work we submitted”. I think I did.

              First: libnotify also went through this harsh approval process & was rejected for GNOME 2.20. So rejecting libappindicator is not unprecedented.

              Second: I cited two members of the release team who gave some insight into why libappindicator might not be welcomed with open arms: duplication of functionality with libnotify (an existing dependency), and right now adding unconditional support for libappindicator doesn’t benefit GNOME – either the classic GNOME panel + applets or the new GNOME Shell. As things stand, adding such support would benefit only Ubuntu & Unity. Also, I explicitly said that the history involved has made the discussion of libappnotifier unnecessarily emotionally charged, and that is raising the bar – much as it raised the bar for, say, Beagle or F-Spot before (no, we are not going over new territory here).

              Finally, I have received a triple confirmation that what you were requesting – confirmation that GNOME applications can add optional compile-time support for libappindicator, allowing integration with Unity – is possible in the context of GNOME.

              Concerning copyright assignment, it will indiscutably be an issue if you want to propose a module for inclusion in a GNOME release set. However, GNOME does not have a policy against depending on external libraries with copyright assignment, as you point out. This is not a blocker to libappindicator becoming an external dependency. We do hold modules that are part of GNOME to a different standard that external dependencies. I maintain that the main issue in the last proposal period was that no GNOME applications depended on libappindicator.

              I understand your frustration. I am also trying to help clear the air. I am also trying to point you in a direction which allows us to start working together productively.

              Let’s see if there isn’t some starting point, something we can agree on. Let’s get a small group of people together, working on a shared problem, and get that work included in GNOME, benefiting everyone. I don’t expect miracles, but I really don’t see how GNOME is holding Canonical to a different standard at this point.


              • Jeff Waugh says:

                As things stand, adding such support would benefit only Ubuntu & Unity.

                That is the case now. When patches were filed for libappindicator, and when it was eventually proposed and rejected, Unity did not exist in the public sphere.

                (Mark says Unity is a natural progression from Ubuntu Netbook Remix and that the charges of political games still apply. This is wrong, but I’ll come back to that later in the series.)

  21. James Henstridge says:

    Is there any reason why you keep on pointing out that people have worked on code before posting about the idea? Far from being something sinister, I would have thought it was quite common: if you don’t test out your idea, how do you know whether it would work? I certainly do some basic testing of ideas myself in both work and spare time contexts.

    In the case of Ted’s work on the IM status entries in the FUSA menu, the branch you’ve linked to seems to show at few partial days of work over that month rather than a full months work as you make it sound. It looks like he posted when he had a basic prototype working.

    • Jeff Waugh says:

      I point it out merely because those are the events on the timeline. The start of work indicates intent. I don’t think much of it is “sinister”, but in some cases those points on the timeline are quite illustrative when brought together.

      • James Henstridge says:

        If the behaviour is not out of the ordinary, why draw attention to it? What point exactly are you trying to illustrate?

        • Jeff Waugh says:

          That Canonical does not work collaboratively with upstream. You’re just seeing the tail end of 2008 there, and the beginnings of those projects — there’s little to be drawn from those events at this point. It becomes more clear as the timeline continues…

  22. Anonymous Coward says:

    Whether we like it or not, many more people — possibly tens of millions — will use Unity than Gnome Shell.

    Whether we like it or not, Unity is now the world’s de facto leading Linux desktop environment.

    Whether we like it or not, the Linux desktop market’s center of gravity has tilted permanently in Canonical’s direction.

    Whether we like it or not, Unity is now a de facto upstream project, with Canonical as its leader.

    The good news is that Unity is Free software.

    Just as Canonical consumes upstream Gnome code (produced under Gnome leadership on Gnome’s infrastructure), why can’t Gnome consume upstream Unity code (produced under Canonical leadership on Launchpad)?

    Why can’t Gnome work with Canonical on the same terms that Canonical works with Gnome?

    • momentum says:

      “Whether we like it or not, Unity is now the world’s de facto leading Linux desktop environment.”
      buahah nice joke. You want to know true : KDE is now the world’s leading Linux desktop environment.
      GS and unity will be 2 disasters and everyone knows that and this all talk about GNOME/Canonical war is good especialy for XFCE, KDE and all “normal” DE.

      So Mark, Jeff keep up the good work with spreading fud, hate and other good stuff. The more, the better

  23. Although only a fraction of the issue, I think one of the problems or hard feelings relates to Ubuntu getting a larger proportion of credit than their proportion of code.

    Although hard feelings are understandable, “credit” is a subjective combination of media and peon perspectives. Ubuntu cannot do anything in the current market to contribute code in kernel or upstream in proportion to the “credit” it seems to get. The most they could do is contribute code in proportion to the *revenue* they receive from FOSS.

    My guess is that they receive less than one thousandth of the revenue of Redhat, and if so, could only reasonably be expected or able to contribute one thousandth of the code to FOSS as Redhat does.

    It maybe unfortunate that credit doesn’t get fairly distributed in proportion to code, but at the same time, Linux Mint gets half as much media credit as Ubuntu while only getting enough revenue for 2-3 coders, a small fraction of Ubuntu’s developer base.

    There are far more peons like myself who can build hype for Ubuntu, but not pay anything for it than there are Fortune 500 CIOs who can spend millions in dollars but not time on blogs and reviews hyping Redhat.

    • Omer Akram says:

      Yeah they should rename Ubuntu to Ubuntu Gnome GNU Linux to give everyone credit?

      • Jeff Waugh says:

        That’s an unfair response to an entirely reasonable point made by Carlton.

        • Omer Akram says:

          No, the response is fine. The software is free, you can use it, distribute and modify it, thats what most free software licenses say so I am right there.
          and you don’t like canonical for what ever reason, also you seem to have a personal(old) conflict with Shuttleworth too. I am not saying with your current series of posts but also your other activities that have clearly reflected that you dont like them. Take for example that tweet of yours about unity which was totally pointless, If a company is spending millions of dollars on a product and they are bounded to the user interface(talkin about gnome-shell) that another party is creating when the company have resources and investment to create what they want no one should have a problem, even a little bit.

    • Jeff Waugh says:

      Canonical does get an unfair hearing in a lot of cases, particularly around the issues you raise. The fact is, getting FLOSS in front of lots of people is a huge achievement.

      Is it a contribution? Well, Canonical’s investment has contributed to a broadening of the audience for FLOSS code, so yes, that’s a contribution. Even “competitors” in the FLOSS world should appreciate that… even if they’re less likely to say it in public!

      But it’s entirely orthogonal to their ability to work well with others, work on code, and contribute code. It’s not an answer to that question. Once Canonical had the resources to contribute in the form of code — and in desktop terms, that basically began in 2008 — I think it’s reasonable to ask why they didn’t do so.

  24. Mats says:

    Whether Canonical like it or not, Ubuntu might lost some of popularity and might not be forever and ever the world’s de facto leading Linux desktop environment. Millions of uss have made first touch with Linux by trying Ubuntu. Thank you Canonical. Ubuntu has sofar been quite reliable distro for newcomers. There is no doubt that many of former Ubuntu-users has already moved to distros like Mint (i personally recommend Mint for newbies, not Ubuntu). Some of uss liked more KDE and when Kubuntu is rather poor distro, you gotta have some better like Mandriva or Open SUSE.

  25. Sam Thursfield says:

    Thanks Jeff for the huge amount of work you’ve put in to assembling the facts around this issue and putting them all together.

  26. Wayne Schuller says:

    I’ve been following Gnome and using it as my exclusive desktop since the beginning.

    I remember when Gnome 2.0 was coming out and there were many huge flamewars on the mailing lists. It felt like 2.0 would never come out. Here we are heading into 3.0 with similar scale of wars. I’m sure things will sort themselves out. No need to panic!

    Also, I recall for many years Red Hat (1999-2002) were THE company that had the most influence over Gnome. Their desktop team were benevolent, friendly and awesome. Others were included, but there was a driving force and vision from the Redhat crew. Then Ximian had the most rock star hackers within Gnome for a couple of years.

    If Unity ends up ‘winning’ the popularity contest, I personally wouldn’t mind if Canoncial gets centre stage over Gnome for a season. Like Red Hat and Ximian, they may be able to really accelerate progress whilst drawing in other companies and contributors.

    I can’t wait to try both the Shell and Unity (though I am so used to my panel setup I may remain on Gnome classic forever!)

    Wayne Schuller

  27. Ambleston Dack says:

    These posts really do sound like the death throws of a marriage. I said this. You said that. I did this. You did that! C’mon folks, it’s all well ‘n’ good airing your differences in public, but for the love of any god, if this goes on any longer people are just going to ignore it and just carry on regardless.

    What I see should be happening (and this is just my opinion) instead or crying and shouting and finger wagging about spilt milk, why don’t you guys get round a table and talk about collaboration, working together, ironing out your differences. If all the polls are to be believed, Ubuntu IS the biggest distribution, surely GNOME should take that on board, after all if GNU/Linux usage is only 1% and Ubuntu is the biggest distro, that means a heck of a lot of us are using GNOME. Period.

    Ubuntu is switching to Unity, where does that leave GNOME? And before everybody comes back and says, “Ah well GNOME existed before Ubuntu, so there!” Think about it, don’t let your ego’s get in the way, after all its the end user that is king, not you guys. Your Joe average end user doesn’t give an airborne sexual encounter whether Canonical or GNOME devs were responsible for the notifications, as long as they work, and they are not too distracting and the overall ease of working on an OS is simple. Last thing Joe average wants to do is fight his OS just to get his e-mails, or the latest Twitter feed.

    I’m a designer, I design homes, I would be out of business if I went in with my size 10 shoes and started ignoring what my clients want in their homes. If what they ask for is not possible, I tell ’em. There is a few minutes of awkwardness as they digest that they can’t have glass floors suspended from thin wires and expect to hold a disco on them. I can only advise them based on my knowledge and skill. If you guys still can’t understand, look to the almighty Jobs and his obsessiveness for control. The only good thing that Apple did in terms of designing from an end users perspective is the iPod interface.

    Can we please stop this nit picking and bickering and snide comments from some seriously big players in the GNU/Linux world. I’m an end user. I don’t care about libindicators, I want an OS that works, please, is that too much to ask.

    Seriously, if this continues, I will have to get the headmaster and take away all your blue Smarties, all the e numbers are making you guys a bit hyper 🙂

  28. Wondering says:

    Free rider problem? Companies who relies on Linux _must_ contribute? Ouch. I always believed that open source+free software gives you the freedom, and you don’t need to pay, if software licenses are not broken. It seems it’s not true anymore, you must pay as you would use Windows … Sad 🙁 Well for sure I know the difference but still, it’s very odd to do what Greg did, I can’t even understand his points: Linux is open source and free that you can use freely _without_ paying in any form (like contributions). Sure, compared to other companies who contribute, it’s sad. But it does not make Canonical evil, it just makes the other companies “above the average” where Canonical is just “average” without major amount of contribution but clearly they do not deserve to be called as “bad guys” …

    • Jeff Waugh says:

      Yeah — I think there are completely valid reasons to distribute FLOSS without really contributing to it, and in many cases Canonical has had good reasons for a level of contribution that is lower than expected.

      But it’s that delta between expectation and reality that truly bites, particularly when claims are made about politics being involved in acceptance of contributions.

    • Dave Neary says:

      Absolutely it does! You can do whatever you want with the software. But as in elections, decisions are made by those who turn up. If the software doesn’t do what you want, the solutions are fix it, fork it, dump it, complain, or deal with it.

      Complaining doesn’t buy you brownie points with upstream developers, but it can be a useful contribution if you can do no better. We call such complaints feature requests & bug reports.

      However, if your business depends on our software, then you really should be exercising some form of influence – to do otherwise is bad business sense. And if your solution to changing upstream is to complain, you can expect some push-back.

      If your solution is to fork (that is, develop something independent of upstream), and you suggest that upstream should adopt your work, then you can also expect push-back. Not rejection, but a deep critical review.

      And if you fork & don’t make the effort to push your work upstream then you can expect that the community will route around you.

      Which can be fine too.


Leave a Reply

Your email address will not be published. Required fields are marked *

Comments will be sent to the moderation queue.