[Marxism] ESR's The Cathedral and the Bazaar - excerpts

Clay Claiborne clayclai at gmail.com
Fri Jan 3 12:06:37 MST 2014

This is undoubtedly ESR's best known work. It has been translate into 23
languages and should be required reading for all Marxists in the modern era.

    The Cathedral and the Bazaar

> Linux is subversive. Who would have thought even five years ago (1991)
> that a world-class operating system could coalesce as if by magic out
> of part-time hacking by several thousand developers scattered all over
> the planet, connected only by the tenuous strands of the Internet?
> Certainly not I. By the time Linux swam onto my radar screen in early
> 1993, I had already been involved in Unix and open-source development
> for ten years. I was one of the first GNU contributors in the
> mid-1980s. I had released a good deal of open-source software onto the
> net, developing or co-developing several programs (nethack, Emacs's VC
> and GUD modes, xlife, and others) that are still in wide use today. I
> thought I knew how it was done.
> 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 software (operating
> systems and really large tools like the Emacs programming editor)
> 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.
For my part, let me say that Linux convinced me that Marx was right
about the future stateless society. While I accepted the theory that the
state was required by class antagonisms and would thus wither away with
class differences, it remained hard to envision a modern high-tech
society functioning without some sort of state structure, but then I,
like ESR, could not envision a modern OS like Windows, which required
millions of lines of code from thousands of programmer, all of which had
to function together like clockwork, that wasn't constructed by a large
hierarchical organization assigning tasks  and co-ordinating efforts.
Linux showed me I was wrong. If something as complex as a modern OS
could be constructed without bosses, even under capitalism, then
certainly a future society could use the same methods to maintain and
develop without the state.

I think one of the reasons RMS efforts have failed to produce a Linux
equivalent is that he has always insisted on holding everything close
and under his control. Rather than disparaging the label "open source"
he would be better served by considering the importance of openness in
what he was trying to do. I doubt there is a single word on the FSF
website that he doesn't personally approve of.

> 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.
> The fact that this bazaar style seemed to work, and work well, came as
> a distinct shock. As I learned my way around, I worked hard not just
> at individual projects, but also at trying to understand why the Linux
> world not only didn't fly apart in confusion but seemed to go from
> strength to strength at a speed barely imaginable to cathedral-builders.
Note for below: EMACS was RMS's baby:
>     Release Early, Release Often
> Early and frequent releases are a critical part of the Linux
> development model. Most developers (including me) used to believe this
> was bad policy for larger than trivial projects, because early
> versions are almost by definition buggy versions and you don't want to
> wear out the patience of your users.
> This belief reinforced the general commitment to a cathedral-building
> style of development. If the overriding objective was for users to see
> as few bugs as possible, why then you'd only release a version every
> six months (or less often), and work like a dog on debugging between
> releases. The Emacs C core was developed this way. The Lisp library,
> in effect, was not---because there were active Lisp archives outside
> the FSF's control, where you could go to find new and development code
> versions independently of Emacs's release cycle [QR]
> <http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s14.html#QR>.
> The most important of these, the Ohio State Emacs Lisp archive,
> anticipated the spirit and many of the features of today's big Linux
> archives. But few of us really thought very hard about what we were
> doing, or about what the very existence of that archive suggested
> about problems in the FSF's cathedral-building development model. I
> made one serious attempt around 1992 to get a lot of the Ohio code
> formally merged into the official Emacs Lisp library. I ran into
> political trouble and was largely unsuccessful.
> But by a year later, as Linux became widely visible, it was clear that
> something different and much healthier was going on there. Linus's
> open development policy was the very opposite of cathedral-building.
> Linux's Internet archives were burgeoning, multiple distributions were
> being floated. And all of this was driven by an unheard-of frequency
> of core system releases.
You can see that the political differences between RMS and ESR predated
the question of "free software" vs "open source" by many years, as did
the difference between the FSF closely held model of development, vs.
the very open model that lead to the successful develop of an OS.

> Linus was directly aiming to maximize the number of person-hours
> thrown at debugging and development, even at the possible cost of
> instability in the code and user-base burnout if any serious bug
> proved intractable. Linus was behaving as though he believed something
> like this:
>     8. Given a large enough beta-tester and co-developer base, almost
>     every problem will be characterized quickly and the fix obvious to
>     someone.
> Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I
> dub this: ``Linus's Law''.
> In Linus's Law, I think, lies the core difference underlying the
> cathedral-builder and bazaar styles. 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 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.
These are a few excerpts and I hope it gives you the favor and teaches
you something about Linux. I advise you read the whole thing. One thing
I hope will be clear is that RMS's demand that the product of this labor
of thousands be called GNU/Linux is based on ego and little else, RMS
may have written much of the early code from which Linux sprung but
Linus led in the development of the methodology that made Linux what it
is today. That is the reason the community, not Linus, has chosen to
call it Linux, just as it is flaws in the FSF's methods that have caused
it to fail for 30 years to produce a usable kernel.

Another piece I high recommend is the  Halloween Documents
<http://www.opensource.org/halloween/>. A fun red. More than a decade
before Cheslie Manning or Ed Snowden, internal Microsoft workers [we
called the MicroSerfs] were leaking internal documents about MS plans to
derail Linux. If you don't already know this story, they will make for
some very interesting reading.

More information about the Marxism mailing list