Subject: Re: Open letter to those who believe in a right to free software
From: "Stephen J. Turnbull" <>
Date: Wed, 27 Oct 1999 18:52:42 +0900 (JST)

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

    Ben> I can argue against every one of [the usual assumptions]
    Ben> except the continuity, and in the real world the difference
    Ben> between a nasty continuous function and a discontinuous one
    Ben> is not worth arguing about.  Besides which, at heart I am a
    Ben> constructivist and so I am at least somewhat dubious about
    Ben> the existence of non-continuous functions! :-)


    Ben> And what grounds can I ague against them?

    Ben> The cost of distributing free software realistically is
    Ben> largely the cost of getting people to be aware of and trained
    Ben> in it.  As a piece of software reaches wider distribution it
    Ben> becomes easier to tell people about it, and easier for them
    Ben> to learn it.

Network externalities on the consumer side.  I disagree about the
empirical significance of these externalities; I think they're
small compared to the personal cost of learning for most people.

But I will keep the point in mind.  I suspect you are right that if
moderately strong it could affect the conclusion.

    Ben> The cost function for developing software is complex.  Sure,
    Ben> as you get more interfaces you get increasing costs.  (As
    Ben> Brooks points out.)  However real projects periodically
    Ben> recognize their internal problems and go through internal
    Ben> clean-up.  Plus most significant projects eventually develop
    Ben> reasonable interfaces through which additional functionality
    Ben> can be added in a pretty good way.  When that happens the
    Ben> development cost does the unexpected and drops.

This is a good point.  However, it is not clear to me that it is
relevant to economics.  I think that for economic purposes Perl 5 is
_not_ a bigger Perl 4.  It is a new product.  I think that this model, 
although unnatural for the developers themselves, is accurate and
would support the result I proposed (a mixed regime is better).

    >> 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> Possibly not all, I grant you that.  I am having a hard time
    Ben> coming up with a good example though...

Anything under GPL.  You can hire anyone who can read code to fix it
for you.  At that point, the decision to go back to the original
supplier means they've come up with such an incredibly redeeming
improvement that it's equivalent to deciding to buy a new product.

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

    >> In fact, it's a misuse of the term "monopoly".

    Ben> I claim that there are monopolies today in areas like:

[examples snipped]

I don't contest these examples are monopolies.  I am contesting that
lock-in necessarily implies monopoly in the important market.  It does
not imply monopoly in the original installation market, and I claim
that for many software products that is the important one.

    Ben> I claim that general factors about the software market cause
    Ben> the emergence, again and again, of such monopolies.  I

Yes, but the factors that cause monopoly are economies of scale in
distribution and network externalities for users.  Not lock-in.

    Ben> further claim that, theory notwithstanding, in the market the
    Ben> seller is in fact forcing buyers to absorb the costs of
    Ben> lock-in, and not the other way around.

A real example of sellers shouldering the switching cost is in the
long distance telephone market, where vendors offer significant
bonuses to customers to switch.  In software, many vendors offer
significant rebates to users of competing products, and discounts to
students.  Of course, once you've learned to use Word as a student,
you or your company must bear the switching cost as a legal assistant.
But it's not like the company invested in handcuffs from which you get
no benefit.  To many customers who complain about lock-in, I say
"didn't you listen when your mom told you not to take candy from
strangers?"  Or, to switch metaphors: overeaters shouldn't complain
about the cost of the Alka-Seltzer!

If the seller can establish a monopoly, the seller can extract a
greater share of the surplus from the long-term relationship created
by lock-in.  That awkward wording is intentional; it focuses on two
things.  First, the buyer is not forced to absorb the costs of
lock-in; they are deducted from the surplus.  Second, lock-in is a
_good_ thing from the (static) point of view of production; costs of
switching are avoided, thus creating the increased surplus.

This means that customers who buy products which artificially create
switching costs (eg, proprietary file formats) are locking the
handcuffs on their own wrists.  Caveat emptor, I have no sympathy.
But if the firm was a monopoly ex ante, the unbalanced sharing of
gains from trade should be ascribed to the monopoly, not to the

Today we see customers everywhere demanding source and compatibility
to public interfaces.  It worked for TCP/IP, it worked for HTML, it
will work for XML.

Of course Microsoft will try to hijack XML with proprietary
extensions.  So what?  If the extensions are worth that much to you,
you're stuck with Microsoft anyway.  If you don't use the extensions,
then the file format is compatible.  (Further comments below.)

    Ben> Should the resulting monopolies not be called natural?

It depends on what you see as their cause.  Natural monopolies in
economic analysis have a strong connotation of productive efficiency.
You don't want to put that gloss on proprietary software, do you?

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

    Ben> Both are significant in software.  Isn't it true that
    Ben> software is a major motivator of studying network
    Ben> externalities?  In any case the example of lawyers using Word
    Ben> Perfect is an example where the one factor is pitted against
    Ben> the other.  So far lock-in has won in this case.

Yes.  It's worth noting that the lock-in here is generated by a strong
network externality in a "local" community, opposed by a weaker global
network externality.

    Ben> There *YOU* are using the phrase, "natural monopoloy"!
    Ben> AFAICS I was using it to mean the same thing that you are
    Ben> here...

Lock-in doesn't mean increasing returns to scale (IRTS).  The scale of
the relationship doesn't change.  So it is not a natural monopoly,
even with respect to the locked-in customer, in the sense of IRTS.

    Ben> Partial disagreement here.  What I mean by readily
    Ben> distributed is that it is possible to extract considerable
    Ben> parallelism in the testing.  The overall effort may be
    Ben> substantially increased, but the time to test plus the
    Ben> individual effort required from any one participant is
    Ben> decreased.

Unless the cost of time-to-market really dominates the cost of
production, this is convex costs.

    Ben> Here is an interesting question for you.  Suppose that
    Ben> marginal total costs are increasing, but the marginal
    Ben> costs/participant are decreasing.  Does this economically
    Ben> behave like you would normally expect a convex cost-model to
    Ben> behave?  If all participants are part of a single economic
    Ben> entity, clearly yes.  But if they are not?

No, this doesn't behave like convex costs.  This is precisely why the
free software case is so theoretically interesting.  The costs of
producing proprietary software are (plausibly) convex, whether
development is centralized or distributed.  The costs of distributing
it are not.  However, we can plausibly separate the two processes, so
that your question about the two margins are analytically separable.
This is basically the economic state of the art, as represented by
_Information Rules_.

It is not clear to me that the free software production costs are
analytically separable in that way, to the extent that the users join
the developer community.  This is fascinating.  My belief is that some
software products will have a strong advantage to being produced in a
free regime, but they will be greatly underfunded because of the free
rider problem.  Others will have a smaller advantage, so the lower
degree of underfunding in the proprietary regime will be the important
consideration.  (Note that monopoly production also guarantees
underfunding (but less); this is a general property of monopoly.)  It
is this tradeoff that leads to my conclusion that a mixed regime leads
to the highest benefits for society.

    Ben> A concrete example to consider is Perl's test suites.  A
    Ben> substantial amount of Perl, including most good modules, come
    Ben> with test suites.  If something obscure breaks on your
    Ben> system, there is an excellent chance that the breakage was
    Ben> found and identified on installation, and your standard
    Ben> perlbug report likely contains the information that
    Ben> developers will need to debug what happened.  This means that
    Ben> a lot of people sit through a lot of tests, but fixing things
    Ben> becomes far, far easier!

This can, of course, be emulated by proprietary firms, although their
customers may tend to be more cranky about sitting through the tests.

I don't understand the implications for cost; it looks like developing
test suites should be convex in size.

I suppose that user bug reports are helpful, but again proprietary
firms can use this.  (User-supplied fixes are something else, of
course.  That discussion belongs elsewhere.)

    Ben> However one thing is much more sharply true of free software
    Ben> than proprietary software.  Poor modularity in your
    Ben> interfaces much more rapidly becomes a barrier for testing
    Ben> and development.  As a result free software has a strong
    Ben> immediate incentive to keep things modular and well-defined.
    Ben> Is this a benefit or a disadvantage?  I have seen both sides
    Ben> argued...

I can't see how the beneficial part can do anything but dominate in
the real world, which is dynamic.  I know that Windows NT started as a
microkernel architecture but today is anything but, for performance
reasons.  Well, Linux, for all purposes I know of, kicks that
"anything but".  And Linux is going to be able to "embrace and extend" 
new modules faster.  I expect this advantage to increase as more and
more stuff gets modularized.

Also, given the results we're seeing in Windows NT, I suspect there
must have been a management failure somewhere.  For example, in all
implementations I know of, a C++ static class member variable is
nothing but a global variable as far as the CPU knows.  This means
that where global variables are efficient, a C++ class can preserve
modularity without giving up efficiency.

I imagine that there are similar devices for most of the performance
problems that would have occurred.  So (following every development
guru in history) I would say that good management would have resulted
in a microkernel _architecture_ that would have been compiled into an
efficient integrated _executable object_.

(I am not a professional programmer; I welcome criticism of this
analogy, but do consider whether others on FSB need to see it ;-)

Re: planned obsolescence.

    Ben> Tell me why I cannot buy a slant 6 engine today then.  (This
    Ben> was an engine sold briefly by Dodge in the 70's that was
    Ben> unbelievably reliable.  I know people who still swear by
    Ben> it...)

I remember those.  I can't see that this has anything to do with
"obsolescence," let alone the "planned" version.  I can think of lots
of reasons why they might discontinue a technically superior product,
like lower consumer-willingness-to-pay/producer-cost ratio, higher
costs of maintaining and improving the design, couldn't meet
California pollution standards cheaply enough, etc.  If you tell me
none of those are true, I dunno; I still don't see a connection to
planned obsolescence.

    Ben> Agreed that customers are ignorant of computers.  However I
    Ben> suspect that rapid change is in the nature of sofware for the
    Ben> near future.  Rapid change guarantees ignorance in most of
    Ben> your consumers...

True.  This can be a big problem, sufficient to justify legal
intervention (creation of non-disclaimable implicit warrantees).

However, remember that most economic processes are driven by what
happens at the margin.  If the customers at the margin of the
"informedness" distribution are well-informed, they may be enough to
start a "stampede for the exit" (did you have investments in stocks on 
Black Monday?  do you have them today?)

And remember that distribution costs of _information_ are low.
Training consumers to understand the meaning of what you say may be
hard, but I don't think the broad properties of software change that
fast.  Eg, once a consumer understands the idea of a secure VPN,
changing the encoding method or the various tunneling/addressing
methods can be treated as information that the consumer doesn't need
to understand in detail.  This should improve over time.

    Ben> Agreed.  If you were not locked in to the solution, then
    Ben> guarantees of future support would not matter - you could
    Ben> just switch later.  But switching is hard, consumers know
    Ben> that, and so said guarantees are very important to consumers.

However, one thing that consumers are going to be more aware of as
time goes on is that one simple measure---using publically
standardized interfaces---decreases switching costs enormously.

    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> I think that you cannot ignore the shift when you move from
    Ben> having a vendor selling a product with a company like
    Ben> LinuxCare which offers you support on a range of products
    Ben> from a range of sources.

Point taken; I don't see its relevance.  Reflecting....  ;-)

    Ben> I claim that these factors result in unusual economic
    Ben> properties for software, and should not be ignored in an
    Ben> analysis.  If you explain why they are irrelevant to an
    Ben> analysis, that should also be sufficient.  I believe that the
    Ben> shift in economic models followed by the supplier is likely
    Ben> to break hidden assumptions that economists make...

All of that is true.  My claim is that they can be considered
independently, or in some cases in groups of two.  Experiences with
examples using such small groups of factors is sufficient to extrapolate 
to models combining them all.

    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> Huh?  I am claiming that they are relevant, why should I try
    Ben> explaining why they are irrelevant?

As my sister would say, "Steve, stop being a d**kh**d."  I don't say
those factors are irrelevant, because they are not. and I was pissed
that you were misreading me to say they do.

Sorry, entirely my bad.

What is irrelevant is demanding an example with all of the various
influences together.  For example, for nearly all purposes cost-side
factors and demand-side factors can be treated completely separately
because they are additively separable in profit (= revenue - cost).

    Ben> It was somewhat of a rhetorical question.  I am claiming that
    Ben> software lends itself strongly to natural monopolies, this
    Ben> fact is being recognized more and more widely, and the
    Ben> resulting dynamics are not to be underestimated.

I don't understand what you're getting at.  The natural monopoly
aspect is sufficiently obvious that anybody who doesn't understand it
had better get a job working for somebody who does (or why Wozniak
worked for Jobs, not vice versa).  It has been at least since

What is really interesting about software is that product space is
continuous (up to your intuitionistic objections), and that the design
process is sufficiently powerful that a product "near" another product
can be designed, specified, and coded, although possibly at great
expense.  Once the product is designed, producing and distributing it
is trival, unlike hardware.

This means that software is naturally what economist call
"monopolistic competition".  However, normal monopolistically
competitive markets have strong decreasing returns to scale, so there
are many firms, and the competition results in perfect competition
in the limit.  This is not true of software.  On the other hand, the
very low costs (by industrial standards) of entry mean that there
could be more competition.

One application:  the strongest competition for Word 2000 is Word 98.

Another: freeing a program instantly results in several-orders-of-
magnitude leap in competition in that application, because it lowers
the costs even further.

    Ben> But when the "monopoly" is held by a free software product,
    Ben> which allows for the product to be supplied by "an internal
    Ben> free market" within the bounds what would otherwise be a
    Ben> "monopoly market", then you get an opportunities for a more
    Ben> efficient competition.

That's true, as I re-stated above.  Except that I don't see an obvious 
definition for "internal free market".  I don't even really have a
good idea of what it looks like to the firms and users participating,
let alone what the crucial economic relations will be.

    Ben> A major claim of mine is that as a consequence the choice
    Ben> between a proprietary product and a free software product is
    Ben> an implicit choice between whether your needs will be
    Ben> provided by a monopoly with all that entails, or a free
    Ben> market.

True.  But what you're missing in that statement is that you can
choose the degree of monopoly by specifying the level(s) at which
public standard interfaces must be used.  It may very well be
acceptable to the market and public policy for Word to be entirely
proprietary in code as long as the user has the ability to save files
in a publically standardized format.  (It may not; this may not be
enough to keep Microsoft from mangling say XML to the point that the
only Microsoft-generated XML files that are readable from other
programs could just as well have been saved as text/plain.  It might
be necessary to legally create an implicit warrantee that all programs 
claiming compliance with a published standard must provide a list of
features which, if used, have _any_ possibility of producing
non-standard output.)

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

    Ben> In the long-run at equilibrium, yes.  However a substantial
    Ben> part of the dynamics of software depends upon what the
    Ben> current *dis-equilibrium* is.

True.  I think that the important part of disequilibrium is that
consumers don't realize things like "all Internet connections are
publicly accessible" in a certain sense, though.  Once consumers are
educated to that level, they will start demanding appropriate features
and standards and the perceived/real differential will vanish.

    Ben> Transient effects are hard to model, granted.  However that
    Ben> does not stop them from being incredibly important in a
    Ben> rapidly changing industry...

On the flip side, robber barons come and go, but government regulatory 
agencies are forever.

PS to FSB:  Is this conversation of general interest?  Should we
take this one to private email, or are people following this?

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