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ässt:
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 ist nicht neu.
Der interessante Punkt hier, der Punkt, vom dem die Geschichte
von Linux und fetchmail verlangt, dass 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, dass
Programmiererzeit nicht gut stapelbar ist -- mehr Entwickler in ein
verschlepptes Software-Projekt zu werfen verschleppt es nur noch mehr.
Er 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. 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, in Englisch bei
DORSET HOUSE PUBLISHING CO., INC.)
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, dass 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, dass
diese Analyse die verdiente Akzeptanz erhielt -- man muss unwillkürlich
lächeln bei dem Gedanken, Internet-Hacker als ohne Ego zu
bezeichnen. Aber ich denke, dass 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 verhinderte ein solches Vorgehen
aufgrund verschiedener Faktoren.
Einer davon waren die juristischen Einschränkungen der verschiedenen
Lizenzen, Firmengeheimnisse und kommerziellen Interessen.
Ein anderer war (rückblickend), dass das Internet
einfach noch nicht gut genug war.
Vor dem billigen Internet gab es einige geographisch kompakte
Gemeinschaften, deren Kultur zu Weinbergs Programmieren ohne Ego
ermunterte, und ein Entwickler konnte leicht viele kompetente Kiebitze
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 bewusste und erfolgreiche
Anstrengung unternahm, die ganze Welt als seinen Pool von Talenten zu
verwenden. Ich glaube nicht, dass es Zufall ist, dass 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, dass es die einzige war. Ein
weiterer wichtiger Faktor war die Entwicklung eines Führungsstils und
eines Repertoires 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 musste 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
ernst gemeinte Anstrengung übereinstimmender Willen erreicht werden."
Die ernst gemeinte 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 vergisst man dann den Umstand, dass 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
dass 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 Übereinkunft
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 alleine durch nachhaltige Kooperation in
Bewegung gehalten werden kann. Mit dem fetchmail-Projekt habe ich
gezeigt (zugegebenermaßen in viel kleineren Dimensionen), dass seine
Methoden mit gutem Erfolg nachgeahmt werden können. Vielleicht habe
ich es sogar etwas bewusster und systematischer getan als er.
Viele Leute (besonders jene, die freien Märkten aus ideologischen
Gründen misstrauen) würden von einer Kultur von Egoisten erwarten, dass
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, dass Programmierer das Dokumentieren
hassen. Wie kommt es dann, dass 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, dass
durch angemessene Pflege der Egos vieler anderer Hacker ein starker
Entwickler/Koordinator das Internet verwenden kann, um in den Genuss
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 Voraussetzung, dass der Entwicklungskoordinator ein
Medium zur Verfügung hat, dass wenigstens so gut ist wie das Internet,
und dieser Koordinator weiß, wie man ohne Zwang führt, werden viele
Köpfe zwangsläufig besser arbeiten als nur einer.
Ich glaube, dass 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, dass individuelle Weitsicht und individuelle
Brillanz nicht mehr zählen werden. Ich denke, dass 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, dass Kooperation moralisch richtig oder das Horten von
Software moralisch verwerflich ist (was unterstellt, dass 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.
|