If you were, you know, living your lives, you’ve probably missed it, but old fires are burning brightly once again: there’s somewhat of a falling-out going on between KDE and GNOME, with Canonical siding squarely with… KDE. The issue seems to revolve around GNOME’s lack of collaboration, as explained by KDE’s Aaron Seigo.
Before we get to Seigo though, I want to focus on Mark Shuttleworth. In a lengthy post on his blog, he explains that while Canonical set out to create Unity under the umbrella of a GNOME, as a shell for GNOME. They wanted to use GNOME-friendly technologies, and if they were to choose to create something on their own, it would require “substantial review”. Canonical wanted to create competition within GNOME, instead of competing with GNOME.
“We’ve failed,” Shuttleworth concludes bluntly, “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.”
A prime example of this, according to Shuttleworth (and Seigo, but we’ll get to that in a minute) is the work on status notifiers (appindicators in Canonical-speak), which is now a FreeDesktop.org standard, and has been adopted by both Canonical’s own Unity as well as KDE. GNOME, however, while first being open to this idea, later rejected it.
The reason behind the rejection is, according to Shuttleworth at least, that GNOME sees Unity as being in competition with GNOME, and hence, technologies that sprout from it – no matter how potentially useful – are a threat, and not a gift. “It doesn’t integrate with gnome-shell” is the reason given by GNOME, which is an odd reason given the API wasn’t being pushed as an integral part of GNOME; no, it was merely proposed as an external dependency so that GNOME applications running on other platforms could make us of it the API was present.
“So the premier reason given for the rejection of these APIs 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’,” Shuttleworth argues.
The underlying goal, then, seems to be to discourage GNOME application developers from supporting this API – this has failed, according to Shuttleworth, because developers have picked up on the API anyway, whether GNOME likes it or not.
“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,” Shuttleworth further clarifies, “Here we had APIs 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.”
It goes deeper than that, though. The work on this API, and Canonical’s vision for it, were shown to GNOME Shell designers at the 2008 UX hackfest. “[Jon] McCann denies knowledge today, but it was a clear decision on our part to talk about this work with him at the time, it was reported to me that the conversation had happened, and that we’d received the assurance that such work would be ‘a valued contribution to the shell’,” Shuttleworth recalls, “Clearly, by the time it was delivered, McCann had decided that such assurances were not binding, and that his interest in an alternative panel story trumped both that assurance and the now-extant FreeDesktop.org discussions and spec.”
KDE did do the work to work well with the status notifiers, and as such, KDE applications ‘just work’ in Unity, all because the API has become a standard and has been adopted by KDE.
According to Shuttleworth, there’s major problems with the way GNOME is currently run. While the long tail of contributors and developers are just fine and dandy, it’s leadership where things to wrong. “I’ll state plainly that I feel the long tail of good-hearted contributors to Gnome and Gnome applications are being let down by a decision-making process that has let competitive dynamics diminish the scope of Gnome itself,” he states, “Ideas that are not generated ‘at the core’ have to fight incredibly and unnecessarily hard to get oxygen. Ask the Zeitgeist team.”
“This is no way to lead a project. This is a recipe for a project that loses great people to environments that are more open to different ways of seeing the world. Elementary. Unity,” he adds.
As already mentioned, KDE’s Aaron Seigo has also come to the conclusion that GNOME is not collaborating with the greater Free software community as much as it used to. “When I got to the point in Dave’s blog where he justified GNOME not picking up the appindicator work I cringed and then cringed some more,” Seigo explains, “For you see, the appindicator story is not so much about GNOME and Canonical as it is about GNOME and the rest of the free software desktop ecosystem and the regressive behavior being demonstrated there.”
Once, Seigo recalls, there was a lot of effort being put from all parties into closing the several interoperability gaps present in the Free software stack, with FreeDesktop.org being an important piece of that puzzle. More recently, however, it seems like GNOME is eschewing this idea.
“Those days seem to be receding into the past however as GNOME seems increasingly content to ‘do their own thing’,” Seigo believes, “It’s like they have lost sight of the goal of a coherent experience for users of Free software regardless of the applications they choose to use.”
“It is indeed not incumbent upon any project, be it GNOME, KDE or any other to adopt every single technology on offer,” Seigo continues, “However, it is in all our best interests to work together more rather than less and to share what makes sense, even if sometimes it means some short term compromise. KDE has made that decision many times even in recent times as we adopted various technologies such as D-Bus, shared mimetypes, shared icon theme definitions, etc. It’s taken a lot of effort on our part and at times we’ve had to make some compromises, but our users have been reaping the benefits.”
While I generally prefer GNOME to KDE, there’s no denying this last point. KDE has always worked a lot harder on integrating well with GNOME than the other way around, and it seems like this pattern is intensifying instead of diminishing. That’s a very bad thing, since cooperation, especially on lower-level elements, is key in the Free software world. Call it a blessing or a curse, but fact is there are multiple desktop environments, and they need to work together as much as possible.
We’ll have to see what this all leads to, but I’m hoping this ruffles a lot of feather and causes a great stink, since a re-evaluation of what kind of cooperation is important could be just what the doctor ordered.
You can’t blame Gnome for ‘not co-operating’. They don’t want to co-operate, it’s their right to not co-operate.
Although my opinion is that there even shouldn’t be two or more different desktop environments for Linux, I don’t think Gnome devs can be blamed for the path they have chosen.
That’s the price of freedom. We may not agree with the others, but we’ve got to respect their position.