Honest question. Do you think the GNOME project is as healthy today as it was, say, 4 years ago? Benjamin Otte explains that no, it isn't. GNOME lacks developers, goals, mindshare and users. The situation as he describes it, is a lot more dire than I personally thought.

And what exactly should constitute an 'open source desktop'? I last used Gnome 2 six months ago, and it's barely changed from the days when it was still known as 'Mac OS 7.1' - i.e. 20 year-old GUI idioms, barely changed over all those years. (Still not as bad as its CLI, mind you, which is mired in 1970s-era design, or persistent storage, which is 1950s.)

The fundamental failing of all the mainstream Linux DEs - not just the GUI shells but the apps that run on them too - is that they all play to the competition's - i.e. MS and Apple - strengths when instead they ought to be playing to their own - i.e. *nix - strengths. Everyone involved in creating the first Linux desktops instantly forgot everything they ever knew about Unix Philosophy: keep everything small, simple, highly modular, endlessly composable, agile, adaptable. [1]

Instead, they built up these huge, grand palaces, fine testaments to their own mastery of sophistication and complexity, but insanely time-consuming and expensive to construct and maintain, and horribly bad at adapting to changing circumstances and requirements.

FWIW, the Linux GUI folks aren't the only ones to fall into this trap - web framework developers are also notorious for it, as is C++ where the answer to every question on how to improve it is invariably 'add another kitchen sink'.

The problem is this: the likes of Apple and Microsoft, who possess sufficient material resources that they can afford to get away with such a high-cost, high-maintenance strategy. Whereas OSS communities simply do not have the spending power to keep up with them; by the time they've constructed their own edifices, they can barely afford the existing upkeep, never mind the aggressive experimentation and evolution needed to keep it moving forward. Nor can they afford to throw away such a massive monolithic investment as that means starting over again from scratch. So they creak along year after year; okay, the lack of change may appeal to the strongly conservative nature of the majority of Linux nerds/geeks, but I would hope even they would eventually admit that such a strategy means they will forever be left trailing in the wake of the Big Two, with absolutely zero chance of ever jumping out ahead.

Let's call the above approach the 'Intel strategy'. Yes, x86 architecture sucks, but Intel are so incredibly wealthy that they are able to ameliorate its worst failings simply by throwing vast quantities of raw resources at it. What the Linux GUI folks need to adopt is an 'ARM strategy': don't even try to compete with Intel's approach to the problem; instead, develop a nimble, low-cost strategy that plays to your own unique strengths, redefining the problem itself where appropriate to better accommodate these goals, and do an end-run right around the competition.

I mean, consider just one problem: developing a word processor. Outsiders may not think it'd be such a hard problem (it's only one step up from a simple text editor, right?), but in fact just dealing with Middle East and Far East scripts alone is sufficient to put 20 years on even the strongest, smartest developer. LibreOffice copies Microsoft's approach: vast powerful monolith achieved through brute strength. Looks very impressive, but what a vast waste of an opportunity: completely inflexible structure, no feature reuse across other apps, requires a major commitment and loads of time and work to become a developer on it. Conventional commercial vendors can afford not to care about this - if anything, it's a valuable marketing tool, ensuring mass user lock-in. OSS folks though need to squeeze every single line of code, every single minute of developer and tester time, in order to extract every last possible ounce of value they can. Which is, of course, the sort of 'work smart, not hard' approach that Unix Philosophy is all about.

Now, you might think discussion of application architecture is irrelevant to the subject of DE development, but it's absolutely everything: DEs exist solely for the purpose of running applications, so the whole philosophy and construction of the DE inevitably dictate the philosophy and construction of all the applications that run on it.

Off the top of my head, the only Linux DE project whose philosophy is anywhere close is Etoile. Although the notion of a component-based desktop is not new. For instance, consider Apple's OpenDoc, which they abandoned at least partly because it did undermine the vendor-lock-in advantage of giant monolithic apps, ensuring that the main commercial app vendors (Adobe, MS) would never want to adopt it. With the technical issues ironed out I could see such an architecture being a terrific, natural fit for Linux DEs, precisely because it'd play so well to OSS strengths. Make it work, and all of a sudden Linux has a Unique Selling Point that the commercial DEs cannot directly compete on because it's against their interests to replicate it.

And that is what an OSS desktop should be.

...

That's all about where Linux should be heading though. Getting back to where it is today, especially with regard to Gnome 3?

IMO, wind up the entire Gnome project and close it down in orderly fashion. There are far too many poorly differentiated Linux DEs as it is - a period of consolidation in the immediate future would do them all a world of good, allowing more resources to be focused on fewer, more distinctive projects. If we're being brutally honest about it, all Linux really needs to cover all current bases are three production DEs: e.g. Unity as the everyman DE, KDE for the cool kids who love their endless bells and whistles, and Mint for the crusty old conservatives who like their desktops 1980s-style, thankyewverymuch.

All the folks left over by such a consolidation can then go spend some time getting individual GUI apps polished up a bit more (Dog knows most of them seriously need it). A few might even crack open their extremely dusty copies of the Art of Unix Programming, and think about how to apply all that forgotten wisdom to inventing a brand new OSS DE that follows Unix Philosophy through and through - one that doesn't simply continue the tradition of trailing way back in the wake of Windows and OSX/iOS, but instead completely outsmarts and performs an end-run right around them.