neral 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].
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 unsucces
