Thema 25:
von Sven Koalick und Rene Herzog


The Cathedral and the Bazaar
von Eric Steven Raymond



Aufbau:

1. Wer ist Eric Steven Raymond?

2. Was ist mit Bazaar & Cathedral gemeint?

3. Open Source Beispiel "Fetchmail"
3.1. Was ist Fetchmail?
3.2. Entwicklungsprozess von Fetchmail

4. Zusammenfassung der bei Fetchmail gewonnen Erkenntnisse

5. Vorraussetzungen für den Bazaar-Stil

6. Der soziale Kontext der Open-Source-Bewegung

7. Über Management und die Maginotlinie

8. Netscape geht auf den Bazar

9. Quellen



"Wenn du in der ganzen Welt herumreisen willst und wenn du willst, dass man dich überall einlädt, um an den verschiedensten Orten Vorträge zu halten, dann schreibe einfach ein Unix-Betriebssystem."
Linus Torvalds



1. Wer ist Eric Steven Raymond?

- allgemein anerkannter "Open-Source-Guru"

- gilt als Sprecher der Linux-Gemeinde (ist aber nicht mehr unumstritten)

- hat an vielen Open-Source-Projekten mitgewirkt (z.B. GNU, Emacs; hauptsächlich im Unix-Bereich)

- lebt zur Zeit in Malvern, Pennsylvania


2. Was ist mit Bazaar & Cathedral gemeint?

- 2 Unterschiedliche Programmier- / Entwicklungsstile

- die Kathedrale bezeichnet den konventionellen Entwicklungsstil

- der Basar steht für den Open-Source-Stil

- basieren auf gegensätzlichen Annahmen über die Natur des Debugging

- bei Kathedralen wird, wie bei den meisten Softwareprodukten, vorher geplant, was, wann, wo, wie und von wem gebaut bzw. entwickelt / geschrieben wird

- beim Basar fügen sich einzelne, relativ unabhängige Teile ohne vorherige Planung zusammen

- die Frage, die sich stellt, ist: "Wie schafft es ein Basar (ein paar unabhängige Programmierer) eine Kathedrale (ein lauffähiges Betriebssystem) zu bauen?"


3. Open-Source-Beispiel "Fetchmail"

3.1. Was ist Fetchmail?

- E-Mail-Software, an der Eric S. Raymond zum ersten Mal die Open-Source-Techniken, mit denen Linux entwickelt wurde, anwendet und testet.

- wurde unter Leitung von Eric S. Raymond mit Hilfe mehrerer Hundert Interessierter gemeinsam entwickelt

3.2 Entwicklungsprozess von Fetchmail

1. Jede gute Software beginnt mit den persönlichen Sehnsüchten eines Entwicklers.

- 1993 E. S. Raymond war für den (kleinen) gratis-ISP Chester County InterLink, den er mitbegründet hatte, tätig

- wollte sich E-Mails automatisch auf den Heimrechner schicken und sich sofort benachrichtigen lassen

- mit seiner damaligen Software war es nicht möglich, da der Heimrechner nicht permanent online war (also keine dauerhafte IP-Adresse hatte)

- suchte nach Programmen, die ihm dies ermöglichen, und fand 3 oder 4

- eine Zeit lang nutze er pop-perl, verwarf es aber, da ein einfaches Antworten nicht möglich war

2. Gute Programmierer wissen, welchen Code sie schreiben sollen. Großartige Programmierer wissen, welchen Code sie umschreiben (oder recyceln) können.

- untersuchte die ihm zur Verfügung stehenden Clients und überlegte, welcher am günstigsten zum Weiterentwickeln wäre

-fand mehrere gute Programme, u.a. auch 'fetchpop' von Seung-Hong Oh, welches er Grundlage nahm, und entwickelte es weiter

3. "Plane etwas wegzuwerfen; du machst es sowieso"
(Fred Brooks, "The Mythical Man-Month", Kapitel 11)


- Wochen später fand er 'popclient' von Carl Harris, dessen Code sauber war und sich noch etwas besser eignete
 
-entschied sich zu wechseln, da mehrere verschiedene Protokolle unterstützt wurden

- nach dem Motto: „Erst wenn es einmal gemacht wurde, weiß man, was man beim 2. Mal besser machen kann.“

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

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

- am 25.6.96 schickte er die ersten Patches an Carl Harris, welcher das Interesse an popclient verloren hatte und die Leitung an Raymond übergab

- Raymond erbte popclient und seinen Benutzerstamm

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

- eines der wichtigsten Prinzipien, da viele Augen mehr sehen als wenige

-durch das Übernehmen des Benutzerstamms standen Raymond sehr viele Augen zur Verfügung

- Ansatz: Debugging ist parallelisierbar

7. Früh veröffentlichen. Oft veröffentlichen. Seinen Usern zuhören.

- durch möglichst viele und möglichst oft erscheinende Releases wurden die User von popclient in den Prozess des Bugfixing mit eingebunden

- die User wurden mit regelmäßigen Releases geradezu für ihre Arbeit belohnt, da sie den Fortschritt ihres gemeinsamen Projekts sehen konnten

8. Wenn man einen ausreichend großen Stamm an Betatestern und Mit-Entwicklern hat, wird jedes Problem schnell identifiziert und die Lösung Jemand  offensichtlich sein.

-oder anders: "Alle Bugs sind trivial, wenn man nur genügend Entwickler hat" ("Linus` Gesetz")

- jedes Problem ist wenigstens für eine Person ersichtlich und für eine (andere) lösbar

- durch die vielen Tester (User) werden Fehler schnell entdeckt, und da alle Mit-Entwickler sind, auch schnell behoben

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

- Raymond begann den Code von popclient zu vereinfachen und zu reorganisieren

-ursprünglich wurde viel Wert auf den Code und weniger Wert auf die Datenstruktur gelegt, Raymond änderte dies, um die Weiterentwicklung zu vereinfachen

- "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." Brooks, Kapitel 9

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

- wie ging Raymond mit seinen Usern um?

    1.Er veröffentlichte früh und oft (fast immer mindestes einmal alle zehn Tage; während Zeiten intensiver Entwicklung einmal pro Tag).

    2.Er fügte seiner wachsenden Beta-Liste jeden hinzu, der ihn zu fetchmail kontaktierte.
   
    3. Er verschickte ausführliche und in lockerem Tonfall gehaltene Ankündigungen, wann immer er eine Freigabe machte, und ermunterte     seine Leute, am Prozess teilzuhaben.

    4. Er hörte auf seine Betatester und befragte sie regelmäßig zu Designentscheidungen und lobte sie, wann immer sie Patches oder             Anregungen lieferten.

- dies ermöglichte eine effektive und motivierende Mitarbeit der zwischenzeitlich über 300 Mitentwickler

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

- Harry Hochheiser war derjenige User, der dem Projekt popclient den entscheidenden Anstoß zu fetchmail gab

- er sandte einen Code für das Weiterreichen von Mail an das SMTP-Port, der alle anderen Modi der Zustellung fast überflüssig machen würde

12. Oft stammen die hervorragendsten und innovativsten Lösungen aus der Erkenntnis, dass die ganze Vorstellung vom Problem falsch war.

- Raymond hatte versucht,  popclient alle möglichen Funktionen zu geben (z.B. viele verschiedene Möglichkeiten und Optionen, Mails zu senden)

- als er einige unwichtige und ersetzbare wegließ, lösten sich viele Probleme beim Schreiben einfach in Luft auf

13. "Perfektion (im Design) ist nicht erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn es nichts mehr wegzunehmen gibt." (Antoine de Saint-Exupéry)


- also wurden diese Features einfach weggelassen und popclient entwickelte sich soweit von seinem Ausgang weg, das eine Namensänderung richtig schien

- aus popclient wurde fetchmail

- Raymond erkannte, dass sich fetchmail mit der Zeit zu einem "Kategorienkiller" entwickeln könnte

- mit dieser Motivation suchte Raymond nach weiteren Verbesserungen und neuen Features

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

- er fand die Multidrop-Unterstützung (rausholen von Mails aus Mailboxen und diese an eine größere Gruppe weiterschicken)

- positiv:
    auch Bugs beim Singledrop wurden entdeckt und entfernt
    bessere Verwaltung von Mailinglisten

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!

- durch Befolgen dieses Satzes wurde bei fetchmail verhindert, dass bei einem Verbindungsabbruch die Daten verloren gingen, da sie bei der Quelle noch vollständig vorhanden waren

16. Wenn Ihre Programmiersprache in keinster Weise Turing-vollständig ist, können Sie sich mit syntaktischen Feinheiten anfreunden.

- die Steuerungssyntax bei Fetchmail ist extrem eingeschränkt

- dadurch leichtes Verstehen der Syntax und geringe Möglichkeit von Ungenauigkeiten  und Verwirrungen mit natürlicher Sprache (Englische Befehle)

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

- bei Fetchmail wird der Passwortschutz nicht mit unterstützt, da jeder den Quellcode zur Verfügung hat und so den Passwortschutz selbstständig umgehen kann

- Passwortschutz wäre nur eine Illusion


4. Zusammenfassung der bei Fetchmail gewonnen Erkenntnisse

1. Jede gute Software beginnt mit den persönlichen Sehnsüchten eines Entwicklers.

2. Gute Programmierer wissen, welchen Code sie schreiben sollen. Großartige Programmierer wissen, welchen Code sie umschreiben (oder recyceln) können.

 
3. "Plane etwas wegzuwerfen; du machst es sowieso"

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

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

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

7. Früh veröffentlichen. Oft Veröffentlichen. Seinen Usern zuhören.


8. Wenn man einen ausreichend großen Stamm an Betatestern und Mit-Entwicklern hat, wird jedes Problem schnell identifiziert und die Lösung Jemand  offensichtlich sein.

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

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

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

12. Oft stammen die hervorragendsten und innovativsten Lösungen aus der Erkenntnis, dass die ganze Vorstellung vom Problem falsch war.

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

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


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!


16. Wenn Ihre Programmiersprache in keinster Weise Turing-vollständig ist, können Sie sich mit syntaktischen Feinheiten anfreunden.


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

18. Um ein interessantes Problem zu lösen, muss man ein Problem finden, für das man sich selbst interessiert.

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.


5. Vorraussetzungen für den Bazaar-Stil

-    Bazar kann nicht bei Null anfangen

-    Dies wurde nicht bei Fetchmail versucht und auch nicht bei Linux

-    Testen und debuggen ja, aber keine grundlegenden Neuentwürfe durch eine ganze Community

-    kann sehr ungeschliffen, von Bugs geplagt, unvollständig und spärlich dokumentiert sein

-    es muss aber bereits laufen, und die Community überzeugen, dass es in Zukunft etwas wirklich „giftiges“ werden kann

-    bei Linux und Fetchmail war vielversprechendes Design am Start, viele Open-Source-Befürworter sind überzeugt davon, dass ein interessantes Design die grundlegende Voraussetzung für das Interesse der breiten Entwicklermasse ist

1. Wichtige Kernkompetenz: Projektleiter sollte hohes Maß an Intuition für gutes Design besitzen ODER das Talent besitzen, gute Designs zu erkennen (letzteres galt für Linus Thorvalds)

-    SMTP Forwarding war bei Fetchmail jene außerordentlich neue Designinnovation

2. Wichtige Kernkompetenz: Der Koordinator oder Leiter eines Basar-Projekts muss mit Leuten umgehen und kommunizieren können.

-    Um eine Entwicklergemeinde aufzubauen, muss man Menschen begeistern und für seine Sache interessieren können und bewirken, dass sie mit dem eigenen Anteil am Aufwand zufrieden sind.


Eric S. Raymond:
„Es ist kein Zufall, dass Linus ein netter Kerl ist, der bewirkt, dass die Leute ihn mögen und ihn unterstützen wollen. Es ist kein Zufall, dass ich ein extrovertierter 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 bisschen Charme hat, um die Menschen für sich einzunehmen.“


6. Der soziale Kontext der Open Source Bewegung

18. Um ein interessantes Problem zu lösen, muss man ein Problem finden, für das man sich selbst interessiert.

- kleine Abwandlung von Regel 1

"Vom Mythos des Mann-Monats" - Fred Brooks

-    Brooks Gesetz: Behauptet, dass die Komplexitäts- und Kommunikationskosten proportional zum Quadrat der Anzahl der Entwickler wachsen, während die vollendete Arbeit nur linear dazu wächst. - Wäre diese Formulierung wahr, würde das Prinzip von Linux nicht funktionieren.

-    Korrektur des Gesetzes: in "The Psychology Of Computer Programming" von Gerald Weinberg: „Programmieren ohne Ego“: Arbeit geht erfahrungsgemäß besser voran, wenn die Coder sich nicht wie „Revierbesitzer“ verhalten

-    Diese Korrektur wurde nie richtig anerkannt, da der Begriff Hacker und das Ego einer Person unweigerlich zusammengehören, dennoch kann dies ein Aspekt sein, der das Bazar-Prinzip ermöglicht

-    Codieren an sich ist „autistische“ Arbeit, aber die Projektierung unter Nutzung der Gehirnpower ganzer Gemeinden beschleunigt die Arbeit ungemein und bündelt Kreativität und Debugging-Zeit
-    Im Falle Unix wurde diese Kraft gebremst: durch Lizenzprobleme, Überstrapazierung des Prinzips (extrem viele Entwickler für einzelne Projekte) und mangelhafte Infrastruktur des Internets

-    Deshalb: der Erfolg von Linux ist stark mit sinkenden Internetkosten und steigender Attraktivität des Internets korreliert (Internet Boom 1993-1994), außerdem werden auch die Entwicklung von geeigneten Führungsstilen und gewisse Verhaltensregeln und Sitten bei der Entwicklung von Open Source Projekten aufgebracht.

 „Prinzip der Übereinkunft“ als Führungsstil im Kontrast zu „Prinzip von Befehl und Bestrafung“

 Die Entwickler müssen aus freien Stücken ein ernstgemeintes gemeinsames Ziel anstreben, unter Zwang wäre Open Source nicht realisierbar

Das Bazar-Prinzip wird mit dem System eines freien Marktes verglichen - Viele Agierende, die ihren eigenen Nutzen maximieren wollen und somit ganz automatisch Teil eines selbstregulierenden Systems werden.

 raffinierter und effektiver als jede zentrale Organisation.

- der eigene Nutzen der Hacker besteht hier darin, dass sie ihre eigene Anerkennung unter „Kollegen“ zu maximieren suchen und ihr    Ego stärken wollen, dies ist in etwa gleichrangig mit dem Nutzen, den sie aus der Verbesserung des Produkts an sich ziehen.
- Gegenargumente gegen „freier Markt“ - Struktur: feindselig, fragmentiert, ressourcenfressend (wie reale Marktwirtschaft)
- Jedoch ist ein guter Koordinator/Projektleiter dazu in der Lage, unter regelmäßiger Pflege des Egos der Hacker deren Kräfte zu bündeln und zu nutzen

 Formulierung im Kontrast zu Brook’s Gesetz:

19. Unter der Vorraussetzung, dass der Entwicklungskoordinator ein Medium zur Verfügung hat, das 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.

Raymond macht folgende Vorhersage: Mehr Leute werden sich von der Kathedrale abwenden hin zum Bazar, denn es wird schwierig und teuer, so wie z.B. bei Fetchmail 1999 600 Leute zu organisieren (und zu bezahlen), die das Projekt erschaffen.

Vielleicht wird sich Open Source nicht aufgrund von moralischen Vorstellungen durchsetzen, sondern eher wird „Closed Source“ im Wettrüsten mit kostenloser „Brainpower“ untergehen (oder zumindest große Marktanteile verlieren).


7. Über Management und die Maginotlinie

Die oben genannten Behauptungen und Beispiele klingen zwar überzeugend, doch gab es viele Skeptiker, die den Text kritisierten.

Zusammenfassung der Argumente: Die Lässigkeit, mit der sich Projektgruppen beim Programmieren auflösen und wieder entstehen, würden die Vorteile der Ansammlung von vielen Menschen als Kreativitätspool wieder wettmachen.

-    nach Ansicht der Skeptiker ist nur nachhaltige Investition in ein Produkt der Schlüssel zur Zufriedenstellung des Kunden
-    sicherlich wird das Ausmaß an Dienstleistung zu einer Software maßgeblich über deren Erfolg bestimmen
-    „nachhaltige Investition“ ist auch durch den ständigen Einsatz von Angehörigen des Bazars in einzelnen Fällen bereits realisiert worden, durch das lange Durchhaltevermögen kleiner Gemeinden, die wirklich die ganze Zeit der Entwicklung über an dem Produkt drangeblieben sind, zielstrebig gearbeitet haben, ohne Aufsicht eines Managements, das von Skeptikern als so wichtig eingeschätzt wird.

Bestes Beispiel: GNU Emacs-Editor - Entwicklung der Software 15 Jahre lang, trotz starker Fluktuation der Entwicklergemeinde und nur der durchgehenden Arbeit einer einzigen Person: des Autors selbst - solche Langlebigkeit entwickelte kein Closed-Source-Editor.

1. Möglichkeit der Anforderungsdefinition an Closed-Source-Management: Was erhoffen sich Entwickler von „Closed Source“-Software also von Ihrer Methode

-    Einhalten von Deadlines?
-    Liefern von zuverlässiger Software?
-    Einhalten von Budgets?

Sicherlich keine der drei Anforderungen, denn kommerzielle Software dieser Art erfüllt selten auch nur 2 davon, auch ist der Wandel und die Anpassung an sich ändernde Spezifikationen nicht unbedingt ein Vorteil dieses Managementstils

 Konversion von Windows 16 Bit zu 32 Bit hat Millionen verschlungen, während dies mit Linux im gleichen Zeitraum fast umsonst geschah (gemessen an diesen Dimensionen).

Viele Nutzer / Unternehmen sehen in Closed Source die Möglichkeit, den Urheber bei Fehlfunktion zu verklagen, doch eher mangelhafte bis gar keine Ergebnisse in der Vergangenheit.

2. Möglichkeit der Anforderungsdefinition an Closed-Source-Management:
1.    Es definiert Ziele und sorgt dafür, dass alle Teilnehmer am selben Strang ziehen.
2.    Es überwacht den Fortschritt und stellt sicher, dass 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.
Viele der Punkte werden doch allein durch die Existenz der Open-Source-Bewegung und ihr erfolgreiches Bestehen entkräftet.

Weitere Argumente:

-    Open Source liefert nur Produkte, wo sich technischer Glamour hervorbringen lässt oder einfach nur Interesse weckt
-    Sollte dies jedoch die einzige „Maginot Linie“ der Closed Source-Technik sein, so wird auch diese in endlicher Zeit fallen (60 - 75% der gemanageten Softwareprojekte scheitern heutzutage - diese sind entweder falsch spezifiziert oder an den Anwendern vorbei spezifiziert - deshalb sinnvoller, wenn die Anwender selbst (oder zumindest ein Teil künftiger Anwender) an der Produktion beteiligt sind)

Aus der Psyche eines jeden Menschen lässt sich schlussfolgern:
-    nichts ist effektiver als das Spielen, ein SW-Entwickler wird effizienter, je mehr Spaß er an der Sache hat und Spaß kommt vom Spielen und von dem eigenen Interesse am Projekt

Open Source ist zwangsläufig effizienter als Closed Source, wo Menschen unter Zwang oder fremden Anreizen Projekte entwickeln, an denen sie keine Freude haben.


8. Netscape geht auf den Bazar

Sieben Monate nach dem eben bearbeiteten Text verlautete Netscape, den Code seines nächsten Projektes im Web zu veröffentlichen.

Dieser Praxistest für das Bazar-Modell würde, so die Prognose des Autors, mit seinem Gelingen oder Scheitern den Bazar praxisreif für die Wirtschaft machen oder diese so sehr abschrecken, dass erstmal weitere 10 Jahre vergehen würden, bis sich jemand diesem Modell wieder annähert.

„Mozilla“ war nur ein teilweiser Erfolg. Microsofts Monopol am Browsermarkt wurde vorerst vereitelt.

-    Jedoch: Netscape gelang es nicht, die Kräfte außerhalb der eigenen Firma erfolgreich zu bündeln, wahrscheinlich, weil einige Grundregeln des Bazars verletzt wurden: Die erste Distribution lieferte nichts anschauliches, leicht lauffähiges. Für das Kompilieren wurde min. 1 Jahr danach noch eine Lizenz für eine sog. Motif-Bibliothek benötigt.  erhebliche Bremse für freie Entwickler.
-    Am erheblichsten vielleicht: Rücktritt eines der Vorstände des Mozilla-Projektes „Open Source ist kein Zauberstab“  Beschwerde über falsche Nutzung der Möglichkeiten

Für die Zukunft sind der Open Source Technik jedoch rosige Aussichten vorherzusagen. Allein durch die fortwährende Entwicklung von Linux erhält die Szene Schwung, und auch Mozilla steht mittlerweile weitaus besser da.


9. Quellen:
http://www.xinux.de/docs/misc/tutor/gurus.htm
http://tuxedo.org/~esr/writings/cathedral-bazaar/