Subject: Re: New ESR paper: The Magic Cauldron
From: Ian Lance Taylor <>
Date: 26 Jun 1999 12:10:02 -0400

   From: "Stephen J. Turnbull" <>
   Date: Sat, 26 Jun 1999 17:38:34 +0900 (JST)

   I don't understand the "not scale" point.  I've looked at this in a
   simple mathematical model, where "hackerishness" is the innate
   propensity to hack, and is distributed randomly in proportion to
   population.  In that case, the problem is homogeneous of degree one in
   the number of users.  In order to get less than degree one, you need
   to assume that in some sense the hackers are "first in" and as the
   number of users rises the proportion of hackers falls.  This may be
   true when you compare Linux against MS Windows, but it's not at all
   clear to me that it's true in general, especially as you consider the
   education effect of having source available.

I think it's correct that as the number of users rises the proportion
of hackers falls.  This matches my personal experience, and it matches
the predictions of Geoffrey Moore's early-adopter/late-adopter model.
Hackers tend to be early adopters of software.  Late adopters expect
the software to work, and are less inclined to fix it, or deal with it
at all, if it doesn't.

   If you take the "all bugs are shallow with enough eyeballs" argument
   seriously, it leads to the conclusion that bugfixing and feature
   provision should be increasing returns to scale in user population.
   Now, it is true that with "easy" bugs and features, congestion and
   coordination problems will quickly lead to decreasing returns (pace,
   Steve McConnell).  But with "hard" bugs and features, the number of
   discoveries should be sufficiently sparse that the normal OSS
   procedure of "discuss on Usenet, code, and distribute" will be
   sufficient coordination.  Presumably these are the highest
   value-added, too.

I personally only believe that argument in the sense of finding the
bugs in the first place.  For finding bugs, I think it's true that the
more people you have looking at the program the better.

For actually fixing the bugs, I agree that you have to categorize the
bugs.  Easy bugs can be fixed by anybody who understands the source.
But they naturally tend to get fixed quickly.  For any given package,
I believe there are ordinarily relatively few people who can fix hard
bugs.  It's true that as the number of users goes up, the number of
people who can fix hard bugs generally goes up.  But the increase is
not only not linear, it's exponentially decreasing, and moreover it
often tops out at a relatively small number of actual developers.