3. Der Fertigungswahn

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.

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.

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.