Nach einem skeptischen Blick auf ein bestehendes Modell sollten wir versuchen ein anderes, besseres zu entwickeln - eine nach streng wirtschaftswissenschaftlichen Methoden geschaffene Erklärung dafür, was Open Source-Kooperation Nachhaltigkeit und Bestand ermöglicht.
Diese Frage erfordert Untersuchungen auf mehreren Ebenen. Die eine ist die des Verhaltens von Individuen, die zu Open Source- Projekten beitragen; eine weitere die des Verständnisses der ökonomischen Kräfte, die das kooperative Verhalten bei konkreten Projekten wie Linux oder Apache antreiben.
Wieder müssen wir zuerst einmal mit einem weit verbreiteten Folkloremodell aufräumen, das uns am Weg zu einem umfassenden Verständnis behindert. Die Falle, in die wir hier gehen könnten, kann man nach Garret Hardins berühmter Parabel als die Tragedy of the Commons (ungefähr: "Die Tragödie der Kommune") bezeichnen.
Hardin fordert auf, sich eine Wiese vorzustellen, die in einem Dorf von Bauern (den "commons") als allgemeines Gut und als Weidefläche verwendet wird. Das Abgrasen aber macht die Kommune ärmer, da zu viele Halme aus dem Boden gerupft werden und die Wiese nach und nach in einen schlammigen Grund verwandelt wird. Wenn es keine abgemachte (und auch exekutierte!) Politik gibt, um die Nutzungsrechte so zu rationieren, daß Überweidung verhindert wird, dann werden die beteiligten Bauern nur den Anreiz haben, so viel Vieh wie möglich über die Wiese zu treiben, um ihren Anteil daran zu maximieren, bevor das allen gehörende Grundstück völlig ruiniert ist.
Die meisten Menschen wissen intuitiv, wie kooperatives Verhalten funktioniert. Obwohl ihre Vorstellung eigentlich keine gute Entsprechung der ökonomischen Problemstellungen der Open Source-Bewegung ist, steht diese Analogie hinter den meisten der Einwände, die ich gegen Open Source höre.
Die Tragödie der Kommune läßt nur drei mögliche Ausgänge der Geschichte zu. Der eine ist die Schlammruine. Ein weiterer die eines Despoten, der dem Dorf eine Rationierungspolitik auferlegt (die kommunistische Lösung). Die dritte Möglichkeit ist die Aufteilung der Grundrechte: die Bewohner zäunen einen Teil für sich ein und sind für das Haushalten mit ihrem Stück Wiese selbst verantwortlich (die Grundbesitzer-Lösung).
Wenn Leute dieses Modell reflexiv auf die Open Source- Kooperation anwenden, erwarten sie Instabilität mit einer kurzen Halbwertszeit. Da es keine offensichtliche Möglichkeit gibt, eine Rationierungspolitik für Entwicklerzeit über das Internet zu exekutieren, führt dieses Modell geradewegs zur Vorhersage, daß die Bauern sich zerstreiten werden, daß kleine Stücke der Software in Closed Sources verschwinden werden, und immer weniger Arbeit in den allgemeinen Pool zurückgespeist wird.
Tatsächlich kann empirisch nachgewiesen werden, daß das genaue Gegenteil der Fall ist. Umfang und Tiefe von Open Source- Entwicklungen nimmt ständig zu (was man, zum Beispiel, an der Anzahl der täglichen Ankündigungen bei freshmeat.net oder Beiträgen messen kann, die täglich an Metalab geliefert werden). Klar erkennbar gibt es einen kritischen Fehler in der Anwendung der Tragedy of the Commons, um zu erklären, was hier vorgeht.
Die Antwort liegt zum Teil in dem Umstand begründet, daß der geringe Individualwert der kleinen Happen, die zum allgemeinen Codepool beigetragen werden, nur schwer zu vergüten ist. Nehmen wir an, ich schreibe eine Korrektur eines irritierenden Softwarefehlers, und nehmen wir an, eine lange Reihe von Leuten erkennt, daß dieser Fix für sie einen gewissen Geldwert hat. Wie hebe ich eine Gebühr von diesen Leuten ein? Konventionelle Zahlungssysteme haben so hohe Unkosten, daß er für die hier angebrachten Kleinstbeträge zu einem echten Problem wird.
Noch treffender könte die Beobachtung sein, daß dieser Wert nicht nur schwer einzutreiben, sondern oft sogar schwer zu bestimmen ist. Lassen Sie uns ein Gedankenexperiment machen. Nehmen wir, daß Internet wäre mit einem idealen Verrechnungssystem für sehr geringe Beträge ("Micropayments") ausgestattet - hochsicher, allgemein verfügbar, keine Unkosten. Nehmen wir weiter an, Sie hätten Korrekturcode mit dem Titel "Diverse Korrekturen für den Linux-Kernel" geschrieben. Woher wissen Sie, wieviel Geld Sie dafür verlangen können? Wie würde ein potentieller Käufer, der ihr Paket ja nicht kennt, wissen, wieviel es wert ist?
Was wir hier vorfinden, ist ein Zerrbild von F. A. Hayeks "Kalkulationsproblem" - der Handel mit dem korregierten Code verlangt ein übernatürliches, allwissendes Wesen, das nicht nur den Wert berechnen kann, sondern dem auch genug getraut wird, um den Preis entsprechend festzusetzen.
Unglücklicherweise sind allwissende Wesen im Augenblick ausverkauft, und so bleibt dem Autor der Korrektur keine andere Wahl als sein Produkt entweder nicht zu veröffentlichen oder gratis der Allgemeinheit zur Verfügung zu stellen. Die erste Möglichkeit führt zu nichts. Die Alternative führt vielleicht auch zu nichts, könnte aber andere ermutigen, ebenfalls Geschenke zu machen, möglicherweise welche, die umgekehrt unserem Autor nutzen. Diese zweite Wahl, obwohl augenscheinlich altruistisch, ist in Wahrheit ein eigennütziges Optimum - um es in der Sprache der Spieltheoretikern zu sagen.
Bei der Analyse einer derartigen Kooperation ist es wichtig, daß trotz der vorhandenden "Trittbrettfahrer"-Problematik (wegen fehlender finanzieller oder äquivalenter Anreize mangelt es an Beiträgen an Entwicklungsarbeit) diese Problematik von der Anzahl der Benutzer unabhängig ist. Die Komplexität und der Aufwand für die Kommunikation in einem Open Source-Projekt ist fast gänzlich eine Funktion der Anzahl der involvierten Entwicklern; auch noch so viele Konsumenten, die sich mit dem Quellcode nicht weiter befassen, kosten praktisch gar nichts. Zwar wird sich die Menge an dummen Fragen in der Mailingliste ehöhen, was aber durch Pflege einer FAQ leicht aus der Welt geschafft werden kann; Leute, die sie nicht lesen, werden dann einfach ignoriert (tatsächlich sind beides typische Praktiken).
Das wirkliche Trittbrettfahrerproblem bei Open Source-Software ist mehr eine Funktion der Reibungsverluste bei der Abgabe von Beiträgen. Ein potentieller Spender mit geringem Interesse am Spiel um Status in der Gemeinde (siehe auch [HtN]) wird vielleicht denken: "Diese Verbesserung abzugeben ist mir den Aufwand nicht wert; ich müßte den Code aufräumen, einen Protokolleintrag verfassen und die FSF Assignment Papers unterschreiben..." Aus diesem Grund korreliert die Anzahl der Beitragenden zu (und damit der Erfolg von) Projekten stark und invers mit der Anzahl der Hürden, die man als Codespender überwinden muß. Solche Reibungsverluste können mechanisch oder politisch sein. Zusammen könnten sie erklären, warum die locker organisierte und amorphe Linux-Kultur ein Vielfaches an kooperativer Energie mobilisieren konnte als die straff organisierten und zentralisierten BSD-Projekte, und auch, warum die Free Software Foundation an relativer Wichtigkeit von Linux in den Hintergrund gedrängt wurde.
Soweit ist alles schön und gut, aber diese Erklärung beleuchtet nur die Entscheidung, was Otto Normalhacker mit seinem Patch macht, nachdem er fertig gestellt ist. Wir benötigen noch die andere Hälfte: eine ökonomische Erklärung, warum O.N. überhaupt in der Lage war, diesen Patch zu schreiben, anstatt an einem Closed Source-Programm zu arbeiten, das ihm einen Warenwert geschaffen hätte. Welche Business Models erzeugen Nischen, in denen Open Source-Entwicklungen gedeihen können?