This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


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

By Nathan Willis on August 26, 2006 (8:00:00 AM)

Share    Print    Comments   

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, 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 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."

Share    Print    Comments   


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

Note: Comments are owned by the poster. We are not responsible for their content.

Linux Standard base has not ended yet.

Posted by: Anonymous Coward on August 26, 2006 07:57 PM
Portland is just partofit.

Merging the distro's is not exactly a simple task.

Linux Standard Base is a Silver Bullet just a slow moving Bullet to get to target.


They're not failures.

Posted by: Anonymous Coward on August 26, 2006 08:54 PM
BlueCurve aimed to make a matching set of themes so that any application would look good on any desktop. is unifying the free desktops.

Project Mad Hatter never intended to unify dekstops, from what I can tell.

Metatheme is basically a more thorough attempt at BlueCurve. It seems dead, but Tango Project is planning to do something with it once they've finished the icon theme.

The Linux Standards Base is unifying Linux OSs, but perhaps not as quickly as some would like.

GTK-Qt just wants GTK apps to look native in KDE.

The desktops won't be unified soon, but they will be eventually. LSB, Portland,, and Tango look like the major forces.



Posted by: Anonymous Coward on August 26, 2006 09:00 PM
Well, I am glad that atleast they got ambitions and atleast they are willing to try.

It probably wont unify the desktops to a synergy of perfect balance and harmony, but hopefully it can help it and blend it together a little bit nicer.

Hope for the best!<nobr> <wbr></nobr>:)


heretic thought

Posted by: Anonymous Coward on August 26, 2006 10:51 PM
There was a discussion on local usenet group about the people they called PengWins. The individuals who switch from Windows and exect to find similar functionality. Some group regulars claimed that such individuals "pollute" Linux with their ideas and that they should switch back. I don't agree, but it started me thinking why people switch ? They are running desktop, not servers, and they have no UNIX-like experience. What is the driving force ?

I realized that it was the diversity of the desktop. There is only one desktop environment on Windows. One can change theme, but it is always same old Windows. On UNIX-likes there are some 50 desktop environments and window managers. There is something for everyone, simple ones, complex ones, large ones, small ones, fast ones and slow ones.

I believe that the primary reason for switching, for non-technical user is just a diversity of desktop. And, as we see, every now and then somebody is trying to kill that.



Re:heretic thought

Posted by: Anonymous Coward on August 27, 2006 10:14 AM
I switched out of curiousity and desire for more network power than windows when internet took over for the local BBs scene. Having grown up with family computers from dos to win2k. I'd explored all the operating systems I could get my hands on until someone gave me a huge thick book with a cd in the back.

My first Linux was Slackware with a rather unpleasent install process and reluctance to read the manual but I was young and spoiled on pictures so long after retirnment of dos. Now, I can't remember the last time I build a machine with only one booting OS.

I gotta tell ya, the diversity of applications is part of the apeal for me. There's no one solution for everyone and you can see it in each personal "perfect config". I can understand the desire for more uniformity but it is a daunting dream with the array of hardware the kernel runs on.


Man on the moon?

Posted by: Anonymous Coward on August 27, 2006 12:23 AM
Ever since Newton invented Gravity, it became impossible to put a man on the moon. Even if we did get there, how would we bring back that cheese without it melting during reentry? And that is nothing compared to the complexity of finding a good tortilla chip which can withstand the pressures of being shot into space.

Sure there is going to be difficulty here, but that doesn't mean that your assumptions of impossibility are true, or that these previous one-year projects are indicitive of success (or not) of these new projects. APIs are human-made and can be modified, and now that both KDE and GNOME finally understand the importance of this idea (they didn't before), I would expect success.

Success, if for no other reason that I am not involved and I prefer to be optimistic, especially when I have no real idea of the challenges.


confucious say

Posted by: Anonymous Coward on August 27, 2006 01:34 AM
Man who complain that something can not be done, should step aside and make room for the man who is doing it.


Re:A Solution in Search of a Problem

Posted by: Anonymous Coward on August 27, 2006 04:16 AM
Since the article author already got it wrong, you're concerned about things that actually do not exist.

The Porland Project is not about unifying free desktops, it is about allowing access to desktop features, also called desktop integration, in an uniform way.

Neither of the participating desktop project has to be changed for this, nor does it restrict any customization.

The Portland Project's work provides a new way into the desktop, it does not remove or change the current paths applications can use.

Kevin Krammer
xdg-utils developer



Posted by: Anonymous Coward on August 27, 2006 04:42 AM
Youre mixing the nuts. Bluecurve never was about unifying desktop apis, and novel has never tried it either. The whole article is meaningless and basically serves no other purposes than FUD.

Let people do constructive work, if you are too limited to see any solutions you should just keep to yourself, and cerainly not list unrelated projects which hasnt succeeded doing something they didnt try to do.


You don't get it

Posted by: Anonymous Coward on August 27, 2006 05:43 AM
As already mentioned and summarized <a href="" title="">here</a>, you completely misunderstand the goals, aims, specs and working idea behind, LSB or Portland.

None of these (!) tries to unify the desktop as you state. You cannot compare these to things like bluecurve or others.
Why should they try to unify? They have completely other aims:
- LSB aims for a standard ABI
- aims for a common base which can be shared between desktop environments
- Portland aims for easy tools for 3rd party vendors to exectute simple tasks.
And, all were quite successful until know, and each of them is still developing further and further.
(Examples: Portland is used in Google Earth and others, freedesktop produced a common input system (scim), a common communication system (dbus), and so on, and the LSB is well known and used in enterprise Linux environments).

The only project which really aims for the unification is the only one you haven't mentioned: the Tango project. The try to unify the desktop with naming schemes for icon-sets and wallpapers to give the desktop environments the ability to share the same icon set - which results in the fact that standard icons are the same among all apps.
And, they already did a great job, and the naming schemes implementation is in strong development in KDE as well as in GNOME right now - so they are successful.

Sorry to say it with so hard words, but since you completely missed the aims of the described projects, and also, which is even worse, missed the most important project in the described topic, your article is not worth reading - and should not be on such a famous place!


Please Look Closser.

Posted by: Anonymous Coward on August 27, 2006 06:35 AM
LSB intergates freedesktop. Freedesktop is one of the spec development grounds from LSB. Most of Freedesktop specs will upstream into LSB.

Portland is part of LSB projects to build stuff to help Win32 developers to migrate to LSB without using Win32 like envorment like

If you look closely the Linux attack is just slow moving. But its moving. Hart of it is LSB.

LSB does not just define ABI. It defines directorys, config locations and filenames of stuff. On top of that desktop standards are entering as they become stable. Most of the distros have agreed to follow LSB. So any standard of Linux is better to go threw LSB since you really don't need to go threw the agreement process all over again.

LSB is the silver bullet. Without the agreement between distros no project could even merge the Linux desktop. Many people think LSB is just server. Sorry to say that is where it started but not where its going. Without a stable base of the system merging the desktop was point less. So they merged the base first.


Oh, I get it just fine, thanks

Posted by: Nathan Willis on August 28, 2006 04:46 AM
I don't take issue with any of the technologies mentioned, and as I state in the article, I think Portland stands a good chance at succeeding at its technical goal.

But its technical goal and its marketing talk are wildly at odds. To quote from the press release sent to us just prior to LWCE:

A breakthrough in desktop Linux will be announced today at 3:30 p.m. ET to coincide with the afternoon LW panel on desktop Linux. No need to hold, if you wish to use this earlier.

A community open source effort is releasing its first software that ties together the two leading Linux desktop environments (KDE and Gnome). As you know, one of the biggest issues for adoption of Linux on the desktop has been that every application developer needs to choose between one or the other or both and that adds cost and time to shipping Linux-ready applications for the desktop. All major ISVs would prefer one desktop environment for Linux.

The group making this happen is called the Portland Project. Last year it brought together scores of the different Linux desktop projects to get them all to focus on addressing the problem and driving consensus. Shockingly it appears to have worked and to have accomplished something that the big IT vendors had not been able to do themselves.

The key claims in need of re-examination are in paragraph two, for the record.

As to the question of whether the other cited projects also exhibit a similar disconnect, it's easy to forget after-the-fact how they were touted at the time; I leave it up to you to read the linked material -- some of which is only accessible via Wayback Machine, regrettably.

The bottom line is that over-the-top predictions on the importance of a technical project must always be taken with a hefty grain of salt, and really, we would all be better off if they were skipped entirely. Pass on the P.R.; get in touch when you have working code, then we'll all respect it based on the merits of its performance -- not the breadth of its presumption.


In this case they're not trying to unify desktops.

Posted by: Anonymous Coward on August 27, 2006 06:41 AM
It's not a silver bullet - what they're trying to do is to make irrelevant which desktop you're using - so long as you've got the Linux Standard Base installed.

Use whatever desktop you like.


Silver Bullet?

Posted by: Anonymous Coward on August 27, 2006 07:19 AM

Portland intends to generate a common set of Linux Desktop Interfaces and Tools to allow all applications to easily integrate with the free desktop configuration an..,

"end user has chosen to work with."

End Quote!

Yet you tend to be stating the purpose of the Portland initiative is to Unify desktops - funny it states a common set of api's/tools for app integration - I didn't see it state its purpose was to unify to a common desktop. Furthermore, the LSB (Linux Standards Base) is to give developers a common file structure and road map - not to unify Linux distros.

I wish you guys (reporters) would get your facts straight before posting inaccurate fud and misinformation. I find this happens especially frequently where technical issues are concerned. Please go back and re-check the "stated" purpose of the Portland initiative and the mission of the LSB once more. And who said the mission of either initiative as meant to be a Silver Bullet?

Talk about embellishment, Sheesh!


So what about wxWidgets?

Posted by: Anonymous Coward on August 27, 2006 08:30 AM
I agree that portland won't be the silver bullet for this situation. Although, I find it interesting that no one has mentioned wxWidgets. wxWidgets already has a quite usable multiplatform API: Linux (GTK), OSX, Windows, and even some embedded devices. So why not make wxQT? I mean instead of reinventing the wheel here, why not take advantage of this existing framework and API? At least it wouldnt need a VM, unlike portland.


Re:So what about wxWidgets?

Posted by: Anonymous Coward on August 28, 2006 12:48 AM
Although, I find it interesting that no one has mentioned wxWidgets

wxWidgets is definitely an option developers with multiplatform applications should look at.

However, developers using other base technologies like Qt or GTK should also have the possibility to gain access to desktop capabilities.

So why not make wxQT?

You mean wxKDE, wxGNOME and so on? Just wrapping another toolkit would not get you better desktop integration

I mean instead of reinventing the wheel here, why not take advantage of this existing framework and API?

That's what we are doing, we take advantage of the already proven implemenations and just delegate from a common API to them.

Reimplementing all functionality would be pretty stupid and lots of work.

At least it wouldnt need a VM, unlike portland

Not sure what VM stands for in this context. Assuming you meant virtual machine, Portland does not need one, especially not the common desktop API usually referred to as "DAPI".

Kevin Krammer
xdg-utils developer


Re:So what about wxWidgets?

Posted by: Administrator on August 28, 2006 08:25 PM
GUI APIs like wxwidgets by themselves do not give the application programmer control over the desktop interface itself. For instance, adding a status icon to the 'system tray' with its own little menu and readouts. To do this you have to marry yourself to either Gnome or KDE (or Xfce) and that is a very big choice.

Another example is just determining if the accessibility mode has been enabled, or helping the user enable it.

Allowing programmers to target only one library for the most often used desktop-oriented features will make it much easier to write applications for Linux desktops.


small steps

Posted by: Anonymous Coward on August 28, 2006 12:43 AM
Imho all projects you named did a little thing to unify a piece of the desktops. Portland also will. It wants to make it easier for developers to target Linux desktops that stick to the standards. Nothing wrong with that!


Dr. Portland and Mr. Hyde

Posted by: Anonymous Coward on August 29, 2006 08:17 AM
The Portland participants fall into two camps:
1) the practical guys who just wanted to collect
and standardize some of the scripts that ISVs had
already been writing for themselves into a
package called xdg-utils.
2) the visionary guys who wanted to replace the
existing KDE and Gnome APIs with a silver bullet
called DAPI.

The guys in the first group couldn't quite bring
themselves to kick the guys in the second group
out of the room. That's why, if you look at
<a href="" title=""></a> you see both
efforts represented. xdg-utils is already
being used by ISVs, but I haven't heard of
anybody using DAPI.

Your skepticism is perhaps appropriate with
regards to DAPI, but quite out of place with
regards to xdg-utils, which is a small and
useful contribution to the standard linux


Re:Dr. Portland and Mr. Hyde

Posted by: Anonymous Coward on August 29, 2006 07:04 PM
2) the visionary guys who wanted to replace the existing KDE and Gnome APIs with a silver bullet called DAPI.

No! Neither subproject of Portland is meant to replace existing desktop APIs.

They are an additional way to access desktop services.

DAPI, either as a library or as a set of D-Bus interfaces allows to implement the more sophisticated integration tasks, because it is easier to do some things in code than in shell scripts.

but I haven't heard of anybody using DAPI

That's because DAPI itself is more powerful but also more complex. Implementing it properly takes more time and our resources and those of the interested ISVs are focused on xdg-utils right now.

Once the demand for integration tasks increases beyond the offers of xdg-utils, DAPI will become the more suitable solution

Kevin Krammer
xdg-utils developer


Re:Dr. Portland and Mr. Hyde

Posted by: Anonymous Coward on August 29, 2006 11:29 PM
Kevin is one of the folks in the second group
I mentioned. Once DAPI is finished, they want
to replace the simple xdg-utils scripts with
versions implemented on top of DAPI.
It's not clear to me what benefits this
would bring, and it would hugely increase

The DAPI proponants, primarily Lubos, have
never really defined how many things DAPI
will do. Lubos has refused to rule anything
out. As far as I can tell, he would actually
like developers to code to DAPI rather than
to Qt or gtk, and he would like all GUI widgets
to be out-of-process. If you know of a URL
where Lubos has set limits on what DAPI will
be used for, I'd like to see it.


Re:Dr. Portland and Mr. Hyde

Posted by: Anonymous Coward on August 30, 2006 06:35 AM
Kevin is one of the folks in the second group
I mentioned

I definitely feel flattered for being called a visionary, I count myself primarily to the first group and IMO as the contributor of the first set of scripts as well as large portions of the shared code, I can be counted as part of the script people, can't I?

And, whoever came up with this might care to explain why they think so, but we're not on the quest of replacing GNOME or KDE APIs.

I guess this is true for all involved KDE developers, but I certainly like the KDE API: its elegance, its features, etc

Once DAPI is finished, they want
to replace the simple xdg-utils scripts with
versions implemented on top of DAPI.

While it might be possible to create an xdg-utils implementation based on DAPI, it would be an additional effort.

I think our resources are better spent maintaining the current scripts and developing DAPI as a separate solution for tighter integration and the more complex tasks.

We have already encountered a couple of difficulties while creating the scripts, since any kind of sophisticated encoding/decoding will have to be done in the calling applications.

As far as I can tell, he would actually
like developers to code to DAPI rather than
to Qt or gtk

I think that's a pretty far fetched assumption. A better assumption would be that he would prefer people to code for Qt/KDE but he's obviously acknowledging that other developers feel different.

If you know of a URL
where Lubos has set limits on what DAPI will
be used for, I'd like to see it

Since this is an implementation of the Portland integration tasks, this is the list of things that need to be implemented.

If any contributing developer would actually prefer some meta toolkit solution, they would be working on wxWidgets, we KDE developers prefer to spend our time on improving KDE code, but will also spend time on improving cross-desktop cooperation.

Kevin Krammer
xdg-utils developer


Re:Dr. Portland and Mr. Hyde

Posted by: Anonymous Coward on August 31, 2006 01:17 PM
Everything you say sounds fine, but somehow
I doubt Lubos agrees with you. Back when
I was following Portland, he was unwilling
to answer questions like these, and seemed to
have quite grandiose plans for DAPI. Perhaps
he's just not as good at communicating as you


Re:Oh, I get it just fine, thanks

Posted by: Anonymous Coward on August 29, 2006 08:23 AM
So what you actually complain about is the P.R. talk?

Yes, probably press releases state more than the technical descriptions, but where is the surprise?
And, yes, projects evolve, and projects develop, and projects alter their aims. Again, where is the surprise?

The aim of the Portland project was always a short/mid-term aim which was aimed at specific needs of ISVs- it never aimed at creating a unified look. And since you've wrote about gtk-qt-engine and bluecurve that's exactly what a reader could think.

And to write like is dead or was just to produce specs is misleading. Guess what, dbus lives and so do a lot of other projects of fd.o. fd.o itself also, btw.
Sure, several projects of fd.o are dead today, but keep in mind that fd.o is also *meant* to be a breeding place to check what comes out.
And writing like the gtk-qt-engine is something like the LSB is just disturbing. The first thing does not have anything to do with the other one, and I'm quite sure that you know that. And, also, writing about the LSB like it is dead or has no relevant meaning at all today is also just strange and does not help anyone.

Do not compare apples with pears or even with bananas. Not even if the P.R. of both was misleading at the launch of these projects. If you wanted to complain about P.R. and marketing, do it, but with the right words. For example, mention them at least once in your article.

And, talking about words: are you aware of the fact that neither in the quote nor in the given link to the newsforge article you will find the word "unify"? You introduced it in case of the Portland Project.


Re:Oh, I get it just fine, thanks

Posted by: Anonymous Coward on August 31, 2006 09:03 AM
While you raise some interesting points, the hundreds of millions of end users out there don't care about any of these subtleties. They just want something that's easy to use and that is reasonably consistent from office to office, employer to employer. That is one of the several reasons that most end users stay with Windows; another major one, of course, is OEM preloading agreements.

As for the PR issue: you're right in that most folks who read NewsForge probably know better than to take press releases at face value. After all, we've been watching Microsoft for years.<nobr> <wbr></nobr>:-) But that's exactly what works against PR blurbs like that cited here. In the FOSS world, it is already known that press releases by themselves are suspect. Therefore, when you, as an organization, make a PR blurb with any part of the FOSS community as your intended audience, you've got to make sure that it's accurate, or else you're likely to lose your credibility with that audience. It seems that the article's author is saying that this is what happened, in which case, he is absolutely right to complain about the PR talk.


Re:So what about wxWidgets?

Posted by: Anonymous Coward on August 29, 2006 06:50 PM
For instance, adding a status icon to the 'system tray' with its own little menu and readouts.

Hmm, bad example, there is a cross-desktop specification for system tray stuff
<a href="" title=""><nobr>m<wbr></nobr> tray_2dspec</a>


Re:not another api

Posted by: Anonymous Coward on August 31, 2006 09:22 AM
OK, which one?

The two "major" desktops being discussed here, GNOME and KDE, have their own API's. That's because they started out using different toolkits (GTK+ and Qt, respectively). To dump one of those API's would mean either a massive re-write of one of the desktops, or the abandonment of one. Neither of those choices will fly in the real world.

For example, there are tons of people out here who use KDE, including Linus himself. I, too, mostly use KDE, as do most of the guys in my office. SuSE has always favored KDE. Linspire also installs a KDE desktop. I was at Walt Disney World a couple of years ago, and I saw one of their animation labs; all the PCs were running the KDE3 desktop. However, most Red Hat folks use GNOME, as Red Hat has traditionally contributed to its development. If you use Ubuntu, currently the most popular GNU/Linux desktop distribution, the desktop that comes with it is GNOME. Many people, therefore, like and use GNOME, too.

So, again, which API or desktop do you get rid of?


Re:not another api

Posted by: Anonymous Coward on August 31, 2006 11:28 AM
As I said at the end of my post:

There are a lot of languages in use, so why not gui api's? Lets just live with it. That is not advocating getting rid of one.

I think it would have been better if one of them had never been started, but they have and its water under the bridge.

I was never seriously suggesting we get rid of one, they are both too well established, but was making the point that putting a new api wrapper around the two existing apis' means there are now three api's, not one - how is that a solution? I would rather have two apis than three.

It would only be a solution if all existing apps within KDE and Gnome were also switched to use the new api. But that would be more or less equivalent to getting rid of both of them - a complete rewrite.

Like I said - lets live with the two api's, but dont write another one. People can pick which one they want to use. So long as both desktops survive, then so what? One is C++, one is C (bindings aside), so they do address different areas.


Re:not another api

Posted by: Anonymous Coward on September 02, 2006 07:14 PM
...was making the point that putting a new api wrapper around the two existing apis' means there are now three api's, not one - how is that a solution?

That's one of the misunderstandings: very different scope.

The new API is a wrapper around a small portion of the desktop APIs, allowing for a limited set of task to be done in a common way.

For example it isn't necessary to wrap or implement things that are covered in specifications, e.g. communication between application and window manager or location of trash folders.

Kevin Krammer
xdg-utils developer



Posted by: Administrator on August 26, 2006 06:03 PM
It is never said why is it a silver bullet. Nor exactly what he means by it, and which parts of the problem each initiative proposes to solve.


Not intended to be a silver bullet

Posted by: Administrator on August 27, 2006 12:42 PM
Each of the initiatives you mention addresses specific needs, none of which your article describes. For example, the BlueCurve theme was created to provide a distintive look and feel for a specific commercial implementation - Red Hat. Because the themes are openly available, they can be used elsewhere, and have been. That seemed to be a success.

The Linux Standards Base (LSB) has specified mamy common interfaces and has been widely adopted. Software can be distinctive, yet most major distributions meet these standards, so that initiative seems to have accomplished its objective.

The Desktop Linux initiative has made huge inroads in building components that can be used in desktop systems, and the number of implementations that use its work have mushroomed. That, too, seems to be a work that has had considerable accomplishments.

I do not see a lot of success in the various consortiums. The DCC is the latest consortium with limited success. United Linux is another example of a consortium that did not seem to work out. Yet even there, code gets developed out of these initiatives that can be freely used in other work (and has been), so to say that these efforts have been a complete failure is probably too strong.

I find that in free software, you can take the best ideas and run with them, and even when an idea doesn't work out, you can take the best of it and learn from both the best and worst.

To me, the only thing lacking in the free software movement is marketing. If a few of the big companies would put their full heads, not only into server systems marketing, which has seen some success, but into desktop systems marketing, I could see more success there. IF someone is looking for a market, I would use the inexpensive free software to develop underdeveloped markets first, particularly in relatively poor technology regions of the world, and use those markets to generate interest, testing, critical mass, and an income source. The US and Europe are unlikely to dump their large installed based of well established desktop systems unless the combination of lower cost and greater security and stability created such a compelling argument that people abandoned, en masse, the current status quo; fairly unlikely to happen, though it is, I suppose, possible.

Forget about that silver bullet, though. It could be that you are among the few looking at this in that way; I certainly am not.


A Solution in Search of a Problem

Posted by: Administrator on August 26, 2006 11:30 PM
Portland is a solution in search of a problem.

Linux does not need a unified desktop. Being able to customize the Linux desktop is a feature, not a bug!

Microsoft has a unified desktop. In its attempt to please everyone, it is useful to practically no one. Having multiple desktops to choose from allows the user to choose the configuration which is right for the tasks he or she does -- and the hardware he or she is doing it on.

Standardizing on a "unified" desktop might be a dream of ISVs, but it isn't the ISV that makes the market -- it is the user base. And the user base seems to be quite content with having a variety of desktop technologies to choose from, if the proliferation of projects is any indication.


How important is important?

Posted by: Administrator on August 28, 2006 03:30 AM
You said "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."

whilch makes the same mistake you'd pointed out yourself earlier when you'd said:

" Its symptom is a wild disparity between the tasks the code actually performs and the claims made about its importance."

If this project can hook in the ISV's, then it will be more important than the silver bullet you are proposing.

When Linus started dinking around with his hardware in 1990, the Linux of 16 years later was unimaginable. In the same manner, but under a different timetable, ISV participation itself is an enormous sea change in it's own right.

The momemtum of the marketplace is held up in the inertia among the existing ISV's who are living in the Windows' ecosystem. So while the KDE/Gnome "split" is an interesting parallel, the deeper implications of the Portland project are deeper than you are realizing. As the ISV "species" start to migrate over to the Linux platform at the desktop level, there will be an increasing pressure on the Windows Only ISV's to make the leap.

Whether this project can accomplish the acceleration of ecosystem permeability at the desktop level remains to be seen. But make no mistake, when photoshop, quicken, filemaker pro and other major desktop companies begin selling into the Linux marketplace... then we'll be looking at a whole new ballgame.

Oh, but wait... is the Linux ecosystem willing to pay for software on the desktop? I believe it's as willing as the Windows world, where piracy is rampant. There are always going to be good eggs who are willing to shell out greenbacks for the businesses who provide high quality software. Even if a large number of others won't pay.

Regardless, the ISV's who have held out with Microsoft in the hope that Linux would go away... have to admit that because of server-side success LINUX IS NOT GOING AWAY. Now they need to decide whether and when to begin supporting it as a platform.

David Pool,
Portland, Oregon
(not associated with the Portland Project)


not another api

Posted by: Administrator on August 29, 2006 08:23 PM
I should think the last thing Linux needs is yet another api.

And the goal seems false - the aim is to "unify" the desktops. But the true way to do that would be to get rid of one of them, not create a third api wrapper.

And the wrappers never do there job well enough, never cover all the functions, and introduce another set of bugs to add to the total.

There are a lot of languages in use, so why not gui api's? Lets just live with it.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya