Subject: Re: Hal's new white paper - Free Software/Public Sector
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: Wed, 24 Mar 2004 16:10:50 +0900

Long.  Executive summary:

1.  "Transportation cost" is a metaphor for "cost of adapting actual
    behavior to expectations."

2.  As usual for economic models, this one is not particularly
    interesting to FSB practitioners.  The idea of "cost of
    adaptation" is taken as a primitive abstraction, but this is too
    high-level to be directly useful to FSBers.

3.  It _could be_ useful to government policy makers, because the
    model can predict qualitative features of behavior by profit-
    oriented agents who have specialized knowledge the government
    cannot (afford to) acquire.

4.  I don't think the model in question (as presented here, I haven't
    read the paper yet) is appropriate.  Many of FLOSS's benefits come
    from the rapidity with which products can be morphed into better-
    adapted products, but this model assumes that proprietary software
    adapts just as well in the short run ('t' is the same for all
    software) and ignores long-run evolution and standards conformance.

>>>>> "David" == David N Welton <davidw@dedasys.com> writes:

    David> I guess what I'm not getting with that is why there is any
    David> relationship between the transportation costs of the two?
    David> That's not related at all to whether the software is free
    David> or proprietary.

OK, first of all, "transportation" means reconfiguration of software
or user practice so that software behavior meets user's expectations
and vice versa.  (It's not clear to me whether you got that far or
not.)  Economists say "We're in feature space, not geographical
space."  It's the same metaphor that's used when one says "that's
_really far_ from {what I expected,satisfactory}" and the like.
Another way to put it is "distance = new or changed LOC".

So the "distance" is between "what the software does" and "what the
user wants it to do".  Some users want nearly what proprietary
software does (note that "nearly" is once again a commonly used
metaphor), others are "closer" to what OSS does.

I don't think this really makes a lot of sense for what most FSBers
are here to discuss.  It's actually best fit to rms-ism, where free
software is an issue of human rights.  But rms will tell you that
economics is not an appropriate way to treat these issues.

OTOH, most "OSS" advocates believe that there are measurable economic
benefits, and we need to talk about those specificially.  That's why I
mentioned "fitness landscapes", which are a fairly realistic model of
matching user needs to software features, although they were
originally developed to model adaptation of biological genotypes to
natural environment.

However, if (as economists often do) you measure "distance" in terms
of "cost of adaptation", then suddenly things start to make sense
again.  Your problem with "cost of adaptation" (which surely makes
sense to you) is that it is at a rather high level of abstraction,
hardly useful to people trying to _run_ FSBs.  "Just reduce costs of
adaptation" says the economist, and you say "How?!"  Bletch.

The model might be of greater interest to government policy-makers
concerned with deciding whether to try to make the business
environment more FSB-friendly (although again it probably doesn't help
very much with _how_ to do _that_, either), because _if_ the
practitioners have an idea of what "costs of adaptation" are in dollar
terms, the economic model can help predict what market structures and
government policies will result in (profit) incentives for the
economic actors to increase net social benefits.

Note that for this to be of use to government, all you need to believe
is that the practitioners know more than the government does about
costs of adaptation, and that it is quite expensive for the government
to learn what the practitioners already know.  I can't imagine that
anybody familiar with the behavior of the USPTO can object to that!

    David> Ahhh, I think I get it.  The 'x' is present, but there
    David> isn't anything that says it isn't .5 (or nearby), or even
    David> "in favor" of free software?

In fact, the idea is that each customer has a personal value of 'x',
and they are distributed between 0 and 1 (ie, between "I [heart]
Windows" and "die unless $software->free" in some sense).  Usually
this is assumed to be a uniform distribution (ie, the number of people
with a value x satisfying xlow < x < xhi is proportional to xhi -
xlow), for ease of analysis.  But it can be something more realistic,
it just makes solving the equations harder.

*****

I think this is a bad model because it neglects the ease of chasing
taillights in the software field.  What most (ie, people who aren't
rms-like) customers want is features of the software.  If free
software has the same features, customers will value them the same---
and all recent experience says that FLOSS catches up fast.  Similarly,
if FLOSS popularizes a feature (eg, TCP/IP communications) there is
_nothing_ to stop Microsoft, Novell, DEC, and MIT from supplementing
(or even abandoning) their idiosyncratic networking standards.

What FLOSS has _as an aggregate_ is a very high level of adaptability.
_But this is not a feature of any one product_, which is what the
"transportation cost" model assumes.  In the transportation cost
model, _each_ application will be allocated to a OS product or a CS
product based on Uo > Uc or not.  This model (from what was presented
so far) ignores a number of things that are very important to our
argument, such as the far lower cost of adapting software behavior to
user expectation.  In the short run, the user has source and can
either modify the software in-house or outsource that job.  In the
longer run, source is (usually) published, and therefore "evolution"
(both "taillight-chasing" convergence to current best practice and
introduction of new features) should be much faster than proprietary
software (given the same amount of development effort).

This model complete ignores the long run issues (which is OK for an
initial model), and gets the short run assumption just plain wrong
('t' is the same for all software).  Oh, well.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.