I may be wrong but I think that you miss my point. Labor is a
common, because anyone can freely fish (graze) in the pool of
competent people to get some work done. I am not considering the fact
that you actually pay for the resource. The fact is that programming
competence is rarely paid what it is worth anyway, considering the
productivity ratio between good and bad programmers. I do not believe
that salaries actually regulate that market, and even if they do, it
may be that there is too much money available to get grazing
permission, so that it is not properly regulated.
Maybe the issue is that, to avoid the problem of the commons, the
use of commons has to be regulated. It may be by cutting it into
private plots. It may also be by selling grazing rights, and have an
authority controlling these rights, for example by auctioning them.
It may also be poorly controlled by the authority in charge, and thus
poorly used.
I think that to some extent that is what is happening to the
programmer pool.
I understand that is not exactly like the original common problem,
but my intuition is that there is a way of looking at it, a proper
dimension or measure, that will get us back into the original commons
framework.
Bernard
On Fri, Jan 04, 2002 at 10:03:54PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Bernard" == Bernard Lang <Bernard.Lang@inria.fr> writes:
>
> Bernard> The tragedy of commons arises from attempting to turn a
> Bernard> common resource into competing private ones, not caring
> Bernard> for the global usefulness of the resulting production.
>
> No, the _tragedy_ of the commons arises from _failing_ to treat as a
> private good what is perfectly reasonable to treat that way, viz, a
> rivalrous resource. So it has nothing to do with software as such.
>
> Bernard> the commons of egineering competence
>
> There are two sides to engineering competence. Labor, which is not a
> commons at all as Karsten points out. And "embodied" engineering
> competence, ie, software. Embodied competence is "accidental", as
> Fred Brooks ("No Silver Bullet") says; the labor is "essential".
>
> I believe Brooks: it's a truth about engineering. But what's
> important is that it is most definitely true from the FSB standpoint:
> we're all here because we're interested in the problem of compensating
> _developers_ instead of "owners of (private) intellectual property".
>
> Bernard> If you have a limited pool of a given rivalrous
> Bernard> resource, avoid turning it into a common, because the
> Bernard> invisible hand of economic selfishness will quickly
> Bernard> destroy it by overgrazing.
>
> This isn't a problem in software. The essential rivalrous resource is
> labor. By law in all countries I know of, not only is labor a private
> good, but it can't even be sold, it must be rented. No commons here.
>
> So, as usual, we come back to the problem: producing a non-rivalrous
> good requires a rivalrous resource. The former "should" be priced at
> marginal cost (near zero), whereas the latter "should" have a
> relatively high price. Result: an _essential_ market failure. But
> nothing does better than the market AFAICS. :-(
>
>
> --
> Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
> Don't ask how you can "do" free software business;
> ask what your business can "do for" free software.
--
Non aux Brevets Logiciels - No to Software Patents
SIGNEZ http://petition.eurolinux.org/ SIGN
Bernard.Lang@inria.fr ,_ /\o \o/ Tel +33 1 3963 5644
http://pauillac.inria.fr/~lang/ ^^^^^^^^^^^^^^^^^ Fax +33 1 3963 5469
INRIA / B.P. 105 / 78153 Le Chesnay CEDEX / France
Je n'exprime que mon opinion - I express only my opinion
CAGED BEHIND WINDOWS or FREE WITH LINUX