Subject: Pitching a "Big Tent" for Open Source
From: Rich Morin <rdm@cfcl.com>
Date: Mon, 13 Dec 1999 22:14:48 -0800

Over the years, I have written articles, moderated panels, and generally
made a nuisance of myself pitching my "Big Tent" view of the Open Source
community.  Basically, the notion is that we are a community, with more
than a few common interests, and we should start to act that way.  One
of my more recent articles on this topic can be found, FWIW, at:

  "Wanted: Centralized open source support"
  http://www.sunworld.com/sunworldonline/swol-10-1999/swol-10-silicon.html

I am writing now in an attempt to engage some portion of the FSB list in
a discussion of these ideas, with two aims in mind:

   *  I would like to explore the range of infrastructure that the Open
      Source community could benefit from having, what parts of it can
      be done for profit, and what parts cannot.  I have some opinions
      about this, which I will share; I hope (and expect :-) that some
      folks here will lend some opinions of their own.

   *  My secondary aim, baldly stated, is to find a way to get funding
      to create the "unprofitable" and "uninteresting" parts of the
      needed (or at least desirable :-) infrastructure.  After all, if
      the Open Source community is coining money, shouldn't some of it
      be available for these sorts of long term efforts?

So, here are some partly-baked ideas, to start things off.  Have fun!

   *  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.

      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.

      Assume, for purposes of discussion, that there are five hardware
      architectures and 10 Unixish operating system families that the
      Open Source community wishes to support.  This gives us a matrix
      of 50 architecture/OS combinations, containing perhaps 25 worth-
      while porting targets.  Actually, the porting matrix is larger
      than this (e.g., both *BSD and Linux have several variants).

      Multiply the 25 "worthwhile ports" by the 10,000 packages listed
      in FileWatcher (http://filewatcher.org/).  This gives us 250,000
      "interesting" nodes.  Indexing and some degree of annotation are
      being supplied by Debian, FreeBSD, FileWatcher, and others, but
      that's only a patch on the total problem.

      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 (http://www.freebsd.org/ports
      or, for that matter, http://www.debian.org/distrib/packages)
      porting and packaging automation for the matrix as a whole.

      Some of this, of course, is subject to the usual sorts of NIH-
      based debates (RPM rulez!), but other parts (e.g., automated
      provision of reliable hosting for FTP, WWW, mailing lists and
      such for any "legitimate" Open Source effort should be pretty
      easy to provide.

      We know how to set up this kind of infrastructure; in fact,
      we've done it hundreds of times!  Now, let's do it in a way
      that allows every Open Source project to have access to it,
      without the need for each developer to "learn the ropes" of
      a dozen different technologies (e.g., Apache, Majordomo, ...)

      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...

   *  The Distributed Porting Laboratory

      Assuming that I'm willing to "scratch someone else's itch", I
      might be willing to spend some time updating the port for the
      wombat package on the Linux/PowerPC platform.  Unfortunately,
      I may not have one of those around.  Why isn't there an easy
      way for me to gain access to such a platform for the evening?

      All this would take is:

      -  provision by vendors of "current" platforms

      -  a reliable (e.g., reputation-based) way to qualify trusted
         developers

      Everything else (e.g., ssh and the Internet itself) is already
      in place.  This should be a no-brainer!  So, why is it that it
      hasn't been set up?  (Hint: who sees it as "their" problem?)

Those two are probably enough to get some discussion started.  If
folks seem interested, I have more (:-).

-r

--
Rich Morin:          rdm@cfcl.com, +1 650-873-7841, http://www.ptf.com/~rdm
Prime Time Freeware: info@ptf.com, +1 408-433-9662, http://www.ptf.com
MacPerl: http://www.macperl.com,       http://www.ptf.com/ptf/products/MPPE
MkLinux: http://www.mklinux.apple.com, http://www.ptf.com/ptf/products/MKLP