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/