Subject: Re: street performer protocol
From: "Stephen J. Turnbull" <>
Date: Tue, 23 May 2000 10:49:28 +0900 (JST)

>>>>> "Crispin" == Crispin Cowan <> writes:

    >> My point is that it is not possible to avoid lock-in; you just
    >> have a choice of what kind of lock-in you wish to accept.

    Crispin> I disagree with this fundamental premise.  It is possible
    Crispin> to avoid lock-in if you deal with an FSB.  You are still
    Crispin> locked into a *class* of products, but they are no longer
    Crispin> single-source.

Yeah, so?

Reductio ad absurdem:  don't buy it, build it.  Now you're no longer
locked in to the FSBdotcommers either.

I don't deny that competition will reduce unit costs and make it
easier to switch to other firms' versions of the same product.  But
the switching costs of changing technology do not decrease.  Single-
source has nothing to do (by definition) with lock-in, which is about
switching costs from changing products.  Single-source is just
monopoly; monopoly is, of course, facilitated by lock-in, but monopoly
does _not_ create lock-in.

However, the competition that results from multi-sourcing necessarily
reduces the surplus available for future development of that product
(compared to a monopoly), and thus greatly increases technology risk
that some other product will turn out to be better.  The point is that
switching among suppliers of essentially identical products is _not_
the kind of switch that software-related managers generally worry
about---they face much bigger costs in any upgrade to the same firm's
next version.  Rather, the big worry is "how soon will I need to
switch to an alternative technology?"

So the choice we are discussing is to be greedy and take the _current_
cost reductions definitely available from the low-price open source
product, or to be patient and accept the risk inherent in betting that
proprietary product will develop at least as fast, and fast enough so
that the product improvement outweighs the monopoly price.  But that
seems rather plausible given the greater resources proprietary firms
can devote to development.

"But open source development is cheaper!" you cry.  Which brings us
back to the assertion that open source in the long run can develop
better products with _much_ less financing.

How?  Why aren't those techniques available to proprietary firms?

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