[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]








