Nach der Untersuchung der Business Models, die Open Source- Entwicklungen fördern, können wir uns an die allgemeine Frage wagen, wann es wirtschaftlich Sinn macht, seinen Quellcode zu veröffentlichen und wann nicht. Zunächst müssen wir uns aber darüber klar werden, was die jeweiligen Vorzüge der beiden Strategien sind.
Der Closed Source-Ansatz gestattet es Ihnen, Gebühren für eingekapslete Bits einzuheben; auf der anderen Seite schließt er die Möglichkeit wirklich unabhängiger Peer Review aus. Der Open Source-Ansatz schafft die Voraussetzungen für unabhängige Peer Review, schließt aber die Vergebührung eingekapselter Bits aus.
Der Gewinn aus dem Besitz unzugänglicher Bits ist leicht zu verstehen; traditionelle Software-Business Models sind darum herum aufgebaut. Bis vor kurzem war ein gutes Verständis des Gewinns aus Peer Review nicht so verbreitet. Das Betriebssystem Linux aber zeigt, was wir wahrscheinlich schon vor Jahren lernen hätten können, und zwar aus der Geschichte der Kernsoftware des Internet und anderen Ingenieursfakultäten - daß Peer Review die einzige in großem Stil anwendbare Methode ist, um hohe Qualität und Zuverlässigkeit zu erzielen.
Auf einem wettbewerbsorientierten Markt, auf dem Kunden hohe Qualität und Zuverlässigkeit suchen, werden daher jene Software- Produzenten belohnt werden, die ihren Quellcode veröffentlichen und herausfinden, wie sie durch Anbieten von Service, Value-Add und durch Zusatzmärkte Gewinne machen können. Dieses Phänomen ist es, daß hinter dem bemerkenswerten Erfolg von Linux steht, das 1996 aus dem Nichts auftauchte, Ende 1998 17 Prozent des Business Server-Marktes erobert hatte und voraussichtlich innerhalb der nächsten zwei Jahre zur dominierenden Plattform auf diesem Markt werden wird (Anfang 1999 prognostizierte IDC, daß Linux bis zum Jahr 2003 schneller wachsen wird als alle anderen Betriebssysteme zusammen).
Von fast ebenso großem Wert ist der Nutzen, den Open Source stiftet, wenn es um offene Standards und das Erzeugen von Märkten dafür geht. Das dramatische Wachstum des Internet verdankt sehr viel dem Umstand, daß TCP/IP niemandem gehört und niemand daher die Schlüsselprotokolle des Internet in einem proprietären Würgegriff hält.
Die Netzwerkeffekte hinter dem Erfolg von TCP/IP und Linux sind ziemlich klar und reduzieren sich letztlich auf Belange wie Vertrauen und Symmetrie - potentielle Nutzer einer gemeinsamen Infrastruktur können logischerweise mehr Zuversicht in ein System haben, von dem sie jedes Detail nachprüfen können und werden daher eine Infrastruktur bevorzugen, an der alle Parteien symmetrische Rechte haben. Daneben werden Systeme schnell unattraktiv, die eine einzelne Partei in eine privilegierte Position versetzen und die in der Folge Kontrolle ausübt oder Gebühren einhebt.
Es gibt aber keine zwingende Notwendigkeit, für die Wichtigkeit von Symmetrie für Software-Konsumenten Netzwerkeffekte vorauszusetzen. Kein Softwarekonsument wird sich aus rationalen Gründen dazu entschließen, sich in ein herstellerkontrolliertes Monopol einzusperren, wenn es irgendeine Open Source- Alternative von vergleichbarer Qualität gibt. Dieses Argument bekommt noch mehr Gewicht, wenn Software für das Geschäft des Konsumenten ein ausschlaggebender Faktor ist - um so wichtiger sie ist, um so weniger wird ein Konsument Kontrolle durch einen Außenstehenden tolerieren.
Schließlich ist Zukunftssicherheit ein weiterer wichtiger Vorzug von Open Source-Software und die steht in engem Zusammenhang mit Vertrauen. Wenn der Quellcode öffentlich ist, hat der Kunde wenigstens ein letztes Mittel für den Fall zur Hand, daß der Distributor bankrott geht. Das kann für das "Glasierungsmodell" besonders wichtig werden, da Hardware zu sehr kurzen Lebenszyklen tendiert, der Effekt ist aber allgemein anwendbar und ergibt automatisch einen zunehmenden Wert für Open Source- Software.
Wenn die Gebühr für eingekapselte Bits höher liegt als der Ertrag aus Open Source, macht es ökonomischen Sinn, die Closed Source-Methode anzuwenden. Wenn die Erträge aus Open Source höher sind als die Gebühr für geheime Bits, macht es Sinn, die Closed Source-Methode anzuwenden.
Das ist natürlich eine triviale Beobachtung. Nicht trivial ist aber die Bemerkung, daß der Vorzug der Open Source-Methode schwieriger zu messen und vorherzusehen ist als die Erträge aus eingekapselten Bits - dazu kommt, daß der Vorzug öfter unterschätzt als überschätzt wird. Tatsächlich war es bis zu dem Zeitpunkt, als der Mainstream der Geschäftswelt durch das Echo auf die Veröffentlichung des Mozilla-Quellcodes die Vorzüge von Open Source neu überdachte so, daß die Vorteile von Open Source mit dem Wert Null veranschlagt wurden.
Wie können wir also den Wert von Open Source evaluieren? Das ist eine schwierige Frage, aber wir können den selben Ansatz wie für jede andere prognostische Problemstellung verwenden. Beginnen wir mit den Beobachtungen von Fällen, in denen die Open Source-Methode ein Erfolg war oder versagte. Wir können dann versuchen, daraus ein allgemeines Modell zu entwickeln, das uns wenigstens ein Gefühl für den Kontext verschafft, in dem Open Source ein Nettogewinn für den Investor oder das Unternehmen ist, das versucht, die Erträge zu maximinieren. Danach können wir zu unseren Daten zurückkehren und versuchen, das Modell zu verfeinern.
Durch die in [CatB] präsentierte Analyse können wir erwarten, daß Open Source von hohem Wert ist, wenn a) Zuverlässigkeit/Stabilität/Skalierbarkeit von ausschlaggebender Bedeutung sind, und b) die Korrektheit des Designs und der Implementation nur auf dem Weg der unabhängigen Peer Review verifiziert werden kann. (Dieses zweite Kriterium gilt in der Praxis für die meisten nicht-trivialen Programme).
Das verständliche Bedürfnis des Konsumenten, möglichst nicht in die Falle eines Herstellermonopols zu gehen, wird das Interesse an Open Source erhöhen (und daher den Wettbewerbsdruck auf Hersteller erhöhen, die Open Source-Methode zu unterstützen), wenn die Software für den Konsumenten von zentraler Bedeutung ist. Daher gibt es noch ein drittes Kriterium c), das in Richtung Open Source drängt: die Software ist ein geschäftskritischer Faktor (wie das zum Beispiel bei vielen MIS-Abteilungen großer Firmen der Fall ist).
Für das Gebiet der Applikationen haben wir bereits festgestellt, daß Open Source-Infrastruktur Vertrauen und Symmetrie schafft, die mit der Zeit mehr Kunden anziehen wird und Closed Source- Infrastruktur in den Hintergrund drängen wird. Oft ist es auch besser, ein kleineres Stück eines solchen rapide wachsenden Marktes zu haben, als ein großes Stück eines geschlossenen und stagnierenden Marktes. Dem entsprechend ist es für die anvisierte Allgegenwart von Open Source wahrscheinlicher, daß der Wert höher und nachhaltiger ist als der einer kurzsichtigen Closed Source-Politik, die an der Vergebührung von geistigem Eigentum orientiert ist.
Tatsächlich impliziert die Fähigkeit von potentiellen Kunden, über die zuküftigen Konsequenzen von Herstellerstrategien nachzudenken und ihr Widerstand gegen Herstellermonopole eine noch schwerwiegendere Einschränkung: auch ohne einen überwältigenden Marktanteil kann man sich entweder für eine mögliche vollständige Marktdurchdringung durch Open Source oder direkte Gewinne durch Verkauf von Closed Source-Software entscheiden, aber nicht beides zusammen. (Einer Analogie dieses Prinzips begegnen wir beispielsweise auf Märkten für Elektronik, auf denen Kunden sich oft weigern, exklusive Designs - d.h solche ohne einen alternativen Hersteller - zu kaufen). Man kann es auch weniger negativ darstellen: wo Netzwerkeffekte (positive Netzwerkexternalitäten) eine dominierende Rolle spielen, ist Open Source wahrscheinlich der richtige Weg.
Wir können diese Logik durch die Beobachtung zusammenfassen, daß Open Source dort höhere Erträge als Closed Source verspricht, wo (d) die Software eine gemeinsame Datenverarbeitungs- oder Kommunikationsinfrastruktur hervorbringt oder fördert.
Schließlich noch die Bemerkung, daß die Betreiber einzigartiger oder auch nur hochgradig differenzierter Dienstleistungen einen höheren Anreiz haben, sich vor der Plagiierung ihrer Methoden durch Mitbewerber zu fürchten, als Dienstleister, deren zentrale Algorithmen und Kompetenzen allgemein verstanden werden. Dem entsprechend ist es für Open Source wahrscheinlicher, Gebiete zu dominieren, wenn (e) die Schlüsselmethoden (oder funktionalen Äquivalente) Teil allgemein bekannter Ingenieurskunst sind.
Die Kernsoftware des Internet, Apache und die Linux- Implementation des ANSI-standardisierten Unix API sind Schulbuchbeispiel für alle fünf Kriterien. Vor dem Zusammenwachsen von Datennetzwerken durch TCP/IP Mitte der 1990er gab es fünfzehn Jahre lang vergebliche Bemühungen, auf diesem Gebiet proprietäre Imperien zu errichten, auf der Grundlage von geschlossenen Protokollen wie DECNET, XNS, IPX und anderen. Diese Konvergenz illustriert die Rolle, die Open Source bei der Evolution solcher Märkte spielt.
Auf der anderen Seite scheint Open Source für Firmen den geringsten Wert zu haben, die über einzigartige wertschöpfende Software-Technologie verfügen (die Kriterium (e) erfüllt, relativ unempfindlich für Ausfälle ist (a), sehr gut auf anderem Weg als unabhängige Peer Review verifiziert werden kann (b), nicht geschäftskritisch ist (c) und dessen Wert nicht durch vollständige Marktdurchdringung oder Netzwerkeffekte gesteigert wird (d)).
Hier ein Beispiel für einen solchen Extremfall. Anfang 1991 wurde ich von einer Firma nach der Sinnhaftigkeit gefragt, ihren Quellcode zu veröffentlichen. Die Firma stellte Software her, die Schnittbilder für Sägewerke berechnet, um die Länge von Brettern zu maximieren, in die ein Baumstamm aufgeteilt werden kann. Meine Antwort auf diese Frage lautete "Nein". Das einzige Kriterium, das durch die Software wenigstens halbwegs erfüllt wurde, ist (c); owbohl ein erfahrener Werkmeister die Schnittmuster in der Praxis auch händisch berechnen könnte.
Als weiteren springenden Punkt muß man im Auge behalten, daß sich die Position eines Produkts oder einer Technologie auf diesen Skalen mit der Zeit verändern kann, wie wir das in der nächsten Fallstudie beobachten können.
In Summe kann man sagen, daß folgende Merkmale Evolutionsdruck in Richtung Open Source erzeugen:
(a)
Zuverlässigkeit, Stabilität und Skalierbarkeit sind von
ausschlaggebender Bedeutung
(b)
Die Korrektheit des Designs und der Implementation kann
nicht leicht auf anderem Weg als dem der unabhängigen Peer
Review überprüft werden.
(c)
Die Software ist für den Benutzer geschäftskritisch
(d)
Die Software etabliert oder ermöglicht eine gemeinsame
Computer- oder Kommunikationsinfrastruktur.
(e)
Die Schlüsselmethoden (oder deren funktionale Äquivalente)
sind Teil wohlbekannter Ingenieurskunst.
Die Geschichte von id Softwares Spiele-Bestseller Doom illustriert die Wege, auf denen der Druck des Marktes und Produktevolution die Größenverhältnisse beim Gewinn von Closed vs. Open Source bedeutend verändern können.
Als Doom Ende 1993 erstmals herauskam, machten es seine Echtzeitanimation und subjektive Kamera einzigartig (was die Antithese zu Kriterium (e) darstellt). Nicht nur waren die Techniken und die visuelle Wirkung atemberaubend, auch konnte niemand herausfinden, wie diese Resultate mit den verhältnismäßig schwachen Mikroprozessoren der damaligen Zeit erzielt werden konnten. Diese eingekapselten Bits hatten für den Verkauf einen bedeutenden Wert. Daher lohnte sich die Veröffentlichung des Quellcodes so gut wie gar nicht. Das Spiel war für nur einen Spieler, ein Ausfall der Software war tolerierbar (a), das korrekte Funktionieren war nicht weiter schwierig zu überprüfen (b), von geschäftskritisch konnte keine Rede sein (c), und es gab keine Aussicht auf Netzwerkeffekte (d). Es war ökonomisch sinnvoll, den Quellcode für Doom unter Verschluß zu halten.
Der Markt um Doom stand aber nicht still. Zukünftige Mitbewerber erfanden funktionale Äquivalente für die Techniken zur Animation, und andere "first-person shooter"-Spiele wie Duke Nukem kamen heraus. Mit zunehmenden Marktanteil für Konkurrenten für Doom schrumpfte der Wert für die Vergebührung eingekapselter Bits.
Auf der anderen Seite brachte der Aufwand, diesen Marktanteil zu vergrößern, neue technische Herausforderungen mit sich - höhere Ausfallsicherheit, mehr Leistungsmerkmale, ein größerer Benutzerstamm und mehrere Plattformen. Mit dem Auftauchen von "Todesmatch"-Spielmodi und Doom-Onlinevermittlungen für Spielpartner begann der Markt signifikante Netzwerkeffekte zu zeigen. All das verzehrte Programmiererzeit, die id lieber in das nächste Spiel invstiert hätte.
Alle diese Trends erhöhten das Ausmaß in dem sich die Veröffentlichung des Quellcodes lohnte. Ab einem gewissen Punkt schnitten sich die Kurven des Nutzens und es machte für id ökonomischen Sinn den Quellcode für Doom freizugeben und ihr Geld auf Sekundärmärkten wie Szenario-Anthologien zu verdienen. Irgendwann nach dem Erreichen dieses Punktes wurde dieses neue Business Model Wirklichkeit. Dooms kompletter Quellcode wurde Ende 1997 veröffentlicht.
Doom ist eine interessante Fallstudie, da es sich weder um ein Betriebssystem noch um Kommunikations- oder Netzwerksoftware handelt; es ist von den üblichen und offensichtlichen Beispielen für Open Source-Erfolge weit entfernt. Tatsächlich ist Dooms Lebenszyklus - komplett mit Schnittpunkten der Nutzenkurven - vielleicht ein zukünftiges Schulbuchbeispiel für Applikationen in der heutigen Codeökologie, eine in der sowohl Kommunikation und Distributed Computation hohe Anforderungen an die Robustheit/Zuverlässigkeit/Skalierbarkeit stellen, der nur durch Peer Review entsprochen werden kann, und die oft die Grenzen zwischen technischem Substrat und einander konkurrierenden Akteuren verwischen (mit allen impliziten Belangen des Vertrauens und der Symmetrie).
Doom evolvierte vom Solo- zu einem Todesmatch-Spiel. Mehr und mehr wird das Netzwerk zum Computer. Ähnliche Trends sind sogar bei den konservativsten Business-Applikationen sichtbar - wie etwa ERPs. Die Geschäftswelt verbindet Firmennetzwerke mit denen ihrer Lieferanten und Kunden. Die ganze Architektur des World Wide Web ist natürlich ein zentrales Beispiel für diese Trends. Aus all dem folgt, daß der Nutzen von Open Source mehr und mehr steigt.
Wenn die gegenwärtigen Trends sich fortsetzen, wird die bedeutendste Herausforderung an die Software-Technologie und das Produktmenagement im nächsten Jahrhundert sein, zu wissen, wann man seinen Quellcode aus dem Tresor an die Öffentlichkeit bringen und in die Open Source-Infrastruktur integrieren soll, um den Effekt von Peer Review auszunutzen und durch Dienstleistungen und Sekundärmärkte in den Genuß höherer Erträge zu kommen.
Es gibt offensichtliche Gewinnanreize, den Schnittpunkt der Nutzenkurven nicht zu sehr zu in die eine oder die andere Richtung zu verfehlen. Darüber hinaus gibt es ein ernstes Opportunitätsrisiko, wenn man zu lange wartet - man könnte von einem Mitbewerber verdrängt werden, der seinen Quellcode in der selben Nische vorher veröffentlicht.
Der Grund für die Schärfe dieser Verfehlung ist, daß sowohl der Pool von Benutzern als auch der Pool von Talenten, die für eine Open Source-Kooperation für ein bestimmtes Produkt rekrutiert werden können, sehr begrenzt ist und diese Rekrutierung die Tendenz hat, ein für alle mal zu erfolgen. Wenn zwei Hersteller als erster und zweiter mit ihrem Quellcode herauskommen, der ungefähr die gleiche Funktionalität hat, dann wird wahrscheinlich der erste die meisten Benutzer und die am höchsten motivierten Mitentwickler für sich gewinnen können. Der zweite wird nur bekommen, was übrig bleibt. Die Rekrutierung ist nachhaltig, da die Benutzer sich an das Produkt gewöhnen und die Entwickler ihre Investitionen in den Code weiter nutzen wollen.