Subject: Re: Pitching a "Big Tent" for Open Source
From: Ian Lance Taylor <>
Date: 14 Dec 1999 10:40:29 -0500

   Date: Mon, 13 Dec 1999 22:14:48 -0800
   From: Rich Morin <>

      *  The open source matrix

	 The open source matrix is a three-dimensional space, defined by
	 the architectures, operating systems, and packages that we wish
	 to support.  No single part of the Open Source community deals
	 with this matrix as a whole, but each part must contend with a
	 "view" of it.

In some sense standardization is designed to permit the matrix to be
viewed in a simpler fashion.  Standardization of the OS interface
permits dealing with all operating systems as one.

Careful coding permits dealing with all architectures as one.

There is currently no way to deal with all packaging systems as one.

This matters because there needs to be one central set of sources for
any given package (or, at least, a very small number).  Otherwise
rippling changes from one set of sources to another becomes too

A matrix can serve a real purpose by providing a set of testing
platforms (you mentioned this at the end of your note).  However,
beyond that, I would prefer to think in terms of eliminating the
matrix in software development, rather than somehow exploiting it.

I'm glossing over how hard it is to spread across multiple OSs and
multiple architectures.  My point is more that the goal should be to
spread across them.  This may be what you are saying too.  I'm not

	 For instance, aggregators such as Red Hat are only concerned
	 with packages that run on RH Linux on their supported hardware
	 platforms.  The Apache folks must, in contrast, deal with many
	 hardware platforms and OS variants, but only one package.

Note that Cygnus, for example, is concerned with yet another matrix
dimension: target platforms (i.e., particular embedded targets).
Cygnus has a range of hosts and a range of targets.

	 What we'd really like to see is Apache-level infrastructure for
	 each package (CVS repositories, web pages, email lists, news-
	 groups, etc.) and FreeBSD-level (
	 or, for that matter,
	 porting and packaging automation for the matrix as a whole.

As far as infrastructure goes, see  I
haven't used it myself, but it sure looks nice.

	 While we're off doing the easy stuff, we can try to cajole
	 the assorted packaging and porting experts to pool their
	 efforts a little; it's really a little bit silly to have so
	 many incompatible distribution and packaging systems and the
	 wasted effort in maintaining multiple sets of metadata is
	 really a bit staggering, at least to me...

My impression is that porting experts have by and large pooled their
efforts.  Most people use autoconf/automake/libtool.  Certainly a few
packages use Metaconfig, a couple use imake, and a number of packages
use homegrown techniques, but I think autoconf/automake/libtool
clearly have the numbers for packages which are portable across
multiple operating systems.

Now, autoconf/automake/libtool have a lot of problems.  I happen to
think that they are better than any current alternative, but I also
think they could be improved a great deal.  I think people who care
about these issues should focus on what we've learned from the current
generation of tools (including Metaconfig, imake, etc.) and see what
can be done to produce wholly new tools which are much simpler to use.

Packaging, on the other hand, is wide open.  Perhaps eventually people
will settle on one packaging system.  My recollection is that RPM
technology spread pretty quickly once it was available.

The difficulty I see is that packaging tends to take over your whole
system.  That makes it hard to switch from one packaging system to
another.  Also, the existing packaging systems tend to be somewhat OS
specific (as far as I know--please correct me if I'm wrong).  Also,
the existing packaging systems have somewhat different goals.

So there is certainly work to be done here, but I'm not sure how it
should start.