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

[mark at pc-intouch.com]

On Tue, 17 Aug 1999, Jacques Chester wrote:

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

Mathematically, N^2-N is only the number of *two-ended* communication
paths.  I could see several situations in which what would matter would be
the number of possible *subsets* of the number of developers, which would
be a much scarier 2^N.

One extremely important effect we're not considering is the collaborative
amplification of creativity: when people work on a project together
instead of breaking it into pieces and taking one piece each, they share
ideas that would otherwise never be implemented.  As someone else who's
name I don't remember said, "If I give you my idea and you give me your
idea, we each have two ideas, and together we have four."  This could turn
out to be an even more significant contributor to bazaar-style development
than the scaleability issue.

> 'Always' is a dangerous word. 'So far' might be a safer bet
> for now. So far the favoured solution is the Bazaar being a

What I meant was that adding more people will never slow down development.  
(My interesting observation about Brooks's Law was specifically that for
sufficiently high values of N, the developers will produce *nothing at
all*.)  The new people might turn out to be totally useless, but the
additional cost per new person is so small that the free-rider problem is
negligible.  If one out of a hundred people on the project's mailing list
actually contributes anything to the project, the mailing list is doing
its job.

The only cases in which this becomes a problem are those in which the free
riders actively interfere with development by, for example, starting flame
wars on the mailing list, spamming the newsgroup, wasting bandwidth on the
FTP site, etc.  In that case, the core development group (once it realizes
it can't restore order) will typically adapt to the situation by moving to
a new mailing list, for example.

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

I didn't know ESR said that.  I was thinking that in a group that's not
being forced (by a phalanx of whip-cracking PHBs) to build an entire
project from the ground up, it would be natural to build it in pieces that
communicate with well-defined APIs.

The *interpersonal* communication paths only exist within each subgroup.  
So if N developers break into M subgroups, they go from N^2 two-ended
paths to N^2/M paths.  The communication between groups is handled by the
APIs in their respective projects, as well as some higher-level
coordination through Freshmeat-style shared resources.

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

Or, as Heinlein said, "The best thing about space travel is that it made
it possible to go elsewhere."