###########################################################################
# Cathedral & Bazaar Notes                                                #
# Anuradha Weeraman, 18 April 2004                                        #
# Adapted from "The Cathedral & The Bazaar", Eric S. Raymond              #
# $Id: cathedral-n-bazaar.txt,v 1.1 2004/06/02 21:17:53 anuradha Exp $    #
###########################################################################

* Every good work of software starts by scratching a developer's
personal itch.

* Good programmers know what to write.  Great ones know what to rewrite
(and reuse).

* ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, ``The
Mythical Man-Month'', Chapter 11)

* If you have the right attitude, interesting problems will find you.

* When you lose interest in a program, your last duty to it is to hand
it off to a competent successor.

* Treating your users as co-developers is your least-hassle route to
rapid code improvement and effective debugging.

* Release early, release often.

* Release early.  Release often.  And listen to your customers.

* ``Given enough eyeballs, all bugs are shallow.'' -- Linus' Law

* Sociologists years ago discovered that the averaged opinion of a
mass of equally expert (or equally ignorant) observers is quite a bit
more reliable a predictor than that of a single randomly-chosen one of
the observers.  They called this the ``Delphi effect''.

* Smart data structures and dumb code works a lot better than the other
way around.

* If you treat your beta-testers as if they're your most valuable
resource, they will respond by becoming your most valuable resource.

* The next best thing to having good ideas is recognizing good ideas
from your users.  Sometimes the latter is better.

* Often, the most striking and innovative solutions come from realizing
that your concept of the problem was wrong.

* ``Perfection (in design) is achieved not when there is nothing more
to add, but rather when there is nothing more to take away.''
	-- Antoine de Saint-Exupery

* When writing gateway software of any kind, take pains to disturb the
data stream as little as possible -- and *never* throw away information
unless the recipient forces you to!

* When your language is nowhere near Turing-complete, syntactic sugar
can be your friend.

* A security system is only as secure as its secret. Beware of
pseudo-secrets.

* It's fairly clear that one cannot code from the ground up in bazaar
style.  One can test, debug and improve in bazaar style, but it would
be very hard to originate a project in bazaar mode.

*   In ``The Mythical Man-Month'', Fred Brooks observed that programmer
time is not fungible; adding developers to a late software project
makes it later.  He argued that the complexity and communication costs
of a project rise with the square of the number of developers, while
work done only rises linearly.  This claim has since become known as
``Brooks's Law'' and is widely regarded as a truism.  But if Brooks's
Law were the whole picture, Linux would be impossible.

* Provided the development coordinator has a medium at least as good
as the Internet, and knows how to lead without coercion, many heads are
inevitably better than one.

* Perhaps in the end the open-source culture will triumph not because
cooperation is morally right or software ``hoarding'' is morally wrong
(assuming you believe the latter, which neither Linus nor I do), but
simply because the closed-source world cannot win an evolutionary arms
race with open-source communities that can put orders of magnitude more
skilled time into a problem.

* One thing many people think the traditional mode buys you is somebody
to hold legally liable and potentially recover compensation from
if the project goes wrong.  But this is an illusion; most software
licenses are written to disclaim even warranty of merchantability, let
alone performance -- and cases of successful recovery for software
nonperformance are vanishingly rare.  Even if they were common,
feeling comforted by having somebody to sue would be missing the point.
You didn't want to be in a lawsuit; you wanted working software.

* Having a conventional management structure solely in order to motivate,
then, is probably good tactics but bad strategy; a short- term win,
but in the longer term a surer loss.

* ESR very nearly called the paper "The Cathedral and the Agora", the
latter term being the Greek for an open market or public meeting place.

* In Programing Pearls, the noted computer-science aphorist Jon Bentley
comments on Brooks's observation with ``If you plan to throw one away,
you will throw away two.''.

* John Hasler has suggested an interesting explanation for the fact that
duplication of effort doesn't seem to be a net drag on open- source
development. He proposes what I'll dub ``Hasler's Law'': the costs of
duplicated work tend to scale sub-qadratically with team size -- that
is, more slowly than the planning and management overhead that would be
needed to eliminate them.

This claim actually does not contradict Brooks's Law.  It may be the
case that total complexity overhead and vulnerability to bugs scales
with the square of team size, but that the costs from duplicated work
are nevertheless a special case that scales more slowly.  It's not hard
to develop plausible reasons for this, starting with the undoubted fact
that it is much easier to agree on functional boundaries between different
developers' code that will prevent duplication of effort than it is to
prevent the kinds of unplanned bad interactions across the whole system
that underly most bugs.

* When programmers are held both to an immutable feature list and a
fixed drop-dead date, quality goes out the window and there is likely
a colossal mess in the making.

* One way to do this is to fix the deadline but leave the feature list
flexible, allowing features to drop off if not completed by deadline.
This is essentially the strategy of the "stable" kernel branch.

* The other way to do this is to set a desired feature list and
deliver only when it is done.  This is essentially the strategy of the
"experimental" kernel branch.  De Marco and Lister cited research showing
that this scheduling policy ("wake me up when it's done") produces not
only the highest quality but, on average, shorter delivery times than
either "realistic" or "aggressive" scheduling.

* ``If you have four groups working on a compiler, you'll get a 4-pass
compiler''. -- Conway's Law

* ``True communication is possible only between equals, because inferiors
are more consistently rewarded for telling their superiors pleasant lies
than for telling the truth.'' -- SNAFU principle