Subject: Re: funding indirect services
From: "Stephen J. Turnbull" <>
Date: Tue, 1 Aug 2000 16:34:44 +0900 (JST)

>>>>> "kms" == Karsten M Self <> writes:

    kms> I'll comment on this and add my own bias to the discussion.
    kms> Not that I think this is the proper forum for discussing
    kms> Meta, but Rich hasn't (AFAICT) specified another.  How about
    kms> a SourceForge project?

I think this discussion should take place elsewhere.  I would like to
know where it goes, but I don't think here is a good place..

    kms> At the ORA PC4/OSSC Meta BoF, we spelled out a few issues of
    kms> what Meta might be,

Do _you_ have a better blurb?

    kms> Does this gel with others' perceptions of Rich's proposal or
    kms> am I out in left field as usual?

I'm intentionally _not_ reading Rich's detailed proposal, and won't,
because I'm _more_ interested in the current discussion.  That is, how
to create and communicate business models and (related but not too
closely) business objectives.  I don't want my objectivity polluted by
knowing too much.  Changing that order of priority might be a good
test of the "blurb".  :-)

What I gathered from Rich's blurb is that he's not happy with current
PMSes and other admin tools because

    (1) it's hard to find the interface that does what you want in any
        of them, and
    (2) knowledge about any one doesn't much help with the others.

Meta is supposed to resolve this by providing a front end to give a
common interface to administrative (configuration) data, tools, and

One thing that is missing is *how*.  We know how to implement designs;
that's why so many of Ben Tilly's objectives were "project references"
as Crispin put it.  Once we have a design, it's a "mere" matter of
finding resources to implement it.  At this point, meta suffers from
the fatal flaw (in terms of attracting paying customers) that it's
implausible due to lack of "how".  It's basic research; you could get
a foundation to fund it, but not customers.  (IMHO, of course.)

Karsten's proposal to implement as a VFS doesn't help me much.  That
doesn't deal with how the data bases are going to be gathered, where
they're going to live, and so on.  (See the discussion of the design
of Autoconf in its Info manual for an example of the kinds of issues
that just aren't addressed by either Rich's blurb or your proposal.)

Aside: I don't think that these things are as hierarchical as you
seem to think.  Eg, in /proc many entries are replicated with
different functions:


and in package management, there are at least two kinds of hierarchies
in common use:  priority (essential, standard, ...) and function
(text, graphic, net, ...).  Debian adds a trivial license hierarchy
(free, contrib, non-free).  The Unix file system hierarchy has been an
excellent model to date, but requires a lot of discipline (eg, the
FHS) to use effectively.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."