With the end of the calendar year, reflections
on the events of 2004 are popular. Ed Driscoll's
The Year Of Blogging
Dangerously, with its top ten, is typical.
A common theme in the reminiscences is the rise of the blogosphere
and its influence on public opinion, increased accountability, and
Old Media's loss of control.
But before the blogosphere, there was
fetchmail, a software
package to retrieve emails from remote servers and forward them to
... well, allowing you to read your emails. It's
open source, maintained by
Eric S. Raymond. By itself,
it's not remarkable, simply another example of a useful program
donated to anyone wanting to use it.
But in taking over development of an earlier program (popclient),
and hacking at his code, Raymond learned some lessons:
- Every good work
of software starts by scratching
a developer's personal itch.
- If you have the right attitude, interesting problems will find
you.
- Treating your
users [readers] as co-developers is your
least-hassle route to rapid code improvement and effective
debugging [analysis].
- Release early, release often, because 'Given a large enough
beta-tester and co-developer base, almost every problem will be
characterized quickly and the fix obvious to someone.' (This is
Linus
Torvald's Law: 'many eyeballs make shallow bugs'.)
From these lessons, he abstracted the difference between the
'cathedral model' and the 'bazaar model' of software development,
but which is equally applicable to the rise of citizen
cooperative analysis:
In the cathedral-builder view of programming, bugs and
development problems are tricky, insidious, deep phenomena. It
takes months of scrutiny by a dedicated few to develop confidence
that you've winkled them all out. Thus the long release intervals,
and the inevitable disappointment when long-awaited releases are
not perfect.
In the bazaar view, on the other hand, you assume that bugs are
generally shallow phenomena -- or, at least, that they turn shallow
pretty quick when exposed to a thousand eager co-developers
pounding on every single new release. Accordingly you release often
in order to get more corrections, and as a beneficial side effect
you have less to lose if an occasional botch gets out the
door.
White Paper: The Cathedral and the Bazaar, page four. And more
users [readers] find more bugs [flaws in the analysis].
More users find more bugs because adding more users
adds more different ways of stressing the program. This effect is
amplified when the users are co-developers. Each one approaches the
task of bug characterization with a slightly different perceptual
set and analytical toolkit, a different angle on the problem. The
"Delphi effect" seems to work precisely because of this variation.
In the specific context of debugging, the variation also tends to
reduce duplication of effort.
So adding more beta-testers may not reduce the complexity of the
current "deepest" bug from the developer's P.O.V., but it increases
the probability that someone's toolkit will be matched to the
problem in such a way that the bug is shallow to that
person.
So,
nihil sub sole novum (Eccl. 1:10 in the Vulgate): 'there
is nothing new under the sun'. The blogosphere's networked ability
to raise and address issues is the bazaar in action.