The Portland project: No silver bullet for hairy problem of multiple desktops

When OSDL announced the first release of its Portland initiative at LinuxWorld Boston in April, heralding it “a breakthrough in desktop Linux,” I muttered my skepticism to a co-worker. He expressed surprise at my reaction, noting that the initiative employs extremely smart people. I don’t doubt their intelligence, or their sincerity, but I wouldn’t bet a penny on the project living up to its initial claim, because you can’t conjure a silver bullet out of intelligence and sincerity.

The Portland project is an effort to unify the Linux desktop by specifying and implementing a common set of APIs that all applications can use, and by supplying tools to assist application developers. Its primary target is third-party independent software vendors (ISV), a group that the Portland project leaders describe as interested in deploying software on Linux, but held back by the fractious dueling-desktop-environment mess.

The issue is certainly real. The free software community has known it and debated it for years. Multiple desktop environments are a pain for everyone in the software food chain: developers, distributors, and users. Portland is attacking the problem head-on and at full force.

The trouble is, so did all of its predecessors.

Bullet shopping

Ever since the beginning of the dot-com bubble and its infusion of capital into Linux and free software, a new alchemist has sprung onto the stage promising a magic cure to the problem of multiple desktops about once a year. All sincere, all masters of their craft, all hard workers, almost all forgotten today.

Remember Bluecurve? Bluecurve was Red Hat’s effort to create a unified desktop by producing identical themes for GNOME and KDE applications. The themes were almost identical, but the desktop remained un-unified. Looking back at the project with hindsight, it seems obvious that the work was skin-deep, but at the time, it was trumpeted by company and media alike as a panacea.

Novell boasted in much the same way when, after completing its purchase of Ximian and SUSE, it proudly proclaimed the dawn of the unified desktop thanks to the new company’s unique position to combine the best of KDE and GNOME. On the not-for-profit side, freedesktop.org was founded with the goal of unifying the Linux desktop through common APIs. Even Sun got into the act, with Project Mad Hatter, its effort to unify the Linux desktop by sewing together GNOME, Java, StarOffice, and Mozilla.

The list goes on — MetaTheme, the Linux Standards Base, the GTK-Qt Theme Engine. Some projects were primarily technical, some artistic, some philosophical. Some were short-lived, while some continue to this day. They share just two common factors: one, they claim to unify the Linux desktop, and two, they fail to live up to that claim.

But wait, you say, Portland is not a skin-deep widget theme like Bluecurve, nor limited to particular applications like Mad Hatter. Very true. But those earlier projects did not fail to “unify the Linux desktop” because they were too limited in scope or chose the wrong API to attack — they failed to unify the Linux desktop because it is a fundamentally unachievable objective.

Prognosis: werewolf

Don’t misunderstand me: I do not think that silver bullet projects produce poor results; Bluecurve was a nice-looking theme, and freedesktop.org has produced useful specs. I am only saying that these silver bullet projects failed to achieve their lofty goals. Or to put it another way, silver-bullet-itis is an affliction of programmers, not their programs. Its symptom is a wild disparity between the tasks the code actually performs and the claims made about its importance. But our engineering problems are not supernatural, and they have no magic cures.

“Unifying the Linux desktop” is an absurd, monstrous goal; to name it your target is to declare your project a silver bullet. The “unify the Linux desktop” silver bullet projects that persist today have, for the most part, traded in their grandiose ambitions for smaller, more concrete objectives. Assuming the Portland project has done its research, it will probably find a market among ISVs for its API and tools. But that will be the full extent of its influence.

When Fred Brooks wrote No Silver Bullet: Essence and Accidents of Software Engineering in 1986, the werewolf-du-jour was a tenfold increase in programmer productivity. When was the last time you heard anyone announcing a solution to that particular problem? The sad adult truth is that there are no silver bullets, not for “write once, run anywhere,” not for “easy-to-use security,” and not for today’s favorite, “unifying the Linux desktop.”