Subject: Re: funding indirect services
From: Rich Morin <rdm@cfcl.com>
Date: Sun, 30 Jul 2000 17:40:12 -0700

Crispin Cowan wants a "short, pithy paragraph describing the proposed
work that makes it blindingly obvious why one would want such a widget,
and if it's an infrastructure thing, how we might get there without
breaking the world".

I don't feel capable of all that, but how about this:

   Meta is a unified interface for system information, where both "system"
   and "information" are interpreted very broadly.  It maps documentation,
   system state, and other useful information into a single "name space",
   easing the creation of powerful support tools (e.g., system browsers
   and administrative tools).  Initial versions of Meta will concentrate
   on package management metadata and assorted documentation resources.

I second Stephen Turnbull's comments:

   You're taking history too seriously.  If ESR is right, then big
   corporations will do it on purpose and systematically, ...

I think that most Open Source companies are investing significant funds
in development activities.  In fact, Open Source companies may be more
strongly motivated to fund development (including both maintenance and
research) than they would be as proprietary companies.  After all, Open
Source users are a very demanding (and fickle) lot...

As a case in point, I am contracting for OpenSales, which is developing
a Perl-based e-commerce solution ("AllCommerce").  They are paying me
for specific development services which they feel will benefit them.

If they became convinced that Meta was an appropriate technology for
them to adopt, they could opt to pay me to help them with that effort.
They might also, in order to increase the value of their Meta efforts,
help to support (e.g., "sponsor") generalized development on Meta.

A direct contracting relationship (as we currently have) would serve
for the first case, as would the collab.net style of association.  The
second case, however, needs a bit more "decoupling" between the sponsor
and the developers.  Specifically, if a development effort is too tied
to the specific needs of a given client, it may well fail to meet more
general objectives.

A similar argument to this was made by RMS back in the early days of
Cygnus Support.  How, he asked, would the development of GCC be biased
by the fact that it was being done to meet specific client's needs?  I
don't want to get lost in the specifics of this instance, but I believe
his concern was legitimate.

Brian Behlendorf's point is also well taken:

   ... sometimes there are tasks that "need doing" on an open source
   project that are either too complex or too boring or too large for
   the available volunteer resources at the time ...

I would contend that Prime Time Freeware's work in selecting, organizing,
and annotating substantial amounts of free software met all three of his
criteria.  At the time, nobody else wanted to spend the time and effort
to do this work, but customers were willing to pay for the results.  The
current "OS integrators" (e.g., Red Hat) fill a similar niche, today.

If tasks are diffuse in nature, the collab.net approach may be a bit too
specific to work well.  Sometimes you just want to hire folks whom you
trust to "do the right thing" and then set them free to work.  If they
seem to be getting bogged down, you can always stop funding them, but
the freedom to experiment is critically necessary to doing research.

Well, that should stir the pot a bit 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