Jeff Waugh created a timeline of events regarding the StatusNotifier specification, the example that's being used to demonstrate how, supposedly, GNOME is not collaborating with the greater Free software community in the same way KDE has been doing for a long time now.
His timeline is supposed to show several things. First, that Canonical did not do what was required to get the API into GNOME as an external dependency. Second, that GNOME did not reject it because of 'not invented here'. And third, that the rejection is meaningless because it had no adverse effect on Canonical's goals.
The first point has resulted in a word-against-word situation; Waugh claims Canonical didn't do enough, Shuttleworth disagrees. I honestly wouldn't know what exactly is needed in order to get an external dependency accepted into GNOME, and I'd love to have an impartial developer look over this bit.
We do know this interesting bit. GNOME developer Owen Taylor states some of the things Canonical apparently didn't do: "They didn't engage with GNOME to make the user interface idea part of future designs. They didn't even propose changes to core GNOME components to support application indicators," Taylor states.
The first point is already a strange one to make (the API leaves the graphical side open to be implemented by the respective graphical user interfaces (GNOME, Xfce, Unity, KDE, etc.) as seen fit), but the second one is even stranger, if you were to believe Shuttleworth: changes to core GNOME components were proposed, but they weren't accepted... Because the API wasn't an external dependency!
Dave Neary also stated a few requirements for external dependencies in a personal email to Shuttleworth - "make the case for the dependency, which should be a few sentences or so, and wait a short while for people to check it out (e.g. making sure it builds)" - but those had all been met as well. Update: Neary posted the full email - with more details - as a comment.
In the meantime, all I see is that Canonical and KDE managed to work things out and get their applications to integrate well with each other; KDE applications integrate nicely within Unity when it comes to the API in question. I'd say that if KDE - of all parties - manages to work together with Canonical, then that's proof enough that Canonical did enough. You'd think collaboration between Canonical and KDE would be harder than collaboration between Canonical and GNOME, considering Ubuntu's GNOME-centric history.
The second point is interesting, and clearly shows the failings of Waugh's timeline. Waugh hammers on about how Unity was unveiled a few days after the API was rejected from GNOME, but he fails to mention that "announcing" Unity actually means "announcing" nothing more than a name. Unity already existed for a long time before its name was unveiled - it was called Netbook Remix.
Then there's the issue of the timeline focussing entirely on mailing list discussions and blog posts, ignoring the various talks that take place on IRC or offline. Shuttleworth insists that Canonical's planned work on the API was shown to GNOME developers back in 2008 (a year before the first entry in Waugh's timeline), and that the GNOME developers saw the API as 'a valued contribution to the shell'. I'm guessing that Canonical - having close ties with the GNOME community - saw this as an assurance, and I have to admit that since we're talking about a community here, and not a cold and heartless company, I agree with them.
Someone's word should mean something, especially in the more informal world of open source/Free software development. It all seems like too convenient an excuse - sure, we may have made promises to you, but hey, we didn't sign a contract so tough luck! That doesn't seem like the kind of attitude that works well in the open source/Free software world. In fact, it'd be nigh-on impossible, since the interpersonal dynamics in an open source/Free software project are far more complex than in a company (where you have a clearly defined managerial structure).
Of course, the fact that GNOME developers liked Canonical's ideas back in 2008 is further demonstrated by the fact that GNOME developed its own alternative, and incompatible, API years later for GNOME Shell. KDE chose to collaborate - despite parts of the work coming from outside KDE; GNOME chose to take a my-way-or-the-highway approach. They could've engaged with Canonical and KDE for the good of users and developers alike, but decided otherwise.
The third point Waugh tried to illustrate through the timeline and his blog post is that Canonical didn't need GNOME to be included in the design process since they could achieve their goals even without the API becoming an external dependency. While manydevelopers have indeed included support for the API despite the fact GNOME hasn't blessed it, Shuttleworth claims that because the API wasn't blessed by GNOME, several developers have stated they are concerned about the repercussions of including support for it anyway.
"The uncertainty created by the rejection as an external dependency creates a barrier to that collaboration [between Canonical and GNOME]. As Jeff says, those patches can land without any problems. But to land such a patch, after the refusal, takes some guts on the part of the maintainer," Shuttleworth claims, "Lots have done it (thank you!) but some have said they are concerned they will be criticised for doing so."
Dave Neary's blog post is far more extensive than Waugh's, and covers several aspects Waugh didn't touch upon, most importantly the role of FreeDesktop.org - which he considers to be a broken organisation that needs to be repurposed. On this, Shuttleworth agrees.
"There are a number of things we can do to move forward from where we are now," Neary summarises his post, "Improve processes & structure for freedesktop.org (this will require buy-in from key GNOME & KDE people), make the operation of GNOME (and the operation of individual modules) more transparent to outsides, cut out a lot of the back-channel conversations that have been happening over the phone, in person & on IRC, in favour of documented & archived discussions and agreements on mailing lists & wikis, and work to ensure that people working on similar problem areas are talking to each other."
I think this is about as accurate a description of the lessons learned from all this as you can get. Who, exactly, is to blame - well, you can make up your own mind. I think I, at least, have been pretty clear who I think needs to change the most.
Grow the **** up...
...probably sums up my overall feeling. I'd say that the best interests of users and developers have not been kept at heart by GNOME, and instead of frantically trying to rationalise everything, they should just be a man about it and admit they've been at fault. I say this as a former heavy GNOME user (I don't use Linux anymore), but GNOME developers might want to sit down and a have good chat with their KDE counterparts about how to interact with the greater Free software community, and how you sometimes need to make compromises for the sake of interoperability - which actually translates into for the sake of users and developers.
Thanks to this little spat, something as bloody simple and elementary as menu bar status icons have become quite the headache for developers (and thus users). Shove that damn pride away, and do what's best for developers and users. We don't give a rat's bum about who invented what, where it came from, or the small technical details. We want our crap to work