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

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

Recap

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

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

2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mark helpfully ropes in Ted Gould to answer any questions:

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

Sjoerd Simons tries to be encouraging under the circumstances:

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

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

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

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

March 18, 2009: GNOME 2.26 is released.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ted Gould presents messaging menus.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

… to which Celeste Lyn Paul replies:

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

September 24, 2009: GNOME 2.28 ships.

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

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

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

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

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

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

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

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

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

Wonderful news all ’round, congratulations both!

Such… optimism.

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

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

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

  1. nzjrs says:

    The links in the following paragraph are wrong AFAICT

    On the same day, Colin Walters begins a discussion about a different form of application menu on the GTK+ and XDG (freedesktop.org) lists. Ted Gould points out how some similar issues were dealt with in the Ubuntu messaging menu.

  2. Ploum says:

    The way they tried to push libnotification in Empathy reminds me a lot of that bug: https://bugs.launchpad.net/gtg/+bug/496445

  3. The Emapthy indicator patch has not be included upstream for 2 reasons:

    – It used to be of very poor quality; just see the length of the review I posted on the bug. Furthemore I spent a lot of time tracking crashes reported upstream which were actually a nasty side effect of this patch.
    Note that the quality of the patch improved a lot now as I don’t receive such crashes any more.

    – Telepathy is a very flexible framework and we are thinking that such feature should be implemented directly in the indicator applet (using Telepathy) rather than in Empathy. We worked hard to design API flexible enough to allow Ubuntu doing that and are continuing to help them to move to that direction. That’s something I discussed with Ken during the Brussel UDS for example.

  4. Vadim Peretokin says:

    Last 3 posts on Planet Gnome seems to come from here. Hasn’t everyone else moved onto the solutions part?

    • Dave Neary says:

      Do you think that this historical perspective is contributing negatively to the debate?

      I haven’t spoken to Jeff about this, but believe that he is acting with the best of intentions, and has been tactfully avoiding adding pro-GNOME or anti-Canonical spins for the most part.

      For my part, I think that this series has been a positive contribution, allowing everyone to agree on how things happened, so that (moving forward) we can concentrate on participant’s interests, not positions.

      Dave.

      • Steve George says:

        Dave,

        I personally don’t think it’s helpful. It’s at best Jeff’s personal understanding of the situation and lets be honest people don’t change their recollections of situations. So both sides in this argument aren’t going to change because of Jeff’s seven (really!!?) blog posts on this.

        This debate either needs to move forward to find solutions, or frankly both sets of people should just get on with doing their own thing.

        Steve
        ps my personal opinion.

        • Jeff Waugh says:

          I’m irrelevant, Steve. My time spent on this is not time away from the next GNOME release or the next Ubuntu release.

          The “sides in this argument” won’t change because of my posts? But what if Mark’s claims are clearly incorrect, for whatever reason? He might not be able to admit it, or even apologise for it, but the community will be much the wiser as the result of my work. :-)

      • João Pinto says:

        If you believe there wasn’t enough debate already, and the key objective should be to keep an historical debate, then yes, it may have some use.
        If your goal is to improve collaboration between projects, then no, I don’t see how this will help.
        It is just a list of events selected and presented by someone which clearly assumed a position on the debate.

        Everyone will have it’s own view on how things happened, because different people have different interpretation for the same events. If you are seeking to get a common historical view, it will fail.

        Trying to demonstrate a specific view of many events on the last years will not reveal the participants interests, for those please set up an effective meeting, have a clear face to face discussion and show some direction for the future.

        • Jeff Waugh says:

          I believe that can happen only once an understanding is reached about the mistakes of the past. See the series contents post and my comments on the others.

  5. Anonymous Coward says:

    Yes, Canonical experimented with, designed, and developed Unity largely on its own. So what?

    Ultimately, what matters is adoption: if Unity is embraced by the 12 to 30 million desktops currently using Ubuntu (no one knows the exact number…), then it will be in Gnome’s best interest to become compatible with it.

    Canonical wants to lead the Linux desktop in a new direction. They want us to follow them. Isn’t that what we want from Canonical, leadership?

    • bkor says:

      You’re asking questions which aren’t core to the issue.

      Mark seems to say that we didn’t work with them. Me perspective is that they didn’t work with us.

      To answer one thing you raised: Canonical doesn’t lead the Linux desktop. Nor does anyone want leadership from them. That said, don’t interpret this as a negative nor positive comment.

      • Steve George says:

        Right – so what’s your _solution_ to the first point. I understand your perspective, and Mark has a different one. So how do things move forward?

        Raking over these old coals is boring, I personally don’t think we need another set of blog posts on a partial view of history. Jeff may not intend to be biased, but he has bias (everyone does). And even if he didn’t, he has only partial information – he knows nothing of what happened privately. And if he did, he can at best interpret intentions he doesn’t _know_ what they were. So it all comes out as a partial picture of history.

        And history isn’t the problem, we know how many of the actors feel about the situation. But what about the future, the questions are:

        a. Do they have the same, or mutually acceptable goals?
        b. Assuming they do, how do they work together in a reasonable way?

        Steve

        • Jeff Waugh says:

          Mark made some extraordinary claims about both the GNOME community and individuals within it. He has doubled-down on those claims. History does not support them. That needs to be cleared up to build acceptance and trust before the community can forgive and forget.

          Private discussions are at best irrelevant to the activities of an open community, at worst they’re an attempt to work around it.

          I haven’t got to my angle on conclusions and solutions yet, but there are good people in Canonical and GNOME trying to sort things out. That said, it will be impossible for anyone to figure out a co-operative way forward if we don’t agree on what went wrong. No one will be happy.

        • Scott James Remnant says:

          Hi Steve!

          I see these blog posts of Jeff’s as a response to the posts being made by Mark on his blog; they’re not raking over new coals, they’re trying to put the other side of the story over about the coals Mark is raking.

          I don’t agree with Jeff on a lot of his points (we had a long and enjoyable multi-hour call before he started this series, my co-workers enjoyed hearing just my side of it too ) but I do believe that Mark’s current posts warrant a response as there are two sides.

        • bkor says:

          Steve: I’ve asked the board to intervene. They haven’t kept me up to date on any progress. So if they’re doing something, they haven’t said anything yet.

          If nothing happens after GNOME 3.0, I will. Until that time, people are busy with GNOME 3.0.

          The history as recorded by jdub is interesting though. Everyone seems to agree on the timeline, but not on the conclusions.

          This is really important to avoid any misunderstandings in future. And to quiet people who say it isn’t useful. Seemingly, though we agree on the history, there is disagreement on the conclusions from that history.

          Need to analyse why different conclusions are/were drawn and get some mutual understanding. Maybe some assumptions are different. This to avoid a repeat in future.

          In any case, asking for a ‘solution’ is simplistic in my mind. First understand what is going wrong, only then solve it.

          That said, I really dislike public accusations.

      • Anonymous Coward says:

        IMO this question is core to the issue.

        Superficially, the issue appears to be about the details of a failed effort at past collaboration. In reality, the whole brouhaha is about the *nature* and *balance of power* in the relationship between Gnome and Canonical — and Red Hat.

        For several years I’ve been seeing all these complaints about how Canonical hasn’t assumed a leadership role commensurate with Ubuntu’s large installed base, or how Canonical hasn’t contributed back enough, and so on.

        Well, here they are, hiring top talent, doing truly original work, and attempting to lead the Linux desktop in a new, different direction. And they’ve released it all under GPL v3 — a bona fide contribution to the Free desktop ecosystem.

        And what do we do in response to their attempt at leadership? We tell them no. We tell them they can only do it how we want them do it, when we want them to do it, and only if we want them to it — i.e., “our way or the highway.”

        No wonder Mark et al are frustrated…

        The beauty of all this is that ultimately users — that is, regular people — will decide whether Unity succeeds. If Unity is embraced by Ubuntu users, it will be in Gnome’s best interest to become compatible with it. To refuse compatibility with Unity because things didn’t happen the way we hoped strikes me as less than smart.

        • Jeff Waugh says:

          Canonical have always been entirely within their rights to create their own software, their own way, for their own reasons. Many other organisations have done this, with GNOME, and no one has ever kicked up a stink. There’ll be the occasional, “bummer that they don’t contribute” grumblings, but that’s about it.

          What’s different here is that there was clear messaging suggesting that Canonical would contribute. Then, from mid-2010, Mark Shuttleworth was criticising GNOME for not accepting Canonical contributions for “political reasons”. Ultimately, that was used as public rationalisation for the jump to Unity.

          Canonical can take Free Software and go their own way all they want — many companies have! — but criticising a FLOSS project so publicly and viciously for not collaborating, when the failure to collaborate was very clearly in Canonical’s court? This will not stand, man.

          • Jeff

            Is it so difficult to accept that our actions might have been exactly as we said they were?

            * we said we were starting to invest in design and engineering, something new from Canonical.

            * we were interested in things like indicators and the messaging story; rather than secretly doing all the work, we took it to the UX hackfest (you’ve documented all of this, including the enthusiastic acknowledgement of that contribution to discussions by others)

            * we started writing the code. We broke it out into patches that would be useful outside of Canonical, and Ubuntu.

            * we made efforts, above the stated bar, to have that code embraced. We managed to collaborate with other desktop groups more easily than our natural partners in GNOME

            * we feel let down by those counterparts, who seem to show little willingness to find common ground. Issues like copyright assignment and infrastructure are held against the work, when the same issues are not blockers elsewhere (pulse, cups)?

            * we feel frustrated, and express that frustration.

            In order to collaborate, you need two parties, with common goals and a willingness to find common ground. You’ve documented many steps we took to find that common ground – showing up at meetings, discussions with different parties, patches generated and debated, designs proposed and implemented, collaboration with KDE and other groups. And yet, your conclusion is that *Canonical*’s shortcomings are to blame for the mess (and it is a mess). Despite accepting that neither I nor anyone at Canonical is perfect, I don’t accept your conclusion.

            At the end of the day, we’re accountable to our own conscience. We care about the success of free software on the desktop, and we feel that when the chips are down, what matters is our willingness to put our money where our mouth is and make it happen. In this case, we felt that the right way forward was to commit to doing the design and implementation of what we felt could be the most exciting interface for the free desktop, ever, and in Unity I am confident we have the beginnings of that. The world is welcome to it, with love, under the GPLv3.

            Losing my cool in these discussions was not a triumph of leadership. Me culpa. But my intent in criticising the actions of others is to catalyze change for the good in GNOME: better accountability, more consistent application of policies, more openness to contributions and ideas. It remains to be seen whether the community tackles those problems, or not, but I don’t think that shrugging them off would have been the right thing to do. I don’t think it’s the right thing for you to do either.

            It’s hard enough to challenge an organisation from the inside. It’s impossible to do so from the outside. I had thought, after many years bringing GNOME to the world, acting as the frontline for bugs and integration issues, we were an insider. And as an insider, I felt I had every right to want the game raised.

            Nevertheless, it’s becoming clear that it is easier for senior folk in GNOME to define me (and by proxy Canonical) as an outsider, and dismiss my commentary as the complaint of a competitor, someone who “doesn’t understand GNOME” or “is working an agenda”. Perhaps some will look at these timelines and see what I see: a good faith effort to engage from the start on exciting work, backed with the willingness, if engagement was not forthcoming, to knuckle down and do the work that nobody else seemed willing to do.

            What remains now is to understand the basis on which we *can* collaborate.

            • Jeff Waugh says:

              I don’t believe history supports your claims, and I’m willing to put in the time to convince you of that, for the betterment of Canonical, Ubuntu, GNOME and Software Freedom. Clearly I’m making progress — your tone has changed substantially, and you’re even writing “GNOME” correctly! But we’re not there yet.

              (Remember: I am not a “senior person in GNOME”.)

          • Anonymous Coward says:

            Jeff, looking at Mark’s post above, it’s impossible not conclude that Canonical has contributed _a lot_: (1) they have invested meaningful amounts of money, people, and resources to produce *Free software*; (2) they have publicly stated that they would like to see Unity and/or its libraries incorporated into Gnome, even if only as ‘external’ components; and (3) they have made it very easy for Gnome to use the code produced by Canonical.

            Why can’t Gnome treat Unity, say, as one of its upstream projects?

            • Dave Neary says:

              “upstream” means “code flows from them to us”. Unity is a consumer of the GNOME platform, and Ubuntu is a consumer of GNOME. They are thus downstreams, not upstreams.

              Not all platforms make it easy to do anything you want on them & get the platform changed. Ask Microsoft to change the Windows API for example.

              So the question is, how easy should we make it? I think we have struck a fair balance, but some persistence is expected of the requestor.

              Cheers,
              Dave.

              • Anonymous Coward says:

                Dave — yes, I know that Gnome is “upstream” to the Ubuntu project.

                The Unity project, however, should arguably be viewed and treated by Gnome as akin to an upstream project — or maybe as a sister project, if you will — a project from which Gnome draws code, in much the same way it draws code from other projects.

                Anyway, that was my rationale for using that word… does that make sense?

                • Jeff Waugh says:

                  It is much like Nokia’s Maemo user experience and Hildon APIs. It used GNOME, but was not related to GNOME.

                  Did anyone kick up a stink about that? Not really, because the relationship and expectations were clear.

                  Did Nokia accuse GNOME of playing politics with contributions they barely even attempted to make? Not so much.

                  I’ll be covering Unity in an upcoming post… but keep in mind that it is not the object of GNOME community frustration, and it’s only a symptom of a larger problem.

                  • The difference, clearly, is that we set out thinking of our work as a contribution to GNOME. Yes, we have constraints in how we can work, or how we want to work, but so does every other participant in the ecosystem.

                    On the up side, we have a unique commitment to free software on the desktop, and the willingness to go to great lengths to make it great and popular. THat wouls surely be the basis for compromise and collaboration: different parties bringing different things to the table, subject to different constraints.

                    Instead, what we found was an attitude that our concerns and constraints were an easy basis for discrimination against our work and contribution. We get accused of “not understanding GNOME”, when it’s clear that GNOME does not have clear policies and does not apply them consistently. What’s really driving all of this? Competitive instincts without any overarching ledership that sees GNOME as more important than the differences between its participants.

                    GNOME is entitled to determine the way it acts, but drawin hard lines means you leave some people outside and unable to participate. Ask yourself whether it’s wise for GNOME to draw such hard lines against contributions from Canonical, lines it has not maintained against contributions from elsewhere.

                    Your argument about Maemo and Hildon misses the point: we *set out* to contribute, as we could, as documented in my blog at the time, and those of many others. We feel stumped and stifled. Making a virtue out of Nokia’s reluctance to try and get their work adopted under a GNOME umbrella seems a strange way to encourage others to do it differently.

                    • Jeff Waugh says:

                      It would have been difficult to discriminate or play political games with an entity which failed to engage. If you “set out to contribute”, you fluffed it, plain and simple, by not engaging with the community in a useful manner. If you wanted to get your stuff in, you should have tried.

                      It wasn’t until the GNOME 2.30 process that the first Canonical related module was proposed (and amusingly, it didn’t even suffer from “constraints” such as Launchpad), and only for GNOME 3.0 that the first indicator related API (not user interface!) was proposed.

                      Canonical didn’t even give GNOME a chance to “play political games”, “discriminate”, “draw hard lines” or show “competitive instincts”, which is why your extraordinary accusations must be answered and corrected.

                  • Anonymous Coward says:

                    Jeff — as I see it, the differences between Unity and Maemo/Hildon are considerable, but let me mention just two: Canonical has explicitly and repeatedly asked Gnome to consider Unity for inclusion even if only in the form of ‘external’ libraries, whereas Nokia never asked for such inclusion; and Unity is 100% Free software, whereas Maemo had mandatory proprietary components.

                    But I’m happy to see we’re no longer debating whether Canonical is contributing. We agree: Canonical is contributing _a lot_ — in the form of working code that will be used by millions the moment it’s released.

                    Your complain, then, can be boiled down to this: Canonical failed to contribute _on Gnome’s terms_ — terms, which, as Mark has pointed out, are not explicitly stated nor consistently applied by the Gnome project.

                    I still have not heard a good answer to my simple question: why can’t Gnome draw code from Unity (treating it as something akin to an upstream project like PulseAudio)? (The responses to this question, so far, have been in the nature of “we can’t because Canonical did or didn’t do this or that,” which is backward-looking. I’m looking for an answer in the nature of “we can’t because Unity is or isn’t this or that.”)

                    • Jeff Waugh says:

                      Canonical has explicitly and repeatedly asked Gnome to consider Unity for inclusion even if only in the form of ‘external’ libraries

                      No, they did not. Asking GNOME developers to depend on optional, external APIs is one thing (and in many cases, those patches were accepted), but proposing APIs and user interface components for inclusion is quite another. The first Canonical-related proposal for inclusion was for 2.30, and the first which had anything to do with indicators was for 3.0. That’s a long period of not doing homework.

                      Canonical failed to contribute _on Gnome’s terms_ — terms, which, as Mark has pointed out, are not explicitly stated nor consistently applied by the Gnome project.

                      They were and are explicitly documented and consistently applied.

                      why can’t Gnome draw code from Unity (treating it as something akin to an upstream project like PulseAudio)?

                      It could. But what, and why?

        • bkor says:

          I’m sorry, but I totally not understand you.

          I don’t work for Canonical, nor Red Hat. Still, you assume it is about companies and so on.

          Additionally, you go on about Canonicals contributions. I also do not care about that.

          I’ve said this is about Marks claim that Canonical contributed one specific thing. I think he hasn’t done enough in this case.

          I don’t care how much Canonical does in other topics. The claim is about this specific case. In this case, I don’t think enough effort was made. We asked for responses, got none.

          Offtopic to this is all the things you’re bringing up. That Canonical is attempting leadership and stuff about Unity. I don’t understand why you’re bringing this up. It all seems unrelated.

    • Mike says:

      Some of the things to consider are:

      * If you combine all of the Linux desktops (i.e. non-servers) running non-Ubuntu Gnome, they still do not come anywhere near the number of Ubuntu desktops that are out there.
      * While this is the case, Ubuntu is marketed heavily for non-IT people. Meaning the percentage of people sending patches back is less than for other Linux distributions.
      * While this is the case, Ubuntu tools like apport make it so that even non-technical users will be at least reporting at least some bugs such as program crashes. Apport is turned off by default in stable releases though. Even during betas, bug reports are private until bug triagers make them public. Then there’s the question if they ever make it coherently upstream. And whether those developers working on the latest commit will bother to check if this bug from a release several months back is still around.
      * An important point – Canonical does not have the manpower to fork Gnome. Ubuntu users have exposed many bugs in Gnome, and they have been fixed upstream. What happens if Ubuntu starts moving further and further away from Gnome? Ubuntu just barely manages (and often does not manage) to get useful, coherent, reproducible bug reports upstream to Gnome, never mind having the capability to fix these things in-house. It does not have the capability, and I’m skeptical it ever will. Natty Narwhal has a handful of Unity components which Canonical has changed, and many more Gnome and freedesktop applications there as well, many of which are broken by the Unity changes. Who is going to fix these bugs which have appeared in the Gnome/fd.o applications Ubuntu still uses which broke due to changes in Unity? As they are piling up on Launchpad, and as Ubuntu 11.04 is only six weeks from release, I have to say that 11.04 will be shipping with them, and the more Unity diverges from Gnome, the worse it will get. I should note it is not always obvious right off the bat that the bug was caused by Unity either, so a lot of these Unity-caused bugs in Launchpad are not marked as such. I myself have massaged bugs and written patches for Ubuntu when it helped fd.o, Gnome and Ubuntu. I will continue to do so as well. But I am not going to do so for fork-related things, or problems caused by the fork. Who is going to fix these bugs I wonder? Canonical does not have the manpower to do this, and the community is not going to freely contribute time helping create a fork where none is needed.

      To quote Steve Ballmer, “Developers, developers, developers, developers”. You are right that Shuttleworth can snap his fingers, and 80% of the users of a Gnome module will disappear, and start using a Unity module. But the problem is, then Shuttleworth has to support that module. The users shift, but the developers do not. Many of them are working for Intel, Red Hat, Novell etc. Even ones like me who are independent, speaking for myself, I will still contribute to Ubuntu, but not on forked stuff or problems caused in other applications by the fork. This is something to consider.

      Anyone who is skeptical of what I am saying should read through some of these bug reports for nux, which is breaking compiz all over the place

      https://bugs.launchpad.net/nux

      And nux is what they are devoting manpower to. The real problem is Gnome and fd.o applications which are broken due to all of these Unity changes.

      • bkor says:

        Just to add to this: I think all distributions are great, whatever their focus is. I’d wish Canonical would ship gnome-shell and work more using GNOME infrastructure. They don’t and though I find it really unfortunate, I think it is interesting to see one distribution/company trying a different method/way.

        I don’t prefer any distro/company over another. Though obviously to develop GNOME I want a distribution which just has GNOME as-is. But that is just related to helping GNOME development, nothing more.

      • Alex H says:

        Wow, I’d never heard of nux before. So they’ve written an entirely new toolkit, apparently Clutter is not good enough, and they’re the only ones using it.

        Well, frankly, bully for them. If that’s the bed they choose they can lie in it.

  6. Lapo says:

    You’re correct giving credits to president Vuntz, but you should also mention Jon McCann, he did a huge coordinatin work (not considering his design work), without him there will be no Gnome 3.

    P.S. : I’m not affiliated with redhat or anybody else, just to be clear eh :-)

  7. David says:

    Interestingly, webOS 3.0’s notifications look like a hybrid between Ubuntu’s and GNOME Shell’s.

  8. ConsultantsAreMessy says:

    Today I learned that GNOME stands for the GNU Object Model Environment. This all makes so much more sense now.

  9. Anonymous Coward says:

    Jeff — for whatever reason, I can’t reply to your last response…

    Regardless, it’s now obvious to me that we can all look at the same facts in as much detail as you want, but we simply won’t reach the same conclusions.

    Let’s hope Gnome and Canonical will find a way to work together.

  10. chris says:

    I wanted to comment on Mark’s wishlist entry about empathy:
    https://bugzilla.gnome.org/show_bug.cgi?id=574744 mentioned above.
    Has anyone read it?I will quote what Mark said here:

    #1: “Empathy would benefit from being integrated with the libindicate messaging
    indicator. This would allow people to access the contact list and jump directly
    to unread IM’s, as Pidgin can.”
    #2: “libindicate (not libnotify) is a library for indicators, and the messaging
    indicator is the first of those. Ted Gould would be
    the best person to speak with. He says there’s some documentation in the
    package in 9.04, not much more to go on, sorry.”

    Honestly, this looks like a request opened from a user who’s entrirely new in open source software and/or has just opened his first ticket on a bug tracker.
    The reporter has to comment to specify what each descriptive term is uses actually is!
    Such a feature request is equivalent to a “please help, my $app crashed” bug report.
    Yet the same person some days ago, only 2 years later, questions the leadership and in general the whole operation of GNOME…
    How many people outside Canonical are even *aware of the existance* of libindicate at this point since it hasnt even been released neither individually ( which Ted Gould’s later comment proves) neither in Ubuntu? My guess would be very few to hardly anyone. How many empathy developers?
    Also i would like to point the use of “9.04”. This is the one of the most important roots of the problem. Mark assumes/demands others to know (thats subject to the readers interpetetion) what he is talking about.
    With a “since everyone around me at Canonical know, that means the whole FOSS community knows” mentality. And sadly, its not just Mark, this is common practice from Canonical. Its also how most of its employees write in their blogs. Like the product they produce is the only thing out there and everyone should know everything about it. You have to save the article locally and s/Ubuntu/Linux/g to start making some sense. Yet they claim to truely understand the FOSS community? This is straightforward corporate mentality of the modern kind, with an LGPL3 wrapping. Plain and simple.
    All these clearly indicate the direction Canonical wants to go IMO.

    Disclaimer: This post tried very hard to avoid insulting all mentioned parties in order to actually be posted on this blog and hopefully be useful.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments will be sent to the moderation queue.