Frei und/oder offen?

From Pentagon Source to Open Source and beyond

(aus FIfF Kommunikation 3/1999, 21-27)

Rainer Fischbach
http://www.rainer-fischbach.info
mailto:rainer_fischbach@gmx.net

Quellenoffene Software erlebt derzeit die Promotion zu einem Thema für die Technik- und Wirtschaftsseiten der Tagespresse. Was ist geschehen, daß eine Sache, die seit Jahrzehnten ein selbst von der Fachpresse kaum beachtetes Leben führt, zu solcher Prominenz gelangt? Und weshalb ist auf einmal vor allem von offenen Quellen die Rede, wo doch ein signifikanter Teil der herausragenden Programme mit offenem Quellcode als freie Software bekannt ist?

Die Vorgeschichte

Die wichtigsten Produzenten quellenoffener Software waren bis in die 80er Jahre die in öffentlichem Auftrag forschenden Universitäten und Laboratorien. In den USA bestanden die Geldgeber ­ allen voran die ARPA des DoD und die NSF ­ darauf, daß die Ergebnisse, sofern sie nicht der militärischen Geheimhaltung unterlagen, der Öffentlichkeit zugänglich zu machen seien. Besonders die Informatikförderung der ARPA zielte weniger auf unmittelbar militärisch verwertbare Resultate sondern darauf, den Stand der Disziplin insgesamt anzuheben, die Kooperation zwischen den Forschern zu verbessern und Ressourcen intensiver und auf innovative Weise zu nutzen. Projekte wie MAC am MIT und das ARPANet sind in diesem Zusammenhang zu sehen und nicht etwa in dem eines atomkriegssichern Kommunikationsnetzes (das das ARPANet niemals war und das Internet nicht ist), das durch diverse Legnden geistert. [Norberg/Neill/Freedman1996]

Unter der Tarnkappe der militärischen Forschung betrieb die ARPA vielmehr Wissenschafts- und Industriepolitik. Eine ähnliche industriepolitische Rolle kam dem Vergleich zu, den AT&T 1956 mit dem Justizministerium abschloß, um das Telefonmonopol zu behalten: Der Telefongigant mußte darin nicht nur darauf verzichten, ins Computergeschäft einzusteigen, sondern auch sich auch verpflichten, seinen Technologieschatz — die Bell Labs waren damals die größte Forschungseinrichtung der USA, die praktisch aus einer in den Telefongebühren enthaltenen Forschungsabgabe unterhalten wurden — zu öffnen und gegen nominelle Gebühren zu lizenzieren. Die Halbleiter- und die Softwareindustrie in den USA erhielten dadurch entscheidende Anstöße. Die zu einem großen Teil durch die ARPA finanzierte Unix-Entwicklung in Berkeley und anderen Universitäten sowie deren in den 80er Jahren einsetzende Kommerzialisierung durch daraus hervorgegangne Firmen wie Sun wären ohne diese Grundlage nicht möglich gewesen. [Lüthje1993, Salus1994]

Berkeley-Unix, TeX und vieles andere sind Produkte von dafür ordentlich aus öffentlichen Mitteln alimentierten Wissenschaftlern. Doch auch in Europa gab es erfolgreiche Beispiele: Die weite Verbreitung von Pascal in den 70ern und 80ern wäre ohne den im Quellcode verfügbaren p-Compiler aus der ETH Zürich nicht möglich gewesen. Der Mißerfolg des avantgardistischeren und weitaus leistungsfähigeren Simula lag dagegen nicht zuletzt darin, daß die norwegische Regierung dem staatlichen Rechenzentrum, wo die Sprache in den 60ern entwickelt worden war, nicht erlaubte, den Compiler öffentlich zu machen.

Das erste Zeitalter der quellenoffenen Software ging mit der Kommerzialisierung der öffentlich geförderten Entwicklungen in den 80er Jahren zuende. Viele der Forscher waren zu Unternehmern geworden, die ihre vom Steuerzahler finanzierten Entwicklungen in Betriebsgeheimnisse oder Patente verwandelten. Die gewandelte Haltung des obersten Bundesgerichts und nachfolgend des Patentamtes zur Patentierbarkeit von Softwareverfahren begünstigte diese Entwicklung in den USA. Nachdem klar geworden war, daß das Telefonmonopol keinen Bestand haben würde, konnte AT&T seine Unix-Lizenzpolitik ändern. Der Traum, nach der Reorganisation im Computergeschäft reüssieren zu können, stellte sich zwar als Irrtum heraus, doch die sprunghaft angestiegenen Gebühren und die restriktiver gewordenen Bedingungen einer Lizenz für den Unix-Quellcode besiegelten nicht nur das Ende der ersten Epoche der quellenoffenen Software sondern gaben auch das Signal zum Beginn der zweiten.

Die öffentlich finanzierten Unix-Erweiterungen und Verbesserungen aus Berkeley waren von AT&T effektiv privatisiert worden. In Berkeley machte man sich nun daran, ein Unix zu schaffen, das ganz frei von AT&T-Code sein sollte: 4.4 BSD. In dem Rechtsstreit, in den AT&T die UC Berkeley darum verwickelte, sollte sich die Gegenklage, daß AT&T, ohne auf den Ursprung hinzuweisen, Berkeley-Code verwendete, als entscheidende Waffe erweisen. [McKusick1999]

Software als öffentliches Gut

Von keiner geringeren Tragweite als die Entwicklungen in Berkeley war die Gründung der Free Software Foundation durch Richard Stallman. Deren (und Stallmans) Bedeutung liegt nicht allein darin, daß sie mit dem GNU-Projekt eine Reihe von herausragenden Softwareprodukten hervorbrachte, sondern auch darin, daß sie den Begriff der freien Software prägte und durch eine politische Argumentation explizierte: Freie Software zeichnet sich dadurch aus, daß sie nicht nur im Quellcode verfügbar ist und man sie nach Belieben nutzen, abändern und weiterverbreiten darf, sondern daß alle, die letztere Möglichkeit wahrnehmen, verpflichtet sind, jene Freiheiten zu erhalten. Das Kriterium der freien Software ist das Privatisierungsverbot. [Stallman1999]

Es war nicht zuletzt die Erfahrung der frühen 80er Jahre, als aus öffentlich geförderten Projekten kommerzielle Unternehmen und der Quellcode von immer mehr Software unzugänglich wurde, die Stallman dazu motivierte, in die GPL eine Bedingung hineinzuschreiben, die den Status freier Software irreversibel macht. Doch hinter dem Begriff steht auch eine politische Reflexion der Funktion und der wirtschaftlichen Merkmale von Software: Software ­ zumindest die, die für breite Anwenderschichten unmittelbar oder mittelbar von Nutzen ist ­ stellt nach Stallmans Analyse ein öffentliches Gut dar. [Stallman1992]

Öffentliche Güter zeichnen sich nach der überlieferten volkswirtschaftlichen Lehre durch Nichtrivalität und Nichtexklusivität aus; wobei Nichtrivalität bedeutet, daß der Wert des Gutes nicht leidet, wenn viele es nutzen, und Nichtexklusivität, daß es (mit vertretbarem Aufwand) nicht möglich ist, Nutzer auszuschließen. Klassische Beispiele für solche Güter sind Straßen und Leuchttürme. Es gibt eine berechtigte Kritik an diesen Kriterien, die darauf hinweist, daß sie meist nie aus rein technischen Sachverhalten ­ also der grundsätzlichen Unmöglichkeit von Nutzungskonflikten oder Ausschließungsmechanismen ­ herzuleiten seien, sondern sie auch immer normative Vorgaben reflektierten: Straßen z. B. sollen als eine der Voraussetzungen praktischer Freiheit offen und ohne Diskriminierung zugänglich sein. Die entscheidenden technisch-wirtschaftlichen Merkmale öffentlicher Güter seien benauer als Externalitäten (Nutzen oder Schaden, der durch wirtschaftliches Handeln nicht unmittelbar zu kontrollieren ist) und Unteilbarkeiten (Größen und Verbundvorteile) zu bestimmen. [Fritsch/Wein/Ewers1996]

Tatsächlich bietet das Softwaregeschäft ausgeprägte Größen- und Verbundvorteile: Wegen der fixen Entwicklungskosten sind die Grenzkosten einer Lizenz außerordentlich niedrig; woraus sich unter dem herrschenden Regime der Softwareproduktion eine Tendenz zum Monopol und bei hohen Stückzahlen immense Profitmöglichkeiten ergeben. Alternativ liegt darin jedoch auch die Möglichkeit, solche Produkte zu öffentlichen Gütern zu machen, da damit die Voraussetzung für Nichtrivalität gegeben ist. Das dehnt sich jedoch nicht auf die Anwenderunterstützung aus: Hier existieren keine vergleichbaren Unteilbarkeiten; weshalb Rivalität gegeben ist. Während die Verbundvorteile der Softwareproduktion heute die Position und die Profite der monopolistischen Anbieter stärken, könnten sie auch zugunsten der Öffentlichkeit wirken.

Mit Software verbinden sich vielfältige positive Externalitäten: Die wichtigste besteht darin, daß mittels verbreiteter Technik das Kopieren von elektronisch gespeicherten Daten mühelos, selbstverständlich und oft auch zwangsläufig erfolgt. Daraus ergibt sich die Nichtexklusivität von Software. Das heutige Regime der Softwareproduktion verhindert diese Externalität durch Kunstgriffe, die den Anwendern das Leben schwer machen, und stellt, falls das nicht funktioniert, Fälle von Nichtexklusivität unter Strafe. Die strafrechtliche Unterdrückung bzw. Einschränkung der Kopierexternalität hat, sofern sie sich auf den Quelltext erstreckt, noch weitere, wohlfahrtsmindernde Folgen: unterbliebene Anpassungen, Verbesserungen und Wiederverwendungen des Quellcodes sowie nicht stattgefundene Lernprozesse durch sein Studium. Schließlich verbinden sich mit der heute massenhaft verbreitete Software ausgeprägte Netzexternalitäten: Der Wert meines Betriebssystems, meiner Publishingsoftware, etc. steigt mit der Zahl ihrer Nutzer, da ich dann z. B. mit mehr Partnern Daten und (vorsicht kriminell!) weitere Software austauschen kann.

Unter dem heutigen Regime der Softwareproduktion spielen die Unteilbarkeiten und Netzexternalitäten den Monopolen in die Hände ­ genauer: Sie machen sie erst möglich und verstärken ihre Position. Dem Staat kommt die Rolle zu, diese Position abzusichern, indem er die Kopier- und Verbesserungsexternalitäten von Software unterdrückt. Dieses Regime ist mit immensen Wohlfahrts- und Freiheitsverlusten verbunden: es behindert die Kommunikation, Bildung und persönliche Entwicklung von Menschen, es verhindert die Verbesserung und Anpassung von Software an ihre Bedürfnisse, es ist verschwenderisch, da es redundanten Aufwand erzwingt, es führt schließlich zu einer Fehlallokation von gesellschaftlichem Reichtum, indem es Superprofite, Marktingschlachten und ausschließlich der Machterweiterung dienende Fusionen ermöglicht.

Ein Regime, das Software zum öffentlichen Gut macht, ist auf der Basis der dargelegten Unteilbarkeiten und positiven Externalitäten nicht nur sachlich möglich, sondern auch im Interesse von Freiheit und Wohlfahrt der Bürger geboten. Das ist die Ratio für ein alternatives Regime der Softwareproduktion. Stallman hebt einige ihrer Elemente ­ die Freiheits- und Wohlfahrtsgewinne durch freie Software ­ mit idealistischer Intonation hervor und stellt vor allem die ethische Motivation, die zur FSF und zum GNU-Projekt führte, heraus. Ein alternatives Regime würde nicht alle Software betreffen sondern die 5-10%, die für ein großes Publikum und dessen Informationsaustausch von Bedeutung und folglich Bestandteil der informationellen Infrastruktur sind. Die meiste Software wird weiterhin für spezielle industrielle Zwecke geschrieben und an wenigen Punkten eingesetzt werden; was die Merkmale, die einerseits Monopolprofite und andererseits die öffentliche Verfügbarkeit ermöglichen, in den Hintergrund drängt.

Nicht übersehen sollte man, daß Software zum öffentlichen Gut zu machen einen großen Fortschritt für die Verbraucher darstellen, jedoch die Kostensituation der Wirtschaft nur unwesentlich verändern würde. Die reinen Lizenzkosten, von denen wiederum nur ein kleiner Prozentsatz auf die hier in Frage stehenden Produkte entfällt, stellen nur einen geringen Teil der IT-Systemkosten dar. Entscheidend für die Wirtschaft wären an öffentlicher Software Gesichtspunkte wie erweiterte Wahlmöglichkeiten, veringerte Abhängigkeit, bessere Beherrschung des Updatezyklus und seiner Folgekosten sowie bessere Qualität und Anpaßbarkeit der Produkte. Ihrer Wertschöpfung nach gehören Microsoft & Co noch nicht zu den ganz Großen. Im Vergleich dazu riesenhaft sind nur ihre Profite und geradezu gigantisch ihre Börsenkapitalisierung ­ was im Falle ihres Niedergangs einige Verwerfungen auf den Finanzmärkten nach sich ziehen könnte.

Wer bezahlt oder wer schenkt?

Nichtexklusive Güter bieten gewinnorientierten Unternehmen kaum Anreize sie bereitzustellen: Wenn man Nichtzahler von ihrer Nutzung nicht ausschließen kann, dann muß man, was riskant ist, sich darauf verlassen, daß genügend Leute freiwillig bezahlen. Die Alternative besteht darin, daß Akteure, die nicht gewinnorientiert arbeiten, die Versorgung mit solchen Gütern übernehmen. Die traditionelle Lösung besteht in der kollektiven Allokation: die öffentlichen Hände übernehmen die Versorgung ­ entweder durch öffentliche Betriebe oder indem sie private beauftragen ­ und ziehen Zwangsbeiträge zu ihrer Finanzierung ein. Bei Leistungen mit ausgeprägten Externalitäten wie Bildung und Grundlagenforschung ist das in den Industrienationen eingespielte Praxis.

Software mit Infrastrukturcharakter kollektiv durch die öffentlichen Hände oder von ihnen beauftragte Akteure bereitzustellen, mag sich heute zwar wie eine exotische altlinke Idee anhören, doch entspricht dies einem historisch erfolgreichen Muster. Letzten Endes sind viele der grundlegenden informationstechnischen Innovationen und nicht zuletzt auch die entscheidenden Standards des Internet samt ihrer Modellimplementation das Ergebnis der Tätigkeit öffentlicher Hände. Richard Stallman, dem der Ruf vorauseilt, die Produktion freier Software für eine Sache von Idealisten zu halten, ist übrigens keinesfalls ein grundsätzlicher Gegner solcher Lösungen. Er hält die Entwicklung freier Software im bezahlten Regierungsauftrag durchaus für eine gute Sache. [Stallman1992 und persönliche Mitteilung] Doch es gibt auch andere Stimmen aus den USA, die der Regierung hier eine Rolle zusprechen. [Bollier1999, Stoltz1999]

In der politischen Landschaft der 80er war die Aussichtslosigkeit entsprechender Appelle offenkundig. Als einzige Altrnative zur sich ausbreitenden kommerziellen Softwarekultur bot sich damals eine Graswurzelbewegung an, die auf Sach- (Programmcode, Hardware) und Finanzspenden, aus denen Programmiererarbeit bezahlt wurde, angewiesen war. Das Privatisierungsverbot für freie Software steht in engem Zusammenhang mit dem Graswurzelcharakter der Bewegung: Es grenzt freie Software klar von kommerzieller ab, stabilisiert die Motivation derer, die freiwillig Beiträge dazu leisten und übt im gleichen Maße, in dem die Attraktivität freier Produkte steigt, einen gewissen Druck aus, selbst unter kommerziellen Prämissen zu ihrer Entwicklung beizutragen.

Wenn dagegen quellenoffene Software durch bezahlte Arbeit im öffentlichen Auftrag entsteht, sind die Abgrenzungs- und Motivationsanforderungen wesentlich geringer. Der Souverän kann hier, wie er es in vielen Fällen auf anderen Gebieten auch tut, Infrastrukturleistungen unter wohlfahrts- und industriepolitischen Gesichtspunkten bereitstellen. Genau das war schließlich die Funktion der Informatikförderung durch die ARPA. Zu fragen wäre allerdings, ob die öffentliche Hand, wenn sie denn in quellenoffene Software investierte, nicht solche Verwertungen die deren Offenheit erhalten, begünstigen und solche, die dies verweigern, entmutigen sollte. Kein harter Zwang, aber doch ein sanfter Druck zur Offenheit wäre angezeigt. Daß es zudem außer der direkten staatlichen Intervention auch andere bewährte Formen des öffentlichen Wirtschaftens wie die öffentlich-rechtlichen Anstalten gibt, wäre zu bedenken.

Es wäre jedoch ein Wunder, wenn es allein beim sozialdemokratisch-bürokratischen und beim graswurzelhaft-anarchistischen Modell der quellenoffenen Software geblieben wäre. Ein zeitgeistkompatibles, kein neoliberales Dogma in Frage stellendes Modell war spätestens dann angesagt, als solche Software sich einmal als Erfolgsgeschichte erwiesen hatte: Es liegt seit zwei Jahren vor, nennt sich Open Source und setzt sich bewußt von der Programmatik der FSF mit ihrem Privatisierungsverbot ab. Sein zentraler Anspruch besteht darin, eine schlüssige Antwort zu liefern auf die Frage, warum Menschen Arbeit und/oder Geld in quellenoffene Software investieren sollen ­ eine Antwort zumal, die keiner Appelle an die ethischen Maßstäbe von Individuen oder gar das Handeln des Gemeinwesens bedürfe.

Für Eric Raymond, den führenden Propagandisten von Open Source ist dieses Modell nicht die Alternative sondern die zwangsläufige und geradezu naturhafte Fortsetzung des entfesselten Kapitalismus. Open Source erscheint in seiner Darstellung als eine Maschine, die quasi naturgesetzlich Arbeitskraft und Kapital ansauge, um nicht nur Software konkurrenzloser Qualität sondern auch Profit auszuspucken. Eine Bericht aus der Feder von Tim O'Reilly in Esther Dysons Investorenbrief Release 1.0 [O'Reilly1998] soll dementsprechend mit Ratschlägen, wie man mit Open Source Geld machen könne, Investoren locken. O'Reilly muß es wissen: Wenn irgend jemand mit quellenoffener Software Geld gemacht hat, dann er. Die Formel: Wenn andere Software verschenken, verkaufe das Buch dazu, ist seit Jahren ein Knüller.

Die zentralen Komponenten von Raymonds Open Source-Maschine bilden die sogenannte Geschenkökonomie [Raymond1998b] und die Bazarmethode [Raymond1998a]. Der Geschenkökonomie kommt die Funktion zu, dem Unternehmen Open Source hochmotivierte Arbeitskraft zuzuführen, und der Bazarmethode bzw. ihrer Propagierung die, Investoren und industrielle Softwarenutzer von den unübertrefflichen Vorzügen des Modells zu überzeugen. Wichtig ist, daß das Modell die Grundkategorien Eigentum und Profit nicht nur unangetastet läßt sondern in neuem Kontext rehabilitiert. Zur Krönung des Ganzen bastelt Raymond schließlich einen Frontier-Mythos, in dem Open Source sich als vorläufig letzte Wiederholung des ewigen und uramerikanischen Going West-Themas offenbart. [zu dessen Funktion im High-Tech-Kontext vgl. Fischbach1998]

Freudloser Egoismus

Wenn Tausende von Menschen ohne materielle Gratifikation und einige wenige vielleicht gegen bescheidenen Lohn Software zum Verschenken entwickeln, dann stellt dies aus der Sicht des vorherrschenden Menschenbildes, dem zufolge die Suche nach dem größtmöglichen individuellen wirtschaftlichen Nutzen das Handeln antreibe, eine beunruhigende Tatsache dar. Doch Raymond gibt Entwarnung [Raymond1998b]: Dieses Verhalten sei völlig ok, nur daß die Entwickler statt monetären Reichtums eben einen Reputationsschatz anhäuften. Keine Spur von subversiver Selbstvergessenheit sei da vorhanden. Der puritanische Analcharakter, so ist man versucht, Raymonds frohe Botschaft an die Stützen der Gesellschaft zu extemporieren, sei strukturell intakt geblieben, er habe sich nur eine neue Währung, ein neues Medium der Akkumulation erkoren.

Auf der Basis des materiellen Reichtums, den die kapitalistische Marktwirtschaft hervorgebracht habe, sei eine Geschenkökonomie entstanden, in der es jedoch garnicht, wie es oberflächlich den Anschein habe, ums Schenken, sondern um die Anhäufung von Ansehen gehe, das proportional zum Umfang der Geschenke wachse. Geschenke sind Mittel der Reputationsbereicherung, keine Zwecke in sich und die Arbeit bleibt so entfremdet wie zuvor. Raymond hat auch gleich ein geschichtsphilosophisches Schema zur Hand, in das sich das alles trefflich einfüge: Auf die Kommandohierarchien finsterer Vorzeiten folge die helle Gegenwart der universalen Tauschwirtschaft, über die sich schließlich als die den Informationswaren angemessene Form die Geschenkökonomie lagere. Daß innerhalb der Organisationen, die als die wichtigsten Akteure der Tauschwirtschaft fungieren, Kommandohierarchien vorherrschen, scheint Raymond keines Gedankens wert zu sein. Die kapitalistische Marktwirtschaft sei der alternativlose Sieger der Geschichte, die Geschenkökonomie ihre logische Komplettierung.

Wenn es nicht ums Schenken geht sondern um die Akkumulation von Reputation, dann spielt auch der genaue Charakter der Geschenke keine Rolle mehr. Das Privatisierungsverbot erweist sich dann, wie Raymond nicht müde wird zu versichern, als wirtschaftsfeindliche Altlast. Deshalb Open Source als neues Label mit einer liberaleren Lizenzpolitik. Der Akkumulationszwang im Felde des Ansehens treibe den Open Source-Projekten die Programmierer in Scharen zu; womit sich nicht nur das Nachdenken über deren Finanzierung erübrige sondern sich auch eine wiederum innerhalb des Marktsystems ausbeutbare Produktivkraft darbiete. Open Source als Nulltarif-Outsourcing und Experimentierfeld für neue Geschäftsmodelle: so lautet die Botschaft, die Raymond, O'Reilly & Co. an die Venture Capitalists richten.

Wichtig sei natürlich auch, daß auf dem Felde, auf dem Programmierer sich ihre Reputation erarbeiten sollen, die richtige Ordnung ­ oder genauer: Eigentumsordnung ­ herrsche. Und auch diesbezüglich, so meldet Raymond [Raymond1998b], sei alles in Ordnung. Um es in ein schlichtes Bild zu fassen: Es gehe zu wie weiland im Wilden Westen. Das, was die Horden von Programmierern, die quellenoffene Software produzieren, trieben, sei in Wirklichkeit Landnahme im Reiche der Ideen. Daß Raymond dies feierlich als Besiedlung der Noosphäre ausgibt, verrät zumindest mangelnde Sorgfalt: Wie man bei seinem Schöpfer Teilhard [Teilhard1959] oder auch in einem guten Lexikon nachlesen kann, bezeichnet der Begriff Noosphäre nicht, wie Raymond glaubt, das »Territorium der Ideen«, sondern den des Denkens fähigen sowie den unter seiner Anleitung umgestalteten Teil der physischen Welt — nach unserem Wissen also die Menschen und ihre Artefakte. Jedenfalls landet Raymond mit diesem Versuch, schon durch die Wahl eines Wortes einen hoch- und weitreichenden Anspruch vorzutragen, glatt auf dem Bauch.

Daß, obwohl die diversen Lizenzen für quellenoffene Software allen erlauben, mit dem Sourcecode nach Belieben zu verfahren, die entsprechenden Projekte keinesfalls immer in eine Vielzahl von Entwicklungssträngen zerfasern, glaubt Raymond durch die Existenz von stillschweigend akzeptierten Eigentumsrechten in den Gefilden der Programmideen erklären zu können. Zwischen dem Buchstaben der offenen Lizenzen und der Praxis der Projekte glaubt er einen Widerspruch feststellen zu müssen.

Nun bilden der Sourcecode und was alle möglichen Leute damit anstellen mögen eine Sache, seine Verbreitung unter einem bestimmten Namen als Träger eines Produkts dagegen eine andere. Die Anwender und auch diejenigen, die darauf ihre Erweiterungen bzw. Anpassungen aufsetzen, möchten an einem konsolidierten Entwicklungsstrom teilhaben, in den auch zukünftig die entscheidenden Verbesserungen einfließen. Die Betreuer dieser Projekte sind nicht ihre Eigentümer sondern sie genießen das Vertrauen der Anwender und Koentwickler ­ und das ist geliehen. Das Postulat von Eigentumsrechten in einem Ideenland ist nicht nur überflüssig sondern ungeeignet, um diesen Sachverhalt zu erklären. In seinem Bekenntnis zu den Eigentumsrechten als Schlüsselkonzept seines Weltverständnisses gibt Raymond sich als radikaler Verfechter des gsellschaftlichen Status quo zu erkennen. Eigentum ist für ihn stammesgeschichtlich als verrechtlichte Form des Reviers legitimiert. Daß es in der Natur ganz unterschiedliche Formen des Territorialverhaltens gibt, schert ihn dabei so wenig wie der Umstand, daß die sozial folgenreichsten Formen des Eigentums keinesfalls mehr die Funktion haben, Individuen eine Schutzzone zu gewähren ­ oft genug das Gegenteil.

Der Umstand, daß selbst dann, wenn, wie im Falle der quellenoffnen Software einer beliebigen Vielfalt von Produkten, Herstellern und horizontalen Austauschbeziehungen keine formalen Hindernisse im Weg stehen, sich trotzdem stabile Formen von vertikaler Integration, eben: hierarchische Beziehungen ausbilden, besitzt eine rationale Erklärung auf der Basis der Reduktion von Transaktionskosten sowie von Bündelungs- und Größenvorteilen. Es ist für die Anwender eben einfacher, mit einem verantwortlichen Entwickler bzw. Lieferanten für ein Funktionsbündel umzugehen und wenn jener als Fokus für diesbezügliche Verbesserungen, Innovationen und Informationen fungiert, dann gewährleistet dies, daß diese mit gringstem Aufwand die schnellste und weiteste Verbreitung finden. In den Wirtschaftswissenschaften bildeten solche Zusammenhänge in den letzten zwei Jahrzehnten eines der aktivsten und fruchtbarsten Forschungsgebiete [Carrol/Teece1999], aus dem die Einsicht erwuchs, daß Hierarchien eben oft effektiver funktionieren als horizontale Märkte. Die Konzerne kennen und praktizieren diese Einsicht übrigens auch ­ unbeschadet aller ideologischen Bekenntnisse zur Überlegenheit des Marktes.

De facto sind die meisten Projekte quellenoffener Software auch hierarchischer, als das deklarierte Selbstverständnis es wahrhaben will, doch die Entwickler, Distributoren und Propagandisten müssen diese Lektion noch lernen. Selbst wenn das in der Praxis tatsächlich funktionieren sollte: Man kann die Leute aus der Wirtschaft nicht auf irgendwelche diffusen Quellen verweisen. Sie wollen für bestimmte Probleme auch bestimmte Ansprechpartner ­ und zwar insgesamt nicht allzu viele ­ haben, die dafür die Verantwortung übernhmen. Anders sind Entscheidungen z. B. für freie Produkte innerhalb eines Unternehmens nicht durchsetzbar.

Magische Rezeptur?

In der Metapher des Bazars, die Raymond [Raymond1998a] mit dem Anspruch einführt, ein gültiges, bewährtes Software-Engineeringwissen obsolet machendes Modell der offenen Softwareentwicklung zu beschreiben, artikuliert sich möglicherweise ein Selbstmißverständnis der Bewegung. Der Bazar soll für eine völlig offene, dezentrale Entwicklung ohne Hierarchien stehen. Doch weit davon entfernt, eine Methode zu beschreiben, breitet Raymonds Text lediglich eine Anekdote aus. Schon das Bild vom Bazar liegt weit daneben: Ein Bazar ist weder ein Ort, an dem man sich vorwiegend Geschenke macht, noch einer, an dem offene, horizontale Austauschformen dominieren: familiäre Bande, Stammeszugehörigkeiten, zünftige Loyalitäten, alte Freundschaften, religiöse Bruderschaften und politische Bünde beherrschen dort das Geschehen. Kein Vorbild also für die offene Softwareentwicklung ­ oder doch?

Fraglich ist vor allem, wie verallgemeinerungsfähig Raymonds Behauptungen sind. Ohne Zweifel sind, um die beiden immer wieder angeführten Perlen der Bewegung zu nennen, der Linux-Kernel und Apache gute, bewährte Produkte, die gegenwärtig expandierende Nischen erfolgreich besetzen. Doch weder ein klassischer, monolithischer Unix-Kernel noch ein Server-Daemon für ein TCP-basiertes Anwendungsprotokoll können heute als innovative Produkte durchgehen. Beide beruhen auf konservativen, weithin bekannten Designs und nicht minder verbreitetem Knowhow, das mehr oder weniger Bestandteil der Informatikausbildung ist. Daß man an diesen Designs durchaus auch fachliche Kritik üben kann, sei hier einmal beiseite gestellt. Jedenfalls kann man bei einer vorgegebenen, bekannten Produktstruktur mit genügend unabhängigen Komponenten und reichlich vorhandenen, passenden Qualifikationen leicht Brooks Law [Brooks1995] scheinbar außer Kraft setzen. Die Annahme, daß das Modell sich auf beliebige Problemstellungen übertragen ließe bzw. in beliebige Dimensionen skalierbar wäre, erscheint zumindest als unfundiert, wenn nicht gar als verwegen. Solange zuverlässige softwaremetrische Daten fehlen, bleiben entsprechende Behauptungen unseriös.

Selbstüberschätzung der Akteure und ein blindes Vertrauen in scheinbar unübertreffliche Methoden stellen die größte Gefahr für die Sache der quellenoffenen Software dar. Z. B. ist es schlicht größenwahnsinnig, nicht wahrzunehmen, daß der Linux-Kernel noch Skalierungsdefizite aufweist und in dieser Hinsicht weit hinter den führenden kommerziellen Unix-Systemen wie Solaris und ein wenig auch hinter NT zurückbleibt. [DHBrown1999, Schmidt1999] Sun mußte einige Jahre hart und konzentriert arbeiten, um die heutige SMP-Skalierbarkeit von Solaris zu erzielen. Manche Aufgaben verlangen wohl doch einen strukturierten Ansatz.

Auch der von Raymond propagierte Glaube, daß allein schon die Zahl der Augen, die sich auf den Quellcode eines Programms richteten, eine Gewähr für dessen Korrektheit darstelle, ist gefährlich; zumal man sich nicht sicher sein kann, wieviele das im Einzelfall tatsächlich sind: Korrektheit besteht nur relativ zu einer Spezifikation und wenn die unvollständig oder gar widersprüchlich, vielleicht auch nicht hinreichend bekannt ist, dann nützen noch so viele Augen nichts! Die durchgängige Konformität mit umfangreichen, vorgegebenen Spezifikationen wie z. B. Posix stellt bisher nicht gerade eine Stärke von Linux dar [Eißfeldt/Helsch1996]. Auch dies erfordert einen strukturierten und zentralisierten Ansatz mit klaren Verantwortlichkeiten. Die Offenheit des Quellcodes ist politisch wünschenswert und bietet technisch wie ökonomisch viele Vorteile. Sie kann dazu beitragen, die Sicherheit und Korrektheit von Software zu erhöhen. Doch sie ist dazu weder hinreichend noch notwendig.

Doch es passen nicht alle quellenoffenen Produkte in das Schema, das Raymond zum Paradigma erklärt: TeX und Metafont z. B. waren zu ihrer Entstehungszeit tatsächlich innovativ, verlangten jedoch auch Spezialwissen, das nicht zur Informatikausbildung gehört. Sie sind Musterbeispiele nützlicher, ressourcensparender, wohldokumentierter und außerordentlich robuster Software. Doch sie stellen ihrer Genesis nach in Raymonds Terminologie eben »Kathedralen« aus der Hand eines Meisterarchitekten dar. Der Kathedrale kommt die Rolle des Gegenbildes zum Bazar zu; wobei allerdings die realen Kathedralen praktisch nie auf einen einheitlichen, umfassenden Plan aus einer Hand zurückgehen. Die Bauwerke entwickelten sich meistens über Jahrzehnte oder gar Jahrhunderte in wechselnden Händen unter dem Einfluß von Ad-hoc-Entwürfen und öfters auch mißlingenden Experimenten. Sich das Wissen anzueignen, dessen es bedarf, um eine stimmige Metaphorik hervorzubringen, scheint Raymonds Sache nicht zu sein. Doch wie auch immer: TeX, Metafont und viele GNU-Produkte sind das Ergebnis geplanten, systematischen Handelns und beziehen daraus viel von ihrer Qualität.

Das einzige, was von Raymonds Modell übrigbleiben könnte, wäre eine schlichte Rezeptur zu der Aufgabe: Wie nutze ich die Kooperationsbereitschaft und Begeisterungsfähigkeit von Tausenden von Entwicklern zu beliebigen, auch kommerziellen Zwecken aus. Ob so unbedingt die nützlichsten Produkte zustande kommen, ist fraglich. Es könnte jedoch auch sein, daß die Motivation der Entwickler sich im gleichen Maße als erschöpflich herausstellen wird, in dem sich jener Hintergdanke in den Vordergrund drängt. Das wäre vielleicht das Ende einer vielversprchenden Bewegung. Die Schwierigkeiten, mit denen Netscapes Mozilla und ähnliche Projekte kämpfen, geben darauf einen Hinweis.

Das Internet eröffnet tatsächlich eine neue Dimension der Softwareentwicklung. Es ermöglicht es, verstreute Kräfte, die für sich allein unbedeutend blieben, zu bündeln. Doch das Internet ist kein unerschöpflicher Quell. Es vermittelt nur zwischen den sonst fragmentierten, endlichen Kräften, um die auch andere Nachfrager konkurrieren. Die Diffusion des Internet ermöglichte und verstärkte den Aufschwung offener Softwareprojekte in den letzten Jahren. Doch das ist kein irreversibler Prozeß. Selbst Raymond macht in seinem letzten Text widersprüchliche Aussagen zur Verfügbarkeit von Personalressourcen. [Raymond1999]

Gefordert ist Einsicht in die Vielfalt möglicher Motivationen. Die Frage, wie egoistisch oder altruistisch Menschen tatsächlich handeln, kann man dahingestellt sein lassen. Sicher kann man in jedes noch so altruistischen Handeln eine egoistische Logik hineinkonstruieren, doch genau deshalb ist Raymonds These vom universalen Egoismus empirisch gehaltlos. Aus ihr ergibt sich keine Prognose des konkreten Verhaltens, vor allem nicht, daß Programmierer zwanghaft dem Reputationsspiel in seiner Auslegung folgen müssen. Realistischerweise wird man davon ausgehen müssen, daß manche Absolventen, die sich in offenen Projekten hervorgetan haben, sich der Attraktion eines Schecks und eines Aktienpakets nicht entziehen und in Zukunft Reputation Reputation sein lassen werden. Doch warum sollten andere nicht tatsächlich das machen, was Freude macht und sozialen Nutzen verspricht? Und warum, um noch einmal eine altlinke Idee hervorzukramen, nicht in Erwägung ziehen, daß die Gesellschaft solche Tätigkeit auch materiell belohnen könnte, um die Projekte zu stabilisieren, die für sie wichtig sind?

Quellen

Bollier1999
David Bollier: The Power of Openness: Why Citizens, Education, Government and Business Should Care About the Coming Revolution in Open Source Code Software. Cambridge, MA: Berkman Center for Internet and Society, 1999 <http://www.opencode.org/h2o/>
Brooks1995
Frederick P. Brooks: The Mythical Man-Month: Essays on Software Engineering. 2. Aufl., Reading, MA: Addison-Wesley, 1995.
Carrol/Teece1999
Glenn R. Carrol, David J. Teece: Firms, Markets, and Hierarchies: The Transaction Cost Economics Perspective. Oxford: Oxford University Press, 1999.
DHBrown1999
D. H. Brown Associates, Inc.: Linux: How Good Is It? Port Chester, NY, 1999
DiBona/Ockman/Stone1999
Chris DiBona, Sam Ockman, Mark Stone (Hrsg.): Open Sources: Voices from the Open Source Revolution. Sebastopol, CA: O'Reilly, 1999 <http://www.oreilly.com/catalog/opensources/book/toc.html>
Eißfeldt/Helsch1996
Heiko Eißfeldt, Rüdiger Helsch: »Feinschliff: Linux zertifizieren«, iX, August 1996, 88–91.
Fischbach1998
Rainer Fischbach: »Der Mythos des 21. Jahrhunderts? Vom Krieg der Sterne zum Cyberspace«, Blätter für deutsche und internationale Politik, Juni 1998, 677–685.
Fritsch/Wein/Ewers1996
Michael Fritsch, Thomas Wein, Hans-jürgen Ewers: Marktversagen und Wirtschaftspolitik: Mikroökonomische Grundlagen staatlichen Handelns. 2. Aufl., München: Vahlen, 1996 (Vahlens Handbücher der Wirtschafts- und Sozialwissenschaften).
Lüthje1993
Boy Lüthje: Die Neuordnung der Telekommunikationsindustrie in den USA. Wiesbaden: Deutscher Universitäts-Verlag, 1993.
McKusick1999
Marshall Kirk McKusick: »Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable«. [DiBona/Ockman/Stone1999, 31–46] <http://www.oreilly.com/catalog/opensources/book/kirkmck.html>
Norberg/Neill/Freedman1996
Arthur L. Norberg, Judy E. O'Neill, Kerry J. Freedman: Transforming Computer Technology: Information Processesing for the Pentagon, 1962-1986. Baltimore, MD: Johns Hopkins University Press, 1996.
O'Reilly1998
Tim O'Reilly: »The Open-Source Revolution«. Release 1.0, Novmber 1998 <http://www.edventure.com/release1/1198.html>
Raymond1998a
Eric S. Raymond: The Cathedral and the Bazaar. November 1998. <http://www.tuxedo.org/—esr/writings/cathedral-bazaar/>
Raymond1998b
Eric S. Raymond: Homesteading the Noosphere. April 1998. <http://www.tuxedo.org/~esr/writings/homesteading/>
Raymond1999
Eric S. Raymond: The Magic Cauldron. Juni 1999. <http://www.tuxedo.org/~esr/writings/magic-cauldron/>
Salus1994
Peter H. Salus: A Quarter Century of Unix. Reading, MA: Addison-Wesley, 1994.
Schmidt1999
Jürgen Schmidt: »Gemischtes Doppel: Linux und NT als Web-Server im Test«, c't, Nr. 13, 21. Juni 1999, 186–191.
Stallman1992
Richard Stallman: Why Software Should Be Free. April 1992. <http://www.gnu.org/philosophy/shouldbefree.html>
Stallman1994
Richard Stallman: Why Software Should Not Have Owners. 1994. <http://www.gnu.org/philosophy/why-free.html>
Stallman1999
Richard Stallman: »The GNU Operating System and the Free Software Movement«. [DiBona/Ockman/Stone1999, 53–70] <http://www.oreilly.com/catalog/opensources/book/stallman.html>
Stoltz1999
Mitch Stoltz: The Case for Government Promotion of Open Source Software. San Francisco, CA: NetAction, 1999<http://www.netaction.org/opensrc/oss-report.html>
Teilhard1959
Pierre Teilhard de Chardin: Der Mensch im Kosmos. München: Beck, 1959.