[Weiter] [Zurück] [Inhaltsverzeichnis]

12. Wie man Erfolg verkraftet

Die Tradegy of the Commons mag auf Open Source- Projekte in der heutigen Form nicht anwendbar sein. Das bedeutet aber nicht, daß es keine Gründe gibt, die Nachhaltigkeit des augenblicklichen Drehmoments der Open Source-Gemeinde in Frage zu stellen. Werden die Schlüsselfiguren einen Rückzieher machen, sobald mehr auf dem Spiel steht?

Diese Frage kann man auf mehreren Ebenen stellen. Unsere Gegengeschichte der "Komödie der Kommune" basiert auf dem Argument, daß der Wert individueller Beiträge zum Codestamm schwierig zu vergebühren ist. Dieses Argument hat aber weniger Einfluß auf Firmen (wie etwa Linux-Distributoren), die durch Open Source bereits Geld verdienen. Dort wird bereits jeden Tag mit ihren Beiträgen Geld gemacht. Ist ihre augenblickliche Rolle in der Kooperation stabil?

Die Erörterung dieser Frage führt uns zu einigen interessanten Einsichten über die Ökonomoie von Open Source-Software, wie sie sich uns heute tatsächlich präsentiert - und darüber, was ein wirkliches Dienstleistungsparadigma für die zukünftige Softwareindustrie impliziert.

Auf der praktischen Ebene wird die Frage üblicherweise auf eine von zwei Arten gestellt. Die eine lautet: wird sich Linux zersplittern? Die zweite: wird sich Linux zu einem dominierenden, quasi-monopolistischen Mitspieler entwickeln?

Die historische Analogie, auf die viele Leute zurückgreifen werden, um auf eine Fragmentierung von Linux hinzuweisen, ist das Verhalten der Hersteller von proprietären Unix-Varianten in den 1980ern. Trotz der endlossen Debatten über offene Standards, trotz der zahlreichen Allianzen und Konsortien und Abmachungen, zerbröckelte Unix in diverse proprietäre Varianten. Die Hersteller hatten Sehnsucht nach Differenzierung ihrer Produkte und versprachen sich Erfüllung dieser Sehnsucht aus dem Hinzufügen und Verändern von Betriebssystemmerkmalen. Die Sehnsucht war stärker als das Interesse, den absoluten Umfang des Unix-Marktes durch Kompatibilität zu erweitern (was in der Folge zu geringeren Hürden für unabhängige Software-Entwickler und geringeren Kosten für die Konsumenten geführt hätte).

Es ist unwahrscheinlich, daß dies auch bei Linux passiert - aus dem einfachen Grund, daß alle Distributoren die Auflage haben, von einem gemeinsamen Codestamm aus zu operieren. Differenzierung ist keinem von ihnen wirklich möglich, da die Lizenzen unter denen Linux entwickelt wird, das Teilen von Code mit allen Parteien auferlegt. In dem Augenblick, in dem irgendein Distributor ein Leistungsmerkmal entwickelt, steht es allen Mitbewerbern auch zur Verfügung.

Da das von allen Beteiligten verstanden wird, denkt niemand über Manöver auch nur nach, die zur Fragmentierung von proprieritären Unixen führten. Stattdessen sind Linux-Distributoren gezwungen, auf eine Art miteinander zu konkurrieren, die für die Konsumenten nützlich ist, das heißt in der Arena von Service, Betreuung und der Güte ihrer Entscheidungen darüber, wie die Schnittstellen für leichte Installation und Verwendung auszusehen haben.

Der gemeinsame Codestamm schließt auch die Möglichkeit von Monopolisierung von vornherein aus. Wenn sich Linux-Leute darüber Sorgen machen, wird in der Regel der Name "Red Hat" gemurmelt - des größten und erfolgreichsten Distributor (mit ca. 90 Prozent Marktanteil in den USA). Beachtenswert ist aber, daß innerhalb von Tagen nach Red Hats 6.0-Release im Mai 1999 - noch bevor Red Hats CD-ROMs in Stückzahlen ausgeliefert wurde - CD-ROM-Images von Red Hats eigener FTP-Site von Verlegern und mehreren anderen CD-ROM-Distributoren angeboten wurden, und das unter dem von Red Hat erwarteten Listenpreis.

Red Hat selbst war das gleichgültig, denn ihren Gründern ist völlig klar, daß sie die Bits ihres Produktes nicht besitzen und nicht besitzen können; die soziale Norm der Linux-Gemeinde verbietet das. In einer neueren Auflage von John Gilmores berühmter Beobachtung, daß das Internet Zensur als schädlich interpretiert und Wege darum herum findet, wurde richtig gesagt, daß die für Linux verantwortliche Hackergemeinde Versuche, die Kontrolle an sich zu reißen, als schädlich interpretiert und Wege darum herum findet. Für Red Hat hätten Proteste gegen das Cloning ihres neuesten Produkts die Möglichkeit aufs Spiel gesetzt, auch in Zukunft mit der Entwicklergemeinde zu kooperieren.

Im Augenblick am wichtigsten ist aber vielleicht, daß es juristisch verbindliche Software-Lizenzen gibt, die es Red Hat ausdrücklich verbieten, den Quellcode zu monopolisieren, der die Grundlage ihrer Produkte ist. Das einzige, das sie verkaufen dürfen ist eine Service/Support-Beziehung mit den Leuten, die freiwillig bereit sind, dafür zu bezahlen. In so einem Kontext ist ein Raubritter- Monopol keine ernsthafte Bedrohung.


[Weiter] [Zurück] [Inhaltsverzeichnis]