Has GNOME rejected Canonical help?

3:14 pm community, freesoftware, gnome

Through the fall-out from the Unity decision, and now the fall-out from the packaging of Banshee on Natty, I have repeatedly read Canonical & Ubuntu people say “We offered our help to GNOME, and they didn’t want it”.

Exhibit #1:

For starters, some people in the GNOME community moan about how Ubuntu doesn’t pull its weight upstream.They then make it difficult for Ubuntu-y folks to contribute things upstream.

Exhibit #2:

For the app indicators we also had a lot of community involvement, it was based on a Freedesktop.org spec, worked on with consultancy from KDE, we invited GNOME developers to participate in the Freedesktop discussion and proposed them to the GNOME community for inclusion, but it’s not up to us, if they take it or not

Exhibit #3:

Where tensions between Canonical and GNOME have occurred, according to Bacon, is in Canonical’s desktop innovations for improved usability, such as the Ayatana indicators for sound and social media, and the new Unity desktop, all of which were submitted to GNOME and rejected, leaving Canonical to develop them outside the GNOME project. […] Asked whether Canonical could have developed its usability modifications within GNOME, he replies, “To be honest with you, I don’t think it could have been done. The fact that nothing’s been accepted is a pretty reasonable indicator that the two projects have widely different directions.”

Exhibit #4:

We committed to build Unity […] because we had ample reason to believe that the trajectory of the alternatives was going to fail. And it did fail – Gnome 3 looks much more like the vision we painted with Unity than the original vision […] I am sorry that a few Gnome leaders have blocked Gnome’s adoption of Unity API’s, and the stress that will cause, but I feel proud that we had the guts, and the capacity, to design and deliver something wonderful.

I have seen and heard this mentioned by others too, but cannot find any others right now – additional pointers in comments would be welcome!

So – given that GNOME is a project which scores very highly as being Open By Rule (disclosure: I put together the evaluation of GNOME for Simon), I thought I would go back through the archives and see how true this was.

Looking at what was actually proposed for inclusion in GNOME from Ayatana work, libappindicator was rejected because (quoting directly from the release team’s decision):

  • it doesn’t integrate with gnome-shell
  • probably depends on GtkApplication, and would need integration in GTK+ itself
  • we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen
  • there’s nothing in GNOME needing it

I went back to see where the discussion happened for the libappindicator proposal. There was a discussion, some over & back, Ted was (as usual) forthcoming & helpful, and things appeared to be moving approximately in the right direction. There were some issues over copyright assignment, and the discussion petered out. No feedback I could see from the GNOME Shell team – positive or negative – to depending on the library.

Now, this is hardly ideal. I would love to see debate on why there wasn’t a more in-depth debate on using libappindicator in GNOME Shell. Was this ever proposed? If so, where? I can’t find any reference. Was there any reaction other than “we don’t think it’s an issue” to the copyright assignment issue? Perhaps there was a lot more discussion in another forum that I haven’t linked to – on the release-team list, on IRC, or elsewhere? Comments, please!

I would love to point to other instances of work which has been proposed upstream from Canonical and which has been rejected, but my (admittedly, brief) search has not turned up much useful stuff. I can’t find any online reference to displeasure with the GNOME Shell vision, or proposals of alternatives, nor can I find situations of “Paper Cut” patches being rejected because they were from Canonical or Ubuntu. In fact, the one reference I found to the UX hackfest in 2008 from Mark seemed quite positive about the whole thing.

There are apocryphal stories about patches submitted twice by different people before they were accepted, other stories about people being “impossible to work with”, design feedback being ignored, and more – I would love to see some evidence of this, or some documented criticism from 2008 of some of the GNOME Shell design documents. I hear often that some of the design decisions were unacceptable, but ask which ones, where the discussion took place, or how much effort was spent trying to get things changed, and hand-wavy “lots of stuff” type answers is what you get back.

I would really like to shed some sunlight on this – if we do not have publicly archived references to places where these disagreements have happened, then there are a couple of possible conclusions we can draw: either insufficient effort was made to collaborate, or the effort was made, and GNOME Shell is not sufficiently transparent for the developers and designers to be accountable.

So please – pile in on the comments. I want to know of instances when GNOME has (allegedly) refused contributions or help from Canonical, with links to Bugzilla, mailing lists, even IRC logs or wiki pages. Let’s get to the bottom of this & see if we can’t solve the problem.

Updated to clarify that the reasons for rejecting libappindicator were not mine, but were copied from the release team decisions, after reading Aaron Seigo’s response

74 Responses

  1. Anonymous Says:

    Has anyone considered the possibility of re-evaluating indicators at this point? I’d love to see more menu-style use of the panel; it seems like a great win for usability and consistency.

  2. Jef Spaleta Says:

    I have a private email sent to me yesterday from Shuttleworth where he cites some bug tickets from 2010 as evidence of patch rejection that have caused hurt feelings inside the Canonical fenceline.

    Unfortunately he has not given me permission to rebroadcast the email so I’m not sure what to do with the information to work towards some sort of resolution that makes anyone feel better moving forward.

    If I try to re-hash the contextual perspective “how Canonical sees it” with my own words in an effort to both see forward progress as well as respect Mark’s wishes that the content of the email remain priviate…I run the risk of imposing my own interpretation of what Shuttleworth said to me…confusing the matter further. I have no desire to put words in Shuttleworth’s mouth…even if I am doing so with the best intentions.

    I wish Shuttleworth or another Canonical employee would feel comfortable repeating the same information given to me in private so there could be a discussion on the merits about how certain rejected patches were handled.


  3. Dave Neary Says:

    Hi Jef,

    Without posting Mark’s words, you can certainly point to publicly accessible bugs & let people draw their own conclusions.


  4. Juanjo Marin Says:

    Michael Banck post about the Application Indicators:


  5. Adam Williamson Says:

    “there’s nothing in GNOME needing it”

    this is, of course, a circular argument. It’s impossible to get the patches for appindicator support into any GNOME apps, because appindicators aren’t part of GNOME…

  6. Jef Spaleta Says:

    I can post the bugs. And I’m considering it. But I want to give Shuttleworth the chance to reconsider trying to have this discussion in private and engage on this in a meaningful way.

    That being said the crux of the problem continues to be the contextual feelings about how the bugs were handled…not what is recorded in the bug reports. If the contextual frustration being expressed had explicitly appeared in the bug reports then they would stand as evidence to the problem and I would point you to them with no qualms.

    However, if I just point to the bugs, different people are going to come to different conclusions about the handling. Everything that is at issue is contextual/cultural interpretations of what is suppose to happen when there is technical disagreement. If I can’t related the contextual information…the feelings…the reports are just going to serve to harden opinions on both sides. And that’s not what I want to do.


  7. Dave Neary Says:

    @Adam: That’s untrue – maintainers decide all the time to depend on new libraries and then post a request for that library to be added as an external dependency. Once it’s an external dependency other applications may decide it’s a less risky choice, but ultimately the choice to depend on a library rests with the maintainer/developer, and not with the release team.


  8. Emmanuele Bassi Says:

    @Adam: not really, no. one fundamental tenet for the whole 2.x series (and it still holds true now with 3.x) is that GNOME apps can start depending on external libraries — possibly in a conditional way, but it’s not strictly necessary. this is what the external dependencies moduleset was all about.

    if enough applications depend on an external library then the dependency usually moved to the “desktop” moduleset (which has lax rules about ABI/API compatibility). a lot of GNOME libraries belonged to that moduleset. gstreamer was part of that moduleset.

    if a library is core to the whole experience, then it can be moved to the “platform” moduleset; only API/ABI stable libraries can exist there, as they are part of the core GNOME platform. glib and gtk+ are there.

    for 3.0, the modulesets have been re-organized, but generally we have a core platform, and extended platform and an external dependencies modulesets.

    now, if GNOME applications started depending on libappindicator, that particular library could have been placed in the external dependencies moduleset without any problem. it’s just up to the individual maintainers to actually do that — either by accepting patches or by working on it themselves.

    the process has been like this for years — it’s not something that was set up in a fortnight and changed every six months; there’s no point in feigning lack of knowledge for that.

  9. Andrés G. Aragoneses Says:

    Adam raises a good point. The thing that we should wonder is if there is any Gnome app interested in using the appindicators…

  10. Adam Williamson Says:

    BTW, the design issue I always see cited as being ‘inspired’ by Unity is the change from a fat sidebar with Places and so on included (in the overview window) to just a Dock-style thing. That’s argued to have happened right after Unity came up with a very similar design.

  11. Andrés G. Aragoneses Says:

    Ok, I rectify now my comment because I have read the replies to Adam :)

  12. RadekB Says:

    I think there might be something like culture clash. Canonical is more focused on visual design and designers like to keep their work secret until it’s ready. And when it’s ready, it’s non-negotiable, it’s the designer’s “masterpiece”. This might contribute to communication problems between those two projects.

  13. Jason D. Clinton Says:


    Evidence: http://www.markshuttleworth.com/archives/611/comment-page-1#comment-345769

  14. Jimmy Smiths Says:

    If AppIndicators was voted against being included, how many developers will see that and think “I’ll start depending on that anyway”?

    Also, don’t external dependencies need to be approved? The module decisions for gnome 2.26 make decisions explicitly on external dependencies:

    brasero (desktop suite)
    evolution-mapi (desktop suite)
    gnome-user-share (desktop suite)
    DeviceKit-power (external dependency)
    farsight2 (external dependency)
    libgda (external dependency)
    libical (external dependency)
    libmapi (external dependency)
    libnotify (external dependency)
    libproxy (external dependency)
    Mono.Addins (external dependency)
    pulseaudio (external dependency)
    unique (external dependency)

    for gnome 2.30:

    gmime (external dependency)
    libdb (external dependency)
    vala (external dependency)
    gnome-packagekit (desktop)
    nautilus-sendto (desktop)

    If these don’t need to be approved, why are they submitted for approval?
    What would rejection mean?

  15. Jimmy Smiths Says:

    Also, speaking as a spectator of the Planet, it really seems like most of Gnome is run by Fedora people, with some OpenSUSE folks. That makes it look like Red Hat and Novell not wanting to play ball with Canonical.

  16. Juanjo Marin Says:

    Something I don’t particularly really like about Canonical/Ubuntu is the fact I think they do unilateral plans about how the desktop should be. I mean unilateral because they don’t count/communicate with upstream people.

    For example, it is supposed they will enhance Evince [1], but as far as I know they haven’t been in contact with any Evince maintainer or fill any bug report about it.

    It seems an obvious communication problem here. It has been improved a bit, when some upstream people are starting to go to UDS [2]. When I read [2] I was shocked that a Python friendly company which delivers a GNOME distro wasn’t awared of GObject Introspection plans.

    I think what Ubuntu and GNOME needs is a more coordinated work, from conception/ideas stage to implementation and we must find the correct channels of communication.

    [1] http://www.markshuttleworth.com/archives/455

    [2] http://blog.tomeuvizoso.net/2010/05/ubuntu-and-gobject-introspection.html

  17. mccann Says:

    @adam Yeah, it is even weirder than that though. Jeremy and I were working on part of the new shell layout (that you see now) while sitting in the Canonical offices during the Spring 2010 GNOME 3 UX Hackfest. No one from Canonical seemed to want to talk about GNOME 3 despite repeated requests from us. It made sense later after they announced Unity. But at the time it was really weird. Unity was a complete secret at that point and, as far as I know, not mentioned once while we were there. Shrug.

  18. Jef Spaleta Says:

    That particular interpretation of Unity as influence of GNOME is pretty late in the game..in 2010.

    The issue, for me at least, was where is the evidence of any attempt at communication in 2008 and 2009 ahead the decision to fund Unity development in-house.

    I am not commenting on whether Unity has any good or bad design ideas worth stealing or not. I have asked, and what I think Dave here is asking for is any evidence of _any_ _timely_ communication about design ideas from Canonical that were injected into the early GNOME 3 design discussion leading up to their decision to start working on Unity in-house. Anything at all from 2008 and 2009 in the archived public record would be a starting point for evaluation.

    If Shuttleworth wants to allude to irreconcilable differences in design vision as a reason needing create Unity as a project, he needs to back that opinion up with references to publicly archived design discussions from 2008 and 2009, which occurred ahead of any resources be expended on building Unity.


  19. pt Says:

    Unity is progressing nicely without the bureaucratic burden of the Gnome hierarchy.
    It is not just those bugs mentioned above, but there are many bugs reported on Launchpad, but when reported upstream (to Gnome esp. Nautilus) get ignored or rejected.
    With Canonical they can hire UI experts and carry out tests to make important decisions, than relying on a developer who is out of touch with regular users (who aren’t programmers) of the application.

    With Ubuntu consisting of more than 60% of Linux Desktop users, and a bigger proportion of new users, Gnome will lose it’s relevancy if it doesn’t listen to Canonical.

  20. Florian Müllner Says:

    In the context of the libappindicator rejection, it’s probably worth pointing out the discussion on KDE’s status notifier spec[0], where criticisms from Dan and Matthias have been mostly discarded by KDE developers.

    [0] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html

  21. Ted Gould Says:


    I think that any discussion of who said what isn’t truly valuable. It’s just going to result in nit-picking over details. What I do think is interesting, and important, is that there are patches in GNOME bugzilla that are bit rotting. Who submitted them, I don’t care, but they’re not getting to all GNOME users everywhere.

    I think that a valuable thing that the GNOME Release Team can do (because I hear they’re bored) is start to put that in their reports on release readiness. Hopefully this could push more patches into final states instead of being unexamined or left to linger in uncertainty.


  22. Allan Day Says:


    A wise comment indeed! :)

    I’m sure you realise that it is not always easy to get patches reviewed and applied – everybody is busy.
    If there are patches waiting, an email to the relevant list is always a good idea (and if that doesn’t get people’s attention, just post to desktop-devel-list). There is no reason why these issues cannot be dealt with in the open.



  23. Andreas Nilsson Says:

    Ted: Agreed, but I don’t think it’s the release teams responsibility alone. We must fix this together.

    In an e-mail in October I asked for what would be a sane review time goal, will ping again with that. Please reply to it :)
    Is there also a good/simple way to do a report of all unreviewed bugs? I think that would be a good start.

  24. Matthew Barnes Says:

    Unreviewed patches in open GNOME bugs (where “unreviewed” means patch status == “none”). You can edit the search and limit it to components you’re interested in.


  25. Vadim Peretokin Says:

    Jef, I’d love to see those bug reports. I don’t see anything wrong in allowing people to draw their own conclusions.

  26. Eric Pritchett Says:

    Forget about rules for now. You need to make sure two things exists when it comes to people, responsibility and accountability.
    What it sounds like is that the accountability is lacking in some cases and responsibility is lacking in others. Even in the open source world projects need authority to protect *everyone’s* freedom. I would recommend Philip K Howard’s TED talk on this at http://www.ted.com/talks/philip_howard.html or even his book Life without Lawyers.
    Seriously though, watch the TED talk and apply it to Gnome, Canonical, Red Hat, Individual App projects, etc. Consider what happens when people continue to bring up or hammer the same little “knit-picky” issues that slowly corrodes the common good of the project (and in effect ruins everyone else’s freedom). I want you to pretend you’re a new company, user, developer, etc and tell me who is accountable to whom. In fact, tell me who runs Gnome from starting at gnome.org. I had to go to gnome.org > About > find a paragraph with a link in it to foundation.gnome.org/about and there go to a site that is designed under a different template that doesn’t have an easy way to contact the board members directly or show who’s accountable to whom.

    I believe this is the root of the problem, so let me ask do think this is the root as well? How could we accomplish this within the Gnome Project/Foundation? I have more thoughts, but I’ll leave it up to discussion from this point.

  27. mike Says:

    That’s how I see it too. Now that Ubuntu is progressing and getting even more popular so fast, everyone seems to be pulling it down.

  28. benQ Says:

    At the end of the day, one has to accept that there are two groups of people that have a vision of the Desktop. This vision is, apparently, not the same one.

    So whether group A has tried (extensively or not) to persuade group B of their vision, is really not worth discussing. Maybe group A has simply taken from the actions that group B undertook, that discussion would not lead to any acceptable solution for them.

    At the time Unity was released (as an idea), GNOME3 had Mutter that was unstable, resouce consuming … the Desktop interface was unintuitive and a lot of complaints of the userbase was ignored, at least this was my impression (yes, it was ignored for the good reason to not fight over things that are on the move). However, ignoring early user feedback gives the impression that the makers of GNOME3 are picky about influence from outside the GNOME3 developing community.

    This (percieved) situation is ideal for making a switch if you expect your vision to be incompatible with the vision GNOME3 appeared to have.

    It is à la mode to be picky about Canonical. However, I do not see how the situation could be different right now.

    Who will be the “winner”? Clearly the user, who can pick out a working environment that suits his workflow the most.

  29. Dave Neary Says:

    @Ted: I disagree that “who said what” is useless. It seems to be at the heart of the current “them & us” mentality which is setting in between GNOME & Ubuntu developers – this is unhealthy for all involved, and I would love to see Ubuntu developers consider themselves “us” when it comes to GNOME. I don’t want to set myself up as a marriage counsellor, but it would be nice to know what the sources of tensions & conflicts are.

    What I can tell you from my point of view – with no involvement in a project competing with Ubuntu, but as someone who has worked hard on the GNOME project over the years – is that it looked to me like it started as “Fedora/Red Hat vs Ubuntu” but it has now spread way beyond that to “GNOME vs Canonical”. And Canonical being in conflict with a software project on which they depend for substantial parts of their contributor base & software development is an untenable situation.


  30. Simon Says:

    I am not involved with any of the projects, but it looks to me that Ubuntu and RH/Fedora were competing on who will have greater influence on the future direction of GNOME and Ubuntu hoped to lead by example, changing first their distro and then proposing those changes to GNOME. That failed. RH on the other hand, decided to build GNOME Shell as an official GNOME project using it’s gnome developers. The influence on design outside RH was very limited to say the least. Unhappy with that, Canonical decided to pursue their vision of the desktop which is why we now have Unity. After that, gnome shell changed it’s design, so the two shells now look similar but are still different at their core. I think that this does have its good side because it would be hard to find the compromise between the two groups with such different visions. I am only sad that some really useful multiplatform things like dbus menus and indicators will not have official Gnome support. That would make things more consistent and it would make app developer’s life easier.

  31. aklapper Says:

    @pt: I’d love to see examples for this. To generally imply deliberate intention of not fixing bugs is misleading, as for every other open source project with limited manpower. Plus I’m more interested how many *patches* delivered upstream by Canonical are actually “ignored” (also see mbarnes’ link here), instead of bug reports. It’s a fact that things get fixed quicker when a patch is available.

  32. danw Says:

    See my reply to the d-d-l thread, which was several months later and so is not linked to the thread you linked to.

    The #1 reason we rejected appindicators was because the protocol that they are built on (the original protocol, not the additions written for Ayatana) is a joke, and when we tried to suggest changes that would make it more useful to GNOME, we were more or less told (again, by KDE people, not Ubuntu people) that we were stupid. It quickly became clear that it wasn’t worth making any further attempt to work with them, so we wrote them off.

    There are various bugs in gnome-shell (eg, 630842, 641853) that cannot easily be fixed with the current trayicon system, which would be trivial to fix with appindicators. And so we are probably going to end up designing something more-or-less equivalent to libappindicator for 3.2, but sane underneath. And this is all a huge waste that would have been avoided if Canonical had discussed the idea of appindicators in GNOME with the GNOME community before implementing them rather than just trying to force us to accept extremely unfortunate technical decisions after the fact.

  33. Open Trends nieuwsselectie 8 March 2011 » Open Trends Says:

    […] Safe as Milk Blog Archive Has GNOME rejected Canonical help? […]

  34. Jef Spaleta Says:


    Apparently even my telling you of Mark’s private email to me..without relaying the specifics to you has been considered a bad faith action on his part. I did not anticipate that reaction. And of course the same logic holds then my telling you that my previous action was considered bad faith is itself going to be considered bad faith.

    it appears as if Mark wants to treat private correspondence under the same rules as correspondence being used in project Harmony without first getting agreement to those rules from me.

    So apologizes to Mark for twice over revealing to people information sent to me in private that he would not like revealed. While I considered the comments to be something to hold private, I did not forsee that he wanted me to hold the very fact that he sent me a private email as confidential.

    But now that I know what his standard for private correspondence is… I cannot in good faith reveal the bug tickets as presented to me for fear of misrepresenting his feeling on the matter and having that reveal of information be called a bad faith action.

    I feel I have been given information in that I was knowingly meant not to make use without it being called a bad faith reveal on my part. I feel manipulated. He has effectively check-mated me into a conflicted position concerning the balance of the ethical use of private correspondence and the need for public discussion concerning the allegations of prejudicial handling of patches.

    So its up to Mark now. I’ve lost what slim shot I had as being a good faith mediator when I revealed to you that he sent me an email.


  35. bz Says:

    KDE’s Aaron Seigo follow up on your post:

  36. Adam Williamson Says:

    Dave, Emmanuele: appindicators are somewhat different from just ‘an external dependency’ though. It’s not just a boring library which abstracts away some handy function or other, it’s a UI change. In my experience, GNOME generally works UI changes by defining what the change is going to be and then implementing it in applications, not the other way around.

  37. Sense Hofstede Says:

    What we’re seeing here is a clash of visions and habits. Canonical has its own vision for the future of the Linux-based desktop/netbook, and its own habits for making it reality. GNOME works differently.

    People often don’t like it very much when they’re presented with a block of work that is done and the only choice they have is whether or not to take it fully. This may have been the case with Canonical’s proposed modules. The Canonical developers and designers implement their ideas and visions internally, not in the open. They announce it only when they’re done.

    If they would have really wanted to play a part in the GNOME 3 design procedure, they shouldn’t have come with finished ideas, rolling out of their own factory in blocks. Instead, they should have done the brainstorming and designing in the GNOME community. By not doing this, Canonical placed itself outside the whole process. I am sure that Canonical’s management is smart enough to realise this.

    Like I said before, people don’t like it when you present them with finished work to replace (part of) your own work. It feels foreign, and there hasn’t been any consensus building, no ‘poldering’. (Poldermodel!)

    Of course, whether or not this is a wise strategy is debatable. I agree that good design is not done by committee, and that you need to have an extraordinary and unified vision to produce a good OS/desktop environment, because of its complexity.

    When you have a situation where it depends on the personal preferences of the maintainers whether or not a new technology gets implemented, you get a fragmented landscape where progress is slow and coherence is low. I applaud Canonical’s attempts to resolve this. I do hope that they will be able to improve their communication with projects like GNOME.

  38. Jef Spaleta Says:


    Can you point me to a healthy multi-vendor backed project that welcomes large fully implemented code drops as-is that GNOME participants could look at as an example of an alternative development culture? I can’t think of one.

    I think the historic record shows that kernel development culture frowns on that behaviour as well. And it’s far from clear that such behaviour has ever been a good thing for long term maintainability of a project or a codebase.

  39. nmarques Says:

    Dear people,

    Though my voice is tiny and shy compared to the ‘dinosaurs’ already engaged on this discussion, I would love to see something nice coming out of this.

    Aren’t we missing a bit of pedagogic attitude towards each other?

    I’ve packaged the (in)famous indicator stack for openSUSE and the nice thing was that I had to live on an outcast repository. It’s has a nice cool things, through OBS I can pretty much enable builds for Mandriva, Fedora and friends, etc. And since upstream and Canonical seem to be unable to work with each other (somehow understandable given the conflict of interests between some of their sponsors), I’m forced to run patched ‘unsupported’ stacks… To be precise, 4 patches (being one for menu proxy, which doesn’t really is necessary for the indicator stack). I doubt Canonical couldn’t maintain those if they were upstreamed… Maybe the way they are accomplished isn’t the desired… good opportunity for upstream to take some pedagogic action instead of taking stones?! Maybe the licensing is an issue… Mark? Defend your people and your vision? Sometimes we need to give a step back in order to give 2 forward… Maybe it’s just corporate behind…

    All this fights are purely a waste of resources and intellectual capabilities… maybe all this resources combined together would help…

    In the end, distributions are even endangering themselves because if people demand options, they will get them… and then we have to spend more resources in producing extra spins… there’s lots of people with free time that with a bit of guidance can accomplishing it.

    To finish with… one thing I know for sure, all my questions addressed to Canonical developers were always answered, I can’t say the same about other projects. That’s all I need to know to make my opinion. As for the wars… keep up feeding the opinion makers, I’m sure they love to pick up on this cases to promote themselves and pass on a twisted vision of the reality… sad no one was smart enough to realize it… I wouldn’t even doubt there would be a few of those ‘opinion makers’ in the pay role of (…).

    Can we still turn this into something constructive on behalf of potential GNU/Linux users?

    I know I would love to see millions of GNOME desktops! I know I would love to see Linux flourish… but this petty wars do not make you attractive for your potential investors…

    Sun Tzu: “Divide in order to conquer” – I’m sure the real competitors (closed source alternatives) are laughing up on us and how we waste time and valuable resources in useless fights.

    Best of luck to GNOME and Canonical, with high hopes of seeing your guys working together in the future. This set of bits expresses a personal opinion.


  40. ebassi Says:

    for everyone that thinks that Canonical earned the only place in the GNOME doghouse, let me remind you just two words: Novell, gnome-main-menu.

    Novell learned the lesson that GNOME is made and steered by those who show up every day, not by dropping code and expecting everyone else to fall in line.

    RedHat also learned this along the way, during GNOME 1.x — and they managed to be the force steering the 1.x → 2.x transition; just as now they are providing resources for the 2.x → 3.x transition. resources for projects designed and developed in the open; not code drops.

    at some point, I’m sure, Canonical will learn the lesson as well.

  41. Jef Spaleta Says:

    I was just looking up 1.x to 2.x transition history for other reasons.

    But I’m failing at digging up some useful material. It was such a long time ago and my local offline caches have long been purged. I’ve got nothing locally that dates back that far.

    If you would be so kind as to point me to a archived discussion thread about that transition I’d appreciate it.


  42. Dave Neary Says:

    You might want to read this for some c. 2000 background: http://pault.ag/kde-gnome/

    GNOME had a lot of issues at the time – gnome-devel-list and the early days of d-d-l have a lot of it. Basically, any of the common mailing lists around 2001-02. But it was “we’re all in it together” angst.

  43. wally Says:

    “Novell learned the lesson that GNOME is made and steered by those who show up every day,”

    Are you saying there is some sort of ‘moral rightness’ that they believe is more important than quality or usability?

  44. Jef Spaleta Says:

    while funny… I was hoping to dig up discussion concerning the transition for GNOME 2.x… particularly of interest the perceived role of Ximian in the process. Also of personal interest is discussion around moving away from sawfish as the window manager.

    I think there are some very interesting compare and contrasts to be done with lessons for today by just focusing on those two very specific historical nauces of early GNOME 2.x.


  45. Dave Neary Says:

    I imagine he means that they learned that being forthcoming with information to the GNOME project when you have it, and working with the maintainers of modules you’re looking to update all through the process, is more successful than keeping your usability work private until your software development is “finished”.

  46. Mark Shuttleworth » Blog Archive » Internal competition is healthy, but depends on strong and mature leadership Says:

    […] Neary has to his credit started to ask “what’s really going on […]

  47. Paul Sladen Says:

    Jef: Bug reports and public mailing list reports are in the public domain, yourself or anyone else are free to independently use Google to find and link to them—on this occasion it’s a bit late as the pack of cards has already been turned over and I fear that on this occasion your sources have been revealed. Chatham House Rules (“…the same rules as correspondence being used in project Harmony…”) are not specific to any project but are the implicit basis of most private discussions. Listen to the radio: “An anonymous official…”, “A senior government minister…”—these quotes, just like private email, allow highlighting existing information without revealing who the journalists’ private source of confirmation was. What you won’t hear is “An anonymous prime--minster…”, or “An anonymous benevolent dictator…” it is too revealing and is not going to get that reporter their scoop for the next time. If it can only have come from a very small number of people it is unlikely to be anonymously in the public knowledge domain already.

    Purely public discussions also have a major advantage and this is where the Free Software wins consistently: through having open communication and clear factual debate. In those public conversations everyone is clear from the start on the [different set of] rules in-force; people tailor their answers to the situation and those answers should not generally be used outside of the environs in which they were willingly given.

    Saying “Chatham House Rules” or “don’t forward private email” are much the same.

  48. ebassi Says:

    @wally: no “moral rightness” — it’s just how community-driven open source projects work; it shouldn’t shock people any more. you don’t expect the Linux kernel to be steered by a single company, do you? you have to engage the kernel developers community, and continue to do so; otherwise you just have one option: fork the kernel, and maintain the fork. how is GNOME any different than the Linux kernel? even KDE, albeit depending on a single company for code-dropping their toolkit, behaves the same way for the rest of their environment.

    now, if Canonical wants to fork GNOME 2.x for its LTS release I have absolutely no qualms with that. I mean, it’s not a great move — for Canonical, not for GNOME. unless, obviously, you have a lot engineering resources to spare; but after all, GNOME 2.x is basically done, so it might just be doable.

  49. What does it takes to be a good open source citizen? | Linux News Says:

    […] Neary took note of one of the recurring Canonical themes in their […]

  50. Anonymous Says:

    Indicators are completely pointless reduce usability rather than improve it.

    The GNOME developers are right to reject it, we don’t need it and don’t want it.

  51. Damon Says:

    Glad I’m back to Windows. The Linux community is still behaving like spoiled children after 20 years.

  52. Has GNOME Rejected Canonical Help? Shuttleworth Responds | JetLib News Says:

    […] and even Fedora community members to ask why these things were done. In Dave Neary’s ‘Has GNOME rejected Canonical help?‘ post, he states, ‘I have repeatedly read Canonical & Ubuntu people say, “We […]

  53. Jef Spaleta Says:


    As I said I did not have a compatible expectation as to what Mark regarded as private as I did not ask for a private discussion from him and have made it clear in the comment track in his blog…repeatedly..that I am looking for public discourse. I will take the full blame on myself for telling everyone here that Mark sent me a private email.

    In the future I’ll delete unlooked and unwelcome private emails from him without reading them so I don’t have to be conflicted by access to information he considers confidental when I am specifically and very forthrightly requesting public information. I’m not trying to scoop a story I am trying to get us past what appears to be abuse of off-the-record conversations instead of public channels for years of discussion between people.

    Now as I said in the first post here. I am very reluctant to post any bugreports without contextual information about how an unnamed person feels about it. I do not necessarily agree with the views expressed to me, and I am not going to be able to defend the views. It would be half-hearted at best and I think the people inside the Canonical fenceline deserve someone who will relay their interpretation in a public discussion with an authoritative voice.

    I am not that person. And as much as it pains me to have been thought of as acting in bad faith by telling you I got an email from Mark with specific bug tickets… it would pain me significantly more to have anyone think I was representing Canonical’s pov in public in bad faith. I have no desire to be seen to be speaking for anyone inside Canonical.

    So please, if you feel you can be that person. Please email mark or any other canonical employee you feel will talk to you off the record and ask for the same information he sent to me so that you can then relay the ticket numbers and attempt to defend their interpretation.


  54. The blame game | tante's blog Says:

    […] the last few days we’ve seen some good old poo-flinging in the open source world. First Dave Neary pointed out some of the problems he saw with the Canonical/GNOME collaboration and pointed to […]

  55. Doug Reed Says:

    I am a software designer, but don’t work on desktop stuff. I use Windows, Linux, and OSX.

    Ubuntu is based on Debian, is friendly and works.
    RedHat is ugly and hard to manage and RPM stinks.
    Don’t know about Suse.

    Gnome didn’t used to work.
    KDE used to work. They broke it.
    Gnome fixed it.
    Now Gnome wants to kill the Max/Min buttons and break it again.

    Why is it necessary to rewrite what works every couple of years?

    I stand with Ubuntu. The Gnome and KDE guys live in some world the rest of us can’t see.

  56. rch Says:

    HEY: I use Fedora every day and never think about any of this nonsense. Even when I decide to actually look at the desktop I do not notice any serious problems at all… None. I haven’t seen an MS desktop in 4 or 5 years, but OS X doesn’t impress me, so I don’t expect Windows to do so either.

    The fact is, they all work pretty well already.

    Now… say you can reduce the scope and complexity of an api and I will listen. Tell me that you found a great way to remove something like app indicators (whatever those are) without bothering too many 3rd party developers at once, and I’ll get interested. Make it simple.
    Really, just make it simple already.

    The truth is none of what needs to be done with the ‘desktop’ is all that hard, and the tricky bits were figured out ages ago.

    Remember when Linus said to choose [omitted] and move on? That was So So long ago, and things do not seem to have improved much at all.

    So: consolidate, simplify, and move on already. And whatever you do, don’t race with Mark to capture the attention of the lowest-common-denominator users. It is easy enough to make a living writing interesting software without their help.

  57. Paul Sladen Says:

    Jef: Per “Please email mark”, I have taken your suggestion and emailed, and that it appears that others have done just that too. My understanding (from the reply received four hours later) is that Mark Shuttleworth has already cleared it with you (by email?) that you are free to release the correspondence in question; is this the case?


  58. Jeff Schroeder Says:

    @Dave: Here is (if true) a small but relevant smoking gun:

  59. Ability vs Authority, Ubuntu vs Gnome « theNthDoctor's Better and Worse Ramblings Says:

    […] blogs like this with respect to your involvement in a community like this just makes you look […]

  60. On cross-project collaboration | Daringsearch Says:

    […] is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I […]

  61. Safe as Milk » Blog Archive » Lessons learned Says:

    […] my rather controversial question a few days ago and multiple reactions from around the KDE & Canonical world, a lot of reading […]

  62. Jef Spaleta Says:

    Yes in the same email that Mark said I was acting in bad faith, he also gave me permission to repost. Mark still has not given me permission to publish the full email exchange.. so the very fact that I am telling you that he told me that I can repost the one email may be considered bad faith. I honestly have no idea what he personally considers confidential at this point.

    So please understand that I am reluctant to repost anything with regard to that conversation now. Mark reacted quite strongly to what I did say publicly. In the same email where he gives me belated permission he first berates me for using the information I did mention publicly to raise tensions. I’m not going to release further information into a situation where Mark feels like I’ve backed him into a corner in bad faith and misused information given to me. I have apologized
    publicly, that is the best I can do under my own code of ethics.

    Mark is free to repost his email to me in its entirety and our entire email exchange starting with his first email to me. I want to be accountable for what I say and I have expressed that desire to him. But I do not want to be put into a position where I am expected to re-interpret or defend anything he desires to say or to make a judgement as to what is or is not confidential.


  63. On cross-project collaboration | Maemo Nokia N900 Says:

    […] is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I […]

  64. On cross-project collaboration – Henri Bergius | Scripting4You Blog Says:

    […] = {"data_track_clickback":true};There is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I […]

  65. Шаттлворт и Нири рассуждают о конкуренции и взаимодействии между проектами Ubuntu и GNOME Says:

    […] с проектом GNOME. Заметка Марка опубликована в ответ на замечания Дэйва Нири (Dave Neary), в прошлом входившего в совет […]

  66. On cross-project collaboration – Henri Bergius Says:

    […] is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I […]

  67. Ubuntu Linux and GNOME: The Disputes continue | ZDNet Says:

    […] The specific problem that started the current discussions roiling the Linux desktop waters was explored by Dave Neary, a member and former director of the GNOME, in a commentary on how Canonical and Ubuntu people claimed that “We offered our help to GNOME, and they didn’t want it.” […]

  68. Ubuntu Linux and GNOME: The Disputes continue | Linux Desktop Says:

    […] The specific problem that started the current discussions roiling the Linux desktop waters was explored by Dave Neary, a member and former director of the GNOME, in a commentary on how Canonical and Ubuntu people claimed that “We offered our help to GNOME, and they didn’t want it.” […]

  69. S04E02 – Stranger in a Strange Land | Ubuntu Podcast from the UK LoCo team Says:

    […] du-jour “CanoniGNOMEAppIndicatorGATE!” (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in […]

  70. S04E02 – Stranger in a Strange Land – OGG HIGH | Ubuntu Podcast from the UK LoCo team Says:

    […] du-jour “CanoniGNOMEAppIndicatorGATE!” (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in […]

  71. S04E02 – Stranger in a Strange Land – MP3 HIGH | Ubuntu Podcast from the UK LoCo team Says:

    […] du-jour “CanoniGNOMEAppIndicatorGATE!” (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in […]

  72. S04E02 – Stranger in a Strange Land – MP3 LOW | Ubuntu Podcast from the UK LoCo team Says:

    […] du-jour “CanoniGNOMEAppIndicatorGATE!” (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in […]

  73. A Rift Opens Between KDE and GNOME « UNIX Administratosphere Says:

    […] is valid or not. Blog posts have been erupting everywhere on this topic: Dave Neary of GNOME: Has GNOME rejected Canonical help? and Lessons Learned – Aaron Siego of KDE: collaboration’s demise – Mark […]

  74. Az Ubuntu desktop eve | KTamas' blog Says:

    […] amit, nos, mindenki a szivere vett, one thing led to another, akit erdekel a teljes sztori az innen induljon ki es kovesse a linkeket. De az Ubuntu amugyis huz el evek ota az upstreamtol egy sajat […]