OpenSource


* Einf├╝hrung * Installation * Paketmanager * Grundlagen * Shells * Entwicklung * KDE * Skriptsprachen * AWK * PHP * Perl * Apache * Veranstaltungen * Schulungen * B├╝cher * Netzwerk * OpenOffice * OpenSource * Samba

OpenSource


© <a href="http://www.fotolia.de/p/29003">Ljupco Smokovski</a> - FOTOLIA
Home
Geistiges Eigentum
Die Kathedrale und der Basar
Open Source und Kommunismus
Warum "Freie Software" besser ist als "Open Source"
Mit freundlicher Unterstützung von:

Linux-Kurse und Seminare Linux Kurse
Veranstalter des
Linux-Tag
am Bodensee
2007 und 2008

Kontakt
Haftung
Impressum
Problem Hilfe Startseite


Die Kathedrale und der Basar

 von Eric S. Raymond

Aus dem Amerikanischen von Reinhard Gantar

Diese ├ťbersetzung basiert auf der Fassung vom 8. August 1999


Ich untersuche das erfolgreiche Open Source-Projekt fetchmail, das ich willk├╝rlich als Test f├╝r einige ├╝berraschende Theorien ├╝ber Software-Entwicklung herausgegriffen habe, und die durch die Geschichte von Linux nahegelegt werden. Ich er├Ârtere diese Theorien unter dem Blickwinkel zweier grunds├Ątzlich verschiedener Entwicklungsarten. Das eine Modell ist das der "Kathedrale", das in der kommerziell orientierten Software-Welt ├╝berwiegt. Das zweite ist im Gegensatz dazu das des "Basars" und der Linux-Welt. Ich werde hier zeigen, da├č diese Modelle auf jeweils entgegengesetzten Annahmen ├╝ber die Natur des Debuggings von Software beruhen. Es folgt die These, da├č jeglicher Bug schnell gefunden wird, wenn sich nur genug Entwickler damit befassen - "Given enough eyeballs, all bugs are shallow" - was auf den in der Geschichte von Linux gemachten Erfahrungen beruht. Ich zeige Analogien zu anderen selbst-korrigierenden Systemen von egoistischen Vertretern und erforsche vor dem Abschlu├č noch einige Implikationen dieser Einsichten f├╝r die Zukunft der Software.

1. Die Kathedrale und der Basar

Linux ist subversiv. Wer h├Ątte auch vor nur f├╝nf Jahren (1991) gedacht, da├č sich ein Betriebssystem der Spitzenklasse wie durch Zauberei materialisieren k├Ânnte, geschaffen von Tausenden ├╝ber den ganzen Planeten verstreuten Nebenerwerbs-Hackern, die durch die eng verwobenen Str├Ąnge des Internets verbunden sind?
Ich sicher nicht. Zu dem Zeitpunkt, als Linux 1993 auf meinem Radarschirm auftauchte, hatte ich bereits zehn Jahre in der Unix- und Open Source-Entwicklung verbracht. Mitte der Achtziger war ich einer der ersten Beitragenden zu GNU. Ich hatte bereits umfangreiche Open Source-Software im Internet ver├Âffentlicht, die ich selbst entwickelt oder mitentwickelt hatte (nethack, Emacs VC und GUD modes, xlife und andere) und die heute noch viel verwendet wird. Ich dachte, ich w├╝├čte, wie es gemacht wird.
Dann stellte Linux alles in Frage, was ich zu wissen glaubte. Ich hatte das Unix-Evangelium der kleinen Tools, des rapid prototyping und der inkrementellen Verbesserung seit der ersten Stunde verbreitet.
 Ich glaubte aber auch, da├č es eine bestimmte kritische Komplexit├Ątsstufe gebe, ab der ein zentralisierterer Ansatz mit sehr genauer Vorausplanung erforderlich wird. Ich glaubte, da├č die wichtigste Software (Betriebssysteme und wirklich umfangreiche Tools wie Emacs) so gebaut werden m├╝├čten wie Kathedralen, sorgsam gemei├čelt von einzelnen Druiden oder kleinen Teams von Hohepriestern, die in totaler Abgeschiedenheit wirkten und keine unfertigen Beta-Freigaben ver├Âffentlichen d├╝rften.
Linus Torvalds' Entwicklungsstil auf der anderen Seite - mit seinen fr├╝hen und h├Ąufigen Freigaben, seinem Delegieren von allem, was nur irgendwie m├Âglich ist, und der an Promiskuit├Ąt grenzenden Offenheit - war eine echte ├ťberraschung. Es handelte sich nicht gerade um eine stille und ehrfurchtsvolle T├Ątigkeit, wie der Bau einer Kathedrale eine ist -- stattdessen schien die Linux-Gemeinde ein gro├čer, wild durcheinander plappernder Basar von verschiedenen Zielsetzungen und Ans├Ątzen zu sein (alles sehr treffend durch die Linux-Archivsites repr├Ąsentiert, die Beitr├Ąge von *jedem* nehmen), der ein koh├Ąrentes und stabiles System wohl nur durch eine Reihe von Wundern hervorbringen konnte.
Die Tatsache, da├č der Basar zu funktionieren schien, und zwar sehr gut zu funktionieren schien, war ein ausgesprochener Schock. W├Ąhrend ich lernte, mich in dieser neuen Umgebung zurechtzufinden, arbeitete ich nicht nur angestrengt an eigenen Projekten, sondern versuchte auch zu verstehen, warum die Linux-Welt sich nicht nur nicht einfach in v├Âlliger Konfusion aufl├Âste, sondern an Durchschlagskraft immer weiter zulegte und eine Produktivit├Ąt ausbildete, die f├╝r die Erbauer einer Software-Kathedrale kaum vorstellbar gewesen ist.
Mitte 1996 dachte ich, da├č mir ein genaueres Verst├Ąndnis d├Ąmmerte. Durch Zufall bekam ich eine ausgezeichnete Gelegenheit, meine Theorie zu testen, und zwar in Form eines Open Source-Projekts, das ich bewu├čt im Basar-Stil abwickeln konnte. Das tat ich dann auch -- und es wurde ein bedeutender Erfolg.
Dies ist die Geschichte dieses Projekts. Ich verwende es, um einige Aphorismen ├╝ber effektive Open Source-Entwicklung vorzustellen. Nicht alle davon erfuhr ich als erstes in der Linux-Welt, ich werde aber auf Beispiele aus der Linux-Welt zur├╝ckgreifen, um bestimmte Punkte zu illustrieren. Wenn ich damit richtig liege, werden sie helfen zu verstehen, warum gerade die Linux-Gemeinde zu so einem steten Quell guter Software geworden ist -- und vielleicht auch, wie Sie selbst produktiver werden k├Ânnen.

2. Post mu├č immer ankommen

Seit 1993 k├╝mmere ich mich um die technische Seite eines kleinen Gratis-ISP namens Chester County InterLink (CCIL) in West Chester in Pennsylvania (ich bin Mitbegr├╝nder von CCIL und schrieb unsere einzigartige Multiuser BBS-Software -- man kann sie sich durch einen telnet zu locke.ccil.org ansehen. Heute werden fast dreitausend Benutzer auf drei├čig Leitungen unterst├╝tzt). Der Job gestattete mir nicht nur den Zugriff auf CCILs 56K-Leitung , sondern machte ihn praktisch unbedingt notwendig!
Dementsprechend gew├Âhnte ich mich an einen ununterbrochenen Zugriff auf Internet e-Mail. Aus komplizierten Gr├╝nden war es sehr schwerig, SLIP f├╝r die Verbindung zwischen meiner Maschine zu Hause (snark.thyrsus.com) und CCIL tauglich zu machen. Als ich endlich Erfolg damit hatte, fand ich das periodische Telnetten zu locke.ccil.org bald l├Ąstig. Was ich wollte, war eine sofortige ├ťbermittlung meiner elektronischen Post zu meiner snark-Maschine und eine Benachrichtung des Eintreffens, um sie gleich mit meiner lokalen Software bearbeiten zu k├Ânnen.
Ein schlichtes Weiterreichen durch sendmail h├Ątte nicht funktioniert, da meine pers├Ânliche Maschine nicht immer am Netzwerk angeschlossen ist und keine statische IP-Adresse hat. Was ich brauchte, war ein Programm, das ├╝ber meine SLIP-Verbindung die e-Mail abholte und lokal verf├╝gbar machte. Ich wu├čte, da├č es derartige Software gab, und da├č die meiste davon ein einfaches Anwendungsprotokoll namens POP (Post Office Protocol) verwendete. Es gab nat├╝rlich bereits einen POP3-Server als Teil von locke's Betriebssystem BSD/OS.
Ich brauchte also einen POP3-Klienten. So ging ich hinaus ins Netz und fand einen. Tats├Ąchlich fand ich sogar drei oder vier. Einige Zeit lang verwendete ich pop-perl, vermi├čte aber ein f├╝r mich sehr plausibles Leistungsmerkmal -- die F├Ąhigkeit, die Adressen in abgeholter e-Mail umzuhacken, so da├č auch die Antworten darauf richtig weitergereicht w├╝rden.
Das Problem war folgendes. Nehmen wir an, jemand namens 'joe' mit einem Mail-Konto bei locke w├╝rde mir eine e-Mail schicken. Wenn ich dann die Mail zu mir auf meine snark-Maschine hole und dann versuche, darauf zu antworten, dann w├╝rde mein Mailer diese Antwort an einen nicht-existenten 'joe' auf snark schicken. Ein h├Ąndisches Erg├Ąnzen von "@ccil.org" wird schnell zu einer ernsthaften Plage.
Das war ganz offensichtlich eine M├╝he, die sich der Computer machen sollte, nicht ich. Aber keiner der existierenden POP-Klienten konnte das tun. Und das bringt uns zur ersten Lektion:

   1. Jede gute Software beginnt mit den pers├Ânlichen Sehns├╝chten eines Entwicklers.


Das h├Ątte vielleicht jedem sofort einleuchten sollen (schlie├člich gibt es das Sprichwort "Not macht erfinderisch" schon seit geraumer Zeit), aber viel zu oft haben Softwareentwickler ihre Tage mit der Arbeit an Programmen verbringen m├╝ssen, die sie weder gebraucht noch geliebt haben. Aber nicht in der Linux-Welt -- was vielleicht die ├╝berdurchschnittliche Qualit├Ąt der von der Linux-Gemeinde geschaffenen Software erkl├Ąrt.
Setzte ich mich also gleich hin und begann im Schaffensrausch einen brandneuen POP3-Klienten zu codieren, der mit den bereits bestehenden konkurrierte? Das kam nat├╝rlich nicht in Frage und war auch nicht n├Âtig. Ich erforschte sorgf├Ąltig die POP-Utilities, die ich zur Hand hatte und stellte mir die Frage: "Welcher davon kommt meinen Anforderungen am n├Ąchsten?" Denn was gilt, ist dies:
   2. Gute Programmierer wissen, welchen Code sie schreiben sollen. Gro├čartige Programmierer wissen, welchen Code sie umschreiben (und recyclen) k├Ânnen.

Obwohl ich nicht behaupte, ein gro├čartiger Programmierer zu sein, bem├╝he ich mich immer, einen zu imitieren. Ein wichtiger Charakterzug gro├čartiger Programmierer ist konstruktive Faulheit. Sie alle wissen, da├č man sehr gute Noten nicht durch sehr gro├čen Aufwand, sondern durch sehr gute Resultate bekommt -- und da├č es fast immer einfacher ist, bei einer guten Teill├Âsung anzufangen als ganz von vorne.
 Linus Torvalds zum Beispiel versuchte erst gar nicht, Linux ohne grundlegenden Code auf der gr├╝ne Wiese zu erstellen. Stattdessen borgte er Code und Ideen von Minix, einem Unix-├Ąhnlichen Betriebssystem f├╝r PC-Clones. Schlie├člich war aller Minix-Code durch neuentwickelten Code ersetzt oder komplett umgeschrieben -- aber solange er pr├Ąsent war, lieferte er ein Ger├╝st f├╝r den S├Ąugling, der schlie├člich zu Linux wurde.
Nach der gleichen Philosophie suchte ich nach einer bestehenden POP-Utility, die ausreichend gekonnt geschrieben war und als Grundlage f├╝r meine Weiterentwicklung dienen konnte.
Die Tradition der Weitergabe von Software der Unix-Welt war dem Recyclen von Code gegen├╝ber immer sehr wohlwollend und aufgeschlossen eingestellt (was auch der Grund daf├╝r ist, da├č das GNU-Projekt Unix als sein Basis-Betriebssystem gew├Ąhlt hat - und das trotz starker Vorbehalte gegen├╝ber Unix selbst). Die Linux-Welt hat diese Tradition bis fast an die Grenzen des technisch M├Âglichen weitergef├╝hrt und stellt Terabytes an offen gelegtem Sourcecode zur Verf├╝gung. Daher ist es in der Linux-Welt am wahrscheinlichsten, bei der Arbeit an eigenen Projekten auf ausreichend guten Source-Code zu sto├čen, als irgendwo sonst.
Bei meinem Projekt funktionierte es. Zusammen mit den schon vorher gefundenen Programmen hatte ich nach meiner zweiten Suche insgesamt neun Kandidaten -- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail und upop. Als erstes entschied ich mich f├╝r 'fetchpop' von Seung-Hong Oh. Ich f├╝gte meinen Code zum automatischen Umschreiben von Headern ein und nahm eine Reihe anderer Verbesserungen vor, die der Autor in seine Release 1.9 aufnahm.
Ein paar Wochen sp├Ąter aber stolperte ich ├╝ber den Code f├╝r 'popclient' von Carl Harris und fand heraus, da├č ich ein Problem hatte. Obwohl fetchpop ein paar gute und originelle Ideen implementierte (wie etwa seinen Daemon-Mode), konnte es nur POP3 bedienen und war auch sehr laienhaft geschrieben (Seung-Hong war damals ein brillanter, aber unerfahrener Programmierer und beides konnte man an fetchpop sehr gut erkennen). Carls Code war besser, sehr professionell und solide, aber dem Programm fehlten einige wichtige und knifflig zu implementierende Leistungsmerkmale, die fetchpop sehr wohl hatte (darunter auch die von mir geschriebenen).
W├╝rde es sich lohnen zu wechseln? Wenn ich wechselte, m├╝├čte ich meinen schon geschriebenen Code verwerfen und w├╝rde daf├╝r eine bessere Ausgangsbasis gewinnen.
Ein praktischer Anreiz daf├╝r war die Unterst├╝tzung mehrerer Protokolle. POP3 ist das ├╝blichste Protokoll f├╝r Post Office Server, aber nicht das einzige. Fetchpop und seine Mitbewerber konnten kein POP2, RPOP oder APOP, und ich hatte bereits mit vage Pl├Ąne f├╝r einen Zusatz f├╝r IMAP (Internet Message Access Protocol, das neueste und m├Ąchtigste Post Office-Protokoll), das ich nur so zum Spa├č implementieren wollte.
Es gab aber noch einen - theoretischeren - Anreiz, einen Wechsel zu popclient zu erw├Ągen. Das hatte mit etwas zu tun, das ich schon lange vor Linux gelernt hatte.

   3. "Plane eines f├╝r den Papierkorb; auf die eine oder andere Art machst du das sowieso." (Fred Brooks, "Vom      Mythos des Mann-Monats", Kapitel 11, in Addison-Wesleys ├ťbersetzung von Arne Sch├Ąpers und Armin Hopp).

Anders gesagt: oft versteht man das Problem gar nicht richtig, bevor man nicht die erste Implementation einer L├Âsung wenigstens halbwegs vollendet hat. Beim zweiten Mal hat man aber vielleicht schon genug gelernt, um es dann richtig zu machen. Wenn man also eine gute Implementation w├╝nscht, sollte man sich darauf gefa├čt machen, wenigstens einmal ganz von vorne anzufangen [JB].
Nun, so sagte ich mir, meine Verbesserungen an fetchpop waren mein erster Versuch. Auf zu popclient.
Nachdem ich am 25. Juni 1996 meine ersten Patches f├╝r popclient an Carl Harris geschickt hatte, fand ich heraus, da├č er schon einige Zeit vorher jedes Interesse an seinem Programm verloren hatte. Der Code war ein wenig verstaubt und hatte einige geringf├╝gige Fehler h├Ąngten heraus. Ich mu├čte viele ├änderungen machen und wir kamen schnell ├╝berein, da├č es das logischste w├Ąre, wenn ich das Programm einfach ├╝bernehmen w├╝rde.
Ohne da├č ich es wirklich gemerkt hatte, war das Projekt eskaliert. Ich dachte nicht mehr einfach ├╝ber kleine Patches f├╝r einen bestehenden POP-Klienten nach. Ich ├╝bernahm die Wartung eines ganzen Programmpakets und in meinem Kopf turnten Ideen, von denen ich wu├čte, da├č sie zu weitreichenden Umstellungen f├╝hren w├╝rden.
In einer Software-Kultur, die zur gemeinsamen Nutzung von Code ermuntert, ist das der nat├╝rliche Weg, auf dem sich Projekte weiterentwickeln. Ich tat nichts anderes, als folgende Regel zu leben:

   4. Mit der richtigen Einstellung werden interessante Probleme dich finden.

Aber Carl Harris Haltung war sogar noch wichtiger. Er verstand, da├č

   5. Sobald man das Interessen an seinem Programm verliert, ist es die letzte Pflicht, es einem kompetenten Nachfolger zu ├╝berlassen.

Ohne es jemals diskutiert haben zu m├╝ssen, wu├čten Carl und ich, da├č wir eine gemeinsame Vorstellung von der besten L├Âsung hatten. Die einzige Frage war f├╝r jeden von uns beiden, ob ich meine Qualifikation daf├╝r beweisen k├Ânnte. Sobald ich das getan hatte, handelte er gro├čz├╝gig und gelassen. Ich hoffe, da├č ich es auch so gut machen werde, sobald die Zeit gekommen ist.

3. Von der Wichtigkeit, Benutzer zu haben

Und so erbte ich popclient. Ebenso wichtig war, da├č ich popclients Benutzerstamm erbte. Benutzer sind etwas wunderbares, und nicht nur, weil sie deutlich vor Augen ef├╝hren, da├č man einem Bedarf nachkommt und etwas richtig gemacht hat. Gut kultiviert, k├Ânnen sie zu Mit-Entwicklern werden.
Eine weitere St├Ąrke der Unix-Tradition, die von Linux unbek├╝mmert bis auf die Spitze getrieben wird, ist, da├č viele Benutzer gleichzeitig auch Hacker sind. Da der Quellcode verf├╝gbar ist, k├Ânnen sie zu sehr effektiven Hackern werden. Das f├Ârdert das prompte Entfernen von Bugs sehr. Mit ein bi├čchen Ermunterung werden Ihre Anwender Probleme diagnostizieren, entsprechende ├änderungen vorschlagen und bei der Verbesserung des Codes in einer Weise mitwirken, die Sie alleine nie zustande bringen k├Ânnten.

   6. Die Anwender als Mit-Entwickler zu sehen ist der Weg zu schnellen Verbesserungen und Fehlerbehebungen, der die geringsten Umst├Ąnde macht.

Die Durchschlagskraft dieser Erscheinung untersch├Ątzt man leicht. Tats├Ąchlich ist es so, da├č so gut wie alle von uns in der Open Source-Welt drastisch untersch├Ątzt haben, wie gut diese Kraft mit der Anzahl der Anwender und gegen die Systemkomplexit├Ąt skaliert, bis Linus Torvalds uns darauf hingewiesen und es demonstriert hat.
Und tats├Ąchlich denke ich, da├č Linus' cleverster und ausschlaggebendster Hack nicht der Linux-Kernel selbst war, sondern die Erfindung des Linux-Entwicklungsmodells. Als ich diese Meinung einmal in seiner Gegenwart ├Ąu├čerte, grinste er und wiederholte etwas, das er schon oft gesagt hatte: "Ich bin ein sehr fauler Mensch, der sich gerne mit fremden Federn schm├╝ckt und anderer Leute Lorbeeren erntet." Ein echtes Faultier; oder, wie der Science Fiction-Autor Robert Heinlein es einmal f├╝r eine seiner Figuren formulierte: zu faul, um zu versagen.
Im R├╝ckblick f├Ąllt einem ein Vorl├Ąufer der Methode und des Erfolges von Linux ein -- die Entwicklung der GNU Emacs Lisp-Bibliothek und Lisp Code-Archive. Im Gegensatz zum Stil der Kathedrale, in dem der Emacs C-Kern und die meisten anderen FSF-Tools entwickelt wurden, war die Evolution des Lisp-Codepools sehr flie├čend und hatte die Anwender als ihre treibende Kraft. Ideen und Prototypen wurden oft drei- oder viermal umgeschrieben, bevor sie ihre endg├╝ltige Form bekamen. Und lose verbundene Zusammenarbeit ├╝ber das Internet - a la Linux - gab es sehr oft.
Tats├Ąchlich war mein erfolgreichster einzelner Hack vor fetchmail wahrscheinlich der Emacs VC mode, eine Linux-├Ąhnliche Zusammenarbeit ├╝ber e-Mail mit drei anderen Leuten, von denen ich nur einen (Richard Stallman, Autor von Emacs und Gr├╝nder der FSF) bis heute getroffen habe. Es war ein Front End f├╝r SCCS, RCS und sp├Ąter CVS f├╝r Emacs, das Operationen zur Versionskontrolle "auf Knopfdruck" erm├Âglichte. Es entwickelte sich aus einem winzigen, groben sccs.el-Mode, den jemand anderer geschrieben hatte. Die Entwicklung von VC wurde ein Erfolg, weil - anders als Emacs selbst - der Emacs Lisp-Code die einzelnen Generationen der Release/Test/Verbesserung sehr schnell durchlief.

4. Fr├╝h freigeben, oft freigeben

Fr├╝he und h├Ąufige Freigaben sind ein wichtiger Bestandteil des Linux-Entwicklungsmodells. Die meisten Entwickler (darunter auch ich) glaubten fr├╝her, da├č das eine schlechte Politik f├╝r nicht-triviale Projekte w├Ąre, weil fr├╝he Versionen fast per Definition viele Bugs haben und man ja nicht die Geduld seiner Anwender ├╝berstrapazieren will.
Diese Auffassung verst├Ąrkte das allgemeine Festhalten an einem kathedralenartigen Stil bei der Entwicklung. Wenn die erste Zielsetzung war, da├č Benutzer so wenige Bugs wie m├Âglich sehen sollten, warum dann nur alle sechs Monate (oder noch weniger h├Ąufig) eine Release durchf├╝hren und wie ein Pferd am Debugging schuften? Der Emacs C-Kern wurde in dieser Weise entwickelt. Bei der Lisp-Bibliothek war das anders -- da es beliebte Lisp-Archive au├čerhalb der Kontrolle der FSF gab, konnte jeder neuesten und noch in Entwicklung befindlichen Code finden, der von Emacs' Freigabezyklus unabh├Ąngig war [QR].
Das wichtigste dieser Archive, das Ohio State elisp Archive, nahm die Philosophie und viele der Merkmale der heutigen gro├čen Linux-Archive vorweg. Aber wenige von uns dachten sehr angestrengt dar├╝ber nach, was dort eigentlich vorging oder was die blo├če Existenz dieser Archive f├╝r die Probleme der FSF mit dem Kathedralenmodell bedeuten k├Ânnte. Ich unternahm um 1992 herum einen ernsthaften Versuch, einen Gro├čteil des Ohio-Codes formal mit der offiziellen Emacs Lisp-Bibliothek zu verschmelzen. Ich bekam politische Probleme und war nicht sehr erfolgreich.
Aber nur ein Jahr sp├Ąter, als Linux bereits einige Breitenwirkung entfaltet hatte, war klar, da├č dort etwas anderes und viel ges├╝nderes vorging. Linus' Politik der f├╝r alle offenen Entwicklung war das exakte Gegenteil des Kathedralen-Stils. Die Sunsite- (heute Metalab) und tsx-11-Archive boomten, mehrere Distributionen wurden ver├Âffentlicht. Und all das wurde durch eine unerh├Ârte Frequenz von Kernsystemfreigaben angetrieben.
Linus behandelte Anwender als Mit-Entwickler, und das in der effektivsten nur m├Âglichen Weise.

   7. Fr├╝h freigeben. Oft freigeben. Seinen Anwendern zuh├Âren.

Linus' Innovation war nicht so sehr, da├č er es so machte (das war ja schon seit langer Zeit so die Tradition in der Welt von Unix), sondern bestand darin, es bis zu einer Intensit├Ąt hin zu betreiben, die der Komplexit├Ąt seines Unternehmens angemessen war. In jenen fr├╝hen Tagen (um 1991) war es f├╝r ihn nicht ungew├Âhnlich, mehr als einen neuen Kernel pro Tag freizugeben. Da er seinen Stamm von Mit-Entwicklern gut kultiviert hatte und das Internet weit ausgiebiger f├╝r die Zusammenarbeit nutzte als irgendjemand sonst, funktionierte es auch.
Aber wie funktionierte es? Und war es eine Methode, die ich nachahmen konnte oder beruhte sie auf einem einzigartigen Talent von Linus Torvalds?
Das glaubte ich nicht. Sicher, Linus ist ein verdammt guter Hacker (wie viele von uns k├Ânnten einen ganzen Betriebssystemkernel mit Produktqualit├Ąt bauen?). Aber an Linux war nichts, was einen atemberaubenden Quantensprung dargestellt h├Ątte. Linus ist kein (oder wenigstens noch kein) genialer Innovator wie zum Beispiel Richard Stallman oder James Gosling (NeWS und Java) welche sind. Stattdessen erscheint er mir als ein eminent begabter Ingenieur, der mit einem sechsten Sinn f├╝r das Vermeiden von Programmierfehlern und Entwicklungssackgassen und mit einem wirklichen Talent f├╝r das Auffinden des Wegs des geringsten Aufwandes ausgestattet ist. Das ganze Design von Linux atmet diese Qualit├Ąten und spiegelt Linus' grunds├Ątzlich konservativen und vereinfachenden Entwicklungsansatz wider.
Wenn also rasch aufeinanderfolgende Releases und die kompromi├člose Nutzung des Internets nicht zuf├Ąllig, sondern integraler Bestandteil von Linus' Ingenieurstalent und seiner profunden Einsicht in den Weg des geringsten Aufwandes waren, was maximierte er dann? Was war sein Beitrag zum Code schaffenden Ameisenhaufen?
In dieser Weise gestellt, beantwortet sich die Frage von selbst. Linus stimulierte und belohnte seine Hacker/Anwender ununterbrochen -- stimulierte durch die Aussicht auf Ego-pflegende Urheberschaft und Anteil an der Bewegung, belohnte durch Vorzeigen st├Ąndiger (sogar t├Ąglicher) Verbesserung des gro├čen Werks.
Linus zielte direkt auf die Maximierung der Anzahl der Mannstunden, die f├╝r das Debugging und die Entwicklung aufgewendet wurden, und lie├č es sogar darauf ankommen, da├č sich m├Âglicherweise Instabilit├Ąten in den Code schleichen und die Benutzerbasis ausgebrannt werden konnte, falls sich irgendein Bug als unbehebbar herausstellen sollte. Linus verhielt sich, als w├╝rde er ungef├Ąhr an folgendes glauben:

   8. Wenn man einen ausreichend gro├čen Stamm an Betatestern und Mit-Entwicklern hat, wird jedes Problem schnell identifiziert und die L├Âsung jedem offensichtlich sein.
.
Oder, salopper ausgedr├╝ckt: "Alle Bugs sind trivial, wenn man nur gen├╝gend Entwickler hat" ("Given enough eyeballs, all bugs are shallow"). Ich nenne das "Linus' Gesetz".
Meine urspr├╝ngliche Formulierung war, da├č jedes Problem wenigstens f├╝r "irgend jemanden offensichtlich sein wird". Linus wendete ein, da├č die Person, die das Problem versteht und behebt, nicht notwendigerweise oder nicht einmal ├╝blicherweise dieselbe ist, die das Problem als erstes charakterisiert hat. "Jemand entdeckt das Problem", so Linus, "und jemand anderer versteht es. Und ich unterschreibe jederzeit, da├č das Auffinden der schwierigere Teil davon ist." Der springende Punkt hier ist aber, da├č beides in der Regel sehr schnell passiert.
Hier haben wir, so denke ich, den grundlegenden Unterschied zwischen den Erbauern einer Kathedrale und dem Stil des Basars. Nach Auffassung der Erbauer der Kathedrale sind Programmierfehler und Entwicklungsprobleme knifflige, tiefgehende und heimt├╝ckische Erscheinungen. Es dauert Monate der Analyse durch eine entschlossene Elite, um Zuversicht in die Fehlerfreiheit des Codes zu bilden. Daher die langen Intervalle zwischen den Freigaben und die langen Gesichter, wenn eine langerwartete Release nicht fehlerfrei ist.
Die Auffassung hinter dem Basarstil ist eine ganz andere. Man geht davon aus, da├č Bugs ein sehr triviales Ph├Ąnomen sind -- oder wenigstens eines, das sehr schnell trivial werden kann, wenn es tausend begeisterten Mit-Entwicklern ausgesetzt wird, die nach jeder neuen Release darauf herumtrampeln. Dementsprechend f├╝hrt man sehr oft Freigaben durch, um so zu mehr Korrekturen zu kommen, und ein n├╝tzlicher Nebeneffekt ist, da├č man weniger zu verlieren hat, sollte gelegentlich eine besonders verungl├╝ckte zur T├╝r hinausgelangen.
Das ist alles. Das ist genug. Wenn "Linus' Gesetz" falsch ist, dann h├Ątte jedes System, das so komplex ist wie der Linux-Kernel und das von so vielen H├Ąnden ├╝berarbeitet wird, ab irgendeinem Zeitpunkt unter dem Gewicht unvorhergesehener und sch├Ądlicher Interaktionen zusammenbrechen m├╝ssen -- und was anderes sind unentdeckte, "tiefe" Bugs? Wenn Linus' Gesetz aber stichhaltig ist, dann reicht es aus, um Linux' relative Fehlerfreiheit zu erkl├Ąren und auch, da├č es monatelang oder sogar jahrelang ununterbrochen laufen kann.
Vielleicht sollte das ja gar keine so gro├če ├ťberraschung sein. Soziologen haben schon vor Jahren herausgefunden, da├č die gemittelte Meinung einer Masse von gleich kompetenten (oder gleich dummen) Beobachtern etwas zuverl├Ąssigere Vorhersagen macht als die eines einzelnen willk├╝rlich herausgepickten Beobachters. Sie nennen das den "Delphi-Effekt". Es scheint, da├č es das ist, was Linus gezeigt hat: Diese Erscheinung l├Ą├čt sich sogar auf das Debuggen eines Betriebssystems anwenden -- der Delphi-Effekt kann sogar die Komplexit├Ąt eines Entwicklungsprojektes z├Ąhmen, sogar wenn sie so hoch ist wie die f├╝r einen OS-Kernel.
Ein spezielles und dem Delphi-Effekt sehr f├Ârderliches Merkmal der Situation, in der sich Linux befindet, ist der Umstand, da├č die Teilnehmer an einem Projekt sich praktisch selbst ausw├Ąhlen. Einer der Teilnehmer der ersten Stunde wies darauf hin, da├č die Beitr├Ąge nicht einfach von irgendwelchen Freiwilligen kommen, sondern von Menschen, die ausreichend an der Software interessiert sind, um ihre Funktionsweise und Aufbau zu erforschen, L├Âsungen f├╝r vorgefundene Probleme zu finden und dann tats├Ąchlich eine halbwegs brauchbare Verbesserung zu entwickeln. Jeder, der alle diese Filter durchlaufen hat, wird sehr wahrscheinlich f├Ąhig sein, einen echten Nutzen zu stiften.
Meinem Freund Jeff Dutky <dutky@warm.umd.edu> verdanke ich den Hinweis, da├č Linus' Gesetz auch zu "Debugging l├Ą├čt sich parallelisieren" umformuliert werden kann. Jeffs Beobachtung ist, da├č obwohl Debugging vom Debuggenden wenigstens ein bi├čchen Kommunikation mit einem koordinierenden Entwickler erfordert, es doch keine bedeutende Koordination der Debuggenden untereinander notwendig macht. Daher ist der Gesamtaufwand nicht anf├Ąllig f├╝r das quadratische Wachstum der Komplexit├Ąt und Managementkosten, die das Mehr an Entwicklern problematisch macht.
In der Praxis ist der theoretisch m├Âgliche, doppelte Aufwand durch einander ├╝berlappende Arbeit von debuggenden Entwicklern in der Linux-Welt fast gar kein Thema. Ein Effekt des "fr&uhmlh freigeben, oft freigeben" ist die rasche Weitergabe und das rasche R├╝ckspeisen von Verbesserungen, was solche ├ťberlappungen minimiert.
Mehr Anwender finden mehr Bugs, weil das Mehr an Benutzern auch ein Mehr an M├Âglichkeiten bedeutet, das Programm zu verwenden und zu belasten. Dieser Effekt wird noch verst├Ąrkt, wenn die Benutzer gleichzeitig Mit-Entwickler sind. Jeder hat individuelle Ans├Ątze, Auffassungen und analytische Werkzeuge, wenn es um die Betrachtung eines Problems geht. Der "Delphi-Effekt" scheint wegen eben dieser Vielf├Ąltigkeit gut zu funktionieren. Im speziellen Kontext des Debuggens vermindert so eine breite Palette auch noch das Duplizieren von Aufwand.
Mit anderen Worten, ein Mehr an Betatestern mag die Kniffeligkeit des augenblicklich "tiefstsitzenden" Bugs vom Standpunkt des Entwicklers aus nicht reduzieren, aber das Mehr erh├Âht die Wahrscheinlichkeit, da├č irgend jemandes Methoden an das Problem derma├čen gut angepa├čt sind, um dieser Person trivial zu erscheinen.
Aber auch Linus will nicht alles auf eine Karte setzen. F├╝r den Fall, da├č es tats├Ąchlich schwer zu behebenden Fehlern gibt, sind die Versionen des Linux-Kernels so numeriert, da├č potentielle Benutzer die Wahl haben, entweder die letzte offiziell "stabile" Version zu verwenden, oder aber an die vorderste Front der Entwicklung zu gehen und f├╝r neue Features das Risiko von Fehlern einzugehen. Diese Taktik wird von den meisten Linux-Hackern offiziell noch nicht imitiert -- vielleicht sollten sie das aber tun, denn eine Auswahl zu haben, macht jede der beiden M├Âglichkeiten f├╝r sich attraktiver.

5. Wann ist eine Rose keine Rose?

Nach dem Befassen mit Linus' Verhalten und dem Entwickeln einer Theorie dar├╝ber, warum es so erfolgreich ist, traf ich eine bewu├čte Entscheidung, um diese Theorie an meinem neuen (und zugebenerma├čen weniger komplexen und weniger ehrgeizigen) Projekt zu testen.
Das erste, was ich aber machte, war, popclient zu vereinfachen und zu reorganisieren. Carl Harris' Implementation war robust und solide, zeigte aber eine Art von unn├Âtiger Kompliziertheit, die f├╝r viele C-Programmierer charakteristisch ist. F├╝r ihn war der Code das Zentrale, und die Datenstrukturen waren die Unterst├╝tzung f├╝r den Code. Das f├╝hrte zu sehr sch├Ân gestaltetem Code, aber zu sehr improvisierten und unansehnlichen Datenstrukturen (wenigstens nach den hohen Standards dieses alten LISP-Hackers).
Neben dieser Verbesserung des Designs hatte ich aber noch einen anderen Nutzen im Auge, als ich den Code umschrieb. Die erste tiefgreifende Umstellung war, da├č ich Unterst├╝tzung f├╝r IMAP einbaute. Ich schrieb die Protokoll-Automaten in einen generischen Treiber plus drei Tabellen mit Methoden um (jeweils eine f├╝r POP2, POP3 und IMAP). Diese und die vorhergehenden ├änderungen illustrieren ein allgemeines Prinzip, das Programmierer im Auge behalten sollten, speziell bei Sprachen, die dynamisches Typisieren nicht von Haus aus unterst├╝tzen:

   9. Smarte Datenstrukturen und dummer Code funktionieren viel besser als umgekehrt.

Brooks, Kapitel 9: "Also zeige mir Deinen [Code], aber verh├╝lle Deine [Datenstrukturen], und ich werde auf ewig im Dunkeln tappen. Zeige mir aber Deine [Datenstrukturen] und ich werde Deinen [Code] gar nicht brauchen, denn ich wei├č, wie er aussieht."
Eigentlich redete er von "Flu├čdiagrammen" und "Tabellen", aber unter Beachtung der drei├čig Jahre, die seither vergangen sind, ist die kleine Anpassung zul├Ąssig.
Zu diesem Zeitpunkt (Anfang September 1996, sechs Wochen nach der Stunde 0 des Projekts), dachte ich, da├č eine Namens├Ąnderung angebracht sei -- immerhin war das Programm kein reiner POP-Klient mehr. Ich z├Âgerte aber, weil es noch keine wirklich neuen Erweiterungen im Design gab. Meine Fassung von popclient mu├čte erst eine eigene Identit├Ąt entwickeln.
Das ├Ąnderte sich aber, und zwar radikal, als fetchmail lernte, wie man abgeholte Mail an das SMTP-Port weiterreicht. Ich werde das gleich n├Ąher erl├Ąutern, vorher aber noch folgendes. Ich habe meine Entscheidung schon erw├Ąhnt, dieses Projekt als Test f├╝r meine Hypothese zu verwenden, die ich mir ├╝ber Linus Torvalds' Erfolg gebildet hatte. Was genau bedeutet das? Die Frage ist berechtigt, hier also, was ich tat:
  1. Ich ver├Âffentlichte fr├╝h und h├Ąufig Freigaben (fast immer wenigstens alle zehn Tage; w├Ąhrend der Zeiten intensiver Entwicklung eine pro Tag).I
  2. Ich f├╝gte meiner wachsenden Beta-Liste jeden hinzu, der mich zu fetchmail kontaktierte.
  3. Ich verschickte ausf├╝hrliche und in lockerem Tonfall gehaltene Ank├╝ndigungen, wann immer ich eine Freigabe machte, und ermunterte meine Leute, am Proze├č teilzuhaben.
  4. Ich h├Ârte auf meine Betatester und befragte sie regelm├Ą├čig zu Design-Entscheidungen und lobte sie wann immer sie Patches oder Anregungen lieferten.
Diese simplen Ma├čnahmen zahlten sich unmittelbar aus. Vom Anfang des Projekts an bekam ich Bugreports von einer Qualit├Ąt, f├╝r die die meisten Entwickler alles und ihren linken Arm hergeben w├╝rden; oft waren auch gute Korrekturen beigelegt. Ich bekam konstruktive Kritik zu h├Âren, Fanpost und wohldurchdachte Anregungen f├╝r neue Features. Das f├╝hrt uns zu:

   10. Wenn man seine Betatester wie die wertvollste Ressource behandelt, werden sie als Reaktion darauf zur wertvollsten Ressource werden.

Eine interessante Ma├čnhhme hinter fetchmails Erfolg ist die schiere Gr├Â├če der Beta-Liste, die fetchmail-friends. Im Augenblick der Abfassung dieses Textes enth├Ąlt sie 249 Mitglieder und w├Ąchst jede Woche um zwei oder drei.
Tats├Ąchlich ist die Liste zum Zeitpunkt der ├ťberarbeitung im May 1997 von einem Zenit von 300 wieder geschrumpft, und das aus einem interessanten Grund. Mehrere Leute haben mich gebeten, sie von der Liste zu nehmen, weil fetchmail so gut funktioniert, da├č es f├╝r sie keine Veranlassung mehr gibt, am Gedankenaustausch teilzunehmen! Dies ist vielleicht ein f├╝r reife Basar-artige Projekte normaler Lebensabschnitt.

6. Aus popclient wird fetchmail

Der wirkliche Wendepunkt im Projekt kam, als Harry Hochheiser mir seinen von fetchmail unabh├Ąngigen Code f├╝r das Weiterreichen von Mail an das SMTP-Port der Klientenmaschine schickte. Ich erkannte fast augenblicklich, da├č eine zuverl├Ąssige Implementation dieses Leistungsmerkmals alle anderen Modi der Zustellung fast ├╝berfl├╝ssig machen w├╝rde.
Viele Wochen lang hatte ich an fetchmail und an einer kleinen Verbesserung nach der anderen gebastelt und hatte dabei den Eindruck, da├č das Schnittstellen-Design zwar leicht zu handhaben, aber nicht ganz sauber durchdacht sei -- ohne Eleganz und mit zu vielen geringf├╝gigen Optionen, die ├╝berall heraush├Ąngten. Die Optionen f├╝r das Umleiten von abgeholter Mail in einer Mailbox-Datei oder zur Standardausgabe war mir ein besonderer Dorn im Auge, ich konnte aber nicht herausfinden, warum.
Als ich mir die Sache mit dem SMTP-Forwarding ├╝berlegte, erkannte ich das Problem. Popclient versuchte zu viele Dinge auf einmal. Er wurde entworfen und gebaut, um sowohl als Mail Transport Agent (MTA) als auch als Local Mail Delivery Agent (MDA) aufzutreten. SMTP-Forwarding w├╝rde ihn aus dem MDA-Gesch├Ąft hinausbugsieren und ihn zu einem reinen MTA machen, der Mail f├╝r die lokale Zustellung an andere Programme weiterreicht -- so wie sendmail das tut.
Warum eigentlich, so meine selbstgestellte Frage, sollte ich mich mit der ganzen Komplexit├Ąt der Konfiguration eines Mail Delivery Agent plagen oder lock-and-append f├╝r eine Mailbox aufbauen, wenn doch Port 25 fast garantiert auf jeder Plattform existiert, die TCP/IP unterst├╝tzt? Speziell wenn dies bedeutete, da├č die abgeholte Mail garantiert wie gew├Âhnliche sender-initiated SMTP-Mail aussehen w├╝rde - was es eigentlich ist, was wir wirklich wollen.
Hier kann man einige Lektionen lernen. Die erste: Diese Idee mit dem Weiterreichen von SMTP-Mail war die lohnendste Einzelleistung, in deren Genu├č ich durch bewu├čtes Nachahmen von Linus' Methoden kam. Diese gl├Ąnzende Idee kam von einem Benutzer -- alles, was ich tun mu├čte war, deren Auswirkungen zu verstehen.

   11. Das zweitbeste nach eigenen guten Ideen ist das Erkennen von guten Ideen von Benutzern. Manchmal ist letzteres sogar das bessere.

Paradoxerweise werden Sie schnell herausfinden, da├č, wenn Sie total selbstlos die ganze Wahrheit dar├╝ber offenbaren, wieviel Sie anderen Menschen verdanken, Sie die ganze Welt behandeln wird, als h├Ątten Sie jede einzelne Erfindung h├Âchstpers├Ânlich gemacht und w├╝rden einfach nur die nat├╝rliche Bescheidenheit des wahren Genies zeigen. Wir haben alle gesehen, wie gut das f├╝r Linus funktionierte!
(Als ich auf der perl-Konferenz im August 1997 meine Rede hielt, sa├č Larry Wall in der ersten Reihe. Als ich zur eben aufgeschriebenen Zeile kam, ereiferte er sich im gespielten Tonfall eines Predigers: "Verk├╝nde es, Bruder, verk├╝nde es!". Das ganze Publikum lachte, denn jeder wu├čte, da├č sie auch f├╝r den Erfinder von perl funktioniert hatte.)
Nach einigen wenigen Wochen in diesem Geiste begann ich in den Genu├č von ├Ąhnlichem Lob zu kommen -- nicht nur von Benutzern, sondern auch von Leuten, die von meinem Projekt erfahren hatten. Ich habe einige von den e-Mails aufgehoben; eines Tages werfe ich vielleicht noch einen Blick darauf, falls ich mich fragen sollte, ob mein Leben einen Sinn gehabt hat :-).
Es gibt hier aber zwei fundamentalere, nicht-politische Lektionen zu lernen, die f├╝r alle Arten von Design gelten.

   12. Oft stammen die hervorragendsten und innovativsten L├Âsungen aus der Erkenntnis, da├č die ganze Vorstellung vom Problem falsch war.

Ich hatte versucht, das falsche Problem zu l├Âsen, als ich fortfuhr, popclient als einen kombinierten MTA/MDA zu entwickeln, der alle m├Âglichen Modi der lokalen Zustellung unterst├╝tzte. Fetchmails Design mu├čte von Grund auf neu ├╝berdacht und als reiner MTA gesehen werden, und als Teil des ├╝blichen SMTP-sprechenden Internet-Postweges.
Nun, so kam ich zu einer Neufassung meines Problems. Klar war, da├č (1) Unterst├╝tzung f├╝r SMTP-Forwarding in den generischen Treiber dazugehackt werden mu├čte, (2) dies der Standardmodus werden mu├čte, und (3) schlie├člich alle anderen Modi der Zustellung hinaus geh├Ârten, besonders die M├Âglichkeit, Mail in eine Datei oder zur Standardausgabe umzuleiten.
Bei Schritt 3 z├Âgerte ich f├╝r einige Zeit. Ich hatte Angst, alte popclient-Benutzer zu vergr├Ąmen, die von alternativen Zustellungsmechanismen abh├Ąngig waren. Theoretisch h├Ątten sie sofort zu .forward-Dateien oder deren Non-sendmail-├äquivalenten wechseln k├Ânnen, praktisch aber war dieser Wechsel ein Alptraum.
Als ich mich dazu entschied, stellten sich die Vorz├╝ge als riesig heraus. Die haarigsten Teile des Treiber-Codes verschwanden einfach. Die Konfiguration wurde radikal leichter -- kein St├Âbern mehr nach der System-MDA und der Mailbox des Benutzers, keine Sorgen mehr dar├╝ber, ob das zugrunde liegende Betriebssystem das file locking unterst├╝tzt.
Auch verschwand die einzige M├Âglichkeit, Mail zu verlieren. Wenn man Zustellung in eine Datei spezifizierte und die Disk voll war, verschwand die Mail. Das konnte bei SMTP-Forwarding nicht mehr passieren, da der SMTP-Listener einfach kein OK gab, solange die Nachricht nicht zugestellt werden oder wenigstens f├╝r sp├Ątere Zustellung gespoolt werden konnte.
Auch der Durchsatz erh├Âhte sich (obwohl man das in einem einzigen Durchlauf wahrscheinlich nicht bemerken k├Ânnte). Ein weiterer, nicht unbedeutender Nutzen dieser ├änderung war, da├č die man-Seite wesentlich simpler wurde.
Sp├Ąter mu├čte ich einen benutzerspezifizierten lokalen MDA wieder zum Funkionieren bringen, um einige obskure Situationen abzudecken, die Dynamic SLIP involvierten. Ich fand aber eine viel schlichtere Methode daf├╝r.
Die Moral der Geschichte? Z├Âgern Sie nicht, ├╝berholte Features aufzugeben, wenn die Effektivit├Ąt davon unbeeinflu├čt bleibt. Antoine de Saint-Exup├ęry (der Pilot und Flugzeugdesigner war, wenn er nicht mit dem Schreiben von klassisch gewordenen Kinderb├╝chern besch├Ąftigt war) sagte einmal:

  13. "Perfektion (im Design) ist nicht erreicht, wenn es nichts mehr hinzuzuf├╝gen gibt, sondern wenn es nichts mehr wegzunehmen gibt."

Wenn Ihr Code sowohl besser als auch einfacher wird, dann wissen Sie, da├č Sie es richtig gemacht haben. Dadurch bekam fetchmail seine eigene Identit├Ąt und l├Âste sich von seinem Vorfahren popclient.
Es wurde Zeit f├╝r eine Namens├Ąnderung. Das neue Design sah mehr nach einer Entsprechung von sendmail aus als der alte popclient; beide sind MTAs, aber so wie sendmail die Zustellungen fortschickt, so f├Ąngt sie der neue popclient ein. Daher taufte ich ihn in fetchmail um.
Es gibt hier aber eine noch allgemeiner anwendbare Lektion dar├╝ber, wie SMTP-Zustellung ein fetchmail-Feature wurde. Es ist die, da├č nicht nur Debugging parallelisierbar ist -- auch die Entwicklung ist es und (in einem vielleicht ├╝berraschenden Ausma├č) auch die Erforschung des Designraumes. Wenn der Entwicklungsmodus mit sehr kurzen Iterationszyklen arbeitet, werden Entwicklung und Erweiterung zu Spezialf├Ąllen des Debuggings -- zu einer Beseitigung von "Fehlern, die Auslassungen sind" - Auslassungen im urspr├╝nglichen Konzept der Software.
Sogar auf h├Âheren Ebenen des Entwurfs kann es sehr wertvoll sein, das Denken vieler Mit-Entwickler in den Design-Raum eines Produkts ausschw├Ąrmen zu lassen. Stellen Sie sich dazu vor, wie eine Wasserpf├╝tze einen Abflu├č findet, oder noch besser, wie Ameisen Essen finden: Erforschung durch Einsickern, gefolgt von einer Diskussion, die ├╝ber skalierbare Kommunikationsmittel gef├╝hrt wird. Das funktioniert sehr gut; wie bei Harry Hochheiser und mir, wird einer Ihrer Sp├Ąher einen riesigen Gewinn in Ihrer Reichweite entdecken, den Sie nur aus ein wenig Vernageltheit nicht gesehen hatten.

7 Fetchmail wird erwachsen

Da war ich also mit einem eleganten und innovativen Design, Code, von dem ich wu├čte, da├č er gut funktionierte, da ich ihn jeden Tag verwendete, und einer lebhaft wachsenden Beta-Liste. Nach und nach d├Ąmmerte mir, da├č ich nicht mehr mit einem trivialen pers├Ânlichen Hack befa├čt war, der einigen Leuten n├╝tzlich sein konnte. Ich hatte meine Finger in einem Programm, da├č jeder Hacker mit einer Unix-Maschine und einer SLIP/PPP-Mailverbindung wirklich braucht.
Durch das Leistungsmerkmal des SMTP-Forwarding zog fetchmail der Konkurrenz soweit davon, da├č es realistisch wurde, in ihm einen baldigen "Kategorienkiller" zu sehen, eines jener klassischen Programme, die eine Nische so kompetent ausf├╝llen, da├č Alternativen nicht einfach nur weggeworfen, sondern fast vergessen werden.
Ich denke, man kann ein solches Ergebnis nicht wirklich planen oder anstreben. Man mu├č von Designideen hineingezogen werden, die so m├Ąchtig sind, da├č sie im R├╝ckblick wie offensichtlich, nat├╝rlich oder sogar gottgewollt wirken. Die einzige M├Âglichkeit, so eine Idee zu finden, ist, eine Menge solcher Ideen zu haben -- oder das technische Urteilsverm├Âgen, um die guten Ideen anderer Leute jenseits deren Vorstellungen weiterzuentwickeln.
Andy Tanenbaum hatte die urspr├╝ngliche Idee, ein einfaches Unix f├╝r den IBM PC zu schaffen, der eigentlich ein Lehrbehelf war. Linus Torvalds hievte das Minix-Konzept weiter als Andrew es wahrscheinlich f├╝r m├Âglich gehalten h├Ątte -- und es wurde etwas ganz wunderbares daraus. In der selben Weise (nur in kleinerem Ma├čstab) ├╝bernahm ich einige Ideen von Carl Harris und Harry Hochheiser und hetzte sie zu H├Âchstleistungen. Keiner von uns war "originell" in dem romantischen Sinne, in dem sich die Leute ein Genie vorstellen. Es ist aber so, da├č die Wissenschaften, Ingenieursk├╝nste und Softwareentwicklungen nicht von Genies weitergebracht werden, was immer anderes die Hackermythologie auch behauptet.
Die Resultate konnten sich trotzdem sehen lassen -- tats├Ąchlich war es genau die Sorte Erfolg, f├╝r die jeder Hacker lebt! Und das bedeutete, da├č ich meine Latte noch h├Âher legen mu├čte, um fetchmail so gut zu machen, wie ich nun sah, da├č es werden konnte. Ich mu├čte nicht nur f├╝r den eigenen Bedarf schreiben, sondern auch Leistungsmerkmale unterst├╝tzen, die f├╝r Menschen au├čerhalb meines Orbits wichtig w├Ąren. Und simpel und robust sollte mein Programm auch noch sein.
Das erste und mit Abstand wichtigste Leistungsmerkmal, das ich nach dieser Erkenntnis schrieb, war Multidrop-Unterst├╝tzung -- die F├Ąhigkeit, Mail aus Mailboxes zu holen, die alle Mail f├╝r eine ganze Gruppe von Benutzern angesammelt hatte, und dann jede einzelne davon an die jeweiligen Empf├Ąnger zuzustellen.
Ich entschied mich f├╝r den Einbau von Multidrop-Unterst├╝tzung zum Teil deswegen, weil Benutzer es sehr nachdr├╝cklich forderten, aber der Hauptgrund daf├╝r war meine ├ťberlegung, da├č es einige Bugs aus dem Single Drop-Code herausr├╝tteln w├╝rde, da es mich zwang, Adressierung in allgemeinster Form zu behandeln. Und genau so war es auch. Das Parsing RFC 822- konform zu bekommen kostete mich erstaunlich viel Zeit, die aber nicht f├╝r ein individuelles, besonders kniffliges St├╝ck Code draufging, sondern weil es eine Menge Details gab, die alle voneinander abh├Ąngig waren und peinlich genaue Implementation erforderten.
Die Verbesserung lohnte sich aber; die Multidrop-Adressierung stellte sich als eine exzellente Design-Entscheidung heraus. Ich wu├čte danach auch, warum:

   14. Jedes Tool sollte in der erwarteten Weise n├╝tzlich sein, aber wirklich gro├čartige Tools bieten dar├╝ber hinaus unerwarteten Nutzen.

Der unerwartete Nutzen von fetchmail mit Multidrop ist der, da├č damit eine Mailingliste mit Alias-Expansion betreiben kann -- und das von der Klientenseite der SLIP/PPP-Verbindung aus. Das bedeutet, da├č jemand mit einem ISP-Konto eine Mailingliste ohne Zugriff auf die Alias-Dateien des ISP unterhalten kann.
Eine weitere bedeutende ├änderung, die von meinen Betatestern gefordert wurde, war die Unterst├╝tzung von 8 bit MIME-Betrieb. Das war releativ einfach, da ich mir M├╝he gegeben hatte, den Code 8-bit-clean zu halten. Nicht da├č ich die Nachfrage f├╝r dieses Feature vorhergesehen h├Ątte, aber ich befolgte einfach eine andere Regel:

   15. Beim Entwickeln von Gateway-Software jeglicher Art ist jeder Aufwand gerechtfertigt, um den Datenstrom so wenig wie m├Âglich zu beeinflussen -- und man darf Information *niemals* wegwerfen, au├čer der Empf├Ąnger verlangt es so!

Wenn ich diese Regel nicht befolgt h├Ątte, w├Ąre 8-bit MIME-Unterst├╝tzung schwierig und voller Fehler geworden. So aber war alles, was ich zu tun hatte, die RFC 1652 zu lesen und ein triviales Schnipsel von Header-generierender Logik einzubauen.
Einige europ├Ąische Benutzer nervten mich solange, bis ich eine Option einbaute, die die Anzahl der Nachrichten pro Verbindung begrenzte (so da├č sie die Kosten f├╝r ihre teuren Telefonleitungen steuern konnten). Ich zierte mich lange Zeit und bin noch immer nicht ganz gl├╝cklich damit, aber wenn man f├╝r die ganze Welt Software schreibt, mu├č man auf seine Kunden h├Âren -- das ├Ąndert sich auch dann nicht, wenn sie einem daf├╝r nichts bezahlen.

8. Was wir von fetchmail sonst noch lernen k├Ânnen

Bevor wir zu den allgemeinen Belangen der Software-Entwicklung zur├╝ckkehren, wollen wir noch einige spezifische Lektionen der fetchmail-Erfahrung untersuchen.
Die rc-Syntax beinhaltet die optionalen "noise"-Schl├╝sselw├Ârter, die vom Parser einfach ignoriert werden. Sie gestatten eine an Englisch angelehnte Syntax und sind bei weitem lesbarer als die traditionell knappen Schl├╝ssel/Wert-Paare, die man erh├Ąlt, wenn man diese "├╝berfl├╝ssigen" Schl├╝sselw├Ârter ausl├Ą├čt.
Diese Schl├╝sselw├Ârter begannen ihre Karriere als sp├Ątn├Ąchtliche Experimente, als ich bemerkte, wie sehr die rc-Deklarationen bereits einer imperativen Mini-Programmiersprache ├Ąhnelten. (Aus diesem Grund ├Ąnderte ich auch das urspr├╝ngliche popclient-Schl├╝sselwort "server" zu "poll").
Mir schien es, als w├╝rde eine Anpassung dieser imperativen Mini-Programmiersprache an gew├Âhnliches Englisch die Benutzung vereinfachen. Obwohl ich ein ├╝berzeugter Partisan f├╝r die "Mach eine Sprache daraus"-Schule des Designs bin (Beispiele daf├╝r sind Emacs, HTML und viele Datenbankmaschinen), zweifle ich normalerweise an "Englisch-├Ąhnlichen" Syntaxen.
Traditionellerweise haben Programmierer eine Tendenz, Steuerungssyntaxen zu bevorzugen, die sehr pr├Ązise und kompakt sind und keine Redundanzen beinhalten. Das ist ein kulturelles Erbe aus jener Zeit, als Computerressourcen teuer waren und die einzelnen Phasen des Parsing so einfach und billig wie m├Âglich sein mu├čten. Englisch auf der anderen Seite, mit seiner 50-prozentigen Redundanz, sah damals nach einem sehr unzul├Ąnglichen Modell aus.
Das ist aber nicht mein Grund, aus dem ich englisch-├Ąhnliche Syntaxen normalerweise vermeide -- ich erw├Ąhne es hier nur, um ihn zu demolieren. Mit den heutigen billigen CPU-Zyklen und Speicherbits sollte Kompaktheit kein Selbstzweck sein. Heute ist es f├╝r eine Programmiersprache wichtiger, f├╝r die Menschen bequem in der Handhabung zu sein, als billig f├╝r den Computer.
Es bleiben aber andere gute Gr├╝nde, um vorsichtig damit zu sein. Einer davon sind die Kosten f├╝r die Komplexit├Ąt des Parsers -- man will die Komplexit├Ąt ja nicht so weit aufbl├Ąhen, da├č sie eine bedeutende Quelle f├╝r Bugs und Verwirrung unter den Anwendern wird. Ein weiter ist der, da├č eine englisch-├Ąhnliche Syntax von ihrem gesprochenen "Englisch" oft verlangt, da├č es in eine groteske Form gepre├čt wird, die dann mit einer ethnischen Sprache nur mehr oberfl├Ąchlich zu tun hat und so verwirrend ist wie eine traditionelle Syntax einer Programmiersprache (was man oft bei sogenannten "Fourth Generation"- und kommerziellen Datenbankabfragesprachen beobachten kann).
Die Steuerungssyntax von fetchmail scheint diese Probleme zu umgehen, da die Sprache extrem eingeschr├Ąnkt ist. Sie kommt einer General Purpose-Sprache nicht einmal in die N├Ąhe, und die Dinge, die sich damit ausdr├╝cken lassen, sind nicht sehr kompliziert. Das Potential f├╝r Verwirrung bei der Unterscheidung zwischen einer kleinen Teilmenge von Englisch und der eigentlichen Steuerungssprache ist daher gering. Ich glaube, es gibt hier eine breiter anwendbare Lektion zu lernen:

   16. Wenn Ihre Programmiersprache in keinster Weise Turing-vollst├Ąndig ist, k├Ânnen Sie sich mit syntaktischer Glasur anfreunden.

Eine weitere Lehre betrifft Sicherheit durch Unsichtbarkeit ("security by obscurity"). Einige fetchmail-Anwender baten mich, die Software so zu ├Ąndern, da├č Pa├čw├Ârter in der rc-Datei verschl├╝sselt werden, so da├č Spione sie nicht so leicht entdecken k├Ânnten.
Ich folgte dieser Bitte nicht, denn es f├╝hrt keineswegs zu einem Schutz. Jeder, der das entsprechende Privileg erhalten hat, Ihre rc-Datei zu lesen, wird fetchmail genau wie Sie aufrufen und verwenden k├Ânnen -- und wenn es Ihr Pa├čwort ist, hinter dem er her ist, wird er in der Lage sein, den Dekoder aus dem fetchmail-Quellcode selbst herauszulesen.
Alles, was verschl├╝sselte .fetchmailrc-Pa├čw├Ârter f├╝r Sie tun k├Ânnten, ist, Ihnen ein tr├╝gerisches Gef├╝hl der Sicherheit zu vermitteln, wenn Sie nicht sehr angestrengt dar├╝ber nachdenken. Die allgemeine Regel hier ist:

17. Ein Sicherheitssystem ist nur so sicher wie seine Geheimnisse. H├╝ten Sie sich vor Pseudo-Geheimnissen.

9. Voraussetzungen f├╝r den Basar-Stil

Fr├╝he Kritiker und das Testpublikum f├╝r dieses Dokument fragten sehr oft nach den Voraussetzungen f├╝r eine erfolgreiche Basar-gef├╝hrte Entwicklung, darunter sowohl Fragen nach der Qualifikation f├╝r den Projektleiter und den Zustand des Codes zum Zeitpunkt der Ver├Âffentlichung f├╝r die Gemeinde der Mit-Entwickler.
Es sollte klar sein, da├č man nicht von Null an im Stile des Basars entwickeln kann [IN]. Man kann am Basar testen, debuggen und verbessern, aber es w├Ąre sehr schwer, ein Projekt im Basar-Modus zu beginnen. Linus versuchte das gar nicht erst, und ich auch nicht. Ihre keimende Entwicklergemeinde mu├č etwas Lauff├Ąhiges und Testbares haben, um damit spielen zu k├Ânnen.
Wenn man mit dem Aufbau der Gemeinde beginnt, ben├Âtigt man ein herzeigbares, ├╝berzeugendes Versprechen. Ihr Programm braucht nicht besonders gut zu funktionieren. Es kann sehr ungeschliffen, von Bugs geplagt, unvollst├Ąndig und sp├Ąrlich dokumentiert sein. Was es aber nicht verfehlen darf, ist, (a) zu laufen, und (b) potentielle Mit-Entwickler davon zu ├╝berzeugen, da├č es sich in absehbarer Zukunft zu etwas wirklich giftigem transformieren l├Ą├čt.
Linux und fetchmail gingen mit starken und attraktiven Designs an die ├ľffentlichkeit. Viele Menschen haben hier vom Basarmodell, wie ich es pr├Ąsentierte, die korrekte Auffassung, da├č dies das allerwichtigste ist und zogen daraus den Schlu├č, da├č f├╝r den Projektleiter ein hohes Ma├č an Intuition f├╝r gutes Design und viel Cleverness unentbehrlich ist.
Linus aber holte sich sein Design von Unix. Ich erbte meines vom Vorfahren popclient (obwohl es sich sp├Ąter noch ganz sch├Ân ├Ąndern sollte, und zwar ├╝berproportional im Vergleich zu Linux). Mu├č der Leiter/Koordinator eines Entwicklungsbasars wirklich ├╝ber herausragendes Talent f├╝r Design verf├╝gen oder kann er damit durchkommen, das Designtalent anderer zu nutzen?
Ich denke, da├č es f├╝r den Koordinator nicht lebenswichtig ist, ein Design von atemberaubender Brillanz zu stiften, da├č es aber f├╝r ihn lebenswichtig ist, ein gutes Design anderer als solches zu erkennen.
Sowohl das Linux- als auch das fetchmail-Projekt liefern Indizien daf├╝r. Linus, der kein besonders origineller Designer ist (wie vorher schon erkl├Ąrt), zeigte doch ein eminentes Talent f├╝r das Erkennen guter Designs und f├╝r die Integration in den Linux-Kernel. Und ich habe auch schon beschrieben, wie die m├Ąchtigste, einzelne Design-Idee hinter fetchmail (SMTP Forwarding) Eingang in meine Software gefunden hat.
Das erste Publikum dieses Dokuments machte mir durch den Hinweis ein Kompliment, da├č ich f├╝r das Untersch├Ątzen von Originalit├Ąt beim Designen f├╝r Basar-Projekte anf├Ąllig w├Ąre, da ich selbst einiges davon bes├Ą├če und daher als selbstverst├Ąndlich n├Ąhme. Das k├Ânnte stimmen; Design (im Gegensatz zu Coding und Debugging) ist sicherlich meine gr├Â├čte St├Ąrke.
Das Problem mit der Cleverness und der Originalit├Ąt beim Software-Design ist aber, da├č beides zur Gewohnheit wird -- man beginnt, die Dinge auszuschm├╝cken und zu verkomplizieren, obwohl man sie doch eigentlich robust und simpel halten sollte. Mir sind schon ganze Projekte um die Ohren geflogen, weil ich eben diesen Fehler machte, aber bei fetchmail schaffte ich es, mich zur├╝ckzuhalten.
Ich glaube also, da├č das fetchmail-Projekt zum Teil deswegen erfolgreich war, weil ich meine Tendenz, clever zu sein, unter Kontrolle hielt, was (wenn schon sonst nichts) ein Einwand gegen die Wichtigkeit von Design-Originalit├Ąt f├╝r Basar-Erfolge ist. Denken Sie nur an Linux: nehmen wir an, Linus Torvalds h├Ątte versucht, s├Ąmtliche grundlegenden Innovationen im Design von Betriebssystemen w├Ąhrend der Entwicklung selbst zu erfinden; erscheint es dann als wahrscheinlich, da├č der resultierende Kernel so stabil und erfolgreich w├Ąre wie der, den wir haben?
Ein gewisses Minimum an Kompetenz f├╝r Design und Codierung ist nat├╝rlich notwendig, aber ich erwarte, da├č fast jeder automatisch ├╝ber mehr als dieses Minimum verf├╝gt, der ernsthaft ├╝ber die Gr├╝ndung eines Basar-Projektes nachdenkt . Der interne Reputations-Markt der Open Source-Gemeinde ├╝bt einen subtilen Druck auf die Leute aus, und verhindert, da├č sie den Keim f├╝r ein Unternehmen legen, dem sie nicht gewachsen sind. Bisher hat das allem Anschein nach tadellos funktioniert.
Es gibt aber noch eine weitere Kompetenz, die normalerweise nicht mit der Entwicklung von Software in Verbindung gebracht wird, die aber f├╝r Basar-Projekte ebenso wichtig ist wie Findigkeit beim Designen -- oder sogar noch wichtiger. Der Koordinator oder Leiter eines Basar-Projekts mu├č mit Leuten umgehen und kommunizieren k├Ânnen.
Das sollte einleuchten. Um eine Entwicklergemeinde aufzubauen, mu├č man Menschen begeistern und f├╝r seine Sache interessieren k├Ânnen und bewirken, da├č sie mit dem eigenen Anteil am Aufwand zufrieden sind. Technischer Glamour wird das meiste der Beinarbeit auf diesem Weg erledigen, aber er alleine ist bei weitem nicht die ganze Geschichte. Der pers├Ânliche Eindruck, den man vermittelt, ist ebenfalls ausschlaggebend.
Es ist kein Zufall, da├č Linus ein netter Kerl ist, der bewirkt, da├č die Leute ihn m├Âgen und ihn unterst├╝tzen wollen. Es ist kein Zufall, da├č ich ein extravertierter und energischer Mensch bin, der das Arbeiten in der Gruppe sehr genie├čt und einiges von der Selbstdarstellung und dem Instinkt eines Kabarettisten hat. Um das Basarmodell zum Funktionieren zu bringen, hilft es enorm, wenn man wenigstens ein bi├čchen Charme hat, um die Menschen f├╝r sich einzunehmen.

10. Der soziale Kontext der Open Source-Software

So steht es geschrieben, und wahr ist es: die besten Hacks beginnen als L├Âsungen f├╝r die pers├Ânlichen und allt├Ąglichen technischen Probleme des Autors und verbreiten sich, weil sich das Problem als typisch f├╝r eine umfangreiche Klasse von Benutzern herausstellt. Das bringt uns zum Kern von Regel 18, die sich vielleicht etwas n├╝tzlicher so formulieren l├Ą├čt:

18. Um ein interessantes Problem zu l├Âsen, f├Ąngt man mit einem Problem an, das einen selbst interessiert.
So war es bei Carl Harris und seinem Ahnen popclient, und so war es bei mir und fetchmail. Diese Erkenntnis gibt es aber schon seit langer Zeit. Der interessante Punkt hier, der Punkt, vom dem die Geschichte von Linux und fetchmail verlangt, da├č wir unsere ganze Aufmerksamkeit auf ihn richten, ist die n├Ąchste Phase -- die Evolution von Software in Gegenwart einer gro├čen, aktiven Gemeinde von Anwendern und Mit-Entwicklern.
 Im "Vom Mythos des Mann-Monats" beobachtet Fred Brooks, da├č Programmiererzeit nicht "gut stapelbar" ist -- mehr Entwickler in ein verschlepptes Software-Projekt zu werfen verschleppt es nur noch mehr. Er behauptet, da├č die Komplexit├Ąts- und Kommunikationskosten proportional zum Quadrat der Anzahl der Entwickler wachsen, w├Ąhrend die vollendete Arbeit nur linear dazu w├Ąchst. Diese Feststellung wurde unter "Brooks' Gesetz" bekannt und oft als Binsenweisheit betrachtet. Wenn aber Brooks' Gesetz nichts hinzuzuf├╝gen w├Ąre, dann w├Ąre Linux unm├Âglich.
Gerald Weinbergs Klassiker "The Psychology Of Computer Programming" (A. d. ├ť.: auf Deutsch nicht erh├Ąltlich, auf Englisch vergriffen) lieferte, was wir aus heutiger Perspektive als eine wichtige Korrektur von Brooks Gesetz sehen k├Ânnen. In seiner Er├Ârterung des "Programmieren ohne Ego" stellt Weinberg fest, da├č in Labors Verbesserungen dramatisch schneller vonstatten gehen, in denen die Entwickler f├╝r ihren Code nicht das Verhalten eines Revierbesitzers an den Tag legen und andere Leute dazu anhalten, nach Bugs und m├Âglichen Verbesserungen zu suchen.
Vielleicht hat es Weinbergs Wahl der Terminologie verhindert, da├č diese Analyse die verdiente Akzeptanz erhielt -- man mu├č unwillk├╝rlich l├Ącheln bei dem Gedanken, Internet-Hacker als "ohne Ego" zu bezeichnen. Aber ich denke, da├č dieses Argument heute ├╝berzeugender wirkt denn je.
Die Geschichte von Unix h├Ątte uns darauf vorbereiten sollen, was wir gerade von Linux lernen (und bereits experimentell in kleinerem Ma├čstab nachweisen konnten, indem wir Linus' Methoden willk├╝rlich nachahmten [EGCS] ). Konkret hei├čt das: W├Ąhrend das Codieren eine grunds├Ątzlich autistische Aktivit├Ąt bleibt, entstehen die wirklich coolen Hacks durch die Organisation der Aufmerksamkeit und Gehirnpower ganzer Gemeinden. Der Entwickler, der nur sein eigenes Gehirn in einem geschlossenen Projekt verwendet, wird gegen├╝ber dem Entwickler zur├╝ckfallen, der wei├č, wie man einen offenen, evolution├Ąren Kontext schafft, in dem Feedback den Design-Raum erforscht und Code-Schnipsel, Bug Reports und andere Verbesserungen von hunderten (oder sogar tausenden) von Teilnehmern kommen.
Die traditionelle Unix-Welt wurde aber vom wirklichen Strapazieren dieses Ansatzes bis zum Extrem durch mehrere Faktoren zur├╝ckgehalten. Einer davon waren die juristischen Einschr├Ąnkungen der verschiedenen Lizenzen, Firmengeheimnisse und kommerziellen Interessen. Ein weiterer (im R├╝ckblick) war, da├č das Internet noch nicht gut genug war.
Vor dem billigen Internet gab es einige geographisch zusammenh├Ąngende Gemeinden, in denen die Kultur zu Weinbergs "Programmieren ohne Ego" ermunterte, und ein Entwickler konnte leicht viele kompetente Kibitze und Mit-Entwickler anziehen. Bell Labs, das MIT AI Lab, UC Berkeley -- sie alle wurden zur Heimat von inzwischen Legende gewordenen Innovationen, von denen noch immer enorme Kraft ausgeht.
Linux war das erste Projekt, das eine bewu├čte und erfolgreiche Anstrengung unternahm, die ganze Welt als seinen Pool von Talenten zu verwenden. Ich glaube nicht, da├č es Zufall ist, da├č die Zeit des Reifens von Linux mit der Geburt des World Wide Web zusammenf├Ąllt. Das war 1993-1994, jene Zeit, zu der die ISP-Industrie abhob, das Interesse der etablierten Medien am Internet explodierte und Linux aus der Gehschule herauswuchs. Linus war der erste, der lernte, wie man nach den neuen Regeln spielt, die das alles durchdringende Internet erm├Âglichte.
W├Ąhrend ein billiges Internet eine Voraussetzung f├╝r die Evolution des Linux-Modells war, denke ich nicht, da├č es die einzige war. Ein weiterer wichtiger Faktor war die Entwicklung eines F├╝hrungsstils und eines Reportoires von Sitten bei der Zusammenarbeit, die es den Entwicklern gestatteten, Mit-Entwickler anzuziehen und das Maximum aus dem Medium herauszuholen.
Aber was war dieser F├╝hrungsstil und was waren die Sitten? Auf Machtverh├Ąltnissen konnten sie nicht beruhen -- und sogar wenn es so w├Ąre, F├╝hrung durch Zwang k├Ânnte das beobachtete Resultat niemals hervorbringen. Weinberg zitiert die Autobiographie "Memoirs of a Revolutionist" des russischen Anarchisten Pyotr Alexeyvich Kropotkin (19. Jahrhundert), um dieses Thema sehr gut zu beleuchten:
"Aus einer Familie stammend, die Leibeigene besa├č, begann ich mein Leben als Erwachsener wie alle jungen M├Ąnner meiner Zeit mit dem Glauben an die Notwendigkeit des Befehlens, Bestrafens, Scheltens und dergleichen. Als ich aber, noch sehr jung, ernsthafte Unternehmen leiten mu├čte und es mit [freien] Menschen zu tun bekam, deren Fehler schwerwiegende Konsequenzen hatten, begann ich, den Unterschied zwischen dem Handeln nach dem Prinzip des Befehlens und der Disziplin und dem Handeln nach dem Prinzip der ├ťbereinkunft zu w├╝rdigen. Ersteres funktioniert vortrefflich in der milit├Ąrischen Parade, ist aber im wirklichen Leben nichts wert, denn ein Ziel kann nur durch die ernstgemeinte Anstrengung ├╝bereinstimmender Willen erreicht werden."
Die "ernstgemeinte Anstrengung ├╝bereinstimmender Willen" ist genau das, was ein Projekt wie Linux erfordert -- und das "Prinzip des Befehlens" ist auf die Freiwilligen unm├Âglich anzuwenden, die wir im Anarchistenparadies Internet vorfinden. Um effektiv zu kooperieren und zu wetteifern, m├╝ssen Hacker, die ein kollaboratives Projekt leiten wollen, lernen, wie man effektive Gemeinden im Sinne von Kropotkins "Prinzip der ├ťbereinkunft" rekrutiert und begeistert. Sie m├╝ssen lernen, Linus Gesetz anzuwenden. [SP]
Ich habe vorher den "Delphi-Effekt" als m├Âgliche Erkl├Ąrung f├╝r Linus' Gesetz erw├Ąhnt. Es empfehlen sich aber auch kraftvollere Analogien der adaptiven Systeme, wie sie Biologen und ├ľkonomen kennen, und das viel eindringlicher. Die Linux-Welt verh├Ąlt sich in vielen Aspekten wie ein freier Markt oder eine ├ľkologie, eine Sammlung von selbsts├╝chtig Agierenden, die versuchen, ihren eigenen Nutzen zu maximieren und dabei von selbst eine selbstkorrigierende Ordnung schaffen, die wesentlich raffinierter und effizienter ist als jede zentrale Planung. Hier ist dann also das "Prinzip der ├ťbereinkunft" zu suchen.
Die "N├╝tzlichkeitsfunktion", die Linux-Hacker zu maximieren trachten, ist nicht in klassischem Sinne ├Âkonomischer Natur, sondern die - etwas unkonkret - Pflege ihres jeweiligen Egos und ihrer Reputation unter Hackerkollegen. (Man mag diese Motivation "altruistisch" nennen, aber dabei vergi├čt man dann den Umstand, da├č Altruismus selbst eine Form von Ego-Pflege f├╝r den Altruisten ist). Tats├Ąchlich sind Kulturen von Freiwilligen, die in dieser Weise funktionieren, nicht ungew├Âhnlich; eine, an der ich lange teilgenommen habe, war die der Science Fiction-Fans, die der Hackerkultur aber insofern un├Ąhnlich ist, als da├č sie "egoboo" (die Vermehrung der eigenen Reputation unter anderen Fans) ausdr├╝cklich als den grundlegenden Antrieb hinter freiwilligen Aktivit├Ąten anerkennt.
Linus positionierte sich als Schrankenw├Ąrter eines Projekts, dessen Entwicklung vorwiegend durch andere getrieben wird und hegte und pflegte es, bis dieses Projekt auf eigenen Beinen stehen konnte. Dadurch hat er einen eminenten Scharfsinn f├╝r Kropotkins "Prinzip der ├ťbereinkunft" gezeigt. Diese quasi-├Âkonomische Auffassung von der Linux-Welt erm├Âglicht es uns zu sehen, wie diese ├ťbereinkuft angewendet wird.
Wir k├Ânnten Linus' Methode als einen Weg ansehen, um einen effizienten Markt f├╝r "egoboo" zu erzeugen -- um die Selbstsucht individueller Hacker so straff wie m├Âglich zu vernetzen und sie vor einen sehr sperrigen Karren zu spannen, der nur durch nachhaltige Kooperation in Bewegung gehalten werden kann. Mit dem fetchmail-Projekt habe ich gezeigt (zugegebenerma├čen in viel kleineren Dimensionen), da├č seine Methoden mit gutem Erfolg nachgeahmt werden k├Ânnen. Vielleicht habe ich es sogar etwas bewu├čter und systematischer getan als er.
Viele Leute (besonders jene, die freien M├Ąrkten aus ideologischen Gr├╝nden mi├čtrauen) w├╝rden von einer Kultur von Egoisten erwarten, da├č sie fragmentiert, in Parzellen zergliedert, verschwenderisch, geheimnistuerisch und feindselig ist. Diese Erwartung wird aber durch viele Beispiele klar widerlegt; eines davon ist die erstaunliche Vielfalt, Qualit├Ąt und Tiefe der Linux-Dokumentation. Es ist eine oft strapazierte Binsenweisheit, da├č Programmierer das Dokumentieren hassen. Wie kommt es dann, da├č Linux-Hacker so viel davon hervorbringen? Offensichtlich funktioniert Linux' freier Markt f├╝r Egoboo besser zur Erzeugung von bravem, r├╝cksichtsvollem Benehmen als die Moneten verbrennenden Dokumentationsfabriken der kommerziellen Softwareproduzenten.
Sowohl das fetchmail- als auch das Linux-Kernel-Projekt zeigen, da├č durch angemessene Pflege der Egos vieler anderer Hacker ein starker Entwickler/Koordinator das Internet verwenden kann, um in den Genu├č vieler Mit-Entwickler zu kommen, ohne das Projekt unter seiner eigenen Masse zusammenbrechen zu sehen. Als Gegengewicht zu Brooks Gesetz stelle ich folgendes fest:
   19. Unter der Vorraussetzung, da├č der Entwicklungskoordinator ein Medium zur Verf├╝gung hat, da├č wenigstens so gut ist wie das Internet, und dieser Koordinator wei├č, wie man ohne Zwang f├╝hrt, werden viele K├Âpfe zwangsl├Ąfig besser arbeiten als nur einer.

Ich glaube, da├č die Zukunft von Open Source-Software zunehmend Leuten geh├Âren wird, die wissen, wie man Linus' Spiel spielt -- Leuten, die die Kathedrale hinter sich lassen und sich f├╝r den Basar entscheiden. Das bedeutet nicht, da├č individuelle Weitsicht und individuelle Brillanz nicht mehr z├Ąhlen werden. Ich denke, da├č die vorderste Front der Open Source-Software von Leuten geschaffen werden wird, deren individuelle Weitsicht und Brillanz dann durch die effektive Konstruktion von Gemeinden von Freiwilligen mit ├Ąhnlichen Interessen verst├Ąrkt wird.
Und vielleicht ist das nicht nur die Zukunft der Open Source-Software. Kein Entwickler von nicht-├Âffentlicher ("Closed Source") Software kann mit dem Talentpool der Linux-Gemeinde mithalten, wenn es um das Bearbeiten einer technischen Problemstellung geht. Sehr wenige k├Ânnten es sich leisten, auch nur die zweihundert (1999: sechshundert) Leute anzuheuern, die zu fetchmail beigetragen haben!
Vielleicht wird die Open Source-Kultur schlie├člich nicht aus dem Grund triumphieren, da├č Kooperation moralisch richtig oder das "Horten" von Software moralisch verwerflich ist (was unterstellt, da├č Sie letzteres glauben, was weder Linus noch ich tun), sondern einfach, weil die Welt der nicht-├Âffentlichen Software in einem evolution├Ąren Wettr├╝sten mit den Open Source-Gemeinden nicht gewinnen kann, die ein Vielfaches an hochqualifizierter Entwicklerzeit in eine Problemstellung investiert.

11. ├ťber Management und die Maginotlinie

Die urspr├╝ngliche Fassung von "Cathedral and Bazaar" endete mit der oben beschriebenen Vision -- der von fr├Âhlichen vernetzten Horden von Programmierern/Anarchisten, denen die hierarchische Welt konventioneller Software in keiner Weise gewachsen ist.
Nicht wenige Skeptiker ├╝berzeugte das aber gar nicht, und ihre Zweifel verdienen eine faire Er├Ârterung. Die meisten der Einw├Ąnde gegen das Basar-Argument lassen sich so zusammenfassen, da├č Open Source-Verfechter den die Produktivit├Ąt multiplizierenden Effekt konventioneller Management-Verfahren untersch├Ątzen.
Traditionell orientierte Manager von Projekten der Software-Entwicklung wenden oft ein, da├č die L├Ąssigkeit, mit der sich Projektgruppen in der Open Source-Welt bilden, ver├Ąndern und wieder aufl├Âsen, einen bedeutenden Teil der Vorz├╝ge einer gro├čen Zahl von Entwicklern zunichte mache. Ihre Feststellung hier ist, da├č in der Software-Entwicklung nicht die Anzahl der auf einen Haufen geworfenen Leute z├Ąhlt, sondern das Ausma├č der nachhaltigen Investitionen in ein Produkt, die Kunden erwarten k├Ânnen.
An diesem Einwand ist etwas dran, so viel ist sicher; tats├Ąchlich habe ich in Der verzauberte Kessel die Idee entwickelt, da├č in Zukunft der Wert der Dienstleistung der Schl├╝ssel zur ├ľkonomie in der Softwareproduktion ist.
Dieses Argument hat aber auch ein ernstes verstecktes Problem; es unterstellt, da├č Open Source-Entwicklung diese nachhaltigen Investitionen nicht liefern kann. Tats├Ąchlich gab und gibt es Open Source-Projekte, die eine bestimmte Richtung und durchschlagskr├Ąftige Gemeinden von Teilnehmern treu verfolgt haben, und das ├╝ber sehr lange Zeitr├Ąume hinweg und ohne institutionelle Aufsicht, die konventionelles Management so bedeutend findet. Die Entwicklung des Editors GNU Emacs ist ein extremes und lehrreiches Beispiel daf├╝r; sie hat ├╝ber f├╝nfzehn Jahre hinweg die Zuwendung und M├╝he von hunderten von Beitragenden in eine vereinigte architektonische Vision absorbiert, und das trotz hoher Fluktuation und trotz der Tatsache, da├č nur eine Person (der Autor von GNU) w├Ąhrend der ganzen Zeit ununterbrochen aktiv war. Kein Closed Source-Editor hat jemals solche Langlebigkeit erreicht.
Das alles legt es nahe, die Vorz├╝ge von konventionell gemanageter Software-Entwicklung anzuzweifeln, die vom Rest der Einw├Ąnde gegen das Kathedralen- vs. Basar-Modell unabh├Ąngig sind. Wenn es f├╝r GNU Emacs m├Âglich ist, f├╝nfzehn Jahre lang eine gerade Linie in der Architektur zu verfolgen, oder f├╝r acht Jahre im Falle eines Betriebssystems wie Linux, und wenn (was tats├Ąchlich der Fall ist) es sehr viele gut entworfener Open Source-Projekte gibt, die l├Ąnger als f├╝nf Jahre am Leben waren -- dann sind wir berechtigt, uns zu fragen, was wir denn, wenn ├╝berhaupt irgendetwas, f├╝r die Unkosten f├╝r konventionelles Management eigentlich kaufen.
Was auch immer es ist, es hat sicher nichts mit der Lieferung von zuverl├Ąssiger Software zu einem versprochenen Termin zu tun, oder mit dem Einhalten des Budgets, oder mit allen in der Spezifikation geforderten Leistungsmerkmalen; es kommt ausgesprochen selten vor, da├č ein "gemanagetes" Projekt auch nur eines dieser Ziele erreicht, von allen dreien gar nicht zu reden. Es scheint auch kein besonderes Talent von konventionellem Management zu sein, w├Ąhrend des Lebenszyklus eines Projekts flexibel auf Ver├Ąnderungen im technologischen oder ├Âkonomischen Kontext zu reagieren. Die Open Source-Gemeinde hat sich bei dieser Wertung als bei weitem effektiver gezeigt. Davon kann man sich sehr leicht selbst ├╝berzeugen, beispielsweise durch den Vergleich der drei├čigj├Ąhrigen Geschichte des Internets mit den kurzen Halbwertszeiten propriet├Ąrer Netzwerktechnologien, oder den Kosten f├╝r die Migration von Microsoft Windows von 16-bit auf 32-bit auf der einen Seite und die fast kostenlose Migration von Linux im selben Zeitraum, die nicht nur auf Intel-Prozessoren beschr├Ąnkt war, sondern auf mehr als ein Dutzend anderer Hardware-Plattformen ausgedehnt wurde, darunter den 64-bit Alpha.
Eines, was sich die Menschen vom traditionellen Modus der Software-Entwicklung versprechen, ist die M├Âglichkeit, jemanden nach einem schiefgegangen Projekt auf Schadenersatz zu verklagen. Das ist aber eine Illusion; die meisten Software-Lizenzen sind so abgefa├čt, da├č sie sogar jede Verantwortung f├╝r Verk├Ąuflichkeit, ganz zu schweigen von Funktionstauglichkeit, ablehnen -- und die F├Ąlle, in denen der Schaden durch nichtfunktionierende Software erfolgreich eingeklagt werden konnte, sind verschwindend gering. Sogar wenn das ├╝blich w├Ąre, ginge dieser Trost, jemanden belangen zu k├Ânnen, am Thema vorbei. Sie wollen keinen Proze├č, Sie wollen funktionierende Software.
Was erhalten wir also durch den Overhead des Managements?
Um das zu verstehen, m├╝ssen wir uns zun├Ąchst mit dem vertraut machen, was Software-Entwicklungsleiter glauben zu tun. Eine Bekannte, die sehr gut in diesem Job zu sein scheint, erkl├Ąrt, da├č Software-Projektmanagement f├╝nf Funktionen erf├╝llt:
  1. Es definiert Ziele und sorgt daf├╝r, da├č alle Teilnehmer am selben Strang ziehen.
  2. Es ├╝berwacht den Fortschritt und stellt sicher, da├č wichtige Details nicht einfach unter den Tisch fallen.
  3. Es motiviert die Leute dazu, auch stumpfsinnige, aber notwendige Plackerei zu machen.
  4. Es organisiert den Aufwand der Leute zu maximaler Produktivit├Ąt.
  5. Es beschafft Ressourcen, die f├╝r den Fortschritt des Projekts notwendig sind.
Anscheinend sind das alles erstrebenswerte Ziele, aber beim Open Source-Modell und seinem umgebenden sozialen Kontext k├Ânnen sie alle sehr schnell eine eigent├╝mliche Bedeutungslosigkeit bekommen. Gehen wir die Ziele in umgekehrter Reihenfolge durch.
Meine Bekannte berichtet, da├č vieles von der Beschaffung von Ressourcen prinzipiell defensiv ist; sobald man seine Leute, Ger├Ąte und B├╝ror├Ąumlichkeiten beisammen hat, mu├č man sie gegen gleichgestellte Manager verteidigen, die um die selben Ressourcen wetteifern, und gegen Vorgesetzte, die den gr├Â├čtm├Âglichen Nutzen aus einem begrenzten Pool herausholen wollen.
Open Source-Entwickler aber sind Freiwillige, die nach Interesse und F├Ąhigkeit selbsternannt sind, um zu einem Projekt beizutragen (das bleibt sogar dann wahr, wenn sie f├╝r das Open Source-Hacken ein Gehalt bezahlt bekommen). Der Ethos der Freiwilligen hat die Tendenz, die gesamte "r├Ąuberische" Seite der Beschaffung von Ressourcen automatisch zu entsch├Ąrfen: die Leute stiften ihre eigenen Ressourcen. Und es gibt wenig oder keinen Bedarf nach einem Manager, der den "Besch├╝tzer" im konventionellen Sinne spielt.
In einer Welt der billigen PCs und schnellen Internet-Verbindungen stellen wir praktisch ├╝berall fest, da├č die einzige begrenzte Ressource kompetente Aufmerksamkeit ist. Open Source-Projekte, die im Sand verlaufen, scheitern nicht an einem Mangel von Maschinen oder Anschl├╝ssen oder B├╝ror├Ąumlichkeiten, sondern daran, da├č die Entwickler das Interesse daran verlieren.
Aus diesem Grund ist es doppelt wichtig, da├č Open Source-Hacker sich selbst organisieren, um durch Selbsternennung das Maximum an Produktivit├Ąt zu liefern -- und das soziale Milieu w├Ąhlt gnadenlos nur die h├Âchste Kompetenz. Meine Bekannte, die sowohl mit der Open Source-Welt als auch mit umfangreichen Projekten unter Ausschlu├č der ├ľffentlichkeit vertraut ist, glaubt, da├č Open Source teilweise wegen seiner Auswahlkriterien so erfolgreich war, die nur 5 Prozent der programmierenden Bev├Âlkerung zul├Ą├čt. Sie verbringt die meiste Zeit mir der Organisation der restlichen 95 Prozent und kennt daher den Unterschied zwischen den f├Ąhigsten Programmierern und den gerade noch kompetenten aus erster Hand; die Produktivit├Ąt verh├Ąlt sich ungef├Ąhr 1:100.
Dieser bedeutende Unterschied hat immer eine verlegene Frage hervorgerufen: w├Ąren individuelle Projekte und das gesamte Feld besser dran, wenn nicht mehr als 50 Prozent der weniger F├Ąhigen daran teilnehmen w├╝rden? Besonnene Manager verstehen seit langem, da├č das ganze Spiel keinen Wert mehr h├Ątte, wenn es die einzige Funktion des konventionellen Managements w├Ąre, die weniger F├Ąhigen von einem Nettoverlust zu einem marginalen Gewinn zu machen.
Der Erfolg der Open Source-Gemeinde versch├Ąrft diese Frage bedeutend. Sie liefert harte Beweise daf├╝r, da├č es oft billiger und effektiver ist, selbsternannte Freiwillige ├╝ber das Internet anzuheuern als ganze Geb├Ąude voller Leute zu managen, die lieber etwas anderes t├Ąten.
Das bringt uns nahtlos zur Frage der Motivation. Eine ├Ąquivalente und oft geh├Ârte Umformulierung der betreffenden Aussage meiner Bekannten ist, da├č traditionelles Entwicklermanagement eine notwendige Kompensation f├╝r schlecht motivierte Programmierer ist, die andernfalls keine gute Arbeit liefern w├╝rden.
Diese Antwort tritt meistens zusammen mit der Behauptung auf, da├č die Open Source-Gemeinde sich nur dort auf das Erbringen von Aufwand verlassen kann, wo er sexy ist oder technischen Glamour ausstrahlt; alles andere w├╝rde ungetan oder schlecht gemacht bleiben, wenn nicht geld-motivierte Gro├čraumb├╝robewohner unter der Knute von Managern zu Hilfe kommen w├╝rden. Ich befasse mich mit den psychologischen und sozialen Gr├╝nden f├╝r Zweifel an dieser Behauptung in "Homesteading the Noosphere". Im Augenblick m├Âchte ich aber auf die interessanten Implikationen hinweisen, wenn man unterstellt, da├č diese Behauptung wahr ist.
Wenn der konventionelle, v├Âllig durchgemanagete und nicht-├Âffentliche ("Closed Source") Stil der Software-Entwicklung wirklich nur durch eine Art Maginot-Linie von Problemen verteidigt wird, die Langeweile hervorrufen, dann wird jedes einzelne Feld von Anwendungen nur solange davor sicher sein, solange diese Problemstellungen niemand interessant findet und niemand einen Weg findet, sie zu umgehen. Ab dem Zeitpunkt, ab dem es einen Wettbewerb um ein "langweiliges" St├╝ck Software gibt, erfahren dann auch die Kunden, da├č sich endlich jemand gefunden hat, der dieses Problem interessant genug fand, um sich darum zu k├╝mmern -- was bei Software wie bei jeder anderen kreativen T├Ątigkeit ein bei weitem machtvollerer Motivator ist als Geld allein.
Eine konventionelle Managementstruktur zu haben, um zu motivieren, ist so gesehen gute Taktik, aber schlechte Strategie; ein kurzfristiger Gewinn, aber langfristig ein sicherer Verlust.
Bis jetzt sieht das konventionelle Entwicklungsmanagement in zwei Punkten wie eine schlechte Wette gegen Open Source aus (Beschaffung und Organisation) und bei einem dritten (Motivation) lebt es von geborgtem Gl├╝ck. Der arme, unter Druck stehende konventionelle Manager wird keine Aufgaben bei ├ťberwachung vorfinden, auf dem er Punkte wettmachen kann; das st├Ąrkste Argument f├╝r Open Source ist die dezentralisierte, unentwegte Kritik und Verfeinerung durch Gleichgesinnte ("peer review"), die allen konventionellen Methoden der Qualit├Ątssicherung weit ├╝berlegen ist.
Bleibt uns wenigstens die Definition von Zielen als Rechtfertigung f├╝r den Overhead des konventionellen Software-Projektmanagements? Vielleicht, aber das verlangt gute Gr├╝nde f├╝r den Glauben daran, da├č Management-Kommitees und Firmenerl├Ąsse beim Definieren von lohnenden und allgemein anerkannten Zielen erfolgreicher sind als die Projektleiter und Stammes├Ąltesten, die eine analoge Rolle f├╝r die Open Source-Welt ausf├╝llen.
Diesen Einwand zu einem ├╝berzeugenden zu machen wird schwierig sein, und es ist nicht so sehr die Open Source-Seite dieser Gleichung (Langlebigkeit von Emacs und Linus Torvalds' F├Ąhigkeit, ganze Horden von Entwicklern durch Reden ├╝ber "Weltherrschaft" zu mobilisieren), die das so erschwert. Stattdessen ist es die Erb├Ąrmlichkeit der konventionellen Mechanismen zur Definition von Zielen f├╝r Software-Projekte.
Eines der bekanntesten Volkstheoreme des Software-Ingenieurswesens ist, da├č 60 bis 75 Prozent aller konventionellen Software-Projekte entweder nie fertig oder von den vorgesehenen Anwendern nicht angenommen werden. Wenn diese Zahlen auch nur ungef├Ąhr stimmen (und ich habe niemals einen erfahrenen Manager getroffen, der sie abgestritten h├Ątte), dann ist mehr als die H├Ąlfte aller Projekte entweder (a) nicht realistisch spezifiziert oder (b) an den Anwendern vorbeispezifiziert.
Das ist mehr als alles andere der Grund daf├╝r, da├č in der Welt des heutigen Software-Ingenieurswesens schon alleine die Formel "Management-Kommittee" dem H├Ârer die Nackenhaare aufstellt -- sogar (oder vielleicht besonders) wenn der H├Ârer selbst ein Manager ist. Die Tage, in denen ausschlie├člich Programmierer dagegen Allergiereaktionen zeigten, sind lange vorbei; Dilbert-Comics h├Ąngen heute auch ├╝ber den Schreibtischen der Chefs.
Unsere Stellungnahme gegen├╝ber dem traditionellen Manager von Software-Entwicklung ist daher simpel: wenn die Open Source-Gemeinde den Wert des konventionellen Managements untersch├Ątzt, warum begegnen dann so viele von euch euren eigenen Verfahren mit so viel Geringsch├Ątzung?
Wieder einmal versch├Ąrft die Existenz der Open Source-Gemeinde diese Frage erheblich -- weil wir Spa├č an dem haben, was wir tun. Unsere kreative Spielerei hat Erfolge nach Kriterien der Technologie, Marktanteile und Beachtung gebracht, deren H├Ąufigkeit das Erstaunliche ist. Wir beweisen nicht nur, da├č wir die bessere Software machen k├Ânnen, sondern auch, da├č Spa├č Kapital ist.
Zweieinhalb Jahre nach der ersten Version dieses Aufsatzes ist der radikalste Gedanke, den ich als Schlu├čwort anbieten kann, nicht mehr l├Ąnger eine Vision einer Open Source-dominierten Software-Welt, die heute sogar vielen n├╝chternen Menschen in Schlips und Kragen plausibel scheint.
Stattdessen weise ich auf eine allgemeinere Lektion zum Thema Software hin (die sich vielleicht auf jede Form von kreativer oder professioneller Arbeit ausdehnen l├Ą├čt). Die Menschen haben in der Regel ihre Freude an einer Aufgabe, die in irgendeiner Weise in die Zone einer optimalen Herausforderung f├Ąllt, die also weder so leicht ist um zu langweilen noch so schwierig um zu ├╝berfordern. Ein gl├╝cklicher Programmierer ist einer, der weder unterfordert noch von schlecht formulierten Zielsetzungen und dem Stre├č b├╝rokratischer Reibungsverluste geplagt ist. "Der Spa├č kommt mit der Effizienz".
Von den Umst├Ąnden und Methoden der eigenen Arbeit angewidert zu sein (sogar wenn sich nur milder Ekel durch Aufh├Ąngen von Dilbert-Comics zeigt) sollte daher als Zeichen daf├╝r gewertet werden, da├č der Proze├č selbst versagt hat. Freude, Humor und Verspieltheit sind ein wertvolles Gut und das Schlagwort von den "fr├Âhlichen Horden" habe ich nicht nur wegen seiner Griffigkeit verwendet. Auch ist es mehr als nur ein Witz, da├č f├╝r Linux' Maskottchen ein kuscheliger, kindlicher Pinguin ausgesucht wurde.
Es k├Ânnte sich ohne weiteres herausstellen, da├č die wichtigste Auswirkung des Erfolges der Open Source die Einsicht ist, da├č es keinen ├Âkonomisch effektiveren Modus kreativer Arbeit gibt als das Spielen.

12. Danksagung

Dieses Dokument gewann durch Gespr├Ąche mit einer gro├čen Zahl von Leuten, die alle mithalfen, es zu debuggen. Mein spezieller Dank gilt Jeff Dutky <dutky@wam.umd.edu>, der die Formulierung "Debugging ist parallelisierbar" beisteuerte und bei der Entwicklung der darauf folgenden Analyse half. Auch Nancy Lebovitz <nancyl@universe.digex.net> gilt mein besonderer Dank. Sie schlug vor, es Weinberg gleichzutun und Kropotkin zu zitieren. Konstruktive Kritik kam auch von Joan Eslinger <wombat@kilimanjaro.engr.sgi.com> und Marty Franz <marty@net-link.net> von der Mailingliste General Technics. Glen Vandenburg <glv@vanderburg.org> wies auf die Wichtigkeit der Selbsternennung unter Beitragenden hin und stiftete die fruchtbare Idee, da├č viel Entwicklungsarbeit "Bugs der Auslassung" behebt; Daniel Upper <upper@peak.org> schlug die nat├╝rlichen Analogien daf├╝r vor. Ich bin den Mitgliedern von PLUG, der Philadelphia Linux Users Group sehr dankbar f├╝r ihr Auftreten als erstes Testpublikum f├╝r die erste ├Âffentliche Version dieses Papiers. Paula Matuszek <matusp00@mh.us.sbphrd.com> erleuchtete mich zum Thema Praxis des Software-Managements. Phil Hudson <phil.hudson@iname.com> erinnerte mich daran, da├č die soziale Organisation der Hacker-Kultur die Organisation ihrer Software widerspiegelt und umgekehrt. Schlie├člich waren Linus Torvalds' Kommentare sehr hilfreich und seine fr├╝he Unterst├╝tzung eine gro├če Ermutigung.

13. Weiterf├╝hrende Literatur

Ich zitierte mehrere Passagen aus Frederick P. Brooks' Klassiker Vom Mythos des Mann-Monats, da seinen Einsichten in vielerlei Hinsicht noch nicht wirklich nachgekommen wurde. Ich m├Âchte Ihnen die Ausgabe zum 25. Jahresjubil├Ąum ganz herzlich empfehlen, die bei Addison-Wesley (ISBN 0-201-83595-9) erschienen ist und auch sein 1986 geschriebenes Papier "No Silver Bullet" enth├Ąlt. (Anm. d. ├ť: auf Deutsch: "Vom Mythos des Mann-Monats", Addison-Wesley, ISBN 3-925118-09-8)

Die neue Ausgabe wird durch eine unsch├Ątzbare R├╝ckschau nach 20 Jahren erg├Ąnzt, in der sich Brooks unverbl├╝mt zu den wenigen Urteilen im urspr├╝nglichen Text bekennt, die sich im Laufe der Zeit als nicht stichhaltig erwiesen haben. Ich las diese R├╝ckschau zun├Ąchst nachdem die erste ├Âffentliche Version im gro├čen und ganzen vollendet war und wurde durch die Entdeckung ├╝berrascht, da├č Brooks Basar-├Ąhnliche Praktiken Microsoft zuschreibt! (Tats├Ąchlich stellte sich aber heraus, da├č dieses Urteil nicht richtig ist. 1998 erfuhren wir durch die Halloween Documents, da├č Microsofts interne Entwicklergemeinde massiv balkanisiert ist und jene Freiz├╝gigkeit im allgemeinen Zugriff auf Quellcode nicht einmal wirklich m├Âglich ist.)

Gerald M. Weinbergs The Psychology Of Computer Programming (New York, Van Nostrand Reinhold 1971) f├╝hrte das etwas ungl├╝cklich getaufte Konzept des "Programmieren ohne Ego" ein. W├Ąhrend er nicht einmal ann├Ąhernd unter den ersten war, die die Zwecklosigkeit des "Prinzip des Befehlens" erkannte, war er wahrscheinlich der erste, der diesen Punkt in Verbindung mit Software-Entwicklung bemerkte und diskutierte.

Richard P. Gabriel machte sich Gedanken ├╝ber die Unix-Kultur der Pr├Ą-Linux-Epoche und gestand in seinem 1989 erschienen Papier Lisp: Good News, Bad News, and How To Win Big einem primitiven Basar-├Ąhnlichen Modell ├ťberlegenheit zu. Obwohl es in vielen Aspekten schon etwas veraltet wirkt, genie├čt sein Aufsatz noch heute zu Recht hohes Ansehen unter Lisp-Fans (mich eingeschlossen). Ein Korrespondent machte mich darauf aufmerksam, da├č sich der Abschnitt mit dem Titel "Worse Is Better" fast wie eine Vorwegnahme von Linux liest. Das Papier ist im World Wide Web unter http://www.naggum.no/worse-is-better.html verf├╝gbar.

De Marco und Listers Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6) ist ein wenig gew├╝rdigtes Juwel, das ich zu meiner gro├čen Freude in Fred Brooks R├╝ckblick zitiert gesehen habe. Obwohl nur wenig von dem, was die Autoren zu sagen haben, direkt auf die Linux- oder Open Source-Gemeinden anwendbar ist, sind die Einsichten der Autoren in die Voraussetzungen kreativen Schaffens stichhaltig und haben ihren Wert f├╝r jeden, der versucht, einige der Tugenden des Basar-Modells in einen kommerziellen Kontext zu importieren.

Schlie├člich mu├č ich gestehen, da├č ich diesen Aufsatz beinahe "The Cathedral and The Agora" ("Die Kathedrale und der Marktplatz", A. d. ├ť.) betitelt h├Ątte. Die klassischen Papiere ├╝ber "agorischen Systeme" von Mark Miller und Eric Drexler, beschreiben die gerade erkennbar werdenden Eigenschaften von Markt-├Ąhnlichen Rechner-├ľkologien und halfen mir dabei, klare Gedanken ├╝ber analoge Ph├Ąnomene in der Open Source-Kultur fassen, auf die mich Linux f├╝nf Jahre zuvor mit der Nase gesto├čen hatte. Diese Aufs├Ątze gibt es im Web unter http://www.agorics.com/agorpapers.html.

14. Epilog: Netscape geht auf den Basar

Es ist ein komisches Gef├╝hl zu merken, da├č man dabei mithilft, Geschichte zu machen...
Am 22. Januar 1998, ungef├Ąhr sieben Monate, nachdem ich "Die Kathedrale und der Basar" erstmalig publiziert hatte, gab Netscape Communications, Inc. ihre Pl├Ąne bekannt, den Quellcode f├╝r den Netscape Communicator zu ver├Âffentlichen. Ich hatte noch am Tag vor dieser Verlautbarung keine Ahnung davon, da├č dies passieren w├╝rde.
Eric Hahn, der Executive Vice President und Chief Technology Officer bei Netscape, schrieb mir kurz danach eine e-Mail:
 "Im Namen aller Netscape-Mitarbeiter m├Âchte ich Ihnen daf├╝r danken, da├č Sie uns so weit gebracht haben. Ihr Denken und Schreiben waren die grundlegenden Inspirationen f├╝r unsere Entscheidung."
In der Woche darauf folgte ich Netscapes Einladung und flog nach Silicon Valley, um zusammen mit ihren Top Executives und technischen Leuten an einer eint├Ągigen Strategiekonferenz teilzunehmen (das war am 4. Februar 1998). Wir entwarfen Netscapes Strategie zur Freigabe des Quellcodes und Lizensierung.
Ein paar Tage sp├Ąter schrieb ich folgendes:
"Netscape steht kurz davor, uns einen riesigen Praxistest f├╝r das Basar-Modell in der kommerziellen Welt zu erm├Âglichen. Die Open Source-Kultur sieht sich nun einer Gefahr gegen├╝ber; wenn Netscapes Plan scheitert, kann das Open Source-Konzept derma├čen in Mi├čkredit geraten, da├č sich die kommerzielle Welt f├╝r ein Jahrzehnt lang nicht mehr darauf einlassen wird.
Auf der anderen Seite ist es eine gro├čartige Gelegenheit. Die erste Reaktion auf den Schachzug in der Wall Street und anderswo war vorsichtiger Optimismus. Wir haben auch die Chance, etwas zu beweisen. Wenn Netscape dadurch bedeutende Marktanteile zur├╝ckgewinnen kann, k├Ânnte es eine l├Ąngst f├Ąllige Revolution in der Software-Industrie ausl├Âsen.
Das n├Ąchste Jahr sollte eine sehr lehrreiche und interessante Zeit werden."
Und das war es dann auch. Ich schreibe dies zur Jahresmitte 1999. Die Entwicklung dessen, was sp├Ąter "Mozilla" genannt wurde, war nur ein teilweiser Erfolg. Das urspr├╝ngliche Ziel Netscapes wurde erreicht -- Microsoft ein Monopol am Browser-Markt zu vereiteln. Der Schachzug bewirkte auch einige dramatische Erfolge (vor allem die Freigabe der Rendering Engine der n├Ąchsten Generation - Gecko).
Das Unternehmen war aber noch nicht in der Lage, au├čerhalb Netscapes jene massive Entwicklungskapazit├Ąt zu sammeln, die sich die Gr├╝nder von Mozilla urspr├╝nglich erhofft hatten. Das Problem dabei scheint zu sein, da├č die Mozilla-Distribution lange Zeit eine der grundlegenden Regeln des Basar-Modells brachen; sie lieferten nichts aus, was potentielle Teilnehmer leicht laufen lassen und arbeiten sehen konnten. (Bis mehr als ein Jahr nach der Release erforderte das Kompilieren von Mozilla eine Lizenz f├╝r eine propriet├Ąre Motif-Bibliothek.)
Am negativsten wirkte sich aus (vom Standpunkt der Welt au├čerhalb Netscapes), da├č die Mozilla Group noch keinen Browser von professioneller Qualit├Ąt geliefert hat -- und eine der Vorst├Ąnde des Projekts sorgte f├╝r eine kleine Sensation, als er zur├╝cktrat und sich ├╝ber schlechtes Management und verpa├čte Gelegenheiten beschwerte. "Open Source", so seine korrekte Beobachtung, " ist kein Zauberstab."
Das stimmt nat├╝rlich. Die langfristige Prognose f├╝r Mozilla sieht heute (August 1999) viel besser aus als zur Zeit von Jamie Zawinskis R├╝cktrittserkl├Ąrung -- er lag aber ganz richtig mit dem Hinweis, da├č die Ver├Âffentlichung des Quellcodes nicht notwendigerweise ein existierendes Projekt retten kann, das durch schlechtdefinierte Ziele, Spaghetticode und anderen chronischen Krankheiten der Software-Entwicklung geplagt ist. Mozilla hat es geschafft, uns gleichzeitig ein Beispiel daf├╝r zu liefern, unter welchen Umst├Ąnden Open Source Erfolg haben kann und unter welchen Umst├Ąnden die Methode scheitern wird.
In der Zwischenzeit hat die Open Source-Idee aber weitere Erfolge landen und weitere Unterst├╝tzung finden k├Ânnen. 1998 und Ende 1999 erlebten wir eine gewaltige Explosion des Interesses an der Open Source-Entwicklungsmethode -- ein Trend, der sowohl den anhaltenden Erfolg von Linux antreibt als auch davon in Schwung gehalten wird. Die von Mozilla in Gang gesetzte Bewegung beschleunigt sich noch weiter.

15. Fu├čnoten

[JB] In Programing Pearls, kommentiert Jon Bentley, der ber├╝hmte Aphorist der Informatik, Brooks' Beobachtungen mit "Wenn Sie planen, eine Version wegzuschmei├čen, werden Sie zwei wegschmei├čen". Er liegt damit ziemlich sicher richtig. Der springende Punkt hinter Brooks' Feststellung und der hinter Bentleys' ist nicht blo├č, da├č man vom ersten Versuch erwarten sollte, da├č er fehlschl├Ągt, sondern da├č es effektiver ist, noch einmal von vorne anzufangen, als zu versuchen, einen Sauhaufen auszumisten.
  [QR] Es gibt Beispiele erfolgreicher Open Source-Projekte im Basar-Stil, die noch vor der Internet-Explosion stattfanden und mit Unix in keinem Bezug stehen. Die Entwicklung des DOS-Packprogramms info-Zip w├Ąhrend der Jahre 1990-1992 ist ein solches. Ein weiteres war das Bulletin Board System RBBS (auch f├╝r DOS), das 1983 begann und eine so starke Gemeinde entwickelte, da├č es bis heute (Mitte 1999) sehr regelm├Ą├čige Freigaben gibt, und das trotz der gewaltigen technischen Vorteile von Internet-Mail und gemeinsamer Nutzung von Dateien ├╝ber lokale BBSs. W├Ąhrend die Info-Zip-Gemeinde bis zu einem gewissen Grad Internet-Mail nutzte, basierte die Entwicklerkultur der umfangreichen RBBS-Gemeinde auf RBBS, das von der TCP/IP-Infrastruktur v├Âllig unabh├Ąngig war.
  [JH] John Hasler regte eine interessante Erkl├Ąrung f├╝r den Umstand an, da├č es bei Open Source-Projekten verh├Ąltnism├Ą├čig wenig vergebliche M├╝he durch ├╝berlappende Anstrengungen gibt. Ich nenne seine Vorstellung "Haslers Gesetz": Die Kosten f├╝r doppelt gemachte Arbeit tendieren dazu, weniger als mit dem Quadrat der Team-Gr├Â├če zu wachsen. In anderen Worten, sie werden immer geringer sein als die Planungs- und Management-Unkosten, die gebraucht w├╝rden, um sie zu eliminieren.
Diese Behauptung widerspricht Brooks' Gesetz nicht. Es mag sein, da├č die Unkosten f├╝r die gesamte Komplexit├Ąt und die Anf├Ąlligkeit f├╝r Bugs mit dem Quadrat der Team-Gr├Â├če w├Ąchst, aber die Kosten f├╝r doppelt vorgenommene Arbeiten sind nichtsdestoweniger ein Spezialfall, der eine weniger dramatische Wachstumscharakteristik hat. Es ist nicht schwierig, plausible Erkl├Ąrungen daf├╝r zu finden. Bedenken Sie nur, da├č es viel einfacher ist, sich auf die Abgrenzung der Funktionalit├Ąt der jeweiligen Module verschiedener Entwickler zu einigen (was doppelt investierten Aufwand verhindert), als die ungeplanten Interaktionen ├╝ber das ganze System hinweg auszuschlie├čen, das den meisten Bugs zugrunde liegt.
Die Kombination von Linus' Gesetz und Haslers Gesetz legt drei ausschlaggebende Umst├Ąnde von Software-Projekten nahe. Bei kleinen Projekten (bis zu drei Entwickler, w├╝rde ich sagen) ist keine aufwendigere Managementstruktur notwendig, als einen Entwickler als Chef-Programmierer zu haben. Dann gibt es einen mittleren Bereich der Projektgr├Â├če, bei dem die Kosten f├╝r traditionelles Management relativ gering sind, so da├č die Vorz├╝ge aus der Vermeidung von ├╝berlappendem Aufwand, Bug-Tracking und dem unentwegten Kampf gegen ├╝bersehene Details unter dem Strich einen Gewinn darstellen.
F├╝r jenseits dieser Projektgr├Â├če aber sagt die Kombination aus Linus' Gesetz und Haslers Gesetz voraus, da├č die Kosten und Probleme des traditionellen Managements viel schneller anwachsen als die zu erwartenden Kosten f├╝r doppelt erbrachten Aufwand. Sicher nicht die geringste dieser Kosten entsteht durch die immanente Unf├Ąhigkeit, die Zuwendung sehr vieler Entwickler in effektiver Weise vor den Wagen zu spannen, was aber (wie wir gesehen haben) eine bessere Methode als das traditionelle Management ist, um zu garantieren, da├č keine Bugs und Details ├╝bersehen werden. Daher treibt die Kombination der beiden Gesetze den Nettogewinn aus traditionellem Management praktisch gegen Null, wenn es um gro├če Projekte geht.
  [IN] Ob jemand Projekte von Beginn an als Basar abwickeln kann, h├Ąngt von der Frage ab, ob der Basar wahrlich innovative Arbeit erm├Âglicht. Einige behaupten, da├č der Basar aus Mangel an starker F├╝hrung nur das Klonen und Verbessern von Ideen handhaben kann, die bereits allgemeiner Standard der Ingenieurskunst sind, aber nicht in der Lage ist, dar├╝ber hinaus etwas zum Fortschritt beizutragen. Dieses Argument wurde vielleicht am prominentesten in den ber├╝chtigten Halloween Documents breitgetreten, zwei Microsoft-internen Memoranden ├╝ber das Open Source-Ph├Ąnomen. Die Autoren verglichen Linux' Entwicklung mit der "Jagd von R├╝cklichtern" ("chasing taillights") und dr├╝ckten die Meinung aus, da├č "sobald ein Projekt Gleichstand mit dem State Of The Art erreicht habe, der Aufwand an Management, der f├╝r das Erreichen neuer Fronten notwendig ist, zu hoch wird" ("once a project has achieved "parity" with the state-of-the-art, the level of management necessary to push towards new frontiers becomes massive").
Dabei macht man aber grobe Fehler, die Implikationen dieser ├ťberlegung widersprechen den Tatsachen. Einer wird deutlich, wenn die Autoren der Halloween-Documents sp├Ąter selbst feststellen, da├č "neuartige Ideen der Grundlagenforschung als erstes unter Linux implementiert werden und verf├╝gbar sind" ("often [...] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms").
Wenn wir "Open Source" f├╝r "Linux" einsetzen, sehen wir, da├č dies weit von einer neuen Erscheinung entfernt ist. Historisch gesprochen: die Open Source-Gemeinde erfand Emacs, das World Wide Web oder das Internet nicht durch die Jagd nach R├╝cklichtern oder durch erheblichen Managementaufwand -- und gegenw├Ąrtig geht in der Open Source-Welt soviel an innovativer Arbeit vor sich, da├č man von der Auswahl geradezu verw├Âhnt wird. Im GNOME-Projekt (um willk├╝rlich eines herauszugreifen) begegnen wir zum Beispiel erheblichen Fortschritten auf den Gebieten der graphischen Benutzeroberfl├Ąchen und Objekttechnologie, die bedeutend genug sind, um die Aufmerksamkeit der Fachpresse auch au├čerhalb der Linux-Gemeinde auf sich zu ziehen. Es gibt Berge von anderen Beispielen, wovon sich jeder durch einen Besuch bei Freshmeat selbst ├╝berzeugen kann.
Es gibt aber einen noch fundamentaleren Fehler in der impliziten Annahme, da├č das Modell der Kathedrale (oder das des Basars oder irgendeine andere Form von Management-Struktur) Innovation zuverl├Ąssig erzeugen kann. Das ist Nonsense. Bandenbildung verhilft nicht automatisch zu bahnbrechenden Geistesblitzen -- nicht einmal die Gruppen von freiwilligen Basaranarchisten sind f├╝r gew├Âhnlich zu echter Originalit├Ąt in der Lage, gar nicht zu reden von Kommittees im Bauch von Firmensauriern, deren ├ťberleben von Status Quo Ante abh├Ąngt. Einsichten stammen von Individuen. Das beste, auf das ihre umgebende soziale Maschinerie jemals hoffen kann, ist, auf bahnbrechende Einf├Ąlle f├Ârdernd zu reagieren -- sie zu belohnen und zu testen, anstatt sie zu zermalmen.
Einige werden das als romantische Ansicht sehen, einen weiteren Aufgu├č des ├╝berholten Cliches vom einsamen Erfinder. Das ist es aber nicht; ich unterstelle hier nicht, da├č Gruppen unf├Ąhig sind, bahnbrechende Einsichten weiterzuentwickeln, sobald es sie gibt. Es ist ja so, da├č gerade der Proze├č der Kritik durch andere Teilnehmer (peer review) solche Gruppen in die Lage versetzt, Resultate von h├Âchster G├╝te hervorzubringen. Stattdessen weise ich darauf hin, da├č jede solche Gruppe ihren Anfang -- den notwendigen Funken -- durch eine gute Idee in jemandes Kopf erh├Ąlt. Kathedralen und Basare und andere soziale Strukturen k├Ânnen diesen Geistesblitz aufnehmen und verfeinern, aber nicht auf Kommando erzeugen.
Daher ist die Wurzel der Problemstellung der Innovation (in der Software und auch ├╝berall sonst) mehr die Frage, wie man vermeiden kann, den Funken auszul├Âschen -- oder, noch fundamentaler, wie man m├Âglichst viele Menschen heranzieht, die zu Einsichten und Geistesblitzen f├Ąhig sind.
Einfach anzunehmen, die Software-Entwicklung im Stil der Kathedrale k├Ânnte diesen Trick zustande bringen, aber die geringen H├╝rden und Flexibilit├Ąt des Basars k├Ânnte es nicht, das ist absurd. Wenn es nur einer Person mit einer guten Idee bedarf, um in einem entsprechend gewogenem sozialen Milieu rasch eine Kooperation von hunderten oder tausenden von Teilnehmern zu etablieren, dann wird diese Person jeder anderen mit dieser Idee davonziehen, die sie erst einmal an eine Hierarchie politisch verkaufen mu├č, um daran arbeiten zu k├Ânnen, ohne gefeuert zu werden.
Und, mehr noch: Wenn man die Geschichte der Software-Innovationen betrachtet, die von Organisationen hervorgebracht wurden, die nach dem Modell der Kathedrale arbeiteten, finden wir schnell heraus, da├č dergleichen sehr selten geschieht. Gro├če Firmen sind bei neuen Ideen von der Grundlagenforschung der Universit├Ąten abh├Ąngig (daher die Nervosit├Ąt der Autoren der Halloween Documents dar├╝ber, da├č Linux die Gabe hat, dieser Grundlagenforschung schneller zu entsprechen). Oder sie schlucken kleine Firmen, die um das Gehirn eines Innovators herum aufgebaut sind. In keinem der beiden F├Ąlle ist die Innovation auf dem N├Ąhrboden der Kathedralenkultur entstanden -- viele derart importierten Innovationen enden damit, da├č sie unter dem Druck des "massiven Managements" (wie das die Autoren der Halloween Documents huldigend nennen) still erstickt werden.
Das ist aber ein Negativ-Beispiel. Der Leser w├Ąre durch ein positives besser bedient. Ich schlage daher folgendes Experiment vor:
  1. Greifen Sie irgendein Kriterium f├╝r Originalit├Ąt heraus, von dem Sie annehmen, da├č es durchgehend angewendet werden kann. Wenn Ihre Definition lautet "Ich erkenne es als solches, wenn ich es sehe", dann ist das f├╝r diesen Test auch kein Problem.
  2. Greifen Sie irgendein Closed Source-Betriebssystem heraus, das mit Linux konkurriert und die beste Quelle f├╝r Berichte ├╝ber gegenw├Ąrtige Entwicklungsarbeit an ihm.
  3. Beobachten Sie diese Quelle und Freshmeat f├╝r einen Monat. Z├Ąhlen Sie jeden Tag die Anzahl der Verlautbarungen von Freigaben auf Freshmeat, die Sie f├╝r eine Innovation halten. Wenden Sie die gleiche Definition von "Innovation" auf das andere Betriebssystem an und z├Ąhlen Sie mit.
  4. Nach drei├čig Tagen addieren Sie die jeweiligen Zahlen.
Am Tag als ich dies schrieb, gab es bei Freshmeat zweiundzwanzig Ank├╝ndigungen von Freigaben, von denen drei den State Of The Art in gewisser Hinsicht weiterzubringen scheinen. Das war ein schwacher Tag bei Freshmeat, aber ich w├Ąre erstaunt, wenn es irgendeinem Leser m├Âglich sein sollte, auf irgendeinem Closed Source-Kanal auch auf drei wahrscheinliche Innovationen pro Monat zu kommen.
  [EGCS] Wir k├Ânnen heute auf die l├Ąngere Geschichte eines Projekts zur├╝ckblicken, das einen aussagekr├Ąftigeren Test der Behauptungen ├╝ber den Basar zul├Ą├čt als fetchmail; die Rede ist von EGCS, dem Experimental GNU Compiler System.
Dieses Projekt wurde Mitte August 1997 angek├╝ndigt und war ein bewu├čter Versuch, die Ideen der fr├╝hen Versionen von "Die Kathedrale und der Basar" anzuwenden. Die Gr├╝nder des Projekts standen unter dem Eindruck, da├č die Entwicklung von GCC, des Gnu C Compilers, seit geraumer Zeit stagnierte. F├╝r die zwanzig darauf folgenden Monate f├╝hrte man GCC und EGCS als parallele Produkte weiter -- beide sch├Âpften aus dem selben Pool der Internet-Entwicklerpopulation, beide starteten vom selben GCC-Codestamm und beide verwendeten im gro├čen und ganzen die selben Unix-Tools und -Entwicklungsumgebungen. Die Projekte unterschied nur, da├č EGCS bewu├čt versuchte, die Basar-Taktik anzuwenden, die ich beschrieben hatte, w├Ąhrend GCC seine mehr Kathedralen-artige Organisation beibehielt, die aus einer geschlossenen Entwicklergruppe bestand und nur selten Freigaben durchf├╝hrte.
Das kam einem kontrollierten Experiment so nahe, wie man es sich nur w├╝nschen konnte, und die Resultate waren dramatisch. Innerhalb von Monaten lagen die EGCS-Versionen bei den Features bedeutend in F├╝hrung; bessere Optimierung, bessere Unterst├╝tzung f├╝r FORTRAN und C++. Viele Leute befanden die EGCS-Entwicklungs-Snapshots f├╝r zuverl├Ąssiger als die neuesten stabilen Versionen von GCC und bedeutende Linux-Distributionen begannen, auf EGCS zu wechseln.
Im April 1999 l├Âste die Free Software Foundation (die offiziellen Sponsoren von GCC) die urspr├╝ngliche GCC Development Group auf und h├Ąndigte die Kontrolle ├╝ber das Projekt dem EGCS Steering Team aus.
  [SP] Nat├╝rlich werfen Kropotkins Kritik und Linus' Gesetz allgemeinere Fragen ├╝ber die Kybernetik von sozialen Organisationen auf. Eine davon wird durch ein anderes Volkstheorem der Software-Entwicklung nahegelegt: Conways Gesetz. ├ťblicherweise wird es so formuliert: "Wenn man vier Gruppen hat, die an einem Compiler arbeiten, bekommt man einen 4-Pass-Compiler." Urspr├╝nglich hatte diese Aussage die Form "Organisationen, die Systeme entwerfen, sind auf das Hervorbringen von Entw├╝rfen beschr├Ąnkt, die Kopien der Kommunikationsstrukturen dieser Organisationen sind." Pr├Ągnanter k├Ânnten wir sagen: "Die Mittel bestimmen das Ergebnis", oder noch zackiger: "Proze├č wird Produkt".
Dementsprechend ist es wertvoll festzuhalten, da├č in der Open Source-Gemeinde die organisatorische Form die Funktion auf vielen Ebenen widerspiegelt. Das Netzwerk ist alles und allgegenw├Ąrtig -- nicht nur das Internet, sondern auch die Seilschaften der Teilnehmer formen eine verteilte, locker gekoppelte Arbeitsgruppe ("peer-to-peer network"), die viel an Redundanz bietet und in der alle grazi├Âse Zur├╝ckhaltung zeigen. In beiden Netzwerken ist jeder Knoten nur so weit wichtig, als da├č andere Knoten mit ihm kooperieren wollen.
Die "peer-to-peer"-Charakteristik ist hier sehr bedeutend f├╝r die erstaunliche Produktivit├Ąt der Gemeinde. Was Kropotkin versuchte im Zusammenhang mit Machtverh├Ąltnissen deutlich zu machen, wird durch das "snafu-Prinzip" weiter entwickelt: "Wirkliche Kommunikation kann es nur zwischen Gleichgestellten geben, weil Untergebene in aller Regel eher f├╝r das Erz├Ąhlen von gef├Ąlligen L├╝gen belohnt werden als f├╝r das Sagen der Wahrheit." Kreative Teamarbeit h├Ąngt sehr von echter Kommunikation ab und wird daher durch die Pr├Ąsenz von Machtverh├Ąltnissen ernsthaft behindert. Die Open Source-Gemeinde ist wirklich frei von solchen Machtverh├Ąltnissen und lehrt uns durch ein dazu in krassem Gegensatz stehendes Beispiel, wie teuer Macht ist: hohe Kosten durch Bugs, geringere Produktivit├Ąt und verpennte Gelegenheiten.
Dar├╝ber hinaus sagt das snafu-Prinzip voraus, da├č es in autorit├Ąr orientierten Organisationen einen Realit├Ątsverlust unter Entscheidungstr├Ągern gibt. Er kommt durch die Erscheinung zustande, da├č nach und nach mehr und mehr der Information aus gef├Ąlligen L├╝gen besteht -- die Folgen sind in konventionellen Softwareprojekten klar zu erkennen. Es gibt f├╝r Untergebene sehr starke Anreize f├╝r das Herunterspielen, Verstecken und Ignorieren von Problemen. Wenn dieser Prozess Produkt wird, ist die Software ein Desaster.


© Copyright 2007 - 2010, Bernd Klein mit freundlicher Unterst├╝tzung von Bodenseo, Linux-Kurse und Schulungen,
Foto linke Seite (Mann mit Strick und Colt): Foto: ┬ę Ljupco Smokovski, fotolia 984022