Ein Vorzug der Schlüsselerkenntnis, daß man unter Warenwert und Gebrauchswert genau unterscheiden muß, ist die Beobachtung, daß durch Veröffentlichung des Quellcodes nur der Warenwert bedroht ist, nicht der Gebrauchswert.
Wenn dieser Gebrauchswert und nicht der Warenwert als tatsächliche treibende Kraft hinter einem Softwareprojekt steht, und (wie das die These in [CatB] ist) Open Source-Entwicklung wirklich effektiver und effizienter als die Closed Source-Methode ist, dann sollten wir Umstände erwarten können, in denen der Gebrauchswert alleine Open Source-Projekte nachhaltig in Schwung hält.
Tatsächlich ist es nicht schwierig, wenigstens zwei wichtige Modelle zu identifizieren, bei denen volle Entwikcklergehäter ausschließlich durch den Gebrauchswert amortisiert werden.
Nehmen wir an, Sie arbeiten für eine Firma, deren Geschäft von einem extrem zuverlässigen Hochleistungs-Webserver abhängt. Vielleicht wickelt er e-Commerce ab, vielleicht handelt es sich um einen berühmten Medienkonzern, der Werbung verkauft, vielleicht ist die Firma ein Web-Portal. Der Server jedenfalls muß ununterbrochen fehlerfrei laufen. Gleichzeitig brauchen Sie Leistung und Flexibilität.
Wie können Sie diese Sehnsüchte erfüllen? Im Grunde gibt es drei Strategien, die Sie verfolgen können:
Kaufen Sie einen proprieritären Webserver. In diesem Fall verwetten Sie Ihre Nerven darauf, daß der Hersteller mit Ihnen bei Zielsetzungen und Zukunftsplänen an einem Strang zieht und darauf, daß der Hersteller die erforderliche technische Kompetenz hat, um den Server befriedigend zu implementieren. Sogar unter der Annahme, daß beide Voraussetzungen erfüllt sind, wird das Produkt wahrscheinlich nicht beliebig anzupassen sein. Sie können nur an den Stellen einhaken, die der Hersteller für Anpassungen vorgesehen hat. Diese Strategie eines proprietären Webservers ist nicht gerade beliebt.
Bauen Sie Ihren eigenen Webserver. Die Entwicklung eines eigenen Webservers ist eine Möglichkeit, die man nicht augenblicklich verwerfen sollte. So ein Server ist nicht besonders komplex und sicherlich leichter zu implementieren als ein Browser. Ein spezialisierter Webserver kann sehr leistungsfähig und sehr schlank sein. Bei dieser Strategie bekommen Sie ganz genau jene Leistungsmerkmale, die Sie wollen und auch die Möglichkeit zu beliebigen Anpassungen. Der Preis dafür sind die Kosten für die Entwicklungsarbeit. Ihre Firma könnte auch zu dem Schluß kommen, daß sie ein gewaltiges Problem hat, sobald Sie kündigen oder in Pension gehen.
Treten Sie der Apache Group bei. Der Server Apache wurde von einer durch das Internet verbundene Gruppe von Webmastern geschaffen, die erkannten, daß es klüger ist, ihre jeweiligen Aufwendungen für die Erweiterung und Verbesserung eines einzigen Codepools zu teilen, um eine große Zahl von parallel laufenden Entwicklungen zu betreiben. Dadurch kamen sie in den Genuß der Flexibilität eines selbstgebauten Servers und des gewaltigen Debugging-Muskels massiv-paralleler Peer Review.
Der Vorteil einer Entscheidung für Apache ist sehr groß. Wie groß, kann man erkennen, wenn man sich die monatliche Erhebung von Netcraft ansieht. Sie zeigt, daß Apache seit seiner ersten Freigabe gegenüber allen anderen proprieritären Webservern mehr und mehr Marktanteil gewonnen hat. Im Juni 1999 hielt man bei 61 Prozent Marktanteil; - und das ohne einen Eigentümer, ohne Werbung und ohne Verträge mit betreuenden Dienstleistungsunternehmen.
Die Geschichte hinter Apache läßt sich in einem Modell verallgemeinern, bei dem die Benutzer von Software in der gemeinnützigen Open Source-Entwicklung Vorteile sehen, da Open Source ihnen ein Produkt beschert, das besser ist als jedes, das sie auf anderem Weg erhalten können und darüber hinaus auch noch kostengünstiger ist.
Vor einigen Jahren bekamen zwei Programmierer bei Cisco (dem Hersteller für Netzwerkausstattung) die Aufgabe, ein verteiltes Print-Spoolingsystem zu schreiben, das dann in Ciscos Firmennetzwerk verwendet werden sollte. Das war keine geringe Herausforderung. Neben der Möglichkeit, einen beliebigen Benutzer A zu einem beliebigen Drucker B (der im nächsten Zimmer oder tausend Kilometer entfernt sein kann) drucken zu lassen, sollte das System sicherstellen, daß im Falle eines Papierstaus oder einer leeren Tonerkassette der Druckjob zu einem anderen nahe gelegenen Drucker umgeleitet wird. Das System mußte auch in der Lage sein, solche Probleme an den Druckeradministrator weiterzuleiten.
Das Duo entwickelte einen Satz von cleveren Modifikationen des unter Unix standardisierten Druckerspoolers und ergänzte einige Scripts, was zur Erfüllung der Aufgabe ausreichte. Dann erkannten sie, daß sie (und Cisco) ein Problem hatten.
Das Problem war, daß weder der eine noch der andere ewig bei Cisco bleiben würde. Irgendwann würden wahrscheinlich beide Programmierer nicht mehr da sein und die Software würde dann ungewartet herumliegen und langsam verrotten (d.h. nach und nach mit den tatsächlichen Gegebenheiten bei Cisco außer Tritt geraten). Kein Entwickler sieht so etwas gerne, wenn es um die eigenen Werke geht. Unser Duo stand unter dem gerechtfertigten Eindruck, daß Cisco für eine Lösung bezahlt hatte, die es bei Cisco wahrscheinlich länger geben würde als ihre Schöpfer.
Folglich gingen sie zu ihrem Chef und drängten ihn, die Freigabe der Printspooler-Software als Open Source zu genehmigen. Ihr Argument war, daß Cisco keinen Verlust von Warenwert zu fürchten hätte. Durch Förderung einer Benutzergemeinde und Mitentwicklern in vielen großen Firmen konnte Cisco dem Schaden durch Verlust der ursprünglichen Entwickler vorbeugen.
Die Geschichte hinter dem Cisco-Druckerspooler läßt sich in einem Modell verallgemeinern, bei dem die Open Source-Methode nicht so sehr die Funktion hat, Kosten zu senken, sondern Risiko zu zerstreuen. Alle Teilnehmer anerkennen dabei, daß die Präsenz einer aktiven Entwicklergemeinde, die durch mehrere unabhängige Einkommensströme finanziert wird, mehr Sicherheit bietet. Diese Sicherheit hat selbst einen wirtschaftlichen Wert, der hoch genug, um Anreize für den Unterhalt eines solchen Projekts zu schaffen.