OSB is not like Linux - or is it?
---------------------------------

This admittedly longish text was originally written as a note, meant to
mediate in a controversy about how to work together in OSB. The note
was welcomed by many, and it was suggested to make it available as
'mandatory reading' for new wizards. Well, here it is.

The text is slightly unusual as it starts quite abstractly and ends
quite emotionally (it also violates 'no long postings' guideline of
style :-), but I think the topic is important enough. You can also read
or ftp this text from the file /doc/intro/linuxosb.

   I will mention 'Linux', 'Apache' and 'GNU compiler'. If you know what
   these are, you can skip this paragraph, else read on. Linux is a free
   Unix operating system for PCs, Macs, Notebooks and other computers.
   Apache is a web server, i.e. the program which delivers the pages
   you look at with your webbrowser. The GNU compiler is a compiler
   for the C language.
   These three programs have a few things in common: they are very complex,
   they come with complete source code so everybody can modify them, and
   even though they were initiated by single persons, the bulk of the
   programs now incorporate the work of thousands of volunteers, and
   these programs are almost the best software you can get for their
   intended purposes.

The last weeks I read several papers which were concerned with the question
why projects like Linux, the Apache web server, or the GNU compiler are
so successful. The papers revealed some interesting insights, which
also shed some light onto OSB. I won't go into details (I can dig out the
URLs for the interested), but mention the main findings.

Common to all the mentioned projects is that everybody is not only
allowed, but even encouraged to participate, to add their own code and
ideas. Effectively, all the projects, or parts of the projects, have
no particular owner. All code can be changed by anybody, irregardless of
who wrote it in the first instance. Eric Raymond calls this 'egoless
programming' - the code is not written to boast ones ego, but to get
the project done.

Curiously, at the same time there is a strong notion of ownership.
Each mentioned project has one person (or a small core group) which are
acknowledged as 'owners'. They set the general direction, are the
final clearing instance in arguments and produce the 'official releases'.
How is this possible when everybody can change everything?

One reason is that these owners do not exercise their ownership. They
don't pass arbitrary judgements and rules onto the others, they freely
inform others about intentions and plans, and don't put themselves or their
ideas above the others. In short, they are the owners because the others
acknowledge them as owners, not because of some fixed hierarchy.

Of course there is a pitfall (isn't there always?): all people working
on the project must be willing to give up the direct egotistical satisfaction
you usually get from knowing that it's _your_ code doing this or that thing.
Allowing others to change _your_ piece of art is a very difficult change
of thinking. This even more for young programmers who are (justly!) proud
of everything they create - even if it's easy stuff for everybody else.

A lot of software projects fail even though their structure is like
that of the well-known projects. They fail because the participants
are unaware of the tricky issues of cooperation and ownership I outlined
above. They failed because the participants could not or did not want
to put away with the 'that-is-my-code-and-only-I-decide-what-to-do-with-it'
mindset. Even worse: the participants didn't trust each other and
implied at every change to their code that the others tried to steal it. 

You can see the connection to OSB. We too are working on a big software
project, bigger than any one person could handle alone. We too are able
to change everything we want to. But we too have pet parts, parts which
are in an informal way 'owned' by different people. Let us be conscious
about that.  

Courtesy demands that we acknowledge the various ownerships - document
changes, ask before we do big changes, and don't grief if an idea of ours
is rejected. But courtesy also demands that we don't hold 'our' code
sacrosanct, that we willingly accept the contributions of others even if
they deviate from our original planning or give a solution to a problem
we preferred to solve on our own.

Like Linux, Apache or GNU, OSB is based on mutual trust. Trust that
the others work with the wellfare of OSB in mind. If something is changed
in 'your' code in a way you don't like, remember that is was good intention
which motivated the change. Maybe it's a mistake, maybe a hitherto
hidden bug, maybe your own judgment is wrong on this particular subject.
Maybe it's just a misunderstanding. But it is never an act of disrespect,
even if at some moments you might feel different. Remember that.

Granted, it's easier to work in an environment where you can own what you
create and where nobody is allowed to modify your things. But if you look
at OSB you'll see that our approach already produced much better rooms
than NF ever had - even though we have fewer people and less time to spend.

OSB gives you the chance to put your name on the mud as a whole, instead
of just a little part. The only price you have to pay is that your name
won't be the only one on this placque of honor. A high price sometimes,
but believe me: it is worth it.

 -- Mateese, 26 April 1998