Community, Communication, and the “Bazaar”

 As I read Eric S. Raymond’s “The Cathedral and the Bazaar,” I chuckled as I my eyes caught something bizarre-looking in my downloaded and printed version: the formats for the open quotes and closed quotes did not match each other.
 I found this humorous, because it brought me back to several years ago, when I was writing and editing for a chain of Boston-area weeklies. Lo and behold, I had to endure that very same software glitch. It infuriated me that something so basic in a publishing tool was so wrong. But alas, there was nothing that I, the tech ignoramus, could do about it; surely, there were greater minds working on this problem. But why, I wondered, was this software released with such a basic flaw?
I found some answers in Raymond’s thoughtful, honest, and down-to-earth piece. And he is a master at explaining concepts in a way that invites us non-techs into his world, thereby showing us that he practices what he preaches:  that building a community is key. Raymond makes a solid case for the “bazaar” approach to software development:  “Given enough eyeballs, all bugs are shallow.” If you properly cultivate users to become co-developers and offer lots of encouragement, he says, your users will diagnose problems and suggest fixes more quickly than any one person can if unaided.
 Point well taken.  A community of debuggers will devote infinitely more time to a debug effort than one person possibly could. Raymond readily admits that design, rather than debug, is his strongest skill. So why not have a community of eager folks complement his best assets? I can apply this to the publishing world, where some are great writers and lousy editors, while others are terrific at debugging others’ work but less adept at or interested in creating editorial work.  We really are co-dependent in producing a seamless product. I found myself wondering if that software bug that bugged me endlessly an editor would have been easily unearthed if the “babbling bazaar” method of software development had been a choice back then.
But I find myself hesitating a bit regarding the “release early, release often” part of Raymond’s open-software philosophy. Raymond said he used to believe that this was bad policy for “larger than trivial” projects, because early versions are almost by definition buggy and you don’t want to wear out the patience of users. He no longer believes that holds. The problem is, I have a tough time letting go of that original outlook. Perhaps that makes me too inflexible. But here’s how I look at it. The techies he attracts to do his debugging are a self-selected bunch who are part of a shared subculture, and so by nature have more patience for bugs than I, the end user non-techie.
 I, on the other hand, just want things to work when I need them to work and have no knowledge about how to fix them. There are lots of me out there, who would lose patience for Raymond’s world.  So while it’s great that great minds are putting their heads together, where does that leave us? That’s why I believe timing of release is still important if “the long tail” of the population – folks like me – is part of the equation.
Kudos to Raymond for recognizing that communication skills are vital to building the community he needs for creating a “bazaar” framework:  “In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing. Technical sizzle will go a long way towards accomplishing this, but it’s far from the whole story. The personality you project matters, too.”  Raymond’s secret sauce: at least a little skill at charming people.  Raymond says this should be obvious, but we all know from our past endurances of pointy-haired bosses (a la Dilbert) that it just isn’t so. He’d be wise to take this one on the road – to all levels of management in all sorts of organizational environments.  Raymond should teach a course in “egoboo,” his term for ego-boosting.
I wish that Tim O’Reilly had made his work as accessible on an equally important subject that sometimes overlapped with Raymond’s: “What is Web 2.0. Design Patterns and Business Models for the Next Generation.”  His piece seemed directed more at techies than a general audience, with several terms and references left unexplained.
  However, he did make some good observations that are easily grasped. “Great internet success stories don’t advertise their products,” O’Reilly says. Rather, their adoption is driven by “viral marketing,” that is, recommendations propagating directly from one user to another.  It was an integral part of Google’s success story, as John Battelle notes in his book, The Search. O’Reilly also notes that companies like Microsoft will have to shed “old patterns” if they want to compete with native 2.0 companies. As a Wall Street Journal post relates today, he’s not the only one with those thoughts.

In describing reaction to Microsoft’s pay cuts for third-party temps, one blogger was quoted as writing, “you’re working for a dinosaur. Word on the street is your brain-trust got raided by Google.”
Ah, winners and losers.  Only time will tell. And that time frame is getting smaller and smaller.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: