» SelfLinux » Einleitung » Die Kathedrale und der Basar » Abschnitt 10 SelfLinux-0.10.0
zurück   Startseite Kapitelanfang Inhaltsverzeichnis   weiter

SelfLinux-Logo
Dokument Die Kathedrale und der Basar - Abschnitt 10 Revision: 1.3.2.7
Autor:  Eric S. Raymond
Formatierung:  Matthias Hagedorn
Lizenz: OPL
 

10 Der soziale Kontext der Open Source-Software

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 en 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. en Bell Labs, das en MIT AI Lab, en 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 de 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.



zurück   Seitenanfang Startseite Kapitelanfang Inhaltsverzeichnis   weiter