The Portland Project
The Portland Project recently gained attention by announcing plans to create an additional set of standards for Linux desktop environments such as GNOME and KDE. Sri Ramakrishna explains its aims, gleaned from a conversation with one of its lead architects, Waldo Bastian.
I had the opportunity to spend a little time with Waldo Bastian over a cup of coffee about the project he’s leading called “The Portland Project”. The Portland Project has recently been in the news thanks to an OSDL press release and coverage at major Internet sites. Waldo, in addition to being one of KDE’s major contributors, works with OSDL (Open Source Development Labs); an organisation that aims to bring Linux to the mainstream. Waldo is chair of the OSDL Desktop Linux (DTL) Technical Board.
Waldo’s introduction to the project actually starts with 10×10, Jeff Waugh’s rallying cry at GUADEC 2005 (GNOME User and Developer European Conference), a vision that Waldo agrees with and wants to see accomplished. The fundamental question Waldo asks is “How do we get there?” To acheive this goal Waldo believes that one of the things we need to look at is identifiable usage models.
Within OSDL DTL, five different categories are recognised:
- Fixed function. This means that people use the system for only one task. Typical examples are Point of Sale (POS) terminals, ATM machines and airline boarding pass kiosks. An increasing number of these systems are running Linux, but it isn’t very visible. Typically you only see the one application that is running on these types of installations. These systems don’t tend to use the “desktop” concept.
- Transactional workstation. Here people typically use one business application, and there may be some additional tasks that require sending e-mail or using a a web browser. This is the kind of system that you find in call centres, for example.
- Technical workstation. This is an interesting one because this is an area where traditionally Unix based work stations have been used. There has been a lot of migration from Unix based systems to Linux systems in this category over the last years. Many microprocessors are being designed on Linux based workstations these days, and if you were at last year’s GUADEC you would have heard how Dreamworks is using Linux workstations for its work on animated movies.
- Basic office. People in this category use office applications, e-mail and web browsers to access an intranet, or to access web-based applications. The amount of functionality used is rather limited and doesn’t change much over time.
- General purpose/advanced office. In this category people are using a wide variety of different applications and there is much more variety in the tasks over time. There is a lot of interaction with people in other organisations.
The other side of coin is the issue of application availability, which plays a role in corporate and enterprise as well as home users. Tellingly, Waldo thinks that the issue of application availability is not going to be solved with free software alone. This is because there are classes of applications that just don’t commend themselves well to the open source approach. For example, it’s not good enough to have TurboTax-like software if it isn’t updated in time to keep up with existing tax laws in the country and locality in which you live. Free and Open Source Software projects have historically been poor in positioning themselves to meet those deadlines due to the fact that they (usually) have only volunteer resources. Unless there is a company behind the project that is willing to keep tax software updated it’s unlikely that it will be accomplished successfully year after year (and well ahead of the filing deadline).
Waldo makes the argument that Linux needs to be able to address application availability and to support usage models like “advanced office” in order to make Linux a viable desktop alternative. Lack of such applications is a deterrent to acceptance (in addition to hardware support, in particular support for peripherals). We have frustrating situations where when you meet with hardware and software vendors they acknowledge that Linux is a great platform and they would love to support it but there are too few sales to justify investing a lot of money in it. A classic chicken and egg problem!
In order to break out of this situation we need to think about market share. We need to present Linux as a single unified platform, not as a diverse eco-system that forces ISVs to look at the various parts. Vendors should not have to deal with KDE or GNOME, but rather with the “Linux Desktop”. When we present Linux as a single platform we are creating a market segment for ISVs that is significant. When we show a large percentage of market share we have something to drive both hardware and software vendors to support Linux. We should fight fragmentation in Linux distributions and the desktop environments. Creating strong standards is a key strategy to encourage third party software investment.
I mentioned the fact that ISVs seem to have the most trouble with packaging since we don’t have a package format that transcends all distributions. Waldo acknowledges that standards in packaging are lacking and mentions that the Desktop Architects conference meeting in Frankfurt, Germany will be talking about issues like these. The idea is to make recommendations to distributions to improve their products, including packaging. LSB prescribes a packaging format in the form of a subset of the RPM format. So even though Debian, for example, uses a different packaging format natively, Debian supports installing these LSB-compliant RPM-based packages as well. There does seem to be quite a bit of room for improvement in this area though. So far packaging on Linux has been mostly approached from a Linux distribution point of view, and less so from the point of view of a software vendor who wants to distribute his software independent from a distribution, and for all kinds of different distributions.
Waldo shifts his focus to a problem all of us are familiar with. Which desktop should we develop for? ISVs have the perception that if they have to write an application, that they will need to choose between one desktop environment over the other. While there is a bit of truth to that, the reality is that 90% of the functionality an application requires comes from the X server. Only 5% of the desktop environment is Desktop Environment specific, but we have to deal with the 5% that is the difference between the desktops.
Good examples are starting an e-mail composer, opening a URL in a web browser or running an application as root. Both GNOME and KDE provide the same functionality; the difference is how you access that functionality.
Waldo asks “Can we define an interface that glosses over the differences and provide one interface, and let you access that functionality at one entry point?” This is the basis of the Portland Project: to provide a stable set of interfaces that ISVs can develop against and that will work under any desktop environment.
Waldo points out that Project Portland is not a widget set. There are plenty of widget sets out there and we have the ability to use theme engines to be able to make them all look the same visually. Differences like button ordering and dialog boxes can and will be addressed by being able to apply policy across all applications regardless of toolkit used. The point here is that the desktop environment can set a policy for that and the widget toolkit can follow that policy. GTK for example already has a gtk-alternative-button-order setting. Same for colours and fonts. It should be noted that fonts aren’t handled very well currently.
The Project Portland will provide the interface and also reference materials for developers. Application developers can use these interfaces to integrate well with both the KDE and GNOME runtime environments.
Linux developers will have the freedom to change how the interfaces are implemented in order to add more value to those interfaces. At the same time, the interfaces need to be stable so that they can be relied upon. Additionally, these interfaces can take advantage of other parts of Linux, like SELinux, allowing greater integration.
Linux desktop or distribution developers will have the freedom to change how the interfaces are implemented in order to add more value to those interfaces. For instance, if your application needs to use root access the current implementation will prompt for password and uses su, but you’re free to implement one for your platform based on sudo for example, or one that requires a fingerprint instead of a password. The Portland Project wants to give as much flexibility in how Linux developers implement the interfaces. The important part though is that the interfaces themselves remain stable, between different distributions as well as over time, so that application developers can rely on them.
Some issues that The Portland Project have been working on are default applications. ISV’s would like to have a way to register their application as the default application to handle file types they support. This feature can be open to abuse, as we’ve seen with Windows. But by directing applications to a single interface we can explicitly control that interface. We also need to be aware that we should handle future problems like malware and viruses. A lot of people still seem to think that as long as there is no root compromise there is no problem, but if your data is compromised or deleted it doesn’t matter whether your OS is protected!
We still need to be able to deal with these issues now before they become widespread. With existing security systems in place like SELinux we can integrate them at a single point and be able to assert control over it. When an application attempts to violate a security policy it will not have permission to do so. Waldo says that we need to think about these issues now before they become widespread. If we introduce well defined interfaces for applications to go through, we can put policies in place behind these interfaces. For example we can prompt the user and ask whether he or she really wants to use application FooBar to open all their *.doc files; or maybe we want to let the system administrator put rules in place for that.
The great thing is that with emerging new security systems such as SELinux and AppArmor we can actually enforce that applications go through such an interface and we can be sure that any policy is enforced: An arbitrary application would simply not be allowed by such security system to make changes to the GNOME or KDE configuration files that determine which applications are used by default.
Autostart is another vulnerability that needs to be addressed. Malware can abuse this feature by inserting itself into the login process. We need to start thinking about addressing these kind of problems. By defining interfaces that applications have to go through we introduce control points that we can use to contain these kinds of threats. There is of course a lot of work to do: in current systems there are many different ways malware can insert itself into the login process; autostart is just one of many.
The end state is that we move certain kinds of functionality out of individual toolkits and instead move them towards the Linux platform by encouraging ISVs to using a standard set of interfaces. By doing so we make room for all kinds of innovation across the Linux platform space, e.g. by GNOME or KDE or by Linux distributors.
As we finished our cups of coffee, and our conversation, I had some time to reflect on what Waldo was trying to tell the desktop community. We need to stop looking at our individual areas and see the Linux desktop as a whole. The idea of market share is a strategic way of getting ourselves out of the catch-22 we find ourselves with vendors and make real progress towards the Linux desktop as a dominant platform for ISVs.
The Project Portland is only one of several projects that work towards building the Linux platform. The other significant effort is the Desktop Architect meetings that seek to form standards in packaging, distributions and desktop technology. The Project Portland will work with popular desktop environments like GNOME and KDE to enhance it’s interfaces in order to support the needs of ISVs around the world.
I’d like to thank Waldo Bastian for taking the time to talk to the GNOME community about The Project Portland and his vision for the Linux platform.