Dieses Dokument befasst sich mit dem gerade entstehenden ökonomischen
Nährboden des Phänomens Open Source. Wir enttarnen einige weit
verbreitete Ansichten über die Finanzierung
Softwareentwicklung
als Mythen und gehen der Preisstruktur
Software auf den Grund. Wir
präsentieren eine spieltheoretische Analyse der Stabilität der
Kooperation in der Open Source-Bewegung und zeigen neun Modelle für
die Unterhaltung
Softwareentwicklung durch Open Source; sieben da
sind gewinnorientiert, zwei gemeinnützig. Wir fahren fort mit dem Aufbau
einer qualitativen Theorie darüber, in welchen Fällen es
wirtschaftlichen Sinn macht, Software unter Ausschluss der Öffentlichkeit
("Closed Source") zu entwickeln. Wir untersuchen dann einige neuartige
Mechanismen, die der Markt gerade erfindet, um gewinnorientierte Open
Source-Projekte zu finanzieren, darunter die Renaissance des Gedankens einer
Patronage und die Idee eines sogenannten Task Markets;. Wir schließen
unsere Überlegungen mit einigen vorsichtigen Vorhersagen der nächsten
Zukunft ab.
1. Von Zauberei nicht zu unterscheiden
2. Mehr als nur Computerstiesel die mit Geschenken
kommen
3. Der Fertigungswahn
4. Der Mythos
"Information WILL gratis
sein"
5. Die Kommune steht Kopf
6. Gründe für Closed Source
7. Open Source und
Gebrauchswert-Modelle
7.1 Fallstudie 1: Apache, Aufteilen des
Aufwands
7.2 Fallstudie 2: Cisco, Aufteilen des
Risikos
8. Warum der Warenwert problematisch
ist
9. Modelle für indirekten
Warenwert
9.1 Lockangebot/Market Positioner
9.2 Widget Frosting - Teile mit Glasur
9.3 Rezepte herschenken und ein Restaurant
eröffnen
9.4 Accessorizing
9.5 Zukunft verschenken, Gegenwart verkaufen
9.6 Software herschenken, Gütesiegel
verkaufen
9.7 Software herschenken, Inhalte verkaufen
10. Wann öffentlich, wann
nicht-öffentlich?
10.1 Was springt dabei heraus?
10.2 Wie das alles zusammenpasst
10.3 Doom: Eine Fallstudie
10.4 Wann soll man seinen Quellcode aus dem Tresor
holen?
11. Das Software-Geschäft als
Ökologie
12. Wie man Erfolg verkraftet
13. Offene Forschung und Entwicklung und die
Renaissance der Patronage
14. Wie geht es weiter?
15. Schluss: das Leben nach der
Revolution
16. Bibliographie und Danksagung
17. Anhang: Warum Hersteller durch Ausschluss
der Öffentlichkeit verlieren
18.
Versionsgeschichte
1. Von Zauberei nicht zu unterscheiden
In einer walisischen Sage besitzt die Göttin Ceridwen einen großen
Kessel, der auf magische Weise Essen hervorbringt - wenn man den nur der
Göttin bekannten Zauberspruch aufsagt. Buckminster Fuller trug zur modernen
Wissenschaft das Konzept der "Ephemeralization" bei - die Idee, dass Technologie
sowohl effektiver als auch billiger wird, wenn die Investitionen in den
frühen Entwurf nicht in physischen Ressourcen bestehen, sondern durch
mehr und mehr Überlegungen über den Entwurf ersetzt werden. Arthur
C. Clarke stellte zwischen Sage und Buckminster Fuller eine Verbindung her,
als er feststellte: "Jede ausreichend fortgeschrittene Technologie ist
Zauberei nicht zu unterscheiden".
Für
viele scheinen die Erfolge der Open Source-Gemeinde wie eine überhaupt
nicht einleuchtende Form
Zauberei. Hochwertige Software entsteht
"einfach so" und ist "gratis". Das ist zwar ganz nett, solange es funktioniert,
kann aber in einer Welt des Wettbewerbs und der beschränkten Ressourcen
wohl kaum
Dauer sein. Wo ist der Haken? Ist Ceridwens verzauberter Kessel
nur ein billiger Trick? Und wenn nicht, wo ist in diesem Zusammenhang die
Ephemeralization - welchen Zauberspruch verwendet die
Göttin?
2. Mehr als nur Computerstiesel, die mit Geschenken kommen
Die Erfahrung der Open Source-Kultur hat sicher viele der Annahmen jener
Leute umgeworfen, die ihre Kenntnisse der Softwareentwicklung außerhalb
dieser Kultur erworben haben. "Die Kathedrale
und der Bazar" [CatB] beschreibt, wie dezentralisierte
Kooperationen
beim Entwicklungsaufwand Brooks Gesetz besiegen
können, was zu einem
noch nie dagewesenen Niveau bei individuellen
Projekten führt.
"Homesteading the Noosphere" [HtN] untersucht die soziale Dynamik,
innerhalb derer dieser "bazar-orientierte"
Stil beim Entwickeln zu Hause ist; mit der
These als Anliegen, dass man diese Dynamik
nicht am besten unter dem Blickwinkel einer
Tausch/Waren-Ökonomie betrachtet, sondern
unter dem einer "Gift Culture"
- Geschenkkultur -, wie Ethnologen das nennen.
In so einer Geschenkkultur gibt es unter
den einzelnen Mitgliedern einen Wettbewerb
um Status, der sich am Wert der hergegebenen
Geschenke misst. In diesem Dokument werden
wir unsere Erörterung damit beginnen,
dass wir einigen weit verbreiteten Mythen
über die Ökonomie der Softwareentwicklung
die Luft auslassen; dann mit der Analyse
[CatB] und [HtN] in das Reich der Wirtschaftstheorie,
der Spieltheorie und der Business Models
vorstoßen und neue Konzepte für
das Verständnis der Art und Weise zu
entwerfen, wie Open Source-Entwickler in
einer Tauschwirtschaft (wie die unsere eine
ist) ihren Lebensunterhalt verdienen können.
Um diese Linie der Analyse weiter zu verfolgen ohne abgelenkt zu werden,
müssen wir die Vorstellung einer Geschenkkultur aufgeben (oder uns
wenigstens darauf einigen, sie vorübergehend zu ignorieren). [HtN] zeigt,
dass es zu dieser Freigiebigkeit in Situationen kommt, die alles Lebenswichtige
in solchem Überfluss bieten, dass ein Austausch
Waren uninteressant
wird. Das ist zwar als psychologische Erklärung ausreichend, versagt
aber für den gemischt-ökonomischen Kontext, in dem die meisten
Open Source-Entwickler operieren. Für die meisten ist das Spiel um Waren
zwar nicht mehr attraktiv, hat aber noch immer die Macht, den eigenen
Aktionsradius einzuschränken - schließlich braucht jeder irgendein
Einkommen.
Das Verhalten dieser Mehrheit muss auch im Rahmen einer herkömmlichen Ökonomie wirtschaftlichen Sinn machen, um ihnen den Luxus der Freigiebigkeit zu ermöglichen.
Daher werden wir nun die einzelnen Arten der Kooperation und des Austausches
beleuchten, die Open Source-Entwicklung ermöglichen - und das gänzlich
innerhalb des Rahmens der herkömmlichen Ökonomie. Dabei werden
wir die pragmatische Frage "Wie kann ich damit was verdienen?" detailliert
beantworten und Beispiele anführen. Als erstes aber werden wir zeigen,
dass sehr viele
den Zweifeln hinter dieser Frage nur vor der Kulisse
der vorherrschenden - und nicht stichhaltigen - Folklore der Ökonomie
der Softwareproduktion berechtigt sind.
(Eine letzte Anmerkung noch, bevor wir zur Ausführung kommen: die
Erörterung und Befürwortung des Open Source-Modells in diesem Text
sollte nicht als These verstanden werden, dass Closed- Source-Projekte
Grund auf falsch sind; auch nicht als Opposition gegen Urheberrechte bei
Software, und auch nicht als ein frömmelnder Aufruf, mit seinen Mitmenschen
zu teilen. Während all diese Argumente unter einer nicht zu
überhörenden Minderheit in der Open Source-Gemeinde noch immer
heiß geliebt werden, zeigen die seit [CatB] gemachten Erfahrungen deutlich
deren Überflüssigkeit. Zur Rechtfertigung
Open Source- Entwicklung
sind die technischen und wirtschaftlichen Zielsetzungen völlig ausreichend:
mehr Qualität, höhere Zuverlässigkeit, geringere Kosten und
eine breitere Produktpalette).
3. Der Fertigungswahn
Wir müssen unsere Betrachtung mit der Bemerkung anfangen, dass
Computerprogramme, so wie alle anderen Werkzeuge oder Investionsgüter,
zwei klar erkennbare Arten
wirtschaftlichen Wert haben. Der eine ist
der Gebrauchswert, der andere der Warenwert.
Der Gebrauchswert eines Programms ist sein wirtschaftlicher Wert als Werkzeug. Der Warenwert eines Programms ist sein Wert als handelbare Ware.
Die meisten Leute tendieren bei Überlegungen über die Produktion
Software zur Annahme eines "Fabrikmodells", das sich auf die folgenden
Voraussetzungen stützt:
1. Die Arbeitszeit der Entwickler wird durch den Warenwert amortisiert.
2. Der Warenwert
Software ist proportional zu den Entwicklungskosten
(also der Kosten, die für die Duplizierung seiner Funktion erforderlich
sind) und zu seinem Gebrauchswert.
In anderen Worten: die Leute tendieren sehr stark zu der Annahme, dass Software bei ihrer wirtschaftlichen Bewertung die Charakteristik eines in der Fabrik hergestellten Guts hat. Beide der oben angegebenen Annahmen sind aber nachweislich falsch.
Zum einen ist Code, der für den Weiterverkauf geschrieben wird, nur
die Spitze des Eisbergs. In der Epoche vor den Mikrocomputern war es
üblich, dass 90 Prozent allen Codes für die eigene Verwendung
Banken und Versicherungsgesellschaften geschrieben wurde. Diese Zeiten sind
vermutlich vorbei - auch andere Industrien sind inzwischen sehr Software-intensiv
geworden, und der Anteil der Finanzwirtschaft entsprechend gesunken - wir
werden aber gleich sehen, dass es empirische Beweise dafür gibt, dass
noch immer 95 Prozent allen Codes für die ausschließliche Verwendung
durch die den Aufwand erbringenden Institutionen entwickelt wird.
Dieser Code beinhaltet das meiste des Tagesgeschäfts der IT- Abteilungen
- die Anpassung
Finanz- und Datenbanksoftware, die jede mittlere und
große Firma braucht. Er beinhaltet die Arbeit
hochspezialisierten
Experten, wie sie etwa in Gerätetreibern steckt (es macht ja fast niemand
Geld mit dem Verkauf solcher Treiber, was uns später noch beschäftigen
wird). Er beinhaltet viele Spielarten
"Firmware", wie er in zunehmend
mikrocomputerisierten Maschinen eingebettet ist -
der Formenfräse
über Tarnkappenbomber bis zum Fernseher oder Toaster.
Der größte Teil dieses nicht gesondert oder überhaupt nicht
zum Verkauf angebotenen Codes ist mit seiner Umgebung so innig verwoben,
dass die Wiederverwendung oder die Vervielfältigung sehr schwierig ist.
Diese Einschränkung besteht unabhängig da
, ob es sich bei dieser
Umgebung um einen Satz
Geschäftsprozeduren innerhalb eines Unternehmens
handelt, oder um die Steuerung der Treibstoffpumpe eines Mähdreschers.
Aus diesem Grund ist die Anpassung solcher Software an eine sich ständig
verändernde Umgebung ein gewaltiger Aufwand.
Diese Arbeit wird "Wartung" genannt und jeder Softwareentwickler oder
Systemanalytiker wird einem erklären, dass sie den überwiegenden
Anteil an den Kosten (mehr als 75 Prozent) verursacht. Die Folge da
ist,
dass Programmierer die meiste Zeit mit dem Verfassen oder der Wartung
Code verwenden, der überhaupt keinen Warenwert hat - eine Tatsache,
der sich der Leser jederzeit selbst überzeugen kann; man muss nur
die entsprechenden Stelleninserate einer beliebigen Tageszeitung betrachten.
Sich den Arbeitsmarkt im Anzeigenteil einer regionalen Zeitung näher
anzusehen ist ein lehrreiches Experiment, das ich jedem Leser ans Herz legen
will. Untersuchen Sie die Angebote für Programmierer, Software-Engineering
und Unternehmens-EDV nach Positionen, die Entwicklung
Software zum Gegenstand
haben. Ordnen Sie die Jobs danach, ob die Software für den eigenen Gebrauch
im Unternehmen oder den Verkauf entwickelt werden soll.
Sehr schnell wird klar, dass, sogar nach der am weitesten gefassten Definition
"für den Verkauf", wenigstens neunzehn
zwanzig der gebotenen
Gehälter durch den Gebrauchswert (also für ein Investitionsgut)
bezahlt werden. Das ist der Grund für unsere Annahme, dass nur 5 Prozent
der Industrie durch den direkten Ertrag aus dem Verkauf der Software bezahlt
wird. Beachten Sie aber, dass der Rest der Analyse in diesem Text für
die konkreten Ziffern relativ unempfindlich ist - auch wenn es 15 oder sogar
20 Prozent wären: die ökonomischen Konsequenzen blieben gleich.
(Wenn ich auf technisch orientierten Konferenzen spreche, beginne ich meine
Rede für gewöhnlich mit zwei Fragen: wie viele Leute im Publikum
werden für das Entwickeln
Software bezahlt, und wie viele da
arbeiten an Software, die für den Weiterverkauf bestimmt ist. Fast immer
ist es so, dass ich auf die erste Frage einen ganzen Wald
erhobenen
Händen zur Antwort bekomme, und nur ganz wenige oder gar keine auf die
zweite - was für meine Zuhörer keine geringe Überraschung
ist.)
Auch die zweite Annahme im Folklore-Modell der Softwareamortistation ist
nicht stichhaltig, was sogar noch leichter demonstriert werden kann. Die
Theorie, dass der Warenwert
Software ihren Entwicklungs- oder
Ersetzungskosten entspricht, kann durch Untersuchen des tatsächlichen
Verhaltens der Konsumenten widerlegt werden. Es gibt viele Güter, für
die diese Proportion richtig ist (wenigstens vor der Wertminderung) -
Lebensmittel, Automobile, Industrieanlagen. Es gibt sogar noch mehr immaterielle
Güter, deren Warenwert eng mit den Entwicklungs- oder Ersetzungskosten
verknüpft ist - Vervielfältigungsrechte für Musik oder Landkarten
etwa. Solche Erzeugnisse können ihren Wert behalten oder sogar
vergrößern, wenn der ursprüngliche Hersteller verschwindet.
Wenn dagegen der Hersteller eines Softwareprodukts bankrott geht (oder sein Produkt einstellt), sinkt der maximale Preis, den die Konsumenten bereit sind zu bezahlen, sehr schnell gegen null. Dieser Höchstpreis ist vom theoretischen Gebrauchswert oder den Entwicklungskosten oder denen eines funktionellen Äquivalents unabhängig. Die Richtigkeit dieser Annahme können Sie leicht selbst überprüfen - sehen Sie dazu nur in einer Softwarehandlung den Korb mit den Restposten durch.
Wie sich Händler gegenüber pleite gegangen Herstellern verhalten, ist sehr aufschlussreich. Es zeigt, dass die Händler etwas wissen, was die Hersteller nicht wissen: der Preis, den Konsumenten bereit sind zu bezahlen, wird praktisch ruiniert, wenn für das Produkt in Zukunft kein Service mehr zu erwarten ist. 'Service' bedeutet in diesem Zusammenhang Erweiterungen, Upgrades und Folgeprojekte des Herstellers.
Anders gesagt, ist die Software-Industrie eine Dienstleistungsindustrie; allerdings eine, die unter der unbegründeten, aber sich hartnäckig haltenden Annahme operiert, eine Güterindustrie zu sein.
Es ist wertvoll, zu untersuchen, warum wir normalerweise zu dieser falschen
Vorstellung neigen. Der schlichte Grund ist vielleicht, dass der kleine Teil
der Softwareindustrie, der seine Erzeugnisse zum Verkauf anbietet, gleichzeitig
der einzige ist, der diese Produkte auch bewirbt. Ein weiterer ist
möglicherweise, dass einige der sichtbarsten und am massivsten beworbenen
dieser Artikel Computerspiele sind, die ja so gut wie keine laufende
Dienstleistung benötigen. (Ausnahmen
dieser Regel gibt es, sie sind
aber selten) [SH]. Man sollte auch beachten,
dass der Fertigungswahn zu einer Vergebührungsstruktur einlädt,
die an der Kompensation für die Entwicklungskosten völlig vorbei
geht. Wenn man annimmt (was allgemein anerkannt ist), dass über 75 Prozent
der Kosten für die gesamte Lebensdauer eines Softwareprojekts auf die
Wartung, die Fehlerbehebung und die Erweiterung entfallen, kommt man dahinter,
dass die übliche Preispolitik der Hersteller für alle Beteiligten
eine schlechte Entsprechung ist: verrechnet wird ja tatsächlich ein
hoher Preis beim Kauf und ein sehr geringer oder gar nichts für die
die Betreuung und Upgrades.
Die Konsumenten verlieren in diesem Spiel, denn obwohl die Herstellung
Software eigentlich eine Dienstleistungsindustrie ist, verleiten die Anreize
eines Fabrikmodells nicht zum Anbieten
kompetenten Services. Solange
die Einnahmen des Herstellers durch den Verkauf
Bits zustande kommen,
wird der meiste Aufwand in die Herstellung und die Vermarktung dieser Bits
gehen; die Help Desks werden nicht als Profit Center angesehen, führen
ein ungeliebtes Schattendasein und werden nur gerade soweit durch das absolute
Minimum unterstützt, um nicht eine kritische Anzahl
Kunden zu
verprellen.
Die andere Seite dieser Medaille ist, dass die meisten Hersteller, die an
dieses Fabrikmodell glauben, auf lange Sicht gesehen, untergehen werden.
Die Mittel für unbegrenzten Support durch einen einmal vergüteten
fixen Preis zu bezahlen, ist nur in Märkten vertretbar, die so schnell
wachsen, dass man seine heutigen Kunden durch die Geschäfte
morgen
finanzieren kann. Sobald der Markt gereift und gesättigt ist, werden
die meisten Hersteller keine andere Wahl haben als die, entweder diese Ausgaben
zu drosseln oder das Produkt stillzulegen.
Egal wie die Entscheidung ausfällt, das Resultat wird sein, dass sich die Kunden an Mitbewerber wenden. Man kann für kurze Zeit aus dieser Falle geraten, indem man bloße Ausbesserungen in der Software als neue Produkte zu einem neuen Preis verkauft, was die Konsumenten aber sehr schnell ermüdet. Langfristig gesehen ist daher der einzige Ausweg aus dieser Klemme, ein Monopol, also keine Mitbewerber, zu haben. Monopolisten kann es aber immer nur einen geben. Tatsächlich haben wir dieses "Ausbluten durch Support" oft beobachten können.
Sogar vitale Hersteller auf Platz zwei in einem lukrativen Nischenmarkt waren
da
betroffen, die Beispiele reichen
proprietären PC-Betriebsystemen
über Textprozessoren, Buchhaltungsprogrammen bis zu Business- Software
im allgemeinen. Die grotesk falschen Anreize des Fabrikmodells führen
zu einem Markt, in dem der Gewinner alles bekommt, und das auf Kosten seiner
Kunden.
Aus dem bisher Gesagten können wir schon beginnen, unsere eigenen Einsichten
über die Gründe zu entwickeln, aus denen Open Source-Software für
die bestehende Ordnung am Markt nicht eine bloße technologische, sondern
auch wirtschaftliche Herausforderung darstellt. Das Resultat
"Gratis"software, so scheint es, ist, uns in eine Welt zu bewegen, in der
die Vergebührung
Dienstleistungen dominiert - und auf die
Strukturschwäche hinzuweisen, die eine Kompensation
Entwicklungskosten
durch Verkauf
Closed Source-Bits darstellt.
Der Begriff "gratis" ist aber noch in anderer Weise irreführend. Die Kosten einer Ware zu senken, führt in der Regel zu einer Zunahme, nicht Abnahme, der Investitionen in die dazu gehörenden Infrastruktur. Wenn die Preise für Autos sinken, steigt der Bedarf nach Automechanikern - was auch ein Grund dafür ist, aus dem in einer Open Source-Welt sogar jene 5 Prozent der Programmierer gut zu essen hätten, die heute noch durch den Erlös aus dem Verkauf dieser Software bezahlt werden. Die Verlierer bei einem solchen Übergang wären nicht die Entwickler, sondern die Investoren einer unangemessenen Closed Source-Strategie.
4. Der Mythos
"Information WILL gratis sein"
Es gibt noch einen weiteren Irrglauben, der dem des Fertigungswahns gleichzeitig
entspricht und entgegenläuft. Er verführt die Menschen, die über
die Ökonomie des Open Source- Modells nachdenken zu der Annahme, dass
marginale Kosten bei der Vervielfältigung
Software Verkaufspreis
null zu bedeuten hat - "Information wants to be free".
In seiner allgemeinsten Form kann man diesen Mythos leicht entschärfen.
Nehmen wir einmal den Wert
Information, die den leichten Erwerb eines
attraktiven Guts bedeutet - eine Schatzkarte etwa, oder die Nummer eines
Schweizer Bankkontos. Obwohl diese Information für Kosten
null
vervielfältigt werden kann, gilt das für das zugehörige Gut
nicht. Daher kann man
den Vervielfältigungskosten nichts über
den eigentlichen Wert ableiten.
Wir bringen diesen Mythos hauptsächlich deswegen ins Spiel, um festzustellen, dass er für die Kosten/Nutzen-Rechnung bei Open Source unerheblich ist; später werden wir sehen, dass nicht einmal die Annahme, er wäre stichhaltig (der Wert der Ware Software ist null) Auswirkungen für unser Modell hat.
5. Die Kommune steht Kopf
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
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
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, dass Ü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, dass die Bauern sich zerstreiten werden, dass 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, dass das genaue Gegenteil
der Fall ist. Umfang und Tiefe
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, dass 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
Leuten erkennt, dass dieser Fix für sie einen gewissen
Geldwert hat. Wie hebe ich eine Gebühr
diesen Leuten ein?
Konventionelle Zahlungssysteme haben so hohe Unkosten, dass sie für die hier angebrachten
Kleinstbeträge zu einem echten Problem werden.
Noch treffender könnte die Beobachtung sein, dass dieser Wert nicht nur schwer einzutreiben, sondern oft sogar schwer zu bestimmen ist. Lassen Sie uns ein Gedankenexperiment machen. Nehmen wir, das 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
F. A. Hayeks "Kalkulationsproblem"
- der Handel mit dem korrigierten 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 Spieltheoretiker zu sagen.
Bei der Analyse einer derartigen Kooperation ist es wichtig, dass trotz der
vorhandenden "Trittbrettfahrer"-Problematik (wegen fehlender finanzieller
oder äquivalenter Anreize mangelt es an Beiträgen an
Entwicklungsarbeit) diese Problematik
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 Entwickler; 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 erhö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
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üsste 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
) Projekten stark und invers mit der Anzahl der Hürden, die
man als Codespender überwinden muss. 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
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 Geschäftsmodelle erzeugen Nischen, in denen Open Source-Entwicklungen gedeihen können?
6. Gründe für Closed Source
Bevor wir uns an eine Taxonomie
Open Source-Geschäftsmodellen wagen
können, sollten wir uns mit den finanziellen Vorteilen
Closed Source
befassen. Was genau wird durch Geheimhaltung
Source Code eigentlich
geschützt?
Nehmen wir einmal an, Sie engagieren jemanden, der Ihnen ein spezialisiertes Buchhaltungspaket für Ihre Firma verfassen soll. Das Problem wird durch Ausschluss der Öffentlichkeit nicht besser gelöst werden, die einzigen rationalen Gründe für diese Politik sind nur: Sie wollen dieses Paket an andere weiterverkaufen, oder Sie wollen verhindern, dass Mitbewerber diese Software auch verwenden.
Die offensichtliche Antwort ist also, dass Sie den Warenwert schützen, aber für die 95 Prozent der Software, die nur für den internen Gebrauch geschrieben wird, ist das nicht anwendbar. Was gewinnen Sie also noch durch Ausschluss der Öffentlichkeit?
Der zweite Grund (Schutz des Wettbewerbsvorteils) erfordert etwas genauere
Untersuchungen. Nehmen wir an, Sie veröffentlichen Ihr Softwarepaket
unter Open Source. Es wird sehr beliebt und gewinnt durch Verbesserungen,
die
der Gemeinde seiner Benutzer vorgenommen werden. Dann beginnen auch
Ihre Mitbewerber, es zu verwenden - und genießen alle Vorteile, ohne
etwas investiert zu haben, was für Sie durch Geschäftsrückgang
spürbar wird. Ist das ein Argument gegen eine Veröffentlichung
unter Open Source?
Vielleicht - vielleicht aber auch nicht. Die wirklich wichtige Frage ist,
ob der Gewinn aus der Aufteilung des Entwicklungsaufwands höher ist
als Ihr Verlust durch die erhöhte Konkurrenz der Trittbrettfahrer. Viele
Leute neigen hier zu Fehleinschätzungen, weil sie a) das Mehr an
Funktionalität durch mehr Entwickler ignorieren, und b) sie nicht sehen,
dass die Entwicklungskosten dadurch sinken, die sie ja aber ohnedies hätten
bestreiten müssen. Diese Entwicklungskosten als Aufwand für die
Veröffentlichung unter Open Source zu verrechnen, ist aber ein Fehler.
Es gibt noch andere Gründe für den Ausschluss der Öffentlichkeit,
die aber alle schlichtweg irrational sind. Sie könnten beispielsweise
unter dem falschen Eindruck stehen, dass geheimgehaltener Quellcode Ihr
Firmensystem sicherer gegen das Ausspähen
Eindringlingen und Crackern
macht. Sollten Sie das wirklich denken, empfehle ich, augenblicklich die
ärztliche Hilfe eines Kryptographen in Anspruch zu nehmen. Menschen,
deren Paranoia ihr Beruf ist, wissen Besseres, als ihre Sicherheit Closed
Source-Programmen anzuvertrauen - sie haben ihre Erfahrungen in dieser Hinsicht
schon auf die schmerzhafte Art erworben. Sicherheit ist ein Aspekt
Zuverlässigkeit, und nur Algorithmen und Implementationen kann getraut
werden, die
Kollegen in der Gemeinde gründlich geprüft wurden
(merken Sie sich den Fachausdruck für diese Prüfung durch Kollegen:
"Peer Review").
7. Open Source und Gebrauchswert-Modelle
Ein Vorzug der Schlüsselerkenntnis, dass man unter Warenwert und Gebrauchswert genau unterscheiden muss, ist die Beobachtung, dass 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 Entwicklergehälter ausschließlich durch den Gebrauchswert amortisiert werden.
7.1 Fallstudie 1: Apache, Aufteilen des Aufwands
Nehmen wir an, Sie arbeiten für eine Firma, deren Geschäft
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 muss 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 proprietären Webserver. In diesem Fall verwetten Sie
Ihre Nerven darauf, dass der Hersteller mit Ihnen bei Zielsetzungen und
Zukunftsplänen an einem Strang zieht und darauf, dass der Hersteller
die erforderliche technische Kompetenz hat, um den Server befriedigend zu
implementieren. Sogar unter der Annahme, dass 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 Schluss kommen, dass sie ein
gewaltiges Problem hat, sobald Sie kündigen oder in Pension gehen.
Treten Sie der Apache Group bei. Der Server Apache
wurde
einer durch das Internet verbundene Gruppe
Webmastern geschaffen,
die erkannten, dass es klüger ist, ihre jeweiligen Aufwendungen für
die Erweiterung und Verbesserung eines einzigen Codepools zu teilen, um eine
große Zahl
parallel laufenden Entwicklungen zu betreiben. Dadurch
kamen sie in den Genuss 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
Netcraft ansieht. Sie zeigt, dass Apache seit seiner ersten Freigabe
gegenüber allen anderen proprietä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
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.
7.2 Fallstudie 2: Cisco, Aufteilen des Risikos
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 auf einem beliebigen Drucker B (der im nächsten Zimmer oder
tausend Kilometer entfernt sein kann) drucken zu lassen, sollte das System
sicherstellen, dass im Falle eines Papierstaus oder einer leeren Tonerkassette
der Druckjob zu einem anderen nahe gelegenen Drucker umgeleitet wird. Das
System musste auch in der Lage sein, solche Probleme an den Druckeradministrator
weiterzuleiten.
Das Duo entwickelte einen Satz
cleveren Modifikationen des unter Unix
standardisierten Druckerspoolers und ergänzte einige Scripts, was zur
Erfüllung der Aufgabe ausreichte. Dann erkannten sie, dass sie (und
Cisco) ein Problem hatten.
Das Problem war, dass 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, dass 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, dass
Cisco keinen Verlust
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, dass 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.
8. Warum der Warenwert problematisch ist
Open Source macht die Vergebührung des direkten Warenwerts
Software
schwierig. Das Problem ist kein technisches. Quellcode ist nicht weniger
leicht zu kopieren als Binärdateien, und das Exekutieren der Gesetze
für Lizensierung und Copyright wäre nicht notwendigerweise
komplizierter als für Closed Source-Produkte.
Die Schwierigkeit liegt mehr in der Natur der sozialen Abkommen, die Open
Source-Projekte ermöglichen. Aus drei einander bestärkenden
Gründen verbieten die Open Source-Lizenzen die meisten Einschränkungen
beim Gebrauch, der Weitergabe und Veränderung, die eine Einhebung direkter
Gebühren für den Verkauf bedeuteten würde. Um diese Gründe
zu verstehen, müssen wir den sozialen Kontext untersuchen, in dem sich
diese Lizenzen entwickelt haben; die Rede ist
der
Internet-Hackerkultur.
Trotz der Mythen, die es auch 1999 noch über die Hackerkultur gibt,
hat keiner dieser Gründe mit Marktfeindlichkeit zu tun. Während
tatsächlich nur eine Minderheit Gewinnmotiven feindlich gegenüber
steht, demonstriert die allgemeine Bereitschaft der Gemeinde, mit
gewinnorientierten Vertriebsfirmen wie Red Hat, SuSE und Caldera zu kooperieren,
dass die meisten Hacker gerne mit der Geschäftswelt zusammenzuarbeiten,
wenn es ihnen nützt. Die wahren Gründe, aus denen Hacker direkte Erträge
aus dem Verkauf
Lizenzen ablehnen, sind subtiler und interessanter.
Ein Grund hat mit Symmetrie zu tun. Während die meisten Open
Source-Entwickler nicht grundsätzlich Einwände erheben, wenn andere
ihren Spenden profitieren, verlangen die meisten, dass niemand in einer
privilegierten Position, zu Profiten zu kommen, sein darf. Otto Normalhacker
ist einverstanden, dass Firma Beutelschneyder & Bluffer durch den Verkauf
der Software Gewinn macht, aber nur solange, wie auch Otto selbst diese
Möglichkeit hat.
Ein weiterer Grund hat mit unbeabsichtigten Folgen zu tun. Hacker konnten beobachten, dass Lizenzen, Einschränkungen und Gebühren für den 'kommerziellen' Gebrauch oder den Verkauf (eine sehr übliche Form der Einhebung des direkten Warenwerts, und keine, die so unangemessen ist, wie es auf den ersten Blick aussieht) einige ernstzunehmende Auswirkungen haben. Eine sehr konkrete ist der juristische Schatten, der dadurch über Aktivitäten wie den Vertrieb durch günstige CD-ROM-Anthologien geworfen wird, zu denen wir aber eigentlich ermuntern sollten. Allgemeiner ausgedrückt, führen Einschränkungen für die Verwendung, Veränderung, Verkauf und Vertrieb zu Unkosten für die Kontrolle und Exekutierung dieser Einschränkungen und zu einem Klima der Angst vor juristischen Risiken.
Diese Wirkung wird zu Recht als schädlich angesehen, und es gibt
daher einen starken sozialen Druck in Richtung einfach gehaltener Lizenzen, die
frei
Einschränkungen sind.
Der letzte und wichtigste Grund hat mit der Dynamik der Geschenkekultur (beschrieben in [HtN] zu tun, die ja ständige Kritik und Verfeinerung durch Kollegen (peer-review) ermöglicht. Einschränkungen in den Lizenzen, die geistiges Eigentum schützen oder den Warenwert erhalten sollen, haben oft den Effekt, dass es juristisch unmöglich wird, unabhängige Entwicklungszweige für ein Projekt einzurichten (ein Beispiel dafür ist Suns sogenannte "Community Source License" für Jini und Java). Obwohl so ein "forking" allgemein unbeliebt ist und nur als ein Notbehelf gesehen wird (aus Gründen, die in [HtN] ausführlich erörtert werden), gilt es als wichtig, auf diesen Notbehelf zurückgreifen zu können, wenn sich der Betreiber des Projekts als inkompetent herausstellt oder einen Rückzieher macht (also zu einer weniger öffentlichen Lizenz übergeht).
Die Hackergemeinde hat Einfluss bei der Symmetrie, daher toleriert sie Lizenzen
wie Netscapes NPL, die dem Urheber des Codes einige Gewinn-Privilegien
einräumen (was bei NPL besonders ausgeprägt ist: es beinhaltet
das exklusive Recht, den öffentlichen Mozilla-Quellcode für da
abgeleitete Produkte zu verwenden, darunter eine Closed Source-Version).
Sie hat weniger Einfluss bei den ungewollten Konsequenzen und gar keine bei
der Möglichkeit, einen neuen, unabhängigen Entwicklungszweig ("fork")
zu schaffen und zu verfolgen (was der Grund für die Ablehnung
Suns
"Community License" (Geimeindelizenz) für Java und Jini ist).
Diese Gründe erklären die Klauseln der Open Source-Definition, die geschrieben wurde, um dem Konsens der Hacker-Gemeinde über die zentralen Merkmale der Standardlizenzen (GPL, BSD-Lizenz, MIT-Lizenz und Artistic License) zu entsprechen. Diese Klauseln haben den Effekt (aber nicht die Absicht) das Einheben des direkten Warenwert sehr schwierig zu machen.
9. Modelle für indirekten Warenwert
Nichtsdestoweniger gibt es Wege, auf denen man Märkte für Software-bezogene Dienstleistungen erzeugen kann, die so etwas wie den indirekten Warenwert vergüten. Dafür gibt es fünf bekannte und zwei spekulative Modelle (in Zukunft könnten noch mehr entwickelt werden).
9.1 Lockangebot/Market Positioner
Bei diesem Modell verwendet man Open Source-Software, um sich auch mit
proprietärer Software am Markt zu positionieren, die direkt vergütet
wird. Die üblichste Variante ist, Open Source- Klientensoftware zu
verschenken, um Server-Software verkaufen zu können, oder mit Open
Source-Produkten eine Website zu promoten, die Gewinne abwirft (sei es durch
Vergebührung
Mitgliedschaften oder Werbung).
Netscape Communications,
Inc. verfolgte diese Strategie und veröffentlichte im März
1998 den Quellcode für ihren Browser Mozilla. Die Browser-Seite ihres
Geschäfts machte nur 13% der Erträge aus, und sank noch weiter,
als Microsoft mit dem ersten Internet Explorer herauskam. Die aggressive
Vermarktung des IE (und zweifelhafte Bundling-Praktiken, die später
zum Gegenstand eines Anti-Kartellverfahrens wurden) erodierte sehr schnell
Netscapes Anteil am Browser- Markt und führte zur Sorge, dass Microsoft
die Monopolisierung des Browsermarktes anstrebte und dann die de-facto-Kontrolle
über HTML verwenden würde, um Netscape vom Server-Markt zu
verdrängen.
Durch Veröffentlichung des Quellcodes für ihren noch immer
sehr beliebten Browser versperrte Netscape Microsoft praktisch die
Möglichkeit, sich ein Monopol zu schaffen. Netscape erwartete, dass die Open Source-Kollaboration
den Entwicklungs- und Korrekturprozess ankurbeln würde und hoffte,
dass Microsofts IE beim Wettrennen um die Definition
HTML auf ein
bloßes Hinterherlaufen reduziert werden würde.
Diese Rechnung ging auf. Im November 1998 eroberte Netscape Marktanteile
vom IE zurück. Zum Zeitpunkt, als Netscape durch AOL übernommen
wurde (Anfang 1999) war der Wettbewerbsvorteil klar genug, dass AOLs erste
Verlautbarung war, das Mozilla-Projekt weiterhin zu unterstützen.
9.2 Widget Frosting - Teile mit Glasur
Dieses Modell ist eines für Hardware-Hersteller. "Hardware" bedeutet
in diesem Zusammenhang jegliche Peripherie, Erweiterungskarten und komplette
Computersysteme. Der Marktdruck zwang die Hersteller, Software für ihre
Hardware zu entwickeln (
Gerätetreibern über Konfigurationssoftware
bis zu kompletten Betriebssystemen), die aber selbst keine Gewinne abwirft.
Sie stellt Unkosten dar, oft sehr hohe.
In dieser Situation macht die Veröffentlichung des Quellcodes keine
Umstände. Es gibt keine Erträge zu verlieren, daher fällt
diese Schattenseite weg. Was der Hersteller gewinnt ist ein ungleich
größerer Pool
Entwicklern, rascheres und flexibleres Reagieren
auf die Bedürfnisse der Kunden und mehr Zuverlässigkeit durch Peer
Review. Portierungen auf andere Plattformen erfolgen kostenlos. Dazu kommt
wahrscheinlich noch erhöhte Kundenloyalität, da die technischen
Stäbe der Kunden mehr Zeit in den Code und Anpassungen investieren,
die sie wirklich benötigen.
Es gibt aber eine Reihe
Einwänden, die Hersteller vorbringen,
typischerweise im Zusammenhang mit Gerätetreibern. Statt deren Diskussion
hier mit den allgemeineren Belangen zu verwässern, habe ich ihr einen
eigenen Anhang gewidmet.
Das Resultat der "Zukunftssicherheit"
Open Source ist in Hinblick auf
dieses "Glasurmodell" besonders ausgeprägt. Hardware-Produkte haben
eine begrenzte Lebensdauer und werden nicht ewig betreut; danach sind die
Kunden auf sich allein gestellt. Wenn sie aber Zugang zum Quellcode haben
und gewünschte Anpassungen selbst vornehmen können, ist es
wahrscheinlicher, dass sie zufrieden sind und immer wieder kommen.
Ein sehr dramatisches Beispiel für die Anwendung der Glasurmethode war
Apple Computers Entscheidung, die Mitte März 1999 gefallen ist: "Darwin",
der Kern ihres MacOSX Server- Betriebssystems, wurde Open Source.
9.3 Rezepte herschenken und ein Restaurant eröffnen
Bei diesem Modell schafft man sich durch Open Source-Software eine Position
am Markt für Dienstleistungen, nicht am Markt für Closed
Source-Software.
(Früher nannte ich das "Rasierer herschenken, Klingen verkaufen", die
Verbindung ist aber nicht so stark wie in der Analogie Rasierer/Klingen).
Das ist es, was Red Hat und andere Linux-Distributoren tun.
Sie verkaufen nicht wirklich die Software, die Bits selbst, sondern den Mehrwert,
der durch Zusammenstellen und Testen eines funktionierenden
Betriebssystems entsteht. Sie verkaufen die (wenn auch nur implizite) Garantie, dass es
sich dabei um ein serienreifes Produkt handelt, das mit allen anderen
Exemplaren vom selben Hersteller kompatibel ist. Weitere Elemente dieses Geschäftsmodells
sind etwa kostenloser Support für die Installation und Optionen auf
Verträge für technische Betreuung.
Diese Markt-erzeugende Wirkung
Open Source kann sehr stark sein, besonders
bei Firmen, die sich zwangsläufig ohnehin in einer Dienstleisterposition
befinden. Ein sehr lehrreiches aktuelles Beispiel ist Digital Creations,
eine Web-Designfirma, die auf komplexe Datenbank- und Transaktionssites
spezialisiert ist. Ihr zentrales Tool, die Kronjuwelen geistigen Eigentums,
ist ein Object Publisher, der schon mehrere Namensgebungen und Inkarnationen
hinter sich hat und jetzt Zope heißt.
Als die Leute bei Digital Creations sich um Venture Capital umsahen, analysierte
ein interessierter VC die anvisierte Marktnische der Firma, die Leute und
die Tools. Seine Empfehlung lautete dann, den Quellcode
Zope als Open
Source zu veröffentlichen.
Nach den traditionellen Maßstäben der Software-Industrie sah das
nach einem völlig durchgeknallten Schachzug aus. Die konventionelle
Weisheit der Betriebswirte lautet hier, dass die eigentliche Substanz der
Firma in ihrer Software Zope liegt und unter keinen Umständen hergegeben
werden darf. Der VC hatte aber zwei miteinander verwandte Einsichten. Die
eine ist, dass Digital Creations' eigentliche Substanz die Gehirne und die
Talente seiner Leute ist.
Die zweite Einsicht ist, dass Zope als markterzeugendes Produkt mehr Wert
schaffen kann als wenn es
der Firma unter Verschluss gehalten wird.
Um das zu erkennen sollte man zwei Szenarios miteinander vergleichen. Im
konventionellen Szenario bleibt Zope Digital Creations' Geheimwaffe. Unterstellen
wir, dass das sehr gut funktioniert. Das Ergebnis wird sein, dass die Firma
überlegene Qualität schneller liefern kann als die Konkurrenz -
aber niemand kann das wissen. Es wird sehr leicht sein, Kunden glücklich
zu machen, aber sehr schwierig, überhaupt einen Kundenstamm
aufzubauen.
Der VC sah aber, dass die Veröffentlichung
Zope zur wichtigsten
Reklame für Digital Creations tatsächliche Substanz werden könnte
- ihre Mitarbeiter. Seine Erwartung war, dass die Kunden beim Erwägen
Zope es für günstiger halten würden, die Experten anzuheuern,
als eigenes Zope-Know-How zu erarbeiten.
Einer der Köpfe hinter Zope hat in der Zwischenzeit bestätigt,
dass die Open Source-Strategie "viele Türen geöffnet hat, die
andernfalls verschlossen geblieben wären". Potentielle Kunden reagieren
tatsächlich auf die Logik hinter dieser Situation - und Digital Creations
geht es dementsprechend sehr gut.
Ein weiteres, minutenaktuelles Beispiel ist
e-smith, inc. Diese
Firma verkauft Support-Verträge für schlüsselfertige Open
Source-Internetserver-Software, ein angepasstes Linux. Einer seiner Leiter
kommentiert
das Wachstum der kostenlosen Downloads so: "Die meisten Firmen würden
das als Raubkopien ansehen, wir halten es für Gratiswerbung".
9.4 Accessorizing
Bei diesem Modell verkauft man Zubehör ("Accessories") für Open
Source-Software. Am unteren Ende wären das Kaffeebecher und T-Shirts,
am oberen Ende professionell redigierte und produzierte Dokumentation.
O'Reilly Associates, der Herausgeber vieler hochwertiger Standardwerke über
Open Source-Software, ist ein gutes Beispiel für so eine Zubehörfirma.
O'Reilly beschäftigt und unterstützt viele bekannte Open Source-Hacker
(wie Larry Wall und Brian Behlendorf), um ihre Reputation am
ihnen
gewählten Markt zu festigen.
9.5 Zukunft verschenken, Gegenwart verkaufen
Bei diesem Modell veröffentlicht man nur die Binaries unter einer Closed
License, die aber ein Ablaufdatum für den Ausschluss der
Öffentlichkeit enthält. Die Lizenz sieht dann beispielsweise so
aus, dass sie die freie Weitergabe gestattet, aber die kommerzielle Nutzung
ohne Gebühr verbietet und garantiert, dass die Software ein Jahr nach
dem Herauskommen oder nach einem Bankrott des Herstellers unter der Open
Source-Lizenz (GPL) freigeben wird.
Durch dieses Modell können die Kunden sicher sein, dass das Produkt
an ihre Bedürfnisse angepasst werden kann, da sie den Quellcode bekommen
werden. Das Produkt ist zukunftssicher , da es die Garantie gibt, dass die
Open Source-Gemeinde das Produkt übernehmen kann, sollte die Herstellerfirma
sterben.
Da der Verkaufspreis und die Umsätze auf diesen Erwartungen der Kunden
beruhen, sollte der ursprüngliche Hersteller mehr Gewinn machen als
durch eine ausschließliche Closed Source-Lizenz. Darüber hinaus
wird älterer Code, der unter die GPL gestellt ist, einer gründlichen
Peer Review unterzogen und durch Verbesserungen und Fehlerbehebungen wird
dem Hersteller ein Teil der 75 Prozent-Last der Wartung
den Schultern
genommen.
Dieses Modell wurde
Alladin Enterprises für ihr Programm Ghostscript
(ein PostScript-Interpreter für eine Reihe
Non- PostScript-Druckern)
erfolgreich angewendet.
Der Hauptnachteil dieses Modells ist, dass der Ausschluss der
Öffentlichkeit Peer Review und Anteilnahme in den Anfangsstadien des
Produktzyklus unmöglich macht, also genau dann, wenn das am dringendsten
benötigt wird.
9.6 Software herschenken, Gütesiegel verkaufen
Dies ist ein spekulatives Geschäftsmodell. Man veröffentlicht den Quellcode
einer Softwaretechnologie, behält sich eine Test-Suite oder einen Reihe
Kompatibilitätskriterien vor und verkauft dann den Benutzern ein
Gütesiegel, das einer bestimmten Implementation einer Technologie
Kompatibilität mit allen anderen Trägern des Siegels attestiert.
(So sollte Sun Microsystems Java und Jini handhaben).
9.7 Software herschenken, Inhalte verkaufen
Dies ist ein weiteres spekulatives Geschäftsmodell. Stellen Sie sich etwa
einen Börsenticker-Service vor. Der Wert liegt weder in der Klientensoftware
noch dem Server, sondern im Liefern
objektiver und stichhaltiger Information.
Daher veröffentlicht man alle Software und verkauft Abonnements der
Inhalte. Wenn Hacker den Klienten auf neue Plattformen portieren und in
verschiedener Weise verbessern, vergrößert sich automatisch Ihr
Markt .
(Aus diesem Grund sollte AOL den Quellcode seiner Klientensoftware
öffentlich zugänglich machen).
10. Wann öffentlich, wann nicht-öffentlich?
Nach der Untersuchung der Geschäftsmodelle, 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.
10.1 Was springt dabei heraus?
Der Closed Source-Ansatz gestattet es Ihnen, Gebühren für eingekapselte
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-Geschäftsmodelle sind darum herum aufgebaut. Bis vor
kurzem war ein gutes Verständnis des Gewinns aus Peer Review nicht so
verbreitet. Das Betriebssystem Linux aber zeigt, was wir wahrscheinlich schon
vor Jahren hätten lernen können, und zwar aus der Geschichte der
Kernsoftware des Internets und anderen Ingenieursfakultäten - dass 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
Service, Wertsteigerung und durch Zusatzmärkte
Gewinne machen können. Dieses Phänomen ist es, das hinter dem
bemerkenswerten Erfolg
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,
dass 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
Märkten dafür
geht. Das dramatische Wachstum des Internets verdankt sehr viel dem Umstand,
dass TCP/IP niemandem gehört und niemand daher die Schlüsselprotokolle
des Internets in einem proprietären Würgegriff hält.
Die Netzwerkeffekte hinter dem Erfolg
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,
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
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
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
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, dass 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.
10.2 Wie das alles zusammenpasst
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 Open
Source-Methode anzuwenden.
Das ist natürlich eine triviale Beobachtung. Nicht trivial ist aber
die Bemerkung, dass der Vorzug der Open Source-Methode schwieriger zu messen
und vorherzusehen ist als die Erträge aus eingekapselten Bits - dazu
kommt, dass 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
Open Source neu überdachte, so,
dass die Vorteile
Open Source mit dem Wert Null veranschlagt wurden.
Wie können wir also den Wert
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
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 maximieren. 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, dass
Open Source
hohem Wert ist, wenn a)
Zuverlässigkeit/Stabilität/Skalierbarkeit
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
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,
dass 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
Open Source wahrscheinlicher, dass der Wert
höher und nachhaltiger ist als der einer kurzsichtigen Closed
Source-Politik, die an der Vergebührung
geistigem Eigentum orientiert
ist.
Tatsächlich
impliziert die Fähigkeit
potentiellen Kunden, über
die zukünftigen Konsequenzen
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
Closed
Source-Software entscheiden, aber nicht für 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, dass 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, dass 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 Internets, Apache und die Linux- Implementation
des ANSI-standardisierten Unix API sind Schulbuchbeispiele für alle
fünf Kriterien.
Vor dem Zusammenwachsen
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
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 deren Wert nicht durch vollständige
Marktdurchdringung oder Netzwerkeffekte gesteigert wird (d)).
Hier ein Beispiel für einen solchen Extremfall. Anfang 1991 wurde
ich
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
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); obwohl ein erfahrener Werkmeister die Schnittmuster
in der Praxis auch händisch berechnen könnte.
Als weiteren springenden Punkt muss man im Auge behalten, dass 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.
Zusammenfassend kann man sagen, dass folgende Merkmale Evolutionsdruck in Richtung
Open Source erzeugen:
(a) Zuverlässigkeit, Stabilität und Skalierbarkeit sind
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.
10.3 Doom: Eine Fallstudie
Die Geschichte
id Softwares Spiele-Bestseller Doom illustriert die Wege,
auf denen der Druck des Marktes und Produktevolution die
Größenverhältnisse beim Gewinn
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),
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 Verschluss 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
"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 investiert hätte.
Alle diese Trends erhöhten die Wahrscheinlichkeit, nach der 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 Geschäftsmodell
Wirklichkeit.
Dooms kompletter Quellcode wurde Ende 1997 veröffentlicht.
10.4 Wann soll man seinen Quellcode aus dem Tresor holen?
Doom ist eine interessante Fallstudie, da es sich weder um ein Betriebssystem
noch um Kommunikations- oder Netzwerksoftware handelt; es ist
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, dass der Nutzen
Open Source mehr und mehr
steigt.
Wenn die gegenwärtigen Trends sich fortsetzen, wird die bedeutendste
Herausforderung an die Software-Technologie und das Produktmanagement 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
Peer Review auszunutzen
und durch Dienstleistungen und Sekundärmärkte in den Genuss
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
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, dass sowohl der
Pool
Benutzern als auch der Pool
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.
11. Das Software-Geschäft als Ökologie
Die Open Source-Gemeinde hat sich in einer Weise selbst organisiert, die Durchschlagskraft und Produktivität des Open Source-Modells noch verstärkt.
Besonders in der Linux-Welt ist eine ökonomisch bedeutsame Tatsache
die, dass es mehrere miteinander konkurrierende Linux-Distributoren gibt,
die eine
den Entwicklern gesonderte Schicht bilden. Die Entwickler schreiben
Code und machen ihn über das Internet allgemein verfügbar. Jeder
Distributor wählt eine bestimmte Untermenge aus dem bereitgestellten
Code aus, verpackt ihn, stempelt ihm seinen besonderen Markennamen auf und
verkauft ihn an seine Kunden. Die Benutzer haben die Wahl zwischen mehreren
Distributionen und können eine Distribution selbst ergänzen, indem
sie weiteren Code direkt
den Entwicklersites herunterladen.
Der Effekt dieser separaten Schichten ist, dass sie einen sehr lebhaften
und reibungslosen internen Markt für Verbesserungen erzeugen. Die Entwickler
konkurrieren in der Arena der Softwarequalität um die Zuwendung der
Distributoren und Benutzer. Die Distributoren konkurrieren in der Arena der
Zweckmäßigkeit ihrer Auswahl und des Supports
Code um
Benutzerdollars.
Ein unmittelbarer Effekt dieser internen Marktstruktur ist es, dass kein
Knoten im Netz unentbehrlich ist. Entwickler können aussteigen; sogar
wenn ihr Teil des Codes nicht direkt
anderen weiterentwickelt wird, kann
im Wettbewerb um die Aufmerksamkeit sehr rasch ein funktionales Äquivalent
geschaffen werden. Distributoren können bankrott machen oder sich vom
gemeinsamen Open Source-Code absondern. Die Ökologie als Ganze reagiert
schneller auf Marktforderungen und ist für Schocks jeglicher Art weniger
anfällig als das monolithischen Herstellern
Closed
Source-Betriebssystemen prinzipiell überhaupt möglich ist.
Ein weiterer wichtiger Effekt sind geringere Unkosten und erhöhte
Produktivität durch Spezialisierung. Entwickler werden nicht durch jene
Tyrannei geplagt, die konventionelle Closed Source-Projekte sehr oft mit
sich bringen und sie in Sümpfe verwandelt - es gibt keine sinnlosen
und ablenkenden Leistungsmerkmale, die vom Marketing vorgegeben werden, um
möglichst viele Punkte auf die Verpackung drucken zu können; es
gibt kein inkompetentes Management, das die Verwendung
unzulänglichen
Programmiersprachen oder veralteten Entwicklungsumgebungen erzwingt; es gibt
keine Forderung nach dem "Neuerfinden des Rades" im Namen der
Produktdifferenzierung oder des Schutzes
geistigem Eigentum; und es gibt
auch keine - und das wiegt am schwersten - Termine. Es gibt keinen Druck,
Version 1.0 noch vor einer befriedigenden Vollendung bei der Tür
hinauszubringen - was im allgemeinen nicht nur zu höherer Qualität,
sondern auch einer rascheren Lieferung
brauchbaren Resultaten führt
(eine Erörterung der übereilten Markteinführung findet sich
in DeMarco und Listers [DL]. Sie nennen
diesen Managementstil "weckt mich auf, wenns vorbei ist").
Distributoren, auf der anderen Seite, können sich auf jene Dinge
spezialisieren, die Distributoren am besten können. Befreit
der
Notwendigkeit, umfangreiche und niemals endende Softwareprojekte zu finanzieren,
können sich auf die Integration, Qualitätssicherung, Verpackung
und Service konzentrieren.
Durch die ununterbrochene Überwachung und das ununterbrochene Feedback durch die Benutzer, die ein integraler Bestandteil der Open Source-Methode sind, werden sowohl die Distributoren als auch die Entwickler zu Ehrlichkeit angehalten.
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, dass 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, dass der Wert individueller Beiträge zum Codestamm schwierig zu vergebühren ist. Dieses Argument hat aber weniger Einfluss 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 Ökonomie
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
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
Linux hinzuweisen, ist das Verhalten der
Hersteller
proprietären Unix-Varianten in den 1980ern. Trotz der
endlosen 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
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, dass dies auch bei Linux passiert - aus dem einfachen
Grund, dass alle Distributoren die Auflage haben,
einem gemeinsamen Codestamm
aus zu operieren. Differenzierung ist keinem
ihnen wirklich möglich,
da die Lizenzen, unter denen Linux entwickelt wird, das Teilen
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
allen Beteiligten verstanden wird, denkt niemand über
Manöver auch nur nach, die zur Fragmentierung
proprietä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
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
Monopolisierung
vornherein
aus. Wenn sich Linux-Leute darüber Sorgen machen, wird in der Regel
der Name "Red Hat" gemurmelt - des größten und erfolgreichsten
Distributors (mit ca. 90 Prozent Marktanteil in den USA). Beachtenswert ist
aber, dass innerhalb
Tagen nach Red Hats 6.0-Release im Mai 1999 - noch
bevor Red Hats CD-ROMs in Stückzahlen ausgeliefert wurde - CD-ROM-Images
Red Hats eigener FTP-Site
Verlegern und mehreren anderen
CD-ROM-Distributoren angeboten wurden, und das unter dem
Red Hat erwarteten
Listenpreis.
Red Hat selbst war das gleichgültig, denn ihren Gründern ist
völlig klar, dass sie die Bits ihres Produktes nicht besitzen und nicht
besitzen können; die soziale Norm der Linux-Gemeinde verbietet das.
In einer neueren Auflage
John Gilmores berühmter Beobachtung, dass
das Internet Zensur als schädlich interpretiert und Wege darum herum
findet, wurde richtig gesagt, dass 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, dass 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.
13. Offene Forschung und Entwicklung und die Renaissance der Patronage
Die Infusion
bedeutenden Mitteln in die Open Source-Welt hat noch eine
weitere Auswirkung. Die Stars der Gemeinde finden gerade heraus, dass sie
für das bezahlt werden können, was sie gerne machen und nicht mehr
darauf angewiesen sind , ihre Projekte als Hobby zu betreiben, das durch
ein anderes Tagesgeschäft finanziert werden muss. Firmen wie Red Hat,
O'Reilly & Associates und VA Linux Systems bauen gerade eigene,
unabhängige Forschungsabteilungen auf, die ausdrücklich dafür
ausgelegt sind, Open Source-Kreative zu beschäftigen.
Wirtschaftlich gesehen macht das nur dann Sinn, wenn die Kosten pro Kopf eines solchen Software-Labors aus den erwarteten Gewinnen aus einem schneller wachsenden Markt leicht bezahlt werden können. O'Reilly kann es sich leisten, die treibende Kraft hinter Perl und Apache für ihre Arbeit zu bezahlen, weil sie für ihren Aufwand erwarten können, mehr Bücher über Perl und Apache zu verkaufen. VA Linux Systems kann sein Labor finanzieren, da Linux den Gebrauchswert ihrer Workstations und Server erhöht. Und Red Hat kann die Red Hat Advanced Development Labs unterhalten, um den Wert seiner Linux- Angebote zu steigern und mehr Kunden anzulocken.
Für Strategen aus traditionellen Sektoren der Software-Industrie, die
Patente oder Geschäftsgeheimnisse als die Kronjuwelen ihrer Firmen ansehen,
mag dieses Verhalten (trotz der erwirkten Erweiterung des Marktes)
rätselhaft sein. Warum soll man Forschung und Entwicklung finanzieren,
die dann ex definitione
jedem Mitbewerber gratis verwendet werden kann?
Es gibt hier augenscheinlich zwei steuernde Ursachen. Die eine ist, dass, solange diese Firmen dominierende Spieler in ihren jeweiligen Märkten sind, sie erwarten können, einen gerechten Anteil am Markt zu gewinnen, der zum Anteil an ihren Aufwendungen für Forschung und Entwicklung proportional ist. Und Forschung und Entwicklung für den Erwerb zukünftiger Profite zu verwenden, ist sicher keine neue Idee. Neu ist aber der Gedanke, dass die zukünftigen Gewinne groß genug sind, um Trittbrettfahrer tolerieren zu können.
Während diese offensichtliche Analyse des erwarteten Werts
für die Welt bodenständiger Investoren notwendig ist, kann sie nicht
erklären, warum ausgerechnet die Stars angeheuert werden. Die betreffenden
Firmen geben hier eine andere, weniger klar umrissene Erklärung. Wenn
man sie danach fragt, geben sie an, dass es nach den Maßstäben
der Gemeinde einfach das naheliegendste und fairste ist. Der Autor selbst
ist mit den führenden Entwicklern in allen drei zitierten Firmen ausreichend
bekannt und kann bestätigen, dass dies nicht einfach als Humbug abgetan
werden kann. Tatsächlich wurde ich Ende 1998 persönlich in den
Vorstand
VA Linux Systems eingeladen, so dass ich verfügbar wäre,
um sie darüber zu beraten, was denn das "naheliegendste und fairste"
wäre, und meine Ratschläge wurden auch ernst genommen.
Ein Betriebswirt hat das Recht zu fragen, welche Rentabilitäten es hier gibt. Wenn wir akzeptieren, dass der Hinweis auf Fairness keine leere Pose ist, dann sollte unsere nächste Frage lauten, welchem Eigennutz der Firmen diese Fairness dient. Die Antwort ist weder überraschend noch schwer zu beweisen, wenn man die Frage richtig stellt. Wie bei anderem augenscheinlich altruistischem Verhalten in anderen Industrien wird hier einfach Sympathie (Good Will) eingekauft.
Für diesen "guten Willen" etwas zu leisten und ihn als Guthaben zu sehen, das zukünftiges Wachstum des Marktanteils fördert, ist ebenfalls kaum eine neue Idee. Interessant ist aber, dass ihn die zitierten Firmen extrem hoch bewerten. Offensichtlich sind sie bereit, teure Talente für Projekte einzustellen, die keine unmittelbaren Gewinne abwerfen, und das während der kapitalhungrigsten Phase - ihres Börsenganges. Bisher wenigstens hat der Markt dieses Verhalten tatsächlich belohnt.
Die Manager dieser Firmen selbst sind sich über die Gründe und
den Wert
Good Will voll im Klaren. Sie verlassen sich auf die Freiwilligen
unter ihren Kunden, sowohl bei der Weiterentwicklung der Produkte als auch
beim informellen Marketing. Diese Beziehung mit ihren Kunden ist eine sehr
innige und basiert oft auf persönlichem Vertrauen zwischen Individuen
innerhalb und außerhalb der Firma.
Diese Beobachtungen bestätigen die Einsichten, die wir schon vorher
durch eine andere Linie unserer Überlegungen erhalten haben. Die Beziehung
zwischen Red Hat/VA/O'Reilly und ihren Kunden und Entwicklern ist nicht eine
für Güter produzierende Firma typische. Stattdessen zeigt sie ein
interessantes Extrem einer Charakteristik, wie wir sie
Wissens-intensiven
Dienstleistungsindustrien gewohnt sind. Außerhalb der Technologiewirtschaft
können wir diese Muster beispielsweise bei Anwaltskanzleien, Arztpraktiken
oder Universitäten beobachten.
Tatsächlich können wir sehen, dass Open Source-Firmen Hackerstars aus genau den selben Gründen beschäftigen, aus dem Universitäten Star-Akademiker anheuern.
In beiden Fällen ist die Praktik der einer aristokratischen Patronage ähnlich, die den größten Teil der schönen Künste bis kurz nach der industriellen Revolution unterhalten hat - eine Ähnlichkeit, der sich manche Beobachter durchaus bewusst sind.
14. Wie geht es weiter?
Die Marktmechanismen für die Finanzierung (und Amortisation!)
Open Source-Projekten entwickelt sich noch immer sehr rasch weiter. Die
Geschäftsmodelle, die wir hier untersuchen, werden wahrscheinlich nicht das letzte
Wort zu diesem Thema sein. Investoren sind gerade noch dabei, über die
Konsequenzen einer Neuerfindung des Softwaregeschäfts nachzudenken und
konzentrieren jetzt sich dabei auf die Services anstatt auf das weggesperrte
geistige Eigentum. Das wird sich für die absehbare nächste Zeit
auch nicht ändern.
Diese Revolution bei den Konzepten wird einige Kosten für jene Leute
verursachen, die im Augenblick in den Warenwert der betreffenden 5 Prozent
der Softwareindustrie investieren. Historisch betrachtet, ist der
Dienstleistungssektor nicht so lukrativ wie die Herstellung
Gütern
(obwohl ihnen jeder Arzt oder Anwalt bestätigen kann, dass die
Ausübenden oft höhere Spannen haben). Versäumte Gewinne aber
werden durch den Nutzen auf der Kostenseite mehr als wettgemacht werden -
die Konsumenten kommen in den Genuss gewaltiger Kosteneffektivität bei
Open Source-Produkten (es gibt hier übrigens eine Parallele: der Ersatz
des traditionellen Telefonnetzwerks durch das Internet).
Die Aussicht auf diese Kosteneffektivität erzeugt eine Chance, auf deren Nutzung sich Unternehmer und Venture-Kapitalisten gerade vorbereiten. Als der erste Entwurf dieses Dokuments in Arbeit war, sicherte sich Silicon Valleys prestigeträchtigste Venture Capital-Firma den Hauptanteil am ersten Startup-Unternehmen, das auf technische Unterstützung der Linux-Plattform spezialisiert ist. Die allgemeine Erwartung ist, dass es noch vor Ende 1999 mehrere Linux- und Open Source-basierte Börsengänge geben wird - und dass sie alle ganz erfolgreich sein werden.
Eine andere sehr interessante Entwicklung ist der Beginn
systematischen
Versuchen,
Task
Markets bei Open Source-Projekten zu finden.
SourceXchange
und CoSource sind zwei
einander leicht verschiedene Wege, das Modell einer umgekehrten Auktion
zur Finanzierung
Open Source-Projekten anzuwenden.
Die übergeordneten Trends sind klar erkennbar. Wir haben IDCs Hochrechnung
schon erwähnt, die angibt, dass Linux bis 2003 schneller wachsen wird
als alle anderen Betriebssysteme zusammen. Apache liegt bei 61 Prozent
Marktanteil und expandiert ununterbrochen weiter. Die Verbreitung des Internets
explodiert, und Erhebungen wie der Internet Operating System Counter zeigen,
dass Linux und andere Open Source- Betriebssysteme bei Internet-Servern bereits
in Führung liegen und ständig gegenüber Closed Source-Systemen
gewinnen. Der Druck zur Nutzung
Open Source-Internet-Infrastruktur wirkt
sich zunehmend nicht nur auf das Design anderer Software aus, sondern auch
auf Geschäftspraktiken und Kaufverhalten bei Software. Diese Trends
scheinen sich noch weiter zu beschleunigen.
15. Schluss: das Leben nach der Revolution
Wie wird die Welt der Software aussehen, wenn der Übergang zu Open Source erst abgeschlossen ist?
Um diese Frage zu untersuchen, ist es hilfreich, Software im Allgemeinen zunächst einmal nach dem Grad der Vollständigkeit einzuteilen, in dem ihre jeweils angebotenen Services nach offenen technischen Standards beschrieben werden können. Dieser Grad der Vollständigkeit steht in engem Zusammenhang damit, wie sehr diese Services "commoditized" sind, d.h. wie in welchem Maß es sich um ganz grundlegende Dienste handelt, deren Implementation allgemein zugänglich ist und gut auf sehr viele Programmierer aufgeteilt werden kann.
Diese Achse entspricht auch sehr genau den üblichen Vorstellungen
"Applikationen" (die im Augenblick überhaupt nicht "commoditized" im
Sinne
"offen" und "standardisiert" sind), "Infrastruktur" (grundlegende
Dienste, verbindliche und verbreitete Standards), und "Middleware" (teilweise
commoditized, effektive, aber unvollständige Standards). Die einzelnen
Paradigmata dafür wären heute (1999): Textprozessor (als typischstes
Beispiel für eine Applikation), TCP/IP-stack (als typischstes Beispiel
für technische Infrastruktur) und Datenbankmaschine (als typischstes
Beispiel für Middleware).
Die weiter oben durchgeführte Rentabilitätsanalyse legt nahe, dass
Infrastruktur, Applikationen und Middleware auf verschiedene Art transformiert
werden können und jeweils eine unterschiedliche ideale Balance an Open
Source und Closed Source haben. Wir erinnern daran, dass unsere Erkenntnis
auch darin besteht, dass der Grad an Offenheit des Quellcodes in einem bestimmten
Softwarebereich da
abhängt, wie stark die wirkenden Netzwerkeffekte
sind, wie hoch die Kosten eines Ausfalls sind und in welchem Maße das
Unternehmen
Software abhängig ist.
Nun können wir einige Vorhersagen wagen, vorausgesetzt, dass wir diese
Erkenntnisse nicht auf individuelle Produkte, sondern auf ganze Segmente
des Software-Marktes anwenden:
Infrastruktur (Internet, World Wide Web, Betriebssysteme und die unteren
Schichten
Kommunikationssoftware, die keine Überschneidungen mit
konkurrierenden Herstellern haben) wird fast vollständig Open Source
sein,
Benutzerkonsortien gepflegt werden und
gewinnorientierten
Dienstleistungsunternehmen (wie heute beispielsweise Red Hat) vertrieben
und betreut werden.
Applikationen, auf der anderen Seite, haben die höchste Tendenz, weiterhin
nicht-öffentlich entwickelt zu werden. Unter Umständen, unter denen
der Gebrauchswert
nicht-öffentlichen Algorithmen oder Technologien
hoch genug ist (und die Kosten für mangelnde Ausfallsicherheit gering
und das Risiko eines Herstellermonopols tolerierbar sind) werden die Konsumenten
weiterhin für geschlossene Software bezahlen. Das gilt besonders für
in sich abgeschlossene, vertikale Anwendungen, bei denen Netzwerkeffekte
nur schwach ausgeprägt sind.
Unser früheres Beispiel vom Verschnittoptimierer für Sägewerke
ist eine solche Anwendung; biometrische Identifikation sieht aus der Perspektive
1999 nach einer weiteren aus.
Middleware (Datenbanken, Entwicklungswerkzeuge oder die Anwendungsschichten
Protokoll-Architekturen) werden nicht so einheitlich abgegrenzt sein.
Ob Kategorien für Middleware offener oder geschlossener sind, hängt
den Kosten für Ausfälle ab, was Marktdruck in Richtung mehr
Offenheit erzeugt.
Um das Bild zu vervollständigen müssen wir aber beachten, dass
weder "Applikationen" noch "Middleware" tatsächlich stabile Kategorien
sind. In "Wann man seinen Quellcode aus dem Tresor holen sollte" haben wir
gesehen, dass bestimmte Softwarekategorien einen eigenen Lebenszyklus zu
haben scheinen, der
"natürlich geschlossen" zu "natürlich offen"
geht. Die selbe Logik gilt auch für das Gesamtbild.
Applikationen rücken nach und nach auf das Feld der Middleware, wenn
sich Standards entwickeln und Teile der Dienste zu grundlegenden Aspekten
(also einer "Commodity") werden. Datenbanken, zum Beispiel, wurden Middleware,
nachdem SQL die Frontends
der Datenbankmaschine entkoppelte. Wenn
Middleware-Services eine Commodity werden, geht der Trend mehr und mehr in
Richtung Open Source - was wir bei Betriebssystemen gerade beobachten
können.
Für eine Zukunft, die Konkurrenz durch Open Source beinhaltet, können wir daher erwarten, dass das letztendliche Schicksal jeder Software sein wird, entweder zu sterben oder Teil der Infrastruktur zu werden. Während das kaum gute Nachrichten für die Unternehmer sind, die am liebsten eine ewige Leibrente für eingekapselte Software erhalten würden, zeigt es doch, dass die Software-Industrie im Ganzen gewinnorientiert bleiben; wird, was immer neue Nischen am oberen (d.h. Applikations-) Ende erzeugt und Herstellern nur so lange Monopole gewährleistet, wie ihre Produkte noch nicht Teil der Infrastruktur sind.
Schließlich wird es natürlich so sein, dass dieses Gleichgewicht
für den Konsumenten
Software nur Vorteile hat. Mehr und mehr qualitativ
hochwertige Software wird permanent verfügbar und beliebig anzupassen
sein, statt irgendwann einmal eingestellt oder in irgendeinem Tresor weggesperrt
zu bleiben. Ceridwens verzauberter Kessel ist dafür eigentlich ein zu
schwaches Gleichnis - denn während Essbares verzehrt oder schlecht wird,
hat Quellcode das Potential für ewiges Leben. Der freie Markt, im weitesten
Sinne jeglicher freiwilligen Aktivität am Markt, der ja zwischen Handel
und Verschenken keinen Unterschied macht, kann unentwegt steigenden Wohlstand
an Software hervorbringen, und das für uns
alle.
16. Bibliographie und Danksagung
[CatB] "Die Kathedrale und der
Bazar"
[HtN]
"Homesteading the Noosphere"
[DL] De Marco and Lister, Peopleware: Productive Projects and Teams (New
York; Dorset House, 1987; ISBN
0-932633-05-6)
[SH] Shawn Hargreaves hat eine gute Analyse der Anwendbarkeit
Open
Source-Methoden auf Computerspiele verfasst;
Playing
the Open Source Game
Einige stimulierende Diskussionen mit David D. Friedman haben mir geholfen,
das Modell der "am Kopf stehenden Kommune" der Open Source-Kooperation zu
verfeinern. Ich stehe auch in der Schuld
Marshall van Alstyne, der auf
die konzeptionelle Wichtigkeit
rivalisierenden Informationsgütern
hingewiesen hat. Ray Ontko
der Indiana Group steuerte wertvolle Kritik
bei. Erfreulich viele Leute im Publikum meiner Vorträge in der ersten
Jahreshälfte 1999 haben auch einiges beigetragen; wenn Sie einer
ihnen sind, wissen Sie es.
Auch ist es ein weiteres Zeugnis für den Wert des Open
Source- Modells, dass dieses Dokument durch Rückmeldungen per e-mail viel
gewonnen hat, die ich innerhalb
wenigen Tagen nach der
Veröffentlichung erhielt. Lloyd Wood wies auf die Wichtigkeit hin, dass
Open Source-Software "zukunftssicher" ist. Doug Dante erinnerte mich an das "Free
the Future"-Geschäftsmodell. Eine Frage
Adam Moorhouse führte zu der Diskussion
der Vorzüge des Ausschlusses der Öffentlichkeit. Lionel Oliviera
Gresse verhalf mir zu einem besseren Namen für eines der Geschäftsmodelle. Stephen
Turnbull reizte mich wegen der zu oberflächlichen Behandlung der
Trittbrettfahrereffekte bis zum Wahnsinn.
17. Anhang: Warum Hersteller durch Ausschluss der Öffentlichkeit verlieren
Hersteller
Peripheriegeräten
(Ethernet-Karten, Plattencontrollern, Videokarten und ähnlichem) sind traditionellerweise
sehr zögerlich beim Öffnen ihrer Software. Das ändert sich aber
gerade; Firmen wie Adaptec und Cyclades haben begonnen, die Spezifikationen
und den Treiberquellcode für ihre Karten zu veröffentlichen. Trotzdem gibt es noch
Widerstand. In diesem Anhang versuchen wir, einige der wirtschaftlichen
Irrtümer darzulegen, die ihn hervorrufen und fördern.
Als Hardwarehersteller fürchtet man vielleicht, dass eine
Veröffentlichung des Quellcodes wichtige Details über die eigene
Hardware enthüllen könnte, die dann
Mitbewerbern plagiiert
werden und ihnen so einen unfairen Wettbewerbsvorteil verschaffen. Früher,
in den Tagen der drei bis fünf Jahre dauernden Produktzyklen, war das
ein gültiger Einwand. Heute aber wäre die Zeit, die Ingenieure
der Konkurrenz für ein solches Ausbaldowern aufbringen müssten,
ein so großer Anteil an der Lebensdauer des Produkts, den sie dann
nicht für eigene innovative und vorteilhafte Entwicklungen verwenden
könnten. Zu plagiieren wäre ein so großer Fehler Ihres
Mitbewerbers, dass Sie sich gar nichts besseres wünschen können.
Auf jeden Fall ist es so, dass technische Details heute nicht lange verborgen bleiben. Gerätetreiber sind nicht wie Betriebssysteme oder Anwendungen. Sie sind klein, leicht zu disassemblieren und leicht zu clonen. Sogar Anfänger im Teenager-Alter können das - und tun es oft auch.
Es gibt buchstäblich tausende
Linux- und
FreeBSD- Programmierern, die sowohl die Fähigkeit als auch die Motivation
haben, Gerätetreiber für eine neue Karte zu schreiben. Für viele Klassen
Geräten, die eine relativ simple Schnittstelle haben und
wohlbekannten Standards entsprechen (wie Plattencontroller und Netzwerkkarten) können diese
fleißigen Hacker Treiberprototypen so rasch erzeugen wie Ihre eigene
Entwicklungsabteilung; sie brauchen nicht einmal Dokumentation oder einen
schon bestehenden Treiber.
Sogar für kniffelige Geräte wie Videokarten gibt es nicht viel, was Sie gegen einen cleveren Programmierer tun können, der über einen Disassembler verfügt. Die Kosten sind gering und der gesetzliche Schutz porös - Linux ist eine internationale Angelegenheit, und es gibt immer einen Ort auf der Welt, in dem so ein Abkupfern legal ist.
Für den überzeugenden Beweis, dass diese Behauptungen wahr
sind, untersuchen Sie die Liste
Geräten, die vom Linuxkernel
unterstützt werden oder sehen Sie sich die Treiber-Unterverzeichnisse auf Websites wie
Metalab;
an. Beachten Sie auch die Rate, mit der neue hinzukommen.
Was lernen wir daraus? Die Details der Implementation Ihres Treibers geheimzuhalten sieht augenscheinlich attraktiv aus, ist aber wahrscheinlich eine kurzsichtige Strategie (sicher gilt das, wenn Ihre Mitbewerber ihren Quellcode bereits veröffentlicht haben). Wenn Sie sich aber schon bedeckt halten müssen, brennen Sie den Code in ein ROM auf der Karte und veröffentlichen Sie die Schnittstellen. Öffnen Sie den Zugang zu den Details so weit wie möglich und zeigen Sie potentiellen Kunden, dass Sie an Ihre Fähigkeit glauben, die Konkurrenz dort zu übertreffen, wo es darauf ankommt: bei Ideen und Innovation.
Wenn Sie sich ganz bedeckt halten, bekommen Sie die schlechteste aller Welten
- Ihre Geheimnisse werden schließlich ergründet werden,
Gratis-Entwicklungen werden an Ihnen vorbeigegangen sein und Sie werden nicht
in den Genuss kommen, dass dümmere Mitbewerber versuchen, Ihr Produkt
zu clonen. Am wichtigsten aber ist, dass Sie die Auffahrt zu weiter Verbreitung
durch frühe Akzeptanz des Marktes verpassen. Ein großer und
einflussreicher Markt (bestehend aus den Betreibern jener Server, die das
Internet in Schwung halten und mehr als 17 Prozent aller Rechenzentren im
geschäftlichen Bereich) wird Ihre Firma richtigerweise als ahnungslos
und übervorsichtig abschreiben, da Sie diese Fakten nicht erkennen.
Dann werden sie ihre Karten
jemanden kaufen, der klüger
ist.
18. Versionsgeschichte
Diese Übersetzung basiert auf der Version 1.14
Versionen, die hier nicht aufscheinen, sind geringfügige Korrekturen
Tippfehlern.
20. Mai 1999, Version 1.1 -- Entwurf
18. Juni 1999, Version 1.2 -- erste private Version zur Kritik "im kleinen
Kreis"
24. Juni 1999 Version 1.5 -- erste Veröffentlichung
24. Juni 1999 Version 1.6 -- geringfügiges Update, Definition des Begriffs
'Hacker'
24. Juni 1999 Version 1.7 -- geringfügiges Update, Klarstellung des
Kriteriums (e).
24. Juni 1999 Version 1.9 -- "Zukunftssicherheit", "Zukunft verschenken"-Modell
und ein neuer Abschnitt über die Vorteile des Ausschlusses der
Öffentlichkeit
24. Juni 1999 Version 1.10 -- besserer Name für das
"Rasierklingenmodell"
25. Juni 1999 Version 1.13 -- Korrektur der 13%-Behauptung über Netscapes
Erträge; verbesserte Behandlung der "Trittbrettfahrereffekte" Korrektur
der Liste der geschlossenen Protokolle.
25. Juni 1999 Version 1.14 -- Hinzufügen
e-smith, inc.
9. Jul 1999, Version 1.15 --- neuer Anhang über Hardware-
Gerätetreiber und eine bessere Erklärung rivalisierender Güter
nach Rich Morin.