Note: This post is part three of a series of thoughts on the relationship between Canonical and GNOME.
Tensions rose this week as claims were made and refuted — mostly as comments on blog posts about entirely different issues! — about the collaboration and relationship between Canonical and GNOME.
After actively participating in much of that discussion, Mark Shuttleworth (founder of Canonical and Ubuntu) responded in a strongly-worded blog post on Thursday morning.
He made a range of claims, but in this part of the series I will focus on his response to the release team’s stated reasons for the rejection of libappindicator:
The premier reason given for the rejection of [Unity’s indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.
…
Now, I can tell you that I was pretty disgusted with this result.
Please read Mark’s entire post to get a full appreciation for the depth, breadth and consequence of his criticism.
History
The history of “indicators” is quite long, but as that will be covered in the timeline for part four of this series, I will fast-forward to the introduction of libappindicator itself, during the Ubuntu Developer Summit for Lucid Lynx (UDS-Lucid).
November 18, 2009: Application Indicators are discussed at UDS, aiming to replace the notification area and present a single set of menus on the panel for consistency. The KNotificationItem specification is chosen as a basis for the protocol, but “the addition that we’ll need is the ability to define a menu”.
Actions include “develop the application library”, despite the fact that libappindicator development had already begun, privately, one month earlier (first commit: October 13, 2009). To be fair, it was still pretty raw immediately prior to UDS, but work had clearly begun.
December 3, 2009: The Ubuntu DX team’s ApplicationIndicators wiki page is created. One week later it is updated to include a very thorough set of use cases, architecture documents and a porting guide.
December 16, 2009: Canonical developer Ted Gould blogs about libappindicator, links to the StatusNotifier specification.
December 17, 2009: On the XDG mailing list, Canonical developer Aurélien Gâteau proposes the StatusNotifier specification, a reworking of the KNotificationItem spec first introduced as a draft on September 5, 2009.
January 13, 2010: Ted Gould emails GNOME’s desktop-developer-list (DDL) to request feedback on StatusNotifier. This is the first time libappindicator is raised on a GNOME mailing list. It is already too late to propose for inclusion in GNOME 2.30.
A few technical questions are asked about Canonical’s plan to port applications. Concluding the thread, Dan Winship states: “Anyway, we want a menubar-like tray for GNOME Shell too, and the new spec seems like a good plan.”
January 18, 2010: Dan Winship responds to the StatusNotifier proposal, raising his concerns about the specification, spawning a discussion almost exclusively with Aaron Seigo (which I will cover in another post).
(So rereading this, it comes across as kinda harsh, but it wasn’t supposed to be, so just add a “:-)” to the end of every line or something. 🙂
February 6-17, 2010: Canonical developers blog about Application Indicators — including Jorge Castro’s Application Indicator Update, Jono Bacon’s KDE Application Indicators in GNOME and (contractor) Jan Arne Petersen’s Application Indicators — all of which note that patches for application support are already being submitted upstream, ie. GNOME’s Bugzilla.
February 15, 2010: The new module proposals period opens for GNOME 3.0.
February 18, 2010: Colin Walters, a Red Hat developer working on GNOME Shell, raises Canonical’s application indicators work for discussion on DDL.
First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here.
His questions revolve around how applications should use it, how it might fit in with the design plans for GNOME Shell, and suggests that it would make sense for the API to live in GTK+ rather than a separate library.
Ted Gould and Jorge Castro participate in the resulting 11 post thread (there was another subthread, but irrelevant to the proposal itself). Matthias Clasen contributes two grumpy points about Canonical’s approach to collaboration (not designing in the open and asking GNOME developers to discuss API issues on the Ayatana list).
Roughly 6 hours after his last post in that thread, Ted Gould proposes libappindicator as an external dependency for GNOME 3.0, strongly emphasising that the discussion focus only on its inclusion as an external dependency. He includes the key question about the library, raised earlier: “Does this fit the the design goals for GNOME Shell?”
Olav Vitters of the release team suggests that question must be answered before the release team can make a decision. Ted replies, “Obviously that’s a question that I can’t answer. Though, one that I’d love an answer and a discussion about.”
A concern is raised about copyright assignment, and there’s a silly little subthread about versions of the GPL (much less likely to be a problem than the CLA).
The meat of the thread is a discussion about libappindicator’s use of GTK+ menu APIs, with suggestions from GTK+ developers for how to improve the libappindicator API.
Discussion peters out, without answers to the fundamental questions, with Ted Gould having sent a total of 5 emails to a 17 post thread. (Cody Russell also contributed, but not about technical issues.)
March & April, 2010: Two and a half months (Feb 19–May 6) pass without a single discussion about libappindicator on any GNOME mailing list.
❧
Intermission! Let’s take a moment to recall Mark Shuttleworth’s comments about why GNOME developers rejected libappindicator:
Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.
…
The premier reason given for the rejection of [Unity’s indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.
What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.
…
It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.
Intermission over.
❧
May 6, 2010: Last call for comments on module proposals. Dan Winship, a Red Hat developer working on GNOME Shell, replies to the libappindicator proposal with the final word on its relevance to the new shell:
The system status area needs numerous features that aren’t available in libappindicator […] so libappindicator will not be useful here.
As for the trayicons in the message tray […] the StatusNotifier protocol that the appindicator work is built on is just… designed to solve some problem other than ours. I still think we don’t want libappindicator.
So while Dan doesn’t think libappindicator fits with GNOME Shell’s system status or notification goals, he doesn’t close the door entirely to StatusNotifier/dbusmenu (the XDG protocol guts wrapped by libappindicator):
And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now.
Ted Gould replies, “Not to criticize your decision, but just to correct a couple of factual details in your e-mail”, noting that dbusmenu is included in KDE and the StatusNotifier spec, and that libappindicator would be ported to gdbus soon. He doesn’t object to Dan’s decision. There is no further discussion.
May 10, 2010: Mark Shuttleworth reveals the Unity netbook user experience to the world during his opening “keynote” at UDS Maverick, and writes about it later that day:
Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.
May 16, 2010: The GNOME release team meets, and based on the feedback received, decides to reject libappindicator for GNOME 3.0.
June 2, 2010: The release team announces new module decisions for GNOME 3.0, stating the reasons why libappindicator is rejected as an external dependency.
No Canonical developers reply.
Excluding vala-list discussions about wrapping the API, there is a grand total of five pages of Google results for “libappindicator” in the GNOME list archives.
Understanding the decision
Mark is not a day-to-day participant in the GNOME community (he does run a company, after all), so it’s easy to understand why he has so misunderstood the process and motivations of the community — through the lens of the release team’s rejection reasons.
Let’s go through them:
- it doesn’t integrate with gnome-shell
I hope I have demonstrated absolutely clearly in the timeline above that libappindicator was not rejected due to a sense of “competition” between Unity and GNOME Shell: The key advice to the release team was given four days before Unity was unveiled.
- probably depends on GtkApplication, and would need integration in GTK+ itself
Unfortunately, this point is badly written, but it’s related to the suggestion that the API should actually be in GTK+ rather than a separate library. It demonstrates that while the library — conceived and designed without technical or strategic advice from the GNOME community — was rejected, the ideas behind it were not. Mailing list discussions reflected the same view, as shown above.
It’s important to recognise that this is not the behaviour you would expect of those who would discriminate against Canonical, or who had already made up their minds a long time ago.
- we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen
Mark’s response to this was, “We made the proposal, it was rejected.” Well, yes… but keep in mind that he is quoting the rejection itself! 🙂
I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”.
I believe the timeline above clearly demonstrates that Canonical did not do “what was required”. Unpaid volunteers regularly do more to get their work into GNOME than Canonical did in this case. I can barely describe how little effort was invested pursuing this proposal.
Ted Gould is not at fault, by the way. If Canonical wanted it done, it could have assigned different people to the task, more people to the task, or anyone at all during March and April.
The flip side to this is that Aurélien Gâteau engaged with the KDE community early and often in his work to update specifications to reflect Canonical requirements, bring in dbusmenu support, etc. I don’t believe the key difference here is between GNOME and KDE, it is in Canonical’s approach to engagement, and its commitment of developers to the task.
- there’s nothing in GNOME needing it.
Mark’s response:
This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”.
This is a simple misunderstanding: No process exists to “pre-approve APIs”. So that’s not the process libappindicator was submitted to… or rejected by.
Any GNOME module can add an optional (or “soft”) build dependency at any time. Jorge, Jono and Jan even blogged about libappindicator support patches being sent upstream… prior to the proposal!
An “external dependency” in GNOME release parlance describes a particular version of a library that is not maintained by the GNOME community, but acceptable as a required (or “hard”) dependency. DBus is a good example: it’s not a GNOME project, but we can rely on a particular version’s API, ABI and protocol being consistent.
The irony is: libappindicator did not need to be listed as an external dependency for Mark to have achieved his goals. Canonical needn’t have engaged at all! (Sure, that would have created all sorts of different problems…)
Conclusion
Mark’s extraordinary criticisms were made without understanding the process, without understanding the quotes he was using as evidence, and frankly, without understanding the GNOME community’s motivations or intentions.
Key points:
- Canonical barely made an effort to have libappindicator “accepted into GNOME” (which, in the context of his criticism, Mark believed was important or necessary)
- It did not even need to go through this process anyway, because it did not need to be an “external dependency” in order to achieve Mark’s stated goals (ie. application adoption of the API)
- So the rejection of libappindicator, for all the sturm und drang, is essentially meaningless — it had no bearing on the opportunity for collaboration between Canonical and GNOME
- Unity did not exist in the public sphere when libappindicator was declared irrelevant to GNOME Shell, and was not ever the reason why: (a) there wasn’t much interest in libappindicator, or (b) GNOME Shell developers decided they were on a different path
- Not proven in this part of the series, but worth noting: the person Mark specifically chose to attack, Jon McCann, did not decide to exclude libappindicator because — being a design contributor to GNOME Shell — he felt threatened by Unity. In fact, he had no part in the decision, and didn’t know Unity existed!
But libappindicator is just one chapter in a much longer story… see you in part four! 🙂
Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.