RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"

[Jacques Chester]

>
>On Sun, 15 Aug 1999, Eric S. Raymond wrote:
>
>> 2. Brooks's Law is not precisely *equivalent* to LODR, but is rather 
a special
>>    case of it involving *particular* nonlinear scaling phenomena.  
Accordingly,
>>    one may assert that the bazaar mode repeals Brooks's Law without 
making
>>    any commitment about the applicability of the LODR in general.
>
>One interesting implication of Brooks's Law is that as N (the number 
of
>developers) gets sufficiently large, the cost of management and 
>coordination (which is a function of N^2) ends up exceeding the
>productivity of the developers (which is a function of N) and nobody
>produces anything.  I suppose the developers spend all their time 
sitting
>in meetings trying to explain Brooks's Law to their boss.

The issue of quadratic paths of communications. It's one of the
suggested causes of Brook's Law.

>If we look at the real-world experience of bazaar-style projects, this
>doesn't happen.  Adding more developers, or even more end users, *
always*
>benefits the project--if nothing else, they'll find bugs faster.  This
>suggests three possibilities:

'Always' is a dangerous word. 'So far' might be a safer bet
for now. So far the favoured solution is the Bazaar being a
highly scalable means of production. This means it has limits;
but where one goes after creating entire operating systems
is beyond me.

>1.  Bazaar-style projects really are immune to Brooks's Law, because
>someone sprinkled pixie dust over them or something.

I seriously doubt this. Seems akin to saying that "Friends"
gets higher ratings for happy peppy reasons; which is
patently rubbish. "Friends" gets high ratings because it
has highly attractive people behaving like children.

>2.  Bazaar-style development is so scaleable that we've never even
>approached the kind of 'critical mass' that it would take for the cost 
of
>management to exceed the productivity of development.  Internet
>technologies make the bazaar scale even better.  We'd need millions of
>developers to start to notice the management overhead that Brooks
>predicted.

I don't know about *millions*. But this seems to be
the best bet at the moment. It may well be that true
Bazaar projects will never reach this point: pressures
of organisational overhead will cause fragmentation
into smaller projects. Rather than everything being
subsumed by the GNU project as a single hierarchy,
for example, a typical linux distro is the result of
endless autonomous units. The pressure to subdivide
spontaneously creates a structure that seems not
unlike a mandelbrot fractal.

>3.  It's so easy for a bazaar project to divide up the labor involved 
in a
>project that the largest bazaars tend to break up into smaller
>task-oriented teams.  (For example, instead of porting Linux to the
>PowerPC chip by having Linus say "OK, all you kernel hackers out 
there, I
>want you all to buy a PowerPC and start porting the kernel", the Linux
>developers handed the task off to a team that had PowerPC experience.)

Well, there you go. If I got ESR right, the labour-division
thing is handled by independent action and the parallel
handling of vertical problems.

>  So
>a large bazaar never reaches critical mass; it recognizes, in an
>adaptive-system way, that it's trying to do too much, and breaks up.  
One
>disadvantage of this process is that if the pre-breakup stresses in 
the
>group are aligned the wrong way, it may lead to forking.

Forking is important and healthy, in my view. Indeed,
if nanotechnology delivers on its promises, forking offers
a glimpse of how future society will work. Don't like
your government's laws? Space colonies are cheap. Fork
off from your current one to a new one.

Enough dreaming.

JC.