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.