Subject: Re: anti/Law (an attempted explaination)...
From: "Stephen J. Turnbull" <>
Date: Thu, 15 Apr 1999 12:00:51 +0900 (JST)

>>>>> "rn" == Russell Nelson <> writes:

    >> We _may_ be able to test proposals, too, in laboratory
    >> experiments.  I'm not real sure about that, though, because in
    >> my current (half-baked) model of the free[1] software
    >> phenomenon the important tension is between developer
    >> preference for free software and profit from proprietary/secret
    >> software.

    rn> Are you talking about a developer preference to create free
    rn> software, or to take advantage of free software?

Here I am talking about the former.  The latter is easily enough
captured (for the purpose of economics) in the cost function.

One of the potential advantages that I see to open source is that the
user/developer distinction is no longer a dichotomy.  A lot of users
with access to the source _contributing_ tiny features, one-line
bugfixes, and even just a little effort to localize a bug can (in
theory) add up to a lot of "core developer" time freed for core
development.  (I'm ignoring the quality-control problem here, which
could be very costly in core developer time.)

COSS might be a way to induce them to put in that effort.  But it
might not be necessary, or even be a counter-incentive for some
personality types.  I'm interested in trying to parametrize and
measure the amount of such _contribution_ (ie, without COSS) that
might take place, and which types of project would tend to attract
it.  We know that many projects do benefit from such.

    rn> If you view support as insurance, then a proprietary support
    rn> model (which comes with proprietary software) creates a larger
    rn> base of rate-payers, and turns support into a cost center to
    rn> be minimized.  This addresses Keith Bostic's classic concern
    rn> that paying for free software by selling support creates an
    rn> incentive for buggy software and inadequate documentation.
    rn> Presumably a free market incents manufacturers to reduce the
    rn> need for support rather than reducing the available support.

Not necessarily.  Note that buggy software has high TCO, especially
consequential expenses, which neither the FSB nor the
proprietary-source firm will reimburse.  If consumers desire
bug-freeness enough, probably you could set the cost parameters
appropriately and generate a model where the support-oriented FSB
needs more users (since only a fraction of them become customers), and
thus more bug-freeness, than the direct-revenue-oriented firm.
Obviously "support" here would have to be "everything but fixing bugs"
in terms of revenue generation.  I suspect the parameters would have
to be pretty extreme; this is probably a rather perverse case.

Two random thoughts: "bugginess" of course is dimension which firms
have long used for "versioning": military-spec hardware is more
expensive than commercial grade, right?  I assume the same is true of
software.  But the support-oriented FSB can't do this.  By definition;
of course an FSB could release "beta-quality" on the Web and demand
payment for the fully-tested and verified version, but that's a
different model of FSB.

With respect to that model, on the "technology of development" side,
Watts Humphreys (for one) argues that developers who inject few
defects are developers who release high-quality software, and that the
inverse is also true.  So testing is an inadequate means to
high-quality software.  To the extent that that is true, a firm which
_sells_ "seven-sigma" versions is likely to be releasing "six-sigma"
betas.  So it may be hard to "version" on defect rates.  (Except by
deliberately injecting bugs; I think releasing crippleware is a far
safer and more controllable strategy for versioning on quality.)

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 two straight lines for?  "Free software rules."