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. 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" untersucht die soziale Dynamik innerhalb derer dieser "bazar-orientierte" Stil beim Entwickeln zu Hause ist; mit der These als Anliegen, daß 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 mißt. In diesem Dokument werden wir unsere Erörterung damit beginnen, daß wir einigen weit verbreiteten Mythen über die Ökonomie der Softwareentwicklung die Luft auslassen; dann mit der Analyse von [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, daß es zu dieser Freigiebigkeit in Situationen kommt, die alles Lebenswichtige in solchem Überfluß bieten, daß ein Austausch von 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 muß 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, daß sehr viele von 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, daß Closed- Source-Projekte von 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 von 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).

Wir müssen unsere Betrachtung mit der Bemerkung anfangen, daß Computerprogramme, so wie alle anderen Werkzeuge oder Investionsgüter, zwei klar erkennbare Arten von 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 von 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 von 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, daß 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, daß 90 Prozent allen Codes für die eigene Verwendung von 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, daß es empirische Beweise dafür gibt, daß 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 von Finanz- und Datenbanksoftware, die jede mittlere und große Firma braucht. Er beinhaltet die Arbeit von 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 von "Firmware", wie er in zunehmend mikrocomputerisierten Maschinen eingebettet ist - von 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, daß die Wiederverwendung oder die Vervielfältigung sehr schwierig ist. Diese Einschränkung besteht unabhängig davon, ob es sich bei dieser Umgebung um einen Satz von Geschäftsprozeduren innerhalb eines Unternhemens 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, daß sie den überwiegenden Anteil an den Kosten (mehr als 75 Prozent) verursacht. Die Folge davon ist, daß Programmierer die meiste Zeit mit dem Verfassen oder der Wartung von Code verwenden, der überhaupt keinen Warenwert hat - eine Tatsache, von der sich der Leser jederzeit selbst überzeugen kann; man muß nur die entsprechenden Stelleninserate einer beliebigen Tageszeitung betrachten.

Sich den Arbeitsmarkt im Anzeigenteil einer regionalen Zeitung näher anzusehen ist ein lehrreiches Experiment, daß ich jedem Leser ans Herz legen will. Untersuchen Sie die Angebote für Programmierer, Software-Engineering und Unternehmens-EDV nach Positionen, die Entwicklung von 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, daß, sogar nach der am weitesten gefaßten Definition von "für den Verkauf", wenigstens neunzehn von zwanzig der gebotenen Gehälter durch den Gebrauchswert (also für ein Investitionsgut) bezahlt werden. Das ist der Grund für unsere Annahme, daß nur 5 Prozent der Industrie durch den direkten Ertrag aus dem Verkauf der Software bezahlt wird. Beachten Sie aber, daß 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 von Software bezahlt, und wie viele davon arbeiten an Software, die für den Weiterverkauf bestimmt ist. Fast immer ist es so, daß ich auf die erste Frage einen ganzen Wald von 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, daß der Warenwert von 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 - Verfielfä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 aufschlußreich. Es zeigt, daß 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, daß 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, daß einige der sichtbarsten und am massivsten beworbenen dieser Artikel Computerspiele sind, die ja so gut wie keine laufende Dienstleistung benötigen. (Ausnahmen von dieser Regel gibt es, sie sind aber selten) [SH].

Man sollte auch beachten, daß 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), daß über 75 Prozent der Kosten für die gesamte Lebensdauer eines Softwareprojekts auf die Wartung, die Fehlerbehebung und die Erweiterung entfallen, kommt man dahinter, daß 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 von Software eigentlich eine Dienstleistungsindustrie ist, verleiten die Anreize eines Fabrikmodells nicht zum Anbieten von kompetenten Services. Solange die Einnahmen des Herstellers durch den Verkauf von 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 von Kunden zu verprellen.

Die andere Seite dieser Medaille ist, daß 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, daß man seine heutigen Kunden durch die Geschäfte von 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, daß 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 davon betroffen, die Beispiele reichen von proprieritä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 von "Gratis"software, so scheint es, ist, uns in eine Welt zu bewegen, in der die Vergebührung von Dienstleistungen dominiert - und auf die Strukturschwäche hinzuweisen, die eine Kompensation von Entwicklungskosten durch Verkauf von 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.

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, daß marginale Kosten bei der Vervielfältigung von Software Verkaufspreis von null zu bedeuten hat - "Information wants to be free".

In seiner allgemeinster Form kann man diesen Mythos leicht entschärfen. Nehmen wir einmal den Wert von Information, die den leichten Erwerb eines attraktiven Guts bedeutet - eine Schatzkarte etwa, oder die Nummer eines Schweizer Bankkontos. Obwohl diese Information für Kosten von null vervielfältigt werden kann, gilt das für das zugehörige Gut nicht. Daher kann man von den Verfielfältigungskosten nichts über den eigentlichen Wert ableiten.

Wir bringen diesen Mythos hauptsächlich deswegen ins Spiel, um festzustellen, daß er für die Kosten/Nutzen-Rechnung bei Open Source unerheblich ist; später werden wir sehen, daß nicht einmal die Annahme, er wäre stichhaltig (der Wert der Ware Software ist null) Auswirkungen für unser Modell hat.

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 von 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 von 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, daß Ü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, daß die Bauern sich zerstreiten werden, daß 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, daß das genaue Gegenteil der Fall ist. Umfang und Tiefe von 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, daß 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 von Leuten erkennt, daß dieser Fix für sie einen gewissen Geldwert hat. Wie hebe ich eine Gebühr von diesen Leuten ein? Konventionelle Zahlungssysteme haben so hohe Unkosten, daß er für die hier angebrachten Kleinstbeträge zu einem echten Problem wird.

Noch treffender könte die Beobachtung sein, daß dieser Wert nicht nur schwer einzutreiben, sondern oft sogar schwer zu bestimmen ist. Lassen Sie uns ein Gedankenexperiment machen. Nehmen wir, daß 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 von F. A. Hayeks "Kalkulationsproblem" - der Handel mit dem korregierten 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 Spieltheoretikern zu sagen.

Bei der Analyse einer derartigen Kooperation ist es wichtig, daß trotz der vorhandenden "Trittbrettfahrer"-Problematik (wegen fehlender finanzieller oder äquivalenter Anreize mangelt es an Beiträgen an Entwicklungsarbeit) diese Problematik von 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 Entwicklern; 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 ehö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 von 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üßte 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 von) Projekten stark und invers mit der Anzahl der Hürden, die man als Codespender überwinden muß. 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 von 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 Business Models erzeugen Nischen, in denen Open Source-Entwicklungen gedeihen können?

Bevor wir uns an eine Taxonomie von Open Source-Business Models wagen können, sollten wir uns mit den finanziellen Vorteilen von Closed Source befassen. Was genau wird durch Geheimhaltung von 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 Ausschluß 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, daß Mitbewerber diese Software auch verwenden.

Die offensichtliche Antwort ist also, daß 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 Ausschluß 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 von der Gemeinde seiner Benutzer vorgenommen werden. Dann beginnnen auch Ihre Mitbewerber, es zu verwenden - und geniessen 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ätzugen, weil sie a) das Mehr an Funktionalität durch mehr Entwickler ignorieren, und b) sie nicht sehen, daß 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 Ausschluß der Öffentlichkeit, die aber alle schlichtweg irrational sind. Sie könnten beispielsweise unter dem falschen Eindruck stehen, daß geheimgehaltener Quellcode Ihr Firmensystem sicherer gegen das Ausspähen von 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 von Zuverlässigkeit, und nur Algorithmen und Implementationen kann getraut werden, die von Kollegen in der Gemeinde gründlich geprüft wurden (merken Sie sich den Fachausdruck für diese Prüfung durch Kollegen: "Peer Review").

Ein Vorzug der Schlüsselerkenntnis, daß man unter Warenwert und Gebrauchswert genau unterscheiden muß, ist die Beobachtung, daß durch Veröffentlichung des Quellcodes nur der Warenwert bedroht ist, nicht der Gebrauchswert.

Wenn dieser Gebrauchswert und nicht der Warenwert als tatsächliche treibende Kraft hinter einem Softwareprojekt steht, und (wie das die These in [CatB] ist) Open Source-Entwicklung wirklich effektiver und effizienter als die Closed Source-Methode ist, dann sollten wir Umstände erwarten können, in denen der Gebrauchswert alleine Open Source-Projekte nachhaltig in Schwung hält.

Tatsächlich ist es nicht schwierig, wenigstens zwei wichtige Modelle zu identifizieren, bei denen volle Entwikcklergehäter ausschließlich durch den Gebrauchswert amortisiert werden.

Nehmen wir an, Sie arbeiten für eine Firma, deren Geschäft von einem extrem zuverlässigen Hochleistungs-Webserver abhängt. Vielleicht wickelt er e-Commerce ab, vielleicht handelt es sich um einen berühmten Medienkonzern, der Werbung verkauft, vielleicht ist die Firma ein Web-Portal. Der Server jedenfalls muß ununterbrochen fehlerfrei laufen. Gleichzeitig brauchen Sie Leistung und Flexibilität.

Wie können Sie diese Sehnsüchte erfüllen? Im Grunde gibt es drei Strategien, die Sie verfolgen können:

Kaufen Sie einen proprieritären Webserver. In diesem Fall verwetten Sie Ihre Nerven darauf, daß der Hersteller mit Ihnen bei Zielsetzungen und Zukunftsplänen an einem Strang zieht und darauf, daß der Hersteller die erforderliche technische Kompetenz hat, um den Server befriedigend zu implementieren. Sogar unter der Annahme, daß beide Voraussetzungen erfüllt sind, wird das Produkt wahrscheinlich nicht beliebig anzupassen sein. Sie können nur an den Stellen einhaken, die der Hersteller für Anpassungen vorgesehen hat. Diese Strategie eines proprietären Webservers ist nicht gerade beliebt.

Bauen Sie Ihren eigenen Webserver. Die Entwicklung eines eigenen Webservers ist eine Möglichkeit, die man nicht augenblicklich verwerfen sollte. So ein Server ist nicht besonders komplex und sicherlich leichter zu implementieren als ein Browser. Ein spezialisierter Webserver kann sehr leistungsfähig und sehr schlank sein. Bei dieser Strategie bekommen Sie ganz genau jene Leistungsmerkmale, die Sie wollen und auch die Möglichkeit zu beliebigen Anpassungen. Der Preis dafür sind die Kosten für die Entwicklungsarbeit. Ihre Firma könnte auch zu dem Schluß kommen, daß sie ein gewaltiges Problem hat, sobald Sie kündigen oder in Pension gehen.

Treten Sie der Apache Group bei. Der Server Apache wurde von einer durch das Internet verbundene Gruppe von Webmastern geschaffen, die erkannten, daß es klüger ist, ihre jeweiligen Aufwendungen für die Erweiterung und Verbesserung eines einzigen Codepools zu teilen, um eine große Zahl von parallel laufenden Entwicklungen zu betreiben. Dadurch kamen sie in den Genuß der Flexibilität eines selbstgebauten Servers und des gewaltigen Debugging-Muskels massiv-paralleler Peer Review.

Der Vorteil einer Entscheidung für Apache ist sehr groß. Wie groß, kann man erkennen, wenn man sich die monatliche Erhebung von Netcraft ansieht. Sie zeigt, daß Apache seit seiner ersten Freigabe gegenüber allen anderen proprieritären Webservern mehr und mehr Marktanteil gewonnen hat. Im Juni 1999 hielt man bei 61 Prozent Marktanteil; - und das ohne einen Eigentümer, ohne Werbung und ohne Verträge mit betreuenden Dienstleistungsunternehmen.

Die Geschichte hinter Apache läßt sich in einem Modell verallgemeinern, bei dem die Benutzer von Software in der gemeinnützigen Open Source-Entwicklung Vorteile sehen, da Open Source ihnen ein Produkt beschert, das besser ist als jedes, das sie auf anderem Weg erhalten können und darüber hinaus auch noch kostengünstiger ist.

Vor einigen Jahren bekamen zwei Programmierer bei Cisco (dem Hersteller für Netzwerkausstattung) die Aufgabe, ein verteiltes Print-Spoolingsystem zu schreiben, das dann in Ciscos Firmennetzwerk verwendet werden sollte. Das war keine geringe Herausforderung. Neben der Möglichkeit, einen beliebigen Benutzer A zu einem beliebigen Drucker B (der im nächsten Zimmer oder tausend Kilometer entfernt sein kann) drucken zu lassen, sollte das System sicherstellen, daß im Falle eines Papierstaus oder einer leeren Tonerkassette der Druckjob zu einem anderen nahe gelegenen Drucker umgeleitet wird. Das System mußte auch in der Lage sein, solche Probleme an den Druckeradministrator weiterzuleiten.

Das Duo entwickelte einen Satz von cleveren Modifikationen des unter Unix standardisierten Druckerspoolers und ergänzte einige Scripts, was zur Erfüllung der Aufgabe ausreichte. Dann erkannten sie, daß sie (und Cisco) ein Problem hatten.

Das Problem war, daß weder der eine noch der andere ewig bei Cisco bleiben würde. Irgendwann würden wahrscheinlich beide Programmierer nicht mehr da sein und die Software würde dann ungewartet herumliegen und langsam verrotten (d.h. nach und nach mit den tatsächlichen Gegebenheiten bei Cisco außer Tritt geraten). Kein Entwickler sieht so etwas gerne, wenn es um die eigenen Werke geht. Unser Duo stand unter dem gerechtfertigten Eindruck, daß Cisco für eine Lösung bezahlt hatte, die es bei Cisco wahrscheinlich länger geben würde als ihre Schöpfer.

Folglich gingen sie zu ihrem Chef und drängten ihn, die Freigabe der Printspooler-Software als Open Source zu genehmigen. Ihr Argument war, daß Cisco keinen Verlust von Warenwert zu fürchten hätte. Durch Förderung einer Benutzergemeinde und Mitentwicklern in vielen großen Firmen konnte Cisco dem Schaden durch Verlust der ursprünglichen Entwickler vorbeugen.

Die Geschichte hinter dem Cisco-Druckerspooler läßt sich in einem Modell verallgemeinern, bei dem die Open Source-Methode nicht so sehr die Funktion hat, Kosten zu senken, sondern Risiko zu zerstreuen. Alle Teilnehmer anerkennen dabei, daß die Präsenz einer aktiven Entwicklergemeinde, die durch mehrere unabhängige Einkommensströme finanziert wird, mehr Sicherheit bietet. Diese Sicherheit hat selbst einen wirtschaftlichen Wert, der hoch genug, um Anreize für den Unterhalt eines solchen Projekts zu schaffen.

Open Source macht die Vergebührung des direkten Warenwerts von 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ären 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 von 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, daß die meisten Hacker gerne mit der Geschäftswelt zusammenzuarbeiten, wenn es ihnen nützt. Der wahre Grund, aus dem Hacker direkte Erträge aus dem Verkauf von 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 von ihren Spenden profitieren, verlangen die meisten, daß niemand in einer privilegierten Position sein darf, zu Profiten zu kommen. Otto Normalhacker ist einverstanden, daß 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, daß Lizenzen Einschräkungen 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 hat. 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 Risken.

Diese Wirkung wird zu Recht als schädlich angesehen, und es gibt daher einen starken sozialen Druck in Richtung simple gehaltener Lizenzen, die frei von 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, daß 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 Einfluß 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 davon abgeleitete Produkte zu verwenden, darunter eine Closed Source-Version). Sie hat weniger Einfluß 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 von 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.

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

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 von 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 Vermaktung 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, daß 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öfentlichung des Quellcodes für ihren noch immer sehr beliebten Browser versperrte Netscape Microsoft praktisch die Möglichkeit, sich ein Monopol zu schaffen. Sie erwartete, daß die Open Source-Kollaboration den Entwicklungs- und Korrekturprozeß ankurbeln würde und hofften, daß Microsofts IE beim Wettrennen um die Definition von 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, daß AOLs erste Verlautbarung war, das Mozilla-Projekt weiterhin zu unterstützen.

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 (von 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 von 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 von Einwänden, die Hersteller vorbringen, typischerweise in 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" von 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, daß 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.

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, daß es sich dabei um ein serienreifes Produkt handelt, das mit allen anderen Exemplaren vom selben Hersteller kompatibel ist. Weitere Elemente dieses Business Models sind etwa kostenloser Support für die Installation und Optionen auf Verträge für technische Betreuung.

Diese Markt-erzeugende Wirkung von Open Source kann sehr stark sein, besonders bei Firmen, die sich zwangsläufig ohnehin in einer Dienstleisterposition befinden. Ein sehr lehrreiches akuelles 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 von 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, daß 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, daß Digital Creations' eigentliche Substanz die Gehirne und die Talente seiner Leute ist. Die zweite Einsicht ist, daß Zope als markterzeugendes Produkt mehr Wert schaffen kann als wenn es von der Firma unter Verschluß gehalten wird.

Um das zu erkennen sollte man zwei Szenarios miteinander vergleichen. Im konventionellen Szenario bleibt Zope Digital Creations' Geheimwaffe. Unterstellen wir, daß das sehr gut funktioniert. Das Ergebnis wird sein, daß 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, daß die Veröffentlichung von Zope zur wichtigsten Reklame für Digital Creations tatsächliche Substanz werden könnte - ihre Mitarbeiter. Seine Erwartung war, daß die Kunden beim Erwägen von 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, daß die Open Source-Strategie "viele Türen geöffnet hat, die anderfalls 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".

Bei diesem Modell verkauft man Zubehör ("Accessories") für Open Source-Software. Am unteren Ende wären das Kaffeehäferl 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 von ihnen gewählten Markt zu festigen.

Bei diesem Modell veröffentlicht man nur die Binaries unter einer Closed License, die aber ein Ablaufdatum für den Ausschluß der Öffentlichkeit enthält. Die Lizenz sieht dann beispielsweise so aus, daß sie die freie Weitergabe gestattet, aber die kommerzielle Nutzung ohne Gebühr verbietet und garantiert, daß 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, daß das Produkt an ihre Bedürfnisse angepaßt werden kann, da sie den Quellcode bekommen werden. Das Produkt ist zukunftssicher , da es die Garantie gibt, daß 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 von den Schultern genommen.

Dieses Modell wurde von Alladin Enterprises für ihr Programm Ghostscript (ein PostScript-Interpreter für eine Reihe von Non- PostScript-Druckern) erfolgreich angewendet.

Der Hauptnachteil dieses Modells ist, daß der Ausschluß der Öffentlichkeit Peer Reiview und Anteilnahme in den Anfangsstadien des Produktzyklus unmöglich macht, also genau dann, wenn das am dringensten benötigt wird.

Dies ist ein spekulatives Business Model. Man veröffentlicht den Quellcode einer Softwaretechnologie, behält sich eine Test-Suite oder einen Reihe von Kompatibilitätskriterien vor und verkauft dann den Benutzern ein Gütesiegel, das einer bestimmten Implementation einer Technologie Kompatiblität mit allen anderen Trägern des Siegels attestiert.

(So sollte Sun Microsystems Java und Jini handhaben).

Dies ist ein weiteres spekulatives Business Model. Stellen Sie sich etwa einen Börsenticker-Service vor. Der Wert liegt weder in der Klientensoftware noch dem Server, sondern im Liefern von objektiver und stichhaltiger Information. Daher veröffentlicht man alle Software und verkauft Abonnaments 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).

Nach der Untersuchung der Business Models, die Open Source- Entwicklungen fördern, können wir uns an die allgemeine Frage wagen, wann es wirtschaftlich Sinn macht, seinen Quellcode zu veröffentlichen und wann nicht. Zunächst müssen wir uns aber darüber klar werden, was die jeweiligen Vorzüge der beiden Strategien sind.

Der Closed Source-Ansatz gestattet es Ihnen, Gebühren für eingekapslete Bits einzuheben; auf der anderen Seite schließt er die Möglichkeit wirklich unabhängiger Peer Review aus. Der Open Source-Ansatz schafft die Voraussetzungen für unabhängige Peer Review, schließt aber die Vergebührung eingekapselter Bits aus.

Der Gewinn aus dem Besitz unzugänglicher Bits ist leicht zu verstehen; traditionelle Software-Business Models sind darum herum aufgebaut. Bis vor kurzem war ein gutes Verständis des Gewinns aus Peer Review nicht so verbreitet. Das Betriebssystem Linux aber zeigt, was wir wahrscheinlich schon vor Jahren lernen hätten können, und zwar aus der Geschichte der Kernsoftware des Internet und anderen Ingenieursfakultäten - daß Peer Review die einzige in großem Stil anwendbare Methode ist, um hohe Qualität und Zuverlässigkeit zu erzielen.

Auf einem wettbewerbsorientierten Markt, auf dem Kunden hohe Qualität und Zuverlässigkeit suchen, werden daher jene Software- Produzenten belohnt werden, die ihren Quellcode veröffentlichen und herausfinden, wie sie durch Anbieten von Service, Value-Add und durch Zusatzmärkte Gewinne machen können. Dieses Phänomen ist es, daß hinter dem bemerkenswerten Erfolg von Linux steht, das 1996 aus dem Nichts auftauchte, Ende 1998 17 Prozent des Business Server-Marktes erobert hatte und voraussichtlich innerhalb der nächsten zwei Jahre zur dominierenden Plattform auf diesem Markt werden wird (Anfang 1999 prognostizierte IDC, daß Linux bis zum Jahr 2003 schneller wachsen wird als alle anderen Betriebssysteme zusammen).

Von fast ebenso großem Wert ist der Nutzen, den Open Source stiftet, wenn es um offene Standards und das Erzeugen von Märkten dafür geht. Das dramatische Wachstum des Internet verdankt sehr viel dem Umstand, daß TCP/IP niemandem gehört und niemand daher die Schlüsselprotokolle des Internet in einem proprietären Würgegriff hält.

Die Netzwerkeffekte hinter dem Erfolg von TCP/IP und Linux sind ziemlich klar und reduzieren sich letztlich auf Belange wie Vertrauen und Symmetrie - potentielle Nutzer einer gemeinsamen Infrastruktur können logischerweise mehr Zuversicht in ein System haben, von dem sie jedes Detail nachprüfen können und werden daher eine Infrastruktur bevorzugen, an der alle Parteien symmetrische Rechte haben. Daneben werden Systeme schnell unattraktiv, die eine einzelne Partei in eine privilegierte Position versetzen und die in der Folge Kontrolle ausübt oder Gebühren einhebt.

Es gibt aber keine zwingende Notwendigkeit, für die Wichtigkeit von Symmetrie für Software-Konsumenten Netzwerkeffekte vorauszusetzen. Kein Softwarekonsument wird sich aus rationalen Gründen dazu entschließen, sich in ein herstellerkontrolliertes Monopol einzusperren, wenn es irgendeine Open Source- Alternative von vergleichbarer Qualität gibt. Dieses Argument bekommt noch mehr Gewicht, wenn Software für das Geschäft des Konsumenten ein ausschlaggebender Faktor ist - um so wichtiger sie ist, um so weniger wird ein Konsument Kontrolle durch einen Außenstehenden tolerieren.

Schließlich ist Zukunftssicherheit ein weiterer wichtiger Vorzug von Open Source-Software und die steht in engem Zusammenhang mit Vertrauen. Wenn der Quellcode öffentlich ist, hat der Kunde wenigstens ein letztes Mittel für den Fall zur Hand, daß der Distributor bankrott geht. Das kann für das "Glasierungsmodell" besonders wichtig werden, da Hardware zu sehr kurzen Lebenszyklen tendiert, der Effekt ist aber allgemein anwendbar und ergibt automatisch einen zunehmenden Wert für Open Source- Software.

Wenn die Gebühr für eingekapselte Bits höher liegt als der Ertrag aus Open Source, macht es ökonomischen Sinn, die Closed Source-Methode anzuwenden. Wenn die Erträge aus Open Source höher sind als die Gebühr für geheime Bits, macht es Sinn, die Closed Source-Methode anzuwenden.

Das ist natürlich eine triviale Beobachtung. Nicht trivial ist aber die Bemerkung, daß der Vorzug der Open Source-Methode schwieriger zu messen und vorherzusehen ist als die Erträge aus eingekapselten Bits - dazu kommt, daß der Vorzug öfter unterschätzt als überschätzt wird. Tatsächlich war es bis zu dem Zeitpunkt, als der Mainstream der Geschäftswelt durch das Echo auf die Veröffentlichung des Mozilla-Quellcodes die Vorzüge von Open Source neu überdachte so, daß die Vorteile von Open Source mit dem Wert Null veranschlagt wurden.

Wie können wir also den Wert von Open Source evaluieren? Das ist eine schwierige Frage, aber wir können den selben Ansatz wie für jede andere prognostische Problemstellung verwenden. Beginnen wir mit den Beobachtungen von Fällen, in denen die Open Source-Methode ein Erfolg war oder versagte. Wir können dann versuchen, daraus ein allgemeines Modell zu entwickeln, das uns wenigstens ein Gefühl für den Kontext verschafft, in dem Open Source ein Nettogewinn für den Investor oder das Unternehmen ist, das versucht, die Erträge zu maximinieren. Danach können wir zu unseren Daten zurückkehren und versuchen, das Modell zu verfeinern.

Durch die in [CatB] präsentierte Analyse können wir erwarten, daß Open Source von hohem Wert ist, wenn a) Zuverlässigkeit/Stabilität/Skalierbarkeit von ausschlaggebender Bedeutung sind, und b) die Korrektheit des Designs und der Implementation nur auf dem Weg der unabhängigen Peer Review verifiziert werden kann. (Dieses zweite Kriterium gilt in der Praxis für die meisten nicht-trivialen Programme).

Das verständliche Bedürfnis des Konsumenten, möglichst nicht in die Falle eines Herstellermonopols zu gehen, wird das Interesse an Open Source erhöhen (und daher den Wettbewerbsdruck auf Hersteller erhöhen, die Open Source-Methode zu unterstützen), wenn die Software für den Konsumenten von zentraler Bedeutung ist. Daher gibt es noch ein drittes Kriterium c), das in Richtung Open Source drängt: die Software ist ein geschäftskritischer Faktor (wie das zum Beispiel bei vielen MIS-Abteilungen großer Firmen der Fall ist).

Für das Gebiet der Applikationen haben wir bereits festgestellt, daß Open Source-Infrastruktur Vertrauen und Symmetrie schafft, die mit der Zeit mehr Kunden anziehen wird und Closed Source- Infrastruktur in den Hintergrund drängen wird. Oft ist es auch besser, ein kleineres Stück eines solchen rapide wachsenden Marktes zu haben, als ein großes Stück eines geschlossenen und stagnierenden Marktes. Dem entsprechend ist es für die anvisierte Allgegenwart von Open Source wahrscheinlicher, daß der Wert höher und nachhaltiger ist als der einer kurzsichtigen Closed Source-Politik, die an der Vergebührung von geistigem Eigentum orientiert ist.

Tatsächlich impliziert die Fähigkeit von potentiellen Kunden, über die zuküftigen Konsequenzen von Herstellerstrategien nachzudenken und ihr Widerstand gegen Herstellermonopole eine noch schwerwiegendere Einschränkung: auch ohne einen überwältigenden Marktanteil kann man sich entweder für eine mögliche vollständige Marktdurchdringung durch Open Source oder direkte Gewinne durch Verkauf von Closed Source-Software entscheiden, aber nicht beides zusammen. (Einer Analogie dieses Prinzips begegnen wir beispielsweise auf Märkten für Elektronik, auf denen Kunden sich oft weigern, exklusive Designs - d.h solche ohne einen alternativen Hersteller - zu kaufen). Man kann es auch weniger negativ darstellen: wo Netzwerkeffekte (positive Netzwerkexternalitäten) eine dominierende Rolle spielen, ist Open Source wahrscheinlich der richtige Weg.

Wir können diese Logik durch die Beobachtung zusammenfassen, daß Open Source dort höhere Erträge als Closed Source verspricht, wo (d) die Software eine gemeinsame Datenverarbeitungs- oder Kommunikationsinfrastruktur hervorbringt oder fördert.

Schließlich noch die Bemerkung, daß die Betreiber einzigartiger oder auch nur hochgradig differenzierter Dienstleistungen einen höheren Anreiz haben, sich vor der Plagiierung ihrer Methoden durch Mitbewerber zu fürchten, als Dienstleister, deren zentrale Algorithmen und Kompetenzen allgemein verstanden werden. Dem entsprechend ist es für Open Source wahrscheinlicher, Gebiete zu dominieren, wenn (e) die Schlüsselmethoden (oder funktionalen Äquivalente) Teil allgemein bekannter Ingenieurskunst sind.

Die Kernsoftware des Internet, Apache und die Linux- Implementation des ANSI-standardisierten Unix API sind Schulbuchbeispiel für alle fünf Kriterien. Vor dem Zusammenwachsen von Datennetzwerken durch TCP/IP Mitte der 1990er gab es fünfzehn Jahre lang vergebliche Bemühungen, auf diesem Gebiet proprietäre Imperien zu errichten, auf der Grundlage von geschlossenen Protokollen wie DECNET, XNS, IPX und anderen. Diese Konvergenz illustriert die Rolle, die Open Source bei der Evolution solcher Märkte spielt.

Auf der anderen Seite scheint Open Source für Firmen den geringsten Wert zu haben, die über einzigartige wertschöpfende Software-Technologie verfügen (die Kriterium (e) erfüllt, relativ unempfindlich für Ausfälle ist (a), sehr gut auf anderem Weg als unabhängige Peer Review verifiziert werden kann (b), nicht geschäftskritisch ist (c) und dessen Wert nicht durch vollständige Marktdurchdringung oder Netzwerkeffekte gesteigert wird (d)).

Hier ein Beispiel für einen solchen Extremfall. Anfang 1991 wurde ich von einer Firma nach der Sinnhaftigkeit gefragt, ihren Quellcode zu veröffentlichen. Die Firma stellte Software her, die Schnittbilder für Sägewerke berechnet, um die Länge von Brettern zu maximieren, in die ein Baumstamm aufgeteilt werden kann. Meine Antwort auf diese Frage lautete "Nein". Das einzige Kriterium, das durch die Software wenigstens halbwegs erfüllt wurde, ist (c); owbohl ein erfahrener Werkmeister die Schnittmuster in der Praxis auch händisch berechnen könnte.

Als weiteren springenden Punkt muß man im Auge behalten, daß sich die Position eines Produkts oder einer Technologie auf diesen Skalen mit der Zeit verändern kann, wie wir das in der nächsten Fallstudie beobachten können.

In Summe kann man sagen, daß folgende Merkmale Evolutionsdruck in Richtung Open Source erzeugen:

(a)

Zuverlässigkeit, Stabilität und Skalierbarkeit sind von ausschlaggebender Bedeutung

(b)

Die Korrektheit des Designs und der Implementation kann nicht leicht auf anderem Weg als dem der unabhängigen Peer Review überprüft werden.

(c)

Die Software ist für den Benutzer geschäftskritisch

(d)

Die Software etabliert oder ermöglicht eine gemeinsame Computer- oder Kommunikationsinfrastruktur.

(e)

Die Schlüsselmethoden (oder deren funktionale Äquivalente) sind Teil wohlbekannter Ingenieurskunst.

Die Geschichte von id Softwares Spiele-Bestseller Doom illustriert die Wege, auf denen der Druck des Marktes und Produktevolution die Größenverhältnisse beim Gewinn von Closed vs. Open Source bedeutend verändern können.

Als Doom Ende 1993 erstmals herauskam, machten es seine Echtzeitanimation und subjektive Kamera einzigartig (was die Antithese zu Kriterium (e) darstellt). Nicht nur waren die Techniken und die visuelle Wirkung atemberaubend, auch konnte niemand herausfinden, wie diese Resultate mit den verhältnismäßig schwachen Mikroprozessoren der damaligen Zeit erzielt werden konnten. Diese eingekapselten Bits hatten für den Verkauf einen bedeutenden Wert. Daher lohnte sich die Veröffentlichung des Quellcodes so gut wie gar nicht. Das Spiel war für nur einen Spieler, ein Ausfall der Software war tolerierbar (a), das korrekte Funktionieren war nicht weiter schwierig zu überprüfen (b), von geschäftskritisch konnte keine Rede sein (c), und es gab keine Aussicht auf Netzwerkeffekte (d). Es war ökonomisch sinnvoll, den Quellcode für Doom unter Verschluß zu halten.

Der Markt um Doom stand aber nicht still. Zukünftige Mitbewerber erfanden funktionale Äquivalente für die Techniken zur Animation, und andere "first-person shooter"-Spiele wie Duke Nukem kamen heraus. Mit zunehmenden Marktanteil für Konkurrenten für Doom schrumpfte der Wert für die Vergebührung eingekapselter Bits.

Auf der anderen Seite brachte der Aufwand, diesen Marktanteil zu vergrößern, neue technische Herausforderungen mit sich - höhere Ausfallsicherheit, mehr Leistungsmerkmale, ein größerer Benutzerstamm und mehrere Plattformen. Mit dem Auftauchen von "Todesmatch"-Spielmodi und Doom-Onlinevermittlungen für Spielpartner begann der Markt signifikante Netzwerkeffekte zu zeigen. All das verzehrte Programmiererzeit, die id lieber in das nächste Spiel invstiert hätte.

Alle diese Trends erhöhten das Ausmaß in dem sich die Veröffentlichung des Quellcodes lohnte. Ab einem gewissen Punkt schnitten sich die Kurven des Nutzens und es machte für id ökonomischen Sinn den Quellcode für Doom freizugeben und ihr Geld auf Sekundärmärkten wie Szenario-Anthologien zu verdienen. Irgendwann nach dem Erreichen dieses Punktes wurde dieses neue Business Model Wirklichkeit. Dooms kompletter Quellcode wurde Ende 1997 veröffentlicht.

Doom ist eine interessante Fallstudie, da es sich weder um ein Betriebssystem noch um Kommunikations- oder Netzwerksoftware handelt; es ist von den üblichen und offensichtlichen Beispielen für Open Source-Erfolge weit entfernt. Tatsächlich ist Dooms Lebenszyklus - komplett mit Schnittpunkten der Nutzenkurven - vielleicht ein zukünftiges Schulbuchbeispiel für Applikationen in der heutigen Codeökologie, eine in der sowohl Kommunikation und Distributed Computation hohe Anforderungen an die Robustheit/Zuverlässigkeit/Skalierbarkeit stellen, der nur durch Peer Review entsprochen werden kann, und die oft die Grenzen zwischen technischem Substrat und einander konkurrierenden Akteuren verwischen (mit allen impliziten Belangen des Vertrauens und der Symmetrie).

Doom evolvierte vom Solo- zu einem Todesmatch-Spiel. Mehr und mehr wird das Netzwerk zum Computer. Ähnliche Trends sind sogar bei den konservativsten Business-Applikationen sichtbar - wie etwa ERPs. Die Geschäftswelt verbindet Firmennetzwerke mit denen ihrer Lieferanten und Kunden. Die ganze Architektur des World Wide Web ist natürlich ein zentrales Beispiel für diese Trends. Aus all dem folgt, daß der Nutzen von Open Source mehr und mehr steigt.

Wenn die gegenwärtigen Trends sich fortsetzen, wird die bedeutendste Herausforderung an die Software-Technologie und das Produktmenagement im nächsten Jahrhundert sein, zu wissen, wann man seinen Quellcode aus dem Tresor an die Öffentlichkeit bringen und in die Open Source-Infrastruktur integrieren soll, um den Effekt von Peer Review auszunutzen und durch Dienstleistungen und Sekundärmärkte in den Genuß höherer Erträge zu kommen.

Es gibt offensichtliche Gewinnanreize, den Schnittpunkt der Nutzenkurven nicht zu sehr zu in die eine oder die andere Richtung zu verfehlen. Darüber hinaus gibt es ein ernstes Opportunitätsrisiko, wenn man zu lange wartet - man könnte von einem Mitbewerber verdrängt werden, der seinen Quellcode in der selben Nische vorher veröffentlicht.

Der Grund für die Schärfe dieser Verfehlung ist, daß sowohl der Pool von Benutzern als auch der Pool von Talenten, die für eine Open Source-Kooperation für ein bestimmtes Produkt rekrutiert werden können, sehr begrenzt ist und diese Rekrutierung die Tendenz hat, ein für alle mal zu erfolgen. Wenn zwei Hersteller als erster und zweiter mit ihrem Quellcode herauskommen, der ungefähr die gleiche Funktionalität hat, dann wird wahrscheinlich der erste die meisten Benutzer und die am höchsten motivierten Mitentwickler für sich gewinnen können. Der zweite wird nur bekommen, was übrig bleibt. Die Rekrutierung ist nachhaltig, da die Benutzer sich an das Produkt gewöhnen und die Entwickler ihre Investitionen in den Code weiter nutzen wollen.

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, daß es mehrere miteinander konkurrierende Linux-Distributoren gibt, die eine von 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 von den Entwicklersites herunterladen.

Der Effekt dieser separaten Schichten ist, daß 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 von Code um Benutzerdollars.

Ein unmittelbarer Effekt dieser internen Marktstruktur ist es, daß kein Knoten im Netz unentbehrlich ist. Entwickler können aussteigen; sogar wenn ihr Teil des Codes nicht direkt von 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 Ganzes reagiert schneller auf Marktforderungen und ist für Schocks jeglicher Art weniger anfällig als das monolithischen Herstellern von 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 von unzulänglichen Programmiersprachen oder veralteten Entwicklungsumgebungen erzwingt; es gibt keine Forderung nach dem "Neuerfinden des Rades" im Namen der Produktdifferenzierung oder des Schutzes von 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 von 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 von 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.

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

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

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

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

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

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

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

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

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

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

Die Infusion von bedeutenden Mitteln in die Open Source-Welt hat noch eine weitere Auswirkung. Die Stars der Gemeinde finden gerade heraus, daß 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 muß. 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 einen 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 finzanzieren, die dann ex definitione von jedem Mitbewerber gratis verwendet werden kann?

Es gibt hier augenscheinlich zwei steuernde Ursachen. Die eine ist, daß, 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 F&E 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, daß 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 es 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, daß 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, daß dies nicht einfach als Humbug abgetan werden kann. Tatsächlich wurde ich Ende 1998 persönlich in den Vorstand von VA Linux Systems eingeladen, so daß 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, daß 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, daß 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 von 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 produziernde Firma typische. Stattdessen zeigt sie ein interessantes Extrem einer Charakteristik, wie wir sie von Wissens-intensiven Dienstleistungsindustrien gewohnt sind. Außzerhalb der Technologiewirtschaft können wir diese Muster beispielsweise bei Anwaltskanzleien, Arztpraktiken oder Universitäten beobachten.

Tatsächlich können wir sehen, daß 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 bewußt sind.

Die Marktmechanismen für die Finanzierung (und Amortisation!) von Open Source-Projekten entwickelt sich noch immer sehr rasch weiter. Die Business Models, 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 von Gütern (obwohl ihnen jeder Arzt oder Anwalt bestätigen kann, daß 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 Genuß gewaltiger Kosteneffektivität bei Open Source-Produkten (es gibt hier übrigens eine Parallele: der Ersatz des traditionellen Telephonnetzwerks 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, daß es noch vor Ende 1999 mehrere Linux- und Open Source-basierte Börsengänge geben wird - und daß sie alle ganz erfolgreich sein werden.

Eine andere sehr interessante Entwicklung ist der Beginn von systematischen Versuchen, Task Markets bei Open Source-Projekten zu finden. SourceXchange und CoSource sind zwei von einander leicht verschiedene Wege, das Modell einer umgekehrten Auktion zur Finanzierung von Open Source-Projekten anzuwenden.

Die übergeordneten Trends sind klar erkennbar. Wir haben IDCs Hochrechnung schon erwähnt, die angibt, daß Linux bis 2003 schneller wachsen wird als alle anderen Betriebssysteme zusammen. Apache liegt bei 61 Prozent Marktanteil und expandiert ununterbrochen weiter. Die Verbreitung des Internet explodiert, und Erhebungen wie der Internet Operating System Counter zeigen, daß 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 von 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.

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 von "Applikationen" (die im Augenblick überhaupt nicht "commoditized" im Sinne von "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, daß 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, daß unsere Erkenntnis auch darin besteht, daß der Grad an Offenheit des Quellcodes in einem bestimmten Softwarebereich davon abhängt, wie stark die wirkenden Netzwerkeffekte sind, wie hoch die Kosten eines Ausfalls sind und in welchem Maße das Unternehmen von Software abhängig ist.

Nun können wir einige Vorhersagen wagen, vorausgesetzt, daß 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 von Kommunikationssoftware, die keine Überschneidungen mit konkurrienden Herstellern haben) wird fast vollständig Open Source sein, von Benutzerkonsortien gepflegt werden und von 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 von 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 von 1999 nach einer weiteren aus.

Middleware ( Datenbanken, Entwicklungswerkzeuge oder die Anwendungsschichten von Protokoll-Architekturen) werden nicht so einheitlich abgegrenzt sein. Ob Kategorien für Middleware offener oder geschlossener sind, hängt von 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, daß weder "Applikationen" noch "Middleware" tatsächlich stabile Kategorien sind. In "Wann man seinen Quellcode aus dem Tresor holen sollte" haben wir gesehen, daß bestimmte Softwarekategorien einen eigenen Lebenszyklus zu haben scheinen, der von "natuerlich geschlossen" zu "natuerlich 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 von 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, daß 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, daß 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, daß dieses Gleichgewicht für den Konsumenten von 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.

[CatB]

"Die Kathedrale und der Bazar"

(www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/)

Die deutsche Version (/www.phone-soft.com/RaymondCathedralBazaar/catb_g.0.html)

Auf unserem Server

[HtN]

"Homesteading the Noosphere"

(www.catb.org/%7Eesr/writings/homesteading/homesteading/)

Die deutsche Version (www.phone-soft.com/raymondhomesteading/htn_g.0.html)

[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 von Open Source-Methoden auf Computerspiele verfaßt; 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 von Marshall van Alstyne, der auf die konzeptionelle Wichtigkeit von rivalisierenden Informationsgütern hingewiesen hat. Ray Ontko von 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 von ihnen sind, wissen Sie es.

Auch ist es ein weiteres Zeugnis für den Wert des Open Source- Modells, daß dieses Dokument durch Rückmeldungen per e-mail viel gewonnen hat, die ich innerhalb von wenigen Tagen nach der Veröffentlichung erhielt. Lloyd Wood wies auf die Wichtigkeit hin, daß Open Source-Software "zukunftssicher" ist. Doug Dante erinnerte mich an das "Free the Future"-Business Model. Eine Frage von 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 Business Models. Stephen Turnbull reizte mich wegen der zu oberflächlichen Behandlung der Trittbrettfahrereffekte bis zum Wahnsinn.

Hersteller von Peripheriegeräten (Ethernet-Karten, Diskcontrollers, 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 Treiberquellcode für ihre Karten zu veröffentlichen. Trotzdem gibt es noch Widerstand. In diesem Anhang versuchen wir, einige der wirtschaftlichen Irrtümer zu zerlegen, die ihn hervorrufen und fördern.

Als Hardwarehersteller fürchtet man vielleicht, daß eine Veröffentlichung des Quellcodes wichtige Details über die eigene Hardware enthüllen könnte, die dann von 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üßten, ein so großer Anteil an der Lebensdauer des Produkts, daß sie dann nicht für eigene innovative und vorteilhafte Entwicklungen verwenden könnten. Zu plagiieren wäre ein so großer Fehler Ihres Mitbewerbers, daß Sie sich gar nichts besseres wünschen können.

Auf jeden Fall ist es so, daß 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 von Linux- und FreeBSD- Programmierern, die sowohl die Fähigikeit als auch die Motivation haben, Gerätetreiber für eine neue Karte zu schreiben. Für viele Klassen von Geräten, die eine relativ simple Schnittstelle haben und wohlbekannten Standards entsprechen (wie Disk Controllers 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 Angelenheit und gibt es immer einen Ort auf der Welt, in dem so ein Abkupfern legal ist.

Für den überzeugenden Beweis, daß diese Behauptungen wahr sind, untersuchen Sie die Liste von 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, daß Sie an Ihre Fähigkeit glauben, die Konkurrenz dort zu übertreffen, wo es darauf ankommt: Ideen und Innovation.

Wenn Sie sich ganz bedeckt halten, bekommen Sie das schlechteste aller Welten - Ihre Geheimnisse werden schließlich ergründet werden, Gratis-Entwicklungen werden an Ihnen vorbeigegangen sein und Sie werden nicht in den Genuß kommen, daß dümmere Mitbewerber versuchen, Ihr Produkt zu clonen. Am wichtigsten aber ist, daß Sie die Auffahrt zu weiter Verbreitung durch frühe Akzeptanz des Marktes verpassen. Ein großer und einflußreicher 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 von jemanden Kaufen, der klüger ist.