Project Portland Article (edited)

[Sriram Ramkrishna <sri aracnet com>]

I have incorporated Waldo's changes.  Please edit and let me know if
there are any problems.

sri

-- 

			      The Portland Project

I had the opportunity to spend a little time with Waldo Bastian,
over a cup of coffee on the project he's leading the effort on
called Portland Project.  The Portland Project has recently been
in the news thanks to an OSDL pr ess release and coverage at major
Internet sites.  Waldo is the chairman of the OSDL (DTL) Desktop
Linux Technical Board.


Waldo's introduction to the project actually starts with 10x10,
Jeff Waugh' s rallying promise at GUADEC 2005 (GNOME User and
Developer European Confer ence) a vision that Waldo agrees with and
wants to see accomplished.  The fundamental question Waldo asks is
"How do we get there?"  To do that Waldo believes that one of the
things we need to look at identifiable usage models.

The usage models today can be broken down to categories.

1. Fixed function. This means that people use the system for only
   one task.  Typical examples are Point of Sale (POS) terminals, ATM
   machines and an airline boarding pass kiosk. An increasing number
   of these systems is running Linux... but it isn't very visible,
   typcially you only see the one application that is running on
   it. These systems don't tend to use the "desktop" concept.

2. Transactional workstation. Here people typically use one business
   application and there maybe some additional tasks that requires
   sending e-mail or use of a web browser. This is the kind of
   system that you find in call centers for example.

3. Technical workstation. This is an interesting one because this
   is an are a 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. Quite some
   microprocessors are being designed on Linux based workstations
   these days and if you were at last years GUADEC you would have
   heared how Dreamworks is using Linux workstations for its work
   on animated movies.

4. Basic office. People in this category use office applications,
   e-mail, web browsers to access an intranet or to access web-based
   applications.  However the amount of functionality used is rather
   limited and doesn't change much over time.

5. 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 idea of application availability
which plays a role in corporate and enterprise as well as home users.

The issue of application availability is not going to be solved
with free software alone. There are classes of applications that
just don't lend themselves well to the open source approach.

It's not good enough to have a TurboTax like software if you
can't keep it updated in time and be able to keep up with existing
tax laws in the country and locality you live in.  Free and Open
Source software have historically been poor in positioning them
selves to meet those deadlines due to the fact that they have only
volunteer resources.  Unless, there is a company behind the project
that is willing to keep tax software updated it's unlikely it'll
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 and hardware peripheral support is a deterrent
to acceptance.

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 not enough sales
to justify investing a lot of money on it.  A classic chicken and
egg problem!

In order to break out of this situation we need to think about Market
Segment Share (MSS).  We need to present Linux as a single unified
platform not as a diverse eco-system forcing ISV's to look at the
various parts.  Vendors should not look at KDE or GNOME, but at the
"Linux Desktop".  When we present Linux as a single platform we
are creating a Market Segment Share that is measurable.  When we
show a large percentage of MSS we have something to drive both
hardware and software vendors to support Linux.  We should fight
segmentation 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 ISV's seem to have the most trouble with
packaging since we don't have a package format that transcends
all distributions.  Waldo believes there is room for improvement
in this area.  Currently, LSB prescribes a packaging format
as a subset of the RPM format.  Even though distributions like
Debian use a different packaing format; they do support the LSB
compliant RPM based packages.  But so far packaging on Linux has
been approached from a Linux distribution point of view, and less
from the point of view of a software vendor who wants to distribute
software independent from a distribution and all kind 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 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.   5% of the desktop
environment is window manager specific; mostly dealt with by the
ICCWM and NETWM specs  and what we have left is the 5% that is the
difference between the desktops.

Good examples are starting of an e-mail composer, opening a URL
in a web browser or running an application as root.  The only
difference with KDE and GNOME is that they both provide access to
that functionality in slightly different ways.

Waldo asks "Can we define an interface that glosses over the
difference and provide one interface and let you access that
funcionality at one entry point?"

This is the basis of the Portland Project.  To provide a stable set
of interface that ISVs can develop against that will work under
any desktop enviro nment.

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 be addressed
by being able to apply policy across applications regardless of
toolkit used. The desktop environment can set policy and the
widget toolkit can follow that policy.  GTK+ for instance can have
policy set to change button order, colors, and fonts.

Project Portland will provide the interface and also reference
materials for developers.  Application developers can use these
interfaces to integrate well for both KDE and GNOME runtime
environment.

The Portland Project wants to give as much flexibility in how Linux
and distribution developers implement their interfaces in order to add
value.  For instance, if your application needs root access the 
current implementation could use 'su' but you're free to use an
alternative.  If we keep the interfaces stable between distributions
then over time application developers will be able to rely on them.

Some issues that Portland Project have been working on are default
applications.  ISV's would like to have a way to register their
applications as the default application for applicable file types.

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 need to
handle future problems like spyware, viruses and other malware.
A lot of people still seem to think that as long as there is no root
compromise there is no problem, but if you're data is compromised
or deleted it doesn't matter whether your OS is protected as you've
lost your data.

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 a sk whether he really
wants to use application FooBar to open all his *.doc files or
maybe we want to let the system administrator put rules in place for
that. The great thing, Waldo says 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 configuation 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.  Waldo says there are still a lot of work to do
in the current systems; there are many different ways for malware to
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 the individual tool-kits and instead move it 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, 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 MSS 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.

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.  Project Portland will work
with popular desktop environment s 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 co mmunity about Project Portland and his vision for the
Linux platform.