Subject: Re: Returns to service professionals
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Mon, 5 Jul 1999 16:11:39 +0900 (JST)

Brian,

"Analysis" follows "analogy" quite closely in a dictionary, but they
are otherwise unrelated.

>>>>> "Brian" == Brian Bartholomew <bb@wv.com> writes:

    Brian> Perhaps the pool of volunteer/charity programming talent is a
    Brian> commons which can be overgrazed.

    >> Afraid not.  Not unless it's slave labor with no choice about
    >> what it works on, or too stupid to have its own opinions about
    >> what's worth doing.

    Brian> Don't you feel you are reputiating the control users have
    Brian> over volunteer producers too strongly?

No.  It's not the control they have over currently working developers, 
it's the control they have over choice of projects that matters.
Common pool in this context means too many projects, not enough effort 
on each.

    Brian> Suppose a ruthless software user tried to motivate a
    Brian> student volunteer to produce more than they cared to

Aren't you forgetting the context?  We're talking about AOL
"exploiting" sendmail or Yahoo, Apache.  I find it hard to imagine
that if AOL calls up sendmail and says "fix this NOW!" they'll get
anything but a bray of laughter back, unless it's accompanied by a
purchase order.  Or the patch is already in the queue anyway.

    Brian> short term, but eventually burn the student out, and sour
    Brian> them on volunteering forever after.

No.  Sure, individual project leaders can exploit their individual
junior developers, but that's not a common pool problem, that's garden 
variety stupidity.

If there's a true common pool problem, it has to be that there are too
many projects fishing for too few developers, so that nothing ever
gets implemented right.  (This is why "knowing what's worth doing"
matters.)  A single project intensively using a developer is the
antithesis of a common pool problem.  The efficiency of such intensive 
use is precisely why economists generally advocate enclosure as the
solution to problems of the commons.  You might find "patent" or
"copyright" more familiar than "enclosure," but they're basically the
same thing: assign a property right to a congestible resource that in
nature is open access.

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