Analysis of the conflict among Canonical, GNOME, and KDE

These problems might take forever to solve [as the organisations are large]... In the meantime, I wouldn't be surprised if someone came up with a better technology model as a replacement.

Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI.

Would be nice if some of this was reusable across OSX/Win/Linux. Perhaps my desktop work should be done in the browser?

The old unix guys might have approached it this way if they had the current web at hand to reuse/augment/embellish upon. Maybe this is more in the true spirit of unix than QT/GTK/Xwindows?

Posts like these really show the problems in the current free software development world; balkanization between different stakeholders and bizarre processes that alternate between bureaucracy and anarchy. Watching the tug-of-war between Red Hat and Canonical play itself out in the form of dysfunctional community development process is depressing. I'm aware that watching sausage being made never makes you very hungry, but as a user of free software, I don't feel my needs are served very well by the territorial and political battles being fought.

What makes it even more frustrating to me is that not only are KDE, Gnome 3, and Unity all failing to cooperate successfully on shared resources, but they are all marching resolutely in the wrong direction, regardless of the pleas of the user community. So far as I can tell, everyone hates Gnome Shell, everyone hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess compared to KDE 3. I see all of these projects as engaging in a slappy fight as they march together off the cliff of unusability and misguided redesigns.

OS-wide user scripts and bookmarklets? Sounds good to me.

I'm interested to see how this ends up being resolved (I use Ubuntu, don't like Unity, and Gnome Shell looks to be just as bad) but have only been half-following this drama. This is a really great summary post.

I'm totally unsurprised that Shuttleworth's penchant for decision by fiat and Jobsian cargo-cultishness has driven a wedge between his company and others in the FOSS movement. (For example window controls, before windicators were announced: "Yesterday I decided to move window controls to the other side for our LTS. It's for a secret project. DO NOT ASK ME WHAT THE PROJECT IS."). But I'm also unsurprised that disorganization and what also appears to be at least a little ego and maybe even jealousy has warped things on the other side as well.

The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction.

It's far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don't have formal design documents, it's a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision --- which will usually involve reverting the change which broke things functionally.)

In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn't have a UI, and there are objective measures of "does it work", and "did the benchmark results go up or down", that either don't exist or aren't as important in the UI world. Questions of whether a UI is "good" or "better" than some other UI choice is a question which can't be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical.

One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we do in the Linux kernel world probably aren't needed in other projects. But in the Desktop world, I think the reverse problem is true. It's a much larger and more complicated ecosystem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes organically and informally might work for Linux, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven't found the need to have someone in that role in the Linux development community.