[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Managing changes to projects that use autoconf/auto

From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla
Date: Thu, 08 Apr 2004 15:12:09 +0900
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux)

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> You can arrange coordination with good tools.

Nonsense.  There is excellent reason to believe there are essential
limits, though I know of no proof.  Coordination without hierarchy
requires communication which is exponential in the number of
participants, or a market structure which free software inherently
foregoes.  Sure, you can design better structures for general
communication, but design implies hierarchy (ie, at least a central
architectural authority), and the ones I know of require some form of
central control.

It's possible that there are efficient decentralized mechanisms which
will evolve that are not market-structured, but none are known at
present.  Take BitTorrent, for example.  The author claims it's a
tit-for-tat kind of mechanism (a la Axelrod _The Evolution of
Cooperation_), but it is not.[1]  It looks much more like a matching
market.  (Osborne and Rubinstein, _Bargaining in Markets_, is quite
readable, and the math, while skippable, is pretty elementary.)

[1]  Yes, it's tit-for-tat in the common parlance, but it doesn't have
the same strategic properties---choking is not really punishment, it's
abandoning a current partner with known poor value of cooperation in
favor of a random value with higher expected mean.  Tit-for-tat's
strategic properties depend on "lock-in" to a specific partner.

Institute of Policy and Planning Sciences
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]