Subject: Correlation between
From: "Stephen J. Turnbull" <>
Date: Tue, 26 Oct 1999 01:19:19 +0900 (JST)

>>>>> "shapj" == shapj  <> writes:

    >> ... the accident that the higher price paid is spuriously
    >> correlated with more services received

    shapj> I have to be missing something obvious.  We generally
    shapj> accept that in real economies one should pay more for
    shapj> greater or more services.  Therefore, a transfer mechanism
    shapj> that shifts the burden in favor of this does not seem
    shapj> problematic to me.

The point is that the services which to you to making payments do not
include the software itself, which may be the bulk of the benefit, and
need not be correlated with the ancillary service.  Don't _count_ the
services, _sum the values_ of the principal service (the application
itself) and the ancillary services.

For example, consider hand-holding.  Firm A which really really needs a
particular application (a) already knows what it does and (b) has the
incentive and the probability of getting very very expert in-house.
This firm probably doesn't need much handholding, if the product is
well designed and documented.  On the other hand, Firm B that uses it
sporadically may very well find that paying for handholding is well
worth its while, even though the gross benefit of the software is far
lower than for firm A.  If the developer uses the handholding business 
model, then Firm B pays the development costs, although Firm A walks
off with the lion's share of the profit, since it need not pay
anything except download costs for the needed application.

The relation between handholding needs and willingness to pay for
development (in the absence of someone to offload the costs onto) is
clearly arbitrary---the story just told is quite plausible, as would
be a story where incremental development means that ease-of-use and
documentation just plain suck and in the early stages hand-holding is
an absolute necessity to the few users with that desperate a need for
the software that they're willing to touch it in its early, crude
stage.  Then paying for development by charging for handholding (no
good controller would let you get away with this internally) aligns
the incentives quite well.  My bet is that both stories will have real
examples a-plenty.  So this model of paying for development means a
completely arbitrary relationship between user value and share of
development cost paid.

Now someone will surely inform me that Firm A, which just loves the
app to death, will line right up and pay to get that app developed,
for any of a variety of reasons.  I'm sure they would, except for one
eentsy-weentsy problem: Firm A was[sic] founded in 2000.  The software
was published in 1998.  Oops.

Notice what the property-in-software model allows here: a firm (aka
venture capitalist) that _bets_ in 1996 (when development starts) that
someday there will be firms willing to pay enough per copy or per site
license or whatever to cover the development costs and then some.

The issue is what is the best way to extract money from users over the
marginal cost of reproduction and distribution, to cover the
development costs.  Property-in-software ties payments directly to
value of the software itself to the user (in the usual weak sense that
voluntary trade guarantees the buyer never pays more than it is worth
to her; price is a lower bound on buyer value); other business models,
to the extent that they are used to finance the development of the
software, tie payments to other valuable commodities.  To the extent
that handholding is used to finance development, users of the software
who also use handholding services are subsidizing those who do not.
Since the price of handholding includes overhead for development, some 
people with a value for handholding between the cost of handholding
(including providing for the retirement of the handholding vendor but
net of development cost) and the full price (including the development 
overhead) get shut out of the handholding market.  Bletch.

You can, of course, cook this example so that pure free software, with
the handheld users paying all costs of realized development, gives
maximum benefits in total[1]; you can also cook it so that it goes the
other way.  It turns out that the optimal arrangement depends entirely
on whether handholding customers or general users are more responsive
to price changes, and that can go either way.

That is not to say that realized development will be the socially
optimal amount; it will not, not enough software will be produced.  It
seems highly unlikely that for all high-quality software the ancillary
services will be of the same order of magnitude of value as the
application itself.  There's going to be a need for direct grit-your-
teeth-and-ante-up[2] contributions to the development process (and
those contributions, of course, go indirectly into the pockets of the
free riders).  But that's a separate matter (especially since it may
be mitigated by cost reduction from efficiencies of free software,
which I don't want to treat here; justified by the fact that there's
no reason to suppose it will approximate the reduction needed to get
software production to the optimal level---could push it higher; we
just don't know).

[1]  This is because charging more for the software than duplication
costs chases some potential users out of the market for the software

[2]  Developers who are doing this in their spare time, of course, are 
grinning, not gritting.  I don't think there are enough of them though.

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