Saturday, January 28, 2012

Cathedral or Bazaar?

[a bazaar in Baghdad; image from flickr user micmol]

The other day we were spending a little time with Eric Raymond’s seminal essay “The Cathedraland the Bazaar”.  We do it periodically as a way of self-medicating against the annoying notion of emergent urbanistic ideologies bandied about in the halls of higher learning, and as a reality check for our own childish notions.  The 1997 essay about the design lessons learned from the Linux system is full of insightful, potent jewels that might inform new models of landscape practice.  More important, simply reading this nerdy computer man’s essay is an aesthetic experience:

Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

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 (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

Throughout the essay Raymond pays extra attention to the mechanics of the Linux system and his materialist analysis leads to surprising conclusions which are cleverly titled with captions such as “Release early, release often” and “On Managementand the Maginot Line”.  When diving in to details such as Linux kernel release mechanisms he bores down in on them, nerdily fumbling them around in his hands, poking it with sticks, and examining them under looking glasses.

My original formulation was that every problem ``will be transparent to somebody''.  [Linux creater] Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.''

In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena…  In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly 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.

But the problem with being clever and original in software design is that it gets to be a habit—you start reflexively making things cute and complicated when you should be keeping them robust and simple.

What strikes us is the emphasis on experimentation and execution.  Conceptualization is rightfully relegated to being the third wheel.  Within the field of landscape practice we would do well to take a page from this book and focus more on experimentation and execution and a little less on conceptualization.  Engagement with the medium itself has long been a fundamental aspect of landscape practice.  Some will object that there are very real barriers to entry with something like operating a backhoe or growing a forest, but the focus on conceptualization is most severe and striking within the academy, the very institutions that might marshal the resources needed to create opportunities to overcome these barriers.  And this is due to an almost singular focuson conceptualization (and representation).

Extending Raymond’s analysis, one could imagine a future where landscape education doesn’t occur solely in a building with a mac, a table saw, and an onsrud router as the only instruments with the surrounding landscape purely ornamental and maintain by crews.  Rather, a significant part of landscape education might allow for coir log installations, driving scale mockup sheet piling, propagating live stakes, and getting a heavy equipment operator’s license.  This leap would require us to wriggle free from the Eurocentric art-historical death grip, but it promises the chance to create more bizarre landscapes.
[there may always be a need for the cathedral, but that doesn't mean that we need to construct the whole academy around them]

No comments:

Post a Comment