I'm just one guy with one keyboard -- there's a lot more going on
than is shown in these notes, and I'm sure my notes have some errors.
If you know of other pages about this meeting, let me
know and I'll link to them.

On loan to IBM CIO. They're providing the desktops for IBM'ers.
Ten years ago, they could tell people to edit config files,
but today they want to target users who don't do that.
They want to lower the TCO relative to fat windows clients,
so systems management is crucial. Security and regulatory compliance, too.

He led the deployment of Firefox at IBM. Took two-three years!
First had to write policy ("open standards required"),
then had to fix the web apps that weren't compliant.
Did a scan of 9M internal web pages.
Helped educate the developers.
Biggest problem now: educating third party vendors who
use ActiveX or noncompliant javascript. Now working with
purchasing department to write requirements into contracts.

Q. Will you open source your crawler? Will you post your guidelines?
A. We can post the guidelines, they're just a page.

Can't deploy a desktop without answering all those questions.
Central wizard to handle installation of a desktop.
Central wizard to handle initial configuration and personalization.

Q. What about accessibility?
A. I'm investing in a screen reader for Linux. Working with Gnome team.
Need some things in X for screen magnifiers and high contrast.
Big focus for next year. I can only get exceptions for the policy
for so long.

Q. What desktop-specific system management do you do?
A. Do you give the user root? Do you provide remote admin? Remote takeover?
Do you allow users to install? Do you lock down the machine?
Do you give the user the ability to defer low-security patches? For how long?
Do you let them pick when patches get applied?
Depends on the business unit; some want really secure systems; some want
really stable systems and don't care about security.

User segmentation and user profiling within IBM. Five different types of
workstation. We're targeting the lowest four categories, not the power
users.

Q. Will these slides be online?
A. No. Munich did it backwards. They talked about it too early.
I don't want to talk this up in the press until most of the work is done.
No desire to be a poster child.

Q. Can you post a summary at least?
A. Sure.

Enterprise enabling the linux client.
Want to lower TCO, but the transition state energy is too high.
His effort for last couple years was to lower the pain of migration.
Needs to be easy for users, easy for system admins, easy for CIO's.

What do CIOs really need?
Want to be able to take a laptop from your
desktop dock to a meeting for an hour, then bring it back.
Network, mouse, projector all that have to switch transparantly
without e.g. restarting X.
Users want to be able to suspend, hibernate, then unsuspend and
have everything working.
Need to expose power management to users. Need a "low power" button
for people on long flights. (KDE folks say "we have that in our
toolbar since three years ago".)
Need wireless drivers and location profile support.
Need the appearance of instant statup.
Need desktop search.
Need input methods and fonts for chinese, japanese, hebrew.

Q. How often do you want to refresh your base kernels?
A. Twice a year.

Q. I don't see "applications" on your list.
A. I didn't put this on the list because it's my problem to work with
the vendors, not yours as linux platform developers. e.g. Brio Insight
Plugin -- we're getting them to support firefox.
Q. But Wine is trying to help solve that problem.
A. I don't want to go that route.
Q. Several years ago you wanted to be at 50000 user by now. Why aren't you
there yet?
A. I wanted Workplace Client. That's how I get the installation easy.

We need things like TPM so we can distribute signed apps and lock out/sandbox
all nonapproved apps.

Document interchange. ODF. If everyone's using Powerpoint, it's hard
to get them to use OpenOffice. We're on a path to get everyone to ODF
on similar time scale as Massachusetts.

Other big gaps I struggle with? When the CEO does his webcasts,
the codecs he uses aren't available for Linux. We need to start
using mpeg4 codecs for our webcasts.

Q. Would you be willing to buy commercial codecs for linux?
A. Yes, as an enterprise. Our network team says bandwidth is critical,
so need to use best available compression.

ThinkPad Linux Configurator (Linux version of Access Thinkpad program)
Makes it easy to configure all the hardware-specific options,
want a picture of your very model showing every option it has.
Gave it to Lenovo. Email grant_shenk at Lenovo if you want this :-)

We need a desktop linux conference.
We also need to go have a sit-in at the linux kernel summit
to get them to

Our hardware database tool lets us go to hardware vendors
and say "We have 50000 users who want a driver for your device."
It also lets us recommend devices that work.
e.g. open source drivers are available for centrino, which
lets us go to other vendors and say "centrino's well supported;
how are you going to respond?"

Q. I've been having much better luck with Nvidia and ATI lately.
They're even assigning a person to just make things work.
They respond very well when you come to them with cool applications
that challenge them. They don't respond well to just general desktop needs.
A. Let's have a separate ATI/NVidia session

Need to get kernel community involved in desktop.
They often say "just solve it in userspace".

Q. Got a specific example?
A. Wireless drivers all wildly inconsistant, need unified API (but see link to Jeff Garzik's work in driver breakout)
Need realtime for multimedia.
Q. Why don't we have any kernel guys here today?
A. Good question.
Q. We need more people like Robert Love working on things like inotify!

Need to get IHVs to care about the Linux desktop!

Openoffice needs to work hard on usability rather than trying to
clone MS Office.

NLD was a quick test. Turned out to be wildly successful.
Next version will be more serious.
Gap-filling needed to hit basic office user.
We do usability testing during development (betterdesktop.org).
We even send usability testers out to different countries
to avoid country bias.
Test ten tasks per week. Actually have developers for those bits on hand.
Evening after the tests, developers try to address the issues.
Sometimes this lets us improve rapidly during the week.
Other times it's too hard, hopefully the videos on the web site
will let others do the improvements later.

90% of people, when asked to tell if they were online,
recognized the firefox logo and clicked on it!

Was root password for things like changing the clock a problem? Turns out, no. (Really?)

We figured out how to set up a usability lab for $1000 and we'd love to
show anybody else how to do it. It's important to make people
comfortable.

We hired Robert Love two years ago, had him do inotify.
Took a year.

We went to call centers and looked at how hard it would be to convert
them to Linux. Turns out they have specialized hardware for voice handling.
Email call center workers wanted good music software, too.
So we worked on that; see Banshee.

Been working on VBA -> OO macro translator.

Challenges:
OpenOffice is the key! We have 6000 internal users.
It's viewed as a cheap clone of MS Office by users.
UI is klunky and bad. Looks worse than MS Office.
MS Office users have trouble using it.
It would be nice if it were faster, good UI, and had some compelling
original functionality.
We're really dependent on Sun's efforts here.
It'd be nice if there was more multilateral development on ooo.

Q. What's stopping Novell from putting more engineers on OOo?
A. We have a few already. It's money, really. If we could have
a revenue strea from it that'd help.

Need a widely accepted way to move apps from Windows. Wine would be
that, but there's this cloud over it in people's heads.

WMV/WMA/MMS support needed! Real's been great, maybe they can help.
If Linux can't play these, people will think it's a cheap piece of crap.

Q. What's the total amount of money needed to get WMA?
A. Publicly quoted price is $420K/year annually to license WMV from MS.
(Linspire pays less.)

Q. These usability videos are great, thanks!
A. They're the only chance some Linux developers have to see women.
(audience laughter)

Our focus is on the basic user, not the power user.
We do lots of business in latin america.
Our customers have no idea how to install software; we
make this a pleasant experience by offering a catalog
of software with user reviews and one-click install.

Q. Has it detected any viruses yet?
A. Yes, windows viruses.
A. (IBM guy:) Business care about this - they don't want linux systems
to act even as passive conduits for windows viruses.
Q. Rathole (this is how the audience vetoes threads that might go on too long).

We have companies sending us hardware every day for validation.
One of our biggest challenges is regression testing
when things like the kernel or KDE change; we want to
make sure the new linspire still works on the old hardware.
Also, lifetime of a motherboard is 6 months -- keeping up
with that is really hard.
Modems are huge for us. Average consumer still using AOL.
Softmodems are a huge mess. Consolidation going on in the
industry isn't helping. We're trying to put pressure on the vendors.

Software is an issue. Everybody wants a financial package.
In India, every PC has Office and the local equivalent of Quicken.

Q. Would Quicken on Wine do?
A. If it works, sure.

Multimedia's a huge issue. All new computers are multimedia machines.
Video playback is especially an issue.
We need games, too. Even when Linux games are available,
they're on the same disk as the Windows game, can't get 'em
separately. (They don't want to split the SKUs because it would
hurt their standings in the industry sales figures.)

Q. What do games have to do with the desktop?
A. The consumer market is the largest single market for PCs,
so games are really a big issue for linux.

Our customers don't think of us as a Linux desktop,
they think of us as a tool to get things done.

It'd be cool to have a central compatibility test for web sites
so web developers could go to one place to find out if their
site was Linux-friendly.

Q. Siemens did a medium-term usability test. If you try to make your UI
look like Windows, they get annoyed if it doesn't actually work like
Windows.
A. It's not a question of copying the menus; it's a question of
"let's not destroy what the users have been doing for the last five years".

We get lots of inquiries about running KOffice or Konqueror on Windows,
or about using KHTML on Windows.
So we're porting KDE to Windows and Mac.
This will make transitions from those OS's to Linux much easier
for both users and ISVs.

Q. KDE is too complex and hard to debug. Lots of strange DCOP messages.
A. Hey, we're just a toolkit. We're not a product. If we were to
simplify it too much, it would make the distros do more work
to add stuff back.
A. Xandros says: KDE is all about modularity. We have no problem stripping
things out.
Q. DCOP messages are annoying.
A. Rathole!

The X server is a real bottleneck. The graphics subsystem is too
slow even on good hardware. This needs to be solved fast.
We've even worked with Keith Packard a bit.
Keith says: often it's a bad use of the X protocol. There's a lot
of application-side rendering going on that should be happening
on the server.

Poor colaboration. Forks all over the place (e.g. WebCore).

Toolset gaps. Linking to the many KDE libraries is a problem.
e.g. to use KDE OpenFile dialog, you have to link to the KDE libraries;
can't do that from C programs. Running KDE programs on a
Gnome desktop looks funny and doesn't work well.
People have tried using a common main loop, but we think
using a fixed ABI won't work. The GCC C++ ABI breaks every month.
[That's an exaggeration; see below. --dank]
RUDI ([1],
[2]) tries
to solve that.
[We ran out of time to discuss it here, but
RUDI's basic idea is "let's use web services instead of C++ calls
for a small subset of high level services".
The speaker says that while he agrees that C++ is a bad
language for providing an ABI, a bigger problem is
early binding. Late binding supposedly lets you stop worrying
so much about a stable ABI. --dank]

Too much crap going on in the open source desktop world.
Self-inflicted FUD. Projects fighting for a piece of that 2%
of market share. (KDE evidently takes a lot of crap from Gnome proponents,
but he didn't give any examples.)
This looks really bad to ISVs.
(An elephant entered the room about now.)

Q. I have a different view of this. The developers for Gnome and KDE work
well together otherwise freedesktop.org wouldn't be where it is.
The problem is the opinionated fan bases.
A. it's also corporations who are pushing their own agendas.
(he didn't mention any names, but maybe he's referring to things like
novell almost dropping kde?)

Q. Supporting both desktops takes a lot of time. We don't have that time!
Unless we can figure out how to make it easier to develop for both
platforms at the same time, we're in trouble.
Q. We need a single platform story!

We want e.g. Adobe Acrobat to work very well in both Gnome and KDE.
It doesn't right now.

Focussing on universal access.
The important people are the people who don't care about computers.
Really being quite stringent about our user interface design.
We have the Human Interface Guidelines, but we also have ideas
about lifestyle and experience design.

Since gnome 2.0 we have a big focus on third-party developers.
We really want to involve projects like Firefox, VMWare.
We've maintained ABI and API compatibility since 2.0;
it's horrendously boring but vital for ISVs. Proof is in
the pudding; the latest VMWare is very nicely integrated into
the desktop.

Gnome release strategy: release every six months reliably;
nice updates without the world changing under your feet.
Release process is phased: four months of development followed
by two months of bugfixing. Fedora and Ubuntu are scheduling
their release schedules around ours because they can rely on us!

The desktop is mostly done, but we need much better system
integration, so we've been working on Project Utopia (HAL, DBUS, etc)
and pushing things like freedesktop.org. Next step is to move
from the WIMP paradigm
(windows, icons, menus, pointing devices) and
on to the important issues (documents, getting laid).

If Mozilla can't give us a stable ABI/API for a rendering engine,
we may have to look elsewhere.
(Mike Shaver, the Mozilla guy:
we have two problems: our APIs are based on
C++, and our stable APIs aren't sufficient to write real apps.
Everyone wants to ship a different mozilla. We'd love to have
everybody use the same Mozilla libraries! I'm very willing to
discuss this issue. I need more details. Also, we don't have
the resources to freeze ABIs all by ourselves. We need help.
KDE/RUDI guy: we really need a uniform way to invoke
the user's preferred mail program and web browser etc.
Mozilla guy: This is rocket science, and not immediately important to most
of our users, so we need help.)

We need more people like Robert Love taking desktop issues
to the kernel, e.g. things like inotify!
And of course, we need better audio, printing, multimedia.

Is diversity really a good thing? Unification is good
for both user experience and for developers (especially the
VB sort of developer).

How do I build better apps? Start with data on users.
Make your own work easy to use by other apps - everything should be
a plugin.

Let's set up the right incentive structure for IHVs to write their own Linux
drivers.
Give driver developers a common API and a clear set of guidelines
that will let them target *every* linux distribution.
Certification? Logo program?

Q. I've heard some kernel developers say that most hardware vendors aren't
qualified to be driver developers
A. Microsoft requires hardware vendors to get certified before
they can write drivers. Maybe we can also certify driver writers?

At this point, everyone was asked to write down on a card
the most important issue facing the projects that had given
presentations. The cards were then stuck up on a wall
in groups. The largest group was for drivers and Plug 'n' Play
issues; the second largest group was "ISV (Independent Software Vendor)
happiness"; the third largest group was kernel issues.
The audience was divided up into breakout groups which discussed
these probles for 45 minutes, then reported back.

The first three breakout groups was for ISVs to
say what was annoying about developing for Linux,
and for the LSB/Gnome/KDE folks to propose solutions.

Problems:

linking against Linux libraries is hell.
There is insufficient ABI discipline among Linux developers. A proposed
solution for this problem was to have the OSDL or LSB bless a set of APIs,
educate open source developers about the need for some ABI discipline,
and provide tools to check for ABI drift.

Once you do pick the Gnome or the KDE api, you face a look-and-feel
problem when a user who picked a different desktop runs your app.
A proposed solution was to pick the most commonly used very high level
functions (like File Open dialog, Open Web Browser, or get/set default browser),
and provide a simple way of using the user's preferred one, even if that's
Gnome and you chose the KDE api, or vice versa. This could be invoked
by running little commandline apps,
or a network protocol, or by a new wrapper library.

The first look at Linux development is terrifying.
The new ISV has to simply flip a coin about which APIs to use.
A proposed solution for this problem was to do something
like "MSDN for Linux".
This could help steer users away from deprecated APIs and toolkits.

In discussions later, the Gnome people commented that even when
they tried to be careful about ABI drift, it popped up in surprising
places, e.g. theme engines. They also pointed out that
fixing a bug can break ISVs, so we may need to even be
disciplined about fixing bugs.

They sell thin client software based on Linux.
The presentation described a migration of 20000 desktops for a retail chain.
The desktops did not store any user data,
so it was practical to simply force a remote network boot
of a script to wipe the disk and install Linux.

One sticking point was that some Windows apps were needed;
for that they used Citrix remote access. They have also used
Windows Terminal Services for this. (They also had a customer
or two that wanted to use wine, so they helped them get Crossover Office
installed.)

Centralized management is key. They use VNC (and say it's implemented
directly in the X server?) to let the helpdesk shadow users.

End user GUI concerns:
absolutely need to avoid unneccessary user changes, since
you can't afford to retrain 20000 users if you can avoid it.
For this project, they used a customized fvwm to achieve
a pseudo-windows look, and XUL customizations to Firefox.

Overall solution cost was about 1/4 the cost of a standard PC/Windows
solution; the savings was about the same as what the customer
would have spent to open a new retail location.
Starting last year, security has been a major selling point;
customers are really tired of windows viruses.
Pricing is flat per user, plus a small maintenance fee.

They have a services and customization orientation;
each customer needs specialized attention. This makes
updates difficult. They try to put the customizations
into a separate install module to make updates easier,
but they still have to avoid promising free updates to
their customers.

Q. What are your font issues?
A. Web pages don't look the same in Firefox as on IE due to fonts.
Also asian fonts are a real problem. We just did some acquisitions
in China, are hoping that will help us there.

Q. What about printers?
A. This is our #1 support issue. Customers which have a single
uniform printer used everywhere aren't a problem, but
customers which have lots of different printers are so
hard to support that we end up giving them windows on the
desktop instead of linux.

An interesting way to approach the driver problem is to pick one
or two laptops and ask what it would take to get
them really working well; he said it turns out to
require lots of work across many different areas.

sometimes there is no documentation, even internal,
for devices beyond the source for the Windows driver.

The IHVs often do a one-time special purpose ASIC that
is half broken, will never be fixed, and they use software workarounds
in the Windows driver.

The PC Company tried writing "open source drivers" into its contracts
a couple years ago, but the vendors weren't ready back then

They only thing IHVs respond to is a real revenue stream.
Give them two big orders, and they'll come around.

Each Linux distro has a list of supported laptops
and an idea of which users are running which laptops.
They need to work together to create the market data
and busness case for better linux support to take to the vendors
A unified hardware compatibility list for all distros would help users
find good hardware.

The Gelato people are working on allowing userspace drivers even
for things like IDE drives or 10ge network cards; maybe that
would make writing drivers easier.
See the lwn article
and the Gelato wiki.

Centrino driver support is pretty good. Business laptops
tend to be easier; the consumer desktops tend to use
the cheapest chipset this month, most of which have no
good linux driver support. We need big customers
to start writing "you must use a linux-certified chipset"
into their RFQs.

On printer drivers: HP is supporting us pretty well. Other
vendors not so well.

We do something fundamentally different than Windows. They make
you download a driver that exposes GUI choices; we encode everything
in the PPD file, then generate our dialog boxes from info in the
PPD file -- and the ppd format isn't quite up to the task.
Our architecture is the right one, but we need to enhance the PPD
spec, perhaps with help from Adobe (the author of the PPD format).
Till from Linuxprinting.org is point person on this; he says
it'll be discussed on the foomatic mailing list.

Modem drivers: it's all softmodems now. Often the hardware
vendor licenses the codec from a third party which places
restrictions on where and how the ihv can distribute the driver.

X needs to handle hotplugged new input and output devices;
you may think this works now since you can plug in a new
usb mouse or keyboard, but that's a kernel bandaid.
There is interesting and difficult work to do to get X up to speed here.

Rumor has it that ATI and NVidia are in a patent deadly embrace;
the first one to really open up to linux driver developers will
get sued by the other. No idea if this is true.

Short term: binary drivers will continue to be needed.
The ATI and NVidia binary driver writers say they are
resource limited, so trying to force them to restructure
their drivers wouldn't go over well.

Intel is currently doing things right; their
graphics hardware isn't the highest performance,
but their drivers are open.
We should focus on a positive message praising companies
that do have open source drivers.

Right now, X is reconfiguring your PCI busses from userspace,
and doing busywaiting instead of relying on the kernel for
those things. The X.org community has plans for dealing with
this, but it's a lot of work.

There are suspend/resume issues. ACPI defines a way to
reinitialize a video card, but hardly any vendors implement it.
FreeBSD does this right.
There's been one meeting a year at OLS about this stuff,
which isn't enough. We need more people working on this,
and meeting more often.
Somebody at Intel's trying to put a summit together;
if you're interested, contact patrick.mochel at intel.com.

Finer-grained power management is needed both by desktops
and by large server farms. Mostly a kernel issue.

Audio. We should ensure we have one well-designed, useful, and
recommended way for game developers and embedded developers to do sound.
We have a network-transparant windowing server,
but not a network-transparant audio system; is there's a disconnect there?

MAS
was developed by the old X consortium, is under the old X license,
would support Jack across the network, and the LTSP people say it works.

Freedesktop.org has been very successful in its
mission so far, and we all believe in it.

We like the agile way freedesktop.org specs come together.
We would like a lightweight way to formalize these specs,
e.g. feed them into LSB.
This is exposing some processes at freedesktop.org that
may need some updating. For instance, freedesktop.org doesn't
speak with one voice to the outside world. How many people
in this room have actually read through the specs there?
(only 20% raise hands) If the folks in this room haven't,
how can we expect the general community to? We need to work
on this.

The old X meetings had a large education component.
Our desktop conferences so far have been aimed at insiders;
we need to add more outreach and education to these events,
and get ISVs to come. OSDW
was a test of this idea, and it
seemed successful.
Somebody said that, just like we need an "MSDN for Linux", we also need an
"PDC for Linux".

So, how do we keep freedesktop.org stakeholder-based, yet provide
some oversight? Maybe an nontechnical advisory board made up of
representatives from key stakeholders (gnome, kde, etc.) to facilitate
communication, and when neccessary, resolve conflicts. The breakout
group looked at actual situations that happened, and found that most
issues had been sorted out by (1) reducing the noise level and (2)
getting the right people together.

OSDL might help by encouraging projects (e.g. Gnome, KDE, Mozilla,
Adobe Acrobat) to improve their support for some of the freedesktop.org specs.

One of the strengths of freedesktop.org is that it's run by
the technical people, and they worked towards solving technical problems
without worrying too much about marketing issues.

Freedesktop.org has done well at making it easier to develop
useful desktop specifications to solve individual problems.
It's a bit like sourceforge.net, though; there are freedesktop.org
specifications that aren't really getting any traction.
We could improve the freedesktop.org site to reflect which
specs are widely adopted.

Waldo would like to see more involvement from projects
like OpenOffice and Mozilla.

Some of the specs are really speculative. Should we require projects to
gain some experience with an initial implementation before encouraging
people to follow a spec, to cut down on the number of specs that turn
out to be bad? The IETF requires two interoperating implementations
before you can create a draft standard.

A spec is not a spec without use cases.
A spec is not a standard (until it it meets some criteria).
Maybe we should encourage people to call these things
proposals until they meet some requirements.

Maybe freedesktop.org needs a neutral person to help
guide authors of proposals.

Several times the group has mentioned the problem that ISVs
have difficulty finding documentation, and choosing
between alternative libraries and tools. ISVs would
like a site with complete, up-to-date, high-quality
Linux documentation. They need roadmaps (perhaps more
than one). There's a lot of misleading documentation out there
which discusses deprecated interfaces as if they were preferred;
the site should help people avoid those.

Such a site should have an advisory board from the community.

Here are some existing documentation resources:

Portals:

Google -- seriously. ISVs say this is where they go for documentation, at least once they know what to ask.

The world is dynamic. X barely handles any change at all without
requiring a restart.

X.org has been maintaining imake for twenty years, and wants
to get out of the build system business. Hence the switch
to autoconf/automake.

X.org has no way currently to tell when they break their ABI.
This makes it really hard for third parties.

Right now, when a security problem is found in a tiny library
like libxpm, X.org's response is -- release the entire X system.
This is one reason they're moving to a modular server.
They're shelving the monolithic code base as of x.org 6.9.

90% of graphics chips are dedicated to 3D now.
X needs to support 3D graphics to take advantage of the
90% of transistors currently laying fallow.
Hence the EXA acceleration work.
Much of the work is in memory management; doing the drawing is the easy part!
This is the short term approach. EXA is part of X.org 7.0, will be
ready for wide use in 7.1. We expect a fairly rapid transition from XAA to EXA.

X should be recast as a GL application. This lets you do all sorts
of interesting things for accessibility (color correction, magnification)
and lets you avoid having multiple 3D drivers (one for X, one for GL).
This is the long term approach -- GL on Linux isn't quite up to this yet.
This depends on the kernel/X interface.

Cleaning up messes - there are turds from long ago we'd like to get rid
of.

Migrating from xlib to xcb -
xlib is broken, doesn't expose all of X protocol,
has too much other stuff in it. xcb is tiny, provably correct, provides
all of the X protocol, lets you use asynchronous X calls to make
your app less sensitive to network latency.

This meeting addressed two issues:
first, it was resolved to come up with a uniform way
for apps to do things like create menu items and get or set
the most common desktop preferences. There are standards
already for how these things are stored, but both Gnome and KDE
have different APIs for accessing them.
This effort was nicknamed the Portland Desktop Integration thingy.
A small group of two Gnome and two KDE developers, plus interested ISVs,
will come up with a short list of services Portland should provide.
The group should then come up with a prototype implementation
simple enough to actually get deployed in the near future
by KDE, Gnome, and Linux distributions, and used by ISVs this year.
(See Waldo Bastian's post.)

The second issue covered by this breakout meeting that ISVs can't
currently create a single binary and expect it to work on all versions
of Linux. This is currently hard because of ABI breakage, i.e.
incompatible system libraries, between different Linux distributions
and between different versions of the same Linux distribution.

Preventing ABI breakage, and making it possible for ISVs to
"write once and run everywhere", is exactly the goal of the LSB.
The ISVs are still skeptical about the LSB because of its limited
scope. Presumably the skepticism will abate once the LSB Desktop
effort bears some fruit.

The LSB verifies that Linux distributions are free of ABI
breakage by running an LSB compliance test before each
release of each distribution. This is fairly late in the game;
projects like Gnome, KDE, and freedesktop.org can and should do
their own ABI stability testing before their own releases.
(They should also take library versioning seriously; see
the recent problems with fontconfig.)

One ISV said that he needs a way to target older distributions.
Autopackage was brought up as a possible solution. The ISV said he
wanted something lighter weight that did not address packaging -- he
wants to continue using his existing packaging techniques, and only
wants something to make e.g. LD_LIBRARY_PATH and LD_PRELOAD tricks easier.
The meeting adjourned without reaching a conclusion on this issue.

A few post-meeting notes on ABI stability:

Gnome seems to have had lots of attention to ABI
stability; see posts from
2003,
2004, and
2005

[ None of KDE/Qt, GNOME/GTK+, nor wxWidgets mets all these requirements. ]
Right now we use, develop, and host FLTK,
which offers all of these things (#5 is part of 2.0...) so that we can write
our UI code once and distribute on multiple platforms.

Followon meetings on topics like wireless, printing, X, power management,
and LSB/ISV issues are being considered. I'll have more info later.
Last update 15 Dec 2005
Send comments and corrections to Dan Kegel (dank at kegel.com)