Subject: Re: Open letter to those who believe in a right to free software
From: "Stephen J. Turnbull" <>
Date: Tue, 26 Oct 1999 04:31:45 +0900 (JST)

>>>>> "Ben" == Ben Tilly <> writes:

    Ben> And their success in modelling is measured by...other
    Ben> economists.

Yup.  I'm not happy about that, but ... intermediate micro is _not_ a
popular course among those who don't plan to become economists.

    Ben> OK, cheap shot.  But still.  You have made many comments that
    Ben> indicate that you are coming to the subject with similar
    Ben> unexamined biases to what people in software started with.
    Ben> Those biases have proven to be incorrect.  Why, then, do you
    Ben> dismiss those informed conclusions?

Because I don't dismiss the informed conclusions and my biases aren't
unexamined.  They are undoubtedly biases, but they're the best I can
do until the real analysis comes along.

    Ben> It is the considered opinion of many experts in software
    Ben> development,

    >> Etc, etc.

    Ben> ie You know better.

Not at all.  Most lists I'm on, it's not considered polite to quote
slabs of text that are not relevant to the discussion.  I simply don't
contest any of the facts that you presented.  The facts are relevant,
but quoting them is not.

    Ben> The usual assumptions appear to be somewhat distorted by the
    Ben> fact that:

Please, you obviously don't know what "the usual assumptions" are.

The characteristics you mention are important, and I'm happy to resond
to them.  But "the usual assumptions" are rather weak; talking about
them being "distorted" is not very useful.  For technical simplicity,
something like monotonicity and continuity of the costs functions for
distributing software, monotonicity, continuity, and convexity of the
cost function for developing software, and downward-sloping and
continuous demand functions for the various products is useful.
"Something like" because the exact assumptions needed are going to
depend on the exact specification of the model.

So the results I'm talking about are on the order of generality of
"the minimum of a strictly convex function on a convex region is

Lock-in may or may not cause problems with the demand functions.  This
will depend on exactly how lock-in is specified in the demand
functions.  But not all software creates lock-in problems.

    Ben>  - Vendor lock-in means that each software product is to some
    Ben> extent a natural monopoly (lawyers originally were encouraged

No.  This is a misuse of the term "natural monopoly."

In fact, it's a misuse of the term "monopoly".  A market which is ex
ante perfectly competitive can still have technical characteristics
which result in full lock-in.  In this case, the buyer can force the
seller to absorb all of the costs of lock-in, except for any
transactions costs due to playing one seller off against another.

    Ben> to put Word Perfect to full use, they are still locked into
    Ben> it despite years of pressure from clients to switch - other
    Ben> examples exist if you are interested)

Lock-in effects can be analyzed separately from the production side.
They're well understood, have been since at latest the late 70s.

Network externalities have only been carefully studied since the early 
90s.  I don't know whether they are more important than lock-in as

I don't see how either makes the software market unique.  They do
imply a first-mover advantage.  From a strategic point of view the
individual product market is "tippy" (rivalry generally ends with one
firm winning a monopoly position, not in a stable duopoly or
oligopoly).  But this is more or less true of any natural monopoly
(defined as a firm whose production technology exhibits global
increasing returns to scale).

    Ben>  - The bulk of development costs lies in testing and
    Ben> debugging, both of which are readily distributed

Ie, their costs are convex, in fact linear, in "size," if I understand
what you mean by distributed.  Except that I don't think it's so easy
to "distribute" testing of a complex system.  Unit test, yes; system
test, no.  That makes development costs convex, ie, marginal costs
increase with system size.  This is the main thing I need; it
basically implies that there are going to be a lot of developers out
there, because the world is not going to merge into a single enormous
"do everything" program (notwithstanding Microsoft's attempt to
integrate the operating system into the browser---or was that vice
versa?---there's still that 95% of software developed for internal use 

    Ben>  - Software quality is frequently a market externality,

I don't know what you mean by "market externality."  Please define it.

    Ben> indeed the developer *benefits* from a certain level of bugs
    Ben> - it gives consumers reasons to upgrade!

Urban legend, IMO.  Optimizing the level of bugs is going to be
expensive; I can't imagine it would be done.  "Planned obsolescence"
has been around for a long time.  There are few documented cases.  If
consumers get the idea this is taking place, they get very angry (as
they do when locked in).  Unless the consumer is also locked in, this
is not very conducive to the health of your future income statement.

Most economists tend to interpret what looks like "planned
obsolescence" as "developer incompetence."  It's much better to get
the customer locked in to features that work, rather than give them
excuses to switch.  I don't say planned obsolescence doesn't happen,
but without quantitative evidence I would think it's unusual in any

Quantitative studies of the automobile industry and the consumer
electronics industry suggested that in those industries what was called
"planned obsolescence" by consumer advocates was due to "preference
for variety" (make that "sucked in by fads" if you like) in part, and
to long lags between developing the "state of the art" and when it
made it to market.

This is not to say that there isn't a tradeoff between quality and
cost; there is, and as users become well-informed about TCO it may
very well behoove the company to raise price for the product in return
for higher quality and lower aftermarket service costs to the users.
However, there's no need to attribute to vendor malice what can be
fully explained by customer ignorance.

    Ben>  - A significant portion of the value to a consumer lies not
    Ben> in the product, but in guarantees of future support and
    Ben> development

>From the economic standpoint this is just a component of lock-in, I

    Ben>  - The incremental cost of distribution is approximately zero

The size of this cost is irrelevant as long it's constant.  (To the
qualitative results.)

    Ben> Please don't just wave a hand and say that you are an expert
    Ben> economist while I am not.  If you are aware of another
    Ben> product with even half of these characteristics, please tell
    Ben> us.

Not my job.  That's like if I asked you for an estimate on a program
which requires a one-line Emacs-keystroke using editing buffer, the
ability to fetch URLs, and the ability to produce postscript output,
and then told you I wouldn't believe you until you produced an example
of a similar program.

    Ben> And also please explain why these factors are irrelevant.

That's your problem, I didn't say they were.  If you think they are,
be my guest and explain.

    Ben> Please explain for each of the above properties why it does
    Ben> not violate "the usual assumptions"...

Your wish is my command.

    Ben> A basic research question that I recommend to you.  To what
    Ben> extent is a proprietary program a natural monopoly?  In

100%.  Fixed cost is positive, marginal cost is low and as near
constant as anything ever could be.  This applies to ALL software.
You never took an intermediate microeconomics course, I take it.

    Ben> particular what are the real and perceived barriers in the
    Ben> market to switching products?

I don't care.  To an economist, perceived barriers are real barriers,
and vice versa.  A real barrier which isn't perceived has a tendency
to supply the dreamer with a rude awakening.  Perceived barriers
which aren't real have a habit of evaporating, to the great profit of
the lucky sleeper who wakes first.  No guarantees, but close enough
for government work.

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