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, dass 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, dass Benutzer so wenige Fehler 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, dass 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  http://metalab.unc.edu/) 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, dass 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 Betriebssystem-Kernel 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 aufeinander folgende Releases und die kompromisslose 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, dass sich möglicherweise Instabilitäten in den Code schleichen und die Benutzerbasis ausgebrannt werden konnte, falls sich irgendein Fehler 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, dass jedes Problem wenigstens für irgend jemanden offensichtlich sein wird. Linus wendete ein, dass 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, dass das Auffinden der schwierigere Teil davon ist. Der springende Punkt hier ist aber, dass 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, tief gehende 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 lang erwartete Release nicht fehlerfrei ist.

Die Auffassung hinter dem Basarstil ist eine ganz andere. Man geht davon aus, dass 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 herum trampeln. Dementsprechend führt man sehr oft Freigaben durch, um so zu mehr Korrekturen zu kommen, und ein nützlicher Nebeneffekt ist, dass man weniger zu verlieren hat, sollte gelegentlich eine besonders verunglückte zur Tür hinaus gelangen.

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 die relative Fehlerfreiheit von Linux zu erklären und auch, dass 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, dass 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, dass es das ist, was Linus gezeigt hat: Diese Erscheinung lässt 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, dass die Teilnehmer an einem Projekt sich praktisch selbst auswählen. Einer der Teilnehmer der ersten Stunde wies darauf hin, dass 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, dass Linus' Gesetz auch zu Debugging lässt sich parallelisieren umformuliert werden kann. Jeffs Beobachtung ist, dass obwohl Debugging vom Debuggenden wenigstens ein bisschen 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üh 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, dass irgend jemandes Methoden an das Problem dermaßen gut angepasst sind, um dieser Person trivial zu erscheinen.

Aber auch Linus will nicht alles auf eine Karte setzen. Für den Fall, dass es tatsächlich schwer zu behebenden Fehlern gibt, sind die  Versionen des Linux-Kernels so nummeriert, dass 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.