Thoughts and a possible plan

Hi,

So. I've been talking with Daniel lately about the platform idea, and he
asked me to do a brain dump to this list. Digest inwardly and enjoy :)
All this is here simply to stimulate debate, flame me if you want.

My vision for a desktop-neutral platform is not much like Daniels.
Daniel, in particular, sees certain issues as being "blockers" that I do
not. More on that later.

Firstly a disclaimer. My interest in the FDO platform concept is purely
related to two things, neither of which you may consider worthy goals:

1) Making installation of 3rd party distro-neutral binary packages more
reliable.
2) Lowering the barrier to entry for proprietary/commercial software on
Linux.

These reasons aren't hard to understand - one of the things that makes
software installation unreliable on Linux today is the sheer number of
dependencies applications have. It's usually possible to resolve some of
these either manually or via a program like apt, but the more you have
the greater the chance of a failed resolution. Consolidating common
dependencies into a single one (a platform) is therefore an interesting
thing to do.

(2) is related to (1) of course - proprietary software cannot simply be
recompiled for the target platform by the user, and the more
dependencies you have the fewer customers you have. That's not
acceptable for proprietary software vendors, and if we want Linux to be
a credible corporate desktop that must be solved.

There are other good reasons for having a platform, but I think those
are the main ones.

So what do I think the platform should be then, in order to meet these
goals?

A) It should be a collection of libraries which meet platform policy
B) It should use time-based releases
C) It should *not* try and do an LSB and specify the
behaviours/APIs/ABIs of the components in DocBook SGML.
D) It should provide an easy way for users to get the platform on their
system and then update to the latest versions, even on older distros.
E) It should have one or at most two maintainers who's word on what goes
in and stays out is final, for sanity's sake. Maintainers can override
policy if a good enough precedent is given.
F) It should be libtool-style versioned. IE the platform is "1.0", then
"1.1" which means all software in the platform is backwards compatible,
then one day it breaks backwards compat (but remains parallel
installable) and becomes platform 2.0

D is clearly something best done by volunteers by preparing apt/yum
repositories, maintaining the (virtual) packages in their distros
archives and so on. The idea is to be able to do "apt-get install
platform-1.2" and have all the necessary libraries installed and
upgraded even on non-current distros.

A is the most important goal. A platform is only useful if it's coherent
in some way. Why is this? Why not just lump together things we find on
freshmeat that might conceivable be useful? Let's take a look at some
basic policy that might be used and see what the justifications are.

Example policies
================

WHAT: Software in the platform should do a major release at max 1 month
prior to the release of the platform OR Software in the platform should
synchronize release cycles with the platform.

WHY: The primary aim of the platform is to reduce dependencies. If
software does not sync its release cycles with the platform, it's
possible a sparkly new version of FooLib will come out a week after the
platform is finalised. Software using FooLib will then depend on not
just the platform but also the newest version of FooLib because the
users want the new features it makes available. We failed to meet our
goal of minimizing discrete dependencies. 

EXTRA: That doesn't mean of course you can't do other releases. Do as
many as you like! But, the maintainer should look dimly on projects that
do major releases shortly after the platform revved.



WHAT: Software in the platform should not break interface stability
until the platform as a whole does.

WHY: Breaking interface stability is bad, as it means extra bloat on the
users system. ELF DSOs, the most common form of reusable library, are
versioned at the file level unless you use GNU ELF extensions. An
interface break implies duplicating the entire library both on disk and
in memory. Too much of this can kill performance. Note the word
interface and not ABI - it's possible things like python/perl modules
would be included. "Interface" also encompasses more than just ABI - for
instance API semantics are included in the concept of interface.

EXTRA: Breaking interface stability wouldn't necessarily mean being
kicked out of the platform - by definition you can't do that otherwise
the platform broke backwards compatibility anyway. If a strong enough
case was made the efficiency hit could be swallowed: no policy is
binding. However, projects that did this repeatedly and showed no regard
for interface stability should be frozen and then kicked out at the next
major-version rev of the platform.


WHAT: Software in the platform should be parallel installable.

WHY: One day, perhaps even with planned regularity, the platform will
break backwards compatibility. When this happens it must be possible for
users to still run software dependant on the old version, and that means
it must be possible for all software within the platform to be parallel
installable.

EXTRA: this technique is new but trivial, see
http://ometer.com/parallel.html for details



WHAT: Software in the platform should be LGPL or X11 licensed (or
equivalents)

WHY: Usage of the platform should not attempt to enforce particular
licensing on the users. This is especially important for achieving the
second stated goal, which is to make Linux more hospitable for
proprietary software. That means GPLd libs are not acceptable.

EXTRA: As with all platform policy the maintainers word is final and
exceptions are allowed if deemed useful. For instance, it may be decided
that allowing Qt is acceptable because of the dual license.



Things the platform would not do:

* Dictate project quality standards. For instance policy on
documentation level, code/API style, implementation language etc is
right out. If people feel that some aspect of a project disqualifies it
from platform acceptance that should just be thrashed out on the list
with the maintainer(s) making the final decision.

* Prevent projects doing certain things. For instance, projects can
still do (or not do) releases outside of the platform schedule if they
want, as long as those releases are not incompatible with policy. If
such releases are incompatible then the only forfeit is inclusion of the
release into the next platform version.

* Force releases for each revision. If a project isn't ready to release
in the platform timeframe, no problem, just wait for the next one.

Other random things - you may have noticed I use the name Linux
liberally throughout this email. Given that all other forms of UNIX have
single, centralised dependency archives and little to no third party
packaging activity, I don't think it'd be useful for say FreeBSD or AIX.
Win32 portability is not an interesting goal at this time.

I think a good starting point would be the following:

* Inclusion of a very small set of libs. Basically what you need to do a
basic desktop app and no more. Other software can be added later once
they have brought themselves into line with project policy. My hotlist
would be:
 	* GTK+
	* Some version of xlibs
	* glibc 2.2.x
		[ features new in mainline glibc 2.3 are not interesting
		  for desktop apps, and the new threading models are not
		  universally available on all distros yet ]
	* C++ support <- there are *still* gcc ABI breaks going on but
	  fortunately only at the edges, we could prolly afford to
	  ignore them

It's almost certainly missing crucial things I forgot about.

Yes, Qt is not there. One widget toolkit is enough to start with. Qt
could be brought in later, if compatible with platform policy and the
maintainers.

DBUS is not there. This is a key point of disagreement between me and
Daniel. I don't see DBUS as being critical for building desktop apps.
While I agree it should probably find its way in there eventually I
think it should be treated the same as any other piece of software - if
the maintainer is willing to work and a good case is made, it should be
included.

KDE and Gnome libraries would typically not be included. There seems
little point - KDE and Gnome are already platforms, if a project wishes
to depend on them then great. For whatever reasons (politics,
portability, dependency sizes, history) there is a great deal of
software out there which is not KDE nor Gnome. These are the programs at
which an FDO platform could/should target.

There is a question of whether the GTK+ maintainers would be willing to
submit the project to platform policy, in particular the release cycle
commitments could be problematic. 

However, I can't see a way to have a useful platform without some
guarantee that the software in it won't be obsoleted a week after the
platform is finalised and that in turn requires release cycle
commitments. The maintainer of GTK+ is a pretty level-headed and
reasonable guy: IMHO if we can't convince Owen that the cost:benefit
ratio is compelling then we don't stand much chance with other
maintainers and we'd need to go back to the drawing board. 

Additionally it's hard to have a desktop app with no widget toolkit and
GTK+ fits the licensing/wide-usage criteria well.

Schedule - has to start somewhere. The most easily identifiable natural
"rhythm" currently is GNOME/Fedora, which are on a 6 month schedule
which is closely linked. That's not really any bias towards
gnome/fedora, it simply makes most sense to start there and adjust if
necessary. 

In particular Fedora is a big distribution with many users - having the
latest version of the platform finalise early enough for it to get into
the next Fedora release would be a good start on the road to usefulness.

That doesn't mean member projects have to adopt 6 month release cycles
of course. As long as they do a major release roughly on some multiple
of 6 months (or are extremely stable like ncurses or glibc) then the
policy goals are met and there's no problem. 

I think 6 months is the max a platform could get away with currently.
Desktop Linux is simply moving too fast to use a longer schedule. People
would end up depending on platform + 12 other things.

The long term goal of the platform would be to slow down the rev rate to
something more similar to the competition (win32, .net, macos) which
frequently go *years* between releases.

OK, it's now midnight and I need sleep. Hopefully that was coherent
enough to get people thinking if not discussing. It's all just hot air
at the moment - remember that. Comments welcome.

thanks -mike