Das Erfolgsgeheimnis von Linux

Die Kathedrale und der Basar

von Eric Raymond (übersetzt von Lukas Müller muellerl@dial.eunet.ch)


Eric Raymond hielt am 4. Linux-Kongress einen Vortrag mit dem Thema die Kathedrale und der Basar. Der Inhalt erläuterte die Hintergründe des unaufhaltsamen Erfolges von Linux. Seine Vermutungen untermauerte er mit Erfahrungen, die er anhand eines Projektes machte, das er basierend auf seinen Thesen durchgeführt hat.

Linux ist durch und durch subversiv. Wer hätte vor ein paar Jahren daran geglaubt, dass ein erstklassiges Betriebssystem durch tausende von Teilzeit-Entwicklern, verteilt um den ganzen Globus und nur durch das Internet verbunden, innerhalb von wenigen Jahren entwickelt werden kann?

Ganz sicher nicht ich. Als Linux auf meinem Radarschirm auftauchte schrieb man das Jahr 1993. Ich war bereits seit einem Jahrzehnt als Entwickler Mitglied der freien Software-Gemeinde. Gleichzeitig war ich einer der ersten GNU-Mitarbeiter in den achtziger Jahren. Ich habe mein Scherflein zur Verbreitung von freier Software beigetragen, indem ich als Entwickler die Früchte meiner Arbeit (nethack, Emacs VC und GUD modes, xlife und einiges mehr) in die Fremde des Internet entlassen habe. Ich dachte ich wüsste wie so was gemacht wird...

Linux erwischte mich auf dem falschen Fuss und belehrte mich eines Besseren. Auch ich habe den Gospel von Unix, d.h. die Predigt der kleinen Tools, des Rapid Prototyping und der evolutionären Programmierung bis zum Umfallen rezitiert. Auch war ich der Meinung, dass Programme, die eine gewisse Komplexität überschritten, nach einem zentralistischen Ansatz verlangen. Ebenso glaubte ich, dass die wichtigsten Programme, worunter Betriebssysteme und sehr grosse Werkzeuge wie Emacs fallen, wie Kathedralen gebaut werden müssen. Von einzelnen, erleuchteten Künstlern oder einer Handvoll auserwählten Baumeistern hinter gut verschlossenen Türen zusammen gebaut, Stein um Stein (lies Zeile um Zeile), mit keinem Betarelease, bevor die Zeit nicht endgültig reif ist.

Linus Torvalds Entwicklungsstil überraschte mich:

gelinde ausgedrückt.

Nicht gerade was man eine ehrfurchtsvolle Kathedralen-Vorgehenweise nennen könnte. Die Linux Gemeinde gleicht schon eher einem grossen plappernden Basar mit verschiedenen Tagesabläufen und Ansätzen (repräsentiert durch die Linux Archive, in die jeder einbringen kann was er will). Dass aus diesen Teilen ein zusammenhängendes stabiles Betriebssystem nur aufgrund einer Reihe von wundersamen Zufällen entstehen konnte, liegt ja wohl auf der Hand.

Die Tatsache, dass die Basar-Entwicklungsmethode zu funktionieren schien, war für mich ein klarer Schock. Als ich mich aufmachte, um des Rätsels Lösung zu finden, musste ich erkennen, dass die Entwicklungsmethode sich nicht nur als praxistauglich erwies, sondern dass sie auch noch schneller war, als es das Kathedralen-Vorgehen wohl je zulassen würde.

In Verlaufe des Jahres 1996 kam ich des Rätsels Lösung langsam auf die Spur. Der Zufall ermöglichte es mir meine Theorie umgehend zu überprüfen. Ich tat dies, indem ich ein weiteres freies Software-Projekt in Angriff nahm. Diesmal jedoch nicht als Kathedralen Baumeister, sondern meiner Theorie entsprechend, dem Basarstil folgend. Nun das Projekt war ein ausgesprochener Erfolg.

Im Rest des Artikels gehe ich näher auf die Geschichte dieses Projektes ein und benütze es, um meine Erkenntnisse im Bereich der Effizienz von freien Software Projekten zu erläutern.

Nicht alles, was ich lernte entsprang der Linux Welt. Noch war es grundsätzlich neu für mich, aber wir werden sehen wie sich die Teile zu einem neuen Ganzen innerhalb der Linux Welt entwickeln. Falls sich meine Theorie bewahrheiten sollte, werdet Ihr verstehen, warum Linux ein solcher Jungbrunnen für gute Software ist - und wie jeder mit Hilfe der Basarmethode produktiver werden kann.

Die Post muss verteilt werden

Seit 1993 betreue ich den frei zugänglichen ISP (Chester County Interlink CCIL) in West Chester Pennsylvania. Ich war ein Gründungsmitglied von CCIL und schrieb hierfür ein Multiuser-bbs-Programm. Interessierte können via telnet auf locke.ccil.org das Resultat begutachten. Heute erlaubt CCIL mehr als tausend Benutzern via 19 Linien Zugang zum Internet. Für diese Entwicklung benötigte ich einen 24 stündigen Zugriff auf eine 56kbps schnelle Verbindung zum Internet via ICCL. Diese wurde mir freundlicherweise zu Verfügung gestellt.

Diesem Umstand ist es zu verdanken, dass ich mich an den Luxus von laufend (unmittelbar) zugestellten Emails gewöhnte. Aus komplizierten Gründen konnte ich SLIP zwischen CCIL und meiner eigenen Maschine (snark.thysus.com) nur schwer davon überzeugen, mir meine Post zuzustellen.... Als ich dies letztlich doch bewerkstelligen konnte, realiserte ich, dass ich regelmässig via telnet meinen Briefkasten überprüfen musste, um über neu eingetroffene Mails im Bilde zu sein. Dies empfand ich als äusserst lästig. Was mir vorschwebte war, dass mir meine Post direkt auf meine Maschine geliefert wird und ich über deren Ankunft informiert werde. Die Post via sendmail einfach an meine eigene Maschine weiterzuleiten würde nicht funktionieren. Da ich im Normalfall weder über eine ständige Verbindung von meiner Maschine zum CCIL Server, noch über eine statische IP Adresse verfüge.

Was ich benötigte, war ein Programm, das via SLIP auf meinen Mail-Account zugreifen und anschliessend meine Post auf meine Maschine abliefern würde. Ich wusste um die Existenz solcher Applikationen (POP Post Office Protocol). Selbstverständlich hatte ich im BSD-basierenden CCIL Server einen POP3-Server eingebaut. Aber nun brauchte ich auch noch einen POP3-Client. Also sah ich mich auf dem Internet um und wurde fündig. Drei bis vier Stück konnte ich lokalisieren. Als erstes verwendete ich popperl für eine Weile, vermisste aber eine augenfällige Eigenschaft: Die Möglichkeit die Absender aus der empfangenen Email zu extrahieren, um komfortable Replies realiseren zu können. Das Problem war folgendes : Angenommen joe (user von CCIL) sendet mir eine Email, so würde mein Mailtool lächelnd meine Antwort an einen inexistenten Benutzer auf den CCIL Server senden... Um dies zu vermeiden, musste ich also mittels Handarbeit die Adresse korrigieren. Je grösser die Anzahl der zu beantwortenden Mails, desto grösser der Aufwand und somit der damit verbundene Ärger. Es ist offensichtlich, dass ein Computer diese lästige Arbeit zu verrichten hat. In der Tat definiert RFC 1123, dass sendmail diese Arbeit zu verrichten hat. Leider verstand es trotzdem keiner der existierenden POP-Clients dies Aufgabe zu lösen... Nun, dies liefert den Grundstein zur ersten Lektion der Basarmethode:

1. Jedes gute Programm hat seinen Ursprung in einer für den Entwickler störenden (nervenden) Unzugänglichkeit.

Vielleicht ist dies offensichtlich, da schon das Sprichwort "Notwendigkeit ist die Mutter der Erneuerung" eben dies besagt. Aber zu oft verbringen SW Entwickler ihre Zeit mit Programmen die sie weder lieben noch gebrauchen...

Nicht so in der Linux Gemeinde (Siehe hierzu auch das Interview mit Dave Miller im Linux Magazin 07/1997). Was vielleicht erklärt, wieso die Qualität der Software, die der Linuxgemeinde entspringt, so hoch ist.

Also was machte ich wohl als nächstes? Heute noch mit der Implementation eines weiteren POP3-Clients von Grund auf neu zu beginnen, um mit den bereits realisierten Clients um die Gunst der Benutzer zu buhlen... Nein nie im Leben!!! Ich lehnte mich zurück, betrachtete die vorhandenen Implementationen sorgfältig und fragte mich, welche meiner Vorstellung am ehesten entsprach. Weil:

2. Gute Programmierer wissen, was geschrieben werden muss. Grosse Programmierer wissen, was neu geschrieben werden muss und was wiederverwendet werden kann (der grüne Punkt lässt grüssen :))

Ich gebe nicht vor ein grosser Programmierer zu sein, aber ich versuche einen zu imitieren...

Eine wichtige Eigenschaft der Mitglieder der Hall of Fame ist die konstruktive Faulheit. D.h. sie wissen, dass man eine "1" ("6" für CH Bürger) nicht für den geleisteten Aufwand, sondern für das gelieferte Resultat, erhält. Ebenfalls ist es fast immer einfacher auf einer bestehenden Lösung, als auf der grünen Wiese zu beginnen.

Linus z.B. versuchte nicht Linux von Grund auf neu zu entwickeln. Stattdessen verwendete er Programmkode von Minix, einem UNIX-ähnlichen Betriebssystem für Intel 386 Prozessoren. Letztendlich war der Minix Programmkode vollständig umgeschrieben oder ersetzt. Während der Bauphase (Entwicklungszeit) bildete Minix eine zuverlässige Basis, um das Neue zu realisieren: LINUX.

Auf dieselbe Art und Weise wählte ich einen existierenden POP-Client aus. D.h. er musste gut genug geschrieben sein, um als Entwicklungsbasis für meinen neuen POP3-Client zu dienen.

Seit langem ist es eine Tradition in der Unixwelt Quellkode frei verfügbar zu machen und so die Wiederverwendung zu fördern. Dies ist auch der Grund wieso GNU trotz ihrer Animositäten gegenüber Unix als Betriebssystem diese als Basis für ihre Entwicklungen wählte. Die Linuxgemeinde wiederum hat diese Tradition fast bis zur Grenze des technisch Machbaren katapultiert. Gibt es doch Terabytes von Linux-basierenden Programmen, die einer breiten Öffentlichkeit frei zugänglich sind. Somit ist es nirgends so wahrscheinlich wie in der Linuxwelt auf ein Stück Quellkode zu stossen, das dem Gesuchten fast entspricht.

So war dies auch in meinem Fall. Mit den Programmen, die ich in meinem ersten Beutezug fand und denjenigen des zweiten kam ich auf stolze neun Kandidaten (fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop). Ich wählte als erstes fetchpop von Seung-Hong Oh. Ich habe meine Erweiterungen eingebaut und getestet (neben vielen Verbesserungen auch die Extraktion der Email-Adresse des Sender). Der Autor akzeptierte diese und baute sie in die offizielle Version 1.19 mit ein.

Einige Wochen später stolperte ich über den Quellkode von popclient von Carl Harrys und merkte, dass ich ein Problem hatte... Obwohl fetchpop ein paar gute Designansätze enthielt (z.B. den dämon Modus), beherrschte es nur das POP3-Protokoll und war aufgrund der Unerfahrenheit des Entwicklers nicht sehr sauber implementiert. Carls Programm dagegen war solide implementiert, jedoch fehlten einige wichtige fetchpop Funktionen. Insbesondere meine Erweiterungen sowie einige andere nicht einfach zu implementierende Eigenschaften.

Nun musste ich mich entscheiden, ob ich die bisherigen Erweiterungen fallen lassen wollte, um mit einer solideren Entwicklungsbasis weiter arbeiten zu können.

Ein Entscheidungskriterium war die Existenz der Unterstützung verschiedener Protokolle durch popclient. POP3 ist zwar dasjenige Post Office Server Protocol mit der grössten Verbreitung, aber nicht das einzige...Fetchpop und alle anderen clients waren nicht in der Lage, andere Protokolle zu unterstützen. Im weiteren hatte ich die Idee IMAP (Internet Message Access Protocol), das neuste und leistungsfähigste Post Office Protocol zu implementieren.

Es gab aber auch noch einen theoretischen Grund, wieso ich mich für einen neuen Client entschied. Diesen Grundsatz lernte ich lange bevor ich den Weg von Linux kreuzte:

  1. Plane etwas wegzuschmeissen, denn du wirst es so oder so tun [2]

Oder anders rum ausgedrückt, man versteht ein zu lösendes Problem erst nachdem man es (mindestens) einmal gelöst, sprich implementiert hat. Beim zweiten Versuch besteht somit die reelle Chance es richtig zu machen. Es kann also nichts schaden sich von Beginn weg auf einen neuerlichen Neuanfang einzustellen.

Also sagte ich mir, dass meine Änderungen an fetchpop mein erster Versuch war und erkor popclient zu meinem zweiten. Nachdem ich meine Änderungen am 25. Juni 1996 an Carl Harrys sandte, stellte sich heraus, dass er die Lust an der Weiterentwicklung an popclient vor einiger Zeit verloren hatte. Der Programmkode war noch fehlerbehaftet und etwas verstaubt. Ich hatte noch viele Änderungen geplant und so war es nur logisch, dass die ganze Sache unter meine Fittiche wechselte.

Ohne dass ich es richtig wahrnahm, tauschte ich meine Rolle vom "Mittäter" zum "Drahtzieher" von popclient. Gleichzeitig spürte ich aufgrund der Ideen , die noch in meinem Kopf rumgeisterten, dass mir noch grundlegende Änderungen bevorstanden.

Die Software-Kultur der freien Verfügbarkeit unterstüzt ein solches Vorgehen in natürlicher Art und Weise. Ich leitete aus diesen Erfahrungen einen weiteren Basarmethodenansatz ab:

  1. Wenn Du die richtige Einstellung hast, finden die interessanten Probleme Dich!

Aber Carls Einstellung war noch wichtiger und er wusste das :

  1. Wenn Du das Interesse an einem Programm verloren hast, ist es Deine letzte Aufgabe, es in fachkundige Hände weiterzureichen

Ohne dass Carl und ich uns über dies unterhielten, hatten wir dasselbe Ziel. Wir suchten gemeinsam die beste Lösung für popclient. Sobald ich ihn davon überzeugt hatte, dass ich seine Arbeit zweckdienlich weiterführen würde, übergab er mir das Steuer für die Weiterentwicklung. Ich hoffe, dass ich in derselben Art das Steuer aus der Hand geben werde, wenn meine Zeit als Kapitän von popclient abgelaufen ist.

Von der Wichtigkeit Benutzer zu haben

So erbte ich popclient und damit , was viel wichtiger war, eine Benutzergruppe! Benutzer zu haben ist etwas Wundervolles. Nicht nur weil sie einem das Gefühl geben, ein Bedürfnis zu erfüllen, sondern weil sie einem wissen lassen, wenn man etwas richtig macht. Falls man es versteht, die Benutzer zu motivieren werden sie zu Mitentwicklern.

Eine weitere Stärke der Unixtradition, insbesondere derjenigen der Linuxgemeinschaft ist es, dass viele Benutzer auch selber entwickeln. Da der Quellkode frei verfügbar ist, machen viele ausgiebig Gebrauch davon. So tragen sie zu Fehlersuche, Fehlerbehebung sowie Programmverbesserung bei. Motiviert man also seine Benutzer zur Mitarbeit, beschleunigen sie den Entwicklungsvorgang in einem Masse, wie es dem Autor alleine nie möglich wäre.

  1. Seine Benutzer als Mitentwickler einzubeziehen, ist die einfachste Art ein Programm zu verbessern und die Effizienz der Fehlersuche zu steigern

Die Wirkung dieser Methode wird oftmals drastisch unterschätzt. In der Tat, alle von uns (freien Software-Entwicklern) haben nicht realisiert, um wieviel die Komplexität eines Problems oder eines Systems mit der Hilfe einer Benutzergruppe reduziert werden kann. Bis Linus uns mit Linux die Augen öffnete und uns eines neuen belehrte...

Offen gesagt glaube ich, dass die genialste und folgenträchtigste Neuerung von Linus nicht die Kernelentwicklung selbst, sondern die des Linux Entwicklungsmodells war. Als ich ihm meine Sichtweise bei einem Treffen einmal erläuterte, lächelte er und wiederholte eine Aussage, die er oft wiederholt: Ich bin eigentlich ein sehr träger Mensch, der es liebt das Ansehen "einzuheimsen", dass anderen gebührt. Träge wie ein Fuchs oder wie Robert Heinlein vielleicht gesagt hat, zu faul um einen Fehler zu begehen.

Rückblickend kann man die GNU Emacs Lisp Library und die Lisp Programm Archive als Vorgänger des Linux Entwicklungsmodel ansehen. Im Unterschied zur Kathedralenmethode des Emacs C-Kern und den meisten anderen FSF Werkzeugen, war die Entwicklungsmethode der Lisp Programmarchive sehr benutzerorientiert. Ideen und neue Emacs-Modi wurden oft drei bis viermal neu geschrieben, bis sie einen stabilen Zustand erreichten. Eine lose Zusammenarbeit via Internet im Stile von Linux fand ebenfalls statt.

Tatsächlich war mein erfolgreichstes Programm vor der Entwicklung von fetchmail wahrscheinlich der Emacs VC mode. Die Frucht einer vierköpfigen Zusammenarbeit, wovon ich bis zum heutigen Tag nur einen persönlich getroffen habe, Richard Stallman. Es war ein Front-End innerhalb des Emacs für SCCS, RCS und dem später folgenden CVS, dass einen "one-touch" Versionenkontrollmodus ermöglichte. Diese Erweiterung basierte auf einem winzigen ungeschliffenen sccs.el Modus, den jemand anderer geschrieben hatte. Die Entwicklung des VC Modus war erfolgreich, weil im Gegensatz zum Emacs selbst, der Emacs Lisp Code kurze Entwicklungszyklen ermöglichte (Release/Test/Improve).

Veröffentliche früh, veröffentliche oft

Für das Linux - Entwicklungsmodell ist es entscheidend, dass möglichst früh und häufig neue Programmversionen veröffentlicht werden. Die meisten Entwickler (mich eingeschlossen) glaubten, dies sei eine schlechte Strategie, um Programme, die eine gewisse Komplexität überschreiten, zu realisieren. Die Angst war, die Benutzer zu verärgern und ihre Geduld übermässig zu strapazieren, mit neuen unausgereiften Versionen, die per Definition fehlerbehaftet sind.

Dieser Glaube untermauerte die allgemeine Verpflichtung gegenüber der Kathedralenmethode, b der als übergeordnetes Ziel eine möglichst fehlerfreie Programmversion proklamiert wurde. Es liegt auf der Hand, dass dies nur mittels grosser Veröffentlichungsintervale zu erreichen war, da man die Zeit zwischen zwei Veröffentlichungen benötigte, um wie ein Berserker nach Fehlern zu suchen. Der Emacs C-Kern wurde so entwickelt. Die Lisp Library hingegen nicht, da es Lisp Archive gab die ausserhalb des Einflussbereiches der FSF waren. Dort konnte man unabhängig vom starren Zyklus der Emacs C-Kern Veröffentlichungen, neue Entwicklungen einbringen und "abholen".

Das wichtigste Archiv des Emacs war das Ohio State Lisp Archive, nahm es doch viele Eigenschaften sowie einen Teil der Stimmung der heutigen Linuxgemeinde vorweg. Aber kaum jemand von uns verschwendet einen Gedanken bezüglich unseres Vorgehens. Dass die alleinige Existenz eines solchen Archives die Kathedralenmethode in Frage stellte, fiel niemandem auf...Im Juni 1992 unternahm ich den ernsthaften Versuch die Ohio Lisp Library in die offizielle Emacs Lisp Library einzubauen. Ich scheiterte kläglich am politischen Widerstand der FSF.

Aber schon ein Jahr später, als die Verbreitung von Linux sprunghaft anstieg, zeichnete sich am Horizont eine Wachablösung ab. Die offene Entwicklungspolitik war das pure Gegenteil der Kathedralenmethode. Das Sunsite und die tsx-11 Archive keimten unaufhörlich und bereits wurden erste Linux Distributionen auf CD Rohlinge gepresst. All diese Aktivitäten wurden durch einen noch nie dagewesenen Austoss an neuen Kernelversionen beflügelt.

Linus behandelte seine Mitentwickler auf die effizienteste aller möglichen Arten :

  1. Veröffentliche früh, veröffentliche oft und höre auf deine Benutzer

Das Innovative von Linus war nicht die Art und Weise, wie er die Sache anging, sondern lag vielmehr darin, wie er die Intensität entsprechend der Komplexität seines Vorhabens anpasste. In diesen frühen Linux Tagen war es nicht Aussergewöhnliches, dass Linus mehr als einen neuen Kernel pro 24 Stunden veröffentlichte. Und weil er die Hilfsbereitschaft seiner Benutzer kultivierte und die Hebelkraft des Internets besser zu nutzen wusste als jeder vor ihm, war sein Vorhaben von durchschlagendem Erfolg gekrönt.

Aber weshalb funktionierte es? War es etwas, dass ich duplizieren konnte, oder war es etwas einmaliges, dass unabdingbar mit Linus selbst zu tun hatte?

Ich glaubte nicht an die Tatsache, dass der Ursprung dieses Erfolges etwas rein Linus spezifisches ist. Zugegeben er ist ein ausgezeichneter Entwickler, wer von uns wäre schon in der Lage einen produktionsreifen Unix Kernel zu schreiben??? Aber Linux repräsentiert auf der anderen Seite keine grundsätzlich neuen Konzepte, vor denen man in Ehrfurcht zur Salzsäule erstarren müsste. Linus ist kein (zumindest bis dato) innovatives Entwurfsgenie wie z.B. Richard Stallman oder James Gosling eines ist. Er ist für mich eher ein genialer Entwickler mit einem sechsten Sinn Design-Fettnäpfchen und Sackgassen zu umgehen. Und er hat den Dreh raus mit schlafwandlerischer Sicherheit denjenigen Weg zwischen Punkt A und B einzuschlagen, der den geringsten Widerstand in sich birgt. Tatsächlich widerspiegelt der Gesamtaufbau von Linux diese Kerneigenschaften von Linus, sich an bekannten Ansätzen zu orientieren und diese möglichst geradlinig umzusetzen.

Also wenn die rasche Verbreitung neuer Versionen und die Hebelwirkung des Internets keine Un- oder Zufälle waren. Sondern vielmehr ein integraler Bestandteil, um den Weg des geringsten Widerstandes aufzuspüren. Worauf in aller Welt basierte der Unterschied?

Anders herum ausgedrückt beantwortet sich die Frage von selbst... Linus stimulierte und belohnte seine Benutzer mit der Gewissheit, ein Teil einer lohnenden Sache zu sein und regelmässig mit Verbesserungen versorgt zu werden, an denen man seinen Anteil hat. Er versuchte die Anzahl Personenstunden, die ein konkretes Problem zur Fehleraufindung oder dessen Behebung benötigt, zu maximieren. Sogar unter dem Risiko, die Benutzer vermehrter Instabiliät auszusetzen und sie so zu demotivieren, falls sich ein Problem als unlösbar oder nicht eruierbar erweisen sollte. Linus verhielt sich nach etwa nach folgendem Grundsatz:

  1. Kann man auf eine genügend grosse Anzahl von Mitentwicklern zählen, lässt sich praktisch jedes Problem schnell charakterisieren und die Lösung ist für einen der Beteiligten offensichtlich.

Oder weniger formal ausgedrückt, hat man genügend hilfreiche Köpfe, werden alle Fehler offensichtlich. Ich nenne dies das Gesetz von Linus.

Meine erste Formulierung hiess, alle Fehler werden für jemanden offensichtlich sein. Linus wandte dazu ein, dass derjenige der den Fehler behebt, oft nicht derjenige ist, der ihn findet. "Jemand findet den Fehler" sagt Linus "und ein anderer versteht ihn". Ich sage die grössere Herausforderung sei das Auffinden. Doch das wichtigste ist, dass mit der Basarmethode beides ungeheuer schnell von statten gehen kann...

Hierin liegt der Hauptunterschied der Kathedralen- und der Basarmethode. In der Sichtweise der Kathedralen- Vorgehensweise, sind Fehler um jeden Preis auszumerzen. Das kann nur gelingen, wenn eine auserwählte Schar von Hackern sich über Monate vergewissert, dass dem auch so ist. Dieses Vorgehen führt unweigerlich zu langen Pausen zwischen den Programmversionen und zu herben Enttäuschungen, sollten sich die Neuerungen doch nicht als fehlerfrei herausstellen.

In der Sichtweise der Basarmethode geht man vom Gesetz des Linus aus. D.h. wird ein Fehler ins Rampenlicht der Öffentlichkeit gezerrt, ergibt er sich innert kürzester Zeit mehr oder weniger freiwillig den Pinguinen. Folglich veröffentlicht man öfters, damit mehr Fehler korrigiert werden. Ein positiver Nebeneffekt dieser Politik ist, dass sich der Schaden in engen Grenzen hält, falls sich einmal ein Lapsus eingeschlichen haben sollte.

Und damit hat sichs... That's it! Falls das Gesetz von Linus falsch ist, dann müsste jedes System mit der Komplexität des Linux Kernels, dass von so vielen Entwicklerhänden geformt wurde, unweigerlich unter Last der unzähligen unvorhersehbaren Interaktionen und unauffindbaren Fehlern zusammenbrechen. Falls es aber zutreffen würde, wäre dies eine ausreichende Erklärung für den relativen Mangel an Fehlern im Linux Kernel.

Nun vielleicht sollte dies eine nicht allzu grosse Überraschung sein. Fanden Soziologen schon vor Jahren heraus, dass eine gemittelte Aussage innerhalb einer Gruppe derselben Leute ( Entwickler, Pfarrer oder andere Experten) mehr Aussagekraft hat, als diejenige eines Einzelnen aus dieser Gruppe. Dies nennt man den Delphi-Effekt. Linus zeigt auf, dass dies sogar für die Entwicklung eines Unix-Kernels zutrifft; dass der Delphi-Effekt die Komplexität eines Bestriebsystemes zähmen kann.

Ich verdanke Jeff Dutky's [4] folgende Interpretation des Gesetzes von Linus: Debugging ist parallelisierbar. Jeff erkannte, dass Leute die Fehler suchen, zwar mit dem Autor kommunizieren müssen, es jedoch zwischen den "Fehlersuchenden" nur einer losen Koordination bedarf. Ganz im Gegensatz zur Problematik, des Vergrösserns eines Entwicklerteams während eines laufenden Projektes (Quadratische Zunahme des Koordinationsaufwandes sowie dessen Komplexität siehe [2]).

In der Praxis ist der theoretische Effizienzverlust, aufgrund der Duplizierung der Arbeit der Fehlersuchenden (Im "Normalfall" suchen mehrere Leute geichzeitig einen Fehler) in der Linuxwelt, nie ein Thema gewesen. Die Auswirkung der veröffentliche früh und oft Politik, ist die Minimierung solcher Verluste durch die rasche Verbreitung der Fehlerkorrektur.

Fred Brooks [4] liefert eine Faustregel im Stile derjenigen von Jeff: Die gesamten Kosten der Fehlerbehebung eines Programmes, mit einer genügend grossen Benutzergruppe, verschlingt etwa 40% der Entwicklungskosten. Pikanterweise sind die Fehlerbehebungskosten stark von der Anzahl Benutzer abhängig... Je mehr Benutzer, desto mehr Fehler (meine Aussage).

Mehr Benutzer finden mehr Fehler, da die Zahl der unterschiedlichen Bedienungsvarianten zunimmt. Dieser Effekt verstärkt sich, falls die Benutzer gleichzeitig als Mitentwickler mit tun. Jeder packt die Fehlersuche, aufgrund seiner Sichtweise, ein bisschen anders an. Jeder besitzt ein eigenes Testbett. Der Delphi-Effekt scheint genau aufgrund dieser Variation der Testumgebungen sowie der Testphilosophien zu funktionieren. Im spezifischen Umfeld der Fehlerbehebung, reduzieren diese Variationen die sinnlose Duplikation der Bemühungen.

Die Vergrösserung der Gruppe der Betatester reduziert die Komplexität des "aufwendigsten" Fehlers, aus der Sicht des Entwicklers, nicht zwingend. Aber es vergrössert die Wahrscheinlichkeit, dass die Testumgebung eines Mitentwicklers dem Fehler zum Verhängnis wird, ungemein.

Linus hat für den Fall eines gravierenden Fehlers, mit jedem Linux Benutzer eine Risikoversicherung abgeschlossen...Wie wir alle wissen, kann jeder frei wählen, ob man die letzte stabile Kernelversion installieren will, oder die aller heisseste mit erhöhtem Fehlerrisiko, dafür den neusten Errungenschaften (Signalement : gerade/ungerade Kernelversionsnummern). Leider wird zum heutigen Zeitpunkt Linus in dieser Beziehung noch zu selten kopiert. Die Wahl dem Benutzer zu überlassen macht beide Versionen wesentlich attraktiver.

Infos
[1]
Erics Ramonds hompage http://locke.ccil.org/~esr/
[2]
Fred Brooks "The Mythical Man Month" ISBN 0-201-00650-2
[3]
Robert Heinlein ein search auf AltaVista ergab, dass es sich vermutlich um einen Sience Fiction Autor handeln muss...Wer weiss mehr ???
[4]
Jeff Dutkys dutky@wam.umd.edu

Der Übersetzer

Lukas Müller verdient seinen Lebensunterhalt zur Zeit als Ingenieur bei der Telecom PTT. Seine Freizeit verbringt er mit seiner drei Monate alten Tochter Francesca. Was an Zeit noch übrig bleibt, wird zu nicht ganz gleichen Teilen in Sport und Linux-Projekte sowie die Pflege der partnerschaftlichen Beziehung zu seiner Frau investiert.

Copyright © 1997 Linux-Magazin Verlag

Zurück zu Hintergrundinformationen