For some reason, when Eric S. Raymond wanted to make a point about the “bazaar” model of open source software development, he named it after someone else. Thus we have Linus’s Law:
Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law”.
The “proof” of this law, such as it is, is a reductio ad absurdum painting the contradiction of the law as a universe in which the Linux kernel couldn’t be created.
If “Linus’s Law” is false, then any system as complex as the Linux kernel, being hacked over by as many hands as the that kernel was, should at some point have collapsed under the weight of unforseen bad interactions and undiscovered “deep” bugs. If it’s true, on the other hand, it is sufficient to explain Linux’s relative lack of bugginess and its continuous uptimes spanning months or even years.
Let us remember the time that Linux development did collapse under its own weight. Raymond’s original essay was written in 1997; by 2006 it seemed that “we’re adding bugs at a higher rate than we’re fixing them”. In between, more developers had (presumably) contributed, so what happened there? Why weren’t all of the bugs even shallower?
I’d like to examine a result from the social sciences here. From the Wikipedia (I am researcher, hear me roar) page on bystander effect:
The bystander effect, or bystander apathy, is a social psychological phenomenon that refers to cases in which individuals do not offer any means of help to a victim when other people are present. The probability of help is inversely related to the number of bystanders. In other words, the greater the number of bystanders, the less likely it is that any one of them will help.
And then, a few paragraphs later when talking about computer-mediated communication:
Research suggests that the bystander effect may be present in computer-mediated communication situations.
The experiments into bystander apathy are specifically about someone in distress, either asking for help or visibly in trouble. Maybe it applies here, too, when the only “distress” is that some software you didn’t pay for could be better than it is. Perhaps, even before we get into discussions of whether the projects have welcoming communities that accept contributors, our projects are putting people off just because they know that there are plenty of others out there who could fix these bugs before they do.
I’ve met software team leaders who, when asked how their techniques and processes could be made to scale to a team of 1,000, answer that they’d start by giving the project to a team of ten. Maybe they’re onto something.
