As CEO of CodeWeavers, Jeremy White heads a company that can truly claim to be, first and foremost, a Linux ISV. CodeWeaver's CrossOver Office products allow Linux users to run many of the popular Windows programs-and the company is a big supporter of the Wine open source imlementation of the Windows API. But when it comes to Linux itself, there's at least one thing that drives White crazy: supporting multiple versions of the desktop.

"This is one of those dirty little secrets that Linux zealots don't want to tell you-and I'm a Linux zealot. There are some amazing and powerful things that Linux does; KDE and GNOME are both wonderful operating environments. Yet there are some basic things that I can't do. For example, I can't write a simple program that makes a menu on the desktop of a generic Linux user. It's not possible because KDE 2.0 did it one way, KDE 3.0 does it another way, and KDE 4.0 will do it yet another way. GNOME 1.0 did it one way, GNOME 2.0 did it this horrible, horrible way, while GNOME 2.2 did it a slightly different way. GNOME 2.8 does it another way that is pretty rational--but is completely different than the other ways. And Mandrake [Linux] doesn't even use GNOME or KDE: it uses the Debian menu system."

White says that it is "absolutely disgraceful" that something as simple as programming a menu is so difficult to do on multiple distributions. "I understand it has to do with the nature of open source development, but we're smart people and should be able to figure this out."

Enter Portland Project, whose mission is to create a set of common interfaces for GNOME and KDE, thereby overcoming what the Open Systems Development Labs calls one of the most significant barriers to Linux adoption on the desktop. "It does some very basic things," says White. For example, there's a command, a very simple one, in which you can say, in effect: 'please make a menu for me.' [See sidebar]. What's exciting is that there's an implementation that works on a wide variety of Linux systems. That means that, long term, an ISV can say: 'We support the Portland Project standard. If your distribution doesn't, then talk to your distro.' And Portland is architected so that a distro can quickly support it."

This approach of creating a common interface to two or more desktops neatly detours around what could have been a political problem: trying to standardize on a single desktop. By not choosing between them, the project has attracted support and representatives from both GDK and GNOME while avoiding any quagmire over whose desktop is better.

Jeff Ayars, vice president of product engineering at RealNetworks, says that Linux has begun to resemble UNIX in its fragmentation. "With all the different package managers, the different methods for registering MIME types, mail clients and other things that an Internet media player requires, we've had to look at Linux support on a distribution by distribution basis." RealNetworks is primarily known as a Windows ISV, but supports Linux through its RealPlayer for Linux, as well as its open source development effort for its Helix media platform and player. "We've had a Linux player since 1996, which usually trails the Windows version by two years," Ayars says. The company has distribution agreements with several of the major Linux distributions.

"We haven't yet picked up the Portland tools," he says. "But we are now planning our next major rev of our player, and we plan to take advantage of them by the time we ship. Projects like Portland are exactly what the Linux community needs in order to compete with the closed-sourced desktops out there."

John Cherry, the Open Source Development Lab's desktop Linux initiative manager, points out that Windows has a distinct advantage for ISVs because it has just one user interface to support. "In Linux, the operating system and the user interface are separate and pluggable so you can use whatever user interface you want to. There's freedom with this approach, but with freedom comes all kinds of problems, as well. That's really what the Portland Project is there to address."

Portland Project came out of a December 2005 meeting of "desktop architects" organized by OSDL Desktop Linux Working Group. "We wanted to pull together representatives from the various organizations in the Linux desktop community-not just the desktops like kde.org and gnome.org, but freedesktop.org, x.org, eclipse.org, openoffice.org, and others," Cherry says. What rose to the top was how do we enable our application developers to be more productive in moving their applications to a Linux environment."

Walter Bastian, Portland's project leader and a Linux client architect at Intel, had been "working on desktop interoperability for some years already so it was a natural fit for me," he recalled in an email exchange. He says that Portland is itself a typical open source project in that it has just a few core contributors, including Tom Whipple, an Intel intern who has been working on a test suite, assisted by OSDL's Bryce Harrington. "We have made good progress," Bastian says. The second beta version is now released and "we are now encouraging people to run the test suite on as many different Linux distributions as possible and report back their findings to make sure the tools work on a wide variety of systems."

Bastian says the Portland development group learned first hand just how different Linux distributions can be. "A particular command line option that works on one distribution may not be available on a slightly older version, and installation paths can differ slightly from distribution to distribution," Bastian says. "These minor issues, taken together, create a lot of work. Of course, that's the reason we have been doing this: we want to save ISVs from having to go through the same pain. It's not until you have gone through such a process that you truly recognize how valuable the Linux Standard Base is," he says, referring to the industry effort to increase compatibility among distributions. "So once Linux distributions start to include these tools in their products, we want the tools to become a part of LSB-so that compliant applications will no longer need to include the tools themselves."

Portland has debuted not, as you might expect, with an API, but with a suite of command line tools. "Originally we wanted to provide a library, but ISVs told us they saw more value in a tool-based approach that would more easily integrate with their products. So we've first focused on tools for the relatively simple tasks, and we'll start looking at a library approach as part of phase two, or Portland 2.0 as I like to call it. There is a technology preview available of the library approach called Desktop API-DAPI." The group has set up a Wiki page, http://portland.freedesktop.org/wiki, for ISV feedback on future functionality, as well as to make certain that the future Portland interfaces meet real world needs. "It also provides a look into what's in store for Portland in the future, although I should hasten to add that I can't guarantee that all functionality listed will make it into a future release."

"The beauty of the tools approach is that it's fairly simple," says OSDL's John Cherry. "The project was conceived in December, and last April, we had our first technology preview." He describes the tools as bash scripts that "provide a common interface application so they can do a particular function on the desktop and that function gets translated, depending on what desktop you're on. If you want to install a desktop icon, for instance, that is done differently on GNOME and KDE. But when you call xdg-desktop-icon, it checks what windowing environment is being run and just does the right thing so the application doesn't have to worry about it." The tools perform basic tasks: icons, menus, opening a file or URL, associating applications with specified of file types. "The more complicated stuff, like printing environments, will eventually be handled by a library, which will come out late this year or the beginning of next. The libraries will probably be written in C and have interfaces for various languages to link to them."

Cherry says that freedesktop.org was an obvious choice to coordinate the effort, which it does via its Wiki. "Freedesktop was the first organization that took a stab at standardizing common ways of doing things on Linux desktops," he says. "That's exactly what we're doing-trying to standardize these interfaces across desktops and applications. Freedesktop.org already has a number of specifications they have posted and are moving through the standardization process, including the icon and menu spec. Portland just puts tools around those specifications."

One of the biggest companies to make use of the tools has been Google, which has ported its popular Picasa picture organizer and Google Earth satellite mapping service. "I installed them just for fun on my desktop," says Cherry, "and then I scrounged through my directory structure, and saw that the Portland tools had been installed. Google just grabbed the tools off the portland.freedesktop.org site and used them." Cherry says that the next step is to make the tools available through Linux distributions-so that they are readily at hand. That's already beginning to happen, he says, and as it does, Linux desktop development will get a little saner.

Sidebar: A Linux Desktop Progress Report from OSDL's John Cherry

As the OSDL's SDL's initiative manager for the Linux desktop, John Cherry has a good view of the operating system's client-side progress. Cherry is a realist, with no illusions that Linux is going to seriously challenge Windows on the desktop in the foreseeable future. Indeed he is careful not even to compare the relative advantages of the two. Even so, he does argue that Linux is moving steadily forward.

"I do think that we're going to slowly get more and more marquis applications ported to Linux, including Google applications, which are prime," he says. "I think we'll see more in the lines of Adobe products at some point. We're going to reach a threshold where users are going to say: 'this is really good, I can do most of what I want with a Linux desktop that I can do with a Windows desktop. There are so many advantages to going the Linux route that there's going to be a kind of avalanche threshold where it's just going to take off. Where and when is that going to happen? I'm not going to go there."

What's your measure of success?

I know that Linux gets market penetration when it has applications for that particular market. So we have started to focus on markets where the application threshold is pretty low. If you look at point-of-sales terminals and kiosks, and other fixed-function applications like airline reservation systems, those areas have incredible market penetration. Most of the users of those systems don't even know they are running Linux.

It sounds like Linux has taken "the low hanging fruit" in terms of market. Will that continue?

Yes. We've made good inroads in enterprise desktop for what we call the knowledge worker. These are computer users who just need email accessibility, browser capabilities, and a basic office suite. That's happening. There are a number of open source mailers including Evolution and Thunderbird. OpenOffice is becoming more and more usable and consistent with Microsoft Office. Beyond the basics, last we counted, there were over 35,000 Linux-compatible consumer applications that consumers used. That's how you get to the threshold of broad Linux acceptance.

Is lower cost the driving force?

That's most of it. But there's also a lot of freedom you get with open source solutions as well. For instance, with Linux, you aren't dependent on the vendor that sold you the product for support. If you like, you can change distribution vendors to get a support program better tailored to your needs.

Do you see Microsoft's Vista as an incentive or a disincentive for moving to Linux?

Officially I don't want to consider Microsoft. Our stand is that that we don't want to go head to head with them: they have such an application advantage. That said, there is a window of opportunity with Vista delayed, especially in the enterprise. Those who are evaluating the next move are going to have to seriously consider alternatives.

What about countries who have said they are only going to be open source? That had an effect on the server market for Linux. Has it also affected the desktop?

It's starting to. In China, there are a couple of government agencies that are working on procurement criteria for desktop environments, and, as of now, they're specifying open source. When you evaluate world markets, the emerging markets like China, Korea, and India are prime targets not just for the knowledge worker, but also for the fully productive office worker.

What does Portland Project add to that mix? Is it a major catalyst or a minor one?

I think it's going to be a pretty good one. The key here is applications, applications, applications. The more applications, the higher up that chain you can go. You start with fixed function and kiosk applications and aim for full consumer support. The more applications that are ported to Linux, the better.

So in the broader scheme of things, Portland is one more way to get applications on Linux-by removing one more headache.

Yes. Our focus is making it easier for application developers. In the Linux market we are always battling a chicken-and-egg dilemma: application vendors don't want to port to Linux because it's a small market, and it's a small market because there aren't enough applications.

When the application vendors look at the cost of entering even a small market, the last thing they want to do is see fragmentation in the environments they have to port to. If I'm an application developer I don't want to say okay I have to port to Red Hat, Novell, Xandros, Red Flag and other Linux distributions. And then when I do that, then I have to port to a KDE or GNOME desktop. The matrix just gets huge. What developers need to justify porting to Linux is the assurance that their application will run cross-distro, cross-desktop. Portland Project is a significant step in that direction.

Where are you in terms of cross-distro?

Cross distro right now is being addressed mainly through binary compatibility and standardization. You'll see most of the activity going on with the Linux Standard Base, LSB, under the Free Standards Group. The intent is to certify Linux distributions against a certain capability criteria, and certify applications against an application criteria. Any LSB-certified application should run on any LSB certified distribution.

How far is along is LSB?

It's coming along: there's a lot of momentum and progress. But it's a thorny problem: binary compatibilities, the library versioning, distro interfaces, and special distro patches-all those kinds of things have to be considered.

It's ironic, because that fragmentation is what helped sink UNIX on the desktop, leaving the door open for DOS, Windows and MacOS.

Exactly. But all the major distributions now are behind the Linux standard today. If you go to the LSB Web page and look at those distributions that have adopted the LSB standard, it's growing by the day and all the major ones are represented there.

Sidebar: Portland Project's Beta Toolkit

Portland Project has taken a keep-it-simple approach to solving the desktop fragmentation problem, opting for command line tools that can be readily deployed by ISVs. The first beta release, xdg-utils, has seven tools-all available for download from http://portland.freedesktop.org/wiki/Project.

Installation Tools

• xdg-desktop-menu: installs desktop menu items
• xdg-desktop-icon: installs icons to the desktop
• xdg-mime: installs file type descriptions
• xdg-icon-resource: installs icon resources

Runtime Tools

• xdg-open: opens a file or URL in the user's preferred application
• xdg-email: sends mail using the user's preferred e-mail composer
• xdg-screensaver: controls the screensaver

For example, xdg-desktop-menu implements Freedesktop's Desktop Menu Specification, in which information about each menu item is stored in a "desktop entry,"-that is, a file containing basic application information in one or more languages. An XML configuration file then defines the layout of menu items, including which items are actually displayed. The tool itself enables programmers to add and remove applications and submenus from a menu, include a vendor-id prefix, specify that changes be made to the current user or all system users, and retrieve help and documentation.