Subject: Re: Open letter to those who believe in a right to free software
From: "Stephen J. Turnbull" <>
Date: Thu, 28 Oct 1999 19:00:54 +0900 (JST)

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

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

    Ben> Compare learning Linux on your own.

    Ben> Compare learning Linux with a friend you can call when the
    Ben> going gets tough.

Strongly negative, in my case.  My learning curve for Linux was like
falling off a cliff:  more annoying than hives to quadruple my
productivity under the previous OS in less than two weeks.  Calling
friends generally results in talking about their problems far more
than about mine.  Says more about my friends than me, I suppose  :-)

    Ben> Just how strong an effect are we talking?

Depends on the parameterization of the model, I'm in no position to
answer quantitative questions like that.

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

    Ben> Being a Perl programmer, I disagree.

"Oh, ith _that_ what'th wrong with you," thaid the Lithper.  :-)

Speaking to the content, I already said it's not natural for you to
think that way.  I don't see where you think the "new product" model
is inaccurate, though.

    >> Anything under GPL [will not produce a lock-in effect].

    Ben> No, you are still locked into the basic product and
    Ben> architecture.

I don't see why this is interesting; it's surely irrelevent to free
vs. proprietary.  If the customer is so worried about it, design the
protocol/API so that it is efficiently extensible (a la X11's wire
protocol or XML).

    Ben> No, it does not imply monopoly when the product comes out.
    Ben> But the threatened future control does constain decisions.
    Ben> In software purchasing people pay a lot of attention to
    Ben> questions about whose products have the most "momentum".
    Ben> People know that something will win, and there is a lot of
    Ben> pressure to be on the right "bandwagon".

I can't help it that Purchasing collects the least-capable employees
after Personnel.  If all they can do is get on "bandwagons," they're
going to be under pressure today and they'll be under pressure
tomorrow.  If you want to get out from under, you step back, look at
your organizational and systems architecture, and design them for
flexible upgrades.  If that means commissioning a custom design for
some component with full docs including source, so be it; you won't
regret it.

Think of it as evolution in action.  Economics is interested in
decisions made by actors who are aware of and attempt to influence
their environment.  By next week, the others aren't going to be of any
interest except to economic paleontologists.

>From the other side of the market, there is a lot of money to be made
by people who give copies of S&V's chapters on lock-in to potential
customers before making their sales pitch for flexible open source

    Ben> Re-training is the least of lock-in worries.  I work for a
    Ben> company which has a significant investment in a rather
    Ben> complex VB front-end to their data.  (The company's basis
    Ben> depends on its models of a specific type of financial
    Ben> security.)

    Ben> At the time they did this development they had to choose a
    Ben> platform.  At this point to switch they have to build a
    Ben> platform with similar functionality - while maintaining the
    Ben> existing one because without it the company would quickly
    Ben> fail.  This is rather greater lock-in than just, "Retrain a
    Ben> couple of people."

OK, so they're locked in.  Maybe they should have spent twice as much
for a more modular, better-specified design which could be
reimplemented and retargeted to a better platform.  Maybe not---then
they're locked in.  But if so, we economists do not consider ourselves
responsible for the preventable self-inflicted injuries of decision-

    Ben> Likewise the Word Perfect example that I gave with lawyers is
    Ben> not a re-training issue.

Lawyers, huh.  Lawyers are the beneficiaries of a government-
franchised cartel and have plenty of room to afford inefficiency.  For
that reason, lawyers are not businessmen.  It's going to take them a
lot longer for them to get to a low-cost equilibrium than firms in
more competitive lines of business.

    Ben> Sure, they could rebuild the system from scratch in Microsoft
    Ben> Word, but the investment required is substantial, plus nobody
    Ben> wants to go through the inevitable mistakes involved in doing
    Ben> such a thing.

Eventually some firm will do so.  They (or if they make big mistakes,
the next one), will make out big.

    Ben> This is all theoretically true, however it merely supplies a
    Ben> general theoretical explanation for my point.  In the
    Ben> software market the supplier frequently does establish a
    Ben> monopoly, and lock-in contributes to the ability of the
    Ben> supplier to extract profits from this situation.

True.  In general, however, the customers also extract profits from
the situation.  Has anybody ever computed the percentage of cost
reductions due to Microsoft products compared to not using the
application at all (not compared to using the best alternative)
captured by Microsoft?  Despite Microsoft's revenues, I'll bet it's in
the single digits, and I'll offer good odds for less than 50%.

The point is that even Microsoft is apparently quite constrained by

    >> This means that customers who buy products which artificially
    >> create switching costs (eg, proprietary file formats) are
    >> locking the handcuffs on their own wrists.

    Ben> Proprietary formats are just the vendor helping the process
    Ben> along.  There are still large factors creating lock-in.  Try
    Ben> to switch a body of automated processes from Perl to Python
    Ben> some time.  Even though the Perl processes may be using
    Ben> non-proprietary files, and the code is available, the switch
    Ben> is not very easy...

So don't.  Why would you want to do such an insane thing?

Lock-in is a problem when somebody comes along and wants to sell you a
product to do the same thing at a price that would be paid for 5 times
over in cost savings in 2 years _if you had no preexisting files_, but
you can't afford to do it because the cost of translating file formats
is prohibitive.

    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> Uh, no.  It is generated by the fact that legal firms have
    Ben> implemented important infrastructures using features of Word
    Ben> Perfect that would have to be rebuilt from scratch in
    Ben> Microsoft Word.

I fail to see where we differ.  You seem to think that only people can 
participate in network externalities?  Not true.  What I had in mind
is that a law office is not composed of lawyers (irrelevant, they have 
no fingers), secretaries, and a monolithic WordPerfect application.
Instead, that "infrastructure" you talk about is actually dozens or
hundreds of document templates, macros, and whatever, that interact
with the secretaries through WordPerfect.  All of that is made more
valuable because they can interact through a single system.

If those templates and macros were all stored in "Active XML", though, 
the infrastructure problem goes away, doesn't it?

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

    Ben> But does it act like convex costs?

As far as I can tell, this question is meaningless.  Does the
subsystem act like convex costs?  Yes it does, because it possesses a
convex cost function.

    >> No, this doesn't behave like convex costs.  This is precisely
    >> why the

    Ben> Apparently not... :-)

Are you trying to score debating points, or are you trying to
understand how modularizing this program will make it more
undertandable and maintainable?

    Ben> I think that in a well-run company the costs of productions
    Ben> need not be convex.  A sample example.  A real company that I
    Ben> know took the C libraries and modified them so that a
    Ben> core-dump, in the process of dumping core, would capture
    Ben> various information including the command-line, location of
    Ben> the core, and a stack-backtrace, and mail that to a list of
    Ben> people.  What do you think this did to their development
    Ben> costs for maintaining their ongoing crons?  (OK, *after*
    Ben> development stopped for a month and a half. :-)

It changed from the original convex cost function to a new convex cost 
function whose values are lower at every quantity.  What did you think 
I was going to say?  _It's not the same cost function, you just went
and changed it._

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

    Ben> I think that having to fill in a bug report when they
    Ben> *expected* to do an install might not fly too well either...

A few messages ago (maybe it was private) you thought that was quite
alright, at least when free software firms do it (the escaping betas
thread).  I don't care whether it's "yes", "no", or "I don't know",
but I don't see why the answer would be different for proprietary
vs. free.

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

    Ben> The introduction and acceptance of this technique will reduce
    Ben> development costs.  Sure, once the improvement is
    Ben> implemented, the costs again begin climbing (more shallowly
    Ben> than before), And there is substantial cost in first creating
    Ben> these suites.  But while you are creating this
    Ben> infrastructure, the future per person development costs are
    Ben> dropping.  This is true both per developer and per user.

I saw you palm that card.  How _did_ that time argument get in there?
I didn't put one in.

Ben, an economic cost function is a function from the quantity of
goods ("size") produced to the cost of production.  It can change over
time, but it is a different cost function then.

    Ben> I like that argument.  But how do you respond to the
    Ben> assertion that many features which consumers want require
    Ben> such tight integration, and as a result free software
    Ben> projects will never be able to tackle projects above a
    Ben> certain complexity?  (Say, any project on the order of
    Ben> NT. :-)

I was hoping _you_ would do that for me.

The basic argument is that if a customer can identify a feature, then
it can probably be compartmentalized into a module.  If it can be
compartmentalized into a module, you can hand it to a separate team to 

Another way to look at it is the adage that a software system reflects
the organization that produced it (and vice versa).  There is a huge
quantum jump between the integration that can be achieved by a single
designer, and the integration produced by a team of designers.  A less 
integrated design permits less integrated development all the way down 
the line to unit test.

    Ben> While this difference hands proprietary software a lot of
    Ben> rope, it also puts a barrier on what sorts of techniques are
    Ben> available to it.

I just don't see that barrier.  I see biases on both sides, but no
absolute barriers.

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

    Ben> The legal system is moving the other way these days...

Many little steps backward, but ... <knock, knock, knock> "Nobody
expects the American Revolution."

    Ben> Cool for helping people understand today's technologies some
    Ben> 5 years too late.  What about the technologies that people
    Ben> will be arguing about in 5 years?

You really think it's going to change that much?  Maybe.  People will
have to learn to abstract faster, is all.  People who can do that,
even imperfectly, will make big bucks as consultants (or, with
somewhat different personalities, chief executives).

If it is going to change that fast, I'm really pessimistic for the
ordinary Joes, though.  Legislation will _never_ be able to keep up,
free software won't help.  They'll just have to accept the trickle-
down from the technocrats.

    Ben> And they have not reached this awareness before?  How did the
    Ben> OSI, POSIX, etc come into existence then?

Do you mean for me to believe that OSI, POSIX, etc, were driven by
_consumer demand_?  Next thing, you'll be selling shares in the
Brooklyn Bridge by MLM....

    Ben> Plus people tend to forget the old lessons with each new
    Ben> generation of types of devices...

"Predictable, self-inflicted injuries."  They should buy insurance
before taking a bath, is all I can say.

    Ben> Thank you for confirming that most of corporate America is
    Ben> run by idiots.  With that established, as these idiots
    Ben> realize that the difference makes a difference to them in a
    Ben> particular area and starts to act on that decision, the
    Ben> result is economically important.

You wanna parse that for me?

    Ben> I strongly suggest looking back through the history of
    Ben> software to see how other "open" initiatives have played out.
    Ben> You should find no shortage of potential examples to sharpen
    Ben> your intuition.

I don't see any that were driven by users.  To date, all
standardization efforts that I know of were driven by developers who
wanted to take advantage of network externalities to get the market
started, then lock-in their own user bases with feature-cuffs.

Except for the developers who just wanted to get the market started so 
that somebody else would help subsidize their toys.

That's my intuition.

    >> 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> Fine.  Will they be informed on the advantages of various
    Ben> types of distributed architectures and the relevant
    Ben> protocols?

Of course not.  That's what's going to finance your retirement, guy.
Why should they be?

Customers are going to learn that when they talk to you, they need to
ask you "once this is done in VB/NT+SMB, how much would it cost to
redo it in Python/Linux+NFS?" and extrapolate from that to guess what
it's really going to cost in 2005 to redo it in Language X/Platform
Y+Protocol Z and budget for that.  Then they're going to ask "suppose
you split it out into a bunch of clients and servers speaking an
extensible network protocol?"

And only then will they decide which one to buy.  The ones who don't
won't be around in 2005 to worry about, they'll be back in MBA school
learning those questions by rote.  :-(

    Ben> Also how long has it taken to teach consumers the realities
    Ben> of what leads to viruses and what viruses will cost?

The grand total of what viruses have cost to date probably leaks out
of the credit card system every week.  I think that's pretty quick
response, actually.

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

    Ben> Not if Microsoft can get the DOJ's budget slashed a few
    Ben> times. :-/

The DOJ will not go away, I assure you, and in 2020, when you talk to
the college recruits about the bad old days with Microsoft they'll
look at you blankly, wondering who's afraid of #100 on the Fortune
500, what with Cygnus Solutions at #3 and in the dock for
planned obsolescence of glibjava....

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