Long and perhaps tedious. Executive summary: GDP is not perfect, but
does pretty well at (1) accounting for benefits and costs that get
anywhere near a market, and (2) remarkably enough, includes proxies
for "human values."
In attempting to discuss policy directed at free software, we are
crippled by the total lack of data on how much free software there is
(from the point of view of "adjusted for usefulness"), and more
important, the utilization rates. This is an inherent difficulty of
the non-market modes of distribution that are major, and unmeasured,
channels for dissemination of free software. This constrasts with the
market mode, which automatically, cheaply, and accurately measures
quantities.
>>>>> "Benjamin" == Benjamin J Tilly <" <ben_tilly@operamail.com>> writes:
Benjamin> For a random instance consider GDP as a measure of how
Benjamin> well off we are. In families with a stay-at-home wife
Benjamin> she does a large amount of work that is not measured in
Benjamin> GDP. If she gets a job, that work still needs to be
Benjamin> done. But now that it is being done by McDonalds and
Benjamin> the local daycare center, so it shows up in GDP. The
Benjamin> work she now does also shows up in GDP. So tracked
Benjamin> economic activity goes up, and gets pointed to as a sign
Benjamin> that lives are getting better. However in reality no
Benjamin> more work is getting done, and some products have gone
Benjamin> down substantially in quality.
Do you really assess women's decision-making abilities to be so poor
and preferences to be so misguided? For shame!
Well, of course not. But! You have just _deliberately_ discounted an
important value, namely, what the ex-housewife herself wants. Merely
to make a point.
Of course GDP has measurement difficulties. However, the very fact
that we are collecting statistics on daycare center income means that
_in principle_ we can use the income and product accounts data to
estimate the sign and degree of the mismeasurement. And, in fact,
there is a cottage industry of economists (including some at the BLS
itself) who have made careers of such corrections. "Unfortunately,"
they track GDP sufficiently closely that statisticians prefer to put
effort into improving the quality of the raw data rather than try to
make these theoretically attractive adjustments "official". Hmmm.
And, by contrast, GDP accountants acknowledge and regret that they
have no direct way to measure the value of "satisfying what the person
wants". However, "at the margin" it magically does appear in the
income and product accounts! In outline, "getting what she wants"
induces her to supply labor, driving down the wage, which increases
use of her labor to produce goods, which are sold on markets, and so
enter the accounts. (Pretty abstract and tenuous, I admit. But then,
so are the arguments that lead the Nobel Committee to conclude that
Prof. Koshiba et al "observed" neutrinos. And it's better than just
dropping it on the floor, as you did.)
Benjamin> I believe that open source software lends itself to very
Benjamin> similar measurement artifacts. There are many benefits
Benjamin> which do not get measured. They range from projects
Benjamin> started which otherwise could not, to training effects
Benjamin> on people who participate, to unanticipated uses of the
Benjamin> source code speeding up development. I have seen and
Benjamin> benefited from all 3, I suspect that the same is true of
Benjamin> most here. But none of those benefits show up directly
Benjamin> in GDP, none are readily quantifiable, and all are far
Benjamin> too easy to discount.
You're wrong on the first two counts. Assuming (as seems indicated by
your phrasing) that the new projects, training effects, and
productivity effects are put to the benefit of the employer, and that
the employer's objective is to make a profit, then the cost reductions
and revenue enhancements generated show up in the firm's bottom line.
They are therefore readily measurable. That bottom line shows up in
the national accounts as income, and therefore directly in GDP. This
is precisely why GDP is such an important tool.
I could therefore speciously argue that point 3 is wrong as well,
since the benefits are automatically accounted in GDP, and therefore
no special effort is required to avoid discounting them. Why is that
argument specious? Because of course we are interested in the
_relationship_ between free software and those benefits, and unless we
measure the quantity and utilization rate of free software in some
way, we cannot even draw empirical relationships, let alone analyze
the structural relationships.[1]
And this shows the true analogy between free software and housewives'
work: the transfers are not mediated by the market. In the
housewife's case, her services are directly consumed within the
household, and so not even the benefits get accounted in GDP. In both
cases, however, because the inputs (software and labor, respectively)
are not traded on markets, they are not quantified.[2]
This is an inherent flaw in the free software model from the point of
view of policy makers. Crucial information about the productivity of
the input is simply not available _to society_ because of the mode of
distribution. Contrast that with proprietary software, where (1) seat
counts have a useful level of correlation with usage levels, and (2)
the customers' willingness-to-pay has a useful level of correlation
with the "size" of the software in terms of benefits to them "at the
margin". This flaw is not a reason to avoid free software. Rather it
makes it difficult to evaluate exactly the questions of benefit and
cost that are crucial to relevant policy decisions.
Footnotes:
[1] This is explicitly acknowledged in the macro productivitystudies,
where the measure called "total factor productivity growth" is aptly
characterized as "a measure of nothing but our ignorance." Ie, it
consists of the unexplained benefits of free software, etc.
[2] It is possible to quantify things in other ways. But the
institutions we usually use to implement markets do so automatically,
cheaply, and sufficiently accurately. Surveys and the like require
explicit effort, are therefore not cheap, and accuracy is poor because
the respondent has little incentive to gather accurate information,
and may even have incentive to distort it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py