4Bibeln: Freie Software

The magic Cauldron | Der verzauberte Kessel


Eric S. Raymond/Juni 1999
aus dem Amerikanischen
von Reinhard Gantar
mit marginaler Überarbeitung von Peter Handrich
(das Original können Sie hier lesen)

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

inhalt

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?

inhalt

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).

inhalt

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.

inhalt

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.

inhalt

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?

inhalt

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").

inhalt

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.

inhalt

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.

inhalt

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).

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

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.

inhalt

freiesofteware