Subject: Re: improving project maintainership
From: "Forrest J. Cavalier III" <mibsoft@mibsoftware.com>
Date: Fri, 8 Feb 2002 15:15:52 -0500 (EST)

> 
> 
>        Forrest:
> 
>        Why does it make sense to centralize the burden of coordination (at the
>        maintainer) away from the divergent developer?  Or put another way,
>        how is the maintainer eventually rewarded for the boost they give to
>        the divergent developer?
> 
> FSBs and semi-FSBs already recognize the value of that coordination.
> See, for example, Bob Young's recent interview (you can find a link to
> it through /.) or IBMs admirable forays into project maintainership
> and sibling project participation (e.g. ICU and the i18n of various
> core GNU/X11/Linux utilities).

I see that response as an attempt to use the long-range business
cases for open source to justify the overhead of the arch central maintainer
that you propose.

I want to be clear that the motivations for a FSB to use, develop,
coordinate, and contribute to open source are distinct from the extra 
work (paid using the arch "tax") which you are proposing to make it
easier to _diverge_.  The benefits of open source are more than the 
ability to diverge to take advantage of additional opportunites.  
Since there are other benefits, one cannot simply equate making it
easier to diverge with participating in open source.

----------------------------------------------------------------------

You have a tough sell.  You either have to show that there is no 
serious penalty for divergence when you use arch.... (I'll point out
that the penalties for divergence are well known, and are not limited
to the problems of duplicated work and inefficiency that arch intends
to solve.)  ...Or that the payoff for being a centralized arch 
coordinator promoting divergence overcomes the penalties of 
divergence.  (That would have to mean better payoffs than 
currently received by any FSB.)

I recognize that divergence is great and arch is a very nice tool,
if you have three things:
      - perfect (i.e. defect free) software, 
      - infinite market and talent,
  and - totally friction-free economy (i.e. instant awareness of all needs
      and solutions in the marketplace)

But software business (FSB's too) have to deal with a reality
which is the opposite.  (And that makes the divergence you propose 
with arch _VERY_ bad most of the time.)  These realities are 
   1. quality assurance, 
   2. finite market and talent, 
   3. and "trust" in the customer relations management sense.

1. The combinatorial explosion problem makes quality assurance
a nightmare in multiple-configuration products.  Divergence
comes with very high added QA cost.  I would estimate so high that
before anyone tries arch, they had better make the case that
the overhead is an investment which is covered by a future return.  (If
you respond to any point in this message, answer this one,
or show me what I missed in arch.  When I read about arch, it didn't seem
to solve any of the hard testing problems created by divergence. And
in recent Software Engineering literature that I am aware of, that
problem is very much still with us.  But I could not be well-read enough.)

2. Finite market and talent means that you must use common denominator products
so that customers buy from you instead of competitors. You do NOT want
to help competitors create new configurations if there is any chance
at all that those customers can be yours. (Also, marketing requires
require having specified products to offer for sale, as opposed to 
infinitely variable ones, but that is not a major issue here.)

3. "trust" means that customers will establish relationships with
a finite number of suppliers.  This is the point of RMS's email that 
you CC'ed to the list.  Promoting "trust" isn't just businesses trying to 
protect territory and wall off their customers from competitors.
It isn't just FUD.  Customers really do want to be able to get the
"official" GNU version, instead of having to select from a menu of
configurations which are likely to be untested as a whole, and often
incompatible.  (I suppose I could rephrase this point in terms of
transaction costs.  Stephen Turnbull would be better at it than I,
so I won't try.)

----------------------------------------------------------------
I am not arguing that arch is a utopian solution.  I am just trying
to better characterize _when_ it is the right solution, i.e. when
it overcomes the negatives I just outlined.  So far, I'm reading is
that arch is the "greatest thing since sliced bread", and should be
used for all projects.  Please correct that misperception.

You must have already thought about your market before you decided
that arch has commercial funding potential.  Can you please
outline who your market is?