It's been almost ten years since Eric Raymond presented his paper, "The Cathedral and the Bazaar" to the 1997 Linux Kongress. In that remarkable work Raymond compares two methods of software development. The "cathedral" approach requires a program to be "carefully crafted by individual wizards or small bands of
mages working in splendid isolation, with no beta to be released
before its time." To contrast this he "anatomizes" the approach taken by Linus Torvalds in developing the Linux OS:
Linus Torvalds's style of development - release early and often,
delegate everything you can, be open to the point of promiscuity -
came as a surprise. No quiet, reverent cathedral-building here -
rather, the Linux community seemed to resemble a great babbling bazaar
of differing agendas and approaches ... out of
which a coherent and stable system could seemingly emerge only by a
succession of miracles.
Raymond makes an astonishingly lucid and persuasive case for open source's raw, hurly-burly horsepower, which "not only did not fly
apart in confusion but seemed to go from strength to strength at a
speed barely imaginable to the cathedral builders."
The Cathedral and the Bazaar was required reading for any aspiring (or in my case, accidental) technology journalist back in the late '90s, and it's surely old hat for some of my readers. Yesterday I re-discovered it. I'm currently researching the third chapter of my book, in which I'll argue that crowdsourcing would never have emerged without the
methodology, philosophy and digital architecture of open
source software. To this end I re-read "Cathedral and the Bazaar," and was amazed by its prescience, and the degree to which it
anticipated the challenges of crowdsourcing in general and Assignment
Zero in particular.
In recent years the 10,000-odd words in Raymond's essay have been been boiled down to a single catchphrase: "Given enough eyeballs all bugs are shallow," which is to say, a diverse and large enough network can solve nearly any problem. It's the centerpiece of Raymond's essay—what he calls "Linus' Law—and with good reason. It explains why a crowd can be wiser than the smartest individual within it in a pithy six words.
The problem is that like a lot of catchphrases, "All bugs are shallow" has entered the realm of the shibboleth—a way to flash one's Web 2.0 credentials without displaying any actual understanding of the underlying concept. I worry that the crowdsourcing community—which as far as I can tell does not contain many programmers—is largely unaware of all the other valuable lessons Raymond has to teach us. Raymond proposes 19 lessons in his paper. Most of them apply equally to all of us—Pros and Ams alike—at AZ. Below I highlight the most salient lessons, and how they apply to our little open source journalism project:
Every Good Work of Software Starts By Scratching a Developer's Personal Itch
Replace "Work of Software" with "Crowdsourcing Project" and you've got the reasoning behind Assignment Zero. Why did we decide to focus on crowdsourcing? Because we had an itch: We wanted to know more about the phenomenon. But this lesson applies to our contributors as well. The greatest asset citizen journalists possess is passion. Find your itch on our Assignment Desk and scratch it.
Plan to Throw One Away. You Will Anyhow.
If you read yesterday's post by AZ Project Manager Steve Fox, you're already aware that Assignment Zero is—get this—a work in progress. But then, that's always been the plan. (See "Release Early, Release Often below). We launched AZ knowing we'd probably have to scrap the first iteration to make way for the second iteration. "There's the way we want things," Steve told me last night. "And there's reality." How will we reconcile the two? "If people are dissatisfied, then the best way to make them satisfied is to bring them into the process of helping fixing it." Well put, Steve. And thanks for the segue to the next lesson:
Given a large enough beta-tester and co-developer base, almost
every problem will be characterized quickly and the fix obvious to
someone.
Whence springs "Given enough eyeballs, all bugs are shallow." This has implications for you, our users and contributors. Assignment Zero isn't our project — It's your project, and it's important to recognize that, well, with great power comes great responsibility. We don't need peanut gallery criticisms, we need constructive advice, hands-on help and most of all, a little bit of patience and the understanding that this is how open source projects develop, through trial and error and a great deal of collaboration from everyone concerned. For our part
the implications are obvious: We should welcome participation from as wide—and
crucially, as diverse—a group of contributors as possible, in order to leverage the infinite range of experience and expertise out there.
Release early. Release often. This is what we learned this week. In Steve's words, we need to let everyone see each other's work, not hide it away until the day of the big release. In open source terms this means one doesn't try to write a perfect bit of
code before letting ones fellow programmers start hacking away at it.
For AZ, it means we should publish the results of our reporting and
writing as we compile it. This allows our contributors to avoid
conducting redundant research, but even more importantly, it allows for
cross-fertilization of ideas.
Good Programmers Know What to Write. Great Ones Know What to Rewrite (And Reuse).
As is obvious now, I'm arguing that Assignment Zero has more in common with an open source project than it does a newspaper or even conventional news site. We're not writing poetry, we're writing mash-up journalism. This doesn't mean we have a license to plagiarize. On the contrary, as with open source software, proper attribution is even more important because it takes the place of more liquid currencies like, you know, actual money. This does mean all of us should be casting the broadest net possible and incorporating good ideas wherever we find them.
Too Much Collaboration Can Be a Bad Thing.
Okay, you won't find this one word-for-word in Raymond's essay. I extrapolated it from his discussion of what sociologists once called the "Delphi Effect" and what we now call the Wisdom of the Crowds. To wit, in Raymond's words: "The average opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than that of a single randomly-chosen one of the observers." All well and good, but what's often misunderstood about the wisdom of the crowds is that it's the wisdom derives from a crowd of individuals thinking and working independently, not from a crowd thinking as a single unit, which leads to mobocracy. (See the jelly bean jar example in my post on the subject from a few days ago.)
What's this mean for AZ? Well, if all we wanted was the crowd to come to a consensus on crowdsourcing, we would have stopped after building our forums (we call it The Exchange.) But we have much more ambitious goals — We want you out there digging up research independently. Confer, by all means, but also be careful to come to your own conclusions. The wealth of the network lies in diversity and discourse, not from sermonizing amongst the choir. Besides, time on the forum is time you could be reporting!
It's been a long post, so congratulations to those of you who made it through. I hope you learned as much reading it as I did writing it. You'll learn much more by reading Raymond's original essay, which I love so much I'm going to link to it again.