Offene Wissensökonomie

Gerd Sebald Offene Wissensökonomie Gerd Sebald Offene Wissensökonomie Analysen zur Wissenssoziologie der Free/Open S...

Author: Gerd Sebald

10 downloads 627 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Gerd Sebald Offene Wissensökonomie

Gerd Sebald

Offene Wissensökonomie Analysen zur Wissenssoziologie der Free/Open SourceSoftwareentwicklung

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Zugl.: Dissertation an der Friedrich-Alexander-Universität Erlangen-Nürnberg 2007

. 1. Auflage 2008 Alle Rechte vorbehalten © VS Verlag für Sozialwissenschaften | GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Monika Mülhausen / Marianne Schultheis Der VS Verlag für Sozialwissenschaften ist ein Unternehmen von Springer Science+Business Media. www.vs-verlag.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: Krips b.v., Meppel Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in the Netherlands ISBN 978-3-531-15705-4

Inhaltsverzeichnis

1

Rahmungen

13

2 Zur Theorie der technischen Grundlagen 2.1 Software in der Produktion, Distribution und Anwendung 2.2 Schrift und Formalisierung . . . . . . . . . . . . . . . . . 2.3 Medientheorie und computerbasierte Medien . . . . . . . 3 Diskurs 3.1 Auswahl und Methode . . . . . . . . . . 3.2 Zurück ins Paradies . . . . . . . . . . . . 3.2.1 Give it away free . . . . . . . . . . . . 3.2.2 Die goldene Regel . . . . . . . . . . . 3.2.3 Lizenzfragen . . . . . . . . . . . . . . 3.2.4 Gesellschaftliche Bezüge . . . . . . . . 3.2.5 Zusammenfassung . . . . . . . . . . . 3.3 Die neutrale Technik . . . . . . . . . . . 3.3.1 Die Anfänge eines Produktionsmodells 3.3.2 Just a hobby . . . . . . . . . . . . . . 3.3.3 Formales . . . . . . . . . . . . . . . . 3.3.4 Just technology . . . . . . . . . . . . . 3.4 Hin zum Neoliberalismus . . . . . . . . 3.4.1 Auf dem Bazar . . . . . . . . . . . . . 3.4.2 »Hallo, Open Source« . . . . . . . . . 3.4.3 Voices from the Revolution . . . . . . 3.4.4 Zusammenfassung . . . . . . . . . . . 3.5 Semantiklinien im Diskurs . . . . . . . . 4

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

Kommunikative und produktive Strukturierungen

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

25 26 38 47 59 60 63 64 69 75 77 83 84 84 86 94 98 105 106 110 114 119 120 123

6

Inhaltsverzeichnis

4.1 Kommunikationen . . . . . . . . . . . . . . 4.1.1 Sprache . . . . . . . . . . . . . . . . . . . 4.1.2 Technische Medien der Kommunikation . 4.1.3 Kommunikative Besonderheiten . . . . . . 4.1.4 Vom »Codeerzeuger« zum »Menschen« . . 4.2 Strukturierungen durch Produktion . . . . . 4.2.1 Technische Bedingungen der Produktion . 4.2.2 Eintrittsschwellen . . . . . . . . . . . . . 4.2.3 Produktionsprozesse . . . . . . . . . . . . 4.2.4 Kurze Typologie der Organisationsformen 4.3 Strukturierungen – Zusammenfassung . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

124 124 126 130 144 149 149 153 159 167 176

5 Ökonomie 5.1 Win - Win? . . . . . . . . . . . . . . . . . 5.2 Kapitalismus und F/OSS . . . . . . . . . . 5.2.1 Eine rein technische Entscheidung? . . . 5.2.2 OSDL . . . . . . . . . . . . . . . . . . . 5.2.3 Ein F/OS-Unternehmen . . . . . . . . . 5.2.4 Eingriffsmöglichkeiten für Unternehmen 5.3 Reperkussionen in der Ökonomie . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

179 180 183 183 189 196 201 202

6 Offene Wissensökonomie 6.1 Software als Ware? . . . . . . . 6.2 Geistiges Eigentum und Wissen 6.3 Jenseits der Tauschbeziehung . . 6.4 Finis opera . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

211 212 217 226 236

Literaturverzeichnis

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

241

Glossar API

Application Programming Interface, Schnittstelle zwischen Computerprogrammen

BSD

Berkeley Software Distribution, von der University of Berkeley, Ca., entwickeltes und distribuiertes Unixbetriebs- und Softwaresystem mit einer eigenen Lizenz

bug

»Wanze«, Fehler in einem Computerprogramm

bugreport

Fehlerbericht an die Programmierenden

Buildtools

Werkzeuge zur Vorbereitung, Unterstützung und Organisation der Kompilierung von Software

CC

Carbon Copy, Kopie einer elektronischen Nachricht an weitere Empfänger

Compiler

Programm zur Übersetzung von Quelltext in maschinenlesbaren Code (Binärtext)

CSS

Content Scrambling System, ein schnell geknacktes Verschlüsselungssystem für digitale Datenträger, das aufgrund der durch die Musikindustrie angestrengten Klagen wegen des damals in den USA neuen DMCA einige Berühmtheit erlangte

cvs

current version system, Software zum Verwalten der Änderungen in Dateien und Verzeichnissen

Distribution

die Zusammenstellung und Abstimmung der vielen quelloffenen Softwarekomponenten zu einem relativ einfach zu installierendem und zu benutzendem Gesamtsystem, meist basierend auf dem Betriebssystem Linux

8

Glossar

DMCA

Digital Millenium Copyright Act, 1999 erlassene wesentliche Verschärfung des amerikanischen Urheberrechts

DRM

Digital Rights Management, technische Absicherung des Urheberrechts

embedded system nicht eigenständiger Rechner, sondern in ein anderes Gerät zur Steuerung oder Kontrolle eingebauter, ›unsichtbares‹ Computersystem F/OS

Free/Open Source, die beiden zentralen Bezeichnungen für das in dieser Arbeit zu untersuchende Phänomen. Aufgrund der Gegensätzlichkeit und des Fehlens eines neutralen Begriffes werden beide zusammen in diesem Akronym verwendet.

F/OSS

Free/Open Source-Softwareentwicklung

FAQ

Frequently Asked Questions, gebräuchliche Form der Dokumentation fur Software, in der die am häuﬁgsten gestellten Fragen zum Programm, meist thematisch sortiert, beantwortet aufgelistet werden.

ﬂame

hochemotionalisierte, wutentbrannte E-Mail

fork

Aufspaltung eines F/OS-Projektes in zwei parallel weiterzuentwickelnde Projekte

ftp

ﬁle transfer protocol, Technik zur Übertragung von Daten in Dateiform

GNU

Gnu’s Not Unix, rekursives Akronym zur Bezeichnung des Softwaresystems der Free Software Foundation

GPL

General Public License der Free Software Foundation, eine der wichtigsten Lizenzen im F/OSSBereich

Glossar

9

Hacker

Programmierenthusiast. Person, die leidenschaftlich gerne Software schreibt

HOWTO

weit verbreitete Form der Dokumentation in F/OSProjekten

IRC

Internet Relay Chat, fast synchrone schriftliche Kommunikationsform im Internet

kompilieren

Umsetzen des Quelltextes einer Computersprache in ein »maschinenlesbares« und ausführbares Programm

Lurker

rein passive Teilnehmende an interaktiven elektronischen Diskussionsforen

Maintainer

Instandhalter, eine Art Moderator oder Leiter eines F/OS-Projektes

Netiquette

Sammlung von allgemeinen Verhaltensregeln in der elektronischen Kommunikation

OSDL

Open Source Development Labs, Zusammenschluß verschiedener IT-Firmen, um die Entwicklung der F/OS-Software voranzutreiben

Patch

kurzes Codebruchstück zur Behebung eines Fehlers im Programm

Portierung

Übertragung eines Programmes in andere Hardware- oder Softwarekontexte

RTFM

Read The Fine Manual. Gebräuchlicher Hinweis an Fragestellende, wenn eine schriftliche Dokumentation existiert

SCO

Computerﬁrma, die ein Unix-Betriebssystem anbietet, kurzzeitig mit dem Linuxanbieter Caldera verschmolzen war und seit 2003 per Gerichtsverfahren feststellen lassen will, daß Teile des Linuxcodes aus dem urheberrechtsgeschützten Unixquellcode übernommen wurden

10

Glossar

Spam

unerwünschte Massenwerbesendungen per E-Mail

thread

thematisch zusammenhängende Diskussion in elektronischen Medien

TPM

Trusted Platform Module, Mikrochip zur Kontrolle sicherheitsrelevanter Daten

Vorwort Eine Arbeit wie die vorliegende verdankt ihre Entstehung nicht der solitären Leistung eines Autors, sondern kann nur vor dem Horizont einer größeren Zahl von Menschen und Institutionen gelingen. An erster Stelle denke ich dabei an die Kolleginnen und Kollegen vom Institut für Soziologie der Friedrich-Alexander-Universität Erlangen-Nürnberg. Ohne die vielfältigen Anregungen in Diskussionen und Lehrveranstaltungen wäre dieses Projekt nie begonnen worden. Besonders Jan Weyand hat das Projekt von Anbeginn an mit konstruktiver Kritik begleitet und allzu forsche Interpretationen und Formulierungen korrigiert. Die Diskussionen mit Ulrich Wenzel und Joachim Renn haben, nicht zuletzt durch das Niveau, das sie erreichten, Problemstellung und Ausarbeitung wesentlich feinkörniger gemacht. Ilja Srubar schließlich hat als Betreuer dieses ihm eher fernliegende Thema akzeptiert und nach Kräften unterstützt. Der NIE-Kreis hat durch sein unentwegtes thematischer Mäandern und den in ihm schlummernden hermeneutischen Talenten dafür gesorgt, daß der Horizont des Textes immer offen blieb und die Interpretationen keine solipsistischen Veranstaltungen blieben. Für anregende Diskussionen zur Theorie der Software und des Wertes danke ich außerdem Fritz, Norbert, Fritjof, Karl-Heinz, Hans und Theo. Zu danken ist in materieller Hinsicht ist der Heinrich-Böll-Stiftung, für die Förderung von Oktober 2002 bis Februar 2006. Besonders Jutta Helm hat Geduld und Nachsicht mit einem säumigen Familienvater bewiesen. Und schließlich möchte ich meiner Frau, Susanne Ettlinger und den Kindern Johannes, Aron und Dorian danken, die eine schier unendliche Geduld mit dem Mann & Vater im Arbeitszimmer hatten. Dank gilt nicht zuletzt den unzähligen Programmierern, die durch ihr Engagement und ihre Arbeit die Software geschaffen mit deren Hilfe diese Arbeit entstand und vor allem den acht Entwicklern, die mir durch ihre Interviews den Weg in eine faszinierende Welt wiesen.

1 Rahmungen Der wissenschaftliche Mensch ist heute eine ganz unvermeidliche Sache: man kann nicht, nicht wissen wollen. Und zu keiner Zeit ist der Unterschied zwischen der Erfahrung eines Fachmanns und der eines Laien so groß gewesen wie in der jetzigen. (Robert Musil1 )

Aus der Sicht der Wissenssoziologie zeigt sich die Differenzierung von Gesellschaften in sozial unterschiedlich verteilten, immer weiter spezialisierten Wissensvorräten. Mit fortschreitender Differenzierung werden immer größere Anteile der gesamtgesellschaftlichen Wissensvorräte nur noch für spezialisierte Akteure relevant, für Experten. Dieser Differenzierungsprozeß treibt gleichzeitig die Prozesse der Wissensproduktion immer weiter an: »Die Fachleute werden niemals fertig. Nicht nur sind sie heute unfertig; sondern sie vermögen sich die Vollendung ihrer Tätigkeit überhaupt nicht auszudenken«, so Musil in der Fortsetzung des obigen Zitats. Parallel zu diesem potentiell unabschließbaren Prozeß der Wissensproduktion unterliegen seit dem Beginn der Moderne wachsende Bereiche des gesellschaftlichen Wissens ökonomischen Verwertungsinteressen. Beide Prozesse scheinen sich mit der Verbreitung der elektronischen Medien zu beschleunigen.2 Als Indikator für die Bedeutung dieser Prozesse in der Gegenwart mag die Entwicklung der These von der Genese einer neuen Gesellschaftsform gelten: der Wissensgesellschaft, deren vorzüglichstes Kennzeichen, zusätzlich zu einer Ausweitung der Wissensvorräte insgesamt, die Integration des Wissens in die 1 2

Musil 1978: Band I, S. 214 f. Vgl. zu dieser Beschleunigung aus einer Position der Kulturkritik stellvertretend Rosa 2005.

14

1 Rahmungen

ökonomische Produktion als eigenständiger Produktionsfaktor neben den herkömmlichen Faktoren Arbeit, Boden und Kapital sein soll.3 Eine historisch fundiertere Betrachtung legt eine andere Sichtweise nahe: Wissen war immer elementarer Bestandteil der Warenproduktion (Marx 1979; Giesecke 1991; Burke 2002). Neu erscheint aus dieser Perspektive nur die Ausweitung der Verwertungsansprüche auf weitere Bereiche des Wissens und vor allem die zunehmende Entkopplung von Wissen und materiellen Wissensträgern, wie sie durch die Digitalisierung für den Bereich des explizierten Wissens in bisher beispielloser Form erfolgt. Diese Entkopplung erschwert die seit der frühen Neuzeit gängige Praxis, Wissen in Warenform zu bringen, etwa als Buch oder etwas später als Patent, und auf diese Weise zu verwerten. Auch wenn die Debatte um Etikette wie »Wissensgesellschaft«, »Informationsgesellschaft« oder »mode 2« der Wissensproduktion (wenn nicht gar der Gesellschaft insgesamt) einen eigenen, eher müßigen Wissensvorrat für Spezialisten zu produzieren scheint4 , sind die zugrundeliegenden Prozesse, Strukturierungen und Auseinandersetzungen hochrelevant für eine Wissenssoziologie der Gegenwart. Daß dabei die maschinelle Symbolverarbeitung eine zentrale Rolle spielt, kann kaum überraschen. Gerade im Bereich der von vielen Autoren als grundlegend und die Entwicklung anstoßend beschriebenen vernetzten Computertechnologie öffnen sich viele neue Felder der gesellschaftlichen Dynamik, der Auseinandersetzung und nicht zuletzt der Wissensproduktion. Die digitale Rechner- und Vernetzungstechnologie als eine Technologie der Kontrolle durch Symbolverarbeitung (Beniger 1986; Schmiede 1996; Winkler 2004) hat die Strukturen der Gesellschaft und der gesellschaftlichen Wissensvorräte verändert und wird sie weiterhin in einem noch nicht absehbaren Maße verändern. Denn, um mit Luhmann zu schreiben, mit der Verwendung von Computern in der Kommunikation wird auch die Sachdimension des Sinns in die Entkopplung von Mitteilung und Verstehen einbezogen. Trends, die soziale Verän3

4

Vgl. dazu etwa Stehr 2001; Willke 1998; 2001; 2002; Gibbons et al. 1994; Nowotny et al. 2001; Drucker 1993 und für eine kritische Perspektive Bischoff 2001; Bechtle 2003; Srubar 2006; Tänzler et al. 2006. Wenn von dem bisher verwertungsintensiven Sonderdiskurs zum »Wissensmanagement« einmal abgesehen wird.

15 derungen in der »Ordnung des Wissens« (Luhmann 1997: 310), besser: den Ordnungen des Wissens, anzeigen, lassen sich vielleicht am ehesten im technologischen Kernbereich dieser Modernisierungsprozesse beobachten, in einer Form von Frühstadium.5 Anders formuliert: die Variationspotentiale einer Technologie, und damit die von sozialen Handlungsmöglichkeitenen, scheinen bereits bereits in den Prozessen der Produktion und Distribution der Technik auf. In einer Analyse dieser Variationspotentiale werden die in diesen Prozessen wirkenden Relevanzen wichtig, weil diese Selektionen wiederum die weitere Entwicklung und auch die Anwendungsprozesse der Technik präformieren können, nicht: determinieren. Es werden, das zeigen die Ergebnisse der Techniksoziologie, gewisse Handlungsrahmen gesetzt. Diese Handlungsrahmen decken sich aber keineswegs mit den Intentionen, Entwürfen oder Planungen der Produzenten, sondern sind in der Technik materialisiert und auf Dauer gestellt.6 Eine soziologische Untersuchung von Softwareproduktion setzt demnach zwar am technologischen Fundament der gesellschaftlichen Dynamik an, aber keineswegs am Fundament der Gesellschaft. Damit sollen und können aufgrund der komplexen und kontingenten Zusammenhänge und Wechselwirkungen zwischen unterschiedlichen Bereichen oder Feldern der Gesellschaft nicht mehr als Tendenzen in den »Ordnungen des Wissens« erfaßt werden. Im Bereich der Softwareproduktion ﬁndet sich seit etwa zwei Jahrzehnten ein auch aus soziologischer Perspektive wenig beachtetes, aber hochinteressantes Phänomen: die Free/Open Source-Softwareentwicklung (F/OSS).7 Das Leitprinzip der Free/Open Source-Softwareentwicklung ist die kooperative Entwicklung von Computerprogrammen durch das Veröffentlichen der Quellcodes im »Internet«, also der in einer Programmiersprache verfaßten, algorithmisierten ›Texte‹. Auf5 6 7

Das beinhaltet alle Unsicherheiten, die eine Beobachtung von Frühstadien mit sich bringt. Ein Diagnosehilfsprogramm kann durchaus zum Schreiben von Arztbriefen verwendet werden, aber eben nicht zum Kaffeekochen (Rammert et al. 1998). F/OSS steht im Folgenden »Free/Open Source-Softwareentwicklung«. »F/OS« steht dagegen für »Free/Open Source«. Für die Erklärung der Begrifﬂichkeiten vgl. Kapitel 3. Der Begriff »libre software«, der für dieses Phänomen häuﬁger in Europa verwendet wird, spielt für die Free/Open Source-Entwickler selbst kaum eine Rolle, weshalb er im Weiteren unberücksichtigt bleibt.

16

1 Rahmungen

grund der über öffentliche und anonym zugängliche Server verteilten Quellcodes ist eine weltweit Distribution und damit auch eine verteilte Weiterbearbeitung dieser Programme möglich. Programmierende holen sich den Quellcode von einem solchen Server, kompilieren ihn, das heißt: machen ihn maschinenlesbar, testen ihn auf ihrem Computer, und können bei Bedarf Änderungen am Quellcode vornehmen, etwa eine neue Funktion programmieren, einen Algorithmus verbessern oder einen Fehler beheben. Diese Änderungen werden über Mailinglisten den anderen Beteiligten mitgeteilt, und, wenn von der Projektleitung akzeptiert, wiederum in den Quellcodearchiven deponiert und sind so allen Interessierten verfügbar. Der an der Free/Open Source-Softwareentwicklung beteiligte Programmierer8 verrichtet die Arbeit und die dafür nötige Kommunikation im Normalfall alleine und in seiner Freizeit vor seinem Computer. Koordiniert wird die Entwicklung vor allem über Mailinglisten. Die Verfügbarkeit, Veränderbarkeit und freie Weitergabe der Quellcodes, und damit des geteilten Wissensvorrates, wird durch Lizenzen abgesichert.9 Mit dieser Form der Softwareproduktion ist es selbstbestimmt arbeitenden Programmiern gelungen, sich gegen die Verwertungsinteressen einer funktionierenden, kapitalistisch organisierten Softwareindustrie zu behaupten und ihren für diese spezialisierte Form der Produktion notwendigen Wissensvorrat für sich frei verfügbar zu halten. Sie entziehen ihren kollektiven Wissensvorrat der Logik der direkten Ver8

9

Aus einem meines Wissens bisher nicht untersuchten Grund sind in der F/OSS fast ausschließlich Männer tätig, laut den bisher vorliegenden Untersuchungen (vgl. etwa Lakhani et al. 2002; Ghosh 2005: 30) mehr als 98 %. Da es mir nicht gelungen ist, eine oder mehrere beteiligte Frauen zu diesem Thema zu interviewen, habe ich die Auswertung des von mir zu diesem Themenkomplex gesammelten Materials auf einen späteren Zeitpunkt verschoben. Im weiteren Text wird für die Bezeichnungen der Entwickelnden deshalb meist die männliche Form verwendet, um diese krassen geschlechtsbezogenen Beteiligungsunterschiede zum Ausdruck zu bringen. Die F/OSS hat in den Sozialwissenschaften bisher erstaunlich wenig Beachtung gefunden. Federführend in der wissenschaftlichen Analyse dieser Zusammenhänge sind vor allem die Ökonomie und die Rechtswissenschaften. Soziologische Analysen liegen bisher recht wenige vor. Zu nennen sind dazu bisher vor allem die Artikel von Holtgrewe (2000); Holtgrewe und Werle (2001); Holtgrewe (2004), und die Veröffentlichungen aus dem »Project Electronic Labour Markets« (http://www.soz. uni-frankfurt.de/arbeitslehre/pelm.html). Soweit diese Arbeiten für meine Fragestellung relevant sind, wird an gegebener Stelle darauf eingegangen.

17 wertung (durch Lizenzgebühren). Das in der Software, genauer: im Quellcode, explizierte Wissen bleibt offen und öffentlich potentiell für alle verfügbar. Damit ist die diese Arbeit strukturierende Problemstellung angerissen: Gefragt wird nach den Bedingungen der Möglichkeit einer solchen »offenen Wissensökonomie«, die in einem kapitalistischen Umfeld entsteht und sich stabilisiert, das eigentlich eine bedingungslose Verwertung nahelegt.10 Diese übergreifende Frage erheischt zu ihrer Beantwortung Speziﬁzierung in verschiedenen Hinsichten: In einem ersten Schritt werden deshalb die technischen Rahmenbedingungen, Software als Produktionsgegenstand und die Medien der elektronischen Schriftlichkeit als Kommunikationswerkzeuge, auf die damit gegebenen Wahrscheinlichkeiten und Unwahrscheinlichkeiten für eine medienbasierte kooperative Produktion von Software hin befragt.11 In einem zweiten und dritten Schritt gilt es dann, auf einer empirischen Ebene die konkrete Ausgestaltung dieses Rahmens durch die F/OSS-Entwickler zu untersuchen, sowohl auf der Seite der projektübergreifenden Selbstthematisierung, dem Diskurs der Entwickler, als auch in der konkreten Gestaltung der gesicherten Freiräume, um die trotz der Instabilität suggerierenden Ausgangsbedingungen erstaunliche zeitliche Stabilität der Projekte zu verstehen. In einem vierten Schritt steht das empirisch vorﬁndbare Verhältnis der F/OSS zur umgebenden kapitalistischen Ökonomie in Frage12 und die Formen der Ausgestaltung dieses Verhältnisses und der Veränderung und zwar auf beiden Seiten. Schließlich gilt es in einem letzten Schritt aus der Gegenüber10 Wohl vor allem aus dieser Diskrepanz speist sich die intensive, wissenschaftliche Beschäftigung aus ökonomischer Perspektive, die, neben der durch die ungewöhnliche Verwendung des Urheberrechtes induzierten juristischen, sicherlich den größten disziplinären Anteil der bisherigen Forschung ausmacht (Holtgrewe 2004). 11 Hier geht dieser Text einerseits mit Luhmann, der analytisches Interesse mit einer »phänomenologische[n] Reduktion« verfolgt (Luhmann 1984: 162), und dabei auf Theorien der Unwahrscheinlichkeit rekurriert. Der Begriff der Wahrscheinlichkeit verweist andererseits auf Webers Begriff der »Chance« (Weber 1972: 14) bzw. auf den der »objektiven Möglichkeiten« [266 ff.](GAzW), der mit Kellner und Heuberger (1988: 272) um die Kategorie der formalen und historischen objektiven Möglichkeit ergänzt werden soll. 12 Unter Kapitalismus soll hier und im Folgenden verstanden werden, das Streben nach Proﬁt durch die zweckrational organisierte, also der betrieblichen Herrschaft unterworfene, (formell) freie Arbeit, die benutzt wird, um für den Austausch zu produzieren. Diese Deﬁnition ist an Weber (1988: 4 ff.) angelehnt.

18

1 Rahmungen

stellung von kapitalistischer und offener Wissensökonomie anhand der Fomen des Eigentums und des Tausches heraus, Kennzeichen und Bausteine einer Ökonomie des Wissens zu gewinnen, und unter diesem Gesichtspunkt die empirischen Ergebnisse der »offenen Wissensökonomie« zusammenzufassen. Der Begriff »offene Wissensökonomie« soll im Folgenden für eine Form des ökonomischen Umgangs mit Wissen stehen, die auf einer lizenzgebührenfreien, öffentlichen Verfügbarkeit von (expliziertem) Wissen beruht. Insofern ist die F/OSS ein Teil, aber keineswegs die Gesamtheit dieser Form von Ökonomie. Die Suche nach Antworten auf diese Fragen muß dementsprechend auf verschiedenen Ebenen der Ordnungen des Wissens erfolgen: auf der Ebene des Produktionsgegenstandes Software und der medialen Produktionsmittel, auf der Ebene der Selbstthematisierung im die einzelnen Projekte übergreifenden Diskurs, auf der Ebene der Mikrostrukturen in den einzelnen Projekten, auf der Ebene des Verhältnisses zur kapitalistisch organisierten Softwareindustrie und schließlich auf der Ebene der Ökonomie des Wissens. Technische Ausgangsbedingungen und ihre soziologische Analyse Daß der Aufbau und Sicherung eines solchen kollektiven Wissensvorrats in Konkurrenz zur Softwareindustrie gelungen ist und weiterhin gelingt, wirft die Frage nach den besonderen Bedingungen dieses Wissens auf, also in einem ersten Schritt die Frage nach dem Gegenstand der Produktion und Distribution: der Software. Das erscheint aus einem soziologischen Blickwinkel keineswegs selbstverständlich. Technik nimmt in den zeitgenössischen soziologischen Theorien einen merkwürdig ambivalenten Status ein. Für die Systemtheorie etwa gelten technische Artefakte als der Umwelt der Gesellschaft zugehörig (vgl. etwa Esposito 1993). Für Latour (2000) oder Knorr Cetina (1998) ist demgegenüber die Trennung der Technik von der Gesellschaft ganz aufgehoben in hybriden oder kreolisierten Mischungen aus menschlichen Beziehungen und Objektbeziehungen. Aus der Perspektive der phänomenologischen Wissenssoziologie, wie sie von Alfred Schütz begründet wurde, ist weder der radikale Trennungsstrich zwischen sozialen und technischen Systemen, wie ihn etwa Luhmann (1984: 15 ff.) zieht noch die Aufhebung jeglicher Unterschiede zwischen technischen Operationen und sinnhaft handelnden

19 Personen angemessen (vgl. dazu Rammert 2006). Aus dieser Theorieperspektive, vor dem Hintergrund der »Strukturen der Lebenswelt« etwa, sind technische Objekte, als materielle oder symbolische Artefakte, ein selbstverständlicher Bestandteil alltäglicher Lebenswelten. Ihr Charakter als Produkte sinnhaften menschlichen Handelns macht sie zu Elementen sozialer Wirklichkeiten. Technik ist damit ein Konstitutionselement der sozialen Welt. Auf der anderen Seite kann mit dieser Theorierichtung die speziﬁsche Differenz von Technik und Gesellschaft betont werden: Technik wird so einerseits zur zweckgerichteten, schematisierten und iterierten Handlung (Berger und Luckmann 1998: 57) und andererseits zur Objektivation dieser Handlungsform. Marx’ Trennung des Begriffes der Arbeit (Marx 1979: 192 ff.) in lebendige und tote Arbeit bringt diese zwei Pole der Technik auf den Punkt. Technik als habitualisierter Vorgang erzielt Wirkung durch das Ausblenden von Sinnbezügen, Technik als anzuwendendes Artefakt dagegen durch das Einblenden in Sinnbezüge. Die These Husserls vom Verlust des lebensweltlichen Sinnes durch τέχνη‘13 erfaßt demnach nur einen Teil des technischen Prozesses: den des Verhältnisses von Anwendung und Produktion, das Hineinragen der materiellen Dauerhaftigkeit von Technik in die Lebenswelten. Die sozialen Prozesse der Produktion weisen natürlich ebenfalls Sinnstrukturen auf, die jedoch nicht in den formalisierten Iterationen aufgehen. Das heißt aber keineswegs, daß diese Sinnstrukturen aus soziologischer Sicht irrelevant werden. Solche Zusammenhänge werden erst in der Integration der technikund wissenssoziologischen Ansätze deutlich und nur so läßt sich meines Erachtens das Phänomen F/OSS adäquat fassen: der Fokus liegt dann auf den Sinnstrukturen, wie sie die Kommunikation prozessiert, auf den zugrundeliegenden Wissensstrukturen und den in materiellen oder symbolischen Artefakten objektivierten Sinn- und Wissenselementen. In der Verschränkung der beiden Ansätze treten die Veränderungen und Wechselwirkungen in den Prozessen der Produktion und Distribution dieses technologischen Wissens deutlich hervor. Nicht gemeint ist mit dem bisher Entwickelten, daß der Gegenstand, Software, diese Prozesse determinieren würde, sondern daß der Gegenstand gewisse 13

selbst ist »eine Entleerung, durch welche das kunstmäßig Gewordene nur noch einen verborgenen [. . .] Sinn beschließt.« (Husserl 1992: 202).

20

1 Rahmungen

objektive Möglichkeiten im Weberschen Sinne bietet, gewisse Rahmenbedingungen setzt, die für ein Verstehen dieser Prozesse wichtig sind. Entsprechend lautet eine der im Folgenden entwickelten Thesen in Bezug auf die F/OSS, daß diese vor allem medienbasierte Form der Kooperation, des Umgangs mit Wissen und Wissensvorräten, der offenen Wissensökonomie, mit anderen, weniger formalisierten Arbeitsgegenständen nicht oder nur unter Einschränkungen möglich ist. In einem ersten Schritt soll demnach in einer theoretischen Analyse nach den Kennzeichen und Eigenschaften dieses besonderen Werkstücks »Software« gefragt werden, nach den speziﬁschen Merkmalen, die eine solche, bisher einzigartige Form der global verteilten, freiwilligen und selbstbestimmten Kooperation wahrscheinlicher machen, nicht: notwendig hervorbringen. Diesen Besonderheiten gilt es in den Prozessen der Produktion, Distribution und Anwendung nachzuspüren. Des weiteren werden die dadurch gewonnenen Erkenntnisse anhand der Begriffe »binäre Logik«, »Schrift« und »Formalisierung« vertieft. Die zentrale These lautet, daß es vor allem die formalisierte Schriftlichkeit von Software ist, die eine Produktionsweise wie die der F/OSS erlaubt. In diesem Zusammenhang ist auch nach den medialen Bedingungen dieser vor allem auf elektronischen Kommunikationsmedien aufsetzenden Produktionszusammenhänge zu fragen (Kapitel 2). Damit ergibt sich ein Rahmen, aus dem heraus nach den Wahrscheinlichkeiten und Unwahrscheinlichkeiten einer Produktionsweise wie der F/OSS aufgrund der technischen Bedingungen, in denen sie sich ereignet, gefragt werden kann. Diskurs Wenn der Gegenstand der Produktion einen solchen Rahmen setzt, werden speziﬁsche Selektionen innerhalb dieses Rahmens pragmatisch ausgeführt und, nicht zuletzt in Form von Selbstthematisierungen, sinnhaft kommuniziert. Diese diskursiven Praktiken, die Foucault zufolge »systematisch die Gegenstände bilden, von denen sie sprechen« (Foucault 1995: 74), fügen sich zu symbolischen Ordnungen, Diskursen, zusammen und bilden die zweite Ebene der Untersuchung. Der projektübergreifende Diskurs der Entwickler ist eine Besonderheit, die die F/OSS von anderen sog. »virtuellen Gruppen« (Thiedecke 2000; Sebald 2005) unterscheidet. Um das Phänomen einzuordnen und grundsätz-

21 liche Elemente herauszuarbeiten, sollen in einem ersten empirischen Schritt anhand zentraler Texte dieser im Diskurs stattﬁndenden Selbstthematisierung gemeinsam geteilte Relevanzen und Grundstrukturen dieses diskursiv konstruierten »Gegenstandes« herausgearbeitet werden: der frei zugängliche Wissensvorrat und die Tätigkeit des selbstbestimmten Programmierens. Das sind die grundsätzlichen Bedingungen der F/OSS, die den Diskurs konstitutiv prägen und die diskursiv festgelegt werden. Der Diskurs der Entwickler ist dabei keineswegs monolithisch. Vor dem Hintergrund dieser zentralen Gemeinsamkeiten differenziert er sich in drei, zwar historisch unterschiedlich entstandene, aber gegenwärtig parallel nebeneinander existierende Semantiklinien. Die beziehen sich vor allem die Form der Legitimation und auf der Betonung speziﬁscher Elemente dieser Praxis. Während die Semantiklinie der Free Software Foundation (FSF) vor allem auf die Freiheit der Distribution des Wissens und der Software rekurriert und sogar Grundzüge eines alternativen Gesellschaftsmodells entwickelt, betont die Semantiklinie der ›neutralen Technik‹ (der quantitativen Untersuchungen zufolge die Mehrzahl der beteiligten Programmierer sich zugehörig fühlt) nur die selbstbestimmte Kooperation und Produktion auf Grundlage einer rein technischen Rationalität. Jeglicher über diese dem Gegenstand Software inhärenten formale Logik hinausgehende Bezug, etwa auf gesellschaftspolitische Fragen und Probleme, wird aus diesem Diskurs herausgehalten. Gegenüber diesen beiden Positionen hebt die neoliberale Open Source-Semantik, die vor allem von Firmen getragen wird (die ihr Geschäftsmodell auf der Verwertung von F/OS-Software aufgebaut haben), die bessere Qualität der F/OS-Software hervor. Diese komme vor allem wegen der an Marktstrukturen angepassten Produktionsweise zustande. Insgesamt konstituiert sich im Diskurs der Entwickler ein eigenständiges Segment der Wissensproduktion und grenzt es von anderen Formen ab. Damit wird eine neue Ordnung des Wissens gesetzt, eine offene Wissensökonomie (Kapitel 3). Mikrostrukturierungen Der Diskurs referiert auf einen vorhandenen Wissensvorrat und auf eine diesen produzierende Praxis von selbstbestimmt arbeitenden Programmierern. Diese Praxis ﬁndet in abertausenden unterschiedlich

22

1 Rahmungen

großer Projekte statt, von denen die größten global verteilt mehr als tausend Programmierer organisieren. Diese Projekte gruppieren sich um eine je speziﬁschen Problemstellung in der Softwareproduktion und bearbeiten diese weitgehend selbständig, allerdings mit Rückgriff auf den geteilten Wissensvorrat. Die Stabilität dieser Projekte als Referenten des Diskurses ist eine wesentliche Bedingung der offenen Wissensökonomie. Das synchrone und diachrone stabile Funktionieren solcher Projekte ist eigentlich unwahrscheinlich: zum einen ﬁndet sich eine relativ hohe Fluktuation, zum zweiten ist die Organisation von meist unbezahlten Freiwilligen erforderlich und schließlich basieren Kommunikationen und Produktion vor allem auf elektronischer Schriftlichkeit, das heißt, die Bildung von stabilisierenden persönlichen Beziehungen ist erschwert. Zusätzlich erschwert das Prinzip der Öffentlichkeit der Kommunikationen, das dem des frei zugänglichen Wissensvorrats korrespondiert, die kommunikative Koordination. Trotz dieser Hindernisse ﬁndet sich eine erstaunliche Anzahl an dauerhaften, oft auch schon mehr als zehn Jahre bestehender Projekte, die Software in auch von der Industrie mehr und mehr anerkannter Qualität produzieren. Deshalb werden in einem zweiten empirischen Schritt anhand der Analyse von qualitativen Interviews und archivierten Kommunikationen ethnographisch die sich in der alltäglichen Praxis reproduzierenden Strukturierungen von Kommunikation und Produktion nachgezeichnet. Das kann aufgrund der Vielzahl der Projekte nur typisierend erfolgen, weist aber auf wesentliche Strukturmuster: In den Projekten gelingt es, mit den Mechanismen der inhaltlichen Ausdifferenzierung der Kommunikationsinstrumente, der Entwicklung von Regelsystemen, der kommunikativen Schließung und vor allem durch die performativ-produktiven Akte der Programmierung die Diskussionen auf ein funktionales Maß einzugrenzen. Zusätzlich zeigt sich für die größeren und bereits längere Zeit währenden Projekte, daß face-toface-Treffen, etwa in Form von Konferenzen oder Workshops, ein wichtiges Element der kommunikativen Stabilisierung für die Projekte darstellen. Die sich in der Kommunikation herausbildenden Strukturierungen werden überlagert von solchen der Produktion, in denen vor allem durch Mechanismen der Homogenisierung (Aufnahmeprozeduren und

23 meritokratische Prinzipien) in der Zusammensetzung der Projektteams in Bezug auf Wissensvorrat und Stil sowie eine Akzeptanz der jeweils geltenden Regeln die Stabilität der Projekte erhöht wird. Wichtig ist für die dauerhafte Organisation von Freiwilligen auch in größeren Projekten zudem die Ausrichtung auf die möglichst weitgehende Selbstbestimmung in den jeweiligen Unterprojekten. (Kapitel 4) Ökonomie Das Erstaunlichste an der F/OSS ist meines Erachtens nach wie vor, daß diese offene Wissensökonomie sich gesellschaftlich etabliert hat, obwohl dieses Feld der Produktion von einer funktionierenden und ﬂorierenden kapitalistisch organisierten Ökonomie beackert wird. In dem ersten ökonomischen Kapitel gilt es, die Wechselwirkung der zwei als inkompatibel erscheinenden Ordnungen des Wissens, der offenen Wissensökonomie und der kapitalistischen Wissensökonomie, zu untersuchen. Das geschieht zum einen anhand eines konkreten Falles von Einﬂußnahme auf die Entwicklung durch Unternehmensinteressen, zum zweiten anhand des Verhältnisses von F/OS-Entwicklern zu den von Unternehmen getragenen »Open Source Development Labs« und schließlich anhand eines Unternehmens, das sein Geschäftsmodell auf die Verwertung von F/OS-Software (durch Dienstleistungen rund um diese Software) aufgebaut hat. In einem weiteren Schritt werden dann die Reperkussionen des Wissensmodells der F/OSS auf die kapitalistische Wissensökonomie anhand einiger weniger Beispiele untersucht. Dabei zeigt sich, zumindest in diesen Beispielen, eine Veränderung in Bezug auf den Umgang mit Wissen zum einen im kooperativen Verhältnis zu anderen Unternehmen und zum anderen im Bezug auf den Umgang mit Kunden. (Kapitel 5) Im abschließenden Kapitel ist dann auf einer theoretischen Ebene die leitende Frage die nach der mit der F/OSS gesetzten Veränderungen in den Ordnungen des Wissens. In einem ersten Schritt wird nach der ökonomischen Logik, die dem Gut »Software« innewohnt, gefragt. Hier ﬁnden sich meines Erachtens einige Speziﬁka von expliziertem Wissen im allgemeinen und Software im Speziellen, die dazu führt, daß deren Verwertung unter den gegenwärtigen Bedingungen der massenhaften Verbreitung von Digitalcomputern und deren Vernetzung auf Schwierigkeiten stößt. Die Schwierigkeiten beruhen vor allem auf der

24

1 Rahmungen

Übertragung eines Eigentumsbegriffs, der aus der materiellen Warenproduktion heraus entwickelt wurde und auf der Ausschließbarkeit von der Nutzung eines Gutes beruht, auf ein mit der vernetzten Digitalisierung ›ﬂüchtiger‹ werdendes Wissen. Software als digital expliziertes Wissen, damit erfolgt der Anschluß an Kapitel 2, lässt sich unter diesen Eigentumsbegriff nicht einfach subsumieren, sondern dafür sind zusätzliche rechtliche und staatlich abgesicherte Mechanismen notwendig, wenn der Warenstatus aufrechterhalten werden soll. Eigentum existiert demgegnüber in der F/OSS nur in einer grundsätzlich modiﬁzierten Form: nicht das Recht auf die Ausschließung von der Nutzung wird zentral, sondern das Recht zur Autorisierung einer zu verteilenden Version. Der zweite problematische Begriff in einer Wissensökonomie ist der des Tausches. Die Multiplikationsfähigkeit von Wissen (problemloses Weitergeben einer »Kopie« ohne den Verzicht auf die weitere Nutzung) macht die Anwendung des Tauschbegriffes nurmehr für explizit warenförmiges Wissen sinnvoll. Stattdessen wird vorgeschlagen, mit dem Begriff des Transfers zu operieren. Mit dem auf Autorisierung fokussierenden Eigentumsbegriff und dem Transferbegriff sind meines Erachtens zentrale Begrifﬂichkeiten der offenen Wissensökonomie, wie sie in der F/OSS praktiziert wird, entwickelt, deren empirisch entwickelte Kennzeichen in diesem Lichte resümiert werden (Kapitel 6).

2 Zur Theorie der technischen Grundlagen Que les nombres étant réduits aux plus simples principes, comme 0 & 1, il paroît par tout un ordre mervelleieux. (Gottfried Wilhelm Leibniz14 )

Zunächst werden die Konstitutionsbedingungen der medial basierten, kooperativen Produktionsform der F/OSS untersucht, und zwar anhand des Arbeitsgegenstandes, der Software. Die Formen der Softwareproduktion können denen der herkömmlichen Wissens- und Warenproduktion gleichen, etwa in wissenschaftlichen Instituten und Laboren oder privaten Unternehmen. Aber wenn die These stimmt, daß F/OSS eine speziﬁsch neue Form der produktiven Kooperation und (Selbst-)Organisation ist, die sich in anderen Bereichen so nicht entwickelt (hat), liegt die Vermutung nahe, daß spezielle Eigenschaften des produzierten ›Gegenstandes‹ diese neue Form der Produktion ermöglichen. Die leitende Frage für diesen Abschnitt ist jedoch nicht, inwiefern der Arbeitsgegenstand die Kooperationsform vorgibt, sondern welche Speziﬁka der Software die Wahrscheinlichkeiten für eine neue Kooperationsform erhöhen oder senken. Im Folgenden geht es also um die Analyse der speziﬁschen Eigenschaften von Software, die F/OSS ermöglichen und damit auch rahmen. Daran anschließend ist die Kommunikationsform, computerbasierte Medien, vor allem Mailinglisten und Internet Relay Chat (IRC), einer theoretischen Analyse zu unterziehen. Die Bedingungen der Konstitution der Produktionsform der F/OSS verstehe ich auch im Fall der medialen Grundlage als notwendige, nicht als hinreichende: Zum Arbeitsgegenstand Software und einer computerbasierten Kom14 »Wenn die Zahlen auf ihre einfachsten Prinzipien wie 0 und 1 reduziert werden, dann herrscht überall eine wunderbare Ordnung.« (Leibniz 1703)

26

2 Zur Theorie der technischen Grundlagen

munikation müssen noch weitere Bedingungen hinzutreten, damit sich eine neue Form der Produktion entwickelt. Das sind vor allem die praktische Aneignung dieser technisch gegebenen Möglichkeiten und die damit einhergehende Ausgestaltung der damit verbundenen Handlungsspielräume. In einem ersten Schritt werden deshalb die Prozesse der Produktion, Distribution und Anwendung von Software beschrieben und daraus erste Kennzeichen dieses symbolischen Artefaktes abgeleitet. Dabei wird auch die gesellschaftliche Einordnung der Softwareproduktion und ihre ökonomische Relevanz kurz diskutiert werden. In einem zweiten Schritt werden diese Ergebnisse durch eine genauere Analyse des Phänomens »Software« anhand der Begriffe Schrift und Formalisierung speziﬁziert. Schließlich werden aus medientheoretischer Perspektive die sich aus den verwendeten Medien ergebenden Probleme der Konstitution und Kooperation analysiert.

2.1 Software in der Produktion, Distribution und Anwendung Gängige Theoretisierungsversuche von Software greifen vor allem auf die Charakterisierung von Software als Wissen und Technik zurück. Software ist Wissen, »programmiertes Wissen, genauer: binär reduziertes Wissen« (Degele 2000: 55). Wissen, das expliziert und wiederholbar gemacht wird, sozusagen geronnenes Verfahrenswissen. Software ist in einem ersten Analyseschritt als ein Wissensprozeß zu fassen und wird als solcher im Folgenden in Hinsicht auf die Speziﬁka in Produktion, Distribution und Konsumtion bzw. Anwendung analysiert werden. Produktion Im Produktionsprozeß weist Software einige Besonderheiten auf. Im Folgenden werden die speziﬁsche Zeitlichkeit aufgrund der Symbolhaftigkeit, die Komplexität und Modularisierbarkeit, die Verschränkung der Prozesse von Produktion und Anwendung und schließlich der für die Produktion relativ geringe Material- und Energieaufwand einer genaueren Betrachtung unterzogen. Software ist erstens eine Form der Explikation von Wissen mit Hilfe von Computersprachen. Diese »Technisierung im Medium der Symbo-

2.1 Software in der Produktion, Distribution und Anwendung

27

le« (Rammert 1995: 16) hat zur Folge, daß das Produkt nicht verschleißt (Rammert 1998a: 317).15 Diese Verschleißfreiheit schafft eine speziﬁsche Zeitlichkeit von Software, die durch die Nichtgebundenheit an speziﬁsche Datenträger und die Gebundenheit an speziﬁsche Hardware zwei Faktoren von Kontingenz erhält. Diese Zeitlichkeit weist auf ein Merkmal von Software hin: die potentielle Unabschließbarkeit der Entwicklung. Die Entwicklung eines Programmes kann immer weiter geführt werden, sei es, daß es nur dem jeweils aktuellen Stand der Technik und vor allem der Hardware angepaßt wird oder daß immer neue Funktionen hinzugefügt werden.16 Der Akt der Programmierung steht aus der Logik des Materials heraus unter keinerlei zeitlicher Einschränkung. Software ist zweitens ein höchst komplexes symbolisches Produkt. Die Komplexität von Software hat, in Verbindung mit der Vielzahl möglicher Lösungen für ein Problem, den unterschiedlichen (und oft wachsenden) Anforderungen an ein Programm und der Fehleranfälligkeit durch diese Komplexität ebenfalls zur Folge, daß der Produktionsprozeß von Software potentiell unabschließbar ist. Es können immer wieder Fehler gefunden, Verbesserungen angebracht oder neue Funktionen implementiert werden. Die speziﬁsche Zeitlichkeit von Programmcode ﬁndet in der Komplexität ein weiteres Vehikel. Die Komplexität von Software hat auch zur Folge, daß nur einfachere Programme von einem einzelnen Programmierer geschrieben werden können, für größere Projekte ist beinahe zwingend17 eine Gruppe von Programmierern erforderlich, was wiederum speziﬁsche Formen der Kommunikation, Organisation und Arbeitsteilung erfordert.18 Softwareproduktion kann in den herkömmlichen Institutionen 15 Der von Marx beschriebene »moralische Verschleiß« (Marx 1979: 426 ff.) ﬁndet natürlich trotzdem statt, vor allem durch die Kopplung an Hardware und durch die rapide Entwicklung derselben. 16 Ein Beispiel ist etwa der mehr als dreißig Jahre alte Editor EMACS (mit dem auch die vorliegende Arbeit geschrieben wurde), der dank der inzwischen vielfältigen Erweiterungen zu einer Art Universalprogramm unter den Editorprogrammen geworden ist. 17 Von den mythischen und legendären Leistungen einzelner Genies wird hier abgesehen. So soll beispielsweise Seymour Cray ein komplettes Betriebssystem in Binärcode geschrieben und eingegeben haben (vgl. Lundstrom 1987). 18 Zur unaufhebbaren Komplexität der Software und der Softwareentwicklung und der

28

2 Zur Theorie der technischen Grundlagen

der kooperativen Wissens- und Warenproduktion, wissenschaftlichen Instituten oder privatwirtschaftlichen Unternehmen, erfolgen. Aber der Arbeitsgegenstand selbst erlaubt auch andere Modi der organisatorischen Bewältigung dieser Komplexität. Die Symbolhaftigkeit ermöglicht – zumindest auf Basis der Vernetzung von Computern – ein einfaches Versenden und Verteilen und damit parallele Entwicklung eines Programmes an verschiedenen Orten. Die formalisierten Symbolketten legen schon in der Entwurfsphase einen speziﬁschen Umgang mit der Komplexität nahe – eine weitgehende Modularisierung des Problems und damit des Programmes, so daß die Teilprobleme wieder auf kleinere, auch von Einzelnen überschaubare Aufgaben reduziert werden können (vgl. dazu Brooks 2001: Kapitel 4, 13). Eine Folge der oben beschriebenen Komplexität und Zeitlichkeit ist drittens die enge Verschränkung von Produktion und Anwendung, oder anders formuliert: der relativ hohe Aufwand an Dienstleistung, der mit dem Einsatz von Software verbunden ist: Software muß auf die Bedürfnisse der Anwendenden zugeschnitten werden, entweder damit der entsprechende Auftrag erfüllt wird oder damit sie sich verkauft. Sie erfordert zudem ständige Wartung (Fehlerbehebungen, Erweiterungen etc.) und aufgrund der Komplexität auch in der Anwendung sind Schulungen der Anwendenden vonnöten. Das scheint nicht für Standardsoftware wie etwa Ofﬁceprogramme zu gelten. Aber auch hier ﬁnden sich speziﬁsche Produktionskreisläufe, »Service Packs«, Fehlerbehebungen und Neuauﬂagen und nicht zuletzt auch Testläufe mit ausgewählten Kunden. Die Prozesse der Produktion, Distribution und Anwendung sind im Falle von Software also eng miteinander verschränkt und werden in iterativen Schleifen durchlaufen. Dieser Prozeß funktioniert meist unter mehr oder weniger intensiver Einbindung der Kunden. Deren ›Feedback‹ ist jedoch oft ungenau: »For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never thought of the problem in the detail that must be speciﬁed.« (Brooks 2001: 200) Genau an der Schnittstelle zwischen Produzent und Anwendern entstehen Übersetzungsprobleme, die den Produktionsprozeß damit verbundenen Schwierigkeiten vgl. generell Brooks (2001) und insbesondere den darin aufgenommenen, in der Informatik vieldiskutierten Aufsatz »No silver bullet« (Brooks 2001: 177 - 203).

2.1 Software in der Produktion, Distribution und Anwendung

29

mit zusätzlicher Komplexität aufladen. Brooks’ Feststellung läßt sich auch umkehren: Die Produzenten können nicht genau kommunizieren, was ihr Programm leisten kann. Ihr Programm passt nie genau in den Arbeitsablauf. Die Anforderungen der Praxis müssen so formuliert werden, daß sie algorithmisiert und in programmierbare Abläufe gepresst werden können. Und umgekehrt müssen die Algorithmen in die Praxis, in der sie wirken sollen, möglichst bedarfsgerecht eingepaßt werden.19 Um diese Übersetzungsprobleme zu minimieren, können in den Entwicklungsprozeß rekursive Schleifen zwischen Entwicklung und Anwendung eingebaut werden. Die Benutzbarkeit von Software in einem sehr frühen Stadium der Entwicklung (wenn die ersten rudimentären Funktionen implementiert sind) ermöglicht es, diese Schleifen zu einer dauerhaften Einrichtung zu machen, d. h. die (daran interessierten) Anwendenden permanent in die Entwicklung zu integrieren. Eine andere Möglichkeit des Umgangs mit diesem Problem ist die Externalisierung der Übersetzungs- und Anpassungsleistungen an spezialisierte Akteure, vor allem Dienstleistungsunternehmen. Diese Möglichkeit wird sowohl in der kommerziellen Softwareproduktion, als auch in der F/OSS genutzt. In letzterem Fall wird ein auf die Zusammenstellung, den Vertrieb und die Anpassung solcher Software spezialisiertes Unternehmen eingebunden.20 Software, als prozessiertes Wissen betrachtet, legt aufgrund der speziﬁschen Zeitlichkeit und der Komplexität stärker und in einem früheren Stadium als andere, materielle Produktionsprozesse die Einbindung der Anwendenden nahe. 19 Für standardisierte Software (etwa Ofﬁceanwendungen) ist dieser Prozeß auf Seiten der Produktion weniger problematisch, er funktioniert über Nutzerbilder (vgl. Hofmann 1997). Das produziert aber auf der Anwenderseite entsprechend einseitige Übersetzungsprobleme. Die vorgegebenen Handlungsmuster müssen übernommen und in den eigenen Arbeitsablauf integriert werden. 20 Diese Firmen haben für die selbstorganisierten Programmiererzusammenhänge jedoch eine gänzlich andere Bedeutung als Dienstleister für ein kommerzielles Softwarehaus: sie verfügen erstens über ein gewisses Maß an ökonomischen Mitteln und damit über Einﬂußmöglichkeiten auf die Produktion selber. Sie bündeln zweitens die Interessen ihrer zahlenden Kunden (vor allem anderer Unternehmen) und nehmen so eine Art Vermittlungsfunktion ein. Und schließlich beteiligen sie sich selbst an der Entwicklung, indem sie Kundenwünsche umsetzen und den daraus resultierenden Code (aufgrund der Lizenz) freigeben (müssen). Vgl. unten Abschnitt 5.2.3.

30

2 Zur Theorie der technischen Grundlagen

Viertens führt die rapide Entwicklung und Verbilligung der symbolverarbeitenden Maschinen dazu, daß die Produktionsmittel für Software so billig und wenig energieaufwendig sind wie bei kaum einem anderen Produkt. Gleichzeitig ermöglicht die vergleichsweise ebenfalls preiswerte Vernetzungstechnologie eine relativ energiearme und kostengünstige Verbreitung dieser Produkte. Diese niedrigen ökonomischen Voraussetzungen ermöglichen eine sehr viel experimentellere Form der Produktion: Fehlschläge oder weniger erfolgreiche Versuche bringen insofern keine gravierenden ökonomischen Kosten mit sich. Zusammen mit der Offenheit des Quellcodes von vielen unterschiedlichen Projekten (was die Verwendung von Code in einem anderen Projekt erlaubt, sofern die Lizenzbedingungen beachtet werden) ermöglicht dies eine spezielle Art der kollektiven, intellektuellen »bricolage« (Lévi-Strauss 1997: 29 und passim)21 , des Ausprobierens, des versuchsweisen Kombinierens, des Improvisierens. Unter diesen Bedingungen ist die Voraussetzung für die Produktion der Software vor allem Wissen, »Computeralphabetisierung« (Kittler 1996). Die relative Unabhängigkeit von kostenintensiven Produktionsanlagen und einer materiellen ›Realisierung‹ sowie der für Produktion, Distribution und Anwendung relativ niedrige Energieaufwand machen Software trotz der Komplexität zu einem leicht zu verbreitenden und leicht anzuwendenden Arbeitsprodukt. Damit ist die Produktion von Software nicht an die aufwendige Konzentration von Produktionsmitteln und Ressourcen angewiesen, wie sie für herkömmliche Waren- und Wissensproduktion typisch ist. Zwar könnte auch der Bauplan eines Automobils in der F/OS-Arbeitsweise und mit Integration der Benutzer entwickelt werden22 , aber nach der Entwicklung ist ein material- und energieaufwendiger »realer« Produktionsprozeß nötig, um die Technik benutzen zu können. Software dagegen kann nach dem Laden aus dem Netz und der Installation ohne zusätzlichen materiellen Aufwand direkt benutzt 21 Dabei sind die Bestimmungen dieses Begriffs bei Lévi-Strauss sehr nah an der handwerklichen Tätigkeit oder einer materiellen Technik orientiert: der Bastler werkelt mit seinen Händen und verwendet Mittel, »die im Vergleich zu denen des Fachmanns abwegig sind.« (ebd.) Dieser Teil der Begriffsbestimmung ist für die die symbolischen Tätigkeiten der F/OSS nicht zu gebrauchen. 22 Das wurde und wird auch praktiziert vgl. Honsig (2006) und die Webpage http: //www.theoscarproject.org.

2.1 Software in der Produktion, Distribution und Anwendung

31

werden. Das ermöglicht eine verteilte Produktion und die Einbindung der Anwendenden in den Produktions- und Distributionsprozeß. Aufgrund der Verbreitung der Computertechnologie ergibt sich damit eine potentiell große, durch die Unterschiede im Wissensstand differenzierte Basis von Anwendenden und Programmierern. Durch diese Eigenschaften des Produktionsprozesses von Software, die speziﬁsche Zeitlichkeit, die Komplexität und Modularisierbarkeit, die Verschränkung von Produktion und Anwendung und schließlich der relativ niedrige materielle und energetische Aufwand steigen die Chancen für die Etablierung einer neuen Praxis neben der Organisation der Softwareproduktion in kapitalistischen Unternehmen oder staatlichen Institutionen. Distribution In einem zweiten Schritt wird Software in Bezug auf den Distributionsprozeß analysiert. Dabei ist für die kommerzielle Distribution vor allem die Schwierigkeit interessant, Nutzungs- und Ausschlußbefugnisse an Wissen und damit auch an Software durchzusetzen, also Software in Warenform zu bringen. Die Frage des Eigentums und der Durchsetzung von Eigentumsansprüchen steht hier zur Debatte. Diese Durchsetzung ist aber im Falle von Wissen im Allgemeinen und Software im Besonderen schwierig, wie schon Georg Simmel feststellte: »Theoretische Vorstellungen dagegen gleichen, wie man wohl gesagt hat, der Fackel, deren Licht darum nicht geringer wird, daß beliebig viele andere an ihr entzündet werden; indem die potentielle Unendlichkeit ihrer Verbreitung gar keinen Einﬂuß auf ihre Bedeutung hat, entzieht sie sie mehr als alle sonstigen Lebensinhalte dem Privatbesitz.« (Simmel 1989: 603) Die Distributionsmöglichkeiten von Software (im Fall des Quelltexts auch des in ihr inkorporierten Wissens) und anderer digitalisierter Informationsgüter werden durch die rapide Verbreitung der Computerund Vernetzungstechnologien, die zumindest in den industrialisierten Regionen der Welt zu einer allgegenwärtigen Alltagstechnik geworden ist, vervielfacht. Damit potenziert sich die Problematik der Verwertung von Software, also des darin inkorporierten Wissens und der

32

2 Zur Theorie der technischen Grundlagen

Durchsetzung von Eigentumsansprüchen. Die Reaktion folgt der Logik der materiellen Warendistribution: über den Versuch die Nutzung auf bestimmte Personen oder bestimmte Zeiträume einzuschränken. Was bei herkömmlichen Waren jedoch durch die feste Kopplung von Materialität und Ware gesichert wird (ein Brot kann nur von einer Person gegessen werden etc.), ist im Falle von Wissen und seit der Vernetzung der Digitaltechnologie auf speziﬁsche Mechanismen zur Sicherung der Warenform angewiesen. Eine gängige Reaktion der Hersteller auf diese Problematik ist die ausschließliche Verteilung des Binärcodes. So kann zumindest erreicht werden, daß das in der Software enthaltene und im Quellcode explizierte Wissen geschützt ist. Aber das Kopieren und die vielfältige Anwendung eines Exemplars wird damit keineswegs eingeschränkt. Auch technische Kopierschutzmechanismen, implementiert in Software oder Hardware, sind prinzipiell umgehbar: »Was solche Verbote schlagend vorführen, ist aber nur die Unmöglichkeit perfekter Zugangskontrollen.« (Kittler 1993c) Die Distribution von Software ist, wenn sie der Verwertung dienen soll, aufgrund der billigen vernetzten Digitaltechnologie und der Nichtgebundenheit an einen speziﬁsichen Träger in einem noch stärkeren Maße als die herkömmliche Güterproduktion auf marktexterne Machtinstanzen zur Sicherung des Warencharakters verwiesen. Das erfordert für Software und andere Informationsgüter einen Legitimationsdiskurs dieser Praxen.23 Wissen im Allgemeinen und Software im Besonderen scheinen sich, zumindest unter den Bedingungen der digitalen Vernetzung einer solchen Form von Aneignung zu sperren.24 Insofern ist die Eigentumspraxis in den F/OS-Softwarezusammenhängen, die gerade nicht auf Nutzungs- und Ausschlußbefugnisse zurückgreift, sondern Eigentum auf das Recht auf Verteilung gründet, dem Gegenstand angemessener: »Property in open source is conﬁgured fundamentally around the right to distribute, not the right to exclude.« (Weber 2004: 16) F/OS-Soft23 Der mittlerweile von der Software-, Musik- und Filmindustrie auf einer sehr breiten Basis geführt wird. 24 Daß die Verwertung von Wissen auch im Zeitalter des Buchdrucks keineswegs einfach war, und ebenfalls stark der externen Machtinstanzen bedurfte, zeigen die mannigfaltigen Beschwerden über Raub- und Billigdrucker und die Entwicklung des Rechtes auf sog. »geistiges Eigentum«.

2.1 Software in der Produktion, Distribution und Anwendung

33

ware dürfen alle nutzen (vgl. unten Abschnitt 6.2). Wichtig wird statt der Ausschlußbefugnis die Möglichkeit und das Recht, die ofﬁzielle Version eines Programmes in die Distributionskanäle einzuspeisen. Diese Eigentumspraxis umgeht die Probleme der Nutzungsbeschränkungen von Wissen und Software. Sie beseitigt damit potentielle Konﬂikte mit den Nutzenden. Aber sie bedarf damit ebenfalls einer Legitimation, weil auf der Produzentenseite durchaus noch Konﬂiktpotential bleibt. Dieses wird jedoch durch die Offenheit des Quellcodes und die Erlaubnis der jederzeit möglichen Veränderung gemildert, wenn auch nicht ganz ausgeräumt, wie das nicht sehr häuﬁge, aber doch immer wieder vorkommende forking von Projekten zeigt.25 Der Distributionsprozeß von Software ist vor allem auf die Fragen der Nutzungs- und Ausschlußbefugnisse, und damit auf die Fragen der Warenförmigkeit und des Eigentums konzentriert. Das Distributionsverfahren der F/OSS nimmt aus dem Distributionsprozeß einen Großteil möglicher Konﬂiktpotentiale heraus und sichert auf der Basis von Vernetzung und relativ billigen Servern26 die für diese Produktionsweise notwendige problemlose, weltweite Allokation der Programme (die unter Marktbedingungen nur mit erheblich höheren Kosten zu realisieren wäre). Das produzierte, in Programmcode explizierte Wissen wird auf diese Weise offen und ohne Ausschluß verteilt. Dieser Distributionsprozeß macht aufgrund der damit verfügbaren gemeinsamen Wissensbasis die Realisierung der F/OSS damit wahrscheinlicher. Anwendungsprozeß Zum dritten kann Software in ihrem Konsumtionsprozeß untersucht werden, der die wiederholte Anwendung eines datenprozessierenden Verfahrens darstellt. Dabei werden die Möglichkeiten der Anwendung vom Rahmen, den das in der Regel multifunktionale Programm setzt, bestimmt.27 Innerhalb dieses Rahmens ist ein relativ großer Spielraum 25 Forking bezeichnet die Aufspaltung eines bestehenden F/OS-Projektes in zwei (oder mehr) getrennt weiter zu entwickelnde Projekte. 26 Die üblicherweise verwendeten Server (ftp, cvs etc.) sind zwar vergleichsweise billig, aber schon deutlich teurer als ein einfacher Internetzugang, der für die Beteiligung an der Entwicklung ausreicht. Hier eröffnet sich eine Möglichkeit der Abhängigkeit von Geldgebern und damit der Einﬂußnahme auf die Entwicklung. 27 Für eine Analyse der Technik in kulturalistischer Hinsicht und in besonderer Berücksichtigung der in der Technik inhärenten Macht- und Praxisphänomene vgl.

34

2 Zur Theorie der technischen Grundlagen

für den Anwender gegeben. Dabei kann das System auch ganz anders genutzt werden, als es die Entwickler vorgesehen haben (für Beispiele vgl. etwa Degele 1995). Ein weiterer Aspekt, der die Nutzung von Computern bestimmt, ist, daß das zweistellige Verhältnis Nutzer – Maschine auf ein dreistelliges erweitert wird: Nutzer – Programmierer – Maschine (vgl. Degele 2000: 66). Jede Verwendung wird damit zu einer Interpretation der vom Programm vorgegebenen Rahmen28 , und sofern eine Rückmeldung an die Entwicklenden stattﬁndet, ergibt sich ein rekursiver Entwicklungs- und Aneignungskreislauf (vgl. etwa Hofmann 1997). Gleichzeitig beinhaltet die je speziﬁsche Anwendung in je speziﬁschen Nutzungskontexten (Hardware, andere Software, speziﬁsche Nutzungsformen) auch ein permanentes Fehlersuchen. Gerade die potentielle Unabschließbarkeit des Produktionsprozesses und die speziﬁsche Zeitlichkeit der Softwareentwicklung machen eine weitergehende Integration der Anwendenden in die Entwicklung zu einer wichtigen Option. Aus der Perspektive der Entwickler verdeutlicht das besonders Frederick P. Brooks. Ihm zufolge ist es für die Anwendenden unmöglich, »to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product« (Brooks 2001: 200). Er schlägt deshalb als eine Lösungsmöglichkeit »rapid prototyping« vor, also den Anwendenden möglichst schnell einen Prototyp zur Verfügung zu stellen, um über deren Rückmeldung die dann besser speziﬁzierten Anforderungen zu implementieren. Das F/OS-Entwicklungsmodell ist letztendlich eine radikalisierte Version dieses »rapid prototyping«. Die Anwendenden haben nicht nur die Möglichkeit zur Rückmeldung, sie werden auf diesem Weg, so sie denn gewisse Voraussetzungen erfüllen, selbst in die Produktion eingebunden.29 Hörning 1995. Für eine eingehendere Entwicklung der »kulturellen Inszenierungen des Computers« vgl. auch Dollhausen und Hörning 1996. 28 Der Rahmen ist keineswegs deckungsgleich mit den umgesetzten Intentionen der Entwickler, sondern im Normalfall durchaus weitergesteckt, vgl. wiederum Degele 1995. 29 Wobei anzumerken ist, daß in der vorliegenden Untersuchung die reine Nutzerperspektive keine Rolle spielt, sondern dieses Verhältnis nur aus Sicht der auch anwendenden Entwickler thematisiert wird. Im folgenden empirischen Teil wird nur die Entwicklerseite analysiert. Die Einbindung der Anwendenden in die Analyse, sowohl in Bezug auf den Diskurs als auch in Bezug auf die je konkrete Nutzung

2.1 Software in der Produktion, Distribution und Anwendung

35

Der Anwendungsprozeß von Software ist demnach in der F/OSS, nicht zuletzt aufgrund der Distributionspraxis, eng mit dem Produktionsprozeß verschränkt. Das setzt allerdings die Beteiligungswilligkeit der Nutzenden voraus. Diese steigt, so ist anzunehmen, mit dem vorhandenen computerspeziﬁschen Wissensvorrat und der Relevanz des Programmes im jeweiligen Nutzungszusammenhang. Zusätzlich sind die freiwilligen Programmierer meist selbst Anwender des zu erstellenden Programmes. Beide Faktoren haben zur Folge, daß die im Prozeß der Programmierung wirksamen Relevanzen von entsprechendem Expertenwissen geprägt sind, und die Benutzerfreundlichkeit von F/OSSoftware für Anwendende mit einem durchschnittlichen Wissen um Computer nur bedingt gegeben ist.30 Es entsteht eine Anwendungs-Wissensschwelle, die auch die Wahrnehmbarkeit des Phänomens F/OSS bis Ende der letzten Jahrtausends auf Expertenkreise beschränkt hat.31 Exkurs: Kapitalismus und F/OS-Software Computer, und mit ihnen Software, nehmen eine zentrale Rolle in kapitalistischen Produktions-, Distributions- und Konsumtionsprozessen ein, sei es, daß sie direkt dazu eingesetzt werden, die Produktion zu automatisieren, sei es, daß sie im Umbau des betrieblichen (und staatlichen) bürokratischen Herrschaftsapparates eine zentrale Rolle spielen. Software dient in diesen Anwendungsfeldern vor allem als Modell zur Steuerung und Veränderung der Wirklichkeit: In diesem neben der medialen Verwendung zweiten zentralen Anwendungsbereich von Software wird die fundamentale, formale Abstraktion der Realität dazu benutzt, formale Modelle dieser Realität zu generieren, die dann zur Steuerung und Kontrolle der realen Welt verwendet werden (vgl. Schmiede 1996: 31 und Winkler 2004: 226 ff.: Verwaltungssoftware, und die Einbindung in den Produktionsprozeß bleibt ein Desiderat. Vgl. dazu die ansatzweisen Beschreibungen von Raymond (2001b), die allerdings auch aus der Entwicklerperspektive erfolgen. 30 Dieser Punkt ist in den letzten zehn Jahren vor allem durch die Unternehmen, die sich auf die Verwertung von F/OS-Software spezialisiert haben, wesentlich verbessert worden. Trotzdem ist nach wie vor für die Benutzung der meisten F/OSSoftware ein größeres Wissen notwendig als für kommerzielle Software. 31 Diese Anwendungs-Wissensschwelle ist, so mein Eindruck, auch ein wichtiges Differenzierungskriterium innerhalb der Anwendungsdiskurse. Deren genauere Untersuchung bleibt allerdings ebenfalls ein Desiderat.

36

2 Zur Theorie der technischen Grundlagen

Datenbanken, betriebliche Softwareanwendungen zur Steuerung von Produktion und Distribution, Wetterprognoseprogramme etc. Von dieser Funktion her muß ihr gesellschaftlicher Einsatz zumindest auch verstanden werden.32 Computer sind vor allem eine Kontrolltechnologie: sie versprechen die Kontrolle von Informationen, Kommunikationen und nicht zuletzt der (gesellschaftlichen) Realität. Hier liegen die Wurzeln ihrer Entwicklung (vgl. Halfmann 1984; Edwards 1996; Beniger 1986: 390 ff.) und hier liegen nach wie vor ihre wichtigsten Einsatzfelder. Mit dieser performativen Anwendung schaffen Computer »eine Kette zwischen einer symbolisch-konstruktiven Modellbildung und [. . .] einer praktisch-empirischen Veriﬁkation.« (Winkler 2004: 228) Nicht zuletzt deshalb ist die Produktion von Hardware und Software ein Kernbereich der kapitalistischen Produktion geworden. Hier sind einige der größten und technologieintensivsten Unternehmen tätig und hier werden nach wie vor enorme Proﬁte erzielt. Was oben in der Betrachtung der Produktions- und Konsumtionsprozesse von Software außer Acht gelassen wurde, ist diese Produktion und Anwendung von Software in kapitalistischen Betrieben. Angesichts der Preislosigkeit der F/OS-Software und ihrer – so zumindest die Behauptung der Produzenten – mit kommerzieller Software durchaus vergleichbaren Qualität erstaunt es wenig, daß, nach anfänglichen Berührungsschwierigkeiten, F/OS-Software immer mehr auch in Verwertungsprozessen eingesetzt wird und eine Vielzahl von Firmen, nicht nur aus der Informations- und Kommunikationsbranche, so entwickelte Software verwenden und dieses Entwicklungsmodell inzwischen auf verschiedenste Weise unterstützen. Das ist die eine Seite des Verhältnisses. Auf der anderen Seite entsteht diese neue, nicht auf Verwertung ausgerichtete Produktionsweise in Konkurrenz zu einer kapitalistischen Softwareproduktion, die aus Verwertungsgesichtspunkten hervorragend funktioniert. Das macht die Entstehung und dauerhafte Etablierung der F/OSS angesichts des Erfolges der letzteren in punkto Efﬁzienz und Organisation nur um so unwahrscheinlicher. 32 Eine Konzentration auf den Aspekt des Computers als Medium, wie etwa von Winkler (1997) oder Bolz et al. (1994) versucht, vernachlässigt die Steuerungsfunktionen des Computers, die gerade in betrieblichen und staatlichen Einsatzfeldern zentral sind.

2.1 Software in der Produktion, Distribution und Anwendung

37

Wahrscheinlichkeiten und Unwahrscheinlichkeiten Die Analyse der Prozesse der Produktion, Distribution und Anwendung von Software zeigen einen Möglichkeitsraum auf, der von der F/OSS besetzt werden kann. Dieser Möglichkeitsraum birgt zwar einige wahrscheinlichkeitssteigernde Faktoren, wie die billige energetische und materielle Grundlage, auf der die Programmierung stattﬁnden kann, wie die speziﬁsche Zeitlichkeit von Software, die die Produktion von Zeitdruck befreien kann, sowie den Verteilungsmodus mit der uneingeschränkten Nutzung und Weitergabe der Software und dem so konstitutierten frei zugänglichen Wissenspool, der als Grundlage für weitere Programme dienen kann. Zudem bietet sich aufgrund dieser Distributionsform die Möglichkeit, die Anwendenden stärker in die Produktion miteinzubinden. Aber dem stehen einige Unwahrscheinlichkeiten gegenüber. Es ist unwahrscheinlich, daß die Koordination bei der Arbeit an einem derart komplexen Gegenstand wie Software außerhalb von bewährten, auf solche Probleme spezialisierten Institutionen und Organisationen funktioniert, ja daß die Koordination bei der notwendigen Modularisierung zwischen einzelnen, isolierten Freiwilligen überhaupt bewerkstelligt und, noch entscheidender, auf Dauer gestellt werden kann. Selbst wenn aufgrund der speziﬁschen Zeitlichkeit von Software die Produktion in diesem Möglichkeitsraum gelingen sollte, ist es unwahrscheinlich, daß sie auch hinreichend schnell funktioniert, um mit der rasanten Entwicklung der Computerhardware überhaupt Schritt zu halten (ein Zeitdruck, der aus dem Kontext der Produktion entsteht). Trotz der durch die Verbreitung der Computertechnik und deren relative Verbilligung geschaffenen potentiellen Basis an Anwendenden und Programmierenden bleibt die Koordination in Bezug auf einen Gegenstand Software unwahrscheinlich, nicht zuletzt aufgrund der Wissensschwellen die für die Anwendung und für die Beteiligung an der Produktion überwunden werden müssen. Und schließlich die größte Unwahrscheinlichkeit: daß sich in einem Sektor funktionierender kapitalistischer Produktion ein alternativer Produktionsmodus überhaupt etablieren kann, ohne sofort vereinnahmt und verwertet zu werden. Im Anschluß an diese Prozeßanalyse wird nun der Arbeitsgegenstand »Software« analysiert.

38

2 Zur Theorie der technischen Grundlagen

2.2 Schrift und Formalisierung In diesem Schritt der Analyse wird im Wesentlichen die These entwickelt werden, daß die formalisierte Schriftlichkeit das entscheidende Merkmal der Software ist, das eine weltweit verteilte Entwicklung durch Freiwillige ermöglicht. Dazu wird in einem ersten Schritt die binäre Logik der Programme erläutert. Auf dieser Grundlage wird in einem zweiten und dritten Schritt anhand der Begriffe Schrift und Formalisierung und die mit ihnen ermöglichte Ausgrenzung von Kontext und Bedeutung das entscheidende Merkmal von Software als Gegenstand der F/OSS entwickelt. In dieser Analyse wird nur auf die momentan gängigste Form der Computer und Programme eingegangen. Neuere Entwicklungen wie neuronale Netze, die Wiedererﬁndung der Analogcomputer usw. spielen aktuell keine Rolle. Gearbeitet wird mit den zuhandenen Computern, und das sind nach wie vor Digitalcomputer mit der sog. vonNeumann-Architektur.33 Binäre Logik Bei der Betrachtung von Software fallen zuerst die zwei Zustandsformen ins Auge: Software kann zum einen als in einer Programmiersprache geschriebener sog. »Quelltext« und zum anderen als »Binärtext« vorliegen, als maschinenlesbare Aneinanderreihung von Nullen und Einsen. Als Beispiel sei ein kleines Programm in der Programmiersprache C++ angeführt: #include int main (void) { cout << "Hallo!" << endl; } 33 Demnach sind Computer aufgebaut aus Rechenwerk (für Rechenoperationen und logische Verknüpfungen), Speicherwerk (Speicher für Programme und Daten), Steuerwerk (für die Steuerung der Ausführung von Programmbefehlen), Eingabe-/ Ausgabewerk (steuert die Ein- und Ausgabe von Daten) und Verbindungssystem. Die von-Neumann-Architektur hat inzwischen vielfältige Veränderungen erfahren, gilt aber im Prinzip immer noch für die meisten Computer.

2.2 Schrift und Formalisierung

39

Dieses Programm wird mit einem sog. Compiler (ein Umsetzungsprogramm) in maschinenlesbaren Binärtext für eine speziﬁsche Hardwarearchitektur übersetzt (in diesem Fall für eine i386-CPU, also einen mit der Intel 386-Architektur kompatiblen Prozessor), oder besser: umgesetzt (weil für die Transformation strikte Regeln gelten). 01001000 01100001 01101100 01101100 01101111 00100001

Diese Zahlenfolge ist die ›maschinenlesbare‹ Transformation der Zeichenfolge »Hallo!«.34 Erst nach dieser maschinellen Umsetzung bewirkt das Laden und Ausführen des Programmes, daß auf dem Bildschirm die Zeichen »Hallo!« ausgegeben werden. Die binäre Darstellung macht ein erstes Merkmal von Software deutlich: die Diskretheit. Es gibt nur zwei unterscheidbare Zustände innerhalb der Maschine: 0 und 1. Digitalrechner sind demnach »JaNein-Organe im strengen Sinne des Wortes« ( John v. Neumann zit. nach Kittler 1993b: 240). Diese Diskretheit hat Auswirkungen auf die Bedingungen der Anwendbarkeit: Jedes in Datenform zu erfassende und computerberechenbar zu machende Kontinuum muß in diskrete Einheiten zerlegt werden. Damit wird eine eindeutige symbolische Welt geschaffen, die zwar komplex sein und in gewisser Weise ›Realität‹ modellieren kann, die sich aber auf einer basalen Ebene von der dem analogen Kontinuum der ›realen‹ Welt unterscheidet: ihr liegt durchgängig eine binäre Logik zugrunde.35 Die Programmierung von Software erfordert die Schaffung einer Parallelwelt, einer Welt der diskreten Symbole, eine Welt mit »wunderbarer Ordnung« (Leibniz), die der unvollkommenen, ungenauen Welt (und deren Sprachen) gegenübersteht. Exkurs: Schichten Die oben erwähnte maschinelle Transformation weist auf den Schichtaufbau von Computern hin: die angeführte binäre Zahlenfolge existiert 34 Das maschinenlesbare Programm besteht natürlich nicht nur aus diesen sechs Achtergruppen, sondern aus insgesamt 13.552 solcher Bytes, also ein Vielfaches des Quelltextes, der nur 70 Bytes groß ist. 35 Für die Analyse der Programmierbarkeit aufgrund dieser Diskretheit und im Verhältnis zu Effektivität und Entwicklungsfähigkeit vgl. Conrad 1995; Kittler 1993b.

40

2 Zur Theorie der technischen Grundlagen

nicht in dieser Form im Rechner, sondern ist nur eine für Menschen leichter zugängliche Form der Symbolisierung der elektromagnetischen Vorgänge: »A deeper analysis shows, that the number itself is not an object in the computer, but that some pattern of impulses or electrical states in turn represents the number. One of the properties unique to the digital computer is the possibility of constructing systems that cascade levels of representation one on top of another to great depth.« (Winograd und Flores 1986: 86 f.)36 Letztendlich prozessieren in der Maschine elektromagnetische Zustände, Spannungsdifferenzen und Stromﬂüsse in einer komplexen Anordnung von Leitungsbahnen, Transistoren, Dioden, Widerständen etc., also in den Strukturen der realen physikalischen Maschine. Die wiederum sind auf einer höheren Ebene in Form von logischen Schaltungen (Und-Gatter, Oder-Gatter, Flip-ﬂops etc.) angeordnet, die komplexe, binäre elektromagnetische Muster generiert: Die nach jedem Takt produzierten und arretierten Spannungszustände lassen sich logisch als 0 oder 1 interpretieren. Diese logisch interpretierbaren Elemente werden zu größeren Einheiten zusammengefaßt, wie etwa Gleitkommaeinheit, Arithmethisch-logische Einheit, Speichermanagement-Einheit, Speicher etc. Die wiederum lassen sich als abstrakte physikalische Maschine beschreiben: Prozessor, Speicher, Mainboard, Festplatte etc. Auf einer weiteren Ebene, vermittelt durch das Betriebssystem, lassen sich die höheren Programmiersprachen und Anwenderprogramme lokalisieren. Entscheidend an dieser Beschreibung ist, daß die Signiﬁkanz der physikalischen Zustände in der Maschine von außen herangetragen wird.37 Die einzelnen Ebenen sind von der logischen Ebene an selbst 36 Zu den Schichtmollen für den Computer vgl. auch Heintz 1993: 241 ff., Kittler 1993b, Esposito 1993: 349 f. und Esposito 2002: 296 f.. 37 »Representation is in the mind of the beholder.38 There is nothing in the design of the machine or the operations of the program that depends in any way on the fact that the symbol structures are viewed as representing anything at all.« (Winograd und Flores 1986: 86) 38 Dieser konstruktivistische Repräsentationsbegriff ist explizit abgesetzt von dem für die Forschungen zur sog. Künstlichen Intelligenz maßgeblichen Repräsentationsbe-

2.2 Schrift und Formalisierung

41

Softwaremodellierungen. Für den Benutzer, sei er normaler Anwender oder Programmierer, im Fall einer funktionierenden Maschine, ist nur die jeweils oberste Schicht der Softwarekaskade sichtbar39 , eine »Oberﬂäche« auf dem Bildschirm: »Vor allem aber ändert der Computer [. . .] das Verhältnis von (zugänglicher) Oberﬂäche und Tiefe. [. . .] die Oberﬂäche ist jetzt der Bildschirm mit extrem beschränkter Inanspruchnahme menschlicher Sinne, die Tiefe dagegen die unsichtbare Maschine, die heute in der Lage ist, sich selbst von Moment zu Moment umzukonstruieren, zum Beispiel in Reaktion auf Benutzung. Die Verbindung von Oberﬂäche und Tiefe kann über Befehle hergestellt werden, die die Maschine anweisen, etwas auf dem Bildschirm oder durch Ausdruck sichtbar zu machen.« (Luhmann 1997: 304)40 Sichtbar ist eine Oberﬂäche, die seit der Durchsetzung der MacIntosh-Ästhetik sich als zweidimensionales »Graphical User Interface« (GUI)41 mit einer speziﬁschen Bürosymbolik präsentiert: Desktop, Ordner, Papierkorb etc. Symbole und Piktogramme ermöglichen einen einfachen Zugang zu Programmen und Daten.42 Mittels Maus und Tastatur wird diese Oberﬂäche manipuliert, in »Unkenntnis der zugrundeliegenden Mechanismen« (Turkle 1999: 51). Die Benutzung des Computers erfolgt auf dieser Oberﬂäche, auch beim Programmieren, wie schon Kittler aus der Tiefe seiner Maschine feststellt: »Schon wer selbigen Tags Technische Schriften schreibt und trotzdem noch zwei

39

40 41

42

griff der »Philosophy of Mind« vgl. zur Kritik des letzteren Putnam 1988; Schneider 1992; Metzinger 1993; Winograd und Flores 1986: 72 ff. Ein Teil der Kaskade wird bei einigen Betriebssystemen noch beim Starten des Computers sichtbar: nach dem Start sind erst die BIOS-Meldungen auf dem Bildschirm zu sehen, danach Meldungen des Betriebssystems und schließlich nur noch die graphische Benutzeroberﬂäche. Die von Luhmann erwähnte »Umkonstruktion« kann natürlich nur im Rahmen der aktuell vorhandenen Hardware und Programmierung erfolgen. Ein Konzept, das zusammen mit der heutzutage ebenfalls allgegenwärtigen sog. »Maus« in den 60er Jahren des vergangenen Jahrhunderts unter anderem von Douglas C. Engelbart entwickelt wurde vgl. Engelbart und English 1968. Zum Wechsel von IBM-Technik, die eine potentielle Transparenz der verschiedenen Ebenen versprach, zur alles überdeckenden Mac-Oberﬂäche vgl. Turkle 1999: 41 ff..

42

2 Zur Theorie der technischen Grundlagen

drei Assemblerroutinen seiner Graphikmaschine optimiert, kann nicht umhin festzustellen, daß die Unterschiede zwischen Schreiben und Programmieren mittlerweile gegen Null gehen.« (Kittler 1993a: 9)43 Der Unterschied verschwindet für den Computer, weil in beiden Fällen zwischen den Ebenen des Computers transformiert werden muß, von den Tastatureingaben im Editor in, letztendlich, elektromagnetische Signale. Der Schichtaufbau macht die tieferen Ebenen für den normalen Benutzer unsichtbar, und damit auch die Diskretheit und binäre Logik der Programme. Für den Programmierer, und das bleibt gegen Kittler festzuhalten, sind die tieferen Ebenen in der allen Ebenen zugrundeliegenden binär-diskreten Logik präsent, sondern auch weil Schreiben in einer ›normalen‹ Sprache für die Schreibenden nach wie vor signiﬁkant vom Schreiben in Computersprachen unterschieden ist. Der entscheidende Unterschied ist der, daß normalsprachliches Schreiben mit Bedeutungen oder Signiﬁkaten operiert, während programmierendes Schreiben genau davon abstrahiert. Diese wichtige Differenz übergeht Kittler in seiner Fixierung auf die Signikanten. Sie wird aber in der Analyse des Schichtenaufbaus deutlich: Bei den Transformationen von der Ebene der arretierten elektromagnetischen Zustände in beispielsweise eine graphische Benutzeroberﬂäche handelt es sich nicht um Über-setzungen, sondern um Um-setzungen von einem Signiﬁkantentyp in den nächsten. »01001000« ist eineindeutig44 »H«45 43 Kittler analysiert solche verschiedenen Ebenen als machtförmige Instrumente, die »eine ganze Maschine ihren Benutzern« (Kittler 1993b: 233) entzieht und sieht entsprechend nur noch produzierte »Untertanen von Microsoft« (Kittler 1993c: 211). Da sich alle Ebenen letztendlich auf die Hardware zurückführen lassen, gibt es, so seine starke These, letztendlich keine Software. (Dreht man das Argument, kann mit demselben Recht behauptet werden, es gibt keine Hardware.) Seinen Vorschlag, die Soziologie von den Chiparchitekturen her aufzubauen, führt er schon durch seine eigene Programmiertätigkeit zur Umgehung des »Protected Mode« ad absurdum, mit der er sich der Unterwerfung durch die Hardware entzieht. Einem solchen Technikdeterminismus bleibt letztendlich nur die Flucht in die Subversion. Strukturell ähnlich argumentiert Baudrillard, der allerdings als zusätzlichen Ausweg noch die reaktionäre Romantik einer gabentauschenden Gesellschaft pﬂegt, vgl. Sebald 2004. 44 Zwar besteht auch das Alphabet aus eindeutigen Zuordnungen von Lauten zu graphischen Symbolen, aber zentral ist die Verknüpfung zu Signiﬁkantenketten, die nichteindeutige Bedeutungen haben. 45 In diesem bestimmten Kontext; in einem anderen Kontext kann die Bedeutung durchaus anders sein, aber sie ist auch dort immer eindeutig.

2.2 Schrift und Formalisierung

43

und kann nicht ›mißverstanden‹ werden. Programmierendes Schreiben ist Formierung einer Signiﬁkantenkette, normalsprachliches Schreiben dagegen Formulierung. Schriftlichkeit Aus diesen Betrachtungen wird neben der Diskretheit ein zweites Merkmal der Software deutlich: die Schriftlichkeit, die lineare Anordnung von graphischen Symbolen. Eine Schrift, die wegen der vielen möglichen Repräsentationsebenen durchaus in verschiedenen Materialisierungen vorliegen kann: als nanosekundenlanger elektrischer Zustand in einem arbeitenden Prozessor, als Lochkartenstanzung, als Abtastunebenheit auf einem sog. Rohling oder als elektromagnetische Zustandsfolge auf einer Festplatte. Die »elektronische Schriftlichkeit« (Wehner 1997b) ist demnach nicht fest an einen materiellen Träger und eine Codierung gebunden, sondern hat eine Vielzahl von möglichen Codierungen und Träger, nicht nur auf der sichtbaren Oberﬂäche46 , sondern auch in der Maschine selbst. Diese Lösung der Kopplung an einen bestimmten materiellen Träger ist ein vor allem im Bereich der Distribution wichtiges Kennzeichen der digitalisierten Schrift. Eine diskrete Schrift, die auch dazu genutzt werden kann, Bilder und Töne zu generieren und anzuzeigen, die es also ermöglicht andere Medienformen zu emulieren, auch die herkömmliche Schrift.47 Für das Schreiben von Programmen entscheidend ist die Ebene der logischen Repräsentation. Die Elemente der Programmschrift auf dieser und den darüberliegenden Ebenen sind »typographische Symbole« (Krämer 1988: 1), also die alphanumerischen Zeichen inklusive einiger Sonderzeichen (im Fall des Binärtextes nur die Zeichen 0 und 1). Diese Zeichen sind aber keine Zeichen oder Symbole im gebräuchlichen Sinne, sondern sie sind innerhalb der formalen Computersprachen bar

46 Gängiges Visualisierungsinstrument der elektronischen Schrift ist der Kathodenstrahl- oder Flüssigkristallbildschirm. Hier werden die Probleme der Codierung vor allem bei einer unzulänglichen Darstellung von sprachlichen Sonderzeichen deutlich. 47 »Un langage parfaitement distinct permettrait un discours entièrement clair : cette langue serait en elle-même une Ars combinatoria. [Eine völlig distinkte Sprache würde eine gänzlich klare Rede gestatten. Diese Sprache wäre in sich selbst eine Ars combinatoria]«. (Foucault 1966: 217 (256 der dt. Ausgabe))

44

2 Zur Theorie der technischen Grundlagen

jeglicher Bedeutung. Was alleine zählt, ist ihr Wert als Signiﬁkant.48 Dieser Wert bestimmt sich über streng formale Deﬁnitionen der Differenz zu anderen Zeichen. Die innere Kohärenz der Computersprachen wird durch ein striktes Regelsystem gesichert, ein Regelsystem, das jede Art von Mehrdeutigkeit ausschließt. Das gelingt nur durch die Abstraktion von Bedeutung oder Semantik.49 Es geht in Programmiersprachen demnach um die regelkonforme Aneinanderreihung gültiger Signiﬁkanten, um formalisierte Schrift. Jeglicher interne Bezug auf eine Realität außerhalb dieser rein syntaktischen Regelsysteme wird in der Maschine gestrichen.50 In der maschinellen Schriftlichkeit der Computersprachen sind die Signiﬁkanten radikal von Kontext und Bedeutung isoliert und auf eindeutige diskrete Zustände reduzierbar. Damit wird die auf der grundlegenden logischen Ebene produzierte Abgrenzung von der analogen, ›realen‹ Welt auf der Ebene der höheren Programmiersprachen reproduziert. Wenn diese Welt in die Software eingehen soll, muß sie in Form von diskreten Daten, denen ebenfalls der Bezug auf den Kontext fehlt, integriert werden. Ein Umgang mit Welt im Programm setzt eine Bearbeitung gemäß den Regeln dieser maschinellen Schriftlichkeit, Eindeutigkeit, Kontextlosigkeit, Isoliertheit, voraus. Die Praxis des Programmierens wird damit von dieser binären Logik und der ihr inhärenten Abgrenzung fundiert.51 Diese Schriftlichkeit hat jedoch zwei Seiten: »A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous deﬁnitions all exist to make intentions clear to the dumb machine.« (Brooks 2001: 164) Das ist die eine Seite des Quelltextes, 48 Luhmann schlägt aus diesem Grund vor, die Begriffe »Zeichen« und »Symbol« aufzugeben, und statt dessen von Formen zu sprechen (Luhmann 1997: 530, Fn. 200). 49 Daß sich auch in Computersprachen Synonyme und Redundanzen entwickeln, wie Kittler (1993c: 222 f.) zeigt, ist ihrer menschengemachten historisch-technischen Entwicklung geschuldet. Deswegen wird aber keinswegs der »heilige Unterschied zwischen Alltagsprachen und formalen Sprachen« eingeebnet (ebd.). Es fehlt nach wie vor die Bedeutungsebene dieser Signiﬁkanten für die Maschine. 50 Für die historische Rekonstruktion der Entstehung dieser Formalisierung vgl. Krämer 1988, Krämer 1991 und Heintz 1993. Für eine philosophische und kulturkritische Betrachtung dieser Formalisierung vgl. Husserl 1992. 51 Vgl. dazu auch Winkler 1997: Kap. 6, der den Begriff der Isolation als Zentrum seiner Analyse der Computer(medien) stellt, und aus einer psychoanalytischen Deutung daraus auch die geschlechtliche Differenz in der Computernutzung erklärt.

2.2 Schrift und Formalisierung

45

auf der anderen Seite gilt aber: »But a written program has another face, that which tells its story to the human user.« (Brooks 2001: 164) Damit der Quelltext von anderen verstanden (und bearbeitet) werden kann, ist es notwendig, ihn mit einer (für die Maschine irrelevanten) signiﬁkativen Ebene zu versehen, sei es in Form von Kommentaren, Erläuterungen, sei es in der Benennung von Programmen, Dateien, Objekten, Funktionen, Variablen, Konstanten etc. In diesen Formen des Umgangs mit den reinen Signiﬁkanten manifestiert sich ein je speziﬁscher Programmierstil, ein Stil, der als solcher jedoch implizit bleibt (vgl. Grüter 1997: 117 ff.). Formalisierung Im Arbeitsablauf der Programmierung werden Signiﬁkantenketten gemäß eindeutiger Verfahrensregeln aneinandergereiht. Im obigen Beispielprogramm ließe sich das so übersetzen: Integriere die Datei »iostream.h« (und die darin enthaltenen Befehle) in das Programm. Deﬁniere die Funktion »main«, die eine ganze Zahl als Ausgabe zurückgibt und die keine Parameter benutzt. Die Funktion selbst lautet: schreibe die Zeichenkette »Hallo!« (gefolgt von einem Zeilenende) in den Standardoutput. Die ausgegebene Zeichenkette hat dabei für das Programm keinerlei Bedeutung. Erst wenn die Ausgabe etwa auf einen Benutzer zielt, der sie als Begrüßung deuten kann, kommt die Bedeutungsebene wieder ins Spiel, aber dieser Kontext liegt außerhalb des maschinellen Programmes. Auch die Benennungen der einzelnen Elemente der Programmiersprache, wie im Beispiel etwa »iostream.h«, eine Abkürzung für Input-Output-Stream, »cout«, character-output etc. sind für das erleichterte Verständnis des Quelltextes interessant, nicht für die Maschine. In Anwendung der Regeln der Formalsprache wird ein Programm, eine Abfolge von Ausführungsvorschriften, formuliert. Das stellt eine zweite Ebene von Regeln dar, eine, die zwar gemäß den Regeln der Formalsprache formuliert sein muß, aber mit diesen regelgemäß geformten Signiﬁkantenketten Befehlsketten bildet. Befehlsketten, die zu einem schematisches Verfahren kombiniert werden, das zur Lösung eines Problemes dienen soll, kurz ein Algorithmus: »Ein Algorithmus ist ein Verfahren, das in einer endlichen Anzahl von elementaren Operationsschritten, deren Abfolge im voraus in einer endlich langen Beschreibung

46

2 Zur Theorie der technischen Grundlagen

eindeutig festgelegt ist, die Lösung eines (mathematischen) Problems erlaubt.« (Heintz 1993: 72) Um ein Problem zu lösen, muß es erst in ein formales Problem umgewandelt werden, dann kann es als Algorithmus in ein Computerprogramm umgesetzt werden, das wiederum bis auf die unterste Maschinenebene gemäß den jeweiligen Formalregeln transformiert werden muß. Mit der Formalisierung wird demnach radikal vom Kontext, von Sinn, von Bedeutungszuweisungen abstrahiert, um dann in einem zweiten Schritt, der konkreten Programmierung, ein Problem, das aus dem ausgeschlossenen Kontext heraus entsteht52 , mit diesen formalen Mitteln zu lösen. Dazu müssen (implizite oder explizite) Modelle dieses Kontextes, soweit er für die Programmierung relevant ist, erstellt werden. Um diese Modelle jedoch generieren zu können, ist, neben der Modellierung der Realität in einer formalisierten Beschreibung, ein je aktuell zu gewinnender Input aus der zu steuernden Wirklichkeit nötig. Dazu dienen quantiﬁzierte Splitter der Realität, Daten, die selbst bereits durch formale Rationalität erzeugt sind und in der maschinellen Verarbeitung jeder Bedeutung entkleidet sind. Um ein Computerprogramm zu schreiben, müssen die Programmierenden das Problem und den relevanten Kontext selbst erst in eine Abfolge von Algorithmen fassen, es formalisieren innerhalb eines Regelsystems, das »seine innere Kohärenz und Leistungskraft [. . .] auf die Reinheit seiner Konstruktion gründet.« (Winkler 2004: 227) Dabei spielt selbst die eigene historische Dimension dieses Regelsystems keine Rolle, d. h. Bezüge zur Vergangenheit werden mit der Formalisierung ausgeschlossen. Die Schlußfolgerung, die ich aus diesen Analysen ziehe, ist, daß es diese formalisierte Schriftlichkeit der Software ist, die eine neue selbstorganisierte Produktionsweise der Programmienden ermöglicht. Nur wenn Kontext und Bedeutung auf eine Minimum reduziert werden können, erhöht sich die Wahrscheinlichkeit einer medienbasierten, symbolischen und kooperativen Produktionsweise wie in der F/OSS. Denn wenn die Regeln einer schematischen Abfolge von Signikanten 52 Natürlich gibt es auch Anwendungen, die sich jeder pragmatischen Verwendung entziehen, die keinerlei Zweck haben, außer dem mit dieser Formalität zu spielen, wie etwa die Visualisierung von sog. Mandelbrotmengen im sog. »Apfelmännchen«. Der überwiegende Teil jedoch ist mehr oder minder direkt auf eine Lösung von realweltlichen Problemen gerichtet.

2.3 Medientheorie und computerbasierte Medien

47

bekannt sind, können Arbeitsweise und Funktionen eines Programmes aus dem Programm selbst rekonstruiert werden.53 Außerdem kann relativ leicht veriﬁziert werden, ob ein Programm den internen Regelebenen genügt. Es funktioniert oder es funktioniert nicht. Es folgt dem internen Schema oder es folgt ihm nicht. Analog zum Leibnizschen Diktum: »Rechnen wir, mein Herr!« (zitiert nach Krämer 1991: 238) können Programmierende leicht die Funktionsfähigkeit eines Programmes überprüfen. Es ist keine Diskussion über eine Form(ul)ierung nötig, wenn diese funktioniert. Einwände können allenfalls in Bezug auf den Stil der Programmierung oder der Angemessenheit der Formalisierung des Problems gemacht werden. Damit kann der Quelltext schließlich als eindeutiger Diskussionsbeitrag unabhängig von der Muttersprache der Programmierenden bearbeitet werden. Es genügt die Kenntnis der Formalsprache.54 Das gilt natürlich nicht für die Diskussionen um Konzeption, Modularisierung, Restrukturierung oder Planung. Aber damit werden auch gewisse Ausgangsbedingungen gesetzt: Zum ersten wird die Kenntnis der Formalsprache(n) zu einer Voraussetzung einer Mitwirkung an der Produktion von Software. Mit dieser notwendigen »Computeralphabetisierung« (Kittler 1996) entsteht eine Wissensschwelle, die über die Möglichkeit der Beteiligung entscheidet.

2.3 Medientheorie und computerbasierte Medien Der Arbeitsgegenstand ›Software‹ ist der eine konstituierende Faktor der Produktion in den Zusammenhängen der F/OS-Entwickler. Da der Großteil dieser Produktion potentiell global verteilt ist und vorwiegend über computerbasierte Medien organisiert wird, müssen in einem weiteren Schritt die verwendeten Medien und die daraus sich ergebenden (Un-)Wahrscheinlichkeiten einer genaueren Betrachtung unterzogen werden. Dazu wird in einem ersten Schritt anhand von medientheoretischen Überlegungen, die auch die alltagspragmatische 53 Was je nach interner Dokumentation, Umfang des Programmtextes und Programmierstil einen mehr oder weniger großen Zeitaufwand erfordert. 54 Klare und eindeutige Deﬁnitionen und Abgrenzungen sind die essentielle Leistung im Prozeß der Formalisierung. Legt diese Praxis entsprechend eindeutige Abgrenzungen nahe, etwa gegen die Unklarheiten in sozialen Praxen?

48

2 Zur Theorie der technischen Grundlagen

Sichtweise miteinbeziehen, allgemeine Merkmale computerbasierter Medien herausgearbeitet. Neben dem generellen Merkmal der (nichtformalisierten) elektronischen Schriftlichkeit, das für alle in der F/OSS verwendeten computerbasierten Medien gilt, werden dann die zentralen Medien, Quelltext, Mailinglisten und Internet Relay Chat einer genaueren Analyse unterzogen. Medientheoretische Überlegungen Die Medientheorie ging lange davon aus, daß Medien ein Mittel der Übertragung einer Botschaft von einem Sender zu einem Empfänger seien. Diese Vermittlungsfunktion ist als Ausgangspunkt einer Medientheorie mit den Analysen von McLuhan (1995), poststrukturalistischen Theorien (vgl. etwa Baudrillard 1991; Kittler 1986; 1995) und der radikalkostruktivistischen Systemtheorie (Krippendorf 1994; Merten 1999; Luhmann 1997: 195)55 , die ein eigenständiges Prozessieren und Bearbeiten der Botschaft durch Medien betonen, zweifelhaft geworden. Zuviel an Eigenschaften und Funktionen von Medien verschwinden hinter der Übertragungsmetapher. Der Medienbegriff soll deshalb im Folgenden gebraucht werden im Sinne eines Instrumentes, das Kommunikation prozessiert und formiert auf je speziﬁsche Weise in Bezug auf Verzeitlichung, soziale Reichweite und mögliche Anschlußpraxen. Medien sind also auch eigenständige »Quelle[n] von Sinn« (Krämer 2000: 74). Nun ist es aber so, daß diese Übertragungsfunktion im Alltagshandeln mit Medien als fraglos gegeben angenommen und Medien normalerweise mit ihrer Vermittlungsfunktion in der Wahrnehmung auftauchen. Wenn ich eine E-Mail schreibe, sind mir keineswegs die Verarbeitungs- und Verbreitungsprozesse im Inneren des Computers bewußt, sondern ich tippe den Text ein, gebe Betreff und Empfängeradresse ein und schließe den Vorgang mit einem Mausklick oder einer Tastenkombination ab. Dabei gehe ich davon aus, daß der oder die Empfänger die Botschaft genauso erhalten, wie ich sie abgeschickt habe. Ich weiß, daß die Nachricht zwar sehr schnell gesendet wird, aber erst gelesen wird, wenn der Empfänger Zeit hat. Die Empfänger haben die Möglichkeit zu antworten, im selben Medium oder in einem anderen. Die Erfahrung im Umgang mit der Maschine hat mich gelehrt, daß 55 Für eine Kritik der systemtheoretischen Medienkonzeptionen vgl. Renn 2006.

2.3 Medientheorie und computerbasierte Medien

49

diese Abläufe und Möglichkeiten vorhanden sind. Im Alltagsgebrauch gehen wir also problemlos von einer reibungslosen Vermittlungsfunktion der Medien aus. Die darunterliegende Technik, die Codierung der Mail entsprechend der gewählten Sprache, das Versenden an einen Mailserver, die Auflösung der Adresse mit Hilfe eines sog. »Domain Name Servers«, die realen Leitungen, durch die die Mail verschickt wird, eine eventuelle Filterung, die Decodierung usw. sind für mich gar nicht sichtbar, oder nur an den Punkten, an denen etwas schiefgeht, und ich eventuell eine Fehlermeldung bekomme. Wie ist diese alltägliche Wahrnehmung nun mit den oben zitierten Befunden der Medientheorie und der Deﬁnition in Einklang zu bringen? Dafür bietet sich das von Schütz (2004a) ausgearbeitete Modell von Vertrautheit und Störung. Der häuﬁge Mediengebrauch hat zu einem habituellen Wissen geführt, das Medium »ist nicht mehr Gegenstand für weitere Untersuchung [. . .] [es wird] fraglos und als solche[s] als gegeben hingenommen, ein Teil der unbefragten Welt. Aber das bedeutet nicht, daß e[s] unbefragbar ist; e[s] ist nur bis auf weiteres unbefragt«. (Schütz 2004a: 120) In dieser Habitualisierung oder Sedimentierung des Wissensvorrats wird das Medium unsichtbar, es verschwindet unter der Hand in seiner ständigen Benutzung. Erst wenn eine Störung auftritt, ein »unvertrauter Aspekt bei einer vertrauten Erfahrung« (Schütz 2004a: 125) wird die mediale Technik wieder sichtbar. Diese Sichtbarkeit richtet sich dabei nach dem jeweils zuhandenen Wissensvorrat. Für Programmierende oder Systemadministratoren ist diese Sichtbarkeit weitaus tiefer gehend, als für einfache Benutzer, die von der Störung nur auf der jeweiligen Oberﬂäche Kenntnis nehmen und entsprechend nur eingeschränkt eingreifen können.56 Erst in der Störung wird das eigenständige Formieren und Prozessieren der Kommunikation durch das Medium sichtbar. Wenn beispielsweise alle Sonderzeichen in einer E56 Vgl. zu dieser Argumentation auch Heidegger (2001: 75), bei dem das Zuhandene erst im »Bruch« sichtbar wird, Jäger (2003), der Kommunikation und Medien als ein Pendeln zwischen den Zuständen »Störung« und »Transparenz« beschreibt und Bolter und Grusin (2000: 18), die Medien als Oszillation zwischen »immediacy and hypermediacy, between transparency und opacity« begreifen.

50

2 Zur Theorie der technischen Grundlagen

Mail falsch dargestellt werden und damit der Text entsprechend schwer lesbar ist, wird die bisherige Decodierungsleistung der Maschine erst deutlich. Soweit die durch das Medium vorgegebenen Strukturierungen in Bezug auf Verzeitlichung oder Anschlußpraxen den alltäglichen Gebrauch rahmen, sind sie den Benutzern durchaus für die kommunikative Handlung präsent. Den Nutzern ist typischerweise klar, daß eine E-Mail nicht sofort gelesen wird und welche Möglichkeiten der Anschlußkommunikation gegeben sind. Aber es wird im Alltagsgebrauch von einer reibungslosen Übermittlung der Nachricht ausgegangen. Etwelche Mißverständnisse werden entsprechend der fehlerhaften eigenen Formulierung bzw. der fehlerhaften Interpretation des Gegenübers zugeschrieben, nicht den medialen Bedingungen. Aus dieser alltagspraktischen Sicht vermindert sich die Wahrscheinlichkeit einer gelingenden Kooperation in Form der F/OSS zumindest nicht. Das Medium erscheint, solange es funktioniert, als eine neutrale Vermittlungsinstanz. Sichtbar wird bereits in dieser Einstellung die je speziﬁsche Zeitlichkeit der Medien. Aber von welchen generellen Merkmalen der computerbasierten Medien kann aus medientheoretischer Sicht auf die (Un)Wahrscheinlichkeiten geschlossen werden, die von den computerbasierten Instrumenten der Kommunikation in oder jenseits dieser subjektiven Wahrnehmungen ausgehen? Bei der Sichtung der Debatte fällt auf, daß die Zuschreibung solcher Merkmale recht pauschal erfolgt, wobei paradigmatisch jeweils ein oder zwei passende computerbasierte Medienformen zur Begründung herangezogen werden. So wird beispielsweise generell von einer anonymen Kommunikation im Internet ausgegangen (vgl. etwa Thiedecke 2000; Esposito 1995; Krämer 2000), die zwar in den elektronischen Netzen möglich ist, die aber auch durch geänderte Spielregeln ausgehebelt werden kann. Gerade im Usenet hat sich ein gegenteiliger Trend herausgebildet, der etwa die Angabe von Realnamen und antwortfähigen E-Mailadressen fordert (vgl. etwa http://www.chemie.fu-berlin.de/outerspace/netnews/netiquette.html, Punkt 14). Auch in der F/OSS wird darauf Wert gelegt, daß Texte und Code einer Person zugeschrieben werden können. In diesen Zusammenhängen kann also keinesfalls von der Kommunikation mit »Chiffrenexistenzen« (Krämer 1997: 96) die Rede sein, sondern eher von einer

2.3 Medientheorie und computerbasierte Medien

51

Re-personalisierung, wenn auch die Wahrnehmung der Person medial eingeschränkt ist.57 Dagegen ist das Merkmal der Schriftlichkeit in den für die F/OSS relevanten Medien durchaus gegeben58 : Die schriftliche Kommunikation macht aufgrund der räumlichen und, im Fall von asynchronen Medien, evtl. zeitlichen Trennung alle Verweise auf den jeweiligen Kontext problematisch und mißverständlich. Gleichzeitig ist dieser Kontext essentiell für das Verstehen der Kommunikation. Eine andere Quelle von Mißverständnissen ist die fehlende parasprachliche Ebene, Mimik und Gestik, die in der persönlichen Interaktion gewisse Bedeutungsnuancierungen erlauben (Ironie, Sarkasmus, Humor) und die schriftlich schwer zu signalisieren sind. Im Gegensatz zu anderen Formen der schriftlichen Telekommunikation, etwa dem Buchdruck, sind jedoch mit der Interaktivität (vgl. Esposito 1995; Wehner 1997a; Wenzel 2001) Möglichkeiten gegeben, Rückfragen zu stellen, während die Kommunikation stattﬁndet, um die Erläuterung unklarer Stellen oder um Ergänzungen zu bitten. Dabei haben die Kommunikationen auch in asynchronen Medien einen gewissen zeitlichen Horizont, in dem ein Thema aktuell ist und der sich auch in Form eines sogenannten »threads«, einem inhaltlich mehr oder weniger konsistenten Kommunikationszusammenhang, in der Struktur der Kommunikation niederschlägt. Dabei haben die Teilnehmer an der Kommunikation selbst immer nur den vom Computer aufbereiteten und dargestellten Text vor sich: sie agieren mit einem Text und interagieren nicht mit einer realweltlichen Person. Durch die Repersonalisierung in der F/OSS werden diese schriftlichen Aussagen, Überzeugungen, Meinungen zwar wieder einer Person zuschreibbar, die hinter der Symbolkette des Namens, der Emailadresse oder des sog. Nicknames konstruiert werden kann. Aber die Schriftlichkeit der computerbasierten Kommunikation erhöht 57 Dabei spielen gerade für diesen Prozeß der Re-personalisierung in der F/OSS ergänzende mediale Formen eine wichtige Rolle: etwa die Homepage des Entwicklers oder sogenannte »Weblogs« oder »Blogs«, also im World Wide Web (WWW) veröffentlichte Tagebücher. Gerade die Möglichkeit der Chiffrenexistenz zeitigt die Gegenposition der authentischen Persönlichkeit, vgl. dazu Sebald (2007). 58 Wenn auch nicht generell für alle computerbasierten Medien, vgl. etwa IP-Telefonie, Onlinevideospiele, Videokonferenzen etc.

52

2 Zur Theorie der technischen Grundlagen

vor allem auf Grund des fehlenden Kontextbezugs eher die Unwahrscheinlichkeit einer darauf gegründeten Kooperation. Andere der mit dem Computer und dessen Vernetzung gegebenen Merkmale als die Schriftlichkeit der telematischen Kommunikation müssen allerdings für jedes computerbasierte Medium einzeln analysiert werden. Generelle Aussagen verdecken die jeweiligen Speziﬁka. Im folgenden sollen deshalb die für die F/OSS wichtigsten technischen Medien in ihren charakteristischen Verwendungszusammenhängen kurz dargestellt und auf ihre werden. Quelltext als Medium Das zentrale Medium der F/OS-Softwareentwicklung ist der Quelltext der zu entwickelnden Programme. Die oben entwickelten Eigenschaften von Software machen den Quelltext zu einem besonderen Medium. Die formalisierten Signiﬁkantenketten haben für die Maschine keine Bedeutung, d. h. eine Interpretation des Quelltextes erübrigt sich. Der Quelltext kann direkt für eine Handlung benutzt werden, d. h. er kann in einen vorhandenen Code integriert59 und kompiliert werden. Das so entstandene Programm kann dann gestartet und benutzt werden. Der Quelltext ist damit nicht in erster Linie ein kommunikativer Akt, sondern vor allem eine Handreichung für einen vom Empfänger zu vollziehenden performativen Akt. Der Code läuft entweder oder er läuft nicht. Wenn er läuft, kann als kommunikativer Anschluß allenfalls der Stil diskutiert werden. Eine Diskussion eines Algorithmus wird erst fällig, wenn zwei verschiedene Lösungsansätze für ein Problem geliefert werden. Läuft der Code nicht, ist erst einmal Fehlersuche angesagt, die ebenfalls unabhängig von Interpretationen ist. Es gilt die fehlerhafte Signiﬁkantenkette zu ﬁnden und entsprechend zu verbessern oder gegen eine andere auszutauschen. Es ist damit ein neuer performativer und produktiver Akt nötig, der den Fehler behebt, oder eine neue Funktion für das Programm schafft. An diesen performativen und produktiven Akt kann wieder Kommunikation anschließen. Damit 59 Normalerweise wird nicht das gesamte Programm herumgeschickt, sondern nur ein sog. Patch, also kürzere Ergänzungen zu einem vorhandenen Programmcode. Dieser Patch muß vor dem Kompilieren in den Programmcode integriert werden. Dafür gibt es spezielle Programme, ebenso wie zur Generierung eines solchen Patches aus den Veränderungen, die am Programmcode vorgenommen wurden.

2.3 Medientheorie und computerbasierte Medien

53

wird im Normalfall zwischen diese kommunikativen Akte eine Handlungssequenz (zumindest Kompilieren und Testen) eingeschoben. Diese Handlungssequenz, und das ist das Entscheidende, operiert schon mit dem (mehr oder weniger fertigen) Produkt selbst, nicht mit einem Plan oder Entwurf desselben. Durch die durch Bezeichnungen und Kommentare hinzugefügte, nur für computeralphabetisierte Menschen signiﬁkative Ebene wird der Quelltext zu einem Kommunikationsmedium: »But a written program has another face, that which tells its story to the human user.« (Brooks 2001: 164) Ein geübtes Auge kann aus einem gut strukturierten Programm Aufbau, Konzept und Funktionsweise der Software herauslesen. Umgekehrt ist es sehr schwer, schlecht dokumentierten Code60 mit nicht aussagekräftigen Benennungen zu verstehen. Die Lesbarkeit ist also sehr vom jeweiligen Programmierstil abhängig, was gerade in Projekten mit einer größeren Zahl von Beteiligten zum Tragen kommt. Damit hat der Quelltext neben der performativen Seite auch eine kommunikative, die aber von der performativen unabhängig ist. Das Programm würde auch ohne diese signiﬁkative Ebene laufen. Die bleibt jedoch wichtig für die rein mediale Kooperation. Der formalisierte, von jeglichem Kontext gelöste Quelltext ist insofern ein ideales Medium für rein mediale Kooperation: er transportiert Signiﬁkanten, die keine Bedeutung an sich haben, die jedoch trotzdem, über die lineare Abfolge und Gliederung sowie Kommentare und Bezeichnungen, Aufbau und Struktur eines Programmes in sich tragen, und so zum einen direkt in die produktiven Akte eingespeist werden können und zum anderen Aussagen über die Form des Produktes ermöglichen. Mit dieser Besonderheit, daß im Quelltext immer schon das Produkt selbst mitkommuniziert wird, wird die Unwahrscheinlichkeit der gelingenden Kooperation stark gesenkt. Usenet Es ist zwar prinzipiell vorstellbar, daß eine mediale Kooperation in der Softwareentwicklung über nicht elektronische Medien erfolgt, etwa 60 Die Dokumentation bezieht sich hier nicht auf die Art und Weise der Benutzung des Programms, seiner Funktionen etc., sondern auf die Prozesse im Programm selbst: welche Variablen werden für welchen Bereich deﬁniert, was macht die jeweilige Funktion etc.

54

2 Zur Theorie der technischen Grundlagen

durch Ausdrucken des Quelltextes, Versenden desselben per herkömmlicher Post, Abtippen und Kompilieren etc., aber eine weltweit verteilte Kooperation ist damit nur schwer vorstellbar.61 Ein entscheidender Schritt war insofern die Entwicklung der computerbasierten Medien und die Ausbreitung der Vernetzung. Nun wurde eine schnelle und wenig aufwendige Übermittlung der Quelltexte an eine Vielzahl von Interessierten möglich. Vor allem in den Anfangszeiten der F/OSS dominierte das sog. Usenet, eine Art elektronisches »schwarzes Brett«, die Kommunikationen (vgl. 3.3). Von der Form her gleicht das Usenet den Mailinglisten (für die speziﬁschen Merkmale vergleiche deshalb unten), es wird inzwischen in der F/OSS seit den 90er Jahren vor allem als Forum für Anwendende benutzt, in das sich zwar einzelne Entwickler einschalten, das aber für die Entwicklung selber kaum Bedeutung hat. Mailinglisten Das wichtigste Kommunikationsmedium in den F/OSS-Projekten sind Mailinglisten.62 Das ist eine Form der maschinellen Verteilung einzelner E-Mails an eine mehr oder weniger große Zahl von »Abonnenten«. Der genaue Leserkreis ist dem Schreibenden dabei unbekannt und diese Unsicherheit wird durch die übliche Archivierung jedes Beitrags noch vergrößert.63 Die E-Mail wird im Fall einer Mailingliste also an eine anonyme und unbekannte Öffentlichkeit, an »einen unerkennbaren Nebel von Lesern« (Esposito 1995), geschickt. Damit schafft diese »digitalisierte Schrift« (Wehner 1997b: 134) speziﬁsche Veränderungen in allen drei Sinndimensionen. Zeitlich ist die Lektüre im Verhältnis zum Schreiben desynchronisiert, auch wenn die Verteilung weltweit und sehr schnell erfolgt. Die schriftliche Kommunikation ist zwar noch asynchron, aber enorm beschleunigt. Die Zeit der Lesenden muß nicht mit der Zeit des Schreibenden koordiniert werden, beide 61 In kleinräumigen Zusammenhängen von wissenschaftlichen Instituten und größeren Unternehmen hat diese Form der kooperativen Softwareentwicklung durch Austauschen des Quelltextes durchaus funktioniert, etwa am MIT oder in Berkeley, vgl. Levy 2001; McKusick 1999. 62 Vgl. dazu auch die Beschreibung von (Stegbauer 2001: 24 ff.). Generell zum Medium E-Mail vgl. auch Buck (1999); Rudy (1996). 63 »Be careful when you put yourself out there in an electronic forum. Your typos and errors of grammar will haunt you forever.« (Torvalds und Diamond 2001: 106)

2.3 Medientheorie und computerbasierte Medien

55

können sich also in je eigenen »komplexen Konstruktion[en] von Zeithorizonten bewegen« (Esposito 1995: 231), was für die Koordination von freiwilliger Arbeit in einem potentiell globalen sozialen Umfeld sehr wichtig ist. Gleichzeitig mit der Lektüre ist dem Lesenden in diesem Medium auch die Möglichkeit der Antwort gegeben (wobei Schreiben und Veröffentlichung nur durch einen Tastendruck oder einen Klick getrennt sind). In der Sachdimension sind neue Formen der Auflösung und Rekombination möglich, und das nicht mehr nur beim Lesevorgang, sondern, durch die sofortige Antwortmöglichkeit, auch beim Schreiben. Dieses Interaktivitätspotential senkt auch die Anforderungen an den Text in Bezug auf Abstraktion, Explikation und Kontextunabhängigkeit. Die Lesenden können Rückfragen an den Schreibenden stellen, Mißverständnisse und Lücken können auf diese Weise behoben werden, wenn auch gerade damit nichtfunktionale Kommunikation, also Formen des ›Rauschens‹ etwa als ausufernde Regeldiskussionen, gerade durch diesen Mechanismus und die in einem dezentralen Netz fehlenden Kontroll- oder Filterinstanzen getriggert wird. In der Sozialdimension schließlich wird die Möglichkeit, global zu kommunizieren, wenn niemand anwesend ist (die schon mit der Schrift gegeben war), durch die Beschleunigung zu einer Möglichkeit der Koordination von Handlungen. So entsteht ein geteilter Text, in dem die Koordination der Produktion von statten gehen soll. Die speziﬁsche, ﬂexible Zeitlichkeit dieses Mediums kommt einer potentiell globalen Kooperation entgegen. Im Unterschied zu persönlichen Interaktionen ist jedoch die Reﬂexivität der Wahrnehmungen nur sehr eingeschränkt gegeben. Es bilden sich in diesen schriftlichen Kommunikationen mit ihrer begrenzten Wahrnehmbarkeit des Gegenübers nur schwer Vertrauensbeziehungen heraus, die helfen, eine Kooperation zu stabilisieren und auf Dauer zu stellen. Gleichzeitig, das zeigt sich in anderen kommunikativen Zusammenhängen, die auf elektronischer Schriftlichkeit gründen, nimmt das ›Rauschen‹, enorm zu. In der Kommunikation über Mailinglisten werden die Unwahrscheinlichkeiten einer gelingende Kooperation eher erhöht und nicht gesenkt.

56

2 Zur Theorie der technischen Grundlagen

Internet Relay Chat Im Gegensatz zu den Mailinglisten handelt es sich beim Internet Relay Chat (IRC) um ein nahezu synchrones Medium.64 Mit IRC ist es möglich, mit einer größeren Anzahl von Kommunikationspartnern schriftlich und fast gleichzeitig zu kommunizieren. Dabei wird der von den Teilnehmenden »durcheinandergeschriebene« Text vom IRC-Programm linear sequentialisiert. Sämtliche Äußerungen werden gleichwertig dargestellt (vgl. auch Thimm 2001; Hoffmann 2004; Ziegler 2004). Das für die F/OSS-Verwendung von IRC wichtige Speziﬁkum ist die damit gesetzte Zeitlichkeit der Kommunikation. Aufgrund der BeinaheSynchronizität ist der zeitliche Antwortrahmen im IRC wesentlich kleiner als auf einer Mailingliste. Zwar können deshalb eventuelle Mißverständnisse schneller behoben werden, aber das Medium fordert auch einen viel größeren Zeitaufwand, weil permanent Kommunikation stattﬁndet bzw. stattﬁnden kann. Das persönliche Zeitmanagement wird durch IRC wesentlich stärker restringiert als durch Mailinglisten. Ein weiterer Faktor in der Verwendung dieses Mediums ist das Problem der Kommunikation über verschiedene Zeitzonen hinweg, etwa zwischen Europa und Australien, die aufgrund der differenten lokalen Tageszeiten schwierig sein kann. Für potentiell globale Kommunikationszusammenhänge ist das eine größere Hürde. Die Verwendung von IRC hat ihren Schwerpunkt entsprechend in Projekten mit stärkerer regionaler Zentrierung oder für regionale Subgruppen in globalen Projekten. Resümee Zusammenfassend kann gesagt werden, daß zwei der technischen Konstitutionsbedingungen der F/OS-Softwareentwicklung nun genauer analysiert sind: Software und computerbasierte Medien. Die formalisierte Schriftlichkeit der Software macht sie zu einem die Wahrscheinlichkeit des Gelingens erhöhenden Gegenstand von medial basierter Kooperation; eine Kooperation, die zudem davon proﬁtiert, daß das symbolische Produkt selbst kommuniziert wird (d. h. keine weitere 64 Der jeweils eingegebene Text kann vor dem Absenden kontrolliert werden, was eine gewisse Zeitverschiebung durch die individuellen Rezeptions- und Schreibgeschwindigkeiten beinhaltet.

2.3 Medientheorie und computerbasierte Medien

57

materielle Realisierung braucht) und gleichzeitig als Medium dient, das performativ-produktive und kommunikative Anschlüsse ermöglicht. Zusammen mit der relativ energie- und kostengünstigen Computerund Vernetzungstechnologie ergibt sich daraus die Möglichkeit einer produktiven globalen Kooperation über die schnellen und trotzdem mit einer ﬂexiblen Zeitlichkeit funktionierenden Mailinglisten. Dem stehen die Schwierigkeiten in der nicht-formalisierten elektronischen Schriftlichkeit entgegen, die eine gelingende Kooperation und Koordination der Produktion eines derart komplexen Gegenstandes eher unwahrscheinlich machen. Gerade die Dauerhaftigkeit der Kooperation ist in einer vorwiegend auf computerbasierten Medien fundierten Sozialität zweifelhaft, weil die stabilisierende Funktion persönlicher Interaktionen fehlt. Zusätzlich wird der Rekrutierungspool an potentiell Teilnehmenden dadurch eingeschränkt, daß durch die notwendige Computeralphabetisierung eine Wissensschwelle eingezogen wird. Und es bleibt die größte aller Unwahrscheinlichkeiten: die mögliche Konkurrenz zur kapitalistischen Softwareproduktion.

3 Diskurs Le discours distribuait l’espace de manière à le stratiﬁer en deux niveaux. D’une part, un espace socio-économique, organisé par une lutte immémoriale entre »puissants« et »pauvres« [. . .]. D’autre part, distinct de cet espace polémologique [. . .] il y avait un espace utopique. (Michel de Certeau65 )

Seit mehr als zwanzig Jahren gibt es F/OSS mit einer Vielzahl von Projekten. Die im vorigen Kapitel aufgezählten Unwahrscheinlichkeiten wurden demnach in Wahrscheinlichkeiten transformiert, der Möglichkeitsraum wurde besetzt. In einem ersten empirischen Zugang wird deshalb im Folgenden nach den zentralen Prinzipien und Gemeinsamkeiten gefragt, wie sie in dem alle Projekte übergreifenden Diskurs als Selbstthematisierungen auftauchen. Von dem Diskurs der Free/Open Source-Softwareentwicklung zu sprechen ist insofern problematisch, als es schwierig ist, in diesem weiten Feld von kommunikativen Zusammenhängen irgendeine Form von projektübergreifender, aber abgrenzbarer Einheit zu ﬁnden.66 Nichtsdestotrotz hat sich ein umfangreiches Feld von Aussagen zu dieser Produktions- und Distributionsweise über der Ebene der einzelnen Projekte entwickelt. Dieser Diskurs ﬁndet statt in unterschiedlichsten Medien, wird getragen von einer Vielzahl von Personen und läßt sich für analytische Zwecke unterteilen in die Diskurse der Entwickler 65 Der Diskurs teilte den Raum in zwei Bereiche auf. Einerseits gab es einen sozioökonomischen Raum, der von dem uralten Kampf zwischen »Mächtigen« und »Armen« organisiert wurde. [. . .] Neben diesem kriegswissenschaftlichen Raum [. . .] gab es einen utopischen Raum. Certeau (1988: 56, S. 32 der frz. Ausgabe). 66 Es wird versucht, eine solche Einheit in Form einer Gemeinschaft zu konstruieren (vgl. 3.4 und Sebald 2005).

60

3 Diskurs

selbst, den Diskurs in den ›herkömmlichen‹ Massenmedien in Bezug auf die F/OSS und den Diskurs der Anwender. Ich werde mich im Folgenden auf den Diskurs der Entwickler selbst beschränken, soweit er über die Grenzen des jeweiligen Projektes hinaus wahrgenommen wird oder werden kann. Das geschieht, weil in den diskursiven Selbstthematisierungen die kollektiven Legitimationen und Relevanzen sichtbar werden, die, wenn die im vorigen Kapitel entwickelten Thesen stimmen, sich innerhalb dieser Rahmenbedingungen bewegen müssen. Dabei geraten unweigerlich, weil konstitutiv für Identitäten, die Grenzziehungen nach außen und auch innerhalb einzelner Fraktionierungen in den analytischen Blick. Auch wird es interessant zu beobachten sein, wie sich entlang der aufgezeigten Wahrscheinlichkeiten und Unwahrscheinlichkeiten zentrale konstitutive Prinzipien oder Reibeﬂächen und Trennungslinien bilden.

3.1 Auswahl und Methode Der Diskurs der Entwickler der F/OSS ﬁndet sich vor allem in Webportalen, die auf die Sammlung von Nachrichten, Interviews, Kommentaren, Artikeln, Stellungnahmen aus den einzelnen Projekten spezialisiert sind. Auch hier gibt es eine Vielzahl von Angeboten67 . Neben diesen allgemeinen Portalen gibt es noch spezialisierte Portale für einzelne Projekte, für Sicherheitsfragen, seit 2003 für die rechtliche Auseinandersetzung mit der Firma SCO etc. Darüberhinaus hat sich ein breites Spektrum an Zeitschriften und Büchern etabliert, von denen der Großteil allerdings auf technische Fragen, Dokumentationen einzelner Programme oder Hilfestellungen gerichtet ist. Es ﬁnden sich jedoch auch immer wieder grundsätzliche Stellungnahmen einzelner Entwickler oder Artikel zu politischen, ökonomischen oder philosophischen Fragen zur F/OSS. Zusätzlich sind inzwischen zwei Sammelbände und zwei Biographien der Protagonisten erschienen. Trotz der mit der Konzentration auf den Entwickler-Diskurs verbundenen Beschränkung in der Materialgrundlage ergibt sich damit 67 Etwa LWN (Linux Weekly News, http://lwn.org), Slashdot (http://www.slashdot.org), Rootprompt (http://www.rootprompt.org), Pro Linux (http://www.pro-linux.de), um nur einige Beispiele zu nennen.

3.1 Auswahl und Methode

61

noch ein enormer, im Rahmen einer Dissertation unmöglich zu bearbeitender Textkorpus. Ich beschränke mich für die Diskursanalyse im Folgenden auf die Texte aus diesem Korpus, auf die immer wieder Bezug genommen oder verwiesen wird. Diese zentralen Texte markieren gleichzeitig herausragende Punkte in der Geschichte der F/OSS-Netzwerke. Der Diskurs läßt sich historisch und in groben Zügen in die folgenden drei Abschnitte gliedern. Die Historizität bezieht sich jedoch nur auf die Entstehungsdaten; es ist nicht so, daß diese »Semantiklinien« (Hajer 1995) sich gegenseitig ablösen, sondern sie laufen nach wie vor parallel nebeneinander und markieren damit gegenwärtige Fraktionierungen. Der Diskurs begann, in etwa zeitgleich mit den ersten Projekten, Mitte der 80er Jahre mit der Gründung der Free Software Foundation (FSF) und der Veröffentlichung ihres Programmes in Form des sog. »GNU Manifestos«. Parallel dazu belebte sich das Internet in Form von Usenetgruppen, Mailboxes und Mailkontakten. In diesen Anfangszeiten waren vor allem Techniker aus den Rechenzentren von Universitäten oder großen Unternehmen Pioniere der Vernetzung. Diese Techniker und Programmierer haben die Möglichkeiten dieses neuen textförmigen Mediums relativ früh dazu benutzt, sich gegenseitig Programmcode, meist zur verbesserten Nutzung eben dieses Mediums, zuzuschicken und diesen gemeinsam weiterzuentwickeln. Aus diesen Technikernetzen heraus begann 1991 auch die Entwicklung des für den gesamten Diskurs emblematischen Betriebssystems »Linux«. Diese Techniker haben in Abgrenzung zur FSF eine eigene »unpolitische«, pragmatische Semantik entwickelt. Während des »New Economy«-Booms, und eng verbunden mit dem Ereignis der Freigabe der Quellen des Netscapebrowsers am Beginn des Jahres 1998, entwickelte sich die »Open Source«-Semantik, wiederum als explizite Abgrenzung zur »Free Software«, allerdings von einer ökonomisch-neoliberalen Seite her. Der Fokus verschob sich, den Interessen der Trägergruppen entsprechend, auf die ökonomischen Vorteile der marktgemäßen neuen Produktionsweise. Diese drei textuellen Zentren des Entwicklerdiskurses werden im Folgenden analysiert. Ein Instrumentarium zu dieser Diskursanalyse ﬁndet sich in der »Wissenssoziologischen Diskursanalyse«, wie sie Reiner Keller entwickelt hat (Keller 2005; 2001; 2003). Dieser Versuch einer »Über-

62

3 Diskurs

setzung« bzw. »Vermittlung« (Keller 2005: 11) zwischen einer eher strukturalistisch orientierten Diskursanalyse á la Foucault und einer verstehenden Soziologie im Anschluß an Alfred Schütz will damit keineswegs über die wissenschaftstheoretischen oder methodologischen Unvereinbarkeiten der Theorieprogramme hinweg operieren, sondern durch den behutsamen Versuch einer Integration von Diskursanalyse in wissenssoziologische Theorie und Methodologie für die empirische Forschung fruchtbare Ergebnisse erzielen. Die von Foucault verweigerte hermeneutische Methode ist unerläßlich für sozialwissenschaftliche Gegenstände und sozialwissenschaftliches Arbeiten, weil diese Gegenstände, die denkenden, handelnden und sprechenden Subjekte, selbst ihre Umwelt immer schon deuten und diese Deutungen in ihr Sprechen integrieren. Aus diesen »Konstrukten Erster Ordnung« leiten sich »die wissenschaftlichen Kategorien ab, sie bilden Konstrukte Zweiter Ordnung« (Knoblauch 1995: 13).68 Das Verhältnis dieser beiden Konstruktebenen bestimmt sich dann entprechend dem »Postulat der Adäquanz«: »Das Postulat der Adäquanz verlangt, dass die typische Konstruktion mit der Totalität sowohl unseres täglichen Lebens als auch unserer wissen- schaftlichen Erfahrung übereinstimmen muss.« (Schütz 1972: 49) Durch die Kombination mit der Diskursanalyse wird aber auch ein Manko der hermeneutischen Wissenssoziologie beseitigt. Der Schwerpunkt der Untersuchungen lag bisher im mikrosoziologischen Bereich, auf der Rekonstruktion von »Allerweltswissen« (Berger und Luckmann 1998: 16) in seiner sozialen und interaktiven Konstruktion in der meist kleinräumigen Lebenswelt. Dabei wird die Rolle von gesellschaftlichen Institutionen und Strukturen zwar erwähnt, aber selten mit in die Analyse einbezogen (vgl. Keller 2001: 120f.). Damit gerät die Eigenlogik, die Eigenständigkeit und die Strukturierungskraft der kollektiven Objektivierungen an den Rand des theoretischen und empirischen Blickwinkels. Deshalb kann sich die Kombination dieser beiden wissenssoziologischen Methoden sich als fruchtbar erweisen. Die einzelnen Texte wurden dann in mehreren Arbeitsschritten analysiert: nach einer inhaltsanalytischen Paraphrasierung wurden die Artikel in tabellenartiger Form bezüglich der Textstruktur, der darin 68 Vgl. dazu vor allem Schütz 1971: 50.

3.2 Zurück ins Paradies

63

aufgeworfenen Problemstrukturen und der benannten Akteure zerlegt. Diese tabellarische Übersicht diente zusammen mit der Inhaltsanalyse auch der Auswahl von Sequenzen zur Feinanalyse.69 Mit deren Hilfe konnten dann speziﬁsche Deutungsmuster und Sinnzuschreibungen rekonstruiert und die grundlegenden Gemeinsamkeiten und Differenzen im Diskurs der F/OS-Entwickler herausgearbeitet werden. Diese Ergebnisse wurden schließlich abgeglichen mit weiteren Texten aus dem Feld, den Aussagen in den Interviews und dem Kontextwissen des Interpretierenden. So entstand die Rekonstruktion des Diskurses der F/OS-Entwickler.

3.2 Zurück ins Paradies Am 27.09.1983 um 10:35:59 Uhr Paciﬁc Standard Time erschien in den Newsgruppen net.unix-wizards und net.usoft ein Posting eines gewissen Richard M. Stallman unter dem Titel »Free Unix!«. Dieses Posting wurde Grundlage des 1985 in der März-Ausgabe des Dr.Dobb’s Journal70 veröffentlichten »GNU-Manifestos«, dem Grundsatztext der 1985 gegründeten Free Software Foundation. Der Text wurde danach etwas überarbeitet und 1993 schließlich, ergänzt um fünf Fußnoten, die einige Mißverständnisse ausräumen sollten, auf den Webservern der Free Software Foundation erneut öffentlich zugänglich gemacht. Das ist der Beginn des Diskurses zu »freier Software«, der die F/OSS von Beginn an bis heute prägt. Im Folgenden werden die zentralen Passagen des GNU-Manifestos und der GNU General Public Licence, der GPL-Lizenz, interpretiert.

69 Die Feinanalyse erfolgte kontrolliert in Gruppen zusammen mit anderen Promovierenden mit dem gleichen methodischen Ansatz oder zumindest mit einer Diskussion der Ergebnisse. Ich möchte an dieser Stelle Thomas Dörﬂer, Claudia Globisch, Andreas Klärner, Markus Säbel und vor allem Jan Weyand danken, die meine Interpretationsversuche hilfreich begleiteten. 70 »Dr. Dobb’s Journal of Computer Calisthenics and Orthodontia« (Dr. Dobbs Journal für Computerfreiübungen und Beseitigung von Zahnfehlstellungen) wurde 1976 gegründet, entstanden aus einem BASIC-Magazin im Umfeld der entstehenden Mikrocomputerszene in Kalifornien. Seither hat es sich zu einer der wichtigsten Computerzeitschriften in den Vereinigten Staaten entwickelt.

64

3 Diskurs

3.2.1 Give it away free Am Beginn des GNU-Manifests, »GNU Manifesto«, des öffentlich dargelegten Programms der Free Software Foundation, ﬁndet sich als eine Art Wappentier das GNU-Logo, der Kopf eines Gnus, der afrikanischen Kuhantilope, die in großen Herden die Savannen durchstreift, umﬂattert von zwei bannerartigen Spruchbändern, auf denen oben die Frage »What’s GNU?« und unten die Antwort »GNU’s Not Unix!« in wacke71 GNU-Logo ligen Großbuchstaben geschrieben ist. Das Gnu taucht öfter in Logos oder Bildsymboliken auf, sei es eher stolz, wie es von diesem Bild behauptet wird, freundlich lachend oder als ﬂiegendes Superheldengnu mit GPL-Uniform (zusammen mit dem Linuxpinguin). Das Gnu steht für ein friedliches Weidetier, das gegen seine zahlreichen Feinde allein mit seiner Zahl, seiner Fortpﬂanzungskraft und seinem Herdenverhalten besteht. Die Feinde (Löwen, Hyänen, Leoparden, Geparden, Krokodile) erwischen meist nur die kranken oder jungen Tiere. Wenn hier auf Software zurückgeschlossen wird, könnte die Verwendung dieses Bildes bedeuten, daß freie Software gegen die raubtierhafte Konkurrenz bestehen kann, wenn die Software sich schnell vermehrt und wie eine »Herde« gut zusammenarbeitet. Die Namensﬁndung selbst war wohl nicht von diesen Bedeutungen bestimmt. Laut Williams (2002: 24) ging es um die Suche nach einem rekursiven Akronym, das die Elemente »Not Unix« enthielt, G war der einzige passende Buchstabe. Auch wird empfohlen das G auszusprechen (»gahnju«), um Verwechslungen zu vermeiden. Dieses Logo ist seither die bildförmige Visualisierung der FSF.72 Der Text des Manifestos beginnt mit den Worten: 71 http://www.gnu.org/graphics/whats-gnu-sm.jpg 72 Das GNU-Betriebssystem wird HURD genannt, eine Sammlung von kleinen Servern (Mikrokernelarchitektur), die Stallman selbst mit einer Herde Gnus vergleicht (Stallman 1999: 65).

3.2 Zurück ins Paradies

65

»GNU, which stands for GNU’s not Unix, is the name for the complete Unix-compatible software system that I am writing so that I can give it away free to everyone who can use it.« Das rekursive Akronym »GNU« mit der Erläuterung »GNU’s Not Unix« schickt die Lesenden, die auf der Suche nach der Bedeutung der Abkürzung sind, in eine Endlosschleife, weil der erste Buchstabe selbstreferentiell wieder nur auf die Abkürzung GNU verweist. Rekursivität ist eine wichtige Operation in der Programmierung, muß aber sorgfältig (mit Bedingungen) implementiert werden. GNU ist nur insofern bestimmt, als es nicht Unix ist. Damit wird die Abgrenzung zu dem zu dieser Zeit bereits kommerzialisierten Unix-Betriebssystem73 vollzogen. Durch die iterierte und negierende Aufnahme der Bezeichnung »Unix« in das eigene Akronym wird aber auch ein Bezug auf das in Technikerkreisen beliebte Betriebssystem hergestellt. Das bestätigt sich in der näheren Erläuterung, die sich im Nebensatz anschließt. Der Name steht für ein komplettes Unix-kompatibles Softwaresystem. Die Ablehnung bezieht sich aufgrund dieser Kompatibilität nicht auf die technische Seite des Betriebssystems. Die wird, wie später deutlich wird, für gut oder sogar sehr gut befunden. Das Softwaresystem, also nicht nur ein Betriebssystem, wie es Unix eigentlich ist, sondern zusätzlich eine Vielzahl von Anwendungsprogrammen, schreibt der Autor gerade, um es »frei wegzugeben«. Der Zweck ist demnach die freie Weitergabe der Programme, nicht die Technik, nicht die Produktionsweise. »Frei« kann sich dabei auf die (Kosten-)Freiheit oder auf die Freiheit von Benutzungseinschränkungen beziehen. Dieser Aspekt bleibt hier offen; aus der 1993 beigefügten Fußnote und dem mandra-artig wiederholten »Free as in free speech not in free beer« kann jedoch auf letzteres geschlossen werden: Stallman 73 Unix wurde Anfang der 70er Jahre von Dennis Ritchie und Ken Thompson in den Bell Laboratories, der Forschungsabteilung des AT&T-Konzerns, entwickelt. Es wurde anfangs kostenlos an Interessierte verteilt. Mit der wachsenden Popularität aufgrund seiner Multitasking-Fähigkeiten und der Portierung, der Anpassung an verschiedenste Hardware, begann AT&T Ende der 70er Jahre, Unix zu kommerzialisieren, d. h. es wurde nurmehr gegen Lizenzgebühren zur Benutzung freigegeben. Diese Lizenzgebühren mußten auch die Anwender der Berkeley Software Distribution (BSD), einer Unixversion, bis zur gerichtlichen Einigung 1994 bezahlen.

66

3 Diskurs

will Benutzungseinschränkungen, die sich aus den Lizenzierungspraktiken von Software ergeben, aufheben. Diese Einschränkungen betreffen die Nutzung, die Vervielfältigung, die (Weiter-)Verteilung und die Änderungsmöglichkeiten. Letztlich geht es darum, in Abgrenzung zu einer »unfreien« Praxis das Wissen, das in der Software steckt und im computersprachlichen Quelltext expliziert wurde, frei verfügbar und verteilbar zu machen, gegen die beginnende Kommerzialisierung dieses Wissens durch urheberrechtlich abgesicherte Lizenzvereinbarungen.74 Durch eine so abgesicherte Beschränkung der Nutzung und Weitergabe erhält Software einen quasi warenähnlichen Status75 , der eine Verwertung durch Lizenzgebühren sicherstellt. Stallman muß also, das impliziert seine Überlegung, mit einem auf dem Copyright basierenden Verfahren sicherstellen, daß GNU-Software von dieser Form von Verwertungspraxis ausgeschlossen bleibt. Um in Software inhärentes Wissen verfügbar zu machen, ist die Verbreitung des Quelltextes notwendig. Die Lizenz muß daher neben einem Verbot von Nutzungsgebühren die Weitergabe des Quelltextes sicherstellen (vgl. 3.2.3). Stallman will die GNU-Software allen geben, »who can use it«. Das schließt eine Beschränkung des Gebrauchs aus, sowohl eine Beschränkung hinsichtlich des Einsatzfeldes, als auch eine Beschränkung hinsichtlich der Art des Gebrauchs, sei es nun die Benutzung entsprechend dem ursprünglichen Zweck eines Programmes, sei es die Anpassung an die eigenen Bedürfnisse. Jedoch bleibt der Autor der Software, in diesem Fall Stallman, die zentrale Verteilungsinstanz, er schreibt und gibt weiter, die anderen benutzen. Der Eigentumsbegriff wird damit umgedreht: statt einer Nutzungseinschränkung bzw. einer Ausschließung von der Nutzung wird die Möglichkeit der Verteilung von Software 74 Grundlage für diese Lizenzvereinbarungen ist die Änderung des US-amerikanischen Urheberrechts mit dem Copyright Act von 1976, der die Urheberrechte auch auf Softwareprogramme ausdehnte. Damit unterlag ein Programm in seiner konkreten Form, nicht einzelne darin ausgeführte Funktionen und Verfahren wie im Fall der Softwarepatente, dem Copyright. 75 Von einer Ware unterscheidet sich Software trotz der rechtlichen Eigentumsabsicherungen nach wie vor dadurch, daß sich die Nutzungsausschließung nicht endgültig absichern läßt und die Rivalität in der Nutzung nicht gegeben ist, vgl. etwa DeLong und Zoomkin 2000 und unten Abschnitt 6.1.

3.2 Zurück ins Paradies

67

(und damit Wissen) zentraler Bestimmungsgrund von Eigentum.76 Mit der Formulierung »everyone, who can use it« erhält das Programm einen utopischen Zug: potentiell versorgt Stallman die gesamte Menschheit mit Software, zumindest den computerbenutzenden Teil der Menschheit, mit GNU-Software und befreit sie damit von Lizenzgebühren und Nutzungseinschränkungen. Das wird auch im letzten Absatz der ersten Version von 1983 dieses Textes deutlich, in dem der Autor nach Programmierern sucht, für die »helping humanity is more important than making money«.77 Es geht zuvorderst nicht um das gemeinsame, kooperative Schreiben von Software, auch wenn einige andere Freiwillige Stallman helfen. Ausgangspunkt ist ein selbstbestimmt produzierendes Individuum. Damit dieses selbstbestimmt produzierende Individuum überhaupt sinnvoll programmieren kann und nicht immer wieder, in diesem Fall wortwörtlich, bei Null anfangen muß, ist es notwendig, daß ihm das bereits vorhandene, in Software materialisierte Wissen zur Verfügung steht (oder zumindest ein größerer Teil davon). Nur so kann die Unabhängigkeit der einzelnen Programmierer als freischaffende Künstler gegenüber einer wachsenden, immer mehr geheimen Quellcode anhäufenden Softwareindustrie gewahrt bleiben. Die freie Distribution ist in diesem Sinne eine Voraussetzung für die Softwareproduktion durch selbstbestimmte Individuen. Diese Distributionsform, die freie Weitergabe, wurde anscheinend als kostenlos verstanden. Eine Fußnote in der Version von 1993 erläutert Freiheit aber gerade nicht als Kostenfreiheit, sondern als Freiheit zum Weiterverteilen und zum Verändern: »The wording here was careless. The intention was that nobody would have to pay for *permission* to use the GNU system. But the words don’t make this clear, and people often interpret them as saying that copies of GNU should 76 Alle Benutzenden können das Programm zwar wiederum weitergeben, aber Stallman bleibt die einzige Quelle für autorisierte Versionen. Die erste Lizenz enthielt sogar einen Passus, der vorschrieb, daß alle Änderungen an Stallman zurückgeschickt werden müssen. 77 In den Versionen von 1985 und 1993 wurde »helping humanity« durch »building community spirit« ersetzt. Zur Begründung dieser Ersetzung vgl. 3.2.2.

68

3 Diskurs always be distributed at little or no charge. That was never the intent; later on, the manifesto mentions the possibility of companies providing the service of distribution for a proﬁt. Subsequently I have learned to distinguish carefully between ›free‹ in the sense of freedom and ›free‹ in the sense of price. Free software is software that users have the freedom to distribute and change. Some users may obtain copies at no charge, while others pay to obtain copies – and if the funds help support improving the software, so much the better. The important thing is that everyone who has a copy has the freedom to cooperate with others in using it.«

(Kosten-)Freiheit wird in der Fußnote so erläutert, daß niemand für die Erlaubnis GNU zu benutzen bezahlen muß, eine gewisse Verteilungsgebühr wird explizit nicht ausgeschlossen. Als Begründung wird auch die weiter unten explizit erwähnte Möglichkeit von Firmen geliefert, die ihr Geschäftmodell auf der Verwertung der Verteilung freier Software aufbauen, etwa indem zur verkauften Software noch Dienstleistungen (Wartung, Anpassung, Schulung etc.) mitverkauft werden.78 Frei wird differenziert als frei im Sinne von Freiheit (Unbeschränktheit der Möglichkeiten) und frei im Sinne von kostenlos. Freiheit bleibt also auch in der Fußnote unklar bestimmt. Einerseits als Kostenfreiheit der Benutzungserlaubnis, andererseits als Freiheit zur Weitergabe und Änderung. Beide Möglichkeiten werden für »freie Software« offengelassen. Interessanterweise wird als abschließende Betonung, »the important thing is«, die unbeschränkte Kooperation im Gebrauch der Software betont. Kooperation durch Verteilung und bei der Veränderung der Software. Eine Kooperation, die jedoch nur auf den Seiten der User stattﬁndet, nicht im vom Stallman dominierten Produktionsprozeß. Auf diese Form der Kooperation wurde erst ab 1993, nach der Verbreitung der medienbasierten Kooperation (vgl. Abschnitt 3.3) hingewiesen. Es geht bei »freier Software« demnach um die Distribution eines unix-artigen Softwaresystems, die zugleich die Voraussetzung für eine 78 Stallman selbst hat in der ersten Zeit nach seiner Kündigung beim MIT vom Versenden von EMACS-Kopien gelebt, $150 das Stück (Stallman 1999: 58).

3.2 Zurück ins Paradies

69

selbstbestimmte individualisierte Produktion ist. Freie Distribution wird zweifach bestimmt, als kostenlos und im Sinne von unbeschränkten Möglichkeiten des Gebrauchs, der Vervielfältigung, der Weiterverbreitung und der Veränderung. Die Stoßrichtung geht also gegen die warenförmige Verwertung von Software, wie sie sich, seit 1976 rechtlich abgesichert, immer weiter verbreitete.79 Das macht zum ersten ein eigenes Distributionsmodell erforderlich, und damit auch eine eigene Lizenz, die auf dem Copyright basiert, zum zweiten wird eine scharfe Frontlinie gegen die Verwertungspraktiken kommerzieller Softwareproduzenten gezogen und zum dritten erfordert es eine Strategie der Verteilung dieser Ideen und eine Überzeugung möglichst vieler Programmierer und Software-Benutzer. 3.2.2 Die goldene Regel Die folgenden beiden Absätze enthalten, in der ersten Person Plural gehalten, eine Aufzählung der schon vorhandenen und geplanter Programme und eine Klarstellung des Verhältnisses zum Unix-Betriebssystems (»GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems.«). Dann kommt der Autor auf seine Motivation zu sprechen: »Why I Must Write GNU I consider that the golden rule requires that if I like a program I must share it with other people who like it.« Hier ﬁndet wieder die Rückkehr zur ersten Person Singular statt. Es geht nicht mehr um die Motivation der Free Software Foundation bzw. deren Mitglieder oder Sympathisanten, sondern um die des selbstbestimmt produzierenden Individuums Stallman. Dieses Individuum unterliegt einem Zwang: es muß GNU schreiben. Warum er das tun muß, erläutert der folgenden Absatz.

79 Vgl. auch den »Open Letter to the Hobbyists«, den ein gewisser Bill Gates bereits 1976 gegen die Aneignungs- und Tauschpraktiken der wachsenden Home-ComputerSzene verfaßte (http://www.blinkenlights.com/classiccmp/gateswhine.html).

70

3 Diskurs

Die Einleitung »I consider« verweist auf eine persönliche Auslegung einer übergeordneten »goldenen Regel«80 , die selbst nicht erwähnt wird. Diese Ableitung bezieht sich nur auf den speziellen Bereich der Software. Es existiert also eine »goldene Regel«, die oder deren Stallmansche Auslegung erfordert, daß, wenn ihm ein Programm gefällt, er es mit anderen Leuten teilen muß bzw. an andere Leute weitergeben muß, denen es auch gefällt. Diese Regel formuliert offenbar eine allgemein bekannte, allem übergeordnete praktische Handlungsanweisung, eine Ethik, die für den speziellen Fall der Softwarebenutzung ausgelegt wird. Allgemeine ethische Sätze dieser Art wären etwa das christliche Gebot der Nächstenliebe oder der Kantsche kategorische Imperativ, aber explizit erwähnt wird keiner. Im Gegensatz zu vielen Ethiken formuliert die »goldene Regel« keinen normativen Appell (du sollst), sondern eine Notwendigkeit: »I must«, er muß GNU schreiben und er muß es mit anderen teilen. Die einzig zwingende Instanz ist die »goldene Regel«. Moral ist in Stallmans Interpretation nicht entscheidungsabhängige Pﬂicht. Wenn die oberste/goldene Regel etwas erfordert, muß es getan werden. Wenn die moralische Pﬂicht es fordert, kann man (oder zumindest das Individuum Stallman) nicht anders. Es gibt anscheinend eine feste moralische Programmierung, eine feste Verdrahtung der Moralregeln, die ähnlich strikt gelesen werden wie Programmabläufe. Die Anwendung der Regel auf Software selbst ist nicht in der Form »man sollte/muß« gehalten, sondern in der Ichform, die auf die individualistische Konnotation verweist: wenn ich ein Programm gut ﬁnde, wenn mir ein Programm gefällt, was als Kriterium der Moral ein individuell ästhetisches Empﬁnden als Kriterium einführt, keine objektives wie etwa Besitz (wenn ich ein Programm habe), Produktion (wenn ich ein Programm geschrieben habe), technische Funktionalität etc. Wenn ein Programm diesen meinen Kriterien nicht genügt, muß ich es demnach auch nicht weitergeben. Und die Regel bezieht sich in dieser Formulierung nur auf Software, auf formalisiertes, in Programmform niedergeschriebenes Wissen. Dieses Wissen muß (mit)geteilt werden. Diese (Mit)Teilung schafft einen offenen Korpus an Wissen, der wieder80 Die Formulierung mit der »goldene Regel« taucht in der Usenet-Version von 1983 und der 1993 überarbeiteten Fassung auf, nicht jedoch in der Druckversion von 1985. Dort beginnt der Satz erst mit »If I like ...«.

3.2 Zurück ins Paradies

71

um die Voraussetzung für die selbstbestimmte individuelle Produktion ist. Formuliert wird also eine Notwendigkeit, die aufgrund einer (Auslegung der) nicht genannten zentralen moralischen Regel entsteht. Die Bedingung für die Anwendung der Regel ist jedoch individuell und bleibt damit angesichts der gesetzesartigen Schärfe der Regel merkwürdig unspeziﬁziert. Der Gegenstand der Regel dagegen ist klar: in Software expliziertes Wissen. Die goldene Regel hat also einige merkwürdige Abweichungen von herkömmlichen Ethiken: sie ist als Notwendigkeit formuliert, an subjektiv-ästhetische Kriterien gebunden und da nur auf in Programmen expliziertes Wissen angewendbar, nur auf einen sehr kleinen Bereich der Gesellschaft bezogen. Die Handlungskonsequenz ist »to share it«. Das Teilen, Verteilen, Weitergeben hat im Kontext von Wissen und Software eine etwas andere Bedeutung: damit wird das Programm ja nicht halbiert oder ganz weggegeben. Man behält es und gibt eine exakte Kopie (des Quelltextes und/oder des Binärcodes) weiter. D. h. es tritt für den Gebenden/Teilenden keinerlei Verlust auf. Er hat das Programm nach wie vor und kann es weiterbenutzen. Insofern ist die Forderung der goldenen Regel keineswegs hart. Die Regel ist auch keine allgemeine Ethik, sondern nur auf Computerprogramme bezogen. Es wird auch keineswegs die kostenlose Weitergabe gefordert, sondern nur die Weitergabe, die kann also auch gegen Gebühr oder Aufwandsentschädigung erfolgen. Schließlich wird eine weitere Einschränkung in die (Auslegung der) Regel eingebaut, Teilen/weitergeben muß ich nur mit/an Leute/n, denen das Programm (auch) gefällt. Die müssen das Programm zumindest insoweit kennen, daß sie ihre ästhetischen Kriterien darauf anwenden können. Leute, die das Programm nicht kennen, fallen also aus dem Verteiler vorerst raus. Das Weitergeben setzt also Kommunikation über die Qualitäten des Programmes voraus. Das ist angesichts des medialen Kontextes merkwürdig, da viele Programme (auch GNU-Software) zum anonymen Download und Gebrauch, sei es im Usenet oder auf ftp-Servern angeboten wurden und werden. Stattdessen wird ein Kontext vorausgesetzt, der ein gemeinsames Begutachten von Software und die Kommunikation der subjektiven und ästhetischen Kriterien impliziert, also letztendlich eine kleine, relativ eng zusammenlebende Gruppe (oder ein Netzwerk von zusammenhängenden Kleingruppen)

72

3 Diskurs

von Softwarebenutzern. Dieser Aspekt wird im folgenden Text noch deutlicher: »Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement.« In diesem Absatz werden die »Software Sellers« (wiederum wird die Ebene der Distribution betrachtet, nicht die der Produktion), die nur trennen, unterwerfen und vorhandene Solidaritäten brechen wollen, einer Gemeinschaft der Benutzenden entgegengesetzt. Sie »wollen die Benutzer trennen«, d. h. die sind oder waren eigentlich zusammen, nicht getrennt. Aber mit einer divide et impera-Strategie werden die Nutzer unterworfen. Sie machen das, indem sie die Nutzer dazu bringen, die goldene Regel zu brechen: jeden Nutzer dazu bringen »making each user agree«: das impliziert keinen direkten Zwang, sondern eine wie auch immer erzielte Übereinkunft, nicht (mehr) zu teilen. Das heißt letztendlich: erst die Einwilligung der Nutzer führt zur Auflösung der wissensbezogenen Gütergemeinschaft. Sie sind der entscheidende Faktor, der aber der Verführung/Überredung der Schlange »Software Sellers« erliegt, und somit werden sie aus dem Paradies vertrieben. Es gilt die Praxis der »Software Sellers« aufzudecken und mit GNU den Weg ins Paradies des geteilten Wissens zu ebnen. Die Frontstellung wird durch diese einfache Gut vs. Böse-Normativierung verschärft. Neben die Sphäre der Verwertung wird damit eine moralisch einwandfreie Sphäre des Teilens von Wissen gesetzt, die zu einer Sphäre des Widerstandes wird. Direkt daran an schließt das auch typographisch einsame und aufrechte »I«, das sich weigert, die Solidarität mit anderen Benutzern auf diese Weise zu brechen. »I« kann nicht guten Gewissens eine Nichtveröffentlichungsvereinbarung oder einen Software-Lizenzvertrag unterzeichnen. »For years I worked within the Artiﬁcial Intelligence Lab to resist such tendencies and other inhospitalities, but eventually they had gone too far: I could not remain in an

3.2 Zurück ins Paradies

73

institution where such things are done for me against my will.« Er hat bereits jahrelang im (militärﬁnanzierten) AI-Lab des MIT in Boston gearbeitet, um diesen Tendenzen und anderen Unfreundlichkeiten zu widerstehen. Aus dieser Erfahrung speisen sich offensichtlich seine Vorstellungen von der Nutzung von Software und der wissensbezogenen Gütergemeinschaft der Softwarebenutzer. Das wird sehr deutlich in einem anderen Text: »When I started working at the MIT Artiﬁcial Intelligence Lab in 1971, I became part of a software-sharing community that had existed for many years. Sharing of Software was not limited to our particular community; it is as old as computers, just as sharing recipes for cooking. But we did it more than most [. . .] Whenever people from another university or a company wanted to port and use a program, we gladly let them. If you saw someone using an unfamiliar and interesting program, you could always ask to see the source code, so that you could read it, change it, or cannibalize parts of it to make a new program.« (Stallman 1999: 53) Stallman geht also von den anfänglichen Bedingungen der Softwareproduktion und -nutzung durch eng zusammenarbeitende und miteinander vernetzte wissenschaftliche Teams in Universitäten und unternehmenseigenen oder staatlichen Forschungsinstitutionen aus. Das sind die Wissensgemeinschaften, das ist das Paradies der selbstbestimmten Softwareproduktion und -verteilung und das ist die Grundlage für die individuell-selbstbestimmte Produktion, die ihm vorschwebt. Der Prozeß der Kommerzialisierung von Software zerstört diese eingespielten Handlungspraxen.81 Die Produktion von Software ist in diesem Modell individualisiert: jemand sieht interessante Software, etwa weil er dem Programmierer über die Schulter schaut, bittet um den Quellcode und liest ihn, ändert ihn oder nutzt Teile davon für ein eigenes Programm. 81 Für eine (eher journalistische) Beschreibung dieser Praxen vgl. Levy (2001), der sich nicht unerheblich auf Informationen des von ihm als »last of the true hackers« bezeichneten Richard Stallman stützt.

74

3 Diskurs

Die Gemeinschaft bezieht sich nur auf das Weitergeben des Quellcodes, ansonsten scheint jeder für sich allein zu programmieren. Eine durch die ökonomische Entwicklung bedrohte Praxis wird idealisiert und als handlungsleitend vorgestellt. Es gilt, diese teilende Gemeinschaft der selbstbestimmt programmierenden Individualisten (oder eine gleichartige) (wieder)herzustellen. Deswegen sucht er auch nach Programmierern, für die »building community spirit is as important as making money« (vgl. Fußnote 77). Deswegen ist die »goldene Regel« so zentral: es gilt einen gemeinsamen Korpus von Wissen als Arbeitsgrundlage zu schaffen und vor allem abzusichern, wie im Folgenden deutlich wird: »So that I can continue to use computers without dishonor, I have decided to put together a sufﬁcient body of free software so that I will be able to get along without any software that is not free.« Ehre82 wird als Motiv des Widerstandes gegen die Aneignungs- und Verwertungspraktiken der Softwareindustrie genannt. Er will deshalb Möglichkeiten schaffen, ohne freiheitsrestringierende Software auszukommen, und das erstmal für sich selbst. Diese Grundlage ist für ihn »a sufﬁcient body of free software«, also ein ausreichend großer, frei zugänglicher Wissensbestand, der eine selbstbestimmte Produktion erlaubt. So geht er mit gutem Beispiel voran und schafft die Grundlagen für ein neues Paradies. Diese Grundlagen sind nicht etwa ein Betriebssystem, sondern zuallererst ein Editor, ein Debugger und ein Compiler.83 Mit diesen essentiellen Werkzeugen war die Grundlage für die Schaffung eines offenen Korpus von Software gegeben. Vor diesem Hintergrund gewinnen die individuell-ästhetischen Kriterien für die Anwendung der goldenen Regel auch einen anderen Sinn: 82 In den beiden ersten Fassungen ist Prinzipientreue das Motiv. 83 »I therefore decided that my ﬁrst program for the GNU Project would be a multilanguage, multi-platform compiler.« (Williams 2002: 103) Das Projekt wurde jedoch aufgrund von Lizenzschwierigkeiten verschoben (ebd.) und die erste GNU-Software wurde der GNU-Emacs Editor, der im Frühjahr 1985 kurz vor der Veröffentlichung des Manifestos fertig wurde und damit eine erste Basis für den hier projektierten freien Wissenskorpus war. Der GNU C Compiler (GCC) wurde 1987 fertig, kurz nach dem Gnu Debugger (GDB). Damit lagen drei essentielle Werkzeuge für die Programmierung vor.

3.2 Zurück ins Paradies

75

In den gemeinsamen Wissenskorpus soll das eingespeist werden, was die selbstbestimmten Programmierer für gut genug halten und für geeignet als Basis für die gemeinsame Arbeit. Sein handlungsleitendes Ideal sind die vergangenen Wissensgemeinschaften von selbstbestimmt schaffenden Programmierern. Man schaute sich gegenseitig über die Schulter und tauschte Programmcode aus. Diese Gemeinschaften wurden durch die Lizenzierungspraktiken der »Software Sellers« aufgelöst. Er bleibt aber keineswegs romantisch rückwärts gewandt, sondern versucht der sich ausbreitenden, kommerziellen Software »a sufﬁcient body of free software« entgegenzusetzen, einen neuen, geteilten Wissenskorpus als Fundament für selbstbestimmt produzierende Programmierer. 3.2.3 Lizenzfragen Dieses Fundament war und ist aber durch die Aneignungspraktiken der Softwareindustrie bedroht. Noch wichtiger als die freie Distribution ist damit die Absicherung dieser Verteilungspraxis und des freien Wissenskorpus auch für die Zukunft. Nach einer nochmaligen Erläuterung des Verhältnisses zum Unix-Betriebssystem, kommt der Text zur Frage des rechtlichen Distributionsmodus: »How GNU Will Be Available GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modiﬁcations will not be allowed. I want to make sure that all versions of GNU remain free.« GNU wird nicht in der »public domain« (lizenzfrei) sein. Jeder darf GNU ändern und weiterverteilen, aber die weitere Verteilung darf nicht eingeschränkt werden. Die einschränkenden Regelungen der Lizenz regeln also, daß es für die Weiterverteilung keine Einschränkungen geben darf. Demnach wird das gebräuchliche Lizenzrecht gegen sich selbst gewandt, und die Beschränkung der Weitergabe in eine unbeschränkte und garantierte Weitergabe verwandelt. Das Ziel ist klar: Alle Versionen von GNU sollen frei bleiben. Es werden keine Aneignungen erlaubt, der Wissenskorpus soll für alle zugänglich bleiben.

76

3 Diskurs

Der Copyright Act von 1976 bezog auch Computerprogramme in das Urheberrecht der Vereinigten Staaten mit ein. Software wurde also genauso behandelt wie literarische Texte oder Musikstücke. Eine Kopie durfte nicht ohne Erlaubnis des Urhebers angefertigt werden. Allerdings waren nicht die im Programm verwendeten Methoden und Prozesse geschützt, sondern nur das Werk als Ganzes. Damit wurde das Eigentum an der Software sichergestellt, und zudem die Möglichkeit, das darin explizierte Wissen geheim zu halten. Es wurde damit aber auch die Möglichkeit geschaffen, die Lizenzvereinbarungen im gegebenen Rahmen frei zu gestalten. Stallman selbst unternahm einen ersten Versuch der Lizenzierung mit der GNU Emacs Licence von 1985.84 Neben dem Recht des Benutzers Kopien anzufertigen und weiterzuverteilen, durfte das Programm auch verändert werden, solange die Änderungen veröffentlicht wurden.85 Außerdem sollten abgeleitete (derivative) Programme ebenfalls unter derselben Lizenz veröffentlicht werden. Aus dieser Lizenz wurde bis 1989 die Version 1.0 und schließlich 1991, ergänzt um einige Formulierungen zu Softwarepatenten, die heute noch aktuelle Version 2.0 der »GNU General Public Licence« (GPL) entwickelt.86 In einer Präambel werden die schon oben entwickelten Intentionen der Lizenz formuliert. Freiheit wird als rechtlich abgesicherte Möglichkeit der Vervielfältigung, der Bearbeitung und der Weitergabe (auch gegen Gebühren) der Software deﬁniert. Aber der Lizenznehmer erhält nicht nur Rechte, sondern hat auch Pﬂichten. Die sind in Ziffer 2 des Lizenztextes geregelt: Vervielfältigung und Weitergabe sind erlaubt, wenn den Empfängern dieselben Rechte eingeräumt werden. Auch die Weitergabe und Vervielfältigung von vorgenommenen Änderungen und Weiterentwicklungen ist erwünscht,87 84 http://www.free-soft.org/gpl_history/emacs_gpl.html 85 Die Veröffentlichung war auch vorgeschrieben, wenn die Änderung nur für den privaten Gebrauch gemacht wurde. Dieser Aspekt, der »Big Brother aspect«, wurde in den späteren Versionen fallen gelassen. Vgl. (Williams 2002: 127) 86 Für eine ausführliche Erläuterung des Textes vgl. IfrOSS (Institut für Rechtsfragen der freien und Open Source Software) (2005). Momentan ( Jan. 2007) werden die Änderungen für eine Version 3.0 diskutiert. 87 Aber sie sind nicht verpﬂichtend, wie noch in der Emacs-Lizenz. Änderungen, die nur für den privaten Gebrauch vorgenommen werden, müssen erst unter die GPL gestellt werden, wenn das geänderte Programm weiterverbreitet wird.

3.2 Zurück ins Paradies

77

aber mit den Einschränkungen, daß Name des Bearbeiters, Datum der Änderung (Ziffer 2a) beigefügt werden müssen und daß das »abgeleitete Programm (derivative work)« ebenfalls unter die GPL-Lizenz gestellt werden. Diese Regelung wird allgemein als »Copyleft«, von Kritikern auch als »viraler Effekt«, von Befürwortern als »Impfeffekt«, bezeichnet.88 Stallman gelingt es mit der GPL im Rahmen des Copyright- und Urheberrechts, seine Intentionen umzusetzen. Die herkömmlichen Beschränkungen im Bereich Vervielfältigung, Bearbeitung und Weitergabe werden so weit aufgehoben, daß es mit dieser Lizenz gelingen kann, den Status von freier Software rechtlich abzusichern,89 und damit den Wissenskorpus zugänglich zu halten. 3.2.4 Gesellschaftliche Bezüge Das GNU-Manifestos zielt der bisherigen Analyse zufolge auf die Distribution von Software und auf die (Wieder-)Herstellung eines gemeinschaftlichen Wissenskorpus in Form von Software, hat also insofern eine gesellschaftliche Ausrichtung als der gesellschaftliche Umgang mit Wissen in Form von Software in Frage gestellt wird. Dieser bisher implizite Bezug auf die Gesellschaft wird im Abschnitt »Why All Computer Users Will beneﬁt« expliziert. Hier werden die gesellschaftlichen Wirkungen des Einsatzes freier Software beleuchtet und schließlich eine Utopie der Softwareproduktion entworfen, die nicht zuletzt die diesem Manifest zugrundeliegenden Vorstellungen von der Tätigkeit der Programmierer nochmals verdeutlicht. »Once GNU is written, everyone will be able to obtain good system software free, just like air.(2) 88 Diese Passage ist die umstrittenste in der GPL. Die Interpretation, was eine abgeleitete Arbeit und wo die Grenze zu ziehen sei, sorgte und sorgt für heftige Diskussionen. Für einen ausführlichen juristischen Kommentar zu dieser Passage der Lizenz, der allerdings in dieser Frage auch zu keinem eindeutigen Schluß kommt, vgl. IfrOSS (Institut für Rechtsfragen der freien und Open Source Software) 2005: 57. 89 Inzwischen hat die GPL auch erste Bewährungsproben vor Gericht bestanden, vgl. das Urteil des Landgerichts München I vom 19. Mai 2004 (http://www.jbb.de/urteil_lg_ muenchen_gpl.pdf). Auf die Version 3 der GPL kann im Rahmen dieses Textes nicht mehr eingegangen werden.

78

3 Diskurs This means much more than just saving everyone the price of a Unix license. It means that much wasteful duplication of system programming effort will be avoided. This effort can go instead into advancing the state of the art.«

Begonnen wird wieder mit der Freiheitssemantik: jedem wird es möglich sein, gute Systemsoftware frei zu erhalten, genau wie das allgemeine Gut Luft. In einer Fußnote wird nochmals auf die zwei Pole der Freiheit hingewiesen, die hier nicht ausreichend differenziert wären. Nach dieser Überschrift geht der Text auf die gesellschaftlichen Vorteile ein: viele der verschwenderischen Parallelentwicklungen der Systemprogrammierung werden vermieden. Die gesellschaftliche Wissensproduktion in Form von Software wird efﬁzienter. Ein gesamtgesellschaftliches Argument, das sich ähnlich auch bei Karl Marx ﬁndet (vgl. Marx 1979: 511, 552). Die proﬁtorientierte Softwareindustrie verschwendet in ihrer Konkurrenzsituation und durch die Geheimhaltung Teile der gesamtgesellschaftlich zur Verfügung stehenden Programmierarbeitskraft auf die vielfältigen Versuche der (Betriebssystem)Programmierung, die mit GNU effektiver verwendet würde und stattdessen auf die sinnvollere Weiterentwicklung des Bestehenden verwendet werden könnten (»advancing the state of the art«). Das ist nach dem »helping humanity« aus dem Schluß des Usenetpostings der erste explizite Hinweis auf GNU als Projekt mit einer gesamtgesellschaftlichen Perspektive, die zudem ein leicht verstecktes, aber deutlich antikapitalistisches Argument enthält. »Complete system sources will be available to everyone. As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes.« Die vollständigen Quelltexte werden für alle erhältlich sein, dadurch steht es einem Benutzer, der Veränderungen des Systems braucht, frei, diese selbst vorzunehmen oder einen Programmierer oder eine Firma

3.2 Zurück ins Paradies

79

dafür zu engagieren. Das ist ein erster Hinweis auf ein mögliches Geschäftsmodell für Software: Dienstleistungen, wie Anpassungen oder Erweiterungen werden anstatt der Lizenzen zur Einnahmequelle für Softwareﬁrmen oder Programmierer. Dem wird die bisherige Praxis gegenübergestellt, in dem die Benutzer auf die Gnade der Firma angewiesen ist, die den Code und damit ein Monopol auf das darin inhärente Wissen besitzt. Verschwiegen wird dabei, daß diese Gnade, ebenso wie die Dienstleistungen zur freien Software, durchaus käuflich ist, weil damit ein Großteil des Umsatzes und Gewinns mit Software gemacht wird. Was allerdings verloren geht, ist das Monopol einer Firma auf den Quellcode.90 Damit wird ein bestimmter Bereich der Wissensproduktion aus der Ökonomisierung (und damit aus der Verwertung) ausgeschlossen, nämlich das explizierte Wissen selbst. Ökonomisiert kann nur noch die Anwendung, Umsetzung oder Anpassung dieses Wissens werden. Das nächste gesellschaftiche Argument lautet: Schulen können viel besser ausbilden, wenn Schüler und Studenten den Quellcode studieren und verbessern können (Computeralphabetisierung). Stallman führt die ehemalige Praxis des Harvardrechenzentrums als Beispiel an, kein Programm ohne den dazugehörigen Quelltext zu installieren. »Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted. Arrangements to make people pay for using a program, including licensing of copies, always incur a tremendous cost to society through the cumbersome mechanisms necessary to ﬁgure out how much (that is, which programs) a person must pay for. And only a police state can force everyone to obey them.« Schließlich entﬁelen die allgemeinen Unkosten (overhead) des Berücksichtigens (und nicht zuletzt der Durchsetzung) der Eigentümerund Lizenzrechte. Damit wird das neue Eigentumsrecht an Wissen (als 90 Das wird von den Befürwortern der F/OS-Software nach wie vor als Vorteil hervorgehoben: die Gebundenheit an einen Anbieter (das sog. »vendor lock-in«) wird damit aufgehoben.

80

3 Diskurs

Recht zur Verteilung) auf einer gesamtgesellschaftlichen Ebene ökonomisch rational begründet.91 Diese Efﬁzienzsteigerung und Beseitigung von unnötigem Recht, ist vielen Beschreibungen der sogenannten »Hackerkultur« zu entnehmen.92 Die Anklänge von »overhead« an den »bürokratischen Wasserkopf« verweisen wiederum auf die eigentlich gewünschte Selbstbestimmung als Programmierer, die in Firmen oder wissenschaftlichen Instituten durch organisatorische Prozesse eingeschränkt wird. Gleichzeitig steckt in dieser juristisch-ökonomischen Argumentation aber auch die Anerkennung der existierenden Gesetze. Die müßten efﬁzienter sein, grundsätzlich sind sie aber in Ordnung. Das gilt auch für das Eigentumsrecht selbst. Problematisch ist nicht das Eigentumsrecht an sich, sondern die Ausweitung desselben auf Software und Wissen und die damit verbundenen Folgen: die Praxis der Nutzungsausschließung, die Lizenzkosten und das Geheimhalten des Quellcodes. Das wird auch aus der folgenden Passage deutlich: Ein Problem seien die lästigen und schwerfälligen Kontrollmechanismen der Bezahlung von Software. Das verursache enorme Kosten für die Gesellschaft. Wieder wird ein gesamtgesellschaftliches ökonomisches Argument gegen rechtliche Regelungen gebracht. Letztlich könne nur ein Polizeistaat die Einhaltung der geltenden Lizenzvereinbarungen erzwingen. Damit tritt zusätzlich ein politisches Argument, die abschreckende Vision eines Polizeistaats, gegen die geltende und rechtlich abgesicherte Praxis der Softwarelizenzen. Stallman konstruiert dann das Beipiel der Benutzung von Luft in einer Raumstation. Statt für die teure Luft unbequeme Atemmasken mit Verbrauchszähler zu tragen und überall Überwachungskameras zu installieren, wäre es besser, die Luftfabrik über eine Kopfsteuer zu ﬁnanzieren. Wieder dieser Vergleich Luft – Software wie im ersten Satz dieses Abschnittes. Dieses Beispiel ist auch ein Vorgriff auf die 91 Vgl. die (diese Argumentation schön illustrierenden) seit einigen Jahren laufenden Bemühungen der Musik- und Filmindustrie, das intellektuelle Eigentum an Musikstücken oder Videos mit Hilfe juristischer und technischer Zwangsmaßnahmen durchzusetzen. 92 Vgl. etwa Levy (2001: 41ff.), Turkle (1984: 262ff.), Williams (2002: 46f.). Und nicht zuletzt ist das effektive Funktionieren mit Minimalaufwand auch ein Kriterium für die Beurteilung von Programmcode: der soll ›schlank‹, efﬁzient und elegant sein.

3.2 Zurück ins Paradies

81

von ihm ausgearbeitete Utopie: die gesellschaftliche Finanzierung der Softwareproduktion: Im als FAQ (Frequently Asked Questions, einer gebräuchlichen Form der Dokumentation von Software) gestalteten letzten Teil des Manifestos schlägt er ein solches Modell vor: »All sorts of development can be funded with a Software Tax: Suppose everyone who buys a computer has to pay x percent of the price as a software tax. The government gives this to an agency like the NSF to spend on software development. But if the computer buyer makes a donation to software development himself, he can take a credit against the tax. He can donate to the project of his own choosing–often, chosen because he hopes to use the results when it is done. He can take a credit for any amount of donation up to the total tax he had to pay. The total tax rate could be decided by a vote of the payers of the tax, weighted according to the amount they will be taxed on. The consequences: * The computer-using community supports software development. * This community decides what level of support is needed. * Users who care which projects their share is spent on can choose this for themselves. In the long run, making programs free is a step toward the post-scarcity world, where nobody will have to work very hard just to make a living. People will be free to devote themselves to activities that are fun, such as programming, after spending the necessary ten hours a week on required tasks such as legislation, family counseling, robot repair and asteroid prospecting. There will be no need to be able to make a living from programming.«

82

3 Diskurs

Damit wird ein utopisches Gesellschaftsmodell zumindest für die Softwareproduktion entworfen. Über eine von den steuerzahlenden Computerkäufern selbst festgelegte prozentuale Abgabe auf die Hardware werden alle Arten von (Software)Entwicklung ﬁnanziert. Das impliziert zwar eine gewisse Bürokratie, die Eintreibung und Verteilung der Steuer regelt, aber es wird nicht direkt in den Prozeß der Programmierung eingegriffen. Die Programmierer sind damit in ihren Entwicklungsentscheidungen weitgehend frei und unabhängig von ökonomischen Zwängen. Sie arbeiten selbstbestimmt und aus einer intrinsischen Motivation heraus. Der Bereich Software wird aus der kapitalistischen Ökonomie herausgenommen, diese Ökonomie aber keineswegs aufgehoben, für Hardware, für Softwaredienstleistungen und anzunehmenderweise auch für andere Waren gilt die herkömmliche Produktions- und Distributionsweise durchaus weiter. Nichtsdestotrotz ist das eine Gesellschaftsutopie, explizit wird dieses Modell des frei zugänglichen Wissenskorpus für Software als ein Schritt hin zu einer »post-scarcity world« bezeichnet und weist damit durchaus Anklänge an sozialistische Utopien auf.93 Das hat zur relativ gängigen Etikettierung der FSF und der GPL als ›kommunistisch‹ geführt. Das GNU-Manifest blendet damit, als einer der wenigen Texte im Entwicklerdiskurs die gesamtgesellschaftliche Ebene keineswegs aus, sondern argumentiert (auch) vor diesem Hintergrund. Der geteilte Wissensvorrat an Software ist nicht nur für die Selbstbestimmung der Programmierer relevant, sondern, weil Software ein immer wichtigerer Bestandteil von gesellschaftlichen Prozessen wird, für die gesamte Gesellschaft. Die efﬁzientere Nutzung und Weiterentwicklung der vorhandenen Software, die einfachere Computeralphabetisierung und nicht zuletzt das Wegfallen der Kontrollen werden als zentrale Argumentationslinien angeführt und schließlich sogar Grundzüge einer gesellschaftlichen Utopie entworfen, die auf der selbstbestimmten, freiwilligen Arbeit der Programmierer beruht.

93 Diese Utopie verweist auf eine der Wurzel der Computerhacker: die Hippie- und Studentenbewegung der 60er Jahre.

3.2 Zurück ins Paradies

83

3.2.5 Zusammenfassung 1983 beginnt Richard M. Stallman, vormals Programmierer am renommierten MIT-Institut in Boston, mit dem Schreiben eines Softwaresystems, das er vom seit spätestens 1976 beginnenden warenförmigen Vertrieb von Software abgrenzen will. Es soll frei weitergegeben werden, d. h. die Benutzenden bekommen auch den Quelltext der Programme, können so selbst Veränderungen oder Anpassungen vornehmen und sie haben auch das Recht es unter denselben Bedingungen weiterzugeben. Produziert wird die GNU-Software von selbstbestimmten Programmierenden, deren Unabhängigkeit wesentlich von dem Vorhandensein eines frei zugänglichen Wissenskorpus abhängt. Auch wenn die Offenlegung des Quelltextes ein kooperatives Programmieren ermöglichen würde, und das erste GNU-Programm, der GNU Emacs-Editor, bereits ansatzweise so produziert wurde, legt das Manifest eher eine individualisierte Produktion nahe. Gerade weil der gemeinsame Wissensvorrat so zentral ist, legt das Manifesto die Betonung auf die Distribution der Software. Entsprechend werden die Lizenzierungs- und damit Geheimhaltungspraktiken der Softwareﬁrmen verdammt, weniger die Produktionsbedingungen. Stallmans Erfahrungen im MIT-Informatikmilieu, in dem der Austausch von Quelltexten gängige Praxis war, sind prägend für das von ihm entwickelte Manifest. Diese Wissensgemeinschaft wurde in seiner Wahrnehmung durch die Kommerzialisierung der Software zerstört, und den unabhängigen Programmierern damit die Lebensgrundlage genommen. Deshalb will er dieses Paradies neu gründen und letztendlich für den computerbenutzenden Teil der Menschheit öffnen. Die Fundamente für diese Neugründung sind individuell und selbstbestimmt arbeitende Programmierer und ein durch Lizenzen abgesicherter, frei zugänglicher Wissensvorrat. Der Kampf der Free Software Foundation zur Durchsetzung der im Manifest entwickelten Vorstellungen ﬁndet also an drei Fronten statt, zum ersten gilt es die Lizenzierungspraktiken der Softwareﬁrmen zu bekämpfen, zum zweiten müssen die Grundlagen für einen freien Softwarekorpus geschaffen werden (und nicht zuletzt die rechtliche Absicherung desselben durch eine Lizenz, die GNU General Public Licence, die die geltenden rechtlichen Rahmen benutzt, um die gelten-

84

3 Diskurs

de Praxis zu konterkarieren), und schließlich muß die Lizenz und die Zielsetzung der Free Software Foundation bei anderen Programmierenden verbreitet werden, um den gemeinsamen Wissensvorrat möglichst umfangreich zu machen. In Bezug auf die im Kapitel 2 entwickelten Unwahrscheinlichkeiten ist zu sagen, daß in dieser Semantiklinie des Diskurses der Fokus auf den politischen und rechtlichen Implikationen des Distributionsprozesses liegen. Zentral ist die Abgrenzung von der kapitalistischen Software-Verwertungspraxis über Lizenzgebühren, nicht jedoch von der sonstigen ökonomischen Praxis. Der Produktionsaspekt spielt nur eine untergeordnete Rolle. Entsprechend der Ziele wird diese Mission durchaus in einen gesamtgesellschaftlichen Zusammenhang gestellt und Ansätze einer Utopie, allerdings auf der Grundlage der geltenden rechtlichen und ökonomischen Rahmenbedingungen, entworfen.

3.3 Die neutrale Technik Die zweite Semantiklinie entstand parallel und größtenteils unabhängig von Stallman und der FSF ebenfalls in den 80er Jahren des vergangenen Jahrhunderts mit der Ausbreitung der digitalen Vernetzungstechnologie. In den neuen, technischen Neztwerken entwickelten die beteiligten Techniker eine neue Praxis des kooperativen Programmierens. Diese Praxis bildet nach wie vor die Grundlage der F/OSS. Ihre Legitimation bezieht sie jedoch nur zu einem kleineren Teil aus der Semantik der Free Software Foundation, sondern es wurde, gerade in Abgrenzung zur FSF, eine eigene Semantik entwickelt, die sich sehr eng an diese technische Praxis anlehnt. Deshalb erfolgt, bevor diese Semantiklinie durchleuchtet wird, ein erster Einblick in diese Praxis und die Entwicklung der Vernetzung in den 80er Jahren. 3.3.1 Die Anfänge eines Produktionsmodells Die Zahl der ans 1969 begonnene ARPA-Net, dem vom Verteidigungsministerium ﬁnanzierten Vorläufer des Internet, angeschlossenen Rechner wuchs von 1983 bis 1987 von 4.000 auf 27.000. Diese standen vor allem in Rechenzentren von Universitäten, Forschungsinstituten oder großen Unternehmen. Neben E-Mail ist in dieser Zeit vor allem das

3.3 Die neutrale Technik

85

sog. »Usenet«, Newsgruppen, die früheste Form öffentlicher elektronischer Diskussionsforen ein wichtiges Austauschmedium.94 Die neuen medialen Möglichkeiten, die schriftliche, anonyme Massenkommunikation mit interaktiven Elementen, wurden in dieser Zeit vor allem von den Technikern und Programmierern in den Rechenzentren genutzt. Mit diesen neuen Möglichkeiten bildete sich eine Praxis des Umgangs damit heraus, wobei vor allem das Anpassen der Technik an die eigenen Bedürfnisse im Vordergrund stand. Jemand hat eine Idee, setzt diese Idee in Programmcode um, veröffentlicht den Quellcode dieses rudimentären Programmes, andere Benutzer holen sich den Quellcode, benutzen das Programm und schicken dem Autor Patches (Ergänzungen zum Quellcode), die der in das Programm einbaut und in einer neuen Version veröffentlicht. Die Distribution erfolgt elektronisch, an ein anonymes Publikum95 und öffentlich. Das neue Medium wird dazu benutzt, das neue Medium benutzbarer zu machen. Software wird aus einem persönlichen Bedürfnis heraus produziert, und öffentlich zur Verfügung gestellt. Die Veröffentlichung des Quellcodes wird damit zum wichtigsten Schritt im Produktionsprozeß, weil nur so Interessierte in der anonymen Masse des Usenet gefunden werden und sich an der Entwicklung beteiligen können. Dieses Produktionsmodell entwickelt eine eigene Semantik, die vor allem technikzentriert ist. Der Diskurs in diesen Zusammenhängen ist eigentlich auf eine Vielzahl vereinzelter Projekte beschränkt und läuft nach je eigenen Regeln und Strukturierungen (vgl. unten 4). Aber in den F/OSS-Portalen, Newstickern etc. tauchen immer wieder bemerkenswerte diskursive Ereignisse aus einzelnen Projekten auf. Vor allem die Entwicklung des Linuxkernels und dessen »Eigentümer« Linus Torvalds spielen hierbei eine prominente Rolle. Aber auch andere »Leader«-Figuren überschreiten die Grenzen »ihres« Projektes, etwa Alan Cox (Linux), Larry Wall (Perl) oder Bruce Perens (Debian). So bildet 94 Vgl. den überschwenglichen Rheingold (2000), der ab 1983 an einer solchen von ihm als »Virtual Communtiy« bezeichneten Kommunikationsforum partizipierte. 95 Die Anonymität der Benutzenden wird aufgehoben, wenn sie selbst Programmcode an den ursprünglichen Autor schicken. Dann wird, so der Patch aufgenommen wird, der Name im Normalfall mit dem neuen Code veröffentlicht. Die Produktion erfolgt in diesem Sinne durchaus öffentlich.

86

3 Diskurs

sich ein projektübergreifender Diskurs der Techniker, ein Diskurs, in dem die führenden, produktiv tätigen Akteure das Wort ergreifen und eine speziﬁsche Semantik prägen. Diese Semantiklinie grenzt sich von der Semantik der FSF ab und ist deshalb als eigenständiger Bereich des Entwicklerdiskurses zu fassen, der jedoch die FSF-Semantiklinie keineswegs ablöst, sondern neben ihr besteht. In einem ersten Schritt werde ich die Praxis dieser Techniker anhand der Entstehung des Betriebssystems Linux genauer nachzeichnen (3.3.2), in einem zweiten Schritt sollen die Grundlagen dieses technischen Diskurses analysiert werden (3.3.3) in einem dritten Schritt werden dann die Vorstellungen von Technik analysiert (3.3.4). 3.3.2 Just a hobby Auch das Betriebssystem Linux entstand aus einem medialen Bedürfnis und vermittelt über ein Medium, Usenet, später Mailinglisten und ftp-Server. Linus Torvalds setzte auf seinem zu Beginn des Jahres 1991 erworbenen PC mit einem 386er Intel-Prozessor das unixartige Betriebssystem Minix ein.96 Das Problem war, daß die Möglichkeiten dieses Betriebssystems, über eine Telefonverbindung das Potential des Universitätsrechenzentrums im Hinblick auf Rechenleistung und Netzwerkverbindungen zu nutzen, sehr beschränkt waren. Torvalds programmierte sich deshalb ein Terminalemulationsprogramm, mit dem er sich in den Universitätsrechner einwählen konnte. Das ließ er aber nicht unter Minix laufen, sondern, um die neue Hardwarearchitektur kennenzulernen, direkt auf der Hardwareebene (vgl. Torvalds und Diamond 2001: 62). Nach etwa einem halben Jahr war sein Programm soweit, daß es einem Betriebssystem zu ähneln begann, so daß in der Usenetgruppe comp.os.minix folgendes Posting erschien: Newsgroups: comp.os.minix

96 Minix wurde von dem niederländischen Informatikprofessor Andrew S. Tanenbaum als unixartiges Betriebssystem für PCs entwickelt. Es wurde 1986 in der Version 1.0 veröffentlicht und sollte als praktische Erläuterung für das Buch »Operating Systems. Design and Implementation« und Übung für Studenten dienen. Die Lizenzbedingungen waren relativ rigide, es wurde zwar der Quelltext mitgeliefert, aber Änderungen daran waren nicht erlaubt.

3.3 Die neutrale Technik

87

Von: [email protected] (Linus Benedict Torvalds) Date: 25 Aug 91 20:57:08 GMT Lokal: So 25 Aug. 1991 22:57 Subject: What would you like to see most in minix? Hello everybody out there using minix I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the ﬁle-system (due to practical reasons) among other things). I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them :-) Linus ([email protected].ﬁ) PS. Yes - it’s free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.

Das ist das wohl berühmteste Posting aus dem Umfeld der Linuxentwicklung.97 Ein ﬁnnischer Teilnehmer an der Minix-Usenetgruppe konfrontiert die Abonnenten dieser Gruppe mit einer Art Meinungsumfrage. Adressiert wird »jeder da draußen, der Minix benutzt«, also explizit eine anonyme Öffentlichkeit. Im weiteren Posting werden 97 Entsprechend ist der 25. August das Datum, das als Geburtstag von Linux gefeiert wird.

88

3 Diskurs

nur Leute/Menschen (»people«) erwähnt, es erfolgt keinerlei direkte Adressierung. Unter den Händen eines Menschen, der sich Linus Benedikt Torvalds nennt, »braut sich« seit 5 Monaten ein Betriebssystem für Intel 386Prozessoren zusammen. Dafür möchte er Feedback haben. Das heißt er macht es nicht nur für sich selbst, sondern hat bereits in diesem Stadium (die Version 0.01 ist noch nicht veröffentlicht) den Fokus auf andere gerichtet. Und zwar in zweierlei Hinsicht: Zum einen fragt er wegen der Ähnlichkeit mit dem Minix-Betriebssystem die Minixbenutzer, was ihnen an Minix gefällt oder nicht gefällt, also nach einer Beurteilung dieses Betriebssystems, um eventuell beliebte Features zu übernehmen bzw. nachzuprogammieren und zum zweiten fragt er generell, welche Funktionen die meisten Leute in dem als bald einsetzbar bezeichneten neuen Betriebssystem haben möchten. Er gibt einige Informationen zum technischen Hintergrund der Hardwarebasis, der Portabilität und dem physikalischen Layout des Dateisystems. Außerdem läuft ihm zufolge bereits eine Shell, eine kommandozeilenorientierte Ein- und Ausgabeumgebung und ein Compiler. Das Programm wird als frei charakterisiert, aber nicht so groß und professionell wie »gnu«. Frei könnte im Zusammenhang mit GNU bedeuten, daß er das Betriebssystem unter der GNU GPL lizenziert hat oder lizenzieren will.98 Das Programm wurde dann bereits 1992 unter die GPL-Lizenz gestellt. Der Fokus liegt also auf der Technik und auf der Suche nach Interessierten in der anonymen Öffentlichkeit, hier erst in Form einer Umfrage. Als Motive für die Veröffentlichung (am 17. September 1991) auf einem ftp-Server nennt er später die Gewohnheit, Programme so auszutauschen, den Stolz auf sein Werk, den Wunsch nach Feedback und das Beweisenwollen, daß er nicht nur heiße Luft produziert hätte (Torvalds und Diamond 2001: 87 f.). Neben einer habitualisierten Praxis lagen der Veröffentlichung also vor allem der Wunsch nach Anerkennung von Gleichgesinnten, eine Anerkennung, die er in seiner näheren Umgebung aufgrund seiner speziellen Interessen nur begrenzt 98 Torvalds schreibt in seiner Autobiographie, daß er »wahrscheinlich 1991« einen Vortrag von Stallman in Helsinki gehört hat, allerdings nicht sonderlich beeindruckt war: »I was interested in the technology, not the politics« (Torvalds und Diamond 2001: 58).

3.3 Die neutrale Technik

89

bekommen konnte, zugrunde. Das neue Medium machte es jedoch möglich »to let the world see« (Torvalds und Diamond 2001: 87), was er produziert hatte, zwar nur einer sehr kleinen Gruppe von auf unixartige Betriebssysteme für 386er Prozessoren spezialisierten Technikern, aber einer Gruppe, die er als kompetent für die Beurteilung seiner Arbeit ansah.99 Eine Gruppe, die ihm über Feedback helfen konnte, sein Programm zu verbessern, die ihm Anerkennung geben konnte und eine Gruppe, der es möglich war, an seinem Programm mitzuarbeiten. Aber auch eine Gruppe, der es nicht um gesellschaftspolitische Fragen oder um die Bekämpfung der Lizenzierungsfragen ging. Sie waren vor allem oder nur an der technischen Entwicklung eines Betriebssystem interessiert, und sie benutzten Usenet und ftp-Server, um Hinweise, Bugreports, Programmschnipsel und Programme zu verteilen. Nicht die Verbesserung der Welt, sondern die eigenen technischen Lösungen (oder die Anderer) stehen im Fokus der Aufmerksamkeit. Als die Version 0.01 auf den ftp-Server geladen wurde, verständigte Torvalds nur eine »handful of people by private email«. Als jedoch Anfang Oktober einige Fehler behoben und einige neue Programme unter dem Betriebssystem zum Laufen gebracht waren, fand sich folgendes Posting in der Newsgroup comp.os.minix: Date: Sat, 5 Oct 1991 05:41:06 GMT From: Linus Benedict Torvalds Subject: Free minix-like kernel sources for 386-AT

Das ist also die erste Nachricht an die Öffentlichkeit, daß ein neues Betriebssystem in einer ersten Version verfügbar ist (bereits im August war mit der »Umfrage« ein erster Hinweis veröffentlicht worden, daß so etwas in Arbeit sei, und vorher hatte dieser Student aus Finnland bereits nach den POSIX-Standards gefragt). In Newsreadern taucht neben dem Namen erstmal die Betreffzeile (Subject) auf: »Freie minixartige Kernelquellen für 386-AT«. Das Posting verspricht einen Hinweis auf freie Kernelquellen, also zugängliche, 99 Seiner Familie hat er nichts von seinem neuen Betriebssystem erzählt. Der wurde die Tragweite seiner Tätigkeit erst klar, als er, anstatt Geld für das Programm zu verlangen, um Postkarten aus dem jeweiligen Land des Benutzers bat und hunderte von Postkarten aus aller Welt eintrafen (Torvalds und Diamond 2001: 93 f.).

90

3 Diskurs

lesbare und veränderbare Quelltexte eines Betriebssystem für PCs mit 386er Prozessoren. Diese Quelltexte sind minixartig, d. h. es können sich Personen angesprochen fühlen, die Nutzer von Minix sind, aber darüber hinaus Interesse an einer Veränderung des Minixbetriebssystems oder an einer freien Alternative haben könnten. Das Posting wurde weltweit verteilt, allerdings nur an eine relativ kleine Gruppe von Minixinteressierten. Von denen wiederum dürfte auch nur ein kleinerer Teil Interesse an einer frei veränderbaren Version gehabt haben, also selbstbestimmte Programmierer im oben entwickelten Sinne gewesen sein. Denen wird allerdings etwas bis dato nicht Verfügbares geboten: die Quelltexte für ein unixartiges Betriebssystem für PCs.100 Es handelt sich um den Versuch, eine kleine Gruppe von spezialisierten Programmierern auf das neue erschlossene Wissensfeld aufmerksam zu machen und sie dafür zu interessieren. Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you ﬁnding it frustrating when everything works on minix? No more allnighters to get a nifty program working? Then this post might be just for you :-)

Wenn der Lesende alle oder eines dieser Kriterien für sich positiv beantwortet, dann wird dieses Posting interessant sein, dann werden die freien Kernelquellen zum neuen Arbeitsgebiet. Diese Einleitung setzt auch den Rahmen für die folgende Ankündigung: es geht um einen rein technischen Diskurs, um selbstgeschriebene Gerätetreiber, modiﬁzierbare Betriebssysteme und fehlerhafte Programme. 100 Es hatte zwar schon die Portierung von BSD-Unix auf die Intel 386-Architektur begonnen (und wurde von den Programmierenden Bill und Lynne Jolitz ab Januar 1991 im Dr. Dobb’s Journal dokumentiert), aber die erste Veröffentlichung erfolgte erst im März 1992. Kurz darauf begann jedoch ein mehrjähriger Prozeß um das Copyright an Unix zwischen AT&T und der Berkeley-Universität: »Meanwhile, the legal hackling had been instrumental in giving a new kid on the block some time to mature and spread itself. Basically, it gave Linux time to take over the market.« (Torvalds und Diamond 2001: 57) Das GNU/Hurd-Betriebssystem wurde zwar angekündigt, aber auch davon war noch (lange) kein Quelltext verfügbar.

3.3 Die neutrale Technik

91

Torvalds adressiert ein ihm (bis auf einige E-Mailkontakte oder durch Postings aufgefallene Personen) unbekanntes Publikum. Keinen der Teilnehmer dieser Newsgroup hat er bisher persönlich getroffen. Er läßt die Anredezeile, die er noch in der »Umfrage« hatte, »alle da draußen, die Minix benutzen«, weg und beginnt direkt mit dem Text. Interessant ist die an Produktwerbung erinnernde, direkte, persönliche Ansprache, aber an ein persönlich unbekanntes Du. Eine Form von ﬁngierter Interaktion. Der lockere, witzige und (selbst-)ironische Tonfall von Torvalds dient als Opener und als Anreiz zum Weiterlesen für die Leute, die sich durch diese Beschreibung einer Lebensweise angesprochen fühlen. Torvalds kennt die Lebensweise und die Herauforderungen der Hacker, er lebt selbst so, aber er kann diese Lebensweise und Bedürfnisse ironisieren, davon Abstand nehmen. Er zeigt sich als einer der ihren, aber auch als witziger Kommunikator. As I mentioned a month(?) ago, I’m working on a free version of a minix-lookalike for AT-386 computers. It has ﬁnally reached the stage where it’s even usable (though may not be depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02 (+1 (very small) patch already), but I’ve successfully run bash/ gcc/gnu-make/gnu-sed/compress etc under it.

Er verweist auf sein »Umfrage«-Posting vom 25. August. Das ist auch ein Hinweis darauf, daß er damals nicht nur so dahergeredet hat, sondern wirklich was zu bieten hat. Torvalds wiederholt aber noch einmal zusammenfassend den Inhalt: »ich« arbeitet gerade an einer freien Version eines Minix-Doppelgängers für AT-386-Computer. Die Quellen sind frei verfügbar und veränderbar, sei es als Public Domain, sei es unter der GNU GPL-Lizenz. Das wird nicht weiter speziﬁziert. Letztendlich wurde Linux erst mit der Version 0.12 vom Januar 1992 unter die GPL-Lizenz gestellt. Die ersten Versionen enthielten nur ein Copyright, das den Verkauf untersagte und die Veröffentlichung der Änderungen vorschrieb. Das bedeutet, daß der Autor die Kontrolle über die Entwicklung seines Programmes

92

3 Diskurs

behalten will.101 Er kann die veröffentlichten Quelltextänderungen jederzeit in seinen Quelltext einbauen, und er will die Kontrolle über die ökonomische Verwertung behalten. »And I didn’t want to lose control, which meant I didn’t want anybody else to sell it, either. [. . .] I wanted people to be able to see it, and to make changes and improvements to their hearts’ content. But I also wanted to make sure that what I got out of it was to see what they were doing. I wanted to always have access to the sources so that if they made improvements I could use those improvements myself.« (Torvalds und Diamond 2001: 94 f.) Hinter der Veröffentlichung steckt ein gewisser Kontrollanspruch, der in dieser Formulierung auch als Eigentumsanspruch gelesen werden kann. Nicht im Sinne einer Nutzungsausschließung, sondern im Sinne der Distributionsmacht. 102 Dieses System, ein Doppelgänger von Minix, ist für seine Ansprüche benutzbar, und er will die Quelltexte zur weiteren (räumlichen und sozialen) Verteilung herausgeben/-stellen. Dann werden einige Programme aufgelistet, die schon erfolgreich getestet wurden, letztendlich wichtige Programmierwerkzeuge. Das System ist damit für Programmierer schon benutzbar. Als Quelle für die Quelltexte wird ein ftp-Server der Universität von Helsinki genannt und das entsprechende Verzeichnis, sowie ein Verzeichnis für vorkompilierte Binaries für das System. Der komplette Quelltext ist erhältlich, weil kein Minixcode verwendet wurde. Um es überhaupt zum Laufen zu bringen, muß der Benutzer jedoch ein »Hacker« sein, ein Computer- und Programmierenthusiast, wie er ironisch im ersten Absatz beschrieben wird. I can (well, almost) hear you asking yourselves "why?". Hurd 101 »Regardless, I didn’t want to sell Linux. And I didn’t want to lose control, which meant I didn’t want anybody else to sell it, either.« (Torvalds und Diamond 2001: 94) 102 Vgl. auch die ähnlich formulierte erste GNU Emacs-Lizenz von Stallman, der später den Veröffentlichungszwang für alle Veränderungen in der GPL wegen der damit implizierten Kontrolle, »the Big Brother aspect«, aufgab (Williams 2002: 127).

3.3 Die neutrale Technik

93

will be out in a year (or two, or next month, who knows), and I’ve already got minix. This is a program for hackers by a hacker. I’ve enjouyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs. It is still small enough to understand, use and modify, and I’m looking forward to any comments you might have.

Dann antwortet er auf die ﬁngierte Frage nach dem »Warum?«, wenn doch das GNU-Betriebssystem Hurd demnächst fertig wird (es wurde und wird von einer kleinen Gruppe entwickelt; Quelltexte wurden erst Ende der 90er Jahre erstmals veröffentlicht; es ist bis heute noch nicht fertig) und Minix zur Verfügung steht. Es ist ein Programm für »Hacker« von einem »Hacker«. Er hebt seine Freude am Schreiben dieses Programmes hervor, hofft, daß Gleichgesinnte ebenfalls ihren Spaß damit haben, und wartet auf Kommentare jeglicher Art dazu, von seinesgleichen, von »Hackern«. Es geht nicht darum, ein ernsthaftes Projekt zu starten, sondern mit der Technik zu spielen, Möglichkeiten auszuprobieren. I’m also interested in hearing from anybody who has written any of the utilities/library functions for minix. If your efforts are freely distributable (under copyright or even public domain), I’d like to hear from you, so I can add them to the system. I’m using Earl Chews estdio right now (thanks for a nice and working system Earl), and similar works will be very wellcome. Your (C)’s will of course be left intact. Drop me a line if you are willing to let me use your code. Linus

Außerdem hofft er auf die Freigabe von Minixerweiterungen für sein Betriebssystem, wobei er die Eigentumsverhältnisse unangetastet lassen will. Zusammenfassend läßt sich also sagen, daß eine Betriebssytementwicklung im damaligen medialen Setting des Internet, Usenet und ftp-Server, gestartet wird. Was auffällt, ist die Betonung des Adressatenkreises, gleichgesinnte Computerenthusiasten und die kommunikativ

94

3 Diskurs

geschickte Ironisierung der Lebenswelt dieser Techniker. Es ﬁndet sich, außer der Frage des Eigentums und der Lizenzierung, keinerlei gesellschaftliche Programmatik in den Ankündigungen. Zentral ist die Eröffnung eines technischen Produktionszyklus’, der mit Hilfe der neuen Vernetzungsmöglichkeiten als technischer Diskurs von gleichgestellten, ebenso spezialisierten Technikern, potentiell weltweit in Gang gebracht werden soll. Anvisiert wird bereits mit der »Umfrage« die gemeinsame Lösung eines neuen technischen Problems und die Eröffnung eines neuen Wissensgebietes für Programmierende, die Erstellung eines unixartigen Betriebssystems für PCs, allerdings unter der Ägide und Kontrolle des Autors. Ohne die neuen medialen Möglichkeiten wäre der Adressatenkreis für dieses sehr spezielle technische Problem auf Interessierte aus dem lokalen Umfeld des Autors beschränkt gewesen, und mangels solcher Interessierter wäre das Projekt wahrscheinlich nicht zu Stande gekommen oder in einem frühen Stadium abgebrochen worden. Im neuen medialen Kontext wurde das Projekt zu dem F/OSS-Projekt, das hunderttausende interessierte Entwickler anzog und anzieht und die Grundlage für den Boom der F/OS-Software am Ende der Neunziger Jahre des vergangenen Jahrhunderts wurde. 3.3.3 Formales Warum funktioniert so ein rein technischer Diskurs nur (oder beinahe nur) über mediale Vermittlung trotz der Unwahrscheinlichkeit der gelingenden Kooperation, wenn diese allein auf computerbasierte Medien gründet (vgl. 2.3)? Es gibt zwar in der These vom Wandel der Gesellschaft hin zu einer Wissensgesellschaft die Subthese, daß sich mit den neuen Medien die Bedeutung der face-to-face-Kommunikation vermindern würde oder gar rein »virtuelle« Kooperationszusammenhänge entstehen würden. Empirische Studien weisen aber darauf hin, daß genau das nicht so einfach ist. Ein Teil der Kommunikation wird zwar auf die neuen Medien verlagert, aber für wichtige Entscheidungen, für Diskussion von Konzepten, für das Entwerfen von Plänen, also für Kommunikation die zentral auf Vertrauen angewiesen ist, ist nach wie vor der face-to-face-Austausch wichtig. Er kann auch nicht vollständig durch eine Videokonferenz ersetzt werden, geschweige denn durch die

3.3 Die neutrale Technik

95

rein schriftliche Formen von Usenet und E-Mail.103 Trotzdem funktioniert die »virtuelle Kooperation« bei diesen Technikern, und zwar erstaunlicherweise so reibungslos, daß auf dieser Grundlage hervorgebrachte Software entsteht. Oben (vgl. 2.2) wurde die These entwickelt, daß vor allem die formalisierte Schriftlichkeit diese Kooperation stabilisiert. Hinweise dafür ﬁnden sich auch in der Semantiklinie der Techniker, in Torvalds’ Biographie in dem Abschnitt »The Beauty of Programming«. Hier beschreibt er seine Motivation zum Programmieren, die Macht über die Maschine und die Erschaffung eigener Welten mit dieser Maschine.104 »I’m personally convinced that computer science has a lot in common with physics. Both are about how the world works at a rather fundamental level. The difference, of course, is that while in physics you’re supposed to ﬁgure out how the world is made up, in computer science you create the world.« (Torvalds und Diamond 2001: 73) Physik will erklären, wie die Welt auf einer basalen Ebene funktioniert, während Informatik, ausgehend von einer basalen Ebene, die Welt erschafft. Ein schönes Bonmot, das aber nur funktioniert, wenn die referenzierte Welt die gleiche ist. Physik versucht »die« Welt zu erklären, bzw. will den physikalischen, materiellen Teil der Welt, die uns umgibt, erklären. Sie hat also immer eine wie auch immer geartete Referenz auf eine Außenwelt. Informatik dagegen schafft eine oder mehrere Welten, und zwar Welten aus Zeichen.105 103 Vgl. die noch nicht publizierten Ergebnisse aus dem DFG-Projekt »Bedingungen der Wissensproduktion in der Wissensgesellschaft«, Laufzeit 03/2004 bis 04/2006. Hier ein kurzer Auszug aus einem Interview mit einem Manager eines sog. »Global Players«: »I: Und wenn man Ihnen sagen wir jetzt die Idee vorsetzen würde und sagt: ok, face-to-face müsste es eigentlich gar nicht sein, heute ist sozusagen die elektronische Vernetzung... K: Das funktioniert nicht (lacht).« Danach folgt eine lange Schilderung von negativen Erfahrungen mit E-Mails, Telefon- und Videokonferenzen. 104 Der Aspekt der persönlichen Motivation ist für eine psychologische oder ökonomische (inwieweit steckt in diesem Handeln individuelle Rationalität) Fragestellung interessant, weniger für eine soziologische Arbeit, weswegen ich darauf nicht weiter eingehe. 105 Diese Welten können jedoch durchaus dazu dienen, die Welt zu modellieren und zu kontrollieren, vgl. Abschnitt 2.1.

96

3 Diskurs »One of the biggest joys was learning that computers are like mathematics: You get to make up your own world with its own rules. [. . .] Mathematics doesn’t have to be constrained by any external logic, but it must be logical in and of itself. As any mathematician knows, you literally can have a set of mathematical equations in which three plus three equals two. You can do anything you want to do, in fact, but as you add complexity, you have ot be careful not to create something that is inconsistent within the world you’ve created. For that world to be beautiful, it can’t contain any ﬂaws. That’s how programming works.« (Torvalds und Diamond 2001: 74)

Aus den Zeichen können eigene Welten erschaffen werden, mit eigenen Regeln, die nicht von externer Logik bestimmt sind. Die aus Zeichen geschaffene Welt gehorcht also nur den selbstgeschaffenen Regeln, sie hat keinen Bezug zur »realen« Welt, außer die zeichenverarbeitende Maschine, auf der das Programm läuft. Die verwendeten Zeichen selbst haben keinen Referenten, keine Bedeutung, die außerhalb des Regelwerks liegen würde. Nur in Bezug auf dieses strikt formale, in sich konsistente Regelwerk und im Bezug auf andere Zeichen ergibt sich ein ›Sinn‹, in Form einer Befehlskette. Programmieren ist also ein Spiel mit Signiﬁkanten, das strengen Regeln gehorcht. Aber der Programmierer kann, indem er die Regeln entwirft und/oder Zeichen mit diesem Regelwerk kombiniert, seine eigene Welt erschaffen. Dafür verleiht er den verwendeten Signiﬁkanten Sinn, nicht innerhalb der regelförmigen Ketten beispielsweise in der Bezeichnung der Befehle selbst (vgl. wiederum 2.2). Je komplexer diese Welt wird, desto größer ist die Gefahr von Fehlern oder Widersprüchen, aber prinzipiell ist es eine streng formalisierte Welt. Das hat zur Folge, daß die Regeln und das Konzept aus der Aneinanderreihung der Befehle selbst herausgeholt werden können. Die geschaffene Welt kann von anderen angeschaut, bewundert oder verbessert werden. Es ist nur wenig oder gar keine Kommunikation über das Konzept selbst oder die weitere Planung notwendig. Unter dieser Voraussetzung und der weiteren, daß eine größere Anzahl von Menschen ebenfalls dieses Wissen über den grundsätzlichen

3.3 Die neutrale Technik

97

Aufbau einer solchen Welt hat, also computeralphabetisiert ist, und Zugriff auf eine zumindest soweit identische zeichenverarbeitende Maschine hat, daß der Quelltext editiert, kompiliert und ausgeführt werden kann, ist eine Zusammenarbeit möglich. Daß diese Zusammenarbeit in einem Medium funktioniert, das aufgrund des Fehlens der nichttextuellen Kommunikationsbestandteile sehr viele Mißverständnisse produziert, hat also vor allem mit dem Gegenstand der Kooperation zu tun, einer »eindeutigen eigenen« Welt, deren Aufbau aus der Abfolge der Befehlsketten ersichtlich sind. Es ist keine Diskussion über die Bedeutung irgendeiner Zeichenkette notwendig, sondern allenfalls darüber, ob die Zeichenkette gemäß den grundsätzlichen Regeln fehlerhaft ist, wie ein Problem innerhalb dieser Regeln gelöst werden könnte oder ob ein Problem durch eine einfachere Zeichenkette gelöst werden kann. Die Kommunikation auf Grundlage von und über Quelltext, also der technische Diskurs über Software, hat eine unmißverständliche Grundlage: die festen Signikantengefüge der Software. Das macht eine gelingende Kommunikation auch in den elektronisch-schriftlichen Medien Usenet oder Mailingliste wahrscheinlicher. Der »Weltenbau« mit der formalisierten Schriftlichkeit des Programmcodes bedeutet für Programmierer wie Torvalds Vergnügen. Entsprechend lautet der Titel der Autobiographie »Just for fun«. Aber dieses erstmal individuelle Vergnügen hat aufgrund der Eigenschaften von Programmcode das Potential, zu einem kollektiven Spielzeug zu werden und sich so zum Projekt eines Teams zu stabilisieren.106 Aus dem individuellen, selbstbestimmten Programmierer im GNUManifesto wird ein Team. Ein Team, das ein produktives Spiel zum Vergnügen spielt. Dieses Team und dieses Spiel erhalten Stabilität aus den formalen Regeln, die das Spielzeug konstitutieren. Das hier entwickelte Denken innerhalb eines abgeschlossenen Systems tendiert dazu, nichttechnische Problemstellungen erst einmal auszugrenzen und diese nicht wahrzunehmen oder zu versuchen, sie auf einer technischen Ebene zu lösen. In einem nächsten Schritt soll 106 Interessant in diesem Zusammenhang ist der Punkt, an dem Torvalds beginnt, in Bezug auf das Betriebssystem die erste Person Plural zu verwenden: an dem Punkt, an dem ein anderer ein wesentliches Stück Programmcode beisteuert, nämlich den patch, der das Ausführen einer graphischen Oberﬂäche (GUI) möglich macht. Vgl. (Torvalds und Diamond 2001: 116).

98

3 Diskurs

daher untersucht werden, mit welchen Bedeutungen Technik in diesem Diskurs aufgeladen wird. bzw. welche Bedeutungen aus dem Diskurs ausgegrenzt werden. 3.3.4 Just technology Neben unzähligen Interviews für Zeitschriften, Webportale, Newsforen, sowie den gelegentlich veröffentlichten Postings von der KernelMailingliste trat Linus Torvalds auch als Buchautor in Erscheinung. In dem gemeinsam mit dem Journalisten David Diamond verfaßten, autobiographisch angelegtem Werk spielt die Technik eine Hauptrolle, nicht in Bezug auf detaillierte Erläuterungen, sondern in der Thematisierung von Technik im Allgemeinen, als zentrales Element in der Argumentation und im Weltbild. Hinter der folgenden kurzen Analyse des Torvaldschen Weltbildes steht nicht die Annahme, daß alle F/OSEntwickler dieses Weltbild teilen. Es wird jedoch von der Annahme ausgegangen, daß, aufgrund der zentralen Diskursposition dieses Textes und seines Autors, sich darin wichtige Semantiklinien ﬁnden. Dieses Techniker-Weltbild und Gesellschaftsverständnis wird deutlich, wenn Torvalds in seiner Autobiographie einen »Wired«-Artikel von Bill Joy, früherer BSD-Unix-Hacker und zum Zeitpunkt des Erscheinens der Biographie Chefentwickler der Firma Sun, für dessen pessimistische Aussichten kritisiert: »I don’t want to tear apart his article line by line, but I have a general belief that the saddest thing that could ever happen to humanity would be that we would just go on and on, as opposed to evolving. Bill seemed to feel that advances like genetic modiﬁcation make us lose our humanity. Everybody always thinks that something different is inhuman because right now we are human. But as we continue to evolve with whatever happens, in 10,000 years we will not be human according to todays standards. We will just be a different form of human. In Bill’s article, he seemed afraid of that. My feeling is, that it’s unnatural— and fruitless—to try and curb evolution. Instead of trying to ﬁnd two different kinds of dog to produce the desired

3.3 Die neutrale Technik

99

offspring, obviously we will resort to genetics; it seems inevitable that this will happen for people, too. In my opinion, changing the human race through genetics is preferable to leaving the status quo. I think that, in the bigger picture, it would be a hell of a lot more interesting to ensure the continued evolution of not just humans but of society, in whatever direction it goes. You can’t stop technology, and you can’t stop the advances we make in our knowledge of how our universe works and how humans are designed. It’s all moving so fast, that some people, like Bill Joy, ﬁnd it scary. But I see it as part of our natural evolution.« (Torvalds und Diamond 2001: 153 f.) Evolution, Technik und Wissen werden als eigenständige, natürliche Prozesse angesehen; es sei unnatürlich und sinnlos, sie zügeln zu wollen. Handlungsmöglichkeiten sind anscheinend begrenzt vorhanden, entweder im immergleichen Trott weiterzumachen (»just go on and on«), oder den Fortgang der Evolution zu sichern, nicht nur für die Menschen, sondern auch für die Gesellschaft, und zwar unabhängig davon, welche Richtung diese Evolution einschlägt. Eine Korrektur dieser Richtung scheint auch nicht möglich zu sein. Daß die Entwicklung der Technik und des Wissens von gesellschaftlichen und ökonomischen Kräfteverhältnissen stark beeinﬂußt wird, um es vorsichtig zu formulieren, daß erst die pragmatische Aneignung und Nutzung der neuen Medien als Produktionsmedium dazu führte, daß Torvalds als »an accidental revolutionary« (so der Untertitel des Buches) bezeichnet werden kann, bleibt in dieser Passage ausgeblendet.107 Technik bleibt ein sich gemäß einer inhärenten Eigengesetzlichkeit entwickelnder Prozeß, der nur um den Preis des Stillstands aufzuhalten ist. Das letztendliche Fundament der Technikevolution ist für Torvalds eine anthropologische Konstante: menschliche Triebe und Bedürfnisse. »Technology is what we make of it, and neither business nor technology will change the basic nature of human needs and yearnings. As with everything else, the evolution slowly but inexorably will cause technology to move 107 Für eine Kritik dieses Technikdeterminismus und dieser Eigengesetzlichkeit der technischen Welt vgl. Habermas (1973).

100

3 Diskurs away from plain survival through a society based on communication and ﬁnally into the realm of entertainment. [. . .] Humans are destined to be party animals, and technology will follow.« (Torvalds und Diamond 2001: 221)

Zentral für die Entwicklung der Technologie sind also basale menschliche Bedürfnisse und Begierden. Die grundlegende anthropologische Annahme ist dabei der homo ludens, der ›Partylöwe‹. Dabei nehme die Technik, unerbittlich getrieben durch die Evolution, eine dreistuﬁge Entwicklung: Sicherung des Überlebens, Unterstützung der gesellschaftlichen Kommunikation und schließlich die reine Unterhaltung, in der die Menschen zu ihrer ursprünglichen Bestimmung fänden. Weder die Ökonomie noch die Technik werden in diesem Weltbild die Richtung der Evolution verändern. Die Einbettung der eigenen Tätigkeit in dieses Gesellschaftsverständnis und vor allem die Abgrenzung des eigenen Tätigkeitsbereiches wird in anderen Passagen, in der er auf seine Rolle als »leader of a growing community« zu sprechen kommt, exemplarisch deutlich: »The technical decisions had never been a problem; the problem was ﬁguring out how to tell one person that I preferred another’s suggested changes—and being diplomatic about it. [. . .] I never saw the point of accepting anything other than what I thought was the best technical solution being presented. It was a way of keeping from taking sides, when two or more programmers offered competing patches.« (Torvalds und Diamond 2001: 120) Problematisch für ihn ist in der Selbstbeschreibung nicht die Entscheidung, sofern sie sich technisch begründen läßt, sondern die Kommunikation dieser Entscheidung an einen abgelehnten Programmierer und in die Gruppe hinein, also die soziale Komponente des Entwicklungsprozesses. Entscheidungskriterium ist immer Technik bzw. die beste technische Lösung, die präsentiert wird. Die Entscheidungsmacht wird damit als rein technische legitimiert, unabhängig von Gruppengrößen etwa, die für die Aufnahme eines Patches sind, unabhängig von vorhergehenden Entscheidungen, unabhängig von gesellschaftlichen,

3.3 Die neutrale Technik

101

politischen oder anderen Überlegungen. Das bedeutet, daß die »beste technische Lösung« ein wichtiger, wenn nicht der zentrale Aspekt in diesem Projekt ist. Zusätzlich bietet die Technik auch einen ›objektiven‹ Standpunkt, der eine persönliche Stellungnahme überﬂüssig macht, sozusagen einen ›neutralen‹ Punkt der Beurteilung (und des Rückzugs). Die Zentralität dieses Aspektes wird auch aus folgender Interviewpassage deutlich: »Es is halt auch häuﬁg so, daß in der freien Wirtschaft Dinge technisch ganz unsinnig gelöst werden [. . .] ist einfach so, weil die Vorgabe sieht so aus und dann mußt du’s so machen, egal ob’s Sinn macht oder nicht, sondern es ist so Befehlsausführung ja? [. . .] in der freien Software kann man das immer so umsetzen, wie man selber die perfekte Lösung sieht, man ist ganz frei auch in den Gedanken und in der Art und Weise, wie man das alles tut, also man kann quasi .. sich selber oder den Anderen [. . .] beweisen [. . .], daß das das Efﬁzienteste oder das die perfekteste Lösung für ein bestimmtes Problem ist.« (E1, Z. 227 ff.)108 Auch für E1 ist liegt in der Möglichkeit die »perfekteste Lösung« umzusetzen, einer der zentralen Vorteile der F/OSS. Hier ist »der« Bereich der Selbstbestimmung vorhanden, in den kein durch nichttechnische Interessen motivierter Befehl störend eindringt. Hier ﬁndet sich eine klar strukturierte Welt der logischen Beweise, die klar von der Welt der »freien Wirtschaft« und auch der Sozialwelt getrennt ist. Was in diesen Überlegungen ausgeschlossen bleibt, ist der Kontext, in dem die Technik steht: wer oder was die Probleme stellt, für die nur die besten technischen Lösungen zugelassen werden. Kritisiert werden auch nur die technischen Vorgaben für die Umsetzung, nicht die Problemstellung. Das Problem bestimmt jedoch die Richtung der Lösung, und damit die Richtung der Weiterentwicklung. Das mag in vielen Fällen nicht relevant sein, wie etwa bei der Behebung von Fehlern, bei der Portierung auf neue Hardwarearchitekturen, bei der Unterstützung 108 E1 arbeitet in einem dem Linuxkernel nahestehenden Projekt. Vgl. zu den Interviews die Einleitung zu Kapitel 4.

102

3 Diskurs

von Mehrprozessorsystemen usw. Interessant sind in diesem Zusammenhang jedoch Fälle, in denen sich Interessenskonﬂikte zwischen verschiedenen Gruppen innerhalb und außerhalb der Projekte ergeben, beispielsweise bei dem unten (vgl. Abschnitt 5.2.1) diskutierten Digital Rights Management. Während demnach die Problemstellung durchaus von extern kommen kann, bleibt die Problemlösung strikt intern. Die Zone der Selbstbestimmung ist damit beschränkt auf den Bereich der technischen Umsetzung. Hier wird sie allerdings rigide eingefordert. Das wird auch in der Explikation des Verhältnisses von Linux zur Unternehmenswelt deutlich. »Without commercial interests, how else would Linux ﬂow into new markets? How else would it create opportunities for innovations? How else would it be able to reach the people who want an alternative—a free alternative—to the bad technology that’s out there? What more realistic way for open source to take hold than through the sponsorship of corporations? And what better way of getting some of the less interesting work accomplished, boring stuff like maintenance and support, than doing it inside companies? Open source is about letting everybody play. Why should business, which fuels so much of society’s technological advancement, be excluded—provided they play by the rules? Open source can do nothing but improve the technology that companies create, and maybe make them less greedy. [. . .] One concern raised in newsgroup ﬂames amid the activity of 1998 was that commercial people wouldn’t give anything back. To some extent, I had to trust the new corporate players as much as Linux developers were trusting me. And they proved themselves trustworthy. They haven’t held back. so far it’s been very positive.« (Torvalds und Diamond 2001: 163 ff.) F/OSS in dieser Passage beschrieben wie ein kollektives Spiel, ein Spiel für ein kooperierendes Team. Nicht mehr der einzelne Programmierer steht hier im Blickpunkt, wie noch im GNU Manifesto, sondern das Team. In dieses Team werden die neuen Firmenspieler mit einem Vertrauensvorschuß aufgenommen.

3.3 Die neutrale Technik

103

Das Verhältnis zur Ökonomie wird durchaus positiv beschrieben: ökonomische Interessen eröffnen Linux neue Märkte(!), eröffnen Chancen für Innovationen, sichern die Verbreitung, sichern über Sponsoring den Fortbestand von Open Source, und bieten eine Möglichkeit, lästige Arbeiten wie Support abzugeben. Das sind die Vorteile, die Linux/Open Source von einer Kommerzialisierung hat. Im Gegenzug wird die von den Unternehmen geschaffene schlechte Technologie109 gemäß den technischen Kriterien verbessert und vielleicht wird die Gier die Unternehmen gedämpft. Unternehmen dürfen »mitspielen«, genauso wie alle anderen. Ebensowenig wie in der Nutzung gibt es für F/OS-Software eine explizite Schranke in der Beteiligung an der Entwicklung. Mitmachen können prinzipiell alle (zu impliziten Schranken vgl. 4.2.2). Deshalb ist die Beteiligung von Unternehmen, die (in diesem Weltbild) sowieso den Treibstoff für einen großen Teil des technischen Fortschritts liefern, durchaus erwünscht. Sie müssen sich nur an die Regeln halten. Dann wird ihnen das bescheiden anmutende Angebot gemacht, ihre Softwaretechnologie zu verbessern. Das impliziert aber, und damit kommt der erste Standbein der selbstbestimmten Entwickler ins Spiel, daß die Unabhängigkeit und technische Kompetenz der F/OS-Entwickler von den Unternehmen respektiert wird. Auf die Frage, inwieweit Unternehmen auf die Weiterentwicklung des Programmes Einﬂuß nehmen, wie sich dieser Einﬂuß äußert und wie er mit anderen Einﬂüssen interagiert, wird in diesem Zusammenhang nicht eingegangen. Eine Beteiligung an der technischen Entwicklung selbst ist durchaus möglich, allerdings nicht präskribierend in Form von Vorgaben110 , sondern in Form von Programmcode und Beteiligung am technischen Diskurs. Auch Unternehmen, oder »die Wirtschaft«, bestimmen aus diesem Blickwinkel nicht die Richtung der technischen Entwicklung. Sie liefern nur den Treibstoff für die Evolution der Technik. Beschrieben wird zwar eine gewisse Abhängigkeit in Bezug auf die Verbreitung und die Stabilisierung der F/OSS, aber keine absolute Abhängigkeit, es wäre für Torvalds wohl auch eine Rückkehr zu den anfänglichen 109 Hier geht es, wie oben bei E1, nicht um eine rein normative Bewertung, sondern eine in Bezug auf die technische Qualität. 110 Vgl. dazu etwa die Diskussion um eine stabile Kernelschnittstelle in Abschnitt 5.2.2.

104

3 Diskurs

Entwicklungsformen ohne Unternehmensunterstützung denkbar, auch wenn die mit gewissen Einschränkungen verbunden ist. Unternehmen dürfen in der offenen Softwareentwicklung mitspielen, wenn sie sich an die Regeln halten, d. h. wenn sie die Lizenzbedingungen einhalten und etwas an die Entwicklergruppen zurückgeben, in Form von Sponsoring oder, vor allem, durch die Veröffentlichung von Code. Dieses Mißtrauen war zu Beginn des ökonomischen Hypes um F/OSS während des New Economy-Booms weitverbreitet. Sie haben sich jedoch als vertrauenswürdig erwiesen, sie haben nicht zurückgehalten. Sie speisen in den offenen, für alle zugänglichen Wissensvorrat ein und versuchen nicht etwas zurückzubehalten, sich etwas davon anzueignen. Das zweite Standbein der selbstbestimmten Entwickler, der frei zugängliche Wissenspool, erfordert, daß die von Unternehmen geschaffene F/OS-Software dem offenen Wissensvorrat hinzugefügt wird. Die Quelltexte müssen veröffentlicht und lizenzrechtlich so abgesichert werden, daß sie in diesem Pool bleiben. Die Spielregeln sichern also zwei Bereiche ab: den geteilten Wissensvorrat und die Selbstbestimmung in technischen Fragen. Zusammenfassung Mit der pragmatischen Nutzung der neuen Medien durch eine technische Elite entsteht ein neues Produktionsmodell für Software. Gewachsen aus persönlichen Bedürfnissen und Ideen, wie die Nutzung von Computern und elektronischen Medien verbessert werden kann, werden Programme, die rudimentäre Funktionen beinhalten, einer weltweiten, aber mit ähnlichen Interessen ausgestatteten technischen Elite zugänglich gemacht. So entstehen ab etwa Mitte der 80er Jahre eine Vielzahl von Projekten. Gemeinsam ist ihnen, neben der medialen Vermittlung, der als Arbeitsgrundlage offen zur Verfügung gestellte Quelltext. Erstmal nur über elektronische Kommunikation vermittelt, wird gemeinsam Software produziert. Später kommen dann in den größeren Projekten, die für die Industrie interessant sind, auch Entwicklerkonferenzen dazu. Voraussetzung dafür ist die strenge Formalisierung der Computersprachen, die von jeder Referenz in der Umwelt abgekoppelt sind, außer von zeichenverarbeitenden Maschinen. Ähnlich abgekoppelt, das zeigt die Diskursanalyse, wird die Technik betrachtet. Mit der Verselbständigung der Technik als a-sozialem

3.4 Hin zum Neoliberalismus

105

Prozeß geraten im Gegensatz zur Semantiklinie der FSF die gesellschaftlichen Rahmenbedingungen und Einﬂüsse aus dem Blickfeld, die vorhandenen Abhängigkeiten ebenso wie die Frage, wer die Probleme stellt, die technisch gelöst werden und damit die Entwicklungsrichtung vorgibt. Es geht nur um die ›objektive‹ beste technische Entscheidung, ohne Vorgaben durch außertechnische Faktoren, wie der Ökonomie oder anderer gesellschaftlicher Gegebenheiten. Technik als objektive Gegebenheit und neutrales Terrain ist der zentrale Bestandteil dieser Semantiklinie. Gesellschaftliches ist nicht formal und axiomatisch zu fassen, es gehorcht keiner maschinenhaft anwendbaren Regel. Es bleibt deshalb außerhalb des Betrachtungswinkels. Über den Besuch eines Vortrags von Stallman schreibt Torvalds: »I have to admit that I wasn’t much aware of the sociopolitical issues, that were—and are—so dear to RMS [Richard M. Stallman] [. . .] I was interested in the technology, not the politics«. (Torvalds und Diamond 2001: 58) Politik ist nicht technisch efﬁzient und perfekt. Für die pragmatischen Techniker in der F/OSS ist entsprechend die Selbstbestimmung in technischen Entscheidungen ein wichtiges Abgrenzungskriterium, wenn nicht sogar das wichtigste. Der Fokus dieser Semantiklinie liegt vor allem auf dem Aspekt der Produktion, der Produktion in unabhängigen Projektteams. Zentrale motivationale Relevanz ist dabei das gemeinsame Vergnügen an der selbstbestimmten technischen Tätigkeit. Der geteilte und offen zugängliche Wissenspool ist zwar als Arbeitsgrundlage ebenfalls wichtig, wird allerdings nicht so stark betont wie im FSF-Diskurs.111

3.4 Hin zum Neoliberalismus Mit der Verbreitung der internetbasierten Produktionsweise, ihrer zunehmenden Verwertung in eigenen, auf Dienstleistung basierenden Unternehmensmodellen und dem Boom der New Economy entstand ab 1997 eine neue Semantiklinie, die sich vor allem auf eine speziﬁsch 111 Das Bewußtsein der Wichtigkeit dieser Arbeitsgrundlage ist aber durchaus vorhanden, wie Torvalds’ meines Wissens bisher einzige politische Intervention zeigt: ein offener Brief an das EU-Parlament gegen die Einführung von Softwarepatenten, vgl. http://www.heise.de/newsticker/meldung/40475.

106

3 Diskurs

ökonomische Deutung der Produktionsweise konzentriert und den Markt in die Semantik einführt. Wiederum ist es so, daß diese Semantiklinie keine der beiden bestehenden verdrängt, sondern neben ihnen weiterbesteht. Der erste Text, der diese Richtung andeutet, ist »The Cathedral and the Bazaar« von Eric S. Raymond (3.4.1). Richtig Fahrt und ein eigenes Label bekam dieses Diskurssegment jedoch erst mit der Ankündigung der Firma Netscape, die Quellen ihres Webbrowsers zu veröffentlichen (3.4.2). Das daraufhin beginnende Marketing für die neue Bezeichnung bündelt sich in dem Buch »Open Sources« (3.4.3). 3.4.1 Auf dem Bazar Eric S. Raymond ist einer der aktivsten Publizisten im Bereich der F/OSS. Seit 1997 weit verbreitet unter F/OS-Programmierern ist sein Artikel »The Cathedral and the Bazaar«, der als Vortrag auf mehreren Konferenzen gehalten wurde, im WWW zur Verfügung steht und 1999 in einer Aufsatzsammlung des Autors auch in Buchform veröffentlicht wurde (mit einer zweiten Auflage 2001). In diesem Artikel beschreibt er seine Erfahrungen mit der medial vermittelten Produktionsweise, wie sie bei der Entwicklung des Linuxbetriebssystems verwendet wird. »Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time. Linus Torvalds’s style of development – release early and often, delegate everything you can, be open to the point of promiscuity – came as a surprise. No quiet, reverent cathedral-building here – rather, the Linux community seemed to resemble a great babbling bazaar of differing

3.4 Hin zum Neoliberalismus

107

agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.« (Raymond 2001b: 21 f.) Linux hat das scheinbar gesicherte Wissen über die Softwareproduktion unsicher werden lassen. Dieses Wissen ist zweigeteilt: das Wissen von der Produktion von kleinen, wenig komplexen Programmen und das von der Produktion von großen und komplexen Programmen. Letztere müßten wie Kathedralen gebaut werden, sorgfältig konstruiert von isolierten Einzelnen oder kleinen Gruppen mit magischen Fähigkeiten. Dafür verwendet er die Metapher der Kathedrale, eines großen, ehrfurchtgebietenden Bauwerkes, das nur von wenigen genialen Baumeistern in enger Interaktion untereinander entworfen werden könne.112 Damit würde eine hierarchische Strukturierung eines Produktionsteams und eine nichtöffentliche Arbeit aufgrund der Komplexität der Programme nahegelegt. Dem wird die Entwicklung des Linuxbetriebssystems gegenübergestellt, die wie ein orientalischer Markt funktioniere, jeder könne Pläne, Code und Herangehensweisen vorschlagen. Der Unterschied liegt in der Öffentlichkeit der Produktion und der Diskussion von Produktionsentscheidungen. Raymond beschreibt seine Konversion von der herkömmlichen Theorie des Software-Engineering zur neuen »Basar«-Methode, deren Kennzeichen ihm zufolge vor allem die marktförmige Öffentlichkeit ist. Der Artikel beschreibt im Anschluß an diese einleitende Passage, wie er aufgrund seines Engagements vom ursprünglichen Chefentwickler ein Programm für den Mailtransport, fetchmail, übertragen bekommt und versucht, seine Beobachtungen 112 Diese Metapher nimmt er aus Frederick P. Brooks’ »The Mythical Man Month. Essays on Software Engineering«, der sein Kapitel 4 zur hierarchischen Strukturierung von Entwicklungsteams mit dem Bild der Kathedrale von Reims einleitet und davon ausgeht, daß für die konzeptuelle Integrität eines Softwaresystems das Design »must proceed from one mind, or from a very small number of agreeing resonant minds« (Brooks 2001: 44), und in diesem Sinne für eine hierarchische Struktur im Produktionsteam optiert. Auf der Ebene der Implementation des Designs legt Brooks durchaus Mitbestimmung oder eigenständiges Arbeiten der Programmierer nahe.

108

3 Diskurs

der Linuxentwicklung auf dieses Projekt zu übertragen. Seine Analyse der Linuxentwicklung faßt er in ökonomische Semantik: »The Linux world behaves in many aspects like a free market or an ecology, a collection of selﬁsh agents attempting to maximise utility, which in the process produces a selfcorrecting spontaneous order more elaborate and efﬁcient than any amount of central planning could have achieved« (Raymond 2001b: 52) Raymond übernimmt die Semantiken des »freien Marktes«, der rational handelnden Individuen (»selﬁsch agents«) und stellt dem so beschriebenen Produktionsprozeß, der eine selbstkorrigierende und spontane Ordnung produziere (daß dabei Assoziationen zur »invisible hand« entstehen, ist nicht zufällig), die zentrale Planung in unternehmensinterner Softwareentwicklung gegenüber. Seine Behauptung ist, ganz im neoliberalen Sinne, daß der freie Markt der zentralen Planung überlegen sei. Der Markt wird nicht nur in der Distributionssphäre verortet, sondern beherrsche demnach mit seinen Mechanismen auch die Produktionssphäre. Und er schaffe in diesem Bereich eine efﬁzientere und elaboriertere Ordnung, als es jede zentral planende Unternehmenshierarchie kann. Damit wird auch auf Veränderungen in Unternehmensorganisationen reﬂektiert, wie etwa die Schaffung eines unternehmensinternen Wettbewerbes (bench-marking) und ﬂacher Hierarchien, die vor allem den hochqualiﬁzierten Arbeitskräften einen größeren Raum für selbstbestimmtes Arbeiten zugestehen. Die Behauptung Raymonds ist demnach, daß Programmierer, wenn sie völlig von Unternehmenshierarchien befreit sind, am besten arbeiten. »Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software ›hoarding‹ is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.« (Raymond 2001b: 54)

3.4 Hin zum Neoliberalismus

109

Der Triumph der Open Source-Softwareproduktion erfolgt demnach nicht aus moralischer Überlegenheit, sondern weil die bessere Organisation und Qualität sich am (freien) Markt durchsetzt. Das sei kein Distributionsproblem (software hoarding), sondern ein evolutionäres: die Closed Source-Welt könne nicht gewinnen, weil die Open Source-Gemeinschaften für die Lösung eines Problems über ganze Größenordnungen mehr an Kapazitäten und Ressourcen verfügten. (wieder der Hinweis auf Gemeinschaft, aber diesmal im Plural).113 Letztere seien die überlegene evolutionäre Weiterentwicklung der bisherigen Formen von Softwareentwicklung. Gefahren könnten demnach nur aus der Aufhebung des freien Marktes entstehen, sei es durch ein Monopol oder durch rechtliche Regelungen. Nicht umsonst wird der Monopolist Microsoft in dieser Semantiklinie zum Hauptfeind. Damit wird die Grenzlinie zur Ökonomie, die von der Free Software Foundation noch immer gegen jegliche Form ›proprietärer‹ Software gezogen wird, verschoben hin zu einem Monopolisten. Das ist auch insofern logisch, als es im weiteren darum gehen wird, Sponsoren, Investoren und Kunden bei Unternehmen zu ﬁnden. Eine generelle Abgrenzung gegen Verwertungspraktiken ist dabei kontraproduktiv. Tenor des Artikels ist demnach, daß die Basarmethode der herkömmlichen, hierarchisch organisierten Softwareproduktion (Kathedralenmethode) in Firmen überlegen ist. Oder, »that the Bazaar style greatly accelerates debugging and code evolution« (Raymond 2001b: 33). Hervorgehoben und in den einzelnen Lehrsätzen relativ detailliert geschildert wird die Produktionsweise, die efﬁzienter, fehlerresistenter, qualitativ besser sei. Der Grund dafür sei die marktförmige Öffentlichkeit der Produktion. Eine Semantisierung der Produktionsweise also, geschaffen für eine Vermarktung der F/OS-Software. Diese Semantik bekam 1998 in der Hausse der New Economy einen neuen Schub.

113 Daß dem keineswegs so ist, zeigen die späteren Erfahrungen mit dem Mozilla- und dem Openofﬁce-Projekt, in dem genau diese Kapazitäten und Ressourcen enorme Probleme mit der schieren Masse von Code hatten, die plötzlich zugänglich gemacht wurde.

110

3 Diskurs

3.4.2 »Hallo, Open Source« Als Reaktion auf die Ankündigung des Unternehmens Netscape, die Quelltexte für das Aushängeschild der Firma, den Browser Netscape Navigator, freizugeben,114 traf sich am 3. Februar 1998 eine Gruppe von Aktivisten. »A group of leaders in the free software community« (DiBona et al. 1999: 3), die ihr Modell der Softwareproduktion propagieren und Kapital für die Unternehmen, die darauf ihr Geschäftsmodell gründeten,115 einwerben wollte. Die Initiative wurde dementsprechend vor allem von Unternehmen, die sich um die Entwicklung quelloffener Software gruppieren, getragen (vgl. unten). »Their concern was to ﬁnd a way to promote the ideas surrounding free software to people who had formerly shunned the concept. They were concerned that the Free Software Foundation’s anti-business message was keeping the world at large from really appreciating the power of free software.« (DiBona et al. 1999: 3) Nicht die Idee der »freien Software« selbst, sondern diese umgebende Ideen sollten Leuten nahegelegt werden, die diesen Begriff vorher gemieden hatten. Es wurde eine Marketingkampagne konzipiert, mit einem neuen Begriff im Mittelpunkt: »Open Source«. Das Distributionsmodell der Free Software Foundation, und damit die antikommerzielle, weil gegen eine direkte Verwertung gerichtete, Ausrichtung, wurden aus dem Zentrum genommen, und statt dessen im Begriff die neue Produktionsweise betont, die mit offenen Quelltexten operiert. Eric S. Raymond, einer der Teilnehmer an diesem Treffen und im weiteren Verlauf einer der Wortführer dieses Diskursstranges, hat am 8. Februar 1998 einen Aufruf an die Gemeinschaft verfaßt: »Goodbye, ›free software‹; hello, ›open source‹ 114 Die übrigens, wie Raymond selbstzufrieden anmerkt, auf die Rezeption seiner Schriften und Vorträge zurückgehen würde. 115 Dabei geht es nicht mehr um die Entwicklung und den Verkauf bzw. die Lizenzierung von Software, sondern vor allem um das Angebot von Dienstleistungen rund um F/OS-Software, etwa Installation, Betreuung, Wartung, Schulung, Dokumentation etc.

3.4 Hin zum Neoliberalismus

111

After the Netscape announcement broke in January I did a lot of thinking about the next phase – the serious push to get ›free software‹ accepted in the mainstream corporate world. And I realized we have a serious problem with ›free software‹ itself. Speciﬁcally, we have a problem with the term ›free software‹, itself, not the concept. I’ve become convinced that the term has to go. The problem with it is twofold. First, it’s confusing; the term ›free‹ is very ambiguous (something the Free Software Foundation’s propaganda has to wrestle with constantly). Does ›free‹ mean ›no money charged?‹ or does it mean ›free to be modiﬁed by anyone‹, or something else? Second, the term makes a lot of corporate types nervous. While this does not intrinsically bother me in the least, we now have a pragmatic interest in converting these people rather than thumbing our noses at them. There’s now a chance we can make serious gains in the mainstream business world without compromising our ideals and commitment to technical excellence – so it’s time to reposition. We need a new and better label. I brainstormed this with some Silicon Valley fans of Linux (including Larry Augustin of the Linux International board of directors) the day after my meeting with Netscape (Feb 5th). We kicked around and discarded several alternatives, and we came up with a replacement label we all liked: ›open source‹.«116 Der Text wird auf der Homepage des Autors eingeleitet mit den Worten: »This is the original call to the community to start using the term ›open source‹ that I issued on 8 February 1998.«117 Er konstruiert 116 http://www.catb.org/~esr/open-source.html, Download vom 17.06.2005. 117 Es ist unklar, wie der Text letztendlich veröffentlicht wurde. Es ﬁndet sich kein Hinweis in den Archiven der Newsportale oder auf Mailinglisten. Der einzige Hinweis ist ein am 01.04.98 im Linuxjournal erschienener Artikel von Raymond selbst, der z. T. identisch ist mit dem Aufruf (http://www.linuxjournal.com/article/2905).

112

3 Diskurs

in diesem Text eine Gemeinschaft, an die er seinen Aufruf richtet (vgl. 3.1)118 . Im Aufruf an die Gemeinschaft verabschiedet er im Titel »freie Software« und begrüßt »Open Source«. Nach der Ankündigung von Netscape, den Quellcode zu veröffentlichen, ist Raymonds Ziel die Akzeptanz von freier Software in der Unternehmenswelt voranzutreiben. Diese Ankündigung wird als ein erster Schritt in diese Welt betrachtet, der aber, um dort wirklich ernsthafte Akzeptanz zu erreichen, noch einen ernsthaften Schub (»serious push«) brauche. Das wäre die nächste Phase. Es geht demnach um eine Richtungsänderung, zumindest eine Abkehr von der bisherigen Darstellung. Als Problem für die Akzeptanz von F/OSS in der Unternehmenswelt identiﬁziert er den Begriff der »freien Software«. Demnach wird die Richtungsänderung eine (teilweise) Abkehr von den Positionen der Free Software Foundation sein. Dabei sollen jedoch das hinter diesem Begriff steckende Konzept der Wir-Gruppe nicht kompromittiert werden und die (Selbst-)Verpﬂichtung auf herausragende technische Qualität erhalten bleiben. Wie schon im Begriff »Open Source«, der einen Aspekt der Produktionsweise betont, wird damit nicht die verteilungsorientierte Semantik der Free Software Foundation betont, sondern nochmals ein Aspekt der Produktion, die technische Qualität und damit die Autonomie in der technischen Umsetzung. Der (konstruierten) Gemeinschaft gegenübergestellt wird die »Mainstream«-Ökonomie. Jetzt bestehe die Chance, dort Akzeptanz zu erreichen und »serious gains« (zum dritten Mal »serious«! vgl. die Spaßsemantik in 3.3) zu machen. Dabei gibt es ein Problem innerhalb der Gemeinschaft, der Begriff »Freie Software«. Der sei zum einen verwirrend und zum anderen mache er die andere Seite nervös. Der Grund für die Nervosität wird nicht erklärt, allerdings sei diese Nervosität hinderlich für das jetzige pragmatische Interesse der Wir-Gruppe, das sich wohl erstmal auf die Verbreitung von F/OSS-Software in Unternehmen bezieht. Diese Verbreitung ist aber primär ein Ziel der Firmen, deren Geschäftsmodell auf F/OSS-Software beruht. Diese Firmen werden als Teil der Gemeinschaft gesehen, wie der Hinweis auf Larry Augustin, 118 Zum Problem der Gemeinschaftskonstruktion in diesen medial vermittelten Beziehungen vgl. Sebald (2005).

3.4 Hin zum Neoliberalismus

113

dem damaligen Vorstandsvorsitzenden des Unternehmens VA Linux, zeigt. Für die einzelnen Entwickler muß das keineswegs ein Ziel sein, ja könnte vorhandenen Zielen und Idealen sogar widersprechen. Ein Teil der Gemeinschaft, der im Übrigen keineswegs notwendiger Bestandteil eines solchen konstruierten Kollektivs sein müßte119 , hat also ein Problem mit einem von der Gemeinschaft verwendeten Begriff, ein Begriff, der den ökonomischen Interessen, der Verbreitung von F/OS-Software im lukrativen Unternehmensmarkt und, angesichts des Börsenbooms der »New Economy«, eventuell auch der Gewinnung von Wagniskapital oder der Unterstützung beim Börsengang im Weg steht. Bei dieser Kampagne waren entsprechend die F/OS-Unternehmen federführend: VA Linux, ein Unternehmen, das Hardware zusammen mit dem Linux-Betriebssystem verkaufte und 1999 an die Börse ging, der O’Reilly-Verlag, der seinen Programmschwerpunkt im Bereich der Dokumentation von F/OS-Software hat und die Firma Red Hat Linux, der Anbieter der weltweit verbreitetsten Linux-Distribution, deren Aktien ebenfalls seit 1999 an der Börse gehandelt werden. Dazu kamen einige Aktivisten aus der Community selbst: Eric S. Raymond, Programmierer und Autor einiger einﬂußreicher Texte zur F/OS-Softwareentwicklung, Bruce Perens, der gewählte Repräsentant der Debian-Distribution, der einzigen auf freiwilliger und unbezahlter Arbeit beruhenden Linux-Distribution sowie einige Vertreter der Silicon Valley Linux User Group und eine Vertreterin des ForesightInstitutes, einer »nonproﬁt educational organization formed to help prepare society for anticipated advanced technologies«.120 Bei Raymond tauchen aber merkwürdigerweise nur einige »Silicon Valley Linux fans« und Larry Augustin, der auch nur in seiner Funktion im Vorstand von Linux International, einer Non-Proﬁt-Organisation zur Verbreitung von Linux, nicht als Manager von VA Linux angeführt wird, als Teilnehmer dieser Runde auf, in der schließlich der neue 119 Die Unternehmen sehen sich aber schon aus Interesse an der Geschäftsgrundlage durchaus als Mitglied dieser Gemeinschaft, wie mir etwa ein Manager eines F/OSUnternehmens im Interview sagte: »Natürlich [ist unser Unternehmen] ein integraler Bestandteil der Open Source-Community, und wir sind da ja auch hochangesehen.« (E6, Z. 109 ff.) 120 http://www.foresight.com/FI/index.html am 20.05.2005.

114

3 Diskurs

Begriff »Open Source« geprägt wurde. Dieser neue Begriff könne verwendet werden, ohne daß die Ideale oder das Engagement für qualitativ herausragende Software aufgegeben werde. Beides wird für die Gemeinschaft unterstellt, wobei die Ideale, wie die bisherige Analyse zeigte, durchaus verschieden sein können. Für die Anhänger der Position der Free Software Foundation könnte die Betonung der GPL, mit ihrer die »corporate types« nervös machenden »viralen« Funktion, eine Differenzlinie ausmachen, für die pragmatischen Techniker dagegen das sozioökonomische Feld, das jetzt betreten werden soll. Eine Gruppe von Unternehmen, die ihr Geschäftsmodell auf F/OSSoftware aufgebaut haben, zusammen mit einigen Aktivisten aus den Entwicklergruppen beschließt nach der Ankündigung von Netscape, den in der Konkurrenz zu Microsoft unterlegenen Browser nach dem F/OS-Entwicklungsmodell weiterzuentwickeln und eine Richtungsänderung im Diskurs vorzunehmen. Mit dem neuen Begriff »Open Source« werden einige die Unternehmen störende Implikationen des Diskurses der Freien Software verabschiedet. Damit ist wohl vor allem der Widerstand gegen den exkludierenden kommerziellen Umgang mit Software gemeint. Dieser Abschied geht vorsichtig von statten. Die bis auf die Verpﬂichtung zu technischer Exzellenz nicht speziﬁzierten Ideale sollen erhalten bleiben. und die als marktförmig beschriebene Produktionsweise wird gegen die FSF betont, sowohl im Begriff »Open Source« selbst als auch in der Verpﬂichtung auf technische Qualität. Damit werden die beiden Grundprinzipien der F/OS-Entwicklung, der frei zugängliche Pool der Quelltexte und die Selbstbestimmung in technischer Hinsicht erhalten, aber mit der Marktsemantik eine dezidiert neoliberale Deutung eingeführt und damit auch eine Kompatibilität mit den ökonomischen Prozessen der Marktwirtschaft nahegelegt. 3.4.3 Voices from the Revolution Um die Verbreitung dieser neuen Semantik zu unterstützen, erschien Anfang 1999 der Band »Open Sources. Voices from the Open Source Revolution« im O’Reilly-Verlag. Daß dieser Band von derselben Gruppe initiiert wurde, die auch den Begriff »Open Source« prägte, zeigt die Liste der Herausgeber des Bandes (die auch als Verfasser des im

3.4 Hin zum Neoliberalismus

115

Folgenden analysierten Textes, des Einleitungskapitels zeichnen): Chris DiBona ist Marketingdirektor bei VA Linux, Sam Ockman ist Präsident von Penguin Computing, einer kleineren Linuxﬁrma und sitzt im Vorstand der weltweit größten F/OS-Messe »LinuxWorld«. Mark Stone ist Lektor im O’Reilly-Verlag und zuständig für F/OS-Publikationen. Ein wichtiges Anliegen des Textes und der Open-Source-Initiative ist die Abgrenzung von der Free Software Foundation (FSF) und Richard M. Stallman. Eine Abgrenzung, die gleichzeitig aber nicht zu radikal sein darf, weil sonst ein guter Teil der konstruierten Gemeinschaft wegbrechen könnte. »Stallman launched the GNU project because essentially he feels that the knowledge that constitutes a running program – what the computer industry calles the source code – should be free. [. . .] Where proprietary commercial software vendors saw an industry guarding trade secrets that must be tightly protected, Stallman saw scientiﬁc knowledge that must be shared and distributed. [. . .] This radical message led many software companies to reject free software outright. After all, they are in the business of making money, not adding to our body of knowledge. For Stallman, this rift between the computer industry and computer science was acceptable, maybe even desireable.« (DiBona et al. 1999: 2 ff.) Stallman wird als ein radikaler Befürworter des freien Quellcodes eingeführt, für den die Abgrenzung von der Softwareindustrie nicht nur akzeptabel, sondern sogar wünschenswert war. Interessant ist die temporale Form dieser Beschreibung: im Präsens bleibt das Gefühl von Stallman, daß der Quellcode frei sein sollte, also letztendlich der Anknüpfungspunkt der Open Source-Semantik und die Geschäftspraktiken der Softwareﬁrmen. Dagegen werden die Differenzen von Stallman und der Softwareindustrie im Imperfekt gehalten, sind demnach Vergangenheit. Damit wird Stallman ein Weg hin zur neuen Semantik offengehalten (den er allerdings in diesem Band grantelnd verweigert: »The GNU Project continues to use the term ›free software,‹ to express the idea that freedom, not just technology, is important.« (Stallman 1999: 70).

116

3 Diskurs »The Open Source deﬁnition is a direct descendant of the ›Debian Social Contract,‹ and thus Open Source is very much in the spirit of GNU. The Open Source Deﬁnition allows greater liberties with licensing than the GPL does. In particular, the Open Source Deﬁnition allows greater promiscuity when mixing proprietary and open-source software.« (DiBona et al. 1999: 3)

Nach einer Berufung auf den Geist von GNU erfolgt der Hinweis auf die zentrale Differenz in der Lizenzfrage: die Mischung von proprietärem und quelloffenem Programmcode wird erleichtert, d. h. die Aneigung von Open Source-Code, die durch den sog. »viralen Effekt« (vgl. 3.2.3) mit der GPL verhindert wurde, soll für Firmen erleichtert werden. Deshalb soll ein größerer Teil der Programmierer überzeugt werden, ihren Code unter einer Open Source-Lizenz zu veröffentlichen.121 Erste Zielgruppe des Richtungswechsels sind damit die programmierenden Mitglieder der konstruierten Gemeinschaft: Um eine Verwertung ihres Programmcodes zu erleichtern, sollen sie eine für die Weiterverwendung des Codes weniger einschränkende Lizenz wählen.122 Zweite Zielgruppe ist natürlich die Softwareindustrie, die eine stärkere Unterstützung von Open Source-Softwareentwicklung leisten soll, 121 Möglichkeiten dafür gab es schon länger, nicht erst mit der Open Source Deﬁnition. Das prominenteste Beispiel für eine solche Lizenz ist die sog. BSD-Lizenz (Berkeley Software Distribution- Lizenz), die eine Übernahme von Code oder den proprietären Vertrieb der so lizenzierten Software unter einem anderen Namen erlaubt. Niemand wird gezwungen, die GPL zu verwenden. Insofern ist das im Text angeführte Beispiel, daß »the advent of Open Source« (S. 4) den Konﬂikt zwischen den zwei großen graphischen Benutzeroberﬂächen in der F/OSS (Gnome und KDE) gelöst und so eine Spaltung der Gemeinschaft verhindert hätte, zumindest zweifelhaft. Die Firma Trolltech, deren Bibliothek die Grundlage für die graphische Oberﬂäche KDE ist, hatte ihre Software anfangs unter einer nicht freien Lizenz, weshalb sich viele Anwender und Entwickler weigerten, KDE zu benutzen. Daraufhin wurde, vor allem unterstützt von der FSF und der Firma Red Hat, die Entwicklung einer freien graphischen Oberﬂäche begonnen, Gnome. Die Firma Trolltech hatte jedoch nie nur die Wahl zwischen der GPL und einer proprietären Lizenz, und sie vertreibt ihr Programm inzwischen auch unter der GPL. 122 Raymond fordert in einem Interview aus dem Jahr 2005 inzwischen sogar die Abschaffung der GPL, vgl. http://www.onlamp.com/pub/a/onlamp/2005/06/30/esr_interview. html am 20.09.2005.

3.4 Hin zum Neoliberalismus

117

etwa in Form der Portierung verbreiteter Anwendungsprogramme auf das Betriebssystem Linux, der Unterstützung von Projekten oder der Anwendung dieses Produktionsmodells selbst. Dabei wird diese Industrie ambivalent eingeführt, unter dem Titel »The dark side of the force«123 : »Industry has produced some marvelous innovations: Ethernet, the mouse, and the Graphical User Interface (GUI) all came out of Xerox PARC. But there is an ominous side of the computer industry as well. No one outside of Redmond really thinks that it is a good idea for Microsoft to dictate, to the extent they do, what a computer desktop should look like or have on it.« (DiBona et al. 1999: 5) Die Industrie, besser: die industriell geförderte Forschung, hat in den Augen der Autoren durchaus positive Ergebnisse gezeitigt. Dem wird aber die Diktatur von Microsoft in Bezug auf die konkrete Ausgestaltung dieser Forschungen gegenübergestellt. Es gibt also die gute, forschende oder forschungsunterstützende Industrie und die böse, monopolisierende und damit innovationsverhindernde Industrie, wobei sich letztere in dieser Semantiklinie auf Microsoft beschränkt. Insgesamt bleibt die Verbindung mit der Industrie aufgrund der teilweisen Gegenläuﬁgkeit von Entwicklungs- und Verwertungsinteressen der Industrie aber eine »uneasy one at best« (DiBona et al. 1999: 4). Im letzten Kapitel dieses Textes schließlich wird eine Traditionslinie der Open Source-Softwareentwicklung hin zur Entstehung der neuzeitlichen Wissenschaft gezogen, die ebenfalls aus dem »open sharing of information« entstanden, die medial über die Druckerpresse verbreitet worden sei. Mit dem Internet als »printing press of the digital age« werde eine neue digitale Renaissance eingeleitet. Damit wird auch ein zum FSF-Diskurs konkurrierender Ursprungsmythos für die neue Gemeinschaft geschaffen. »While this renaissance holds great promise, we must not 123 Das erfolgt in Anspielung auf die Star Wars-Kinoﬁlme, in denen die Anhänger einer merkwürdig manichäischen, metaphysischen »Macht« sich bekämpfen. Die Industrie insgesamt wird mit dieser Macht gleichgesetzt, es gibt jedoch Anhänger der »guten« und der bösen, oder »dunklen« Seite.

118

3 Diskurs forget the century old scientiﬁc heritage on which the Open Source development model is based. Computer science and the computer industry do exist in an uneasy alliance today. There is pressure from industry giants like Microsoft to keep new developments proprietary for the sake of short-term ﬁnancial gain. But as more and more of the development work in computer science has its origins in industry rather than academia, industry must take care to nourish computer science through the open sharing of ideas – namely, the Open Source development model. The computer industry must do this not out of altruistic motives to serve a greater cause, but for the most basic pragmatic reasons: enlightened self-interest.« (DiBona et al. 1999: 17)

Diese Traditionslinie wird als Argument für die Förderungswürdigkeit von Open Source durch die Industrie ins Feld geführt. Nicht die Orientierung auf kurzfristige Monopolgewinne, sondern eine gezielte und längerfristige Förderung liege im aufgeklärten Eigeninteresse der Unternehmen, wieder mit der Ausnahme des Monopolisten Microsoft, der aufgrund seiner Machtposition das kurzfristige Gewinndenken durchsetzen wolle. Mit diesem Monopol wird aber auch der Markterfolg des Open Source-Modells verhindert. Die Einlösung des Versprechens einer digitalen Renaissance hängt dem Text zufolge an einer sorgfältig erwogenen Unterstützung des Open Source-Modells durch die Industrie. Dann werden zwei Gründe für das Interesse der Industrie an einer solchen Förderung aufgeführt: zum einen die Reputation, die damit historisch gewonnen werden könne, und schließlich: »Second, and more important, industry needs the innovation science can provide. Open Source can develop and debug new software with the speed and creativity of science. The computer industry needs the next generation of ideas that will come from Open Source development [. . .] To sustain the digital renaissance we need Open Source development. Open Source development drives progress not just in computer science, but in the computer industry as well.« (DiBona et al. 1999: 17)

3.4 Hin zum Neoliberalismus

119

Open Source liefere die Innovationen, die von der Industrie benötigt würde. Wieder wird auf die Entwicklungsgeschwindigkeit, Kreativität und die Fehlerbehebungskapazitäten hingewiesen, die für eine überlegene Qualität bürgen sollen. Die quelloffene Produktionsweise wird als der Motor des Fortschritts gepriesen. In Abgrenzung von der nicht mit jedem Verwertungsinteresse kompatiblen Semantik der »Free Software«, wonach alle Software frei sein muß, werden wirtschaftsliberalere Lizenzierungspraktiken vorgeschlagen und umgesetzt. 3.4.4 Zusammenfassung Mit der Entstehung von Firmen, die ihr Geschäftsmodell auf F/OSSoftware gründen, also auf die Installation, Konﬁguration und Wartung dieser Software, entwickelt sich, interessanterweise parallel zum New Economy-Hype an den Finanzmärkten und den damit verbundenen Börsengängen der beteiligten Firmen Red Hat und VA Linux, eine neue Semantiklinie im Diskurs der F/OS-Entwickler. Betont werden nun nicht mehr die distributiven oder medialen und technischen Aspekte, sondern die efﬁzientere, marktförmig organisierte Produktionsweise. Es werden Vergleiche gezogen zur hierarchischen unternehmensinternen Form der Softwareentwicklung und die durch die ›unsichtbare Hand‹ effektivere Organisation des Open Source-Modells betont: schnellere Entwicklung, weil mehr Entwickler involviert seien, die Kreativität von nicht in Hierarchien eingebundenen Entwicklern und das schnellere Finden und Beheben von Fehlern in der Software. Damit sei Open Source-Software qualitativ überlegen. Nach dem neoliberalen Modell, das diesen Überlegungen zugrundeliegt, müßte sich demnach diese Software am Markt durchsetzen. Eine Erklärung für diese bisher nicht oder nur langsam erfolgte Durchsetzung am Markt liefern, ganz im neoliberalen Sinne, die Marktwirkung verhindernde Mechanismen, vor allem das Monopol von Microsoft. Dieses Unternehmen wird damit zur Hauptzielscheibe in diesem Diskurs. Andere Firmen wie IBM, Hewlett Packard u. a. die entsprechend und konform der Regeln der konstruierten Gemeinschaft in die Förderung von Open SourceSoftwareentwicklung einsteigen, werden demgegenüber als Vorbilder konstruiert und in die Gemeinschaft integriert. Gleichzeitig erhöht dieser Richtungswechsel im Diskurs jedoch die

120

3 Diskurs

Gefahr der Spaltung dieser Gemeinschaft.124 Die Interessen des neu aufgenommenen Teils, der F/OSS-Firmen und anderer unterstützender Firmen sind nicht unbedingt identisch mit denen des Großteils der Entwickler und vor allem keineswegs identisch mit denen der Free Software Foundation und ihrer Anhänger. Deswegen ist eine vorsichtige, eher umarmende Integration der Positionen dieses Teils und der Galionsﬁgur Stallman notwendig.

3.5 Semantiklinien im Diskurs Im Diskurs der Entwickler lassen sich drei große Semantiklinien ﬁnden, die sich historisch entwickelt haben, jedoch gegenwärtig nebeneinander existieren. Gemeinsame Grundlage aller drei Richtungen sind die selbstbestimmt arbeitenden Programmierer und der frei zugängliche Pool an in Form von Quelltext expliziertem Wissen. Das ist die grundsätzliche Abgrenzung, Konstitution und Legitimation der eigenen Praxis als eine eigenständige Form der Wissensproduktion. • Der Diskurs der Free Software Foundation, so wie er sich im GNU-Manifesto präsentiert, lehnt eine Verwertung von Software über Lizenzgebühren generell ab. Ziel ist die allgemeine Zugänglichkeit von Quellcode und damit ein Wissenspool als Grundlage für selbstbestimmte Programmierer. Deswegen wird versucht den unter der GNU GPL-Lizenz stehenden Korpus von Programmen möglichst umfangreich zu gestalten und dieses Wissensvorrat durch die »Copyleft«-Lizenz auch zukünftig gegen exkludierende Aneignung abgesichert. Zentral ist der Aspekt der Distributionspraxis, die in offensiver Abgrenzung zu den Verwertungspraktiken von Softwareunternehmen legitimiert wird. • Die sich mit der Ausbreitung der Computervernetzung bildenden Technikerzusammenhänge beginnen mit Hilfe dieses neuen Mediums kooperativ Software zu entwickeln und schaffen 124 Das zeigt nicht zuletzt das Statement von Bruce Perens, einem Mitbegründer der OSI, der in einem Posting vom 17.2.1999 deswegen seine »Rückkehr« zur Freien Software-Fraktion verkündet: http://lists.debian.org/debian-devel/1999/02/msg01641.html am 14.06.2005.

3.5 Semantiklinien im Diskurs

121

auf der Grundlage des formalisierten Signiﬁkantengewebes der Quelltexte eine neue Produktionsform. Semantisch grenzt sich die hier vorherrschende Semantiklinie als unpolitisch von der FSF ab und gruppiert sich vor allem um den Begriff der Technik und der technischen Rationalität. Gesellschaftliche Rahmenbedingungen werden dabei ausgeblendet. Die Selbstbestimmung in den technischen Entscheidungen das zentrale Kriterium, wobei sich der Fokus vom Individuum auf Teams verschiebt. In diesem Kontext sind auch Unternehmen als Akteure in der Entwicklung durchaus willkommen, wenn sie sich an die herrschenden Regeln halten. • Parallel zum Boom der New Economy entsteht, initiiert und getragen vor allem von Unternehmen, die ihr Geschäftsmodell auf F/OS-Software bauen, die neoliberale »Open Source«Semantiklinie. In dezidierter Abgrenzung zur »Free Software« werden die Verwertungsinteressen der Unternehmen anerkannt. Damit wird die Deutung der F/OSS als marktförmig funktionierende Öffentlichkeit, als Basar, zentral, die entsprechend efﬁzienter und erfolgreicher in der Allokation von Ressourcen und Wissen in der Produktion sei. Was der projektübergreifende Diskurs der Entwickler damit leistet ist nicht weniger als die gelungene Konstitution und Abgrenzung eines eigenständigen Segmentes der Wissensproduktion und einer eigenen Form der Wissensproduktion. Das wurde und wird geleistet vor allem in den neuen, computerbasierten Medien und parallel zu einer aufblühenden kapitalistischen Softwareproduktion. Wie sich diese diskursive Setzung der zentralen Prinzipien in den konkreten Projekten ›materialisiert‹ ist Gegenstand des folgenden Kapitels.

4 Kommunikative und produktive Strukturierungen Die Welt ist einfach komisch, wenn man sie vom technischen Standpunkt ansieht; unpraktisch in allen Beziehungen der Menschen zueinander, im höchsten Grade unökonomisch und unexakt in ihren Methoden. (Robert Musil)

Als Fundament der F/OSS hat sich in der Diskursanalyse die Konstruktion eines gemeinsamen Wissenspools, aus dem heraus die selbstbestimmten Techniker die technische Entwicklung vorantreiben, herausgestellt. Wie sieht nun die Praxis in diesem diskursiv als eigenständig beanspruchten und konstituierten Bereich, also in einzelnen Projekten, aus? Daß sie, wie Musils Worte nahelegen könnten, praktisch, ökonomisch und exakt sei, ist nicht anzunehmen. Schließlich sind auch Programmierer »nur« Menschen. Nichtsdestotrotz ist anzunehmen, daß es einige Besonderheiten in diesen projektförmigen Zusammenhängen gibt. Wie wird also in den oft räumlich auf einem globalen Niveau operierenden Projekten kommuniziert, welche Besonderheiten weisen diese Kommunikation auf? Wie wird mit den sich daraus ergebenden Unwahrscheinlichkeiten (vgl. Abschnitt 2.3) umgegangen und wie werden die durch die medialen Grundlagen gesetzten Rahmen ausgestaltet? Diese Fragen sollen im ersten Teil dieses Kapitels beantwortet werden. Im zweiten Teil werden die sich aus und mit diesen Kommunikationen sowie aus den Rahmungen, die der Arbeitsgegenstand Software setzt (vgl. Abschnitt 2.2), bildenden stabilisierten Mikrostrukturen untersucht. Dazu werden für die folgende Ethnographie acht leitfadengestützte Experteninterviews mit Entwicklern aus unterschiedlichen Projekten

124

4 Kommunikative und produktive Strukturierungen

ausgewertet.125 In die Auswertung werden aber nicht nur die Aussagen der einzelnen Entwickler berücksichtigt, sondern auch zusätzlich Material aus den jeweiligen Projekten, soweit im Interview darauf Bezug genommen wurde, aber auch Material zu für die Fragestellung interessanten Ereignissen aus anderen Projekten einbezogen. Die Auswertung erfolgt nach dem in Abschnitt 3.1 beschriebenen Verfahren, wobei der Schwerpunkt für dieses Kapitel auf der Inhaltsanalyse lag.

4.1 Kommunikationen Die Koordination der Produktion wird in den Projekten über computerbasierte mediale Kommunikation abgewickelt. Für die tendenziell global angelegten F/OSS-Projekte ist die dabei zu verwendende Sprache ein erstes Problem (4.1.1). Ebenso wichtig ist die Frage nach den verwendeten Kommunikationsmedien (4.1.2). An die Verwendung von technischen Medien schließt sich die daraus ergebende Untersuchung des Umgangs mit den Speziﬁka und Besonderheiten dieser Kommunikationsformen an (4.1.3), mit der Öffentlichkeit der Kommunikation, mit den ›Lurkern‹, mit dem ›Rauschen‹ und schließlich die in dieser kommunikativen Praxis sich konstituierenden Regeln. Den Abschluß dieses Abschnittes bildet eine auf das empirische Material gestützte kurze Diskussion der Frage nach der Bedeutung der face-to-face-Kommunikation, bzw. deren Feheln, für die Stabilität der Projekte. (4.1.4). 4.1.1 Sprache Die Standardsprache in diesen tendenziell globalen Zusammenhängen (allerdings mit starken Schwerpunkten in den USA, Europa und Australien) ist Englisch. Das ist manchmal problembehaftet: »Auf den Mailinglisten ist es manchmal ’n bischen schwierig Entscheidungen zu treffen, oder überhaupt Diskussionen zu führen. Teilweise, weil die Sprache für manche Leute halt nicht die Muttersprache ist und dann Mißverständnisse auftauchen oder einfach jemand der Englisch nicht so 125 Die Interviews wurden

4.1 Kommunikationen

125

ﬂüssig schreibt wie andere Leute, dann halt irgendwie automatisch ’n kleineren Beitrag zur Diskussion manchmal leisten kann. Genau ’selbe im IRC, also da wo’s dann noch spontaner geht, also wenn man dann die Sprache nicht so gut beherrscht, da isses halt manchmal schwierig. Wobei es da einfacher is, Mißverständnisse auszuräumen.« (E5, Z. 172 ff.)126 E5 problematisiert die verwendeten Medien im Hinblick auf die Möglichkeiten Entscheidungen zu treffen und sogar auf das Führen von Diskussionen überhaupt. »Teilweise« werden diese Probleme auf unterschiedliche Kompetenzen in der englischen Sprache zurückgeführt. Das ist einer der Gründe, warum sich in einigen Projekten regionale Zusammenhänge bilden: »P2 is momentan relativ europazentrisch, weil ähm eigentlich nur zwei Entwickler ernsthaft was dran machen, das bin ich und ’n Österreicher. Was sehr angenehm is, weil man halt auch viel Diskussionen mal einfach auf Deutsch führen kann« (Interview E2, Z. 42 ff.)127 Die Einschränkung durch die mangelnde Sprachbeherrschung wird aber nur auf die Diskussion bezogen, nicht auf die Produktion. Die Sprache kann zu einer ersten Hürde für die kommunikative Beteiligung an einem F/OSS-Projekt werden. Auch der LinuxkernelEntwickler Greg Kroah-Hartman weist in seinem HOWTO für angehende Linux-Entwickler auf dieses Problem hin: »The language barrier can cause problems for some people who are not comfortable with English. A good grasp of the language can be needed in order to get ideas across properly on mailing lists, so it is recommended that you check your emails to make sure they make sense in English before sending them.«128 126 E5 ist Entwickler und »Leiter« eines kleineren Projektes unter dem Dach eines Großprojektes, einer Graphischen Benutzeroberﬂäche für das Linuxbetriebssystem. 127 E2 ist Entwickler in einem kleineren Projekt im Rahmen des Apache-Webserverprojektes. 128 http://www.kroah.com/log/, Eintrag unter dem Datum 17.11.2005, am 23.11.2005.

126

4 Kommunikative und produktive Strukturierungen

Um Ideen oder Vorstellungen verständlich zu machen »kann« es erforderlich oder nötig sein, die englische Sprache gut zu beherrschen. Zwar ist anzumerken, daß diese sprachliche Hürde für viele Programmierer nicht allzu hoch ist, weil Englisch weltweit die am häuﬁgsten erlernte Fremdsprache ist, weil das benutzte Englisch sehr stark mit programmier- und computertechnischen Fachausdrücken durchsetzt ist, die ein Programmierer im Laufe seiner »Techniksozialisation« erwirbt129 , weil die gängigen Programmiersprachen zudem stark mit Wörtern und Akronymen aus dem Englischen angereichert sind130 und weil die Beteiligung an Diskussionen nur einen Teilbereich der Tätigkeit ausmacht. Das »kann« im obigen Zitat von Kroah-Hartmann verweist auf einen zweiten Weg, Ideen und Vorstellungen auszudrücken: durch die formalisierte Schriftlichkeit von Programmcode. Für die Diskussion ist die englische Sprache wichtig, nicht jedoch für die Produktion, die erfolgt in einer Programmiersprache. Die Nutzung der Weltsprache Englisch bringt zwar die Möglichkeit für die Projekte, global zu agieren, weil sie (gerade für Softwareentwickler) das größte Integrationspotential hat. Aber sie bringt eine mögliche Einstiegshürde mit sich: für nicht-englische Muttersprachler könnte darin ein (kleineres) Problem und ein eventuelles Hindernis für die Beteiligung an einem F/OS-Projekt stecken. 4.1.2 Technische Medien der Kommunikation Mailinglisten Während in den 80er Jahren für die F/OSS noch viel über Newsgruppen kommuniziert wurde, werden heute vor allem Mailinglisten 129 Wie E2 in seiner biographischen Erzählung verdeutlicht: »und dann hab ich halt angefangen zu programmieren in Hex-Code nicht, nicht Assembler, nicht Basic oder irgendwas, sondern tatsächlich 8085 Hexcodes in den Intelhandbüchern nachgeschlagen, nicht daß ich hätte Englisch lesen können, neinneinnein« (E2, Z. 461 ff.). 130 »Johannes Lohmann [. . .] hat schon vor dreißig Jahren vorgeschlagen, den historischen Ermöglichungsgrund von Programmiersprachen einfach in der Tatsache zu suchen, daß es im Englischen Verben wie Read oder Write gibt, Verben also, die im Unterschied zum lateinischen amo amas amat undsoweiter alle Konjugationsformen abgestreift haben. Kontextlose Wortblöcke [. . .] hindert aber nichts daran, in kontextlose Mnemonics und schließlich in Computer-Opcode übersetzt zu werden.« (Kittler 1993c: 222)

4.1 Kommunikationen

127

und IRC benutzt. Das asynchrone Medium »Mailingliste« (vgl. Abschnitt 2.3) wird in nahezu allen Projekten eingesetzt. Es ermöglicht die automatische, softwaregesteuerte Verteilung von E-Mails an einen Abonnentenkreis. Diese asynchrone und nicht-sequentielle Kommunikationsform hat den Vorteil, daß ein relativ großes Zeitfenster für Antworten zur Verfügung steht. Ein sog. »thread«, eine themenbezogene Diskussion, kann Tage, Wochen, ja sogar Monate aktuell sein. Damit steht den Entwicklern ein relativ großer zeitlicher Antwortspielraum zur Verfügung. Die dadurch erfolgende Verlangsamung der Kommunikation (trotz des sekundenschnellen Transports der einzelnen Nachricht) hat natürlich auch eine Verlangsamung des Produktionsprozesses zur Folge. Gerade dieses auch medial bedingte Fehlen von Zeitdruck wird von den Entwicklern durchaus positiv bewertet: »Es ist halt alles irgendwie bei freier Software sehr viel relaxter, sehr viel gemütlicher, sehr viel stressfreier auch, es wird halt so darauf hingearbeitet. Wenn’s irgendwelche Termine gibt, dann eigentlich nur die, die man sich selber setzt, um halt irgendwo bischen zu Selbstkonsequenz irgendwie zu üben, aber ja, es is also alles sehr viel angenehmer.« (E1, Z. 399 ff.) Der größere zeitliche Spielraum ist gerade in Projekten, die global, also über verschiedene Zeitzonen, verstreut sind, und für selbstbestimmte Entwickler, die F/OS-Programmierung vor allem in der Freizeit betreiben, sehr wichtig.131 Die Zeit der Arbeit in F/OS-Projekten wird als selbstbestimmt wahrgenommen, was nicht zuletzt an der medialen Form liegt, die eine solche zeitliche Selbstbestimmung zuläßt. Dieser erweiterte Zeithorizont, der die Schnelligkeit des Informationstransports konterkariert, wird auch dadurch vergrößert, daß die Abhandlung von Problemen in diesem Medium länger als in persönlicher Interaktionen dauert. Die medienspeziﬁsche »Dehnung der Zeit« (Stegbauer 2001: 47) gilt in besonderer Quantität für die schriftliche Kommunikation über Mailinglisten. 131 Wie unten zu sehen sein wird, wird dieser entspanntere Zeithorizont in der Produktion auch als Begründung für höhere Qualität in Anschlag gebracht.

128

4 Kommunikative und produktive Strukturierungen

Dieses Medium wird von allen Entwicklern als relativ unproblematisch für die Koordination der Kooperation eingeschätzt. »Ähm, ich denk mal, solang’s wirklich um Code geht und solang’s da wirklich um Verbesserungen geht ähm ist es noch relativ einfach da Entscheidungen zu treffen, dann wird halt diskutiert auf den Mailinglisten und dann kommt irgendwie automatisch ’n Ergebnis raus. Im Endeffekt denk ich liegt so die letztliche Entscheidung dann beim Maintainer von dem betroffenen Code.« (E5, Z. 97 ff.) E5 als »Maintainer«, in diesem Falle Leiter eines Unterprojektes, hält die Kommunikation über Mailinglisten für ausreichend, sofern es »wirklich um Code geht«, also nur um die technische Ausführung der Produktion. Den Programmierern genügt für die Koordination der gemeinsamen Arbeit am Programmcode die asynchrone elektronisch-schriftliche Kommunikation, der gemeinsam geschaffene textuelle Raum. Die Diskussionen führen dann »automatisch«, das heißt in diesem Fall wohl: ohne sein Eingreifen als Projektleiter, zu einem Ergebnis. Dieses »elektronische Schreiben« (Wehner 1997b: 135) an ein nur teilweise bekanntes Publikum wird aber auch als einseitig und deﬁzitär beschrieben: »Ansonsten hat man immer nur ’n ganz schmalen Ausschnitt von einem Entwickler, man sieht halt seine professionelle Tätichkeit. Wenn ich einen P2-Entwickler was frage zu ’nem Thema und ich kriege ’ne Antwort, dann stell’ ich ja dann fest, hey der hat ’en Haufen Ahnung von dem Datenbankanwendungsteil, was weiß ich sonst von dem, ich weiß, daß [. . .] der programmieren kann, von diesem Thema Ahnung hat.« (E2, Z. 804 ff.) Das Medium Mailingliste, thematisch immer ﬁxiert an ein speziﬁsches Projekt, ermöglicht nur einen beschränkten Blick auf die Kommunikationspartner. Nur die Programmiertätigkeit wird lesbar. Allerdings stabilisiert sich dieses Bild durch häuﬁgere Teilnahme an der Kommunikation. Im zeitlichen Verlauf der gemeinsamen schriftlichen Kommunikation bildet sich dann ein zwar eingeschränktes, aber doch

4.1 Kommunikationen

129

stärker konturiertes Bild dieser Person bzw. seines Spezialwissens, seiner Programmier- und Kommunikationsfähigkeiten heraus. Das genügt für die alltägliche Koordination im Projekt, wird aber insgesamt als ein Mangel empfunden (vgl. unten 4.1.4). Internet Relay Chat Neben den Mailinglisten ist der Internet Relay Chat (IRC, vgl. 2.3) ein zweites wichtiges Medium, allerdings vor allem auf regionaler Ebene. In globalen Zusammenhängen ist die zeitliche Koordinierung, die unumgänglich für diese Form der beinahe synchronen, schriftlichen Kommunikation ist, problematisch, wie etwa E1 für das Projekt P1 ausführt, in dem vor allem Entwickler aus Australien, Kanada und Europa zusammenarbeiten. Ein Versuch über IRC zu kommunizieren, wurde in diesem Projekt aufgrund der Zeitzonendifferenzen abgebrochen, weil sich kein für alle praktikabler zeitlicher Kommunikationskorridor fand. Für Projekte mit einer regionalen Konzentration der Entwickler gilt das jedoch nicht: »Es ist primär E-Mail und IRC, also es gibt’n IRC-Channel, es gibt ’n eigenen Server, den betreibt jemand, ’n anderer Entwickler und dort gibt’s halt ’n entsprechenden Channel, und da hängt man dann halt rum und das diskutiert man dann, das is eigentlich der normale Weg der Kommunikation.« (E2, Z. 84 ff.) Für E2 ist IRC der »normale Weg der Kommunikation«, darüber kommuniziert er mit seinem österreichischen Entwicklungspartner (in deutscher Sprache). Mit dem »rumhängen« beschreibt er (s)eine Umgangsweise mit dieser Kommunikationsform: das IRC-Programm läuft neben der eigentlichen (Erwerbs-)Arbeit im Hintergrund. Das Programm signalisiert in diesem Modus vom Server gesendete Kommunikationsbeiträge oder kann bei Bedarf, etwa wenn eine Frage auftaucht, aktiviert werden. Eine solche Umgangsform ist natürlich nur auf weniger stark frequentierten Kanälen möglich, was in dem relativ kleinen Projekt von E2 (»Also das Projekt is in der Sache einfach sehr viel Größenordnungen kleiner und dadurch einfach sehr viel überschaubarer als jetzt sag’mer mal die Highlightprojekte wo jeder sich mit beschäftigen möchte oder jeder draufguckt.« Z. 159 ff.) durchaus möglich ist.

130

4 Kommunikative und produktive Strukturierungen

Neben der Schwierigkeit, eine zeitliche Koordination über verschiedene Zeitzonen hinweg zu organisieren, werden jedoch noch andere Argumente gegen die Verwendung von IRC angeführt: »IRC ist so ein Medium, was manche Entwickler sehr stark einsetzen, manche auch weniger, also ich persönlich benutz’s eigentlich relativ wenig, weil’s relativ viel Zeit kostet, aber es ist halt noch’n ziemlich direkter Zugang.« (E2, Z. 140 ff.) Für E5 bestehen die Vorteile des IRC darin, daß es ein »ziemlich direkter Zugang ist« und daß es »einfacher is, Mißverständnisse auszuräumen« (Z. 179 f.). Gerade die aufgrund der (fast) synchronen Kommunikation entstehenden zeitlichen Zwänge stellen für ihn jedoch den entscheidenden Nachteil dar. Diese Einschränkung gilt auch, wenn das IRC-Programm neben der normalen Arbeitsumgebung läuft. Das zeitliche Antwortfenster ist im IRC wesentlich kleiner als im Falle der Mailinglisten und wird hier als Einschränkung thematisiert, weil es eine erhöhte Aufmerksamkeit erfordert und damit Zeit kostet, die im Rahmen einer regulären Erwerbsarbeit nicht immer zur Verfügung steht. Auf der anderen Seite wird die schriftliche Synchronizität gerade wegen dieses Gleichzeitigkeitsmoments von ihm auch als unmittelbarer beschrieben und insofern funktionaler, weil auftretende Mißverständnisse schneller behoben werden können. Auch in der Benutzung des IRC ist die speziﬁsche Zeitlichkeit des Mediums ein strukturierendes Moment, eines das aufgrund der damit verbundenen Einschränkungen in der Zeitverfügung jedoch nicht von allen Entwicklern geschätzt wird. 4.1.3 Kommunikative Besonderheiten Im Folgenden soll rekonstruiert werden, welche kommunikativen Besonderheiten sich in und aus der Verwendung dieser Medien in den Projekten ergeben. Hervorzuheben sind dabei meines Erachtens die Öffentlichkeit der Kommunikation, das Phänomen der »Lurker«, die Formen der als ›Rauschen‹ bezeichneten störenden Kommunikation und schließlich die Differenzierungen und Regeln, die sich daraus ergeben.

4.1 Kommunikationen

131

Öffentlichkeit Die Kommunikation verläuft in F/OSS-Projekten fast ausschließlich in öffentlicher Form.132 Das heißt, konform zur freien Zugänglichkeit des eigenen Wissensbereiches im Diskurs bleiben die einzelnen Projekte in der Kommunikation offen für alle. »Sind auch alles ziemlich offene Mailinglisten, wo jeder drauf posten kann, die alle öffentlich archiviert sind. Also das läuft alles offen ab, da gibt’s auch keine, also es gibt fast keine wirklich irgendwie privaten oder geschlossenen Mailinglisten, für die Entwicklung sowieso nicht.« (E5, Z. 188 ff.) Diese Öffentlichkeit wird von allen Entwicklern betont: Nicht nur der Quellcode und die Programme sind offen zugänglich, sondern auch alle computerbasierten Kommunikationen zur Produktion. Diese werden auch alle archiviert, sind also Jahre später noch zugänglich. Damit ist nicht nur das in der Software explizierte Wissen frei zugänglich, sondern ebenso die Kommunikation, die sich um die Genese dieses Wissens rankt. Es handelt sich dabei natürlich eine speziﬁsche Form von Teilöffentlichkeit (Roesler 1997: 192), die für eine Teilhabe bestimmte Voraussetzungen macht. Zum ersten müssen gewisse technisch-materielle Voraussetzungen gegeben sein, um an einer Mailinglistendiskussion teilzunehmen: Computer, Netzanbindung und Software, deren Verfügbarkeit diejenigen, die sie besitzen als »kein großartiges Selektionskriterium« (Roesler 1997: 183) ansehen, das aber in dem globalen Kontext, in dem F/OSS funktionieren will und soll, durchaus ein Selektionskriterium darstellt. Zum zweiten sind die Englischkenntnisse, die durchaus nicht überall ausreichend für die Teilnahme (oder auch nur die Rezeption) an diesen Diskusssionen vorhanden ist (vgl. 4.1.1). Zum dritten ist aufgrund der stark technisch geprägten und mit programmierspeziﬁschen Ausdrücken angereicherten Sprache ein gewisse Erfahrung im Umgang mit Computern nötig, Computeralphabetisierung, die sich zumindest auf die Grundlagen der Programmierung erstrecken muß. 132 Nur im KDE-Projekt gibt es meines Wissens eine geschlossene Mailingliste nur für die Kerngruppe des gesamten Projektes, die auch nicht öffentlich archiviert wird.

132

4 Kommunikative und produktive Strukturierungen

Trotz dieser Wissens- und materiellen Schwellen wird diese vorbehaltlose Offenheit der Kommunikation in einem öffentlichen, textuellen Raum, die durchaus mit technischen Mitteln eingeschränkt werden könnte (geschlossene, moderierte oder passwortgeschützte Mailinglisten), getragen von den Idealen der freien Rede, des uneingeschränkten Informations- und Wissensﬂusses und des freien Zugangs dazu. Diese offene Praxis ist ein Ausdruck des gelebten Ideals der Informationsfreiheit: »Daß ich einfach grundsätzlich erstmal der Meinung bin, daß Wissen niemand gehören sollte.« (E1, Z. 340 f.) Neben dieser normativen Funktion trägt diese Offenheit und Öffentlichkeit auch zur Verbreiterung der Anwenderbasis und damit potentiell auch zur Verbreiterung der Entwicklerbasis bei. Diese Öffentlichkeit der Kommunikation wird, wie zu sehen sein wird, auch bei Störungen keineswegs aufgehoben (vgl. unten). Lurker Ein Großteil der Abonnenten von F/OS-Mailinglisten verharrt in einer passiven Kommunikationshaltung. Hier läßt sich das von Stegbauer und Rausch (2001) analysierte Phänomen der sog. »Lurker« ﬁnden: »Also bei’ner Größerordnung von=von einigen Dutzend Entwicklern und sag’mer mal Nutzer, die sich auf den Mailinglisten zeigen, daß sie mit dem Programm arbeiten und nicht bloß passiv dort sitzen und quasi zuhören, was an Kommunikation stattﬁndet, würd ich sagen sind maximal einige wenige hundert, also vielleicht hundertfünfzig zweihundert, das heißt die Listen sind auch überschaubar, also auf der Userliste würd ich sagen, da kommen irgendwo so zwischen dreißig und fünfzig mails am Tag und auf der Developerliste noch weniger, also das is etwas, was man vormittags beim ersten Kaffee problemlos lesen kann und auch dann problemlos sich aktiv an der Entwicklung beteiligen kann.« (E2, Z. 148 ff.) Auch im Projekt P1 ist das Verhältnis ähnlich: 20 ständige Contributors, aber etwa 300 - 400 Leute auf der Entwickler-Mailingliste. Es existieren in den öffentlichen Kommunikationsforen eine große Zahl von sog. »Lurkern«, Leute also, die nur die Mailingliste mitlesen, aber

4.1 Kommunikationen

133

sich nicht aktiv an den Diskussionen (und der Produktion) beteiligen. Das ist sowohl bei den Mailinglisten für Anwender so, als auch bei denen für Entwickler (»momentan eigentlich nur zwei Entwickler [,die] ernsthaft was dran machen.« E2, Z. 43). Das Phänomen der Lurker auf den Entwicklermailinglisten kann auf verschiedene Weisen gedeutet werden: Es können interessierte Anwender sein, die sich über den aktuellsten Entwicklungen in einem Projekt informieren, sich jedoch nicht selbst an der Entwicklung beteiligen können oder wollen. Oder es sind Leute, die nur gelegentlich Code für das Projekt produzieren, E1 erwähnt »viele one-shot-Beiträge«, aber sich weder regelmäßig an Diskussionen noch an der Produktion beteiligen. Es können Programmierer aus ähnlichen Projekten oder benachbarten Projekten unter dem Dach eines gemeinsamen Großprojektes sein, die sich für die Entwicklung interessieren (E1, E2 und E5 erwähnen diese Möglichkeit). Oder es sind Programmierer aus der kommerziellen Softwareproduktion, die sich für die aktuelle Entwicklung interessieren. Schließlich gibt es Wissenschaftler, die sich für die Kommunikationen auf Mailinglisten interessieren.133 Ein Fall eines »Lurkers« ﬁndet sich im Interviewsample: E8 ist ein Programmierer, der aufgrund der Arbeit in seiner eigenen Softwareentwicklungsﬁrma nur gelegentlich Patches an einzelne für ihn interessante Projekte schickt und dort auch Mailinglisten mitliest: »Also bei [Projekten, die für die eigene Arbeit interessant sind], da les ich halt die Mailinglisten mit, aber oft nur die Subjects, aber wenn ich keine Zeit hab, dann lösch ich des auch einfach wech.« (E8, Z. 126 ff.) Die eigene Arbeit schränkt sein Zeitbudget so stark ein, daß er über ein gelgentliches Mitlesen gar nicht hinaus kommt. Insofern unterstützen die durch das Medium gebotenen Möglichkeiten, Netzverbindungen und Speicherplatz (wodurch auch größere Textmengen nicht besonders ins Gewicht fallen, schnelle Orientierung an den Themen in 133 Die Deutung, daß Lurker mit dem stummen Publikum von Großgruppen im realen Raum gleichgesetzt werden können, verbietet sich aufgrund der medialen Besonderheiten von Mailinglisten. Für eine Diskussion dieses Punktes vgl. Stegbauer und Rausch (2001: 60 f.).

134

4 Kommunikative und produktive Strukturierungen

den Betreff-Zeilen des Mailprogramms, einfaches Sortieren, Archivieren und Löschen, auch eine Praxis des »Lurkens«. Das in den Listen präsentierte Wissen wird eingeschätzt und gemäß den persönlichen Relevanzen gespeichert, weiterverwendet, weitergegeben oder irgendwann später gelöscht. Man bestellt sich die vielleicht oder gelegentlich interessanten Listen, nimmt die Sortierung aber erst auf dem eigenen Rechner vor. Im Falle von hochfrequentierten Listen führt das gelegentlich zu einem Verarbeitungsproblem. E2 schildert den Umgang mit einer solchen Informationsﬂut: »Bei der Linuxkernelmailingliste, we’mer also zwei Tage nicht liest, dann löscht mer erstmal die ganzen fünftausend Mails, weil es überhaupt gar nicht möglich ist, die kontinuierlich komplett zu lesen.« (E2, Z. 157 ff.) 134 Eine andere Deutung für das Phänomen »Lurker« sind Entwickler, die früher aktiv(er) waren, aber aktuell keine Zeit und in das Projekt investieren können oder wollen. Das würde auf eine größere Fluktuation bei den Entwicklern hinweisen, die E5 auch bestätigt: »Also es läßt sich schwer sagen, weil’s keine geschlossene Gruppe is, weil’s stark im Fluß ist. Also wenn Leute kommen, die machen irgendwie einmal was, schicken einmal ’n Patch, der toll ist, tolle neue Features einbaut und es gibt Leute, die halt regelmäßiger mal irgendwie was machen, aber ’s ändert sich schon sehr stark.« (E5, Z. 39 ff.) Diese verschiedenen Deutungen können alle für das anonyme Publikum der Mailinglisten zutreffen. Obwohl sie nicht in der Kommunikation in Erscheinung treten, nehmen sie zumindest passiv an der kollektiven Produktion und Verteilung von Wissen teil. Ein Desiderat bleibt die Typisierung dieser passiven Teilnehmer in der computerbasierten Kommunikation. ›Rauschen‹ Die computerbasierten schriftlichen Medien haben bestimmte Eigenheiten, die vermehrt zu Tage treten sobald die Projekte eine bestimmte Größe erreicht haben. Dann sind abstraktere Diskussionen über 134 Zu diesem Phänomen des sog »information overload« durch Mailinglisten und dem Umgang damit vgl. auch die Diskussion in Stegbauer (2001: 171 ff.) und Tuten.

4.1 Kommunikationen

135

Design, Planung, Konzeptionen, Rechtsfragen oder Grundlagen der Kooperation nötig. »Letztlich laufen solche Konﬂikte, die wirklich, wo dann einfach nur noch irgendwie Mails hin und her gepostet werden, meistens auch einfach irgendwie ins Leere. [. . .] Grade wenn’s um Code geht, wer’n da halt neue Sachen diskutiert, irgendwelche Lösungen und dann, solche abstrakten Diskussionen, wie man irgendwas schreiben müßte und wie jetzt theoretisch des beste Design aussehen sollte, ohne daß da irgendwie viel dahintersteckt an wirklich Arbeit und vorhandenem Code, das läuft irgendwie meistens darauf hinaus, daß halt Leute, die keinen Code schreiben, diskutieren und grad die Leute, die den Code schreiben, dann halt die Entscheidung treffen, wie’s tatsächlich läuft. Und da werden Fakten geschaffen und dann ((lacht kurz auf)) funktioniert das.« (E5, Z. 220 ff.) Bei solchen Themen zeigen sich die Beschränkungen der schriftlichen, computerbasierten Kommunikation, das Fehlen von parasprachlichen Zeichen (Mimik und Gestik), sowie persönlichem und situativem Kontext. Es entsteht ein ›Rauschen‹ in der Kommunikation, ein Anteil der Kommunikation, der als unnötig, störend und die Kommunikation und Produktion belastend empfunden wird.135 Stegbauer (2001: 172) unterscheidet drei Arten des Rauschens: semantisches Rauschen (Doppeldeutigkeiten, Verwirrungen, Mißverständnisse), stilistisches Rauschen (Regel- und Stildiskussionen) und Informationsrauschen (redundante, irrelevante Informationen). Die von E5 geschilderten »abstrakten Diskussionen«, in diesem Fall eine Form des stilistischen Rauschens, »wie man irgendwas schreiben müßte«, laufen ins Leere, viele Beteiligte klinken sich aus. Bei E5 taucht in der Schilderung zudem eine Grenze auf zwischen Leuten, die Code 135 Dieser aus der Informationstechnik übernommene Begriff verweist auf eine durch akustische oder elektromagnetische Schwingungen verminderte Qualität von Signalen. In dem hier analysierten sozialen Kontext wird die Unterscheidung Signal/Rauschen, und damit die normative Beurteilung der Funktionalität, ausschließlich aus der Perspektive der Kommunikationsteilnehmer vorgenommen.

136

4 Kommunikative und produktive Strukturierungen

schreiben und Leuten, die keinen Code schreiben, sondern nur diskutieren. Erstere steuern die Richtung des Projektes durch die Schaffung von technischenTatsachen, durch die normative Kraft des Faktischen, letztere stören letztendlich nur durch unangemessene und überﬂüssige Diskussionsbeiträge. Ein wichtiges Instrument zur Begrenzung und Steuerung solcher, als unproduktiv empfundenen Diskussionen ist dieses performativ-produktive Setzen von Programmcode. Mit diesem Code wird eine Entscheidung getroffen, die zwar kommunikativ wieder eingeholt, etwa legitimiert, werden kann, die aber nur durch einen oder mehrere weitere performativ-produktive Akte wieder rückgängig gemacht werden kann. Es gibt neben den drei erwähnten Formen eine besondere Form des Rauschens in der elektronisch-schriftlichen Kommunikation. Klapp (1978), auf den sich Stegbauer bei der Differenzierung des Rauschens bezieht, hat noch eine vierte Form aufgelistet: »contagious noise«, darunter faßt er »negative feelings such as ill will, suspicion, discontent, despair, lawlessness and unrest« (Klapp 1978: 4). Diese Form des Rauschens vergleicht er mit der Luftverschmutzung. Ohne diese normative Konnotation zu übernehmen, könnte der Begriff des negativemotionalen Rauschens eine teilweise häuﬁge Form der Kommunikationsstörung in elektronisch-schriftlicher Kommunikation fassen, den andauernden Austausch von Beschimpfungen, die »ﬂame wars«. Gerade diese Form des Rauschens macht einen erheblichen Anteil der nicht-themenbezogenen Kommunikation auf den Mailinglisten aus. E3136 berichtet von einem solchen Fall: »Es war auch so, daß zu [de]m Zeitpunkt [. . .] ’s einige .. äh Lizenzstreitigkeiten gab und wir ham damals also die also die Lizenz [. . .] geändert, das gab doch zuerst auf der Mailingliste sehr sehr lange Diskussionsthreads, wo dann wüste Beschimpfungen und was auch immer kam, sich Leute von extern eingemischt ham, die eigentlich nichts mit’m P3.1-Projekt zu tun ham, sondern die nur gerne 136 E3 ist an zwei Projekten beteiligt, einer Sammlung speziﬁscher Hardwaretreiber für speziﬁsche Hardwarekomponenten (P3.2) und einem größeren Projekt, das den Austausch zwischen verschiedenen Betriebssystemen sicherstellen soll (P3.1).

4.1 Kommunikationen

137

diskutieren.« (E3, Z. 182 ff.)137 Gerade wenn die Diskussion hitzig wird, und die E-Mails entsprechend schnell, unüberlegt und emotional geschrieben werden, kommt es häuﬁg zu »wüsten Beschimpfungen«, sog. »ﬂames«, zwischen den Diskutanten. Nach E3 wird in diesem Fall die Öffentlichkeit der Mailinglisten zum Problem, weil sich »Leute von extern einmischen«, die nur gerne diskutieren und die Diskussion unnötig emotionalisieren. Damit wird ebenfalls eine Grenze zwischen Leuten, die am Projekt arbeiten, und Leuten, die nur (emotional) diskutieren (und damit die Arbeit stören), eingezogen. Dieses beschriebene negativ-emotionale Rauschen ist keineswegs ein Einzelfall, sondern durchaus häuﬁg in den Kommunikationen anzutreffen, wie auch E4 feststellt: »Auf den Mailinglisten hauen sich die Leute teilweise die Köpfe ein.« (E4, Z. 383 f.)138 Das entspricht meinem durch vielfältiges, allerdings nicht systematisches Beobachten der Kommunikationen der F/OSS gewonnenem Eindruck. Dagegen sind semantisches, stilistisches und Informationsrauschen verglichen mit anderen Mailinglisten und Newsgruppen, wo die Diskussionen um interne Regelsysteme, deren Einhaltung oder Änderung, also stilistisches Rauschen, oft mehr als 50 % der gesamten Kommunikation ausmachen, seltener zu ﬁnden. Der größte Teil der Kommunikation läuft erstaunlich sachlich, nüchtern und stark produktionsbezogen ab: »[Diskussionen um Kommunikationsregeln] gibt’s gibt’s selten. Solche Sachen passieren eigentlich fast nie. Könnt mich jetzt nicht erinnern, daß da mal wirklich so’ne Diskussion um so Sachen stattgefunden hätte.« (E5, Z. 199 ff.) Semantisches Rauschen ist aufgrund der um eindeutigen Programmcode zentrierten Kommunikation ebenfalls relativ selten und Informationsrauschen angesichts der hohen Spezialisierung in der Themenstellung selten zu ﬁnden.139

137 Ähnlich verliefen, um zwei konkrete Beispiele anzuführen, etwa die Diskussionen auf der Linuxkernelmailingliste zur Organisation der Entwicklung (vgl. http://lkml.org/lkml/2002/1/28/83) oder der Verwendung eines neuen Programmes zur Codeverwaltung (vgl. etwa http://lkml.org/lkml/2005/4/6/121). 138 E4 ist Entwickler in einem der größten F/OSS-Projekte. 139 Was natürlich häuﬁger vorkommt, aber durch maschinelle Filterung weitgehend ausgeschaltet wird, sind unerwünschte Werbemails, sogenannter »Spam«.

138

4 Kommunikative und produktive Strukturierungen

Differenzierungen und Regeln Die bisher erwähnten Formen der nicht erwünschten, nicht erwarteten oder nicht regelgerechten Kommunikation erfordern in öffentlichen elektronischen Medien einen speziﬁschen Umgang. Im Gegensatz zu Interaktionen fehlen hier feinere Reaktions- und Signalisierungsmöglichkeiten, etwa in Form von Mimik oder Gestik. Zudem ist keinerlei direkte Machtausübung auf als störend empfundene Kommunikationsteilnehmer möglich. Die Reaktionen bestehen zum einen darin, die Kommunikationsforen auszudifferenzieren, um eine möglichst ungestörte Arbeit zu ermöglichen und zum anderen darin, Regeln aufzustellen, die jedoch wieder speziﬁsche Sanktionsformen erfordern. In keinem Fall wurde jedoch meines Wissens bisher die Öffentlichkeit der Foren eingeschränkt. Die Entwicklermailinglisten von F/OS-Projekten sind produktionsorientiert: das Ziel ist die Koordination der gemeinsamen Softwareentwicklung oder letztlich die zu programmmierende Software. Dafür gibt es zwar keine vorher vereinbarte Themenabfolge. Die Diskussionen verlaufen eher ungeplant und assoziativ. Aber das von allen geteilte und hoch spezialisierte Ziel sorgt für größtenteils sachliche Diskussionen und bereits ausgehandelte Regeln werden selten wieder in Frage oder zur Disposition gestellt, wie es für weniger spezialisierte Mailinglisten mit hoher Teilnehmerzahl und vor allem für das Usenet typisch ist. Die Ausdifferenzierung von getrennten Mailinglisten für unterschiedliche Probleme und Gruppen ist ein Versuch, diese Zielorientierung auch bei einer Erhöhung der Zahl der Teilnehmenden sicherzustellen. Ein Kriterium für die Ausdifferenzierung kann ein die produktive Diskussion störendes Rauschen sein, das sich so um einen thematischen Kern gruppiert, daß es sich wie im erwähnten Fall der Lizenzdiskussion von P3.1 in eine eigene Mailingliste verlagern läßt. Die erste Ausdifferenzierung ist in allen Projekten eine in Entwickler und Anwender. Je nach Größe des Projektes kommen weitere dazu: Listen für den Kern der Entwickler (P1, P5), oder spezialisierte Listen für abgegrenzte Themen oder Unterprojekte (P3.1, P4, P5). In der Kommunikation bleiben damit beispielsweise die Nur-Anwender von den Programmierenden getrennt. Nachdem die Mailinglisten (fast) alle öffentlich zugänglich sind, und jede/r mit einer einfachen Mail an das Listenverwaltungsprogramm Zugang erhält, kann diese

4.1 Kommunikationen

139

Trennung jedoch nicht scharf gezogen werden: »Äh es gibt eine Userliste, dort is halt dann heißt es immer also, wenn Du mit dem Programm was entwickeltst, ’n Applikation entwickelst und Fragen dann dazu hast, frage hier, und die Developerliste is halt für die Entwicklung an der Applikation selber, aber die sind nich irgendwie geschlossen und da dürfen nur bestimmte Leute drauf, sondern da darf jeder drauf subscriben, die sind ganz regulär auf dem beim Projekt-Server zu erreichen, bloß es is halt so, daß we’man auf der Developerliste Fragen hat, für ’ne Applikation, die man mit dem Framework schreibt, wird man wahrscheinlich keine Antwort kriegen.« (E2, Z. 106 ff.) Die Reaktion auf eine fehlerhaft plazierte E-Mail, eine Überschreitung der Kommunikationsgrenzen, ist demnach Kommunikationsabbruch und damit die Verhinderung von unsachlicher Kommunikation. Eine andere, ebenfalls gebräuchliche Form der Reaktion ist die Zurechtweisung des »Störenfrieds«. So wird versucht, die Anwender vom Entwicklerbereich fernzuhalten und die Trennung der Kommunikationsbereiche aufrechtzuerhalten. Diese Zurechtweisungen und die Kommunikationsverweigerungen sind eine Form der sozialen Schließung: Bestimmte Themen werden aus der Diskussion ausgeschlossen, um eine reibungslose Arbeit zu gewährleisten. Neben dieser Ausdifferenzierung der Kommunikation wäre eine weitere Möglichkeit, das Rauschen auf den Listen zu vermindern, explizite Regeln für die Kommunikation einzuführen. Daß es für die Kommunikation über Mailinglisten Regeln gäbe, wird jedoch von den meisten Interviewten verneint, obwohl auf vielen Projektseiten im Internet explizite Regeln formuliert sind.140 »Des einzige was es [an Regeln] gibt is so’n ›Wie verhält man sich jetzt aus technischer Sicht auf’ner Mailingliste‹, auf P4-Mailinglisten, also daß man zum Beispiel auf 140 Das gilt zumindest für die größeren Projekte, vgl. etwa http://www.kde.org/mailinglists/ http://mail.gnome.org/ http://www.kernel.org/pub/linux/docs/lkml/.

140

4 Kommunikative und produktive Strukturierungen ’ne Mailingliste, wenn man auf ’ne Mail antwortet, nicht noch’n CC [=Kopie] an denjenigen schreibt, der die Mail geschrieben hat und das sind technische Sachen, so soziale Sachen sind meines Wissens nicht irgendwo festgelegt.« (E4, Z. 386 ff.)

E5 nennt auf die Frage nach Regeln für die Kommunikation die allgemeine Netiquette als generelle, aber nicht projektspeziﬁsche Regel: »Also es gibt keine expliziten Regeln. Es gibt denk ich viele, also ich sag mal keine expliziten P5-Regeln. Ich denk mal es gibt eine ganze Reihe von Regeln, die so allgemeine Netiquette sind, wie man sich eben auf Mailinglisten überhaupt zu verhalten hat. Ich denke, die werden da genauso angewendet, wie sonst überall auch. Ansonsten gibt’s keine speziellen Sachen.« (E5, Z. 184 ff.) Auch im Projekt P5 existieren explizite Regeln zum Verhalten auf den Mailinglisten, in technischer und sozialer Hinsicht. E5 liefert jedoch eine Erklärung für dieses Nichtwissen vom Vorhandensein von ausformulierten Kommunikationsregeln: »Ich denk auch, es liegt auch einfach daran, daß es doch ’ne relativ homogene Gruppe an Leuten is. Also’s sind halt alles Leute, die irgendwie einiges an Erfahrung irgendwie mit Computern, mit Internet, mit Kommunikation im Netz haben und deswegen werden selten solche Regeln irgendwie auch verletzt, oder zumindest nicht in so’nem Maße, daß man sich wirklich drüber aufregen würde.« (E5, Z. 201 ff.) Die vorhandenen und zumindest in vielen größeren Projekten auch explizierten Regeln sind für die Programmierer aufgrund der langjährigen Kommunikationspraxis mit computerbasierten Medien selbstverständliches, implizites Wissen geworden. Als ›alte Hasen‹ der computerbasierten Kommunikation haben sie es auch nicht nötig, sich eventuell vorhandene Regeln anzuschauen, sofern im Projekt sich nicht eine

4.1 Kommunikationen

141

mit der bisherigen Praxis, die sich an der sogenannten Netiquette141 orientiert, kollidierende neue Praxis ergibt. Die Homogenität bezieht damit sich auf die zuhandenen, impliziten Wissensvorräte der beteiligten Entwickler. Diese impliziten Wissensvorräte, das könnte man aus dieser kurzen Passage auch schließen, müssen in bestimmten Bereichen eine gewisse Deckungsgleichheit aufweisen, damit eine weitgehend als störungsfrei wahrgenommene Kommunikation zustande kommt. Daß die Einhaltung der Regeln keineswegs selbstverständlich war und ist, zeigt schon das Vorhandensein der Regelwerke. Im Falle des negativ-emotionalen Rauschens ﬁndet sich eine andere Form des Umgangs mit (dann gehäuft auftretender) nicht regelgerechten oder als störend empfundenen Diskussionen: der Schließungsmechanismus Kommunikationsverweigerung. »Naja also die Diskussion, also einige Leute haben dann auch mit denen diskutiert, aber viele haben dann gesagt: Ja, sag’n wir gar nichts mehr, ignorieren wir sie einfach und dann gehen sie schon weg.« (E3, Z. 305 ff.) Auch hier wird die Grenzziehung zwischen einer Wir-Gruppe (wenn auch nur als Zitat) und einer Die-Gruppe deutlich. Die Störer, oder die Verursacher des Rauschens, werden als Außenstehende semantisiert, die mit dem Projekt nicht nur nichts weiter zu tun haben, sondern sogar den ordentlichen Ablauf von Kommunikation und Produktion stören. Für die öffentliche(n) Mailingliste(n) bestehen nur geringe Möglichkeiten der Sanktion. Entweder kann versucht werden, die Störenden kommunikativ zurechtzuweisen. Das führt aber nur zu weiterem Rauschen und birgt in diesem Medium keinerlei Erfolgsgarantie. Eine andere Möglichkeit wäre die Entfernung der Adressen der Störenden aus dem Verteiler, also ein technischer Eingriff in die Offenheit der Kommunikation. Allerdings könnten die sich postwendend mit einer anderen E-Mailadresse anmelden. Damit würde aber die für die Projekte notwendige Öffentlichkeit (etwa für die Gewinnung neuer 141 Die Netiquette ist eine Sammlung von allgemeinen Verhaltensregeln in der elektronischen Kommunikation. Vgl. zum Beispiel http://www.chemie.fu-berlin.de/outerspace/ netnews/netiquette.html.

142

4 Kommunikative und produktive Strukturierungen

Mitarbeitender) gefährdet (vgl. unten 4.2.2). Damit bleibt die Kommunikationsverweigerung für die Teilnehmenden der einzige Weg, einer sinnlosen Diskussion zu entkommen, und der Regelfall: »Es gibt dann Leute, die diskutieren irgendwie noch weiter, aber auch das ist dann so, daß ziemlich schnell viele Leute keine Lust mehr haben, dann noch Einzelne übrigbleiben.« (E5, Z. 222 ff.) »ich klink mich meistens dann aus den Threads aus, bevor’s mir zu dumm wird.« (E4, Z. 395 f.) Nicht die Störer werden ausgegrenzt, sondern die genervten Entwickler ziehen sich in solchen Fällen aus der Kommunikation zurück. Die soziale Schließung erfolgt durch Ignorieren des störenden Teils der Kommunikation. Wenn solche Störungen anhand bestimmter Themen häuﬁger aufkommen, gibt es auch die (technisch einfache) Möglichkeit, eine auf dieses Thema fokussierte eigene Mailingliste aufzusetzen (»und wegen der Lizenzdiskussion hat’s mal irgendwann eine P3.1-LicenseMailingliste eingerichtet« E3, Z. 277 f.). Die kommunikativen Abgrenzungen zwischen der produktiven Diskussion der Entwicklung und störendem Rauschen erfolgen über Regelsysteme. Diese Regelsysteme sind aufgrund der relativ homogenen impliziten Wissensvorräte der Programmierenden eher für Neulinge und Außenstehende. Wo ein solches Regelsystem nicht greift oder ignoriert wird, erfolgt in Einzelfällen Zurechtweisung oder Kommunikationsverweigerung, ansonsten wird darauf mit Kommunikationsverweigerung oder die teilnehmerbezogene oder thematische Ausdifferenzierung der Kommunikationsmedien reagiert. Besonderheiten, Strukturierungen, Typisierungen Zusätzlich zu dem bisher Entwickelten läßt sich in der Kommunikationssphäre der F/OSS das von Stegbauer (2001) analysierte ZentrumPeripherie-Muster ﬁnden. Das heißt, daß sich in der Diskussion ein Zentrum von besonders aktiven Teilnehmern herausbildet, um das sich eine Peripherie mit abnehmender Teilnahmefrequenz gruppiert.142 142 Interessanter (und aussagekräftiger) als eine solche quantitative Netzwerkanalyse wäre meines Erachtens eine Typologisierung der Teilnehmer entsprechend des Ver-

4.1 Kommunikationen

143

Dabei zeichnet sich der Projektleiter keineswegs durch die größte Anzahl der Beiträge aus, sondern von ihm kommen eher die qualitativ wichtigen Themensetzungen und er verkündet und legitimiert umstrittene(re) Entscheidungen. Seine Beiträge (und die der anderen zentralen Akteure) erhalten größere Aufmerksamkeit.143 Diese zentralen Akteure dominieren das kommunikative Gefüge. In diesem Sinne läßt sich von einer kommunikativen Hierarchie und einer vertikalen Strukturierung sprechen, die sich gerade in einem Medium herausbilden und durchsetzen, das aufgrund der für alle verfügbaren Antwortfunktion als besonders egalitär gilt.144 Neben dieser vertikalen Strukturierung der Kommunikation ﬁndet sich auch eine horizontale Strukturierung (wiederum ähnlich wie bei Stegbauer 2001) in Kern, Spezialisten145 , Diskutanten und ›Lurker‹ (vgl. oben). Diese kurzen Analysen weisen auf einige auffallende Ähnlichkeiten der F/OSS-Zusammenhänge mit den Gruppen der Street Corner Society auf, wie sie von Whyte (1996) analysiert wurden. Zum einen gibt es im kommunikativen Gefüge eine Anzahl von Positionen, die relativ ﬁx sind, während die Individuen die Positionen durchaus wechseln können. Zum zweiten werden diese Positionen aufgrund der Leistungen in den alltäglichen Aktivitäten (Programmierung oder Kegeln) besetzt, eine gegenseitige Abhängigkeit von sozialem Rang und Leistung wie sie auch Homans (1960: 277) in seiner Analyse der Studie von Whyte beschreibt. Trotz der teilweise vorhandenen explizierten Regeln machen die F/OSS-Zusammenhänge auch eher den Eindruck von informellen Verbindungen, nicht zuletzt weil das mediale Setting eine Durchsetzung von Satzung und Statuten schwierig macht und die Fluktuation doch recht hoch zu sein scheint. Gerade letzteres weist aber auf die zentrale Differenz, die sich wiederum aus dem medialen Setting ergibt: es gibt in der F/OSS kein haltens: die »Wortführer«, ihre »Adjutanten«, die »Polizisten«, die auf die Einhaltung der Regeln achten, die »Spezialisten« für einzelne Bereiche, etwa Datenbanken, Verschlüsselung, Netzwerk etc. 143 Einige Beiträge von Linus Torvalds etwa werden nicht nur auf der LinuxkernelMailingliste, sondern in einschlägigen Newsforen veröffentlicht und dort wiederum diskutiert. 144 Vgl. zu dieser Diskussion Poster (1997), Roesler (1997) und Stegbauer (2001: 57 ff.). 145 Je nach Projekt natürlich verschieden, etwa für Datenbanken, Verschlüsselung, Vernetzungstechnik etc.

144

4 Kommunikative und produktive Strukturierungen

derartig engmaschiges Netz von Verpﬂichtungen und Abhängigkeiten und damit auch eine wesentlich weniger ausgeprägte Gruppenloyalität. Vielleicht deswegen ist es auch keineswegs so, daß die jeweiligen Leistungen ständig bewertet und diskutiert würden (Whyte 1996: 22), sondern im Gegenteil, diese Bewertung bleibt verdeckt und muß vom Beobachter jeweils nachvollzogen werden. Wenn eine Kritik vorgenommen wird, ist die auch nie auf die Person bezogen, sondern immer nur auf den Programmcode. Auch hat der Leiter nicht in dem Maße eine Brückenfunktion nach außen, weil eine solche Verbindung nach extern in den relativ selbstbestimmt und programmﬁxiert agierenden Zusammenhängen nicht zentral ist. Gefragt sind eher die Leistungen nach innen: das Treffen und Legitimieren von Entscheidungen, die Moderation der Diskussion und die technische Kompetenz. Nicht zuletzt dieser Vergleich mit sozusagen ›realweltlichen‹ Gruppenstrukturen weist auf ein mögliches Problem dieser vor allem medial basierten Projekte hin: die Unwahrscheinlichkeit von Stabilität und Dauerhaftigkeit, die sich aus der rein medialen Kommunikation ergeben und daraus folgend: die Frage der Notwendigkeit von »realweltlichen« Interaktionen zur Stabilisierung dieser Form der Zusammenarbeit. 4.1.4 Vom »Codeerzeuger« zum »Menschen« Die computerbasierten Medien genügen nach Aussage aller Entwickler für die alltägliche und konkrete Koordination der Kooperation in der Softwareentwicklung. Das gilt vor allem aufgrund des formalisiertschriftlichen (vgl. Abschnitte 2.2 und 3.3.3) und des zumindest auf der maschinellen Ebene »bedeutungslosen« Arbeitsgegenstandes Software. Damit ist es überﬂüssig, über Bedeutungen des Quelltextes zu diskutieren, es genügt frei nach Leibniz ein »Kompilieren wir, mein Herr!« (was Diskussionen über den Stil des Programmierens keineswegs ausschließt). Insofern wären die globalen Zusammenhänge der F/OS-Entwickler ein wunderbares Beispiel für die von der Debatte um die Wissensgesellschaft postulierte Ortsungebundenheit des Wissens. So argumentiert etwa Willke, daß »Ort, Raum und Entfernung [. . .] zunehmend zu vernachlässigbaren Größen für wirtschaftliche Transaktionen [werden]« (Willke 2001: 13). Stehr diagnostiziert gar eine »Bedeutungslo-

4.1 Kommunikationen

145

sigkeit von Zeit und Ort« (Stehr 2001: 316 ff.), die sich mit den neuen Informations- und Kommunikationstechnologien entwickle. Das trifft für die F/OS-Entwicklung insofern zu, als kleinere, modulare Projekte durchaus nur über eine Mailingliste koordiniert werden können und ohne persönliche Treffen auskommen. Damit wird der konkrete Ort der Produktion irrelevant, die Zeit aber keineswegs. Insgesamt war für die technischen Medien der Kommunikation festgehalten worden, daß Mailinglisten und IRC als geeignet und funktional für die Koordination der gemeinsamen Produktion angesehen werden. Die je speziﬁsche Verzeitlichung der Kommunikation führt zu unterschiedlichen persönlichen Präferenzen in der Mediennutzung. Insgesamt jedoch kommt das Medium Mailingliste den zeitlichen Bedürfnissen einer Produktion, die selbstbestimmt, größtenteils unbezahlt und vor allem meist in der Freizeit stattﬁndet, am nächsten. Rauschen in der Kommunikation tritt vor allem bei abstrakteren Fragen auf, und dann häuﬁg als negativ-emotionales Rauschen. Aber selbst dafür werden praktikable Umgangsformen gefunden, so daß eine Beschränkung auf die mediale Kooperation keineswegs als als Beschränkung artikuliert werden müßte. Trotzdem werden die Medien der elektronischen Schriftlichkeit immer wieder als mangelhaft in Bezug auf die Wahrnehmung des Gegenübers beschrieben. Diese Beschreibung der eingeschränkten Wahrnehmung von Personen über das Medium Mailingliste wurde von E2 schon sehr plastisch geliefert (vgl. oben 4.1.2). Aber auch die anderen Entwickler schätzen alle die Bedeutung von face-to-face-Treffen für die kooperative Softwareentwicklung relativ hoch ein. »Also ich hab’s selber nicht gedacht, aber es ist unglaublich produktiv, wenn man sich immer so trifft, mal abends bei ’nem Bier zusammen sich hinsetzt und einfach mal paar Dinge bequatscht. Das war jetzt beim bei dem Treffen in X-Stadt, ja, ich hab gedacht, einfach man trifft sich da und man läßt P4 mal P4 sein, so, mit der Einstellung bin ich halt hingegangen, ja. Aber es war dann irgendwie, man hat doch die ganze Zeit über irgendwas gequatscht und im Nachhinein war’s unglaublich produktiv, also es bringt schon ’ne Menge.« (E4, Z. 221 ff.)

146

4 Kommunikative und produktive Strukturierungen

E4 hatte erst kurz vor dem Interview eine Gelegenheit zu einem ersten persönlichen Treffen mit anderen P4-Entwicklern. Er war bisher mit der Koordination über Mailinglisten sehr zufrieden gewesen. Deutlich zu spüren ist in dieser Schilderung die Überraschung über die produktiven Potentiale, die ein face-to-face-Treffen in sich birgt. Konkret wurde auf diesem Treffen ein neues System der Codeverwaltung diskutiert und dann im Projekt P4 eingeführt. »Also persönlicher Kontakt is’ne wichtige Geschichte, um irgendwie so’n sag ich mal so’n persönliches Verhältnis aufzubauen. [. . .] Aber was ich so immer wieder feststelle, daß es wahnsinnig hilfreich ist, wenn man die Leute einfach mal gesehen hat, wenn man einfach mal mit denen geredet hat, wenn man weiß, einfach so’n Bild vor Augen hat, und man einschätzen kann, wie die drauf sin. Ansonsten isses manchmal, auf den Mailinglisten isses manchmal ’n bischen schwierig Entscheidungen zu treffen, oder überhaupt Diskussionen zu führen.« (E5, Z. 165 ff.) E5 als Leiter eines Projektes hebt hervor, daß E-Mail für das Treffen einer konkreten Entscheidung gut funktioniere, im Falle der Diskussion um Code oder konkrete Verbesserungen sogar »automatisch« (vgl. oben 4.1.2), ohne sein Eingreifen. Das Treffen von schwierigen Entscheidungen bedeutet in diesem Fall das Verkünden und Begründen einer im obigen Sinne »nicht-automatischen« Entscheidung nach einer per Mailingliste geführten Diskussion und die Legitimation einer solchen Entscheidung. Diese Legitimation ist einfacher, wenn die auf der Mailingliste nur eingeschränkt erkennbaren Relevanzstrukturen der beteiligten Entwickler deutlicher werden, wenn also klar ist, »wie die drauf sin«. Deshalb sind für ihn persönliche Interaktionen mit den anderen sehr hilfreich, die ein »Bild« und eine Einschätzung der Einstellungen, des Habitus usw. des Gegenübers ermöglichen. Diese Interaktionen ermöglichen ihm die Konstruktion des Anderen als einer Person, eine typisierende Erfassung des Anderen, die zwar ebenso aber wesentlich eingeschränkter in rein medialen Kontexten erfolgt.146 146 Meines Erachtens liegt hier einer der Gründe für die multimediale Auftritte von Individuen: in Mailinglisten, Foren, in Weblogs, auf Homepages, mit Texten, Bildern,

4.1 Kommunikationen

147

Bereits die Tatsache der Zusammenarbeit verursacht Typisierungen147 , aber dann eben nur beschränkt auf den Aspekt der Arbeit. Ohne diese persönlichen Kontakte bzw. personalen Typisierungen werden die Diskussionen, das Treffen und Legitimieren von Entscheidungen erschwert. Für ihn funktionieren Mailinglisten als Kooperationsmedium besser, wenn die E-Mailkontakte durch realweltliche Interaktionen gestützt und stabilisiert sind. »Diese Konferenzen und auch diese Treffen helfen sehr viel dabei, daß man die (betont: Leute) an sich kennenlernt. [. . .] Wenn man mit demjenigen mal ’nen Abend lang inner Bar versumpft is oder in irgen’ner Kneipe, man hat über alles möglich diskutiert, bekommt man zu den Leuten auch ’n ganz andern Zugang, man lernt die Leute als Menschen kennen und nicht nur als Codeerzeuger.« (E2, Z. 804 ff.) E3 meint ebenfalls, daß für »die technischen Sachen« (E3, Z. 196) die Mailinglisten ausreichend sind. In Bereichen, »wo Vision gefragt ist, wo Plan gefragt ist« hält E3 diese Kommunikationsform für weniger geeignet: »Aber so der Workshop und auch der Kongress hat zumindestens die Leute ham sich dadurch mal kennengelernt und besonders der Kongress hat auch noch mal gezeigt wie die Interessen liegen und was es da für die neue Version, falls sie denn mal kommen sollte dann zu beachten gibt. Also der Kongress hat schon einiges gebracht, denk’ich.« (E3, Z. 175 ff.) Ein Treffen der wichtigen Entwickler macht gerade die unterschiedlichen Interessen und persönlichen Relevanzen in Bezug auf die weitere Entwicklung eines Projektes deutlich. Die werden anscheinend über evtl. Filmen etc. In diesem Sammelsurium kristallisiert sich allmählich die Einheit einer Person heraus, vgl. auch Sebald 2007. 147 Vgl. dazu die Personalitätsmanuskripte von Alfred Schütz 2003: 69, sowie (Schütz 2004b: §§ 36 ff.).

148

4 Kommunikative und produktive Strukturierungen

die reine Mailinglistenkommunikation nicht in dieser notwendigen Deutlichkeit klar. Anzumerken ist zu diesen Aussagen, daß die zitierten Entwickler in einem oder jeweils unter dem Dach eines relativ großen F/OS-Projektes arbeiten, und entsprechend Erfahrungen mit solchen Treffen haben, weil diese Treffen von den an der Software interessierten Firmen gefördert und gesponsort werden. Dahinter steht sicher auch das Interesse an der konkreten Verbesserung des Produkts, das verwertet werden soll (vgl. Abschnitt 5.2). Die Kommunikation über Mailinglisten und IRC reicht für die alltägliche Koordination der Entwicklungsarbeit, für komplexere Diskussionen werden von allen interviewten Entwicklern jedoch Konferenzen oder andere Formen des persönlichen Austauschs bevorzugt, nicht zuletzt um die zwischenmenschlich deﬁzitären elektronisch-schriftlichen Medien zu ergänzen. Damit werden die oben zitierten Thesen der Debatte um die Wissensgesellschaft relativiert: Für den konkreten, also den quelltextbezogenen Teil der Kooperation und Koordination sind die verwendeten Medien tauglich, nicht jedoch für konzeptionelle Fragen im weiteren Sinne und für den nach wie vor wichtigen zwischenmenschlichen Bereich, der wohl nicht zuletzt aufgrund der alltäglichen Arbeitssituation, alleine vor der Maschine sitzen und programmieren, als mangelhaft empfunden wird. In der Forcierung der persönlichen Kontakte kann auch ein Versuch gesehen werden, diesen medialen Mangel zu beheben, und die Produktion zumindest partiell wieder an konkreten Orten und Zeiten der Treffen und damit an konkreten Personen zu verankern. Nicht zuletzt sind die unvermeidbaren Konﬂikte148 auf der Ebene der Interaktion leichter zu lösen. Die neuen computerbasierten Medien sind unter speziﬁschen Bedingungen (kleine Gruppe, hohe Spezialisierung, gemeinsamer impliziter Wissensvorrat) für einen Teil der für die Wissensproduktion nötigen Kommunikation funktional, aber sie können die grundsätzliche Fundierung in realweltliche Zusammenhänge nicht komplett ersetzen. Entsprechend ﬁnden sich in nahezu allen ›älteren‹ und größeren Projekten inzwischen institutiona148 Zu den Konﬂikten in der kommerziellen Softwareentwicklung vgl. Weltz und Ortmann 1992: 125 ff.. In dieser Untersuchung verlief kein einziges der untersuchten 46 Softwareprojekte konﬂiktfrei, in 65 % der Fälle gab es häuﬁg Konﬂikte, meist zwischen den Entwicklern selbst.

4.2 Strukturierungen durch Produktion

149

lisierte Formen von persönlichen Treffen, in Form von Konferenzen, Workshops oder gruppiert um einen Stand bei Messen. Das erlaubt die kürzere und effektivere Diskussion von konzeptionellen Fragen und schafft ein Netz von persönlichen Beziehungen, erhöht also die Stabilität einer auf computerbasierten Kommunikation gestützten Kooperation.

4.2 Strukturierungen durch Produktion Die oben (4.1.3) von E3 und E5 aufgemachte Differenzierung zwischen Leuten, die Code schreiben und Leuten, die nur diskutieren, deutet darauf hin, daß die Strukturierungen der Kommunikation nicht mit den Strukturierungen der Produktion identisch sind oder sein müssen. Die vom Arbeitsgegenstand ›Software‹ gesetzten speziﬁschen Rahmenbedingungen schaffen Besonderheiten, die sich zwar in der Kommunikation widerspiegeln (und letztlich vor allem dort zu beobachten sind), die aber eben gerade nicht in der Kommunikation ihren Ausgang nehmen. Damit bildet sich eine zweite Ebene der Strukturierung, die sich in einer je projektspeziﬁschen Weise mit der kommunikativen Strukturierung mischt. Diese Mikrostrukturen in der Produktion gilt es in diesem Abschnitt in den Blick zu nehmen. Dazu werden in einem ersten Schritt die technischen Bedingungen der Produktion untersucht, in einem zweiten Schritt wird der Umgang mit den durch die Software gesetzten Wissensschwellen idealtypisch beschrieben, in einem dritten Schritt schließlich der alltägliche Arbeitsablauf in den Projekten ebenfalls idealtypisch rekonstruiert. 4.2.1 Technische Bedingungen der Produktion Produktionsmittel Die materiellen Grundlagen für die F/OS-Produktion sind ein Computer mit einer gewissen, dem ›Stand der Technik‹ ungefähr angemessenen Hardwareausstattung149 , Energieversorgung und ein Zugang zum Inter149 Die genauen Erfordernisse sind abhängig von vom jeweiligen Programm, das bearbeitet werden soll. Ein Videobearbeitungsprogramm braucht eine bessere Hardwareausstattung als etwa der Linuxkernel, der nach wie vor auf einem Intel 386

150

4 Kommunikative und produktive Strukturierungen

net. Diese Produktionsmittel sind, verglichen mit Produktionsmitteln für materielle(re) Waren vergleichsweise billig. Für die Softwareproduktion genügen die zumindest in den industrialisierten Zonen der Welt weitgehend zur Alltagstechnik gewordenen Computer. Die materiellen Produktionsmittel sind damit relativ leicht und kostengünstig zu beschaffen. Und wenn sie vorhanden sind, ist der Wissenspool der F/OSS leicht anzuzapfen und alle benötigten Softwarewerkzeuge stehen zur Verfügung. Neben den oben analysierten Kommunikationsinstrumenten (vgl. Abschnitte 2.3 und 4.1.2) sind für die F/OSS softwareseitig noch weitere Produktionsmittel notwendig. Das grundlegende Werkzeug ist die verwendete Programmiersprache. Die ist jedoch durch das jeweilige Projekt vorgegeben, wobei für den einzelnen Programmierenden ein Wechsel der verwendeten Programmiersprache aufgrund des formalisierten Charakters aller Programmiersprachen kein Problem ist: »Wenn man zwei drei Sprachen kennt und mit denen sehr=sehr gut arbeiten kann, dann fällt’s eigentlich relativ einfach noch’ne weitere Sprache zu lernen, weil die Logik is halt immer die gleiche, die Befehle heißen nur anders und die äh Besonderheiten einer Sprache muß man dann eben wissen, und dann kommt man halt gut klar.«150 Aufgrund des, bei vorhandener Computeralphabetisierung, relativ einfachen Wechsels zu anderen Programmiersprachen spielen die technischen Unterschiede keine so große Rolle. Um so wichtiger werden habituelle, stilistische oder sonstige Differenzierungskriterien: »Das is eigentlich auch der Punkt [die zur Sprache vorhandene Dokumentation], daß ich irgendwann aufgehört habe, in diesen ganzen, ich sag immer Spielzeugsprachen, zu entwickeln und dann wirklich zu Java gegangen bin, weil man einfach die Möglichkeit hat, ja, es von den Leuten, die’s entworfen ham, nachzugucken, nachzufragen Prozessor läuft. 150 Dieses Zitat stammt von einem Programmierer, der im Zuge des am Institut für Soziologie der FAU Erlangen-Nürnberg durchgeführten DFG-Projektes »Bedingungen der Wissensproduktion in der Wissensgesellschaft« interviewt wurde (PK, Z. 1285 ff.).

4.2 Strukturierungen durch Produktion

151

und weil es eine Firma gibt, die diese Leute unterstützt.« (E2, Z. 314 ff.) E2 bevorzugt die kommerzielle Programmiersprache »Java«, weil diese ihm eine ausreichende Dokumentation und Unterstützung von den Entwicklern der Programmiersprache und der sie verbreitenden Firma garantiert. Damit ist ihmzufolge eine höhere Professionalität verbunden. Dahinter steht auch ein pragmatischer Zugang zum Werkzeug: nicht die Lizenz unter der es verteilt wird, sondern die für die eigene Arbeit als wichtig wahrgenommenen Qualitäten sind für E2 entscheidend. »Also ich hab schon mal zu DOS-Zeiten mir C angeschaut, hab aber nie mich ernsthaft damit beschäftigt, hab dann ja so C auch mir selber beigebracht und hab mich eben ja da so durchgearbeitet. Auch so Abstecher, was weiß ich, also grad so bischen äh C++ auch natürlich und Java gefällt mir überhaupt net, aber man muß es sich ja mal anschauen, um begründen können warum’s einem nicht gfällt.« (E1, Z. 119 ff.) E1 bringt keine Kriterien, warum ihm die eine Sprache gefällt und die andere nicht, aber es wird wiederum deutlich, daß die Kriterien für die Wahl entweder außerhalb der Programmiersprache liegen (Dokumentation, Unterstützung durch ein Unternehmen, Lizenz)151 oder aber auf bestimmten Funktionalitäten, Gewohnheiten oder Stil beruhen. Anzumerken ist, daß die Wahl einer Programmiersprache nur beim Start eines Projektes bzw., für Neueinsteiger, bei der Auswahl eines Projektes eine Rolle spielt. Für die konkrete Erstellung von Programmcode sind außer der Programmiersprache weitere Programme notwendig. Angefangen von einem Editor, der möglichst programmiersprachenspeziﬁsche Formatierungen und erste Überprüfungen vornimmt, über den nötigen Compiler zur Erzeugung von Maschinencode und mehr oder weniger projektspeziﬁsche sogenannte Buildtools, die die Kompilierung und Installation vorbereiten und durchführen. Von diesen Werkzeugen gibt 151 Vgl. dazu Torvalds und Diamond (2001: 218 f.), der Java zwar für ein »good product« hält, aber diese Sprache wegen der Lizenzbedingungen ablehnt.

152

4 Kommunikative und produktive Strukturierungen

es eine Vielzahl und entsprechend viele Kombinationsmöglichkeiten. Letztendlich genügt für die Programmierung ein einfacher Texteditor und ein Compiler. Es existieren jedoch eine Vielzahl weitaus komfortablerer sogenannter IDEs (›Integrated Development Environments‹). Die Auswahl dieser Werkzeuge bleibt zum größten Teil dem Belieben des einzelnen Programmierers überlassen. Wenn die relativ kostengünstige Hardware, Energie- und Netzwerkanschluß vorhanden sind, müssen die für die Programmierung nötigen ›Werkzeuge‹ installiert werden, die in großer Auswahl im Wissenspool der F/OSS vorhanden sind. Diese Werkzeuge strukturieren zwar die individuelle Tätigkeit, aber meines Erachtens nicht so, daß die Mikrostrukturen in den Projekten etwa bei einem Wechsel von Werkzeugen verändert werden würden.152 Dagegen greifen die technischen Mittel der Distribution sehr wohl in die Mikrostrukturen der Produktion ein. Distributionsmittel Zentral für die Distribution wie auch für die Produktion ist die Servertechnologie, die zum einen den Entwicklern und zum anderen Anwendern den Zugriff auf die jeweils aktuellen Versionen, meist aufgeteilt in eine stabile und eine Entwicklungsversion, ermöglicht.153 Für die weitere Distribution werden meist sogenannte ftp-Server (ﬁle transfer protocol) verwendet, für die Produktion meist Versionskontrollsysteme, also Serverprogramme, die es erlauben, Änderungen rückgängig zu machen. Beispiele dafür sind cvs-Server (current version system) oder das Programm »subversion«. Die Besonderheit von allen drei Programmen ist, daß die Schreib- und Leserechte differenziert sind. 152 Dagegen scheint folgende Aussage zu sprechen: »Und bei Java ist es üblich, daß die Methoden mit java-docs versehen werden, und da wird dann schon mal gemurrt, wenn jemand was eincheckt, was also da jetzt sagen wir mal, anders formatiert ist als der Originalcode oder eben ohne java-docs ist.« (E2, Z. 124 ff.) Aber hier wird letztlich der Formatierungs- und Dokumentationsstil im Projekt angesprochen, der vielleicht durch »Java« erleichtert wird, der aber, das zeigen gerade die Verstöße, keineswegs zwingend in der Verwendung der Sprache ist. 153 Die Kennzeichnung als stabile Versionen erfolgt, wenn die Software eine gewisse Anzahl von Testläufen hinter sich hat und als relativ fehlerfrei gilt. In den Entwicklungsversionen werden dagegen neue, ungetestete Funktionen eingefügt, die gelegentlich oder häuﬁger zu Fehlfunktionen, Programmabstürzen oder gar Datenverlust führen kann.

4.2 Strukturierungen durch Produktion

153

Während bei den in der Regel öffentlich zugänglichen Servern normalerweise alle Benutzenden anonymes Leserecht haben, also auch Programmcode herunterladen können, sind die Schreibrechte wesentlich differenzierter verteilt. Das ist eine Form von Änderungsrecht für einen oder mehrerer Programmierer an der gemeinsam entwickelten Software, die oben (3.2.1) in Anlehnung an Raymond (2001c) und Weber (2004) als Eigentum bezeichnet wird: »The owner of a software project is the person, who has the exclusive right, recognized by the community at large, to distribute modiﬁed versions.« (Raymond 2001c: 73)154 Auf dieser technischen Grundlage fußt die Eigentumsform der F/OS-Zusammenhänge: Die Vergabe dieses Schreibrechts, das auf dem Server explizit für Einzelne oder Gruppen angegeben werden muß, bestimmt das Recht zur Distribution der Software. Änderungen in die ofﬁzielle und autorisierte, auf dem Server liegende Version darf nur einfügen, wer dafür explizit eingetragen ist. Insofern haben die Personen, die dieses Schreibrecht haben, die Kontrolle über die Version, die distribuiert wird. Sie kontrollieren damit nicht den weiteren Verlauf der Distribution, das ist durch die Lizenzen, die allen eine unbeschränkte Nutzung gestatten, ausgeschlossen. Aber sie kontrollieren, was in den Distributionsprozess eingespeist wird. Die grundlegende Grenzlinie zwischen allen an der Entwicklung Beteiligten ist damit die durch die Vergabe des Schreibrechts an den Codeservern gezogene. Diese Rechtevergabe strukturiert die Programmiererzusammenhänge grundlegend. Aber die Formen dieser Strukturierung sind mannigfaltig. Bevor jedoch zur Beschreibung und Analyse einiger dieser Strukturierungen geschritten wird, werden die erst Eintrittsschwellen in ein F/OS-Projekt sowie ein (ideal-)typischer Arbeitsablauf in der F/OSS analysiert. 4.2.2 Eintrittsschwellen F/OSS zeichnet sich vor allem durch die Freiwilligkeit der Beteiligung aus. Für den Eintritt in ein Projekt lassen sich die Werbephase und die 154 Raymond begründet Eigentum generell zum einen mit der Lockeschen Eigentumstheorie (vgl. Locke 1967) und zum anderen mit einer biologistischen Argumentation, die von einem genetisch verankerten Eigentumstrieb ausgeht (Raymond 2001c: 97 f.).

154

4 Kommunikative und produktive Strukturierungen

Eintrittsphase unterscheiden. Die Anwerbephase geht vom Projekt aus, ﬁndet allerdings in expliziter Form meist nur am Beginn eines Projektes statt155 In solchen Ankündigungen wird das neue Projekt vorgestellt, seine Vorzüge gegenüber bestehenden Lösungen hervorgehoben und erste Konzeptvorschläge werden unterbreitet. Gleichzeitig wird auf einen ersten, meist nur rudimentären Programmcode verwiesen (und damit auch auf bestimmte Server, die als Codedepot dienen), der zumindest kompilierbar sein muß, um die eigenen Ideen zu demonstrieren. Wichtig ist auch der Verweis auf Kommunikationsmöglichkeiten (die E-Mail-Adresse des Initiators oder eine bereits bestehende Mailingliste). Das sind Versuche der direkten Anwerbung von Freiwilligen für ein Projekt. Sie erfolgen in Newsgroups, thematisch relevanten Mailinglisten oder verbreiteten Computerzeitschriften und müssen, um ihre Funktion zu erfüllen, einen möglichst großen Kreis der potentiell interessierten Teilöffentlichkeit erreichen, um möglichst viele Programmierende für das neue Projekt zu begeistern. Wenn ein Projekt etwas gewachsen ist und sich stabilisiert hat (stabile(re) Kerngruppe, benutzbares Programm mit den wesentlichen Funktionen) erfolgt die Anwerbung eher implizit und indirekt, vor allem über die Gewinnung von Nutzern für das Programm selbst. Aus dem Kreis der Nutzer werden dann die wegen der doch meist hohen Fluktuation nötigen neuen Freiwilligen für die Programmierung gewonnen. Das bedeutet auch, daß ein Projekt um so mehr Chancen auf neue Freiwillige hat, je verbreiteter es ist und je mehr Weiterentwicklungsmöglichkeiten es bietet. Für die Außenstehenden stellt sich die Eintrittsphase so dar: Sie müssen in allen Fällen den ersten Schritt tun und mit den bereits am Projekt Beteiligten in Kontakt treten und Interesse an Mitarbeit signalisieren. Dieser erste Kontakt ﬁndet meist über E-Mail bzw. über die Mailinglisten statt. Please let me know what I can do to help with the KDE development process. I am a C/C++ programmer and I know QT programming. I am willing to help. If you need parts of KDE developed or even a new type of application to start, just give me the ideas and I will do 155 Vgl. etwa Abschnitte 3.2, 3.3 oder http://groups.google.com/group/de.comp.os.linux.misc/ msg/cb4b2d67ffc3ffce.

4.2 Strukturierungen durch Produktion

155

it!156

Diese kurze Vorstellung beinhaltet eine Beschreibung der eigenen Kenntnisse und die Bitte um die Zuweisung einer Aufgabe. Eine solche offene Bewerbung ist jedoch selten, meist ist das eher ein längerer, impliziter Prozeß, der von der Benutzung des Programmes, Melden von bugreports bis zum Einsenden von Codestücken reicht. Im KDEProjekt werden zur Eingliederung in das Projekt und für die ›Prüfung‹ der Neulinge, neben dem häuﬁger gewählten Weg des direkten Einstiegs in ein Projekt, sog. »Junior Jobs« bereitgestellt. Das sind relativ einfache Aufgaben, an denen Neulinge ihre Programmierfertigkeiten unter Beweis stellen können: Answer: wherever you like, really. As others have already suggested, it can be useful to pick an application that you use and need and try to improve it. Personally, I never use an application unless I’m willing to write patches for it. Most recently that meant ﬁxing KDevelop’s conﬁgure. If something bugs you in an application, you can try to ﬁx it. [...] Related to the quality team is the collection of "Junior Jobs", which are wishlist reports in bugzilla (take a look at bugs.kde.org) that are considered "junior", in the sense of "good to introduce a newcomer to the code of a particular application, not critical features, fairly small to implement". Each JJ has something of a pledge attached to it by the app maintainer that they will help out in the implementation of the JJ, coaching, etc., but they won’t do it themselves (usually due to all their time being chewed up by more important bugs). So you could look for JJs for your favorite app, or not-so-favorite.157

Die Kontaktaufnahme wird, wenn eine Aufnahme in das Projekt erfolgen soll, mit der (möglichst baldigen) Lieferung von Programmcode verknüpft, was den etablierten Entwicklern einen ersten Eindruck von den Programmierfähigkeiten des Neulings vermittelt. Erst wenn der Neuling einige Patches geliefert hat (oder seinen »Junior Job« erledigt hat), erhält er normalerweise Schreibrecht am zentralen Sourcecodearchiv: 156 157

http://lists.kde.org/?l=kde-devel&m=108363068427245&w=2 http://lists.kde.org/?l=kde-devel&m=108366944918526&w=2

156

4 Kommunikative und produktive Strukturierungen »Und so hat man eben angefangen einene Patch zu schicken und noch’n Patch zu schicken und nach dem zehnten Patch hat dann einer gemeint, hey, der wär doch als Committer nich schlecht, und so bin ich dann zu dem Projekt gekommen.« (E2, Z. 73 ff.)

Der Neue muß durch regelmäßige und längerfristige Beteiligung Interesse an einer länger dauernden Mitarbeit signalisieren und er muß vor allem seine Programmierfähigkeit unter Beweis stellen. Das bedeutet, daß eine rudimentäre Computeralphabetisierung, also die grundlegende Kenntnis der verwendeten Programmiersprache(n) vorhanden und der Umgang mit den verwendeten Werkzeugen (Compiler, Buildtools etc.) einigermaßen sicher ist. Prinzipiell können diese Kenntnisse mit einem gewissen Zeitaufwand auch erworben werden, aber innerhalb eines Projektes wird dafür relativ wenig Unterstützung geboten. Vor oder spätestens mit Beginn einer Beteiligung an einem F/OS-Projekt muß also diese grundsätzliche Wissensschwelle überwunden sein oder werden. Es muß daneben natürlich die Bereitschaft vorhanden sein, einen Teil seiner Freizeit für das Projekt zu opfern. Interessanterweise werden diese Einstiegshürden kaum reﬂektiert. Die generelle Aussage ist: »Bei uns kann jeder mitmachen. Wir können jede Hilfe gebrauchen.« Versprochen wird zudem eine schnelle Integration in das Projekt: »Jemand, der aktiv is, der Code schreibt oder sonst sich irgendwie beteiligt, der kriegt halt relativ schnell auch Zugang dann zum cvs oder KDE-Mailingadressen oder so was. Es läuft auch alles sehr sehr informell ab, also es gibt dann halt ’n paar Leute, die die Accounts vergeben und in der Regel läuft’s dann so ab, [. . .] meist läuft’s dann so über’n’Empfehlung von jemand, der schon im Projekt drin ist, der dann sagt, der und der braucht’n Account, um das und das zu machen und dann kriegt der den auch. Also um wirklich ein Teil des Projekts zu werden, das is sehr einfach. Da muß man einfach nur irgendwas machen, was Sinn macht, was gut is, was funktioniert.« (E5, Z. 284 ff.) Wichtig ist der Hinweis auf die schnelle und informelle, unbüro-

4.2 Strukturierungen durch Produktion

157

kratische Vorgehensweise, das zum einen den Neuen relativ einfache Integration verspricht und zum anderen auf Seite der schon Etablierten den Arbeitsaufwand reduziert. »Da muß man einfach nur irgendwas machen, was Sinn macht, was gut is, was funktioniert.« Die (informelle) Beurteilung dieser Leistung obliegt den etablierten Entwicklern oder dem Projektleiter. Dafür sind auch keine expliziten Regeln formuliert. Sie erfolgt vor dem Hintergrund des jeweils vorhandenen Wissensvorrats in Bezug auf Programmierung, Programmierstil etc. Daß eine solche Hürde für Nicht-Programmierer nicht besonders einfach zu nehmen ist, und diese auch wenig Unterstützung zu erwarten haben, wird auf Nachfrage des Interviewers deutlich: »Ich denk, es is sehr viel Learning by doing. Es ist auch sehr viel Eigeninitiative da nötig. Ich denk, es gibt so’ne gewisse Hürde. Man muß da erstmal reinkommen. Also das P5-Projekt is sehr offen gegenüber neuen Leuten, also Leute, die gute Sachen machen, kriegen auch sofort Zugriff und Verantwortung. Auf der andern Seite gibt’s auch wenn jemand ’n Patch schickt, der nich gut is, dann kriegt er das auch gesagt. Also es is auch so’ne gewisse, schon’ne gewisse Auslese, die da stattﬁndet. Aber es basiert eigentlich wirklich alles darauf, daß Leute, die neu reinkommen, von sich aus irgendwie was tun, und da irgendwie auch dranbleiben und sich da selber drum kümmern. Ja, ich denke, es gibt auch nicht so wahnsinnig viel Dokumentation über so was, also man muß sich durch manche Sachen einfach durchbeißen und schauen schon, wie man da selber zurecht kommt. Auf der andern Seite ist die Hilfsbereitschaft schon sehr groß, also wenn jemand irgendwie zeigt, daß er irgendwie da auch konstruktiv mitarbeiten will, dann kriegt er auch jede Hilfe, die er haben will. So, und auch blöde Fragen werden (lachend: normalerweise freundlich beantwortet)((lacht)).« Von den Neulingen wird durchweg eine hohe Portion Eigeninitiative, ein entsprechendes »Durchbeißen« erwartet. Die Unterstützung in Form persönlicher (bzw. medialer) Hilfestellung und vorhandener

158

4 Kommunikative und produktive Strukturierungen

schriftlicher Dokumentation ist nur rudimentär, was in einer Freiwilligenorganisation auch nicht verwundert. Schließlich kostet solche Unterstützung den Etablierten Zeit; Zeit, die sie auf dringendere Probleme oder für Tätigkeiten verwenden, die ihnen mehr zusagen. Signalisiert jemand Willen zur »konstruktiven Mitarbeit«, erhält er »jede Hilfe, die er haben will«. Konstruktive Mitarbeit bedeutet zum einen das Akzeptieren eventueller Kritik und entsprechende Eigeninitiative, sich mit Hilfe der meist spärlich vorhandenen Anleitungen einzuarbeiten. Sogar »blöde Fragen« werden dann beantwortet. Die Hilfe ist aber häuﬁg Hilfe zur Selbsthilfe à la »RTFM« (Read the ﬁne manual). Der Aufwand für den Neuling sinkt natürlich umgekehrt proprotional zur vorhandenen Programmiererfahrung. Ähnliche Strukturen ﬁnden sich im P3-Projekt: »Also es gibt eigentlich keine Ausbildung irgendwie, sondern also man sagt, ja schick halt ein’ Patch und gut also die Patches müssen halt in einem bestimmten Format sein, in so einem uniﬁed diff und gut, da gibt’s vielleicht noch’n paar Kommentare wie ›mach die Einrückung irgendwie so wie’s im ﬁle selber is‹ und vielleicht da und da mit, aber also es gibt keine irgendwie formale Ausbildung. Es gibt auch keine Prüfung oder irgend sowas, nein.« (E3, Z. 315 ff.) Mit dem Eintritt in die F/OSS ist also eine ziemlich hohe Wissensschwelle zu überwinden, die sich für die bereits etablierten Entwickler nicht als solche darstellt. Ein Auslesemodus, der zwar selten expliziert wird und von daher keine scharfe Grenze produziert, der aber nichtsdestoweniger greift. Die Beteiligungsmöglichkeiten für Computeranalphabeten sind meist darauf beschränkt, Dokumentation zu schreiben und Übersetzungen anzufertigen, die von den Programmierenthusiasten meist ungeliebten Tätigkeiten. Dieser Aufnahmemodus stellt eine gewisse Homogenität der Wissensvorräte her. Er sichert gerade auf Grund der langsamen und zeitlich verzögerten Aufnahme das Kennenlernen und die Übernahme der im Projekt herrschenden Normen und Regeln, etwa in Bezug auf den Stil, aber auch grundlegender in Bezug auf die technische Rationalität. Gleichzeitig garantiert dieses Verfahren den schon im Projekt

4.2 Strukturierungen durch Produktion

159

Involvierten ein Minimum an Aufwand und ein in den alltäglichen Arbeitsablauf leicht zu integrierendes Verfahren. Zusätzlich stellt der eine gleichbleibende Qualität in der Produktion sicher. Diese Homogenität der Wissensvorräte, der Regeln, Stile und Rationalitäten, sowie der Qualität ist ein wichtiger stabilisierender Faktor für die Projekte. Erst eine kontinuierliche, konstruktive und für die Beteiligten akzeptable Mitarbeit sichert die Aufnahme ins Projekt. Damit wird, auch wenn keine persönlichen Bekanntschaften bestehen, die für das Weiterbestehen des Projektes entscheidende kooperative und produktive Kontinuität gesichert und die Produktion selbst, zumindest solange es kooperationswillige Interessenten gibt, auf Dauer gestellt. Dieser alltägliche Verlauf der Produktion soll nun typisierend skizziert werden. 4.2.3 Produktionsprozesse Die im Folgenden entwickelte typisierende Skizze des Produktionsprozesses dient vor allem dazu, gängige Strukturierungen nachzuzeichnen. Leitend sind dabei die Fragen, inwieweit sich die Kern-PeripherieDifferenz der Kommunikationsstrukturen wiederﬁndet, wie die Arbeitsteilung zustande kommt, wie diese koordiniert wird und welche Regelungsstrukturen sich dabei herausbilden. Kern – Peripherie Die Programmierarbeit für ein F/OSS-Projekt verläuft typischerweise in folgenden Schritten: Aktualisieren und Kompilieren des Codes, Identiﬁzierung eines Problems oder einer benötigten neuen Funktion, Zuweisung oder Übernahme der Problemlösung, Finden einer oder mehrerer Lösungen für das Problem, Code lokal schreiben und testen, produzierten Code den anderen Entwicklern präsentieren und/oder zum vorhandenen Projektcode hinzufügen. Der erste Schritt ist das Aktualisieren des vorhandenen Codes auf dem eigenen Computer, um zu vermeiden, daß der zu schreibende Code allzusehr mit weiteren jüngst integrierten Änderungen konﬂigiert bzw. um überhaupt mit den neu(est)en Funktionen arbeiten zu können. Das läßt sich mit dem cvs-Programm automatisiert erledigen, so daß immer die aktuelle Entwicklungsversion auf dem eigenen Com-

160

4 Kommunikative und produktive Strukturierungen

puter vorhanden ist. Dieser Code wird kompiliert, um zu prüfen, ob die letzten Änderungen auch auf der eigenen Hard- und Softwarekombination laufen. Das Kompilieren und Ausführen ist gleichzeitig der erste Weg, um vorhandene Probleme zu identiﬁzieren. Andere Möglichkeiten sind Fehlermeldungen (bugreports), die von anderen Entwicklern oder auch Anwendern gesendet wurden und zumindest in größeren Projekten meist in Datenbanken oder datenbankähnlichen Fehlererfassungssystemen gesammelt werden. Diese Einbindung der Benutzer in die Entwicklung durch diese Möglichkeit wird als wichtiges Element in der F/OSS gesehen. Nicht zuletzt wird genau dieser Modus als Garant für die Qualität der Software angeführt: »Given enough eyeballs all bugs are shallow!« (Raymond 2001b: 30) Durch die Nutzung eines Programmes in unterschiedlichen Konﬁgurationen von Hardware und Software ist es möglich, die aufgrund der Komplexität unvermeidlichen Fehler eher aufzuspüren. Je größer die Nutzerbasis, desto wahrscheinlicher ist es dieser Logik zufolge, daß vorhandene Fehler gefunden werden. Das heißt, daß diese Form der Wissensproduktion ohne die pragmatische Einbindung der entwickelten Software in möglichst zahlreiche Anwendungskontexte nicht in der Qualität möglich ist. Qualitätssicherung in der F/OSS setzt nicht in erster Linie auf die Ausweitung maschineller Tests und Prüfprogramme, sondern auf die Ausweitung der Einbindung in verschiedenste individuelle Handlungskontexte.158 Gerade dieser Umstand wird zu einer wichtigen Motivation, um die Einheit eines Projektes zu erhalten und eine Spaltung (forking) zu vermeiden. Neben der Verkleinerung der Nutzerbasis und einem damit verbundenen potentiellen Qualitätsverlust würde eine Spaltung auch die bisher erbrachten Leistungen für das Projekt und die damit erworbene Reputation der beteiligten Programmierenden gefährden. Und nicht zuletzt reduziert sich mit einer Spaltung der Pool, aus dem neue Entwickler für das Projekt gewonnen werden können. Eine möglichst große Nutzergruppe ist damit wichtig für ein F/OS-Projekt. Im Produktionsprozeß liefert diese Integration von aktiven Anwen158 Das heißt nicht, daß eine die Mitwirkung von Individuen minimierende Produktion von Software nicht möglich wäre. Die Einbindung in unterschiedlichste pragmatische Anwendungskontexte liefert aber in höherem Maße eine Ausrichtung der Softwareentwicklung auf diese Handlungskontexte.

4.2 Strukturierungen durch Produktion

161

denden einen ersten Hinweis auf die Kern-Peripherie-Struktur, die schon in der Analyse der Kommunikationen zu sehen war. Die Beteiligten verteilen sich dabei in einem Kontinuum, dessen äußerer Pol vom Typus des reinen Anwenders gebildet wird, der die F/OS-Software nur benutzt und sich überhaupt nicht an der Entwicklung beteiligt.159 Je nach Art der beteiligenden Tätigkeit, Senden von bugreports, Beheben kleinerer Fehler, Programmieren von neuen Funktionen) lassen sich verschiedene Zwischentypen bilden. Am anderen, inneren Pol ﬁnden sich die Kernentwickler: die Programmierer, die den größten Teile des Quelltextes schreiben und geschrieben haben, die Schreibrecht an den Codedepots haben und die die weitere Entwicklung bestimmen. Auch hier ﬁndet die Differenzierung und Positionierung nicht entsprechend der rein quantitativen Leistung statt, sondern durchaus auch nach qualitativen Aspekten, wie etwa die Bedeutung des jeweiligen Codebruchstückes für das Projekt als Ganzes oder die Qualität des gelieferten Beitrags. Die Kern-Peripherie-Struktur in der Produktion muß keineswegs deckungsgleich sein mit der in der Kommunikation aufscheinenden, weil die Kommunikationsfrequenz stark von der Produktionsfrequenz differieren kann und das oft auch tut. Um die aktuelle Position einer Person und in diesen Strukturen und die aktuelle Struktur im Projekt zu bestimmen, müssen demnach sowohl die produktive als auch die kommunikative Position berücksichtigt werden. Wie die ungefähre Relation von Entwicklern und Anwendern (und ›Arbeitsteilung‹) sich gestaltet, wird in quantitativen Studien deutlich: Übereinstimmend ist hier das Ergebnis zu ﬁnden, daß etwa 80 % des Codes im jeweiligen Projekt von einer relativ stabilen Kerngruppe mit maximal 10 - 15 Personen geschrieben werden und nur der Rest von den peripher Beteiligten beigesteuert wird (vgl. Mockus et al. 2002; German 2003). Dagegen ist der Anteil der Kernentwickler an der Problemﬁndung wesentlich geringer. Hier liegt der Hauptanteil in der Peripherie. Eine so sich konstituierende Struktur ist jedoch keineswegs statisch, 159 Dies entspricht der Position des Lurkers in der Kommunikation. Aus ökonomischer Sicht ist das der ›Trittbrettfahrer‹ oder ›free rider‹, der sich ohne eigenen Einsatz die Programme aneignet. Aufgrund der distributiven Besonderheit von Wissen (vgl. Abschnitte 2.1 und 6.1) stellt das aber kein Problem für die Entwicklung dar.

162

4 Kommunikative und produktive Strukturierungen

sondern ist durchaus im Fließen und zwar vor allem durch die starke Fluktuation der Beteiligten. »Also es läßt sich schwer sagen, weil’s keine geschlossene Gruppe is, weil’s stark im Fluß ist. Also wenn Leute kommen, die machen irgendwie einmal was, schicken einmal ’n Patch, der toll ist, tolle neue Features einbaut und es gibt Leute, die halt regelmäßiger mal irgendwie was machen, aber es ändert sich schon sehr stark.« (E5, Z. 39 ff.) Das ist angesichts eines zweckbestimmten, temporären und freiwilligen Zusammenschlusses von selbstbestimmten Programmierenden auch nicht besonders verwunderlich. Eine Erklärung dafür liefert auch die Zwanglosigkeit der medialen Verbindungen. Die Fluktuation nimmt jedoch mit der Nähe zum Kern ab, nichtzuletzt aufgrund der bereits geleisteten Arbeit und der damit verbundenen stärkeren Identiﬁkation mit dem Projekt.160 Hier wirkt nicht zuletzt die Wissensschwelle und die länger dauernde Aufnahmeprozedur stabilisierend. Es ﬁndet sich im Produktionsprozeß ebenfalls eine Kern-PeripherieStruktur wie in den Kommunikationen. Diese Struktur ist aufgrund der hohen Fluktuation im medial bestimmten Feld ebenfalls dynamisch. Sie beschreibt zudem auch eine erste Polarität in der Arbeitsteilung: innen wird programmiert, außen werden Fehler gefunden. Arbeitsteilung Neben dieser sehr grobkörnigen Kern-Peripherie-Arbeitsteilung gibt es in der Kooperation der Programmierenden weitere Formen der Arbeitsteilung. Wenn ein Problem, sei es ein Fehler oder eine neue Funktion, entdeckt ist, schließt sich die Bewertung dieses Problems an: Wie gravierend ist der Fehler bzw. das Fehlen einer Funktion? Wie schnell muß das Problem behoben werden? So entstehen implizite oder auch explizite Tätigkeitslisten mit abzuarbeitenden Problemen. Das grundlegende Kriterium für die Problemlösung oder auch von Programmcode ist dabei die technische Rationalität: 160 Wie stark diese Identiﬁkation werden kann, verdeutlicht die Aussage eines Programmierers: »Ich habe auf jeden Fall väterliche Gefühle gegenüber den Programmen, die ich schreibe. Ich beschütze sie, und ich will, daß sie der Welt Gutes tun.« Zitiert nach Turkle 1984: 290.

4.2 Strukturierungen durch Produktion

163

»Dann isses halt so, wenn da’n Anwender ein Feature haben will und des macht technisch absolut überhaupt gar keinen Sinn und es paßt net rein ’nd es gibt auch keinen Kompromiß, dann gibt’s des Feature halt auch net. « (E1, Z. 248 ff.) Diese grundlegenden Konsensualitäten der Selbstbestimmung und der technischen Rationalität werden auch von den anderen Interviewten immer wieder betont (vgl. auch Abschnitt 3.3). Sind Bewertungen dieser Art und Listen mit Funktionen in mehr oder weniger intensiven Diskussionen erstellt, stellt sich die Frage, wie die Arbeits(ver)teilung sich konkret gestaltet. In einer Organisation von Freiwilligen, die in ihrer Freizeit arbeiten, fehlen die Steuerungsmechanismen Hierarchie und Preis. Eine Möglichkeit zeigt E3 auf (nachdem er die technische Notwendigkeit des Interprozessmoduls erläutert hat): »Und dieses große Projekt von Anfang des Jahres da hab ich mich dann drangesetzt und hab dieses Modul hab ich eingebaut [. . .] Das warn diese vier Wochen und Wochenenden intensiver Arbeit. Danach hab ich hab ich gedacht, jetzt machst Du das einfach, weil wenn Du sagst, ich mach das jetzt, dann kommen sie an und sagen ((mit gehobener Stimme :)) Ja, blablabla, und wieder lange Diskussion, sondern ich hab das einfach so still und leise gemacht, hab das dann geschickt und dann hat es dann auch funktioniert.« (E3, Z. 776 ff.) In den freiwilligen Zusammenhängen der F/OS-Programmierer erfolgt keine Zuweisung von Aufgaben, sondern, das zeigt die obige Sequenz auch, die Übernahme von Aufgaben erfolgt freiwillig, sei es aus einem Verantwortungsgefühl heraus oder aus einer Verpﬂichtung gegenüber dem gemeinsamen Projekt (die in dieser Sequenz bei E3 vorherrschen). Sei es weil die Arbeit Spaß macht, das Problem intellektuell reizvoll ist, sei es aus Reputationsgründen oder sei es aus einem persönlichen Bedürfnis nach dieser speziellen Funktion. Meist dürfte eine Mischung dieser (oder weiterer) Motivationslagen vorliegen.161 Die Übernahme der Aufgabe kann, im Gegensatz zum zitierten Fall, 161 Im Gegensatz zu den ökonomischen Untersuchungen zur F/OSS, die sich vor allem

164

4 Kommunikative und produktive Strukturierungen

entweder kommunikativ unter den Entwicklern abgeklärt werden, um doppelte Arbeit zu vermeiden, oder sie ergibt sich im Zuge einer Verteilung von Verantwortlichkeiten für bestimmte Module, Codesegmente oder Funktionen, also einer eingespielten Arbeitsteilung. Gerade diese Strategie der Modularisierung ist in allen größeren F/OS-Projekten zu beobachten. Sie ist für die Organisation der Arbeitsteilung in einer Freiwilligenorganisation mit begrenzten zeitlichen Ressourcen nahezu unerläßlich. Das große gemeinsame Programm wird entsprechend der Funktionalitäten in einzelne Segmente mit deﬁnierten Schnittstellen aufgeteilt. So lassen sich auch Programme mit dem Umfang von mehreren Millionen Zeilen Programmcode wie etwa der Linuxkernel, von einer kleinen, wohlorganisierten Gruppe sinnvoll bearbeiten. Diese Aufteilung der Zuständigkeiten erfolgt ebenfalls auf freiwilliger Basis. Nach der Übernahme der Aufgabe ist der nächste Arbeitsschritt, eine Lösung für das zu bearbeitende Problem zu ﬁnden. Dabei ist es meist weniger schwierig, überhaupt eine Lösung zu ﬁnden, als aus der Vielzahl der möglichen Lösungen eine in die gesamte Projektentwicklung passende auszusuchen. Diese muß dann gemäß den Stilvorgaben des Projektes umgesetzt werden. Der geschriebene Code wird dann (zusammen mit der aktuellen Version) kompiliert und lokal auf dem eigenen Rechner getestet. Die Lösung des Problems und die ersten Tests liegen also nur in der Verantwortlichkeit der Programmierenden: »Das ist ein etwas heikles Thema, also Qualitätskontrolle bei Open Source Projekten, das is sowieso so’n Thema für sich, es gibt leider in gewissem Sinn auch den Coolnessfaktor: ey das is toll, laß es uns darein packen, ansonsten eigentlich die Committer, da wird erwartet, daß die also in der Lage sind, sich Gedanken zu machen, ob der Code zur Applikation paßt, und daß sie nicht irgendwelchen Kram da in das cvs packen.« (E2, Z. 116 ff.) Danach wird der extrahierte neue Code, der Patch, entweder direkt in den Projektsourcecode eingefügt oder für eine Überprüfung erst auf der Mailingliste gepostet. auf die Frage der individuellen Motivation kaprizieren, um das Modell des rationalen Individuums zu retten (vgl. beispielsweise Lerner und Tirole 1999), bleiben in dieser Arbeit subjektive Motivationen am Rande der Beobachtung.

4.2 Strukturierungen durch Produktion

165

»Jaaa, also das is ein Projekt, wo man ein bischen vorher diskutiert, und man auch die Patches einfach mal vorher hin und her mailt, bevor’s ins ofﬁzielle Repository kommen.« (E2, Z. 131 ff.) Von Seiten der anderen Entwickler (teilweise auch automatisiert) erfolgen Überprüfungen anhand der Kriterien Lizenzen, Stil, Lauffähigkeit etc. Die Arbeitsteilung innerhalb des engeren Entwicklerkreises erfolgt auf Basis eines meist modularisierten Arbeitsgegenstandes und der freiwilligen Übernahme von Aufgaben durch die Programmierenden. In diesem engeren Kreis erfolgt meist auch die erste Prüfung des Codes nach dem peer review-Prinzip, bevor er zum Programm hinzugefügt und veröffentlicht wird. Koordination Nach welchen nicht auf der technischen Rationalität beruhenden weiteren Kriterien ein Patch oder ein neues Stück Code dann beurteilt wird oder werden kann und wer die Verantwortung für das Einfügen trägt, verdeutlicht E5 als Maintainer: »Das gibt alle möglichen Kriterien. Paar ganz allgemeine formale Kriterien, zum Beispiel für die Lizenzen, daß der Code halt unter ’ner entsprechenden Lizenz sein muß [. . .]. An den Libraries muß es heut irgendwie LGPL oder irgendwas Äquivalentes sein, ansonsten GPL oder irgendwas Kompatibles dazu. Das is so ein formales Kriterium. Es gibt so was Stil zum Beispiel angeht, da gibt’s denk ich ganz unterschiedliche Vorlieben, wo im Endeffekt dann halt die Leute, die den Code tatsächlich betreuen dann irgendwie entscheiden müssen, was sie damit machen [. . .] es ist auch von den Projekten her unterschiedlich. Manche sind=also bei dem Mailprogramm zum Beispiel ist es ein etwas konservativerer Entwicklungsansatz. Da wird Code meistens relativ genau angeguckt, bis er reinkommt. Dann gibt’s eigentlich meistens über Patches erstmal Diskussionen auf den Mailinglisten und bei anderen Projekten, also bei P5 handhabe (betont: ich’s) meistens eher ’n bischen lockerer, daß halt Code eher mal reinkommt und dann halt

166

4 Kommunikative und produktive Strukturierungen sich im Projekt quasi weiterentwickeln kann. Ja, inhaltlich gibt’s, kann man gar nicht sagen. Wir haben natürlich so’n paar Sachen irgendwie in unserem User Interface Styleguide, wo drinsteht, wie ’n User Interface aussehen sollte. Das ist natürlich auch’n Kriterium. Ähm, dann muß der Code natürlich funktionieren und fehlerfrei sein und so Geschichten. Aber in der Regel, denk ich, mal abgesehen von so allgemeineren Richtlinien entscheiden die Leute, die direkt mit Code befaßt sind, ob das reinpaßt oder nich.« (E5, Z. 237 ff.)

Im Wesentlichen bleibt es damit den einzelnen gleichrangigen Programmierenden oder den »Codebetreuern« überlassen, welcher Code in das Projekt kommt. Der Produktionsprozeß ist, das zeigt auch diese Aussage, stark individualisiert und auf Eigenverantwortlichkeit ausgelegt. Im Mittelpunkt steht der selbstbestimmte Entwickler. Damit stellt sich die Frage nach der Koordination der Tätigkeiten.162 Die Intensität des Review-Verfahrens ist dieser Aussage zufolge von Projekt zu Projekt verschieden, sie ist auf einem Konsens der beteiligten Programmierenden basiert.163 Gleichzeitig hebt E5 in diesem Zusammenhang die relativ starke Rolle des Maintainers hervor. Bei ihm liegt die letzte Entscheidung über den Code, wenn sich die anderen Programmierer nicht einig werden sollten. Und er ist der Aussage von E5 zufolge zuständig für die Einsetzung, Einhaltung und Reproduktion von Regeln, in diesem Fall für die Regel der Reviewpraxis. Aber er läßt »in der Regel« den »Leuten, die direkt mit dem Code befaßt sind« die 162 Vgl. zur Frage der Koordination Brand und Schmid 2005, die auf Grundlage von empirischen Daten aus dem KDE-Projekt arbeiten. 163 Dieser Aspekt wird nicht von allen Interviewten ausschließlich positiv gesehen: »Es gibt heute Open Source Projekte, die wenn ich downloade, ich weinen könnte, daß Leute so schlechten Code schreiben können, und dann unter dem Motto, es is Open Source, ändert’s euch halt selber, auf den Markt schmeißen. [. . .] Hauptsache ist, daß also Testen und QA in der Open Source Welt eher auf Zufallsbasis basieren, also ich kenne zwar aus dem Javabereich einige gute Projekte, wo viel getestet wird, [. . .] aber dann sind dann häuﬁg Projekte, die auch sofort ein Steering-Kommittee haben, die also auch genau deﬁnierte Strukturen haben, wer überhaupt Code einfügen darf.« (E2, Z. 940 ff.) E2 befürwortet im Sinne einer Qualitätserhöhung eine stärkere Hierarchisierung bzw. die Übernahme solcher qualitätsichernder Tätigkeiten durch Körperschaften (Unternehmen, staatliche Institutionen oder auch die FSF).

4.2 Strukturierungen durch Produktion

167

Entscheidung. Seine Position als Maintainer wird in dieser Sequenz klar: mit der starken Betonung der Eigeninitiative und -verantwortung der Freiwilligen bleiben ihm eher moderierende Aufgaben. Er soll den möglichst reibungslosen Ablauf von Diskussion und Produktion koordinieren,164 grundlegende Konsensualitäten wie die technische Rationalität als generelles Kriterium sicherstellen und über mäßigende und legitimierende Beiträge die Einheit des Projektes erhalten. Trotz des hier angedeuteten nur moderierenden Führungsstils, der für ein Projekt von selbstbestimmten Freiwilligen unumgänglich ist (wenn auch die Ausprägung graduell unterschiedlich sein kann), kann durchaus Führung, Leitung und eine letztentscheidende Instanz existieren, die die erwähnten, relativ unspeziﬁschen Kriterien umsetzt und Freiwillige dazu bringt oder motiviert, gewisse Aufgaben zu übernehmen. Diese Leitungsposition basiert, sofern sie in einem Projekt überhaupt existiert, auf der Anerkennung der selbstbestimmten Entwickler. Diese Position ist aufgrund der Moderationsfunktion mit einem qualitativ, nicht quantitativ, höheren Aufwand an Kommunikationsleistungen verbunden.165 Zwar reduziert sich dadurch eventuell die Softwareproduktion der jeweiligen Person, aber durch die Repräsentationsfunktion, die dieser Position auch anhängt, erfolgt auch die Reputationszuweisung von außen vor allem an diese Position. 4.2.4 Kurze Typologie der Organisationsformen Auf der bisher entwickelten Basis von sich meritokratisch und kooptativ konstituierenden Zusammenschlüssen von selbstbestimmt arbeitenden Programmierern entwickeln sich eine Vielzahl von Organisationsformen.166 Allen gemeinsam sind die selbstbestimmten Entwickler als Kernelemente der Organisation. Das hauptsächliche Differenzierungskriterium für die Organisation der Projekte ist die Verteilung des Schreibrechtes am Quellcodedepot. Diese Form des Eigentumsrechts 164 Daß eine nicht funktionierende Koordination zu einer ernsthaften Krise für eine Führungsﬁgur werden kann, mußte auch die Ikone der F/OSS, Linus Torvalds, erfahren, vgl. http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.3/1000.html. 165 Diese Funktion wird auch exemplarisch im Abschnitt 5.2.1 deutlich. 166 Vgl. etwa zum Linuxkernel und zum fetchmail-Projekt Raymond (2001c;b), zum KDE-Projekt Brand et al. (2005); Brand und Schmid (2005), zum Gnomeprojekt German (2003).

168

4 Kommunikative und produktive Strukturierungen

als Recht zur Verteilung strukturiert die Freiwilligenzusammenhänge grundlegend. Einige der Organisationstypen sollen kurz skizziert werden. Die Bezeichnung der Typen ist zwar an den gängigen politischen Herrschaftsformen orientiert, aber es sei darauf hingewiesen, daß nicht, wie in Webers Deﬁnition, die Chance für einen Befehl Gehorsam zu ﬁnden für die Bezeichnung ausschlaggebend war, sondern die in der jeweiligen Herrschaftsform gegebenen Handlungs- und Teilhabemöglichkeiten der ›Beherrschten‹. Anarchie In kleineren Projekten ﬁndet sich auch das andere Extrem, die freie Vergabe von Schreibrechten an jeden, der es wünscht, ohne die Instanz einer Projektleitung. Ein Beispiel dafür ist das Projekt P3.2: »Das ist eine kleinere Gruppe, also es gibt so einige Leute, die halt da bischen mehr involviert sind, aber es gibt so keinen festgelegten Projektleiter. Und es ist so, daß P3.2 hat einerseits driver und andererseits so die Basislibrary und es gibt viele Leute, die halt so einen oder zwei Treiber betreuen und halt nichts mit der Basislibrary machen und gibt halt Leute, die auch zu ihrem Treiber dann halt auch an der Basislibrary zusätzlich mitarbeiten. Also und es gibt auch da einen Koordinator für die Übersetzung, für die Dokumentation, nee gibt’s glaub’ich keinen. [. . .] da hat eigentlich ziemlich jeder write-access, aber das’s ’n Sourceforge-Projekt ein CVS-Repository da und es hat also jeder der sagt, er hätte gerne write-access, weil er halt das und das beitragen will, kriegt auch write-access.« (E3, Z. 78 ff.) In diesem Projekt ist die Vergabe von Schreibrechten sehr liberal: jeder der Schreibzugriff beantragt, weil er einen Beitrag ankündigt, bekommt ihn auch. Das erspart den wenigen Entwicklern unnötigen Aufwand (etwa Code von jemand anderem zu prüfen und einzuchecken oder die Beurteilung der Leistung der anderen. Die modulare Anlage des Projektes ermöglicht die Aufteilung in kleine, gut abgegrenzte Bereiche, die einzelnen Treiber und eine aus gemeinsam verwendeten Codebausteinen generierte Basisbibliothek. Gleichzeitig unterstellt

4.2 Strukturierungen durch Produktion

169

diese Form der Organisation eine hohe Eigenverantwortlichkeit auf Seiten der Entwickler. Demokratie Basisdemokratie Die Besonderheit des für diesen Typ beispielhaft fungierenden Debian-Projektes liegt darin, daß das Ziel nicht die Entwicklung eines bestimmten Programmes oder einer Gruppe von Programmen ist, sondern die Zusammenstellung existierender Programme zu einer sog. ›Distribution‹, d. h. ein vorkonﬁguriertes, vorkompiliertes und aufeinander abgestimmtes komplettes Software-System (Betriebssystem, Software-Bibliotheken und eine Vielzahl von Anwendungsprogrammen). Das Projekt bietet zum Zeitpunkt der Niederschrift mehr als 15.000 Programme (auf zwei Betriebssystemplattformen für mehr als zehn Prozessorarchitekturen), die von beinahe 1.000 weltweit verteilten Entwicklern betreut werden. Nach einem relativ rasanten Wachstum von einigen Dutzend Entwicklern im Jahre 1994 auf 200 Entwickler 1997 wurde eine Umstrukturierung und stärkere Kodiﬁzierung vorgenommen. So wurden 1997 ein Gesellschaftsvertrag , die Richtlinien für Freie Software (beide unter http://www.debian.de/social_contract zu ﬁnden) und 1998 schließlich eine Verfassung (http://www.debian.de/devel/constitution) verabschiedet.167 Die Präambel dieser Verfassung lautet: »The Debian Project is an association of individuals who have made common cause to create a free operating system.« Die Betonung liegt nicht auf »Open Source«, sondern auf dem von der Free Software Foundation propagierten Aspekt der Freiheit. Damit ist eine eindeutige Positionierung im Diskurs vollzogen. Was als freie Software angesehen wird, ist in den Richtlinien für Freie Software festgelegt und deckt sich weitgehend mit den Deﬁnitionen der FSF. Diese Ausrichtung produziert eine Vielzahl von Rechtsdiskussionen über einzelne Lizenzen, einzelne Passagen aus Lizenzen etc. (vgl. dazu ausführlich Coleman 2005). 167 Auf eine Besonderheit des Debian-Projektes kann hier nicht weiter eingegangen werden: das langdauernde, sehr bürokratisch anmutende Aufnahmeverfahren für neue Entwickler. Die im Folgenden entwickelte Struktur gilt nur für Entwickler, die diese Prozedur durchlaufen haben.

170

4 Kommunikative und produktive Strukturierungen

In der Verfassung werden sechs unterschiedliche Entscheidungsinstanzen für das Projekt festgelegt: die Entwickler können durch Abstimmung projektweite Entscheidungen herbeiführen, der jährlich gewählte Projektleiter, das technische Kommittee bzw. dessen Vorsitzender, der einzelne Entwickler für seinen Arbeitsbereich, vom Projektleiter ernannte Delegierte für bestimmte Aufgaben und schließlich der Projektsekretär. »Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader’s Delegate(s) consider worthwhile.« Freiwillige sind einverstanden, die Ziele des Projekts zu fördern, insbesondere indem sie Softwarepakete pﬂegen oder Arbeiten übernehmen, die von den Delegierten des Projektleiters als wünschenswert angesehen werden. Die Übernahme solcher Arbeiten, das wird in Absatz 2.1. betont, ist jedoch freiwillig. Die einzige Pﬂicht ist, daß nicht aktiv gegen die Regeln und der aufgrund dieser Regeln getroffenen Entscheidungen gearbeitet wird. Die Entwickler können eigenständig Entscheidungen in Bezug auf ihr(e) Paket(e) treffen, sind also in ihrem eigentlichen Arbeitsbereich keiner weiteren Instanz untergeordnet, solange sie sich an die Projektrichtlinien halten. Sie haben aktives und passives Wahlrecht für den Posten des Projektleiters, und sie können Resolutionen beantragen (etwa über Änderung der Verfassung oder des Gesellschaftsvertrags), über beantragte Resolutionen abstimmen oder Entscheidungen des Projektleiters durch ein Votum aufheben. Sie sind also die demokratische Basis des Projektes. Der Projektleiter ernennt Delegierte für bestimmte Aufgaben, ernennt den Projektsekretär und ernennt zusammen mit dem Vorsitzenden des Technischen Kommittees neue Mitglieder des technischen Kommittees. Zudem verwaltet er zusammen mit der Organisation Software in Public Interest (SPI) die materiellen Ressourcen des Projektes. Er wird jährlich von den Entwicklern gewählt. »The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. [. . .] The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.« Der Leiter soll demnach als Repräsentant der Entwickler auftreten. Die in ihrem Arbeitsbereich weitgehend selbständig arbeitenden

4.2 Strukturierungen durch Produktion

171

Entwickler haben sich eine auf demokratischen Wahlen und an ebensolchen Prinzipien orientierte Organisationsstruktur gegeben. Die Repräsentanten und Funktionäre des Projektes sind gehalten, sich an den konsensuellen Entscheidungen der Entwickler zu orientieren. Konsensorientierte Kommittees Ebenfalls stark konsensuell orientiert ist das Apacheprojekt. Allerdings erfolgt die Besetzung der für die Organisation kennzeichnenden Kommittees nur für das oberste, das Board of Directors, durch Wahlen. Die Besetzung der jeweiligen Projekt- bzw. Unterprojektskommittees erfolgt aufgrund kooptativer und meritokratischer Entscheidungen. Apache ist das weitverbreitetste Serverprogramm für das World Wide Web.168 Mit dem Wachstum des World Wide Web (und der damit verbundenen starken Verbreitung des Programmmes), den wachsenden ökonomischen Interessen in diesem Sektor und einer Ausdifferenzierung des Projektes in Module, Unter- und Nebenprogramme wuchs die Notwendigkeit einer formalisierten Organisation. Eine eigentliche Begründung für die Gründung der Dachorganisation Apache Software Foundation ist jedoch der rechtliche Schutz der beteiligten Programmierer. Diese Stiftung funktioniert als Dachorganisation für eine Vielzahl von Projekten. Sie hat eine eigene Satzung (vgl. http://www.apache.org/ foundation/bylaws.html) und eine komplexe Organisationsstruktur entwickelt. An der Spitze beﬁndet sich eine neunköpﬁge Kommission (Board of Directors), die für die Verwaltung der materiellen und intellektuellen Vermögenswerte zuständig ist, jedoch nicht in die Entwicklung der einzelnen Programme eingreift. Auch hier ﬁndet sich die Selbstbestimmung, sowohl auf der Ebene der Projekte als auch der 168 Das Projekt wurde 1995 begonnen, um den vom NCSA (National Center for Supercomputing Applications) entwickelten Webserver weiterzuentwickeln. Die Entwicklung war zum Stillstand gekommen, weil die Firma Netscape einen Großteil der Programmierer abgeworben hatte. Eine Gruppe von Freiwilligen entschloß sich, die existierenden Patches in das vorhandene Programm zu integrieren.169 Daraus wurde schließlich der Apache-Webserver entwickelt, eines der erfolgreichsten F/OSProjekte. 169 Einer Version dieser Erzählung nach soll daher auch der Name kommen: »a patchy Webserver«.

172

4 Kommunikative und produktive Strukturierungen

Entwickler. Diese Kommission wird jährlich von den Mitgliedern der Stiftung gewählt. Die selbstbestimmten Entwickler schließen sich in Softwareprojekten zusammen. Das Apache Software Foundation und das Board haben für diese Projekte nur die Aufgabe, Infrastruktur, Ressourcen, Schenkungen etc. zu verwalten und eine rechtliche Absicherung zu gewährleisten. Sie beteiligen sich (in diesen Rollen) nicht direkt an der Softwareentwicklung. Nur in wenigen Fällen wird vom Board in diesen Prozeß eingegriffen: wenn ein Projekt so zerstritten ist, daß keine Entwicklung mehr stattﬁndet,170 oder wenn der entwickelte Code ohne Lizenz verteilt wird. Die Projekte organisieren weitgehend selbstbestimmt die Softwareentwicklung für ihren Bereich. Das gilt für die internen Regeln, nicht jedoch für die Bestimmung des sog. »Project Management Committees« (PMC). »The Apache projects are managed using a collaborative, consensus-based process. We do not have a hierarchical structure. Rather, different groups of contributors have different rights and responsibilities in the organization. Since the appointed Project Management Committees have the power to create their own self-governing rules, there is no single vision on how PMCs should run a project and the communities they host.« (http://www.apache.org/ foundation/how-it-works.html) Dabei ist der typische Fall, daß ein Projekt mit dem Konsens aller beteiligten Entwickler durchgeführt wird. Auftretende Differenzen werden im Normalfall durch Abstimmung gelöst, wobei die informelle Vorgabe ist, daß jeweils alle zustimmen sollen. Dafür gibt es Abstimmungsregeln: »Es gibt die sogenannten Apache-Voting-Rules, nennt sich das, also es gibt Abstimmungsregeln. Prinzipiell kann jeder 170 Vgl. das Avalonprojekt, das im November 2004 nach monatelangen Auseinandersetzungen innerhalb des Projektteams und der Gründung eines auf dem gemeinsam entwickelten Code beruhenden Projektes außerhalb der ASF geschlossen wurde (http://mail-archives.apache.org/mod_mbox/avalon-dev/, vor allem Juli bis November 2004). Vgl. auch Abaschnitt 6.3 der Stiftungssatzung.

4.2 Strukturierungen durch Produktion

173

Committer hat eine Stimme und er kann eigentlich drei Arten abstimmen: Das ist bei Apache halt so ((schnell: immer schon so gewesen)). Es gibt plus eins, null und minus eins. Wenn jemnd zu einem bestimmten Thema einfach sagt, ich bin minus eins auf dieses Thema, dann gilt das als Veto. Wenn also ein Committer sagt, ich vetoe diese Änderung, dann muß dieses Veto zunächst einmal unter den Committern diskutiert werden, warum das der Fall ist, also warum der sagt, ich bin dagegen, daß das hineinkommt und normalerweise Code, der gevetot is, darf nicht eingecheckt werden, das ist halt so unter den Committern so vereinbart. Null heißt normalerweise, ich hab dazu keine Meinung, und plus eins heißt, ich bin dafür.« (E2, Z. 166 ff.) Für eine Organisation, die wesentlich von den freiwilligen Beiträgen ihrer Entwickler abhängt, ist eine solche konsensbasierte Selbstverwaltung essentiell. Jede Sanktion, jeglicher hierarchische Eingriff von oben kann den fragilen Zusammenhalt stören und damit zu einer Spaltung oder gar Auflösung des Projektes führen. Damit würde auch die Stiftung als Ganzes geschwächt. Deswegen wird die nicht-hierarchische Struktur so betont, wird auf die Selbstverwaltung der Gleichrangigen verwiesen. Nichtsdestotrotz wird der Zusammenhang der einzelnen Projekte mit der übergeordneten Stiftungsstruktur nicht aus den Projekten heraus bestimmt, sondern von der Stiftung. Die »Project Management Committees« (PMC) bzw. die Vorsitzenden derselben sind ernannt von der Stiftung. Um die Rolle als ›Rechtsschutzversicherung‹ und Infrastrukturlieferantin wahrzunehmen, ernennt die Stiftung in den einzelnen Projekten »ofﬁcers«, Funktionäre, die gleichzeitig Vizepräsidenten der Stiftung sind. Sie sollen auf die Einhaltung der Lizenzbestimmungen achten und die Kooperation fördern, schlichtend eingreifen, Konﬂikte lösen helfen und Informationen aus den Projekten an das Board liefern (vor allem in Form von vierteljährlichen Berichten). Wie bei der Mitgliedschaft in der Foundation erfolgt die Ernennung ins PMC wiederum aus dem Projektkern heraus im Sinne einer Kooptation. Dieser für den Ernannten passive Vorgang erfolgt nach Verdienst und Leistungen für das

174

4 Kommunikative und produktive Strukturierungen

Projekt, meritokratisch, und garantiert damit eine gewisse Kontinuität. Die Stiftung muß also eine prekäre Balance zwischen Eingriffen ›von oben‹ im Sinne eines Allgemeininteresses und den Interessen der einzelnen Projekte wahren. Das funktioniert im Großen und Ganzen sehr gut, weil die Eigenständigkeit der Projekte geachtet wird. Die gesamte Organisation beruht auf einen sog. ›top down‹-Mechanismus, in dem Sinne, daß neue Mitglieder oder Funktionäre von den bereits Etablierten nach der Maßgabe ihrer Verdienste und Leistungen bestimmt werden. Dabei behalten die basalen Einheiten der Organisation, die konsensorientierten einzelnen Projekte, jedoch eine weitgehende Selbständigkeit. Nur in Ausnahmefällen wird von oben eingegriffen, und das meist auch nur auf Wunsch der Projekte selbst.171 Die sich auf kooptativer Basis meritokratisch öffnende Organisation des Apache-Projektes weist eine gewisse Polarität zwischen den einzelnen Projekten und der kommitteeförmig organisierten Dachorganisation auf. Dadurch, daß das Konsensprinzip zentral ist und die Stiftung sich jedoch aus der konkreten Produktion heraushält, also die Autonomie der Projekte und Entwickler anerkennt, und nur rechtliche und infrastrukturelle Aufgaben wahrnimmt, kommt diese Polarität nicht negativ zum Tragen. Oligarchie Das Projekt P1 wurde von einer Kerngruppe von fünf gleichberechtigten Leuten geleitet,172 die unbeschränkten write-access haben. Die pﬂegen alle Beiträge der »etwa 20 ständigen Contributors« ein. Auf der Mailingliste sind zum Zeitpunkt des Interviews schätzungsweise etwa 300 - 400 Leute registriert. Es ist also ein größeres Projekt, das von einer kleinen, paritätisch organisierten Gruppe geleitet wird. Die Mitglieder dieser Gruppe kennen sich zum Zeitpunkt des Interviews nur teilweise persönlich, weil sie über 3 Kontinente verstreut sind. E1 wurde in die Kerngruppe aufgrund seiner Beiträge aufgenommen und nachdem er einen der vier anderen Entwickler persönlich kennengelernt hatte. Für die Kerngruppe von P1 scheint dies ein generelles Prinzip zu sein: neben den Beiträgen (zu Beginn des 171 Vgl. wiederum die Auflösung des Avalonprojektes. 172 Diese Aussage bezieht sich auf den Zeitpunkt des Interviews. Inzwischen haben sich die Modalitäten hin zu einem eher zentralistischen Modell geändert.

4.2 Strukturierungen durch Produktion

175

Projektes wurde sogar eine quantitative Messung durchgeführt) ist der persönliche Kontakt ein Kriterium für die Aufnahme in die Kerngruppe. Nachdem es sich bei P1 um sicherheitsrelevante Software handelt, ist Vertrauen, das vor einem direkten Zugang zum Quellcodearchiv erlangt werden muß und das über reinen Mailinglistenkontakt wenn überhaupt, dann nur mühsam aufgebaut werden kann, essentiell. Aristokratie Eine weitere Form ﬁndet sich im Linuxkernel , in dem zwar eine Person »herrscht«, aber aufgrund der Komplexität eines/des Betriebssystems haben sich jedoch Spezialisten für die einzelnen Bereiche herausgebildet, die als eine Art »Minister« für Linus Torvalds fungieren: sie ﬁltern die eingesandten Patches und leiten nur die interessanten Stücke weiter. Gleichzeitig pﬂegen sie teilweise eigene Codedepositorien, die zusätzliche Tests ermöglichen (vgl. dazu auch Raymond (2001a;c), der selbst im fetchmail-Projekt einen monokratischen Führungsstil pﬂegte). Diese Form der Aristokratie unterscheidet sich von der oben entwickelten Oligarchie, die eine gleichberechtigte Gruppe an der Spitze sieht, durch eine klare Hierarchisierung innerhalb der Gefolgschaft. Monokratie Viele Projekte werden von nur einem Entwickler gestartet, und dieses Prinzip, nur eine Person mit dem Schreibzugriff zu betrauen, bleibt in manchen Projekten erhalten, sei es, weil sie klein bleiben und kein Interesse von anderen Entwicklern auf sich ziehen (was früher oder später die Aufgabe eines solchen Projektes nach sich zieht), oder sei es, weil es Gründe dafür gibt, diesen Modus aufrechtzuerhalten: »Also da bin ich ein ganz normaler Entwickler, im Endeffekt. Also es ist auch so, im P3.1-Projekt: es gibt einen Chef-Maintainer, der so über dem Ganzen drübersteht, der auch da Schreibzugriff hat und der auch die Patches am Ende reviewt und alle die dann eincheckt und der Rest sind alles Entwickler, jeder hat so sein zwar sein Spezialgebiet oder seine Spezialgebiete, wo er was macht aber es gibt so keine Hierarchie da weiter [. . .] Also es gibt Leute die halt mehr Patches schicken die wirklich viel machen,

176

4 Kommunikative und produktive Strukturierungen die ’n großen Teil ihrer Zeit darauf verwenden. Es gibt auch welche die halt nur wenig machen, die halt ab und zu ihre Lieblingsapplikation nehmen und da schauen ob die funktioniert und dann ein, zwei Patches machen.« (E3, Z. 26 ff.)

Im Fall von P3.1 ist der Projektleiter die einzige Person, die Schreibzugriff auf den Quellcode hat. Das wird gerechtfertigt mit der notwendigen Qualitätskontrolle und der Komplexität des Codes und von den Entwicklern auch als notwendig akzeptiert. Die Stabilität von F/OSS-Projekten drückt sich aus und erhöht sich durch die jeweilige Organisationsform der Projekte. Die vor allem auf Gleichberechtigung (bzw. im Falle der Abwesenheit derselben auf die breite Anerkennung der Differenzierung), Selbstbestimmung und Konsens beruhenden Formen schaffen einen stabilen institutionellen Hintergrund, vor allem für die größeren Projekte, aus dem heraus Ressourcen, Infrastruktur und vielfältige Hilfen in Bezug auf Rechtsfragen, Lizenzen oder auch Moderation zur Verfügung gestellt werden. In F/OS-Projekten ﬁndet sich auch im Produktionsprozeß eine lockere Kern-Peripherie-Struktur, ähnlich, aber nicht parallel, zu der im Kommunikationsprozeß gefundenen. Grundlage und Zentrum der Produktion sind die individuellen, selbstbestimmten Entwickler. Diese Freiwilligen teilen die anfallenden Arbeiten unter sich auf und greifen dabei in Bezug auf den Arbeitsgegenstand häuﬁg auf das Konzept der Modularisierung zurück. Die Position der Leitung existiert zwar in vielen Projekten, aber nicht im Sinne einer hierarchisch übergeordneten Instanz, sondern als moderierende, schlichtende, motivierende und regelreproduzierende Funktion.

4.3 Strukturierungen – Zusammenfassung Entscheidend für die Strukurierungen in der Produktion ist das Schreibrecht an den Quelltextdepots, d. h. die Möglichkeit, selbständig Code zum gemeinsamen Programm hinzuzufügen. Diese Schwelle setzt die entscheidende Differenz in den Projekten. Sie stellt für bereits computeralphabetisierte F/OS-Entwickler die eigentlich zu überwindende Schwelle in einem Projekt dar. Basierend auf einem mehr oder weniger

4.3 Strukturierungen – Zusammenfassung

177

intensiven, sich meist über einen längeren Zeitraum erstreckenden Auswahlprozeß, der meist meritokratisch und beruhend auf Kooptation sich auf die Leistungen für das Projekt stützt, wird die Akzeptanz und die Reproduktion der Regeln in den Projekten gesichert und versucht, die in freiwilligen Zusammenhängen unvermeidliche Fluktuation zu mildern. Die Koordination der gemeinsamen Arbeit ruht auf einer mehrstuﬁgen Arbeitsteilung auf: der Trennung von Kern und Peripherie und die damit verbundene Trennung von Problemﬁndung und Problemlösung. Sodann wird versucht, über eine Aufteilung des Arbeitsgegenstandes und der freiwilligen Übernahme der Pﬂege, Wartung und Erweiterung der entsprechenden Module, den Koordinationsaufwand zu senken. Schließlich existiert in vielen Projekten eine moderierende Position, um die Koordination zu verbessern, die Regeleinhaltung zu fördern, Konﬂikte zu lösen und die Einheit des Projektes zu wahren. Innerhalb dieser generellen Typik entwickelt sich ein breites Spektrum von Organisationsformen für die Projekte, die selbst die Größe von tausend oder mehr Entwicklern erreichen können. Diese Institutionalisierung verleiht den Zusammenschlüssen einen wesentlich dauerhafteren Charakter. Diese Mikrostrukturierungen in den Projekten sind natürlich nur in den Kommunikationen zu beobachten, aber sie sind deshalb keineswegs gleichbedeutend mit den kommunikativen Strukturierungen. Die Ebene der Produktion hat aufgrund der formalisiert-schriftlichen Gegenstandes Software und den in der Produktion bzw. Distribution verwendeten Programmen eigene Strukturierungspotentiale, die sich mit denen der kommunikativen Ebene zu einer jeweils projektspeziﬁschen Struktur überlagern. In Bezug auf die im Kapitel 2 aufgelisteten Unwahrscheinlichkeiten ist zu sagen, daß die destabilisierenden Wirkungen der computerbasierten Medien auf der kommunikativen Ebene zwar durch die grundsätzliche Öffentlichkeit noch verstärkt wird. Diese Öffentlichkeit entspricht aber dem normativen Prinzip des offenen, frei zugänglichen Wissensvorrats und deshalb unter allen Umständen aufrechterhalten. Mit einer Ausdifferenzierung der Mailinglisten, der Entwicklung von Regelsystemen und Strategien der kommunikativen Schließung wird versucht, die Nachteile dieser Medien auszugleichen. Ein wichtiges

178

4 Kommunikative und produktive Strukturierungen

Element zur Einschränkung der Diskussionen ist die performative Setzung von Code. Damit werden Entscheidungen durch die produktiven Entwickler getroffen, die kommunikativ zwar eingeholt, aber nicht rückgängig gemacht werden können. Diese Mechanismen grenzen die Diskussionen ein und stabilisieren so die Projekte. Zusätzlich ﬁnden sich bei nahezu allen größeren und zeitlich stabileren Projekten mehr oder weniger regelmäßige face-to-face-Treffen in Form von Konferenzen oder Workshops, die durch die Interaktionen die Möglichkeit stabilisierender persönlicher Beziehungen in die Projekte bringen. Mit Hilfe dieser Mechanismen werden die Unwahrscheinlichkeiten einer gelingenden Kooperation auf der kommunikativen Ebene eingegrenzt. Auf der Ebene der Produktion ist durch die formalisierte Schriftlichkeit des Quellcodes eine Wahrscheinlichkeit des Gelingens zwar bereits gegeben, aber hier ﬁnden sich auch noch zusätzliche Mechanismen, die diese Wahrscheinlichkeit erhöhen. Mit Hilfe der durch die Computeralphabetisierung gesetzten Wissensschwelle und von zeitlich meist ausgedehnteren und meist auf meritokratischen Prinzipien beruhenden kooptativen Aufnahmeprozeduren wird eine gewisse Homogenität in der Zusammensetzung der Teams erreicht, die, trotz der für Freiwilligenorganisationen typischen relativ hohen Fluktuation, für eine gewisse Kontinuität sorgt. Zusätzlich geben die zentral auf die selbstbestimmten Entwickler ausgerichteten Organisationsformen, in denen hierarchische Eingriffe nur sehr vorsichtig dosiert werden, zusätzliche Stabilität. Somit ergeben sich insgesamt auf der Ebene der Mikrostrukturen in den Projekten auch für ein dauerhaftes Funktionieren der Produktion ausreichend Wahrscheinlichkeiten. Nach dieser Analyse der mikrostrukturellen Prozesse innerhalb der F/OSS sollen nun in einem abschließenden Kapitel die Wechselwirkungen dieser Form der Softwareentwicklung mit der herkömmlichen, kapitalistisch organisierten Form der Softwareentwicklung und -verwendung untersucht werden, und damit die letzte Form der Unwahrscheinlichkeit, das Entstehen einer neuen Produktionsweise parallel zu einer erfolgreichen kapitalistischen, näher beleuchtet werden.

5 Ökonomie Nichts Niemand Nirgends Nie ! : Nichts Niemand Nirgends Nie ! : (die Dreschmaschine rüttelte schtändig dazwischen, wir konnten sagen & denken was wir wollten. Also lieber bloß zukukken.) (Arno Schmidt)

Die bisherigen Analysen haben gezeigt, daß mit der F/OSS eine medial vermittelte Form der Softwareproduktion durch unentgeltlich und selbstbestimmt arbeitende Freiwillige entstanden ist. Diese Zusammenhänge grenzen sich diskursiv von der kapitalistisch organisierten Softwareproduktion ab und entwickeln einen neuen Eigentumsbegriff, der sich vor allem auf das Recht der Verteilung stützt, nicht mehr auf das Recht der Nutzungsausschließung. Zentral für den Erhalt der Autonomie ist dabei ein allen verfügbarer Pool an Wissen bzw. Software mit verfügbarem Quelltext. Für die Produktion entwickeln sich aus den medialen Zusammenhängen unterschiedlichste Strukturierungs- und Organisationsformen auf dem Grundkonsens der technischen Rationalität, die sich von herkömmlichen Freiwilligenorganisationen und Gruppenbildungen durch den Arbeitsgegenstand Software, die speziﬁsche mediale Form der Kommunikation und die daraus folgende Lockerheit der Bindungen unterscheiden. Die vorhandenen Eintrittsschwellen und meritokratische Mechanismen stellen eine gewisse Homogenität der Beteiligten sicher. Diesen stabilisierenden Mechanismen steht die zentrale Unwahrscheinlichkeit der Entwicklung einer eigenständigen Produktions- und Distributionsweise parallel zu einer existierenden und ﬂorierenden kapitalistischen Produktion entgegen. Dieses vorletzte Kapitel will nun der Frage nachgehen, wie sich das Verhältnis von F/OSS und privatwirtschaftlichen Unternehmen ausge-

180

5 Ökonomie

staltet. Das heißt, welche ökonomischen Reperkussionen die F/OSS hat, also erstens welche Einﬂüsse von Seiten der Privatwirtschaft sich auf diese Zusammenhänge auswirken und zweitens, ob die F/OSS auch den Umgang mit Wissen in der kapitalistischen Ökonomie verändert. Dazu werden in einem ersten Abschnitt die gegenseitigen Vorteile einer Kooperation zudiskutieren sein, bevor die beiden Fragen in den jeweiligen Abschnitten anhand von empirischen Material geprüft werden.

5.1 Win - Win? Es liegt aus Sicht der ökonomischen Theorie nahe, Informationsgüter eher im Bereich der öffentlichen Güter zu verorten, eine Form von Gütern, die der Allgemeinheit etwa aus Steuermitteln unentgeltlich zur Verfügung gestellt werden.173 Demnach könnte die F/OS-Software von den Unternehmen einfach benutzt werden. Das geschieht zwar auch, auffällig sind jedoch die Kooperationsbeziehungen bzw. die Einbindung von Unternehmen in die Entwicklung. In einem ersten Schritt ist deshalb zu fragen, welche Vorteile die Kooperation von F/OSS und Unternehmen den Beteiligten bietet? Der Einsatz von F/OS-Software verschiebt die oben (Abschnitt 2.1, vgl. auch unten Kapitel 6) kurz skizzierte Waren- und Verwertungslogik von Software. Mit der Möglichkeit zur freien Weiterverteilung sinkt der Preis auf die Grenzkosten der Reproduktion, geht also im Fall von digitalisierten Gütern gegen Null. Gleichzeitig verliert der Anbieter mit dem offenen Quelltext sein Monopol auf das im Programm inkorporierte Wissen und damit auch auf die mit der Software verbundenen Dienstleistungen. Damit verschwindet der Warencharakter von Software und für Verwertungszwecke bleiben nur die Dienstleistungen rund um diese Produkte. Gerade diese Herausnahme des Wissens aus der Konkurrenz, die Wiederherstellung der Konkurrenzsituation in Bezug auf sofwarespeziﬁschen die Dienstleistungen (Anpassung, Schulung, Erweiterung etc.) und die Preislosigkeit machen F/OS-Software interessant für den Ein173 Typische Beispiele sind für öffentliche Güter sind Sicherheit, Leuchttürme, Gesetze etc. Vgl. für eine Diskussion des Zusammenhangs von Informationsgütern und öffentlichen Gütern Lang 2003; Klodt 2001; Stiglitz 2000.

5.1 Win - Win?

181

satz in kapitalistischen Unternehmen und staatlichen Verwaltungen. Nach anfänglichen Berührungsschwierigkeiten, die aber spätestens mit der Durchsetzung der neoliberalen »Open Source«-Semantik (vgl. Abschnitt 3.4) sich aufzulösen begannen, setzen eine Vielzahl von Firmen so entwickelte Software ein und beteiligen sich auch an den Entwicklungsprozessen selbst.174 »Es gibt ’ne ganze Reihe Firmen, auch große und sehr große Firmen, die hab’n handfestes Interesse an Open Source. Die wenden aber ihre vorhandenen internen bewährten Mechanismen zur Softwareentwicklung auf Open Source an, sprich [. . .] Linux und IBM. IBM hat eine Plattform, die ist zunächst einmal akzeptiert inzwischen, neben der Windowsplattform in der Industrie, und IBM is ein Hardwareladen, das heißt IBM macht zwar viel Software, aber an erster Stelle verkauft IBM ’ne Box. [. . .] Und, die sehen ein doch von der Qualität her relativ erträgliches Produkt und sagen, ok, wir ham hier quasi ein’ Rohdiamanten, der an vielen Stellen noch Ecken und Kanten hat, nicht geschliffen is. Wir können den aber nehmen, diesen Rohdiamanten, können ihn durch unsere bewährten ﬁrmeninternen Strukturen schicken, sei es QA, sei es Testen, und kriegen am Schluß etwas raus, was wir einfach wieder so zurückgeben, wie’s vorher Open Source war, bauen eine Reputation auf, IBM Open Source-freundlich [. . .] und ... haben ein Produkt, das is in der Benutzerbasis ihrer Maschinen akzeptiert die kaufen dann den IBM e-server mit Linux.« (E2, Z. 662 ff.) Diesem Entwickler und Unternehmer zufolge erkennen große Unternehmen wie etwa IBM das Potential von F/OS-Software und polieren diese Rohdiamanten in ihren vorhandenen Softwareentwicklungsstrukturen auf. Das Engagement solcher Global Players für F/OS-Software, sei es die Unterstützung und Verbesserung auf der einen Seite oder der Vertrieb und entsprechende Dienstleistungen dazu auf der anderen Seite, vervielfacht wiederum die Verbreitung dieser Software: 174 Vgl. auch 2.1.

182

5 Ökonomie »Ob die Daten von’nem Linuxserver oder von’nem Windowsserver gebracht werden is [den Anwendern] völlig egal und IBM sagt dann, ok ihr könnt beides haben, ihr spart hier fünf Prozent [Lizenzgebühren] und die Firmen sagen, hey, das is cool. Das is der kommerzielle Motor und dieser kommerzielle Überbau hat dazu geführt, daß viele kleinere und mittlere Firmen sagen, ok, ich kauf Linux nicht mehr bei ’ner obskuren Klitsche irgendwo in im Baden-Württembergischen oder im Hessischen oder im Bayrischen, sondern ich kauf die bei IBM. Ich kauf sie bei HP. Und wenn ich Probleme hab, dann kommt IBM und hilft mir. ’heißt, das tut viel für die Reputation von Open Source.« (E2, Z. 714 ff.)

Die Verwendung von F/OS-Software in Unternehmen scheint allen Seiten Vorteile zu bringen, den privatwirtschaftlichen Anwendern, weil sie über die nun mögliche Konkurrenz bei den Dienstleistungen eine bessere Marktposition bekommen, weil sie durch F/OS-Software kostengünstige(re) und qualitativ relativ gute Standardsoftware bekommen und weil der Erwerb von Software nicht mehr mit Bindung an einen Anbieter einhergeht. Und nicht zuletzt bringt diese Konstellation den F/OS-Entwicklern Vorteile, weil sich durch das Engagement der Industrie zum einen die Anwenderbasis massiv ausweitet (vgl. zum Wichtigkeit der Anwenderbasis S. 159 ff.) und zum anderen weil die Ressourcen, die für die Produktion ihrer Software aufgewendet werden, sich potentiell vervielfachen, sei es daß Hardware, Server oder Qualitätssicherungsmechanismen zur Verfügung gestellt werden, sei es, daß ﬁrmeneigenes Personal für die Entwicklung von F/OS-Software abgestellt wird. Aber damit entsteht für die F/OSS die Gefahr eines unerwünschten Einﬂusses von außen, der den Konsens und die Grenzziehungen der F/OS-Zusammenhänge gefährden könnte. Für privatwirtschaftliche Unternehmen entsteht demgegenüber im Falle der Weiterentwicklung und Weiterverteilung von F/OS-Software die Gefahr einer Öffnung der bisher geheimen oder geschützten Wissensvorräte und damit eine mögliche Schwächung der eigenen Position im Konkurrenzkampf. Deshalb stellt sich von der einen Seite her die Frage, inwieweit öko-

5.2 Kapitalismus und F/OSS

183

nomische Interessen in der F/OS-Softwareentwicklung auftauchen, über welche Mechanismen sie in den Entwicklungsprozeß eingespeist werden und ob sich dadurch die Abgrenzungen verschieben, und von der anderen Seite, welche Rückwirkungen die offene Form des Umgangs mit Wissen auf die traditionell starke Geheimhaltungskultur der Unternehmen in Bezug auf Wissen hat?

5.2 Kapitalismus und F/OSS In der Diskursanalyse wurde die starke Abgrenzung der Techniker gegen Formen der Einmischung von außen in den technischen Entwicklungsprozeß herausgearbeitet. Im Folgenden soll nun der Umgang mit solchen Einﬂüssen, die angesichts der Zentralität der Informationstechnik für die Ökonomie selbstverständlich vorhanden sind, untersucht werden. In einem ersten Abschnitt wird beispielhaft der Umgang mit zwar unwillkommenen, aber eben technisch vorhandenen bzw. geplanten Hardwareneuerungen analysiert. Anschließend wird das Verhältnis der F/OS-Entwickler und der von Unternehmen getragenen »Open Source Development Labs« (OSDL) untersucht. Die Kooperationspraxen der Unternehmen, die ihr Geschäftsmodell direkt auf F/OS-Software aufbauen, bilden den Abschluß dieses Abschnittes. 5.2.1 Eine rein technische Entscheidung? Die F/OSS-Zusammenhänge können ihr Produkt natürlich nur entsprechend der Entwicklungen in anderen Bereichen der IT-Industrie herstellen. Das heißt, daß das Problem, für das eine Softwarelösung gesucht wird, oftmals kein selbst gestelltes ist, sondern eines, das sich aus den Strukturen der Computerindustrie und -verwendung ergibt. Die im Diskurs aufscheinende Abgrenzung bezieht sich also nicht so sehr auf das »Was« der Entwicklung, sondern vor allem auf das »Wie«. Ein Beispiel für diese Ausgrenzung der Frage nach der Problemstellung ﬁndet sich in der Diskussion auf der Linuxkernel-Mailingliste zum Thema »Digital Rights Management«. Gerade hier wird deutlich, wie wenig offensichtlich die Interessenskonstellationen sind, die letztendlich das

184

5 Ökonomie

»Was« der Entwicklung deﬁnieren.175 Folgendes Posting erschien am 23. April 2003 auf der Linux Kernelmailingliste: From Linus Torvalds <> Subject Flame Linus to a crisp! [...] I want to make it clear that DRM is perfectly ok with Linux! There, I’ve said it. I’m out of the closet. So bring it on...

Das Subject »Flame Linus to a crisp«, die Aufforderung den unumstrittenen Projektleiter knusprig zu braten mit vor Wut ﬂammenden E-Mails,176 kündigt ein heiß umstrittenes Thema an. Die problematische Aussage lautet: »Ich möchte klarstellen, daß DRM (Digital Rights Management) mit Linux absolut in Ordnung ist!« Die schwierige Aufgabe besteht also darin, das Verhältnis von Linux zu DRM, also die software- oder hardwarebasierten Zugangsund Verteilungsregelungen zu oder von digitalisierten Inhalten, klarzustellen. Unter dem Begriff »Digital Rights Management« werden verschiedene Verfahren zusammengefaßt, die eine technische Lösung der Sicherung des Eigentums an digitalen Informationsgütern beinhalten. Neben kryptographischen Lösungen, wie etwa dem sog. CSS für digitale Datenträger ,177 oder sogenannten digitalen Wasserzeichen ist ein wichtiges Konzept die Infrastruktur der »Trusted Systems«. Dabei 175 Daneben kann dieser Abschnitt auch gut zur Illustration der Aufgaben und der kommunikativen Leistung eines F/OS-Projektleiters dienen- Vgl. dazu auch Abschnitt 4.2.3. 176 Ein »ﬂame« ist eine wutentbrannte E-Mail. Solche sog. »ﬂame-Wars« sind keineswegs eine Seltenheit auf den Mailinglisten der F/OSS-Zusammenhänge. Vgl auch 4.1.3. 177 Dieses Verschlüsselungsverfahren erlangte einige Berühmtheit, weil es relativ schnell von einer Hackergruppe geknackt und ein entsprechendes Entschlüsselungprogramm (DeCSS) veröffentlicht wurde. Daraufhin wurden ein Urheber dieses Programmes und einige der Verteiler mit Klagen von Seiten der Filmindustrie überzogen. Von amerikanischen Gerichten wurde das Programm DeCSS verboten, woraufhin als Prozeßkostenhilfe unter anderem T-Shirts mit dem aufgedruckten Quelltext des Programmes verkauft wurden.

5.2 Kapitalismus und F/OSS

185

wird eine zentrale Instanz der Kontrolle geschaffen, die sicherstellen soll, »daß bestimmte Plattformen und Software das Konzept der Nutzungsrechte wahren und erzwingen.« (Grassmuck 2002: 137)178 Das wird ermöglicht durch Zertiﬁzierung von Hard- und Software, die verhindert, daß bestimmte Inhalte überhaupt auf einem Computersystem benutzt werden können. Eine Befürchtung, die in der an dieses Posting anschließenden Diskussion immer wieder geäußert wurde, ist, daß durch die Implementation solcher Mechanismen in die Hardware oder das BIOS bereits das Booten eines nicht von dieser Zentralinstanz autorisierten Betriebssystems verhindert, und damit Softwareentwicklung zumindest im Bereich der Betriebssysteme generell unmöglich wird. Die Aussage von Torvalds lautet nun, daß es absolut in Ordnung ist, DRM mit Linux zu durchzuführen oder es unter diesem Betriebssystem zu anzuwenden. Damit hat er die Entscheidung, daß in Bezug auf die weitere Entwicklung von Linux DRM eine Rolle spielen kann, getroffen und verkündet. Offen bleibt dabei, wer DRM und Linux zusammen bringt und wie das geschieht. Der Anlaß für diese öffentliche Stellungnahme sind einige private Diskussionen und die Erkenntnis, daß viele Leute (in beiden Fällen sind wohl Entwickler gemeint) Linux irgendwie benutzen möchten, um gegen DRM Stellung zu beziehen, sei es durch eine politische Entscheidung oder durch eine Änderung der Lizenz.179 Das heißt aber auch, daß nicht alle Leute das wollen, sondern daß es eine andere (kleinere?) Gruppe (von Entwicklern?) gibt, die DRM mit dem Kernel verwenden möchte. Es geht also nicht um eine Implementierung von DRM-Mechanismen im Linuxkernel selber, sondern nur um die Nutzung von DRM-Hardware und -Programmen unter dem Betriebssystem Linux. Torvalds verweist auf eine seiner Meinung nach ähnlichen Diskussion zu Softwarepatenten in der GPL-Newsgroup, in der die Lizenz gegen Softwarepatente eingesetzt werden soll.Und es sei wie 178 Für eine genauere Beschreibung der verschiedenen DRM-Techniken vgl. Grassmuck 2002: 130 - 162. 179 Eine solche gegen DRM gerichtete Änderung der Lizenz wird für die Version 3 der GNU GPL anvisiert, vgl. http://gplv3.fsf.org/. Die Begründung läuft eine Einschränkung der Benutzungsfreiheit in dem Fall hinaus, wenn die Benutzung der Software dazu dient, die von der Lizenz gewährten Benutzungsfreiheiten einzuschränken.

186

5 Ökonomie

in dieser Diskussion: persönlich mag Torvalds keine Softwarepatente, genauso wenig wie DRM, aber er fühlt das gleiche wie damals: »Ich bin ein ›Oppenheimer‹, und weigere mich Politik mit Linux zu spielen«.180 Die Identiﬁzierung erfolgt, wiederum wohl etwas ironisch, mit einem Wissenschaftler und Techniker, der maßgeblich an der Entwicklung einer gefährlichen Technologie beteiligt war. Er entwickelt verantwortlich eine Technik, möchte aber diese Technik aus der Politik heraushalten, nicht mit der Technik manipulieren oder Winkelzüge machen (»play politics«). Das unsichere und zerspaltene Gebiet der Politik soll gemieden werden, der Rückzug erfolgt in die klare Rationalität der Technik. Die Benutzung der Software, und damit verweist Torvalds auf die Lizenz, soll den Benutzenden freigestellt bleiben. Das bedeutet, daß es anscheinend auch eine Fraktion gibt, die den Kernel in einer DRMArchitektur, also etwa in bestimmten Versionen von einer zentralen Instanz zertiﬁziert und möglichst fälschungssicher signiert, mit dem Kernel nutzen will. Die getroffene Entscheidung ist also die, keine Entscheidung über die Benutzung des Kernels zu treffen. Ein durch die politische Verwendung des Betriebssystems heraufbeschworener Zwist zwischen den Entwicklern, oder gar ein fork, würde die einheitliche Entwicklung des Kernels gefährden.181 Argumentiert wird bisher vor allem auf einer emotionalen Ebene, mit Gefühlen, und mit dem Wunsch und der bisher eingehaltenen Grundregel, statt auf politische Rationalität auf die eindeutigere technische Rationalität zu setzen. Die Frage stellt sich, warum die Diskussion überhaupt losgetreten wurde und warum eine dermaßen positive Stellungnahme an den Beginn gestellt wird. In der sich auf dieses Posting entwickelnden Diskussion erläutert er seine Position noch einmal und kommt auf die Initiatoren dieser Diskussion zu sprechen:

180 Robert Oppenheimer war der Leiter des »Manhattan«-Projekts zur Entwicklung der Atombombe, der allerdings, nachdem er die Folgen der beiden ersten Atombomben realisierte, stark für eine Kontrolle der Nukleartechnologie und gegen den Bau der Wasserstoffbombe einsetzte. Dieser Einsatz war jedoch erfolglos. 181 Aus dieser kurzen Passage werden wiederum die kommunikativen Aufgaben der Projektleitung deutlich: Entscheidungen treffen und begründen, Regeln reproduzieren und nicht zuletzt die Einheit des Projektes wahren.

5.2 Kapitalismus und F/OSS

187

Date Wed, 23 Apr 2003 22:43:37 -0700 (PDT) From Linus Torvalds <> Subject Re: Flame Linus to a crisp! On Wed, 23 Apr 2003, William Lee Irwin III wrote: I suspect that almost all of us would rather have unlimited feeds, and just take it on trust that people would do the right thing. But I can understand why especially embedded Linux users may want to control these things - and maybe my moral sense is lacking, but I just can’t see myself saying "no, you can’t use Linux for that".

Also sind es vor allem die Anwender von »Embedded Linux«182 , die ein Interesse an DRM haben. Nahezu alle Entwicklungsbeiträge in diesem Bereich (Echtzeitfähigkeit, Portierung auf speziﬁsche Hardware, Reduzierung von Speicherbedarf, spezielle Energiesparfunktionen etc.) kommen von Unternehmen, die solche Geräte produzieren (vgl. dazu Henkel 2003). Es handelt sich also um ein speziﬁsches ökonomisches Interesse, und von dieser Verwertungsperspektive her ist der Wunsch der Unternehmen auch verständlich. Wenn sie die mit Linux betriebenen Mikrochips und Steuerelemente in Geräten verwenden wollen, die digitale Inhalte wiedergeben können, also etwa DVD-Player, muß es die Möglichkeit geben, bestimmte Varianten von Linux zu zertiﬁzieren. Denn wenn DRM sich durchsetzt, dann zuerst auf solchen spezialisierten Abspielgeräten. Damit wird die Motivation der Diskussion klar. Es geht nicht darum, ob DRM-Code in den Linuxkernel integriert wird,183 sondern es geht 182 Wenn Linux als Betriebssystem nicht in vielseitig verwendbaren Computern wie PCs eingesetzt wird, sondern speziﬁsch auf spezialisierte Mikrochips für den Einsatz in zweckbestimmten Geräten zugeschnitten wird, wie etwa Video- oder DVDRecorder, Messgeräte oder Maschinensteuerungen. 183 Was übrigens mit der Kernelversion 2.6.12 im Juni 2005 geschehen ist. Seitdem sind Treiber für diverse sog. »Trusted Platform Module«, entwickelt von Mitarbeitern der Firma IBM, in Linux enthalten. Es gab keine weitere Diskussion um die Aufnahme dieses Codes. Ein solches TPM selbst stellt noch keine direkte Verwendung von DRM über eine zentralisierte Instanz dar. Allerdings ist das Potential dafür gegeben:

188

5 Ökonomie

um den Hinweis an die Entwickler, wozu ihr Code von Dritten verwendet werden kann. Die Interessen der Unternehmen, die Linux für »Embedded Devices« auch mit DRM einsetzen wollen und in diesem Bereich weiterentwickeln, werden von Torvalds anerkannt, auch wenn er persönlich, und eine größere Gruppe von F/OS-Entwicklern mit ihm, nichts von DRM hält. Von privatwirtschaftlicher Seite an die F/OS-Entwicklernetzwerke herangetragene Bedürfnisse werden also auch erfüllt, wenn ein (größerer?) Teil der Entwickler aufgrund von politischen, ethischen oder ideologischen Überlegungen dagegen ist. Die Frage auf die sich die technische Rationalität kapriziert, ist nicht, was entwickelt wird, sondern wie. Gerade die Berufung auf diesen Grundkonsens und auf die grundlegende rechtliche Bestimmung der Benutzungsfreiheit in der Lizenz184 macht den fundamentalen Charakter dieser Nicht-Entscheidung deutlich. Damit wird die gezogene Grenze zu politischen oder ökonomischen Interessen insoweit reproduziert, als diesen Bereichen eine Entscheidung über die Benutzung (und eine Implementation von bestimmten Features) überlassen wird, solange das »technisch beste Betriebssystem« dabei herauskommt, seine möglichst weite Verbreitung und die Einheit der entwickelnden Programmierer gesichert sind. Zentral bleibt die Selbstbestimmung in technischer Hinsicht und diese Abgrenzung ist durch DRM nicht gefährdet. Wenn diese Grenze anerkannt wird, ist eine Richtungsänderung oder Erweiterung der Entwicklung möglich.

»The TPM is a microcontroller that stores keys, passwords and digital certiﬁcates. It typically is afﬁxed to the motherboard of a PC. [. . .] The nature of this silicon ensures that the information stored there is made more secure from external software attack and physical theft. [. . .] Access to data and secrets in a platform could be denied if the boot sequence is not as expected.« (https://www.trustedcomputinggroup.org/ faq/TPMFAQ/ Ein solcher Hardwarechip kann dem Schutz der Computernutzenden vor Viren, Paßwortänderung etc. dienen und er kann zur Kontrolle der Benutzung des Rechners selbst verwendet werden, etwa wenn gespeicherte Schlüssel nur die Benutzung bestimmter Informationsgüter erlauben. 184 Vgl. dazu auch die Diskussionen um die dritte Fassung der GPL, mit der die Nutzung von DRM verhindert werden soll. Diese Diskussionen fokussieren unter anderem auf einem linuxbasierten digitalen Videorekorder mit DRM-Technologie vgl. http: //www.heise.de/open/artikel/87628.

5.2 Kapitalismus und F/OSS

189

5.2.2 OSDL Diese Empfänglichkeit der F/OS-Zusammenhänge für solche »geleitenden Umarmungen«, wie sie besonders in der neoliberalen Open Source-Semantik (vgl. Abschnitt 3.4) propagiert wurde und wird, legt institutionalisierte Formen der Einﬂußnahme auf die Softwareentwicklung nahe. Eine solche Form stellen die sog. OSDL (»Open Source Development Labs«) dar. Diese in Portland, Oregon räumlich verortete Institution wurde im Jahr 2000 gegründet als eine Non-Proﬁt-Organisation zur Förderung des Betriebssystemes Linux. Die OSDL sind ein Zusammenschluß von Unternehmen der IT-Branche (u. a. Alcatel, AMD, Computer Associates, Cisco, Ericsson, Fujitsu, Google, Hitachi, Hewlett Packard, IBM, Intel, MontaVista, Nokia, Novell, Red Hat, Siemens, SUN, Toshiba, Trolltech, Unilever und VA Software) »dedicated to creating feature roadmaps, speciﬁcations, and participating in open source projects to further develop Linux for use in telecommunications architectures, data centers, and on enterprise desktops.«185 Das Ziel ist klar: (vor allem) Linux soll für alle Beteiligten (und das sind wichtige Größen der ITIndustrie) gemäß den gemeinsamen Interessen weiterentwickelt werden. Um diese gemeinsamen Interessen zu deﬁnieren, gibt es sog. »Working Groups« und »Special Interest Groups«. Die Verteilung der Sitze in den entsprechenden Gremien ist abhängig vom ﬁnanziellen Beitrag der jeweiligen Firma zu den OSDL, also eine plutokratische Organisation. Mit diesen »feature roadmaps« wird gerade nicht versucht, auf die Art und Weise der technischen Umsetzung Einﬂuß zu nehmen, sondern nur eine Liste von Problemen aufgestellt, die, das legt die Linearität des Begriffes nahe, in einer bestimmten Reihenfolge abgearbeitet werden sollen. Die OSDL, »sponsor of Linus Torvalds, the creator of the Linux kernel« (so in jeder Pressemitteilung zu lesen), ﬁnanzieren aus diesen Beiträgen unter anderem eine Hardwareausstattung, mit der gewährleistet werden soll, daß die Software auf den verschiedensten Hardwarearchitekturen getestet werden kann und lauffähig ist. Außerdem sind einige prominente Entwickler aus den F/OS-Zusammenhängen hier angestellt. An prominentester Stelle Linus Torvalds selbst (seit Juni 185

http://groups.osdl.org/workgroups.

190

5 Ökonomie

2003), sowie der wichtige Linuxkernelentwickler Andrew Morton (seit Juli 2003) und Andrew Tridgell (Januar 2005 bis Februar 2006, seither wieder bei IBM), einer der führenden Entwickler des Programmes samba, das eine Vernetzung von Windows und Linux/Unix-Rechnern auf Basis des Netzwerkprotokolls von Windows ermöglicht. Daß die Zusammenarbeit der OSDL mit den F/OS-Zusammenhängen bisher problemlos verlief, kann nicht behauptet werden. Ein wichtiger Entwickler des Linuxkernels, Greg Kroah-Hartmann, gibt in einem Eintrag in seinem Weblog vom 15. September 2005 der anscheinend schon länger bestehenden Unzufriedenheit schriftlichen Ausdruck. Diese Unzufriedenheit hat sich bisher wohl eher ›hinter vorgehaltener Hand‹ und auf den Kernelkonferenzen geäußert. Der Blogeintrag verweist zum einen auf ein kürzlich stattgefunden habendes Treffen mit dem OSDL-Management und die Entwicklung eines Positionspapieres durch die Entwickler. Am 3. November wird die Unzufriedenheit unter der Übeschrift »OSDL and a binary kernel driver layer« (http://www.kroah.com/log/linux/osdl_gkai.html) zumindest in einem Punkt konkretisiert, in Bezug auf binäre Treiber für den Linuxkernel: »[. . .] Case in point, a number of months ago, OSDL’s director of engineering posted this public message, asking for help with a ›Generic Kernel API‹ that would somehow provide a ›stable kernel api‹ for companies to use. [. . .] So, for the head of OSDL’s Engineering group to say: I’m concerned that the current process doesn’t scale, namely that the community will always update open source drivers when an internal kernel changes break them. As more and more drivers are open-sourced, this becomes a larger and larger effort. shows a great disconnect as to their understanding of how the Linux kernel is developed and maintained over time (hint, the process scales very well, better than anything anyone has ever done before.) Anyway, people outside of OSDL responded properly in that E-Mail thread, showing the error of their ways, and why this was both not a

5.2 Kapitalismus und F/OSS

191

good thing, and that proposing this on some odd, remote OSDL speciﬁc mailing list was not the place to discuss it (it should be done in public, on the linux-kernel mailing list.) I thought this was the end of this proposal. I was wrong.« (http://www.kroah.com/log/linux/osdl_01.html) Unter dem anscheinenden Vorwand, daß die Pﬂege der vielen Treiber zu viel Aufwand für die freien Entwickler sei, hatte der technische Direktor der ODSL eine »stabile Kernelschnittstelle« (API) für Unternehmen gefordert, also eine standardisierte Schnittstelle, über die Unternehmen Software für den Linuxkernel schreiben können (vor allem Treiber für verschiedene Hardwarekomponenten), ohne diese bei Änderungen im Kernel ständig mit ändern zu müssen. Der zu hohe Aufwand liegt also weniger auf Seiten der freien Programmierer, was Kroah-Hartmann auch ziemlich empört von sich weist, sondern auf Seiten der Unternehmen, die ihren Aufwand durch eine stabile Schnittstelle reduzieren möchten. Den Weg, die Software quelloffen in den Kernel zu integrieren und die Wartung und Anpassung den Entwicklern zu überlassen, möchten sie anscheinend nicht gehen. Damit soll in den Treibern inkorporierte Wissen um die Hardware vor der Konkurrenz geschützt werden, aber damit wird auch aus dem Pool der selbstbestimmten Entwickler ausgeschlossen. Trotz der Zurückweisung dieser ersten Offerte wird der Vorschlag wieder auf den Tisch gebracht, und zwar von »3 Japanese members« der OSDL, nämlich »Fujitsu, NEC and Hitachi«, die diese Weigerung, stabile Schnittstelle im Kernel zu schaffen, nicht verstehen. Kroah-Hartmann bekommt eine Präsentation dieser Firmen zugeschickt, die er im Folgenden zitiert: »It gets worse... I got a copy of the proposal, and it contains this lovely slide in the section about ›vendor advantages‹: ›1. No need to be available publicly for the driver. (They can distribute it as closed source software.)‹

192

5 Ökonomie Yes, you got that right, OSDL Japan wants a stable kernel api layer so they can write binary only kernel drivers, which are just so illegal it’s not even funny. The fact that OSDL’s management doesn’t seem to understand this, makes me really worry about how well they even comprehend the legal issues behind the GPL, the kernel, and how the kernel developers feel about this topic.« (http://www.kroah.com/log/linux/osdl_gkai.html)

Vorgeschlagen wird eine dauerhafte technische Änderung, eine stabile Schnittstelle, um rein binäre Treiber angliedern zu können. Der Entwickler ist empört über die Ignoranz der OSDL, in deren Gremien die elementaren rechtlichen und moralischen Grundsätze der Kernelentwickler nicht verstanden worden sind. Gerade die Kombination eines, noch dazu fragwürdigen, technischen Vorschlages186 , also ein Eingriff in die zentrale Sphäre der Autonomie, mit einer lizenzrechtlich illegalen bringt ihn auf die Palme. Die Interpretation, daß alle rein binären Treiber illegal sind, wird so nicht von allen Entwicklern geteilt. Torvalds etwa verweist auf eine Grauzone in der GPL, den Ausdruck »abgeleitete Arbeit«. Demnach muß Software, die von unter der GPL-Lizenz stehender Software abgeleitet ist, selbst wieder unter der GPL stehen (der sogenannte »virale« Effekt, vgl. Abschnitt 3.2.3). Inwieweit Treiber für speziﬁsche Hardware unter diese Klausel fallen, ist unsicher.187 Seine auf die Mitteilungen des OSDL gestützten Vermutungen erweisen sich jedoch nicht als richtig, weswegen er nach dem Treffen mit den japanischen OSDL-Vertretern noch unzufriedener mit dem OSDL ist: »OSDL’s technical management did not provide full disclosure to me about what the situation was going into the meeting. [. . .] They depended on me, and another non-OSDL kernel developer to tell the Japan members what the error 186 Für die technische Argumentation gegen eine stabile Kernelschnittstelle vgl. http: //www.kroah.com/log/linux/stable_api_nonsense.html. 187 Vgl. dazu die Mails von Torvalds (http://lkml.org/lkml/2003/12/3/228) und Alan Cox (http://lkml.org/lkml/2005/11/3/55) zu diesem Thema.

5.2 Kapitalismus und F/OSS

193

of their thinking was, instead of doing it themselves, hence wasting the Japan member’s time, as well as making the kernel community look like a bunch of heavy-handed people. I do not want to deal with OSDL’s technical management again after what happened here.« Trotz dieses Mißverständnisses oder dieser Fehlinformation: die vermutete direkte Einmischung in den technischen Bereich kombiniert mit einem lizenzrechtlich zumindest fragwürdigen und dem grundlegenden Konsens der Entwickler diametral entgegengesetzten Ansinnen, führt zu einer glatten Absage an diese Unternehmen und an ähnliche Bestrebungen. Um seine Ansicht zu unterstreichen, schickt er am 21. 11. 2005 einen aufsehenerregenden Patch an die Linuxkernel-Mailingliste, der nur Treibermodule zuläßt, die unter der GPL-Lizenz stehen.188 »But, what if this patch really did go in? Who would be affected by this? Nothing that is currently in the kernel.org kernel tree, right, so what’s the big deal? Oh yeah, very large companies rely on them right now, and are working on creating more and more closed source drivers. Why? Don’t they know that their legal departments do not agree with this? Are they approaching Linux development in the same way they used to with the old Unix systems, i.e. fork and ›add value‹? Well, consider this a warning shot for anyone who is relying on closed source modules. What you are doing is trying to take from Linux and not give anything back. The GPL explicitly forbids this, and Linux would not be good enough today for you to be using it without that protection. If you, or your company is relying on closed source kernel modules, your days are numbered. And what are you going to do, and how are you going to explain things to your bosses and your customers, if possibly, something like this patch were to be accepted?« 188 Vgl. die Diskussion zur Mail http://lkml.org/lkml/2005/11/21/352.

194

5 Ökonomie

Diese Reaktion und die Diskussion, die daran anschließt, zeigen, daß es Bereiche in der Entwicklung gibt, die sehr sensibel sind gegenüber einer Einﬂußnahme. Im thread auf der Mailingliste wird Verständnis für einige Firmen geäußert, die aufgrund der harten gegenseitigen Konkurrenz ihre Treiber für Linux nur in Binärform veröffentlichen, um möglichst viel des eigenen Wissens zu schützen. Dieses Verständnis zusammen mit dem Wunsch, Linux so weit wie möglich zu verbreiten, hat wohl zur Öffnung der rechtlichen Grauzone der binären Treiber geführt. Die Kommentare zur stabilen Kernelschnittstelle und zu dem vorgeschlagenen »fun patch« zeigen jedoch, daß sich die Entwickler dieser Grauzone durchaus bewußt sind, und es starke Bestrebungen gibt, diese Bresche zu schließen. Nicht zuletzt wird ein Bereich der problematischen Zusammenarbeit von Entwicklerzusammenhängen und OSDL deutlich: auf Seiten der ökonomischen Institution fehlt es an Verständnis für die Entwickler und ihre sozialen und kulturellen Grundlagen. Deshalb kommt es auf Initiative der Entwickler im Januar 2006 zu einem Treffen mit dem OSDL-Vorstand. Kroah-Hartmann veröffentlicht ein Art Protokoll dieses Treffens in seinem Weblog. Die Vorschläge sind aufgeteilt in Hilfen für die Unternehmen, die mit F/OS-Software arbeiten und Hilfen für die Entwickler und die Entwicklung. Die ersten Punkte betreffen die Frage inwieweit den Programmierern neue Hardware zur Verfügung gestellt wird, so daß sie mit der Marktreife dieser Geräte auch die passenden Treiber zur Verfügung stellen können. Die Entwickler schlagen die Gründung einer Organisation vor, die gegen Non-Disclosure-Agreements die Speziﬁkationen zur Verfügung gestellt bekommt und sie an die entsprechenden Entwickler weiterleiten kann. Inwieweit eine solche Politik eine bessere Chance hat oder hätte, die Geheimhaltungsstrategien der Firmen zu überwinden, muß offen bleiben. In Bezug auf das Verhältnis zu Unternehmen wird von den Entwicklern auch eine »training conference« für von Unternehmen beschäftigte Kernelentwickler, um zum einen die Mechanismen der F/OSS deutlich zu machen und zum anderen »[to] allow vendor developers to meet directly with the kernel developers to help ease any tension that might occur over email« (http://www.kroah.com/log/2006/01/26/). Des weiteren soll der Zweck einer solchen Konferenz auch sein, den Unternehmen klar

5.2 Kapitalismus und F/OSS

195

zu machen, daß es nicht angeht, Forderungen zu stellen: »Code and ideas that are implemented are how to control and modify Linux, not providing a speciﬁcation and telling other people to go follow it.« (ebd.) Die F/OS-Entwicklern akzeptieren als direkte Einﬂußnahme auf den Gang der Entwicklung nur Programmcode (oder implementierte Ideen), die sie dann entsprechend ihrer Praxis testen und entsprechend aufnehmen oder verwerfen können. In einem zweiten Teil werden Hilfestellungen der OSDL für die Entwicklung von Linux vorgeschlagen. So etwa die Beschäftigung eines Angestellten, der die technische Dokumentation für den Linuxkernel erledigt, eine Ausweitung des »Fellowship Program«, also der temporären Finanzierung von Entwicklern durch das OSDL für einige problematische Bereiche des Kernels vorgeschlagen, die Einrichtung eines Fonds für Reisekostenzuschüsse, die Verbesserung der Kommunikation der Entwickler mit Linuxbenutzergruppen (um den Entwicklernachwuchs zu sichern) und schließlich die Ausrichtung von mehr Konferenzen. Ein dritter Teil der Vorschläge richtet sich auf die organisationelle Einbindung der F/OS-Entwickler in die OSDL. So wird vorgeschlagen eine Art technischen Ausschuß einzurichten und in den Vorstand ein von den Entwicklern gewählten Vertreter mit aufzunehmen. Diese Vorschläge zeigen die für die Entwickler relevanten Probleme: die Kommunikation mit Unternehmen, bzw. mit für Unternehmen arbeitende Programmierer, scheint generell unter einigen substantiellen Mißverständnissen und kulturellen Übersetzungsproblemen zu leiden. Auf Seiten der F/OS-Entwickler ist jedoch eine große Bereitschaft zur Zusammenarbeit vorhanden, die sich nicht zuletzt in der Bereitschaft zu einer »training conference« zeigen. Denn die Bedingungen der Zusammenarbeit werden von den freien Entwicklern formuliert: keine Forderungen, sondern Integration in den und Beteiligung am Entwicklungsprozeß. Unter diesen Bedingungen ist der Einﬂuß sogar erwünscht, weil er das Ziel, die technisch beste Software zu schreiben, nur befördern kann. Wieder wird deutlich, daß nicht die inhaltliche Ausrichtung des Entwicklungsprozesses sondern sein Ablauf entscheidend ist, nicht das ›Was‹, sondern das ›Wie‹. Die Reproduktion einer bestimmten Kultur der Entwicklung, ihrer fundamentalen Normen und Regeln erweist sich als conditio sine qua non der Zusammenarbeit mit privatwirtschaftlichen Organisationen in der Softwareentwick-

196

5 Ökonomie

lung. Wenn diese aber anerkannt wird, schwinden Berührungs- und Kooperationsängste auf Seiten der autonomen Entwickler. 5.2.3 Ein F/OS-Unternehmen Erfahrener im Umgang mit den eigenwilligen Entwicklernetzwerken sind die auf die Verwertung der F/OS-Software spezialisierten Unternehmen, weil diese Firmen zum einen aus diesen Zusammenhängen heraus gegründet wurden, weil sie viele F/OS-Entwickler beschäftigen und schließlich weil sie intensiver als andere Firmen auf eine funktionierende Kooperation mit den freien Entwicklern angewiesen sind. Ein Geschäftsmodell dieser Firmen, beispielhaft seien etwas Red Hat, Novell/SuSE, Connectiva oder Canonica genannt, basiert darauf, daß sie Dienstleistungen rund um die F/OS-Software anbieten. Das reicht von der Zusammenstellung und Vorkonﬁguration der verschiedenen einzelnen Programme zu einem funktionierenden Softwaresystem, eine sogenannte Distribution, bis hin zur Installation, Anpassung, Wartung und Schulung auf Grundlage dieser Software. Was das Geschäftsmodell von dem herkömmlicher Softwareﬁrmen unterscheidet, ist der Verzicht auf Lizenzgebühren für die Programme selbst. Für erbrachte Leistungen, die Distribution, die Anpassung und Wartung oder die dafür produzierte Dokumentation wird aber durchaus Geld verlangt. Ein anderes Geschäftsmodell ist die starke Beteiligung an der Produktion eines F/OS-Programmes, das dann in den üblichen Distributionskanälen zur Verfügung steht, das jedoch auch auf dem Markt mit Zusatzfunktionen, also etwa besseren Kontrollfunktionen oder erweiterten Möglichkeiten und natürlich entsprechenden Dienstleistungen zum Kauf angeboten wird. Beispiele dafür sind etwa das Datenbankunternehmen MySQL AB oder das auf Mail-Software spezialisierte Unternehmen Sendmail Inc. Das oberste Ziel in beiden Geschäftsmodellen ist klar: »Eine Firma hat da, hat bei all=über allem steht nach wie vor, das Ziel: wir sind ein Wirtschaftsunternehmen, wir wollen müssen Gewinn erzielen für unsere Eigentümer. Das is das, worum’s uns geht.« (E6, Z. 486 ff.)189 189 E6 ist nach seiner Beteiligung an der F/OSS jetzt Manager in einem F/OS-

5.2 Kapitalismus und F/OSS

197

Da Dienstleistungen rund um die F/OS-Software das zentrale Leistungsmerkmal der F/OS-Unternehmen ist, und die Kunden vor allem staatliche Institutionen und privatwirtschaftliche Unternehmen aus den verschiedensten Branchen sind, fungieren die F/OS-Unternehmen sozusagen an einer Schnittstelle zwischen den Großkunden und den Entwicklerzusammenhängen. Damit nehmen sie auch einen entsprechenden Anteil an Übersetzungsaufgaben zwischen diesen Bereichen wahr. Auf der einen Seite kommunizieren sie die Existenz der F/OSSoftware in die Geschäftswelt, auf der anderen Seite tragen sie die Anpassungs- und Änderungswünsche, aber auch Fehlermeldungen oder Problemlösungen der Kunden in die Projekte zurück. Code Der einzige Unterschied zu anderen Softwareﬁrmen ist, daß der Großteil oder zumindest ein größerer Teil des Programmcodes eben nicht im Unternehmen selbst geschrieben, sondern kostenneutral von F/OSServern geholt wird. Dieses frei erhältliche Wissen muß dann für die Verwertung noch aufbereitet werden. Gleichzeitig muß aber die Beziehung zu den F/OS-Projekten und Entwicklern gepﬂegt werden. Das geschieht normalerweise auf Grundlage der jeweils gültigen Lizenz. »Ich nehme ein Stück Code aus dem Internet, ich bastel daran rum. Dann muß ich gemäß der Lizenz ähm in vielen Fällen hergehen, und den Patch, den ich dann gemacht habe auch wieder verfügbar machen, ich muß es ihm nicht zurückgeben, dem Menschen, aber der’s geschr=ich muß es zumindest irgendwo verfügbar machen. Der gute Ton isses jetzt, daß ich den Patch eigentlich dem Menschen zurückschicke. Daß er’s dann meistens einbaut. weil es hilft ihm ja auch, wenn’s ein bischen besser geht. So dass=da sind wir sehr aktiv, alle Patches die wir haben schicken wir quasi zu dem Maintainer wieder zurück. Sag=kuck mal hier, und dann hast Du das wieder und so weiter. Uund dann möchte ich=äh=das is=dadurch nehmen wir natürlich indirekt schon Einﬂuß und zwar deutlichen Einﬂuß darauf.« (E6, Z. 144 ff.) Unternehmen.

198

5 Ökonomie

Das ist die übliche Form der Einﬂußnahme. Ein Programm wird verbessert und die Verbesserung, der sog. Patch, wieder an das F/OSProjekt zurückgeschickt. Insofern funktioniert die Beteiligung des F/OS-Unternehmens so wie die jedes anderen Programmierers auch. Dabei ist das Lizenzrecht nur eine Seite der Medaille. Es gibt schließlich auch Lizenzen, die keineswegs fordern, die Verbesserungen zugänglich zu machen (etwa die BSD-artigen Lizenzen). » Ich schick sie einfach dem=dem Originalautor, weil ich dann in Zukunft ja weniger Arbeit hab. Wenn der des aufnimmt, muß ich’s beim nächsten Mal ja nicht wieder machen.« (E6, Z. 166 ff.) Hinter der Rückgabe des Codes steckt also vor allem das Interesse die einmal vollzogene Verbesserung in den nächsten Produktuzyklen erneut anbringen und eventuell an die dann veränderte Version des Programmes anpassen zu müssen. Wenn der Patch akzeptiert und in das F/OS-Projekt aufgenommen wird, erledigen diese Anpassungen die freien Entwickler.190 Die direkte Beisteuerung von Programmcode oder Fehlermeldungen ist ein Weg, auf dem F/OS-Unternehmen die Beziehung zu ihren ›Lieferanten‹ pﬂegen. Sie integrieren sich so über die ﬁrmenintern mit dem jeweiligen Programm befaßten Programmierer in den F/OSProduktionsprozeß. Sponsoring Andere Wege der Einﬂußnahme sind die vielfältigen Möglichkeiten des Sponsoring. Zum einen die befristete Finanzierung eines (oder mehrerer) Entwickler, die in der Zeit eine bestimmte Aufgabe erledigen sollen: »Ok, hier paß auf, Du darfst jetzt mal, hier, kriegst Geld, kannst ’n halbes Jahr Vollzeit daran arbeiten, oder so was .. Einige Dich mit Deinem jetzigen Arbeitgeber, wie Du das machst. Uund das is also die verbreitetste Form des Sponsoring.« (E6, Z. 334 ff.) 190 Vgl. dazu die Diskussion um eine stabile API 5.2.2.

5.2 Kapitalismus und F/OSS

199

Diese Form funktioniert entweder so, daß ein Projekt an das Unternehmen herantritt und um Unterstützung bittet, oder, wohl häuﬁger, auf Veranlassung des Unternehmens, das ein neues Feature haben im Programm haben will: »Daß wir sagen, gut, ähm unser Produkt braucht ein tolles Feature, also [. . .] waren wir der Meinung, daß wir unheimlich dringend sollten wir DVDs schreiben können. Es gibt jetzt irgendwelche DVD-Schreiber und dann haben wir uns halt jemanden gesucht, also des g’bt dann ein Brennerprojekt, wo man ganz toll DVDs schreiben kann, und da ham wir halt mit den Menschen, die überzeugt davon, paß auf jetzt mach mal drei Monate Vollzeit, und dann programmier uns mal diese und jene Sachen da rein. ’tür’ch alles in der Open Source-Welt und alles offen, nich’dass dann nur wir haben, aber das is ein Feature, das wollen wir halt haben.« (E6, Z. 341 ff.) Mit dieser Art von Werkvertrag schafft sich das Unternehmen die gewünschten Änderungen und neuen Funktionen. Diese Art der Einﬂußnahme wird in den Entwicklerkreisen nicht ungern gesehen, wie die oben zitierte Forderung der OSDL-Kritiker nach solcher befristeter Finanzierung für bestimmte Aufgaben zeigt. Eine andere Form des Sponsoring sind Zuschüsse zu Konferenzen oder Workshops für bestimmte Projekte. Wichtiger sind allerdings Hardware- oder Webspacespenden, die zum einen die Anpassung an neue Hardware ermöglichen und vor allem die für die Produktion und den Verteilungsmechanismus notwendigen ftp- und cvs-Server mit den notwendigen Bandbreiten zur Verfügung stellen. Diese oder ähnliche Formen des Sponsoring sind von den F/OSS-Zusammenhängen akzeptierte Formen des Eingriffs. Im Falle einer solchen direkten pekuniären Gegenleistung kann dann auch eine klare inhaltlich bestimmte Forderung gestellt werden, die, »’tür’ch alles in der Open Source-Welt«, nach den eigenen Maßstäben umgesetzt wird. Arbeitsmarkt Eine weitere enge Verbindung zwischen den F/OS-Unternehmen und den Projekten stellt der Arbeitsmarkt dar. Beide Seiten sind aneinander

200

5 Ökonomie

als Arbeitskräfte bzw. als Arbeitsplatzgeber interessiert. Wobei das Interesse der F/OS-Unternehmen seit dem Ende des New EconomyBooms und dem damit einhergehenden Überangebots an Programmierern weniger stark ist als das der autonomen Entwickler, wie E6 verdeutlicht: »Das=das kommt drauf an. Das is eigentlich die Zeit, daß so was [aktive Anwerbung von Arbeitskräften durch das Unternehmen in den F/OS-Netzen selbst] passiert, is eigentlich=is eigentlich relativ vorbei. Das war so 99 und 2000, daß man das gemacht hat. ’nd eigentlich seit 2001 tut das kaum mehr jemand. [. . .] Wobei des häuﬁch auch sehr reaktiv is, es kommen ganz viele Leute auf uns zu und sagen, sie möchten gerne für uns arbeiten, und ob wir nicht was haben. Dann überlegen wir uns, ob wir des haben oder nicht.« (E6, Z. 304 ff.) Für die Entwickler bedeutet das, daß sie Hobby und Beruf zumindest etwas miteinander verbinden können. Entprechend zahlreich sind die Anfragen bei den auf F/OS-Software spezialisierten Unternehmen. Die Tätigkeiten haben zwar meist nicht direkt mit dem eigenen Projekt zu tun, aber immerhin bieten sie die Möglichkeit einer Erwerbsarbeit im bevorzugten Tätigkeitsbereich. Zudem ist es in der Regel so, daß zumindest ein Teil der Kommunikation mit dem ›eigenen‹ Projekt während der regulären Arbeitszeit erledigt werden kann. Programmieren für das Projekt bleibt jedoch die Ausnahme. Schließlich ist der Gewinn das hauptsächliche Ziel des Unternehmens. Auf der anderen Seite sind natürlich auch die F/OS-Unternehmen an Arbeitskräften aus den Projekten interessiert. Zum einen weil damit für die Firma zentrales Wissen gewonnen wird, nicht in Bezug auf die Programmierung allgemein (das ist auch am regulären Arbeitsmarkt vorhanden), sondern in Bezug auf die F/OS-Programme, an denen die angestellten Programmierer jeweils beteiligt sind und nicht zuletzt in Bezug auf Regeln und Abläufe in F/OS-Projekten. Im Falle der Erstellung und Verwertung einer F/OS-Distribution etwa ist der Arbeitsablauf so organisiert, daß die angestellten Programmierer für bestimmte Programme und deren Integration in das Gesamtkonzept

5.2 Kapitalismus und F/OSS

201

verantwortlich sind. Diese sogenannten »Maintainer« sind damit für die Kommunikation des Unternehmens mit dem jeweiligen F/OS-Projekt zuständig. Gerade weil die F/OS-Unternehmen an der Schnittstelle zwischen den Anwendern aus Ökonomie und staatlichen Stellen und den F/OSProjekten stehen, nehmen sie eine wichtige Übersetzungsfunktion ein. Sie geben Änderungs- und Anpassungswünsche entweder direkt in Form von Code oder über Sponsoring an die Projekte weiter. Und sie tragen wesentlich zur Verbreitung der F/OS-Programme bei, weil sie vorkonﬁgurierte und aufeinander abgestimmte Programmpakete zur Verfügung stellen, die auch für Nichtprogrammierer benutzbar sind. 5.2.4 Eingriffsmöglichkeiten für Unternehmen Es bestehen also vielfältige Eingriffsmöglichkeiten für Unternehmen in den Entwicklungsprozeß der F/OS-Software. Dabei müssen allerdings die speziellen kulturellen Bedingungen in diesen Projekten berücksichtigt werden, wie der Fall der stabilen Linux-Treiberschnittstelle zeigt. Die Entwickler lassen sich nicht direkt in die technische Umsetzung hineinreden, sie wollen ihre Eigenständigkeit und ihren freien und nicht auf Verwertung ausgerichteten Umgang mit dem in Software expliziertem Wissen respektiert sehen. Und sie bestehen auf der Sicherung ihrer Arbeitsgrundlage, des frei zugänglichen Wissensvorrats. Soweit bisher zu sehen ist, gelingt es also den F/OS-Entwicklern ihre selbstbestimmte Produktionsform erfolgreich gegen diese Eingriffe abzugrenzen und sich damit ihre Eigenständigkeit in einem kapitalistischen Umfeld zu sichern. Solange diese Eigenständigkeit anerkannt wird, begrüßen sie Kooperationen mit und Beteiligung von Unternehmen am Entwicklungsprozeß durchaus, weil für sie auch entsprechende Vorteile dabei herausspringen. Die Finanzierung oder Bereitstellung der technischen Infrastruktur, Zuschüsse für Konferenzen und nicht zuletzt mögliche Arbeitsplätze winken den Entwicklern. Zudem wird durch die Verbreitung der Entwicklungsprozeß stabilisiert. Die Unternehmen oder staatlichen Anwender von F/OS-Software bekommen auf der anderen Seiten von Lizenzgebühren freie Software, die inzwischen in den meisten Fällen kommerzieller Software qualitativ

202

5 Ökonomie

gleichwertig, zum Teil sogar überlegen ist.191 Eine wichtige Brückenfunktion zwischen F/OSS auf der einen und Privatwirtschaft und staatlichen Stellen auf der anderen Seite nehmen dabei die F/OS-Unternehmen ein. Vor allem über diese Schiene kommen die Anforderungen des Marktes in die F/OSS und F/OS-Software auf den Markt bzw. zu den Anwendenden.

5.3 Reperkussionen in der Ökonomie Die eben geschilderte Richtung der Einﬂußnahme ist klar und einleuchtend. Wie sieht es aber mit Einﬂüssen der F/OSS auf die kapitalistische Ökonomie aus? Gibt es auch Rückwirkungen auf den Kapitalismus? Zeigen sich Änderungen im Umgang mit dem für die Verwertung relevanten Wissen? Diese Veränderungen beﬁnden sich beﬁnden sich angesichts der Kürze der Wechselwirkungszeit sicherlich erst in einem Anfangsstadium, sind aber nichtsdestotrotz bereits beispielhaft wahrzunehmen und sollen im Folgenden anhand von Beispielen kurz beleuchtet werden. Auffällig sind dabei die Praktiken der Freigabe von unternehmenseigenem Quellcode, neue Formen der kooperativen Umgangs mit Wissen und die Veränderung der Beziehung zu Kunden. Freigabe des Quellcodes Auffällig ist, daß es seit dem Beginn des Jahres 1998 eine steigende Zahl von Firmen gibt, die den vorher streng gehüteten Quellcode unternehmenseigener Programme freigegeben haben und die diese Software mehr oder weniger nach dem F/OS-Modell weiterentwickeln (lassen). Anhand von drei Beispielen soll kurz diese Übernahme des F/OS-Entwicklungsmodell durch Unternehmen diskutiert werden. 1998 gab die Firma Netscape sehr öffentlichkeitswirksam den Quellcode für ihren Browser »Navigator« und der sog. Websuite »Communicator« frei. Die Entwicklung wird weiterhin von der Firma bzw. deren Mitarbeitern kontrolliert und gesteuert, aber es besteht für externe Entwickler die Möglichkeit sich mit Bugreports oder Patches zu betei191 Was nicht heißen muß, daß F/OS-Software in jedem Fall billiger ist. Das hängt vom Einsatzzweck, dem notwendigen Schulungsaufwand, der verwendeten Hardware und anderen Faktoren ab. Der größte Teil der Kosten, meist über 90 %, von Software sind eben nicht die Lizenzgebühren.

5.3 Reperkussionen in der Ökonomie

203

ligen: »a dedicated team within Netscape [. . .] will promote, foster and guide development of Netscape’s source code base.« Nicht erwähnt in der Pressemitteilung ist der ökonomische Hintergrund der Veröffentlichung, der rasante Verlust von Marktanteilen an den Konkurrenten Microsoft. Ziel ist deshalb die »acceleration of the evolution of Communicator 5.0 development by allowing the company to harness the creative power of thousands of programmers on the Internet, incorporating their best enhancements into future versions of Netscape’s software. This strategy is designed to accelerate development and distribution of future high-quality versions of Netscape Communicator to business customers and individuals, further seeding the market for Netscape’s enterprise solutions and Netcenter business.«192 Die freien Entwickler sollen mit ihrer »creative power« die Retter des angeschlagenen Unternehmens werden, das sich dem Konkurrenten ansonsten geschlagen geben müßte. Dieses Kalkül ging nicht so schnell auf wie erhofft. Der umfangreiche Quellcode machte eine Bearbeitung im F/OS-Produktionsmodus trotz der Unterstützung durch die Firma schwierig, so daß die erhoffte »kreative Kraft« sich erst nach einigen Jahren auf den Benutzungsanteil auszuwirken begannen.193 Nichtsdestotrotz hatte dieser Schritt Signal- und Vorbildfunktion für andere Firmen. Das Unternehmen Sun hat im Jahr 2000 die Bürosoftware Starofﬁce unter dem Namen Openofﬁce freigegeben. Auch hier ging es wohl vor allem um die Erhöhung des eigenen Marktanteils gegenüber dem Monopolprodukt Microsoft Ofﬁce. Dieses Ansinnen wurde durch die Einführung eines offenen Dateiformats noch verstärkt: »To create, as a community, the leading international ofﬁce suite that will run on all major platforms and provide access to all functionality and data through 192 http://wp.netscape.com/newsref/pr/newsrelease591.html. Download am 23.01.2003. 193 Erst ab 2005 wurden nennenswerte Anteile dieses neuen Browsers registriert. Die Zahlen sind allerdings sehr unterschiedlich, so daß eine genauere Aussage schwierig bleibt, vgl. http://www.heise.de/newsticker/meldung/75666. Vgl. dazu auch http://people.hbs. edu/pyin/papers/ETB0605.pdf 15.03.2006, sowie Mockus et al. (2002). Entsprechend hat das Unternehmen inzwischen mehrere Eigentümerwechsel hinter sich.

204

5 Ökonomie

open-component based APIs and an XML-based ﬁle format.«194 Auch dieses Projekt wird nach wie vor stark von der Firma Sun unterstützt, vor allem in Form von für dieses Projekt freigestellten und von der Firma bezahlten Entwicklern. Neben dem kostenlosen Openofﬁce wird noch eine um eine Datenbank, Rechtschreibprüfung und Administratortools erweiterte Version unter dem Namen »Starofﬁce«195 verkauft. IBM etwa hat im November 2001 den Quellcode für die Entwicklungsumgebung Eclipse freigegeben. Dieser Vorgang ist insofern interessant, als sich um dieses Programm eine Gruppe von Softwareunternehmen schart, die in einer Non-Proﬁt-Organisation die Software weiterentwickeln. Dieses Konsortium umfaßt alle größeren Softwareunternehmen außer Microsoft und Sun. Das Ziel ist »a vendor-neutral open development platform and application frameworks for building software«196 zu entwickeln und zur Verfügung zu stellen. Das gemeinsame Problem, ein für alle brauchbares Softwareentwicklungswerkzeug, wird kooperativ gelöst, und nicht, wie bisher über Marktmechanismen. Statt auf einzelne Anbieter zu setzen, werden die eigenen Bedürfnisse und Bemühungen zusammengelegt, um ein für alle taugliches Werkzeug zu entwickeln und zu vertreiben. Die Freigabe des Quellcodes erfolgt aus unterschiedlichen Motiven: zum einen, wie etwa im Fall von Openofﬁce oder des NetscapeBrowsers, um eine Erhöhung des Anteils der Benutzenden gegen ein starkes Konkurrenzprodukt zu erreichen, um die gesamten oder einen Teil der hohen Entwicklungs- und Wartungskosten für wichtige Produktionsmittel zu externalisieren und schließlich das Bemühen, das Produkt zu einer weit verbreiteten, wenn nicht gar zu einer Standardanwendung zu machen. Gerade letzteres ermöglicht in Geschäftsmodellen, die vor allem auf die Verwertung von Software durch Dienstleistungen, Wartung und Anpassung setzen, eine enorme Ausweitung der Geschäftsbasis. Im Gegenzug wird auf die Lizenzgebühren verzichtet.

194 http://about.openofﬁce.org/index.html am 12.02.2006. 195 Das war der ursprüngliche Name dieses Bürosoftwarepaketes. Die in den 80er Jahren gegründete Firma wurde 1999 von Sun aufgekauft. 196 http://www.eclipse.org/org/, am 17.03.2005.

5.3 Reperkussionen in der Ökonomie

205

Kooperativer Umgang mit Wissen Der Umgang mit Wissen, wie er in der F/OSS praktiziert wird, scheint auch den Umgang mit Wissen in Unternehmen zu beeinﬂussen. Zwar werden Betriebsgeheimnisse nach wie vor als solche behandelt, aber die Frage, ob bestimmtes Wissen ein Betriebsgeheimnis ist und entsprechend geheimgehalten werden muß, wird nicht mehr so schnell positiv beantwortet. Es zeigt sich für Unternehmen, daß durch den freien und kooperativen Umgang mit Wissen sich die Kosten/NutzenRelationen verschieben und damit wächst auch die Bereitschaft den eigenen unternehmensinternen Wissensvorrat zumindest partiell zu öffnen. Ein Beispiel für einen solchen Umgang mit Wissen ist das »OSADL« (Open Source Automation Development Lab), eine »genossenschaftlich organisierte Institution, die sich als Ziel die Entwicklung, Qualiﬁzierung und Standardisierung einer Linux basierten Betriebssystemumgebung für die Automatisierungsindustrie gesetzt hat.«197 Elf mittelständische Unternehmen aus der Automatisierungs- und Softwarebranche wollen das Potential, das in Linux als Betriebssystem für Embedded Systems steckt, nutzen und treiben in Form einer Genossenschaft die für sie relevanten Aspekte der Entwicklung voran. Das sind vor allem die sog. Echtzeitfähigkeit, also eine technische Komponente und eine »allgemein akzeptierte Echtzeitschnittstelle«, also die soziale Komponente der Durchsetzung einer standardisierten Schnittstelle. Auf dieser Grundlage kann dann jede der einzelnen Firmen ihre eigenen Produkte entwickeln und vertreiben. Wo vorher ein Betriebssystem gekauft oder selbst entwickelt werden mußte, steht jetzt kostenlose Software, die nach gemeinsam erstellten Speziﬁkationen zu einer Arbeitsgrundlage für alle Beteiligten (und potentiell auch für nicht an dieser Kooperation beteiligte Konkurrenten) weiterentwickelt wird. Im Gegensatz zu den üblichen Firmenkooperationen im Entwicklungsbereich, in denen das gemeinsam entwickelte Wissen dann von beiden angeeignet und gerade nicht frei verfügbar wird, wird hier der auch für ›Trittbrettfahrer‹ frei zugängliche Pool von verfügbarem Wissen erweitert. Dabei kann und soll nicht auf die F/OS-Entwickler verzichtet werden. Deren Entwicklungsmodell wird respektiert, allerdings sei für die Durchsetzung der 197

http://www.osadl.org/

206

5 Ökonomie

eigenen Interessen eine Bündelung der Aktivitäten erforderlich: »Die aktuelle Version des Linux-Kernels weist bereits eine große Anzahl von Eigenschaften auf, wie sie für den Einsatz in der Automatisierungstechnik benötigt werden. Dies ist aber nicht das Resultat einer gezielten Einﬂussnahme dieser Branche auf die Kernel-Entwicklung sondern eher auf eine gewisse Interessensüberschneidung mit anderen Anwendungsgebieten zurückzuführen. Wesentliche Merkmale, nämlich die kompromisslose Unterstützung von Echtzeit-Eigenschaften und die Verfügbarkeit einer allgemein akzeptierten Echtzeitprogrammierschnittstelle fehlen zur Zeit; es ist nicht abzusehen, dass diese Eigenschaften in naher Zukunft implementiert werden, wenn dies nicht von einer genügend starken Interessensgruppe befördert wird. Derartige Interessensgruppen sind keine Neuigkeit sondern stellen einen etablierten und anerkannten Mechanismus dar. Beispielsweise wird die Entwicklung des jetzigen Standard-Kernels wesentlich von den Open Source Development Labs (OSDL) getragen; nicht zuletzt ist Linus Torvalds bei dieser Organisation angestellt.« (http://www3.osadl.org/documents/osadl-strategy_de.html, Download v. 11. 08. 2006.) Das Ziel lautet damit, ähnlich wie oben bei den OSDL, ›Lobbyismus‹ im Linuxkernel, um damit die benötigten Codeänderungen durchzusetzen. Die Softwareentwicklung von Linux wird von dieser Warte als politischer Prozeß gesehen, der über Interessensgruppen gesteuert werden kann, wenn die basalen Anforderungen der autonomen Entwickler respektiert werden. »Damit die Ergebnisse der Arbeitsgruppen in die Community und den Open Source Prozess Eingang ﬁnden, ﬁnanziert das OSADL Maintainer im Sinne des Open Source Gedankens. Diese Maintainer haben die Aufgabe, die für das OSADL relevanten Referenzimplementierungen zu pﬂegen und sie gegen die in den Arbeitsgruppen erarbeiteten Speziﬁkationen zu veriﬁzieren. Dabei sind sie frei

5.3 Reperkussionen in der Ökonomie

207

in der Auswahl der Implementierungen unbeachtet der Herkunft (Community oder OSADL Mitglied). Durch diese Freiheit wird die enge Kopplung an die Open Source Community gewährleistet und der Grundgedanke der Auswahl der technisch besten Lösung erhalten.« (ebd.) In Arbeitsgruppen werden die gemeinsamen Ziele festgelegt. Für die Umsetzung soll ein angestellter Programmierer zuständig sein, ähnlich wie an den OSDL, wo etwa der Samba-Entwickler Andrew Tridgell für etwa ein Jahr zur Fertigstellung der Version 4 dieses Programmes angestellt war. Der oder die angestellten Entwickler sollen die für die Echtzeitanwendung relevanten Teile des Betriebssystems pﬂegen und neue Funktionen gemäß den Interessen der kooperierenden Unternehmen realisieren. Betont wird zudem die Freiheit in der technischen Umsetzung. In den OSDL, in denen Unternehmen aus den verschiedensten Branchen mit unterschiedlichsten Interessen sich der Förderung von Linux und Open Source allgemein verpﬂichten, wird nicht so deutlich sichtbar, daß sich hier auch zum Teil harte Konkurrenten zusammen tun, um gemeinsam, gewissermaßen außerhalb der Verwertungslogik, Grundlagenwissen zu erarbeiten bzw. erarbeiten zu lassen. Unter expliziter Ausschaltung der Konkurrenz in einem Bereich des Wissens werden allgemeine Grundlagen des Konkurrenzkampfes marktextern kooperativ geschaffen. Solche Kooperationen gab es bisher auch schon in Form von oft staatlich initiierten und geförderten Forschungsverbünden. Der Unterschied ist jedoch, daß das in dieser Kooperation generierte Wissen nicht angeeignet, sondern der Allgemeinheit zur Verfügung gestellt wird, also auch potentiellen Konkurrenten, die nicht an der Koooperation beteiligt sind. Veränderung der Kundenbeziehung Ein Beispiel für eine nicht ganz so freiwillige Öffnung des Wissensvorrats ist die Firma Siemens. Als dieses Unternehmen im Dezember 2004 die Set-Top-Box Gigaset M740 AV herausbrachte (ein Zusatzgerät zum Empfang von digitalem, terrestrischen Fernsehen (DVB-T)), war aufgrund der Anschlußmöglichkeiten erstmals ein Gerät auf dem Markt, das den PC mit dem Fernseher verbinden konnte. Dieses Gerät verwendet Linux als Betriebssystem, die restliche Software ist proprietär

208

5 Ökonomie

und nicht quelloffen. Siemens mußte kurz nach der Markteinführung einen außergerichtlichen Vergleich mit der Free Software Foundation schließen, weil versäumt wurde, den Quellcode des verwendeten und angepassten Linux zum Download zur Verfügung zu stellen. Trotz des relativ hohen Preises (Linux wurde unter anderem eingesetzt um diesen hohen Preis durch zusätzliche Lizenzgebühren nicht noch weiter in die Höhe zu treiben) entstand aufgrund des technischen Erweiterungspotentials (Netzwerk- und USB-Anschluß) schnell eine größere Benutzergruppe, die sich ebenfalls bereits im Dezember 2004 im Internet ein Forum schuf (vgl. http://www.m740.info), um Erfahrungen und Tips mit dem Gerät auszutauschen. Diese Benutzer nutzten die Möglichkeiten des quelloffenen Betriebssystems zu einer Vielzahl von eigentlich nicht vorgesehenen Benutzungsmöglichkeiten (z. B. ftp-Server, Webserver). Gleichzeitig melden sie gefundene Fehler und Verbesserungswünsche, wie die OSDL in Form von »feature roadmaps«, an das Unternehmen. Zusätzlich wird versucht, die Hardware unabhängig von der proprietären Software mit F/OS-Programmen zu betreiben.198 Das Verhältnis zu den Kunden hat sich im Falle dieses Produktes für Siemens aufgrund des Einsatzes des Betriebssystemes Linux völlig geändert. Die Benutzer versuchen in einem öffentlichen Forum die technischen Grenzen des Gerätes auszureizen und -weiten. Dazu liefern sie Fehlermeldungen und Verbesserungsvorschläge an das Unternehmen, das im Gegenzug versucht, diese, soweit sie sich rentabel umsetzen lassen, zu beheben bzw. zu integrieren. Damit bleibt das Produkt selbst in einem ständigen Produktionsprozeß aufgrund der permanenten Kommunikation mit den Benutzern. Das Unternehmen selbst hat nach Auskunft eines Mitarbeiters mit einer solchen Veränderung in der Kundenbeziehung nicht gerechnet, geht jetzt allerdings soweit möglich und vor allem so weit ökonomisch machbar auf die Kundenwünsche ein. Die F/OSS bringt, wie an diesen wenigen beispielhaften Fällen zu sehen ist, in verschiedenen Bereichen neue Impulse in die kapitalistische Ökonomie, zumindest im Bereich der Softwareproduktion und -vermarktung. Zum einen wird die Produktionsweise in einigen Fällen der F/OS-Produktion angepaßt, bzw. versucht, einen kooperativen 198 Vgl. http://www.open7x0.org/

5.3 Reperkussionen in der Ökonomie

209

Produktionsprozeß außerhalb der Markt- und Konkurrenzbeziehungen auf der Grundlage von quelloffener Software zu etablieren. Das entspricht, wenn die Entwicklung der ökonomischen Logik der Software plausibel ist, genau der Logik des öffentlichen Guts bzw. der allgemeinen Arbeit. Die Verwertung von Software wird deshalb, zumindest teilweise, aus dem problematischen direkten Verwertungsprozeß (Lizenzen) herausgenommen und in den Bereich der indirekten Verwertung verlagert. also hin zur Verwertung über Dienstleistungen, Wartung, Anpassung, Schulung etc. Das bringt auch eine Veränderung der Kundenbeziehungen mit sich: die Konsumtion, also der Gebrauch der Software, wird in den damit stark temporalisierten Produktionsprozeß miteinbezogen, insofern als die Benutzenden Fehlermeldungen und Verbesserungsvorschläge in die Produktion mit einspeisen. Diese reﬂexiven Schleifen, die typisch für die Wissensproduktion im allgemeinen und die Softwareproduktion im speziellen sind, waren zwar schon vorher in der kommerziellen Softwareproduktion vorhanden. Neu ist die Ausweitung dieser Schleifen unter Außerkraftsetzung von Markt und Konkurrenz. Inwieweit der offene Umgang mit Wissen, wie er in der F/OSS praktiziert wird, einen stärkeren Einﬂuß auf kapitalistische Formen der (Wissens-)Produktion hat, ist zum jetzigen Zeitpunkt noch nicht abzusehen. Die aufgeführten Beispiele zusammen mit der Zentralität von Computern und vor allem Software für die aktuellen Umbaubewegungen im Kapitalismus lassen jedoch vermuten, daß das erst der Anfang einer Verschiebung innerhalb der ökonomischen Bewertung von Wissen ist (damit ist jedoch keineswegs eine Änderung in den grundsätzlichen Prozessen der Produktion verbunden). Evolution, Kooperation oder Vereinnahmung? Die empirischen Beispiele zeigen, daß das Verhältnis von kapitalistischer Industrie und F/OSS nicht auf einen einfachen Nenner zu bringen ist. Was deutlich wurde, ist die Tatsache, daß die F/OSS weiterhin neben der kapitalistischen Softwareproduktion besteht und den gemeinsamen Wissenspool bisher gegen Aneignungsversuche gut verteidigen konnte, und soweit das gegenwärtig abzusehen ist, wohl auch in nächster Zukunft gut verteidigen wird können. Ebenso konnte sich die kapitalistische Softwareprodukion trotz der ›kostenlosen‹ Konkurrenz

210

5 Ökonomie

entgegen der Hoffnungen und Voraussagen einiger F/OS-Enthusiasten stabil weiterentwickeln. Der Preis für die Selbständigkeit der F/OSS ist die Fokussierung auf Problemlösungen und die Akzeptanz aller technisch sinnvollen Problemstellungen, d. h. in gewisser Weise auch Verzicht auf die Richtungsentscheidungen in der Technologieentwicklung. Dafür muß die Selbstbestimmung in der Produktion von den Unternehmensakteuren geachtet werden. Unter diesen Prämissen sind gute Grundlagen für Kooperationen vorhanden, die die Anwendung der im Eingangszitat dieses Kapitels erwähnten Schmidtschen Dreschmaschine eher unwahrscheinlich machen. Der interessanteste Teil dieses Verhältnisses liegt jedoch im notgedrungen kurzen zweiten Teil: welche Rückwirkungen hat die F/OSS auf die kapitalistische Form der Wissensökonomie. Die wenigen empirischen Daten weisen durchaus auf evolutionäre Veränderungen in der Kultur der Wissensproduktion und des Umgangs mit Wissen hin, die auch dem Beispiel der F/OSS geschuldet sein können. Ein Ende des Kapitalismus, wie es von einigen Aktivisten der Szene prognostiziert wird, aus diesen wenigen Befunden abzuleiten, wage ich nicht. Als zu wandlungs- und anpassungsfähig hat sich diese Wirtschaftsform bisher erwiesen. Zu erfolgreich wurden neue politische, technische und gesellschaftliche Rahmenbedingungen assimiliert.199 Um die empirisch vorgefundenen, möglicherweise neuen ökonomischen Formen besser einordnen zu können, sind im abschließenden Kapitel einige ökonomische Überlegungen zu leisten.

199 Vgl. für die jüngste Veränderungen etwa Boltanski und Chiapello (2003).

6 Offene Wissensökonomie Wissen hat keinen Wert noch Nutzen für den der einsam lebt. Um es zu genießen, muß es mitgeteilt werden.200

Die F/OSS fügt sich, wie deutlich wurde, nicht ohne weiteres in die kapitalistische Produktions- und Verwertungsweise ein. Gleichwohl ist es, meines Wissens zum ersten Mal in der Geschichte dieser ökonomische Formation, gelungen, parallel zu einer funktionierenden kapitalistischen Produktion eine andersartige Form der Produktion dauerhaft zu etablieren. Die ökonomische Praxis der »offenen Wissensökonomie« ist, wie die bisherigen Analysen zeigen, der herkömmlichen keineswegs antagonistisch entgegengesetzt. Selbst die ideologisch den weitesten Abstand wahrende Gruppe, die Free Software Foundation, betont immer wieder die Vereinbarkeit von GPL-Software mit unternehmerischer Tätigkeit. Trotz dieser unproblematisch erscheinenden Koexistenz von kapitalistischer (Wissens-)Produktion und F/OS-Softwareproduktion und -distribution, gilt es im Folgenden, die grundsätzlichen Differenzen der ökonomischen Praktiken herauszuarbeiten. Differenzen, die gerade in ihrer Gegensätzlichkeit und im Bezug auf die Diskussion um die Entstehung einer Wissensgesellschaft auf den bisher erarbeiteten empirischen Grundlagen vorsichtige erste Ausblicke auf die ökonomische Verfaßtheit einer solchen Gesellschaft ermöglichen können. Dazu sollen in einem ersten Schritt die für eine ökonomische Analyse wichtigen Merkmale von Software im Speziellen und Wissen im Allgemeinen herausgearbeitet werden, bevor in zwei weiteren reﬂexiven Schritten anhand der Begriffe »Eigentum« und »Tausch« bisher eher implizit abgehandelte Merkmale der Ökonomie des Wissens her200 Zitat aus einem 1774 vor dem englischen Court geführten Prozeß. Zitiert nach Bappert 1962: 146.

212

6 Offene Wissensökonomie

ausgearbeitet werden. In einem abschließenden Schritt werden dann die oben erarbeiteten empirischen Befunde im Lichte dieser Analysen zusammengefaßt.

6.1 Software als Ware? Software ist ein typisches Produkt der unter dem Label »Wissensgesellschaft« ﬁrmierenden Form der Ökonomie. Die Entwicklung eines Computerprogrammes benötigt sehr viel Knowhow. Diese Entwicklung ist ein ständig aufs Neue temporalisierter Prozess mit offenem Ende.201 Das gilt sowohl für die standardisierte Massensoftware (Betriebssysteme, Ofﬁceanwendungen o. ä.) als auch für speziell auf die Bedürfnisse eines oder weniger Kunden zugeschnittene Software.202 Um solche wissensintensiven Produkte zu verwerten, gilt es unter kapitalistischen Vorzeichen, sie in Warenform zu bringen, um sie verkaufen zu können (Stehr 2001: 102 ff.). Wenn Wissen in Warenform gebracht wird, kann das nur für einen quasi arretierten Zustand in diesem Produktionsprozeß erfolgen. An diesem Punkt wird der Entwicklungsrozeß gestoppt, um von Entwicklung auf Verwertung umzuschalten.203 Der erreichte Entwicklungsstand wird, um eine in der Softwareentwicklung gebräuchliche Metapher zu verwenden, »eingefroren« und als solcher zur Verwertung in die Warenform überführt. Dabei kann man, wie Nico Stehr feststellt, bei solchen »›symbolischen‹ Waren [. . .] nicht davon ausgehen, dass diese Warenform insgesamt die ökonomischen, rechtlichen und praktischen Qualitäten von herkömmlichen Waren hat.« (Stehr 2001: 313) Als Kennzeichen arbeitet Stehr in der Folge die Kontextsensitivität dieser Waren heraus (a), die geringe Lebenserwartung (b), die Schwierigkeit der Anwen201 Der für Derridas Theorie der Signiﬁkation zentrale Begriff der différance beschreibt dieses Merkmal der vorliegenden symbolischen Produktion sehr gut, vgl. Derrida 1988; 1976. Vgl. auch Abschnitt 2.1. 202 In letzterem Falle ist die Marktmacht der an dieser Kooperation beteiligten Unternehmen entscheidend: Wenn ein Global Player bei einem kleinen Startup Software programmieren läßt, sind die Lizenzbedingungen andere, als wenn dasselbe Programm von IBM erstellt würde. 203 Die Bedingungen, mit deren Erfüllung das Wissen der Verwertung zugeführt werden kann, sind im Normalfall vorher festgelegt, wenn ihr Erreichen auch selten mit dem ebenfalls vorher festgelegten zeitlichen Rahmen zusammenfällt.

6.1 Software als Ware?

213

dung des Eigentumsrechtes (vgl. unten 6.2) und schließlich die nur unvollständige Anwendbarkeit der regulativen Prinzipien des Marktes auf die Austauschprozesse solcher Waren (vgl. unten 6.3). Zunächst sollen die beiden Merkmale der Kontextsensitivität und die geringe Lebenserwartung der »symbolischen« Waren diskutiert werden: (a) Die Nähe von Erzeugungs- und Anwendungskontext ist für in Warenform gebrachtes Wissen ein zentrales Merkmal. Der soziale, technische und kognitive Kontext von Wissen (und Software) ist zentral für die Beurteilung der Qualität, oder in Marx’ Worten: des Gebrauchswertes. Der von Marx analysierte »moralische Verschleiß« (Marx 1979: 426 ff.) beruht im Fall von Wissen im Allgemeinen und Software im Speziellen auf Veränderungen in diesem Kontext.204 Diese Kontextsensitivität weist aber auch auf die nahezu immer nötige Anpassungsleistung des Wissens an den je konkreten Kontext des Kunden bzw. des Kunden an den je konkreten Kontext des Wissens (vgl. Abschnitt 2.1). (b) Die »fast immer sehr geringe« »Lebenserwartung der symbolischen Waren« (Stehr 2001: 313) halte ich aufgrund des nichtvorhandenen Verschleißes von symbolischer Technik (Rammert 1998a: 317) zumindest für diskussionswürdig. Damit ist, wenn man denn den merkwürdigen Begriff »Lebenserwartung« in diesem Zusammenhang verwenden will, eher von einer potentiell sehr langen Lebensdauer von symbolischen Waren auszugehen. Die These von der geringen Aktualitätsdauer beruht meines Erachtens vor allem auf der schnellen Änderung der technischen und sozialen Kontexte, was in bestimmten Bereichen zu einem hohen »moralischen Verschleiß« führt.205 Die Warenform selbst fügt dem zu Technik geronnenem Wissen zwar kein besonderes 204 Die Entschlüsselungsprogramme von Bletchley Park sind insofern verschlissen, weil niemand mehr mit der Enigmaverschlüsselung arbeitet, weil die Hardware nicht mehr existiert (auch wenn sie emuliert werden kann) und schließlich, weil es (vielleicht) inzwischen bessere Decodierungsalgorithmen gibt. 205 Dem stehen jahrtausendealte Wissensprodukte wie etwa die platonischen Dialoge oder die Texte von Aristoteles gegenüber, die sich in immer neue Kontexte integrieren lassen. Vgl. dazu auch die Konstruktion des Lebens nach dem Tode in Arno Schmidts Erzählung »Tina oder über die Unsterblichkeit«, die von der Existenz von materiellen Exemplaren eines Buches abhängt.

214

6 Offene Wissensökonomie temporalisierendes Element hinzu. Allerdings gilt im Falle des marktorientierten Wirtschaftens das Phänomen der Konkurrenz. Dieser Kontext vor allem setzt das in Warenform gebrachte Wissen außer Aktualität, und damit aus der Verwertungs-Erwartung hinaus.

Die beiden ersten von Stehr benannten Merkmale haben nur eingeschränkte oder indirekte ökonomische Relevanz für symbolischen Waren. Die Schwierigkeit der Anwendung des Eigentumsrechtes und der Anwendung von Marktprinzipien sprechen meines Erachtens jedoch zwei eminent wichtige Punkte an. Bevor zu deren genauerer Analyse geschritten werden kann, gilt es jedoch noch einige weitere ökonomisch relevante Qualitäten von Software im Speziellen und Wissen im Allgemeinen herauszuarbeiten. Dazu wird ausgegangen von Marx’ Warenbegriff. Demnach ist die Ware als »Elementarform« des Reichtums der kapitalistischen Gesellschaften »ein Gegenstand, ein Ding, das durch seine Eigenschaften menschliche Bedürfnisse irgendeiner Art befriedigt.« (Marx 1979: 49) Das speziﬁsche der Ware ist nun, daß sie »Gebrauchswert für andere« (Marx 1979: 55) ist, daß sie also für den (marktförmigen) Austausch produziert wird, nicht für die eigenen Bedürfnisse der Produzierenden.206 In den vielfältigen Austauschprozessen erhalten die Waren eine speziﬁsche gesellschaftliche Wertzuschreibung: den Tauschwert, der sich durch die für die Produktion gesellschaftlich notwendige Arbeitszeit bestimmt. Für den Austauschprozeß ist weiterhin notwendig, daß sich die Warenbesitzer »wechselseitig als Privateigentümer anerkennen« (Marx 1979: 99), also ein rechtlich gesicherter Rahmen des Austauschverhältnisses.207 Das erste, was vor dem Hintergrund dieses Warenbegriffes auffällt, ist die Diskrepanz im Arbeitsaufwand für die Produktion und ReProduktion von Software bzw. Wissen. Dem hohen Entwicklungsaufwand für das »erste Exemplar« eines Programmes oder einer (verwertbaren) Erkenntnis steht der minimale Aufwand für die Produktion aller 206 Max Weber (1988: 4) deﬁniert einen »kapitalistischen Wirtschaftsakt« als beruhend »auf Erwartung von Gewinn durch Ausnützung von Tausch-Chancen«. 207 Vgl. zu diesen notwendigen rechtlichen Rahmenbedingungen des Tausches auch Durkheim 1977: 166 ff.

6.1 Software als Ware?

215

weiteren »Exemplare« gegenüber. Oder aus der einer anderen ökonomischen Perspektive formuliert: Die Grenzkosten bei der Produktion eines weiteren Exemplars desselben Programms an einem gegebenen Entwicklungsstand gehen gegen Null. Das Problem ist demnach die Verwertung der geleisteten Entwicklungsarbeit trotz sehr geringer Reproduktionskosten.208 Dieser niedrige Reproduktionsaufwand gilt für in Digitalform vorliegende symbolische Waren seit der zumindest in industriellen Gesellschaften209 nahezu gesellschaftsweiten Verbreitung von Digitalcomputern auch für die Nutzenden dieses warenförmigen Wissens. Für diese haben die symbolischen Waren als zweite Auffälligkeit die vorteilhafte Eigenschaft, daß sie zwar leicht kopiert und weitergegeben werden können, mit der Weitergabe aber keineswegs ein Verzicht auf die eigene Nutzung verbunden ist. Bei näherer Betrachtung zeigt sich als dritte Auffälligkeit, daß (auch) die Produkte der kapitalistisch organisierten Softwareindustrie keineswegs eindeutig abgrenzbare Waren sind. Der Gegenstandscharakter, der nach Marx Waren charakterisiert (Marx 1979: 49) ist aufgrund der nicht an einen bestimmten Träger gebundenen Software letztlich auf den Datenträger beschränkt, nicht auf die Software selbst. Das Neue an der digitalen Technik ist diese gelockerte Kopplung von materiellem Träger und symbolischem Gehalt. Ein Computerprogramm kann eine elektromagnetische Zustandskombination im Arbeitsspeicher oder auf der Festplatte sein, eine Folge von Abtastunebenheiten auf einem mit Laser bearbeitetem Datenträger oder gedruckter Quelltext.210 Auch für die gesellschaftlich akzeptiertere Form der ökonomischen 208 Bei stärker an ihre Materialität gebundenen Waren bestimmt sich der Tauschwert nach dem für die Reproduktion gesellschaftlich notwendigen Arbeitsaufwand, bzw. den neoklassischen Theorien zufolge der Preis nach den Reproduktionskosten für ein weiteres Exemplar. 209 Hier öffnet sich ein weiteres Desiderat der Forschung: trotz der Verbreitung der digitalen Technik und der entsprechenden Programmierkompetenzen ist der Anteil von F/OSS-Entwicklern aus asiatischen Ländern, etwa Indien, Japan oder China, relativ gering. Inwieweit und welche kulturellen Differenzen für eine derart ungleiche Beteiligung sorgen, bleibt eine Frage, die nicht zuletzt wichtig ist für die weitere Entwicklung dieser ökonomischen Praktiken. 210 Das heißt nicht, daß Software bzw. Wissen »immaterielle« Waren sind, wie Haug (2003) behauptet, sondern nur, daß sie nicht fest an eine bestimmte Materialität gekoppelt sind.

216

6 Offene Wissensökonomie

Wissenschaft werfen die hier »Informationsgüter« genannten Produkte einige Probleme auf. Informationsgüter sind nicht knapp, da sie sich mit gegen null gehenden Grenzkosten reproduzieren lassen und die Weitergabe nicht mit dem Verzicht auf die eigene Nutzung verbunden ist. Damit sind auch die weiteren Merkmale der klassischen Güter, die »Ausschließbarkeit« und die »Rivalität in der Güternutzung«, eingeschränkt.211 Gerade deshalb wird im Falle des Erwerbs von Software nicht das Eigentum am Programm erworben, sondern nur ein eingeschränktes Nutzungsrecht. Die konventionellen Softwareunternehmen verkaufen ihren Kunden im Normalfall nicht ein Programm, sondern nur das Recht, ein bestimmtes Programm unter bestimmten Bedingungen zu nutzen. Zusätzlich zum Programm können die Kunden auch noch Beratungs-, Anpassungs- oder Schulungsleistungen erwerben.Die Knappheit wird über Lizenzierungspraktiken erst hergestellt. Nicht das Informationsgut selbst ist knapp, sondern die Nutzungsmöglichkeiten. So ist vor allem Kopieren und Weitergeben zwar technisch sehr einfach, aber allerstrengstens verboten. Als speziﬁsche Merkmale von Software und digitalisiertem Wissen lassen sich damit folgende festhalten: 1. Digitalisierte Informationsprodukte sind aufgrund der losen Kopplung an materielle Träger und der damit gegebenen einfachen Reproduzierbarkeit nicht knapp. 2. Ihre Weitergabe ist nicht mit Verzicht verbunden. 3. Sie sind aufgrund der nurmehr losen Verbindung mit einem materiellen Informationsträger potentiell überall (sofern digitale Infrastruktur vorhanden ist) und immer (sofern kein »moralischer Verschleiß« (vgl. oben 2.1) eingetreten ist) verfügbar. Es sind also die digitalen Informationsprodukte, die aufgrund der mit diesen Eigenschaften beschriebenen Multiplikationsfähigkeit zumindest potentiell zeit- und ortlos (Stehr 2001: 316) sind, keineswegs gilt das jedoch für die Produktion derselben. Die Warenform von Informationsgütern impliziert aufgrund dieser Eigenschaften ein anderes Verhältnis von Hersteller und Kunde, von 211 Vgl. dazu auch DeLong und Zoomkin (2000).

6.2 Geistiges Eigentum und Wissen

217

Käufer und Verkäufer als im Falle von ›herkömmlichen‹, an eine speziﬁsche Materialität gebundenen Waren. Das Machtverhältnis muß sich zugunsten des Anbieters von Informationsgütern verschieben212 , wenn die Warenform zumindest auf einer rechtlichen Ebene hergestellt werden soll.213 Zentral für diese rechtliche Konstruktion ist der Begriff des sogenannten »geistigen Eigentums«, dessen historische Entwicklung im nächsten Abschnitt erläutert werden soll, bevor auf die Besonderheiten der Austauschprozesse von Software und Wissen eingegangen wird.

6.2 Geistiges Eigentum und Wissen Eine Bedingung der Warenform ist, wie oben anhand von Marx’ Text ausgeführt, das Privateigentum an der Ware. Das setzt, neben der gegenseitigen Anerkennung dieses Eigentums, ein gesellschaftlich anerkanntes und forciertes Eigentumsrecht voraus. Die oben entwickelten Eigenschaften machen nun gewisse Abwandlungen dieses Eigentumsrechtes nötig, weil der herkömmliche Eigentumsbegriff, »wie er noch heute unser juristisches Denken beherrscht« (Weber 1986: 102), für bewegliche Gegenstände und für Boden ausgelegt ist.214 Zunächst gilt es das Eigentumsrecht kurz zu erläutern, bevor die historische Entwicklung des »geistigen Eigentums« skizziert wird, um dann von da aus die Eigentumspraxis der F/OSS zu analysieren. Eigentumsrecht und die Sicherstellung des »geistigen Eigentums« Die ökonomische Ordnung des Kapitalismus beruht auf der als Eigentum bekannten sozialen Praxen der Zuordnung von Dingen zu Personen. Dieses Eigentumsrecht hat sich aus dem römischen Privatrecht entwickelt, aus dem ius utendi et abutendi, als Recht der absoluten 212 In extremer Form ist dieses Machtverhältnis seit einiger Zeit in der Musikindustrie zu beobachten. Die Anbieter versuchen selbst den Konsum (!) ihrer Güter durch technische und juristische Mittel zu kontrollieren, um einen aus ihrer Sicht als Mißbrauch deﬁnierten Gebrauch, und damit die Ausschließbarkeit der Nutzung, sicherzustellen. Hier zeichnet sich vielleicht eine Trendwende ab, nachdem der Konzern EMI beginnt, auf eine Anwendung von DRM-Technologie beim Verkauf von Musikstücken zu verzichten (http://www.heise.de/newsticker/meldung/88131). 213 Vgl. zur Frage der Warenform in der F/OSS auch Holtgrewe und Werle 2001. 214 Bzw. der Eigentumsbegriff für bewegliche Güter wurde seit dem römischen Recht auf Land- und Grundbesitz ausgedehnt (Weber 1986: 205 f.).

218

6 Offene Wissensökonomie

Verfügungsgewalt über eine Sache. Hegel (1995) hat diese Bestimmung des Eigentums konkretisiert hinsichtlich Besitznahme, Gebrauch und Veräußerung: »Das Eigentum hat seine näheren Bestimmungen im Verhältnis des Willens zur Sache; dieses ist α) unmittelbar Besitznahme, insofern der Wille in der Sache, als einem Positiven, sein Dasein hat; β) insofern sie ein Negatives gegen ihn ist, hat er sein Dasein in ihr als einem zu Negierenden, – Gebrauch, γ) die Reﬂexion des Willens in sich aus der Sache – Veräußerung; – positives, negatives und unendliches Urteil des Willens über die Sache.« (Hegel 1995: § 53) Hegel erklärt Eigentum aus dem Verhältnis des Willens zur Sache, setzt aber mit dem letzten Punkt eine speziﬁsch neuzeitliche Konnotation des Eigentumsbegriffes hinzu. Nicht mehr nur die Verfügungsgewalt, sondern das Veräußerungsrecht wird wesentlicher Bestandteil. Marx (1957: 315) weist daraufhin, daß Eigentum ein gesellschaftlich garantiertes Verhältnis ist, das sich vor allem in den Praxen des Tausches zeigt. Ähnlich legt auch Max Weber den Schwerpunkt der Deﬁnition von Eigentum: als »monopolisierte Chanc[e]«, die in einer geschlossenen sozialen Beziehung, als erblich appropriiert (Eigentum) oder veräußerlich appropriiert (freies Eigentum), garantiert wird (Weber 1972: 23, 201 f.). Das »freie Eigentum« der Moderne zeichnet sich gerade aus durch seine Veräußerlichkeit über die Grenzen der Gemeinschaft hinweg. Das heißt, das Speziﬁsche der modernen Eigentumspraxis ist, neben der Ausschließbarkeit Anderer von der Nutzung, die Ausrichtung auf die Veräußerung, auf den Tausch (vgl. dazu auch Schmidt 2006: 21 ff.). Die Übertragung dieses Eigentumsbegriffes auf Software und Wissen bringt durch die oben entwickelten Eigenschaften vor allem eine Schwierigkeit mit sich: Wie kann die Ausschließbarkeit und damit die Verwertung über Tauschprozesse sichergestellt werden? Ein erster Schritt hin zur Verwertung des in Warenform gebrachten Wissens ist der Schutz des in der Software enthaltenen Wissens, um die weitere monopolisierte Verwertung über Lizenzgebühren gewährleisten zu können. Letzteres geschieht normalerweise dadurch, daß nur

6.2 Geistiges Eigentum und Wissen

219

vorkompilierte Software, also nur der Binärcode, an die nutzungsberechtigten Kunden geliefert wird. Solange nicht das Programm selbst verkauft wird, sondern nur ein Benutzungsrecht, und damit nur ein binäres Programm zur Verfügung gestellt wird und nicht der Sourcecode, haben die Softwareanbieter die machtvollere Position in dieser Beziehung. So wird das im Programm steckende Wissen geschützt und monopolisiert. Damit bleiben die Möglichkeiten für Anpassungsleistungen, und zumindest die Kontrolle über eventuell zu externalisierende Beratungs- und Anpassungsleistungen beim Hersteller des Programms. Das Geschäftsmodell der Softwareindustrie beruht neben dieser Geheimhaltung aber vor allem auf der Herstellung des Privateigentums am Programm, das durch Urheber- bzw. Patentrecht juristisch sichergestellt wird. Um diese Warenform und die damit notwendig verbundene Ausschließbarkeit und Tauschmöglichkeit garantieren zu können, ist es für diese besonderen Waren notwendig, nicht das Eigentumsrecht zu übertragen, sondern dem Käufer nur ein eingeschränktes Benutzungsrecht zuzugestehen. Monopolisiertes Wissen wird durch Bindung an eine bestimmte Materialität in die Form identischer Exemplare gebracht, deren jeweilige Singularität dann durch Lizenzen und Urheberrecht rechtlich abgesichert wird. Damit wird für dieses speziﬁsche Wissen ein Monopol gesellschaftlich garantiert. Das ist der Prozeß der Kommodiﬁzierung von Wissen. Die rechtliche, also gesellschaftliche Rahmensetzung dieser Kommodiﬁzierung wird nicht von ungefähr seit der gesellschaftsweiten Verbreitung der billigen digitalen Technologie auf globaler und nationaler Ebene enorm forciert (vgl. zu dieser Entwicklung Grassmuck 2002: 51 ff.). Zusätzlich wird versucht über technische Mittel die Weitergabe zu unterbinden oder einzuschränken (vgl. zum DRM auch Abschnitt 5.2.1). Beide Wege, der rechtliche und der technische, sind jedoch mit z. T. nicht unerheblichen Einschränkungen des Gebrauchs verbunden, was in individualisierten Gesellschaften einen enormen Kontrollaufwand impliziert, um Umgehungen zu verhindern. Bevor vor diesem Hintergrund die Eigentumspraxis der F/OSS entwickelt wird, ist ein kurzer Blick auf die historische Entwicklung des »geistigen Eigentums« notwendig.

220

6 Offene Wissensökonomie

Historische Entwicklung des »geistigen Eigentums« – vom Privileg zum Urheberrecht Die vom Begriff des Privateigentums an beweglichen Sachen zu unterscheidende Form des »geistigen Eigentums«, Patente, Urheberrechte, Lizenzrechte und andere juristische Regelungen, sollen Wissen schützen. Diese Form des Eigentumsrechts ist entstanden mit der Produktion von Wissen für den freien und anonymen Markt, also mit dem Buchdruck mit beweglichen Lettern.215 In der handschriftlichen Kultur der Antike und des Mittelalters waren Kopien eine Ehre für den Autor und selbstverständlich gewesen. Die Sorge galt ausschließlich der Richtigkeit und Vollständigkeit der Kopie. Um diese zu gewährleisten wurden gelegentlich »Bücherﬂüche« eingesetzt. Es waren aber keine ökonomischen Interessen mit den Inhalten der Handschriftenproduktion verbunden. »Wirtschaftliche Erwartungen an die Vervielfältigung und die Verbreitung des Werkes zu knüpfen, lag dem Urheber im gesamten Zeitraum des Mittelalters fern [. . .] Der Herstellungsvorgang des literarischen Werkes war ungewerblicher Natur.« (Bappert 1962: 67) Für die Autoren galt diese Position nahezu bis ins 19. Jahrhundert hinein: »Denn ich habs umsonst empfangen, umsonst hab ichs gegeben und begehre auch nichts dafür« (Martin Luther: Vorrede oder Vermanung an die Drücker 1525, zitiert nach Bappert 1962: 145). Die Entwicklung des Buchdrucks mit beweglichen Lettern revolutionierte die Wissensproduktion und -distribution grundlegend. Die Verbreitung von Wissen erfolgte fortan vor allem in der materialen, abgrenzbaren Form des Buches. Von Beginn an, mit Gutenbergs Bibel, löste sich die Buchproduktion von der herkömmlichen Auftragsarbeit und schuf sich einen anonymen Käufermarkt. Erst mit dem Verkauf einer bestimmten Anzahl von Exemplaren ließen sich die Kosten der neuen Technologie amortisieren. Mit dem Buchdruck entstand das Buch als für den Tausch produzierte Ware, die ökonomische Verwertung des Gedruckten durch die Drucker und Verleger und nicht zuletzt die durch die Warenform bedingte, noch heute gültige äußere Form 215 Vgl. dazu Giesecke 1991; Eisenstein 1979; Febvre und Martin 1976.

6.2 Geistiges Eigentum und Wissen

221

des Buches (vgl. dazu etwa Rautenberg 1999). Diese erste Form der maschinell unterstützten Massenproduktion für den Markt ermöglicht zwar die Produktion des einzelne Buchexemplares als Ware. Aber das im Buch inkorporierte Wissen ist keineswegs strikt mit dieser Materialisierung verbunden. Expliziertes Wissen ist generell nicht ﬁx an ein bestimmtes Medium und damit an eine bestimmte Materialität gebunden, sondern kann erklärt, aufgeschrieben, gedruckt oder eingetippt werden. Dabei ergeben sich bestimmte, medienspeziﬁsche Veränderungen, sowohl auf der Produktions- wie auf der Rezeptionsseite. In Buchform expliziertes Wissen konnte und kann deshalb durch die Verbreitung der Buchdrucktechnologie, wenn es denn über den Markt die Öffentlichkeit erreicht, kopiert bzw. nachgedruckt werden, und zwar, gemäß dem entscheidenden Kriterium auf dem Markt, billiger. Sei es, daß beim Nachdruck billigeres Papier, billigere Schrifttypen, billigere (oder gar keine) Illustrationen verwendet werden, oder sei es, daß die aufwendige Herausgeber- oder Autorenarbeit eingespart wird. Die Verwertung des gedruckten Buches in Warenform war also mit der schnellen Verbreitung der neuen Technologie bedroht durch Konkurrenz, die denselben Inhalt in einer billigeren Version anbieten konnte. Das Eigentum an den bereits gedruckten, aber noch nicht verkauften Exemplare wurde durch einen billigeren Nachdruck keineswegs angegriffen. Gefährdet war aber der weitere Verkauf, und damit der gesamte Verwertungsprozeß, der aufwendiger produzierten Bücher. Für die Drucker/Verleger waren enorme Investitionen mit dem neuen typographischen Medium verbunden: die neue Hochtechnologie war teuer und arbeitsaufwendig: Presse, Schriften, Papier, Gehilfen, Illustratoren, Herausgeber etc. wollten bezahlt werden.216 Der gesamte Produktionsprozeß war nur durch den Verkauf möglichst vieler Buchexemplare an anonyme Käufer zu ﬁnanzieren. Diese Finanzierung war aber bedroht, sobald ein billigerer Nachdruck auf den Markt kam.217 So kam es bereits 1469 in Venedig zu einem ersten Druck216 Vgl. zu den Kosten etwa den Rechtsstreit den Gutenberg mit dem Investor und späteren Konkurrenten Johannes Fust hatte (Febvre und Martin 1976: 55). 217 Oder rechtsgeschichtlich formuliert: »D[er wirtschaftliche Wert] entstand vielmehr erst dann, wenn das Ergebnis der Urhebertat (das Werk) den Prozeß der Vergewerblichung vollzogen hatte und zum Handelsobjekt geworden war.« Bappert 1962: 98.

222

6 Offene Wissensökonomie

privileg, dem Schutz des sog. »geistigen Eigentums«, für Johann von Speyer durch die Obrigkeit. Geschützt wurde für fünf Jahre eine Ausgabe von Plinius’ Historia naturalis, in der viel editorische Vorarbeit steckte (Gieseke 1995: 15). Der Schutz erstreckte sich auf das venezianische Herrschaftsgebiet und untersagt wurde der Verkauf von anderen Ausgaben dieses Werkes als der Speyerschen. Damit erhielt der Druckerverleger ein zeitlich und räumlich begrenztes Monopol für das von ihm gedruckte Werk. Diese Korrektur der Marktmechanismen durch obrigkeitliche Eingriffe steuert direkt die Verteilungswege des gedruckten Wissens. In der Folgezeit wurden viele dieser Privilegien für einzelne Bücher oder ganze Verlagsprogramme erwirkt.218 Das waren befristete und meist nur auf das Verbot des Nachdrucks bezogene Urkunden für die Verleger/Drucker, die sich so ihren (Monopol-)Gewinn zumindest in einem begrenzten Gebiet sichern wollten und konnten. Autoren waren darin nur erwähnt, wenn sie sich am Herstellungsprozeß des Buches beteiligten. Aus diesen Sonderrechten hat sich schließlich im Verlauf des 18. und 19. Jahrhunderts das Urheberrecht entwickelt, wobei sich der Eigentumstitel langsam vom Verleger auf den Autor verschob (Gieseke 1995: 115 ff.). Dieser obrigkeitliche Schutz verband sich mit und impliziert letztendlich obrigkeitliche Kontrolle. Nur wenn die Buchmärkte auch kontrolliert wurden, konnten die Privilegien auch wirksam durchgesetzt werden. Hintergrund dieser Kontrollen waren keineswegs nur die Interessen der Druckerverleger: Bereits 1485 wurde das erste Zensuredikt, das bereits sämtliche volkssprachlichen Druckwerke betraf, erlassen, 1487 erfolgte die erste päpstliche Bulle, die Vorzensur befahl (Wittmann 1991: 26). Im weiteren Verlauf wurde die Zensurpraxis eng mit dem Privilegienwesen verbunden219 und Grundlage des modernen Urheberrecht. Auch darin geht es letztlich um die zeitlich begrenzte Garantie 218 »Daraus [aus der Nichtabschließbarkeit der Privilegienlisten] und aus den zahlreichen, das Privilegienwesen betreffenden Verordnungen muß man die Schlußfolgerung ziehen, daß die Gesellschaft im 16. Jahrhundert den Nachdruck ›in ziemlicher Zeit‹ einzuschränken suchte.«(Giesecke 1991: 451) Vereinzelt kam es aber auch zu Nachdruckgenehmigungen[!] für Werke, dür die ein übermäßiger Preis verlangt wurde (Gieseke 1995: 125) 219 Vgl. dazu auch Giesecke 1991: Abschn. 5.5.

6.2 Geistiges Eigentum und Wissen

223

eines Verbreitungsmonopols. Erst mit den Verwertungsmöglichkeiten des neuen Mediums Buchdruck ergibt sich die Idee des »geistigen Eigentums«: »Damals trat die Bedeutung des Standes der Vervielfältigungs- und Verbreitungstechnik und dadurch bedingter Verwertungsmöglichkeiten für die Rechtsentwicklung erstmals klar hervor. [. . .] Erst wenn bestimmte Verwertungsmöglichkeiten vorhanden sind oder neu entstehen, wird ja gefragt, wem sie zustehen sollen.« (Gieseke 1995: XIV) Die Verbreitung des Wissens war seit Beginn der Neuzeit an das in die Warenform des Buches gebrachte Wissen gebunden. Dabei war das Eigentumsrecht in den ersten Jahrhunderten des »Typographeums« (Giesecke 1991) immer beim Drucker/Verleger angesiedelt, der von Seiten der Obrigkeit ein regional und zeitlich beschränkte Monopole zugesichert erhielt (nicht selten verbunden mit Zensurmaßnahmen). Damit ist das »geistige Eigentum« in seiner Entstehung gebunden an die materielle, abgrenzbare Ware ›Buch‹, an die gedruckte Form von Wissen. Gleichzeitig zeigt sich gerade im früh einsetzenden Privilegienwesen die Problematik der Verwertung von Wissen. Zwar war die Vervielfältigungstechnologie keineswegs weit in der Gesellschaft verbreitet und verhältnismäßig teuer, aber bereits die wenigen Reproduktionsanlagen genügten, um die Ware ›Buch‹ in ihrer Verwertung zu gefährden. Autorisierung statt Verwertung – das Beispiel Astronomie Die Entwicklung der neuzeitlichen Wissenschaft korrespondiert eng mit den Verbreitungsmöglichkeiten des neuen Mediums. Das hat Eisenstein für die Entwicklung der Astronomie von Regiomontanus bis Newton gezeigt (Eisenstein 1979: 575 ff.). So wurde die Kommunikation der Wissenschaftler untereinander durch das neue Medium wesentlich gefördert und dadurch, daß überhaupt verschiedene Sterntafeln zur Verfügung standen, wurden der Vergleich und die Überprüfung der Daten angeregt. Erst damit konnte sich die Differenz wahr/falsch als grundlegend für die neuzeitlichen Wissenschaften etablieren (Giesecke 1991: 670 ff.). Aus der Rekonstruktion des Zusammenhangs von Druckerpresse und Wissenschaft wird aber auch klar, daß die Rolle

224

6 Offene Wissensökonomie

der Drucker und Verleger für die Astronomie durchaus problematisch war: Kopernikus’ De Revolutionibus wurde im 16. Jahrhundert nur einmal wiederaufgelegt, während antike astronomische Werke alleine im deutschsprachigen Raum 100 Neu- oder Wiederauﬂagen erfuhren (Eisenstein 1979: 615). Das im Medium inkorporierte Wissen war für die Verwertung nur insofern interessant, als es einen Markt ﬁnden mußte. Die Verleger hatten nur marginales Interesse und entsprechend marginalen Einﬂuß auf die wissenschaftsinternen Entwicklungen. Die Markterfordernisse führten zu einer Marginalisierung der wissenschaftlich wichtigen, aber komplexen und schwierigen Werke, weil populäre Darstellungen sich viel besser verkauften. Nichtsdestotrotz entsteht auf der Basis der neuen Medientechnologie eine europaweite wissenschaftliche Öffentlichkeit. Erst mit der Drucklegung wird Wissen gesellschaftlich und setzt sich gleichzeitig ab von den im Mittelalter gebräuchlichen Begriffen Arkanum, Geheimnis, Weisheit, Brauch oder Erfahrnis. Grundlage wissenschaftlichen Wissens wird die typographische Speicherung (Giesecke 1991: 677) in bzw. trotz der warenförmigen Verbreitung. Gerade das zeigt das zitierte Beispiel der Astronomie: daß sich die Wahrheit des kopernikanischen Modells letztendlich durchsetzte, war ein wissenschaftsinterner Prozeß, der gegen die Hindernisse der Verwertung und gegen die obrigkeitliche Zensur erfolgte. Bedingung dafür war die freie Verfügbarkeit des Wissens, frei nicht im Sinne von kostenlos, sondern von zugänglich. Das Wissen von Kopernikus, Kepler und Galilei war im »typographischen Speicher« vorhanden, war am Markt oder in Bibliotheken zugänglich, war nachprüfbar. Diese Verfügbarkeit konnte trotz des Verwertungsinteresses der Druckerverleger zumindest für eine europäische Elite sichergestellt werden, nicht zuletzt weil die Astronomen die Bedeutung des neuen Mediums erkannten: Tycho Brahe hatte seine eigene Druckerpresse, Kepler war stark in den typographischen Produktions- und Vertriebsprozeß seiner Werke involviert. Die gedruckten Sterntafeln waren billiger und vor allem exakter, als die handschriftlich angefertigten. Zentral für die Entwicklung der neuzeitlichen Wissenschaft war diese Möglichkeit der Verbreitung von gleichen Exemplaren des gedruckten Wissens. Die monopolisierte Verteilung des Wissens war in diesen Zusammenhängen insofern wichtig, als sie die Kontrolle der veröffentlichten Ergebnisse, und damit deren Auto-

6.2 Geistiges Eigentum und Wissen

225

risierung und Richtigkeit erleichterte. Nicht der Verwertungsaspekt sondern der Autorisierungsaspekt des monopolisierten Vertriebsweges ist entscheidend. Das Eigentum in der offenen Wissensökonomie Die historische Entwicklung des »geistigen Eigentums« hat gezeigt, daß hinter diesem Rechtsverhältnis von Beginn an Verwertungsinteressen standen, die eine monopolisierte Verteilung des Wissens erreichen wollten. Demgegenüber standen die Kommunikationsinteressen der sich entwickelnden Wissenschaft, deren Interesse in der kontrollierten Verteilung des ›wahren‹ Wissens lag. Im Gegensatz zur Durchsetzung des geistigen Eigentums an Software wird in der offenen Wissensökonomie die Ausschließbarkeit als Kriterium des Eigentumsbegriffes und -rechtes explizit abgelehnt. Im Gegenteil: was durch die GPL und andere F/OS-Lizenzen sichergestellt wird, ist ein Verzicht auf jegliche Einschränkung in der Nutzung bzw. Ausführung des Programmes. Zentrale Punkte sind die Verteilung und Vervielfältigung. Die weitere Distribution des unveränderten Programmes unterliegt nur der Pﬂicht, die Lizenz mit zu distribuieren. Die Bearbeitung eines Programmes ist ebenfalls uneingeschränkt erlaubt. Komplexer wird der Fall, wenn das Programm in veränderter Form weitergegeben wird. Dann muß zum einen die Änderung deutlich sichtbar gemacht werden und die Veränderungen müssen ebenfalls im offenen Wissenspool veröffentlicht werden (vgl. dazu Abschitt 3.2.3). Es wird also Wert auf die unbeschränkte Verteilung und Benutzbarkeit eines bestimmten Programmes gelegt. Das Kriterium des Eigentums wird statt an die Ausschließbarkeit an das Recht zur Verteilung einer autorisierten Version geheftet. Diese Änderung der sozialen Eigentumspraxis und des Eigentumsbegriffes entspricht den oben herausgearbeiteten Eigenschaften von Wissen und Software: er greift die nicht vorhandene Knappheit und die Weitergabe ohne Verzicht auf und macht sie zum Programm einer weitgehend unbeschränkten Distribution und Anwendung. Nur wenn Veränderungen vorgenommen werden, wenn also produktiv an dem Programm gearbeitet wird, greifen die Mechanismen dieser Lizenzen.220 Mit diesen auf dem Recht des 220 Im Falle der liberaleren BSD-Lizenz ist in diesem Fall (oder auch dem des erlaubten kommerziellen Vertriebes) zumindest eine Namensänderung notwendig.

226

6 Offene Wissensökonomie

»geistigen Eigentums« bzw. dem angelsächsischen Copyright fußenden Lizenzen wird eine Umdeﬁnition des Eigentums vorgenommen, die den Eigenschaften von Software besser angepaßt ist.

6.3 Jenseits der Tauschbeziehung Eine weitere für die Ökonomisierung wichtige Differenz zwischen offener Wissensökonomie und herkömmlicher Warenökonomie ergibt sich aus den Wissenseigenschaften in Bezug auf die schon mit der neuzeitlichen Eigentumspraxis gegebenen Tauschbeziehung: Software bzw. Wissen wird nicht getauscht wie andere, stärker an die jeweilige Materialität gebundene Waren, weil die Warenform Wissensprodukten nur unter rigiden juristischen Einschränkungen und entsprechend umfangreichen gesellschaftlichen Kontrollen durchgesetzt werden kann. Damit stellt sich generell die Frage, welche Rolle der Tausch in der Ökonomie des Wissens spielen kann bzw. welche Einﬂuß die Regulierungsmechanismen von Märkten auf diese Ökonomie haben. Dazu werden in einem ersten Schritt die Implikationen des Tauschparadigmas entwickelt. Eine Alternative der tauschförmigen Erklärung des ökonomischen Aspektes dieser Produktionsweise scheint der Gabentausch zu sein. Deshalb wird in einem zweiten Schritt die Möglichkeit erörtert, soziale Beziehungen in der Ökonomie auf den Gabentausch zu gründen. Schließlich wird als Alternative zu Markt- und Gabentausch der Begriff der Transfers entwickelt. Das Tauschparadigma Eine weitverbreitete Grundlage der Erklärung von sozialen Phänomenen ist der Rekurs auf Tauschprozesse. Etwa in der Form, daß versucht wird, alle oder zumindest viele Erscheinungen der Sozialwelt explizit auf der Grundlage von Tauschprozessen zu erklären. »Wechselwirkungen« (Simmel 1992) werden nicht nur in den explizit tauschfundierten Theorien von Homans (1968) oder Blau (1964) mit Bezug auf dieses Phänomen beschrieben. Auch die Beschreibungen und Modelle von Kommunikation, zu denken ist etwa an Luhmanns Kommunikationsmodell, und Interaktionen basieren häuﬁg explizit oder implizit auf dem Muster des Austauschs von »Dingen« zwischen zwei Akteuren. Das gilt um so mehr, je näher das zu untersuchende Phänomen am

6.3 Jenseits der Tauschbeziehung

227

ökonomischen Feld liegt. Eine Kritik dieser Tauschzentriertheit ﬁndet sich schon beim jungen Marx: »Die Nationalökonomie nun faßt das Gemeinwesen des Menschen, oder ihr sich betätigendes Menschenwesen, ihre ﬁxiert wechselseitige Ergänzung zum Gattungsleben, zum wahrhaft menschlichen Leben unter der Form des Austauschs und des Handels auf. [. . .] Die Gesellschaft, sagt Adam Smith, ist eine handelstreibende Gesellschaft. Jedes ihrer Glieder ist ein Kaufmann.« (Marx 1968: 451) Diese Diagnose der Tauschzentriertheit von Sozial- und Wirtschaftswissenschaften ist, so meine These, bis heute gültig, wie etwa der Blick in ein aktuelles Lehrbuch der Wirtschaftswissenschaften zeigt. Dort werden methodologischer Individualismus, Rationalverhalten, Eigennutzaxiom und soziale Tauschbeziehungen als Prinzipien der Analyse bezeichnet: »Die methodologische Sichtweise des Individualismus impliziert, daß die Individuen nicht isoliert in einem luftleeren Raum agieren, sondern in soziale Tauschbeziehungen miteinander treten. Diese Tauschprozesse erfolgen auf dem Markt, wo knappe materielle und immaterielle Güter nach dem Kriterium der subjektiven Nutzenbewertung getauscht werden.« (Behrends 2001: 6) Auch Stegbauer sieht in Austauschprozessen »den elementarsten Teil des Zusammenlebens« (Stegbauer 2002: 13) und in der Reziprozität die »vielleicht wichtigste Grundregel zur Stiftung von Beziehungen« (Stegbauer 2002: 19). Für ihn scheint, »angesichts einer Anzahl sich lösender Verbindungen, die Gegenseitigkeit eines der letzten universal gültigen beziehungstiftenden Regularien zu sein, die Bindungen produziert und reproduziert und auf diese Weise zur Herstellung eines gesellschaftlichen Gefüges, einer Struktur einen wesentlichen Beitrag leistet.« (Stegbauer 2002: 157) Dabei geht er davon aus, daß mit jedem Austauschprozeß auch ein Beziehungsvorgang verbunden ist. Diese Reduktion der sozialen Interaktionen auf den Tausch ist aber keineswegs einsichtig. Andere Formen und Aspekte von Beziehungen,

228

6 Offene Wissensökonomie

etwa Affektivität, werden so verdeckt oder ausgeblendet. Dieses Marktund Tauschparadigma wird jedoch auch von aktuellen Entwicklungen im ökonomischen Bereich selbst in Frage gestellt, wie etwa Milberg (2001) zeigt, der die Transfers innerhalb von transnationalen Konzernen, die kooperativen Abkommen zwischen ansonsten rivalisierenden Unternehmen und die Rolle des Staates in internationalen ökonomischen Beziehungen als Beispiele nennt. Auch die Untersuchungen von Sauer und Döhl zum »Ausbau unternehmensübergreifender Produktion zu weitverzweigten Produktionsnetzwerken« (Sauer und Döhl 1994: 213) zeigen eine Aushebelung der (Markt-)Tauschmechanismen durch die Bildung von vertragsförmig oder beteiligungsrechtlich abgesicherten Unternehmensnetzwerken. So bleibt als offene Frage, ob das markt- oder gabenförmige Tauschparadigma nicht zu reduktionistisch für eine Erfassung und Beschreibung der komplexen sozialen Wirklichkeit ist. Auch die vor allem ökonomischen Analysen der F/OSS stützen sich stark auf das Tauschparadigma. Die Rational Choice oder spieltheoretischen Ansätze versuchen, ausgehend von den Prämissen des methodologischen Individualismus, die kooperativen »Interaktionen« als Tauschbeziehungen zu zu erklären. Weber (2004) etwa legt den durchdachtesten Versuch einer solchen Analyse vor (auf Grundlage der Theorie kollektiver Aktion von Olson 1998), bleibt aber an entscheidenden Stellen immer wieder dem Tausch verhaftet und damit dem dieser Vorstellung zugrundeliegenden Begriff des privaten Eigentums. Seine zentrale Frage lautet: »Why would any person choose to contribute—voluntarily—to a public good that she can partake of, unchecked, as a free rider on the effort of others?« (Weber 2004: 9) Dahinter steht ein methodologischer Individualismus, der davon ausgeht, »that individuals respond to their envrionmentr, compare costs and beneﬁts of a behavioral choice, and will not choose to do actions that have more costs than beneﬁts.« (Weber 2004: 226) ›Kosten‹ und ›Nutzen‹ verweisen auf das im Hintergrund dieser Semantik stehende Tauschparadigma, auf Leistung und Gegenleistung als Resultate und Voraussetzungen des Verhaltens. Auch die Analysen im Rahmen des »Project Electronic Labour Markets« (PELM), die sich empirisch vor allem auf Daten aus dem KDEProjekt stützen, fußen, wie der Titel des Projektes bereits verrät auf dem tauschorientieren Ansatz der Institutionenökonomie (vgl. dazu

6.3 Jenseits der Tauschbeziehung

229

und Brand et al. 2005). Der Fehler in diesen Analysen liegt meines Erachtens in der Konzentration auf den Tauschbegriff, der eben den, wie abstrakt auch immer vermittelten, Bezug von auf Warenförmiges (oder in Warenform gebrachtes) bezogenen Handlungssequenzen aufeinander impliziert. Akteur1 tauscht Etwas1 gegen Etwas2 von Akteur2 . Beide Akteure haben vorher ein gesellschaftlich und gegenseitig anerkanntes Eigentumsverhältnis zu Etwas, verzichten im Akt des Tausches auf ihr jeweiliges Eigentum und haben nach dem Tauschakt das jeweils andere Etwas. Im von der konkreten Gegenständlichkeit abstrahierenden Tauschakt werden zudem die Tauschobjekte wertmäßig gleichgesetzt.221 Die oben entwickelten Eigenschaften von Wissen machen eine solche Subsumtion schwierig: http://www.soz.uni-frankfurt.de/arbeitslehre/pelm.html

1. Gerade aufgrund der Multiplikationsfähigkeit ist ein Tausch von Wissen gegen etwas anderes nicht notwendig. Akteur1 kann sein Wissen1 bzw. seine Software1 weggeben, ohne sie zu verlieren. 2. Aufgrund der fehlenden festen Verbindung von expliziertem Wissen mit einer bestimmten Materialität kann keineswegs von einer begrenzten Gegenständlichkeit ausgegangen werden. In diesem Zusammenhang kann dann auch wieder die von Stehr erwähnte Kontextsensitivität des Wissens wichtig werden. Ökonomisch ist hier die Stelle, an der Dienstleistungen, Schulungen etc. ins Spiel kommen. 3. Eine In-Wertsetzung des weggegebenen oder auch des empfangenen Wissens ist keineswegs notwendig; im Gegenteil: der Wert geht im Sinne der klassischen Arbeitswerttheorie und im Sinne der neoklassischen Grenznutzentheorie gegen Null.222

221 Zumindest nach Marx’ Theorie. Für die Grenznutzentheorie gilt eine unterschiedliche Bewertung der getauschten Gegenstände durch die tauschenden Akteure, wobei das Objekt des Gegenübers höher bewertet wird. Die Objekte werden aber in beiden Theoriekomplexen in eine Wertrelation gesetzt. 222 Das schließt eine subjektive Bewertung im Verhältnis zum vorhandenen Wissensvorrat oder eine Bewertung im Hinblick auf zukünftigen Nutzen oder Verwertungschancen keineswegs aus.

230

6 Offene Wissensökonomie

Das Tauschobjekt Wissen hat also einige Eigenschaften, die den Bedingungen und Implikationen eines marktförmigen Tausches keineswegs entsprechen. Wie oben entwickelt kann ein solcher Tausch unter Monopolbedingungen und entsprechenden rechtlichen Einschränkungen trotzdem stattﬁnden und ﬁndet auch täglich statt. Mit der Beantwortung der Frage nach den Implikationen des marktförmigen Tausches in der Wissensökonomie ist auch die Frage nach der Möglichkeit der Übertragung bzw. Anwendbarkeit der regulativen Prinzipien des Marktes auf die Produkte und ökonomischen Verhältnisse der Wissensproduktion und -distribution verbunden. Bevor jedoch diese Frage anhand der Praxis in der F/OSS näher ventiliert wird, soll ein ebenfalls auf den Tauschbegriff basiertes Modell für die Wissensproduktion in den neuen Medien und in der F/OSS kurz diskutiert werden. Gabentausch statt Markttausch? Eine Alternative zum marktförmigen Tausch ist für viele Kritiker des Marktes und seiner Mechanismen, nicht nur in der Erklärung des Distributionsmodells der F/OSS, der Gabentausch. Dieses aus ethnologischen Studien gewonnene ökonmische Modell wird häuﬁg gegen den Markttausch in Stellung gebracht. In einem ersten Schritt soll deshalb diese oft kulturkritische Positionierung eines Konzeptes der Ethnologie untersucht werden. Daran schließt eine Zusammenfassung der Versuche an, in denen die Ökonomie der digitalen Medien im Allgemeinen und der F/OSS im Besonderen mit dem Gabentausch erklärt werden soll. Die mit dem Gabentausch gesetzten Implikationen werden schließlich einer Überprüfung hinsichtlich ihres Erklärungspotentials für die Wissensökonomie unterzogen. Bereits mit dem grandiosen »Essai sur le don« hat Marcel Mauss den Begriff des Gabentausches mit einer doppelten Zielsetzung eingeführt: einerseits sollen analytische »archäologische Schlußfolgerungen hinsichtlich der Natur der menschlichen Transaktionen« gezogen werden und zusätzlich andererseits gesellschaftskritische, moralische Schlußfolgerungen, »da wir glauben, hier einen der Felsen gefunden zu haben, auf denen unsere Gesellschaften ruhen«. (Mauss 1997: 13f.) Kreutz (1997) greift diesen Gedanken auf und setzt die Marktwirtschaft insgesamt auf ein Gabenfundament: »Der Geschenketausch sichert somit das, was Durkheim

6.3 Jenseits der Tauschbeziehung

231

organische Solidarität genannt hat und ermöglicht so die soziale Integration innerhalb der von Beruf und Familie vorgegebenen Grenzen. Die durch die Rahmenbedinungen abgesteckten gesellschaftlichen Einheiten bleiben aber leer und funktionslos sofern sie nicht durch reziproken Tausch mit Gaben erfüllt werden. Nicht der zweckrationale, gewinnorientierte Tausch schafft somit primär die Vergesellschaftung der Individuen, sondern es ist umgekehrt so, daß der die individuellen Interessen zwar mitberücksichtigende aber nicht vorwiegend an ihnen ausgerichtete zeremonielle Tausch die soziale Integration sichert, auf deren Grundlage sich dann sekundär eine Marktgesellschaft organisieren kann. Die marktmäßigen, zweckrationalen Austauschprozesse gefährden dabei im Gegenteil sogar die soziale Integration, da sie die vordergründig sinnlos erscheinenden Geschenkzyklen ›wegrationalisieren‹. Die Eliminierung der Reziprozität vernichtet so die Integration und grundlegende Solidarität und entzieht damit dem gewinnorientierten Tausch die Grundlage. Die Verabsolutierung des Marktes vernichtet somit seine Existenzbedingungen.« (Kreutz 1997: 8) Der Markt gerinnt unter diesen Voraussetzungen schon in der Fragestellung zur »parasitäre[n] Interaktionsform« (ebd.). Diese These wird belegt mit Texten und Forschungen zu Tauschnetzwerken in Melanesien und Afrika, sowie einigen Beiträgen zur Generierung sozialer Ungleichheiten in europäischen Gesellschaften. Ähnlich der Ethnologe Elwert: Er will die Gabe aus ihrem Dasein als »Restkategorie« (Elwert 1991: 160) befreien und sie zu »einem zentralen Leistungsbereiche unseres Gesellschaftssystems« aufwerten, denn Gaben »hüllen samtgleich die Arbeitswelt aus« (Elwert 1991: 163). Auch in dem Sammelband »Ökonomie und Anthropologie« (Paul 1999) soll ökonomiekritisch die Erhebung des Tauschprinzips zum zentralen Mechanismus der Verständigung und des Interessensausgleichs kritisiert werden, weil eine solche Gesellschaft »an Zusammenhalt einbüßt und letztlich sogar in ihrem Bestand bedroht ist.« Um diese Entwicklung nicht wie Marx »als Entfremdung zu titulieren« wird auf die Gegenüberstellung von

232

6 Offene Wissensökonomie

»marktvermitteltem Tausch [. . . und] älteren Formen des Austauschs [. . .] auf die Unterscheidung nämlich von Gabe und Tausch« rekurriert. (Paul 1999: 12) Der Begriff des Gabentausches erhält oft die von Mauss gesetzte Doppelfunktion der Beschreibung und Analyse von Wirtschaftsformen in hochintegrierten, meist segmentär differenzierten Gesellschaften und der Kritik an den abstrakten, desintegrierenden, marktbasierten Tauschformen in differenzierten Gesellschaften. Die aus diesen Positionen heraus formulierte Kulturkritik erfolgt deshalb mit einem romantisierenden Gestus. Auch die Analysen sozialer Beziehungen in den computerbasierten Medien rekurrieren häuﬁg auf den Begriff der Gabe. Die Ökonomie des Netzes wird häuﬁg als Geschenkökonomie bezeichnet. Vorreiter in dieser Richtung war der Netzenthusiast der ersten Stunde, Howard Rheingold: »Gegenseitigkeit ist ein Schlüsselelement jeder marktorientierten Kultur. Aber die Übereinkommen, die ich beschreibe, erscheinen mir mehr als eine Art Ökonomie des Schenkens, bei der Menschen etwas füreinander tun aus dem Streben heraus, Verbindungen miteinander zu schaffen, als eines wohlkalkulierten Quidproquo. Wenn diese Geisteshaltung vorherrscht, dann erhält jeder ein klein wenig mehr, etwas Glanz überstrahlt die eher praktischen Transaktionen; verschiedenste Dinge werden durch sie möglich. Wenn jedoch eine Online-Gemeinschaft von Gewinnsucht und Konkurrenzdenken beherrscht wird, dann werden diejenigen, die Wertvolles beitragen könnten, sich passiv verhalten und ihre Ideen mit niemandem teilen.« (Rheingold 1994: 79) Rheingold stellt scharf getrennt »marktorientierte Kultur« und die »Ökonomie des Schenkens« gegenüber, wobei letztere nur positiv konnotiert wird. In seinem Gefolge machen sich andere daran, die neuen sozialen Beziehungen, die mit den »techno-tele-medialen Apparaten« (Derrida 1995: 129) entstehen, mit einer Geschenkökonomie zu erklären.

6.3 Jenseits der Tauschbeziehung

233

Anthropologischer orientiert ist die Metapher von Ghosh: er beschreibt die Ökonomie des Internet als »vast tribal cooking-pot [. . . ] The digital cooking-pot is obviously a vast cloning machine, dishing out not single morsels but clones of the entire pot.« (Ghosh 2000) Jede/r liefert eine Zutat und alle bekommen das komplette Essen und, bei entsprechenden Beiträgen/Zutaten, eine gute Reputation. Auch die vorsichtige Formulierung der »diffuse reciprocity«, wie sie Holtgrewe und Werle (2001: 62) verwenden, verweist auf die Annahme einer wie auch immer gearteten Reziprozität in der Produktion und Kooperation. Immer wird in diesen Erklärungen die archaische Form des Gabentausches parallelisiert mit der konstatierten neuen Geschenkökonomie und der marktförmigen Ökonomie als positives Exempel gegenübergestellt. Diese auf der Oberﬂäche teilweise einleuchtenden Erklärungen werden fragwürdig erstens wegen des romantischen, kulturkritischen Impetus’, der sich dahinter verbirgt: der archaische Gabentausch, neu aufgelegt in den computerbasierten Medien, gilt als Rettungsanker der Integration in einer differenzierten und komplexen modernen Gesellschaft. Das Modell des Gabentausches wird zweitens fragwürdig, wenn die Mechanismen dieser Tauschform genauer analysiert werden. Gabentausch, wie er von Mauss (1997), Sahlins (1972), Polanyi (1944) oder Bourdieu (1987) beschrieben wird, impliziert direkte Interaktionen, die enge persönliche Verpﬂichtungen auf der jeweiligen Gegenseite schaffen. Diese Verpﬂichtungen werden, wie Bourdieu (1987) mit seinem Begriff des symbolischen Kapitals herausgearbeitet hat, durch das hochintegrierte soziale Umfeld einer (Dorf-)Gemeinschaft abgesichert. Solche Interaktionen und solche hochintegrierten sozialen Umfelder sind in den medial-technischen Zusammenhängen nur schwer vorstellbar. Bereits die Verwendung des Begriffes »Interaktion« ist in diesen Zusammenhängen problematisch, wie Sutter (1999) und Wenzel (2001) gezeigt haben. Noch weniger vorstellbar ist der Verpﬂichtungscharakter bzw. die Durchsetzung einer solchen Verpﬂichtung. Um bei dem Besipiel der F/OSS zu bleiben: jede/r kann sich F/OS-Software herunterladen und benutzen, ohne irgendeine Form von Gegenleistung zu erbringen. Eine Kontrolle ist weder möglich noch gewollt, ebensowenig ist eine Verpﬂichtung zur Rückgabe in irgendeiner Weise

234

6 Offene Wissensökonomie

durchsetzbar.223 Voraussetzung für die Anwendung des Gabentausches als Beschreibungsmuster solcher medienbasierter Zusammenhänge ist die Verbindung von Handlungen zu interdependenten Handlungssequenzen. Zudem gelten die für den Warentausch von Wissen herausgearbeiteten Besonderheiten auch für den Gabentausch. Es wird nach wie vor getauscht, vielleicht mit anderen Zeithorizonten und in einem integrativerem Modus. Expliziertes Wissen fügt sich den damit gesetzten Implikationen jedoch keineswegs problemlos. Transfer statt Tausch In den durch computerbasierte Medien konstituierten Kooperationsformen sind die Grundbedingungen des Gabentausches, ein Interaktionsverhältnis und ein die Verpﬂichtungen absicherndes soziales Umfeld, nicht gegeben. Und die Ökonomisierung des digitalisierten Wissens braucht, damit Warentausch stattﬁnden kann, massive rechtliche Garantien (die um wirksam zu sein, auch exekutiert werden müssen). Beide Formen des Tausches, Markttausch und Gabentausch, sind aufgrund der von ihnen implizierten Voraussetzungen für eine Beschreibung der offenen Wissensökonomie nur eingeschränkt brauchbar. Sinnvoller erscheint es mir, statt von bilateralem Tausch von dem unilateralen Begriff des Transfers auszugehen. Damit erübrigt sich die Suche nach einem möglichen Zusammenhang zwischen zwei oder mehr nur medial verbundenen Handlungen. Die Multiplikationsfähigkeit des Wissens ist einfach in die Beschreibung zu integrieren, weil mit dem Transfer keineswegs der Verzicht auf die eigene Nutzung verbunden sein muß. Es entfällt ebenso die in den Tauschvorgänge implizierte Bewertungsakt. Die Probleme des abgrenzbaren Gegenstandscharakters und der Kontextgebundenheit von Wissen bleiben bestehen, die können nur durch begleitende Kommunikation gelöst werden (etwa in Form von schriftlicher Dokumentation). In der F/OS-Produktions- und Distribution lassen sich drei verschiedenen Typen des Transfers differenzieren: 223 Insofern wäre F/OS-Software vielleicht ein Fall der unmöglichen »reinen Gabe«: »Damit es Gabe gibt, ist es nötig, daß der Gabenempfänger nicht zurückgibt, nicht begleicht, nicht tilgt, nicht abträgt, keinen Vertrag schließt und niemals in ein Schuldverhältnis tritt.« (Derrida 1993: 24)

6.3 Jenseits der Tauschbeziehung

235

1. Die Zugänglichmachung von Programmcode auf einem öffentlichen Server: »Hochladen« (hier ist das Moment des Eigentums wichtig: die Autorisierung) 2. das sogenannte »Herunterladen« durch anonyme Benutzer und sonstige Akte der Distribution 3. die Rückmeldungen in Form von Bugreports, Patches etc. an den oder die Eigentümer der Software Diese drei Formen der Transferhandlung funktionieren, ohne daß die Handlungen in ihrem Erwartungshorizont aufeinander bezogen werden müßten, d. h. der Transfer vom Typ 1 muß zwar den mannigfaltigen Transfers der Typen 2 und 3 zeitlich vorausgehen. Aber der einzelne Transfer_2n ist keine verbundene Handlungseinheit mit Transfer_1n–1 oder Transfer_3n+1 . Das verbindende Element der Transfertypen bleibt letztlich der jeweilige Programmcode, um den es geht. Aber diese Verbindung ist zu abstrakt, als daß damit eine Einheit der darauf bezogenen Transfers hergestellt werden könnte. Damit ist der Weg frei, für eine getrennte Analyse der einzelnen Produktions- und Distributionsakte in ihrer Funktion, ihrer Bedeutung und ihrer Zuschreibung an Personen für die kooperative Herstellung von Software im Speziellen und eine neue Form der Ökonomisierung von Wissen im Allgemeinen.224 Die mit diesem Transferbegriff gegebene Befreiung von der Tauschförmigkeit, ob Markttausch oder Gabentausch, stellt eines der charakteristischen Merkmal der offenen Wissensökonomie dar. Die Speziﬁka des transferierten Wissens werden im Begriff des Transfers nicht verändert und die Analyse wird nicht von einer nicht vorhandenen Reziprozität getrübt. Das daneben zweite zentrale Merkmal der offenen Wissensökonomie ist der auf die Autorisierung und nicht auf die Ausschließbarkeit bezogene Eigentumsbegriff. Jede Beschränkung der Distribution wird vermieden, was der Multiplikationsfähigkeit von Wissen entspricht. Statt dessen wird Wert auf die Autorisierungsposition gelegt: wer darf die ›richtige‹ Version verteilen? Bzw: Wer darf 224 Vielleicht läßt sich über solche Analysen die Frage der Motivation durch Reputation, die in dieser Arbeit nur am Rande auftaucht, genauer beantworten als mit einem einfachen Rückgriff auf »gift culture«.

236

6 Offene Wissensökonomie

Transfers vom Typ 1 vornehmen? Das reﬂektiert noch einmal die Beobachtung, daß das Schreibrecht an den Codearchiven die wichtigste Abgrenzung innerhalb der Entwicklerzusammenhänge darstellt (vgl. Abschitt 4.2.1).

6.4 Finis opera Vor dem Hintergrund der konstitutiven Merkmale einer offenen Ökonomie des Wissens, des autorisierenden Eigentums und der nichttauschförmigen Transferbeziehungen läßt sich die konkrete »offene Wissensökonomie«, wie sie in der F/OSS praktiziert wird, abschließend zusammenfassen. Die Analyse der technischen Konstitutionsbedingungen hat gezeigt, daß Software in ihrer formalisierten, dekontextuierten Schriftlichkeit die entscheidende Rahmenbedingungen setzt für die neue selbstorganisierte Wissensproduktion von selbstbestimmten Programmierern. Das kann funktionieren, weil der Quelltext performativ-produktive und kommunikative Anschlüsse ermöglicht, und damit die Schwierigkeiten einer Kommunikation in den Medien der elektronischen Schriftlichkeit (vor allem Mailinglisten) in gewisser Weise eingegrenzt werden können. Gleichzeitig wird jedoch eine Wissensschwelle gesetzt: die Computeralphabetisierung, die mögliche Beteiligung einschränkt. Mit der Bedeutung der formalisierten Schriftlichkeit wird zudem die Übertragbarkeit des medienbasierten Kooperationsmodells auf andere Produktionsbereiche von Wissen schwierig. Wenn diese These der fundamentalen Bedeutung des Produktionsgegenstandes Software für diese Form der offenen Wissensökonomie zutrifft, bedeutet das auch, daß sich das Produktionsmodell nicht ohne weiteres auf andere Bereiche der (Wissens-)Produktion übertragen läßt.225 In der Analyse des projektübergreifenden Entwicklerdiskurses wurde entwickelt, daß jenseits aller Differenzen in den Semantiklinien die warenförmige Verwertung von Software über Lizenzgebühren abgelehnt wird. Der Diskurs kreist stattdessen um das gemeinsame Zentrum: die Schaffung und Sicherung eines allgemein zugänglichen Wissenspools, der die Möglichkeit der selbstbestimmten Arbeit der 225 Vgl. dazu etwa den Verlauf des OSCar-Projektes in Honsig 2006.

6.4 Finis opera

237

Entwickler garantieren soll. Daran schließt eine Praxis der Distribution an, rechtlich über an das geltende Urheberrecht angelehnten Lizenzen abgesichert, die eine exkludierende Aneignung dieses Pools verhindern soll. Dabei wird die Verwertung der geschaffenen Software über den Verkauf von mit der Software verbundenen Dienstleistungen (Schulungen, Anpassungen etc.) explizit gebilligt. Wenn die Selbstbestimmung der Entwickler in den technischen Entscheidungen gewahrt bleibt, ist auch die Beteiligung von Unternehmensakteuren möglich, solange sie den gemeinsamen Wissenspool anerkennen und sich daran beteiligen. Dann werden auch deren Verwertungsinteressen als legitim anerkannt. Diese diskursive Konstitution einer eigenständigen Form der Wissensproduktion und -distribution hat in der praktischen Ausgestaltung eine Vielfalt von Formen angenommen. In der ethnographischen Beschreibung hat sich gezeigt, daß für die alltägliche Produktion die computerbasierten Medien durchaus ausreichen. Für Fragen der Konzeption, der weiterreichenden Planung und vor allem für den nach wie vor wichtigen zwischenmenschlichen Bereich sind persönliche Treffen nicht zu ersetzen. Auch im Sinne der Stabilität und Dauerhaftigkeit der Projekte haben sich die in allen größeren und langfristigeren F/OSS-Projekten inzwischen institutionalisierten Konferenzen und Workshops bewährt. Zusätzlich wird versucht, die Schwierigkeiten der bedingungslos öffentlichen, computerbasierten Kommunikation mit Versuchen der Ausdifferenzierung der Kommunikationsinstrumente und mit Strategien der kommunikativen Schließung auszugleichen. In den bezogen auf den Wissensvorrat relativ homogenen Zusammenhängen ist das entscheidende Strukturierungsmerkmal das Schreibrecht an den Quelltextarchiven. Über einen länger dauernden Auswahlprozeß werden Neulinge kooptativ nach meritokratischen Kriterien über diese Schwellen hinweg in das so markierte engere Projektteam aufgenommen. Allen Projekten gemeinsam ist eine, meist von diesem Schreibrecht bestimmte, Trennung in Kern und Peripherie. Auf diesen allgemeinen Grundlagen hat sich ein breites Spektrum von unterschiedlichen Organisationsformen der Projekte entwickelt. In Bezug auf die zentrale Fragestellung nach der Möglichkeit einer nichtkapitalistisch organisierten Produktionsweise, die parallel zu einer kapitalistischen besteht, hat sich empirisch gezeigt, daß die Abgrenzung sich von seiten der F/OSS nur auf den Bereich der selbstbestimmten,

238

6 Offene Wissensökonomie

technischen Entscheidung und auf die Sicherung des gemeinsamen Wissenspools zielt. Diese Begrenzung des Eigenen ist es vor allem, die eine Koexistenz ermöglicht. Auf dieser Grundlage werden Kooperationsangebote pragmatisch angenommen und Problemstellungen akzeptiert. Ein Bereich, der erst beginnt sich zu entwickeln, sind die Rückwirkungen dieser offenen Wissensökonomie auf die kapitalistisch organisierte Wissensproduktion. Angesichts der Verbreitung von F/OSS und der Größe des bereits angehäuften Wissensvorrates, an dessen Akkumulation nicht zuletzt viele große und konkurrierende Unternehmen der IT-Branche beteiligt waren und sind, halte ich die Chancen des Fortbestandes der F/OSS für relativ groß, trotz der Gefahren, die mit einer eventuellen Verschärfung von Urheberrecht und Softwarepatenten verbunden sein können.226 Die Untersuchungen des letzten Kapitels haben versucht, die Analysen der offenen Wissensökonomie insofern zu vertiefen, als allgemeine Eigenschaften von Wissen herausgearbeitet wurden, die über das konkrete Beispiel F/OSS hinaus, den ökonomischen Umgang mit Wissen bestimmen. Die Multiplikationsfähigkeit von Wissen und die potentielle Zeit- und Ortlosigkeit des Wissensproduktes, nicht der Wissensproduktion, machen die Applikation der Warenform auf Wissen enorm aufwendig, sowohl in Hinsicht auf das Eigentumsrecht als auch in Hinsicht auf die Tauschprozesse. Beides ist jedoch für die Verwertung des Wissens als Ware notwendig. Hier liefert die offene Wissensökonomie ein Gegenmodell: Produziert wird F/OS-Software in einer spezialisierten Teilöffentlichkeit durch Experten, die aufgrund der Einstiegshürde »Computeralphabetisierung« eine relativ homogene Gruppe darstellen. Eine Partizipation ist jedoch auch Nichtexperten möglich, zumindest in den peripheren Bereich der Produktion, der pragmatischen Integration der Software in den je eigenen lebensweltlichen Kontext. Intensivere Beteiligung setzt jedoch Bereitschaft zur eigenständigen Akquisition des notwendigen Wissensvorrats voraus. Auch wenn dieses Produktionsmodell nicht ohne weiteres auf andere Bereiche der Wissensproduktion übertragen werden kann, so weist doch das Distributionsmodell durchaus solche 226 Zumindest in den von mir geführten Interviews wird dieser Bereich als die größte Bedrohung für die Zukunft der F/OSS gesehen.

6.4 Finis opera

239

Möglichkeiten der Übertragung auf andere Bereiche der Distribution von Wissen. Die Distribution der produzierten Software erfolgt nicht über die Warenform und den Tausch, sondern das autorisierte Wissen wird öffentlich über Transfers vom Typ 1 potentiell allen Interessierten zugänglich gemacht. Eine mögliche Verwertung basiert deshalb nicht auf Lizenzgebühren, sondern sozusagen auf den Kontextuierungs-Dienstleistungen wie Schulungen oder Anpassungen. Damit wird der Eigentumsbegriff am Wissen insofern invertiert, als nicht mehr die Ausschließbarkeit von der Nutzung an zentraler Stelle steht, sondern die Autorisierung des zu verbreitenden Wissens. Nachdem seit Jahrzehnten die um den Produktionsfaktor Wissen kreisende neue Ökonomie in Form einer Wissensgesellschaft angekündigt wird, ﬁndet sich in der Free/Open Source-Softwareentwicklung eine, neben der schon praktizierten kapitalistischen Form, eine alternative Umsetzung dieser These. Nicht unter den Vorzeichen der Ware, des Tausches und des exkludierenden Eigentums, sondern als offene Wissensökonomie. Dabei sind die von der F/OSS praktizierten ökonomischen Formen aufgrund der entwickelten Einschränkungen (noch?) keine Alternative zur kapitalistischen Warenökonomie insgesamt, sondern allenfalls in dem beschränkten Bereich der Softwareproduktion. Dort allerdings bestehen und funktionieren diese Formen bereits seit mehr als zwei Jahrzehnten. Die bisherigen Analysen haben gezeigt, daß sich die Warenform und die Form des ausschließenden Eigentums nicht ohne weiteres auf Software und Wissensprodukte übertragen läßt. Zum jetzigen Zeitpunkt ist jedoch noch nicht abzusehen, ob es sich bei der offenen Wissensökonomie um ein auf den Softwarebereich und zeitlich begrenztes Phänomen handelt, ob sich diese Entwicklung der Produktion und/oder Distribution stabilisieren und auf andere Teile oder gar die ganze gesellschaftliche Wissensproduktion ausdehnen wird oder ob sich hier eine Art »Parallelökonomie« für bestimmte Bereiche der Wissensproduktion etabliert, die zum einen Ausdifferenzierungen im ökonomischen System in Form von neuen Verwertungsmodellen triggert, zum zweiten die gesellschaftlichen Praxen im Umgang mit Wissen irritiert und zum dritten neue Möglichkeitshorizonte für eine Wissensgesellschaft öffnet.

Literaturverzeichnis Bappert, Walter (1962): Wege zum Urheberrecht. Die geschichtliche Entwicklung des Urheberrechtsgedankens. Vittorio Klostermann, Frankfurt/M. Baudrillard, Jean (1991): Der symbolische Tausch und der Tod. Matthes & Seitz, München. Frz. Orig. 1976. Bechtle, Günter (2003): Die Weltgesellschaft im Irgendwo und die Wissensgesellschaft als Umgang mit Nichtwissen: Atopia und Dystopia als neue Paradigmen von Gesellschaftstheorie. Soziologische Revue, 26:205 – 212. Behrends, Sylke (2001): Neue Politische Ökonomie. Systematische Darstellung und kritische Beurteilung ihrer Entwicklungslinien. Franz Vahlen, München. Beniger, James Ralph (1986): The control revolution. Harvard Univ. Press, Cambridge, Mass. Berger, Peter L. und Luckmann, Thomas (1998): Die gesellschaftliche Konstruktion der Wirklichkeit. Eine Theorie der Wissenssoziologie. Fischer Verlag, Frankfurt/M. Amer. Orig. 1966. Bischoff, Joachim (2001): Mythen der New Economy. Zur politischen Ökonomie der Wissensgesellschaft. VSA-Verlag, Hamburg. Blau, Peter M. (1964): Exchange and Power in Social Life. John Wiley & Sons, New York/London. Boltanski, Luc und Chiapello, Ève (2003): Der neue Geist des Kapitalismus. UVK Verlagsgesellschaft, Konstanz. Frz. Orig. 1999. Bolter, Jay David und Grusin, Richard (2000): Remediation. Unterstanding New Media. MIT Press, Cambridge/Ms. Bolz, Norbert, Kittler, Friedrich und Tholen, Christoph, (Hg.) (1994): Computer als Medium. Wilhelm Fink Verlag, München. Bourdieu, Pierre (1987): Sozialer Sinn. Kritik der theoretischen Vernunft. Suhrkamp Verlag, Frankfurt/M. Frz. Orig. 1980.

242

Literaturverzeichnis

Brand, Andreas und Schmid, Alfons (2005): Koordination in einem Open SourceProjekt. http://www.soz.uni-frankfurt.de/arbeitslehre/pelm/docs/KOORDINATION_IN_ OPEN_SOURCE-PROJEKT_Brand-Schmid.pd. Arbeitspapier aus dem Project Electronic Labor Markets (PELM). Brand, Andreas et al. (2005): Elektronische Arbeitsmärkte. Empirie der Struktur und Funktionsweise elektronischer Arbeitsmarktplätze in Teilarbeitsmärkten. Hampp Verlag, München. Brooks, Frederic P. Jr. (2001): The Mythical Man-Month. Essays on SoftwareEngineering. Anniversary Edition. Addison-Wesley, Boston, 2. Auﬂ. Buck, Harald (1999): Kommunikation in elektronischen Diskussionsgruppen. http: //www.websprache.uni-hannover.de/networx/docs/networx-11.pdf. Download vom 27.05.2002. Burke, Peter (2002): Papier und Marktgeschrei. Die Geburt der Wissensgesellschaft. Verlag Klaus Wagenbach, Berlin. Engl. Orig. 1997. Certeau, Michel de (1988): Kunst des Handelns. Merve Verlag, Berlin. Frz. Orig. 1980. Coleman, E. Gabriella (2005): Three Ethical Moments in Debian: The Making of an (ethical) Hacker, Part III, Kap. 6. http://healthhacker.org/~biella, Download v. 7.9.2005. Conrad, Michael (1995): The Price of Programmability. In: The Universal Turing Machine (herausgegeben von Herken, Rolf), Springer-Verlag, Wien/New York, S. 262 – 281. 2. Auﬂ. Cullenberg, Stephen, Amariglio, Jack und Ruccio, David F., (Hg.) (2001): Postmodernism, Economics and Knowledge. Routledge, London/New York. Degele, Nina (1995): Vom Nutzen nicht genutzter Expertensysteme. In: Soziologie und künstliche Intelligenz. Produkte und Probleme einer Hochtechnologie (herausgegeben von Rammert, Werner), Campus Verlag, Frankfurt/New York, S. 275 – 298. Degele, Nina (2000): Informiertes Wissen. Eine Wissenssoziologie der computerisierten Gesellschaft. Campus Verlag, Frankfurt/New York. DeLong, J. Bradford und Zoomkin, A. Michael (2000): Speculative Microeconomics for Tomorrow’s Economy. First Monday, 5(2). http://www.ﬁrstmonday.org/ issues/issue5_2/delong/index.html.

Literaturverzeichnis

243

Derrida, Jacques (1976): Die Schrift und die Differenz. Suhrkamp, Frankfurt/M. Frz. Orig. 1967. Derrida, Jacques (1988): Die Différance. In: Randgänge der Philosophie, Passagen Verlag, Wien, S. 31 – 56. Frz. Orig. 1972. Derrida, Jacques (1993): Falschgeld. Zeit geben I. Wilhelm Fink Verlag, München. Frz. Orig. 1991. Derrida, Jacques (1995): Marx’ Gespenster. Der verschuldete Staat, die Trauerarbeit und die neue Internationale. Fischer Taschenbuch Verlag, Frankfurt/M. Frz. Orig. 1993. DiBona, Chris, Ockman, Sam und Stone, Mark, (Hg.) (1999): Open Sources: Voices from the Open Source Revolution. O’Reilly, Sebastopol/CA. Dollhausen, Karin und Hörning, Karl H. (1996): Die kulturelle Produktion der Technik. Zeitschrift für Soziologie, 25(1):37 – 57. Drucker, Peter F (1993): Die post-kapitalistische Gesellschaft. ECON, Düsseldorf/Wien. Durkheim, Emile (1977): Über die Teilung der sozialen Arbeit. Suhrkamp, Frankfurt/M. Edwards, Paul N. (1996): The Closed World. Computers and the Politics of Discourse in Cold War America. The MIT Press, Cambridge, Mass. Eisenstein, Elisabeth L. (1979): The Printing Press as an agent of change. Volumes I and II. Cambridge University Press, Cambridge/New York. Elwert, Georg (1991): Gabe, Reziprozität und Warentausch. Überlegungen zu einigen Ausdrücken und Begriffen. In: Ethnologie im Widerstreit. Kontroversen über Macht, Geschäft, Geschlecht in fremden Kulturen. Festschrift für Lorenz G. Löfﬂer (herausgegeben von Berg, Eberhard, Lauth, Jutta und Wimmer, Andreas), Trickster Verlag, München, S. 159 – 178. Engelbart, Douglas C. und English, William K. (1968): A Research Center for Augmenting Human Intellect. Proceedings of the 1968 Fall Joint Computer Conference, S. 395 – 410. Esposito, Elena (1993): Der Computer als Medium und Maschine. Zeitschrift für Soziologie, 22:338 – 354.

244

Literaturverzeichnis

Esposito, Elena (1995): Interaktion, Interaktivität und Personalisierung der Massenmedien. Soziale Systeme, 2:225 – 260. Esposito, Elena (2002): Soziales Vergessen. Formen und Medien des Gedächtnisses der Gesellschaft. Suhrkamp, Frankfurt/M. Febvre, Lucien und Martin, Henri-Jean (1976): The Coming of the Book. The Impact of Printing 1450 - 1800. Verso, London/New York. Frz. Orig. 1958. Foucault, Michel (1966): Les mots et les choses. Une Archéologie des sciences humaines. Gallimard, Paris. Foucault, Michel (1995): Archäologie des Wissens. Suhrkamp, Frankfurt/M. Frz. Orig. 1969. German, Daniel M. (2003): The GNOME Project: a Case Study of Open Source, Global Software Development. Software Process Improvement and Practice, 8:201 – 215. Ghosh, Rishab Aiyer (2000): Cooking pot markets: an economic model for the trade in free goods and services on the internet. http://www.ﬁrstmonday.org/issues/ issues3_3/ghosh/index.html. Download v. 16.12.02. Ghosh, Rishab Aiyer (2005): Understanding Free Software Developers: Findings from the FLOSS Study. In: Perspectives on Free and Open Source Software (herausgegeben von Feller, Joseph et al.), MIT Press, Boston/Mass., S. 23 – 46. Gibbons, Michael et al. (1994): The New Production of Knowledge. The Dynamics of Science and Research in Contemporary Societies. SAGE, London, 6. Auﬂ. Giesecke, Michael (1991): Der Buchdruck in der frühen Neuzeit. Eine historische Fallstudie über die Durchsetzung neuer Informations- und Kommunikationstechnologien. Suhrkamp, Frankfurt/M. Gieseke, Ludwig (1995): Vom Privileg zum Urheberrecht. Verlag Otto Schwartz & Co., Göttingen. Grassmuck, Volker (2002): Freie Software. Zwischen Privat- und Gemeineigentum. Bundeszentrale für politische Bildung, Bonn. Gräf, Lorenz und Krajewski, Markus, (Hg.) (1997): Soziologie des Internet. Handeln im elektronischen Web-Werk. Campus, Frank/New York.

Literaturverzeichnis

245

Grüter, Barbara Maria (1997): Der Sinn des Rechners. Über die andere Seite des formalen Denkens. In: Technik und Subjektivität. Das Wechselverhältnis zwischen Mensch und Computer aus interdisziplinärer Sicht (herausgegeben von Schachtner, Christine), Suhrkamp, Frankfurt/M, S. 106 – 127. Habermas, Jürgen (1973): Technik und Wissenschaft als ›Ideologie‹. Suhrkamp Verlag, Frankfurt/M. Hajer, Maarten A. (1995): The Politics of Environmental Discourse. Ecological Modernization and the Policy Process. Clarendon Press, Oxford. Halfmann, Jost (1984): Die Entstehung der Mikroelektronik. Zur Produktion des technischen Fortschritts. Campus, Frankfurt/New York. Haug, Wolfgang Fritz (2003): High-Tech-Kapitalismus. Analysen zu Produktionsweise, Arbeit, Sexualität, Krieg und Hegemonie. Argument, Hamburg. Hegel, Georg Wilhelm Friedrich (1995): Grundlinien der Philosophie des Rechts. Felix Meiner, Hamburg. In der Textedition von Johannes Hoffmeister. Heidegger, Martin (2001): Sein und Zeit. Max Niemeyer Verlag, Tübingen, 18. Auﬂ. Heintz, Bettina (1993): Die Herrschaft der Regel. Zur Grundlagengeschichte des Computers. Campus Verlag, Frankfurt/New York. Henkel, Joachim (2003): Open-Source-Aktivitäten von Unternehmen. Innovation in kollektiven Prozessen. Dissertation, Fakultät für Betriebswirtschaft der Ludwig-Maximilians-Universität München, München. Hoffmann, Ludger (2004): Chat und Thema. OBST (Osnabrücker Beiträge zur Sprachtheorie), (68):102 – 122. Hofmann, Jeanette (1997): Über Nutzerbilder in Textverarbeitungsprogrammen Drei Fallbeispiele. In: Technikgenese. Befunde aus einem Forschungsprogramm (herausgegeben von Dierkes, Meinolf), Edition Sigma, Berlin, S. 71 – 98. Holtgrewe, Ursula (2000): Kreativität als Norm zum Erfolg verdammt? OpenSource- Software zwischen sozialer Bewegung und technischer Innovation. In: Gute Gesellschaft? Verhandlungen des 30. Kongresses der Deutschen Gesellschaft für Soziologie in Köln 2000 (herausgegeben von Allmendinger, Jutta), Leske + Budrich, Kap. Opladen, S. 399 – 424.

246

Literaturverzeichnis

Holtgrewe, Ursula (2004): Articulating the Speed(s) of the Internet. The case of open Source/free software. Time & Society, 13(1):129 – 146. Holtgrewe, Ursula und Werle, Raymund (2001): De-Commodifying Software? Open Source Software Between Business Strategy and Social Movement. Science Studies, 14(2):43 – 65. Homans, George Caspar (1960): Theorie der sozialen Gruppe. Westdeutscher Verlag, Köln/Opladen. Amer. Orig. 1950. Homans, George Caspar (1968): Elementarformen sozialen Verhaltens. Westdeutscher Verlag, Köln [u.a.]. Honsig, Markus (2006): Das offenste aller Autos. Technology Review, (Nr. 2, Februar):46 – 53. Hörning, Karl H. (1995): Technik und Kultur. Ein verwickeltes Spiel der Praxis. In: Technik und Gesellschaft: Jahrbuch (herausgegeben von Halfmann, Jost, Bechmann, Gotthard und Rammert, Werner), Campus Verlag, Frankfurt/New York, Bd. 8, S. 131 – 152. Husserl, Edmund (1992): Die Krisis der europäischen Wissenschaften und die transzendenale Phänomenologie, Bd. 8 von Edmund Husserl: Gesammelte Schriften in acht Bänden. Felix Meiner Verlag, Hamburg. IfrOSS (Institut für Rechtsfragen der freien und Open Source Software) (2005): Die GPL kommentiert und erklärt. O’Reilly, Sebastopol/CA. Jäckel, Michael und Mai, Manfred, (Hg.) (2005): Online-Vergesellschaftung? Mediensoziologische Perspektiven auf neue Kommunikationstechnologien. VS Verlag für Sozialwissenschaften, Wiesbaden. Jäger, Ludwig (2003): Störung und Transparenz. Skizze zur performativen Logik des Medialen. In: Performativität und Medialität (herausgegeben von Krämer, Sybille), Wilhelm Fink Verlag, München, S. 35 – 73. Keller, Reiner (2001): Wissenssoziologische Diskursanalyse. In: Keller et al. (2001), S. 113 – 143. Keller, Reiner (2003): Der Müll der Gesellschaft. Eine wissenssoziologische Diskursanalyse. In: Handbuch Sozialwissenschaftliche Diskursanalyse Band 2: Forschugnspraxis (herausgegeben von Keller, Reiner et al.), Leske + Budrich, Opladen, S. 197 – 232.

Literaturverzeichnis

247

Keller, Reiner (2005): Wissenssoziologische Diskursanalyse. Grundlegung eines Forschungsprogramms. VS Verlag für Sozialwissenschaften, Wiesbaden. Keller, Reiner et al., (Hg.) (2001): Handbuch Sozialwissenschaftliche Diskursanalyse. Band I: Theorien und Methoden. Leske + Budrich, Opladen. Kellner, Hansfried und Heuberger, Frank (1988): Die Einheit der Handlung als methodologisches Problem. Überlegungen zur Adäquanz wissenschaftlicher Modellbildung in der sinnverstehenden Soziologie. In: Alfred Schütz. Neue Beiträge zur Rezeption seines Werkes (herausgegeben von List, Elisabeth und Srubar, Ilja), Rodopi, Amsterdam, S. 257 – 284. Kittler, Friedrich (1996): Computeranalphabetismus. In: Literatur im Informationszeitalter (herausgegeben von Matjekowski, Dirk und Kittler, Friedrich), Campus Verlag, Frankfurt/New York, S. 237 – 251. Kittler, Friedrich A. (1986): Grammophon Film Typewriter. Brinkmann & Bose, Berlin. Kittler, Friedrich A. (1993a): Draculas Vermächtnis. Technische Schriften. Reclam, Leipzig. Kittler, Friedrich A. (1993b): Es gibt keine Software. In: Kittler (1993a), S. 225 – 242. Kittler, Friedrich A. (1993c): Protected Mode. In: Kittler (1993a), S. 208 – 224. Kittler, Friedrich A. (1995): Aufschreibesysteme 1800 · 1900. Wilhelm Fink Verlag, München, 3. Auﬂ. Klapp, Orrin E. (1978): Opening and Closing. Strategies of information adaption in society. Cambridge University Press, Cambridge/Ms. Klodt, Henning (2001): The Essence of the New Economy. Institut für Weltwirtschaft, Kiel. Knoblauch, Hubert (1995): Kommunikationskultur. Die kommunikative Konstruktion kultureller Kontexte. de Gruyter, Berlin, New York. Knorr Cetina, Karin (1998): Sozialität mit Objekten. Soziale Beziehungen in post-traditionalen Wissensgesellschaften. In: Technik und Sozialtheorie (herausgegeben von Rammert, Werner), Campus Verlag, Frankfurt/New York, S. 83 – 120.

248

Literaturverzeichnis

Krämer, Sybille, (Hg.) (2000): Medien Computer Realität. Wirklichkeitsvorstellungen und Neue Medien. Suhrkamp, Frankfurt/M, 2. Auﬂ. Kreutz, Henrik, (Hg.) (1997): leben und leben lassen. Die Fundierung der Marktwirtschaft durch symbolischen Tausch und Reziprozität. Leske + Budrich, Opladen. Krippendorf, Klaus (1994): Der verschwundene Bote. Metaphern und Modelle der Kommunikation. In: Die Wirklichkeit der Medien (herausgegeben von Merten, Klaus, Schmidt, Siegfried J. und Weischenberg, Siegfried), Westdeutscher Verlag, Opladen, S. 79 – 113. Krämer, Sybille (1988): Symbolische Maschinen. Die Idee der Formalisierung in geschichtlichem Abriß. Wissenschaftliche Buchgesellschaft, Darmstadt. Krämer, Sybille (1991): Berrechenbare Vernunft. Kalkül und Rationalität im 17. Jahrhundert. Walter de Gruyter, Berlin/New York. Krämer, Sybille (1997): Vom Mythos »Künstliche Intelligenz« zum Mythos »Künstliche Kommunikation oder: Ist eine nicht-anthropomorphe Beschreibung von Internet-Interaktionen möglich? In: Münker und Roesler (1997), S. 83 – 107. Krämer, Sybille (2000): Das Medium als Spur und Apparat. In: Krämer (2000), S. 73 – 94. Lakhani, Karim R., Wolf, Bob und Bates, Jeff (2002): The Boston Consulting Group Hacker Survey. http://www.osdn.org/bcg. Version 0.3, Download v. 03.02.2002. Lang, Christoph (2003): Informationsgüter als öffentliche Güter – Tragödie der Urheberrechte am Beispiel des deutschen Musikmarktes. Magisterarbeit, FriedrichAlexander-Universität Erlangen-Nürnberg, Erlangen. Latour, Bruno (2000): Die Hoffnung der Pandora. Untersuchungen zur Wirklichkeit der Wissenschaft. Suhrkamp Verlag, Frankfurt/M. Amer. Orig. 1999. Leibniz, Gottfried Wilhelm (1703): Explication de L’Aritmètique Binaire. Histoire de L’Acadamie Royale des Sciences 1703, S. 85 – 89. Faksimileabdruck in Siemens Aktiengesellschaft (1966): Herrn von Leibniz’ Rechnung mit Null und Eins.

Literaturverzeichnis

249

Lerner, Joshua und Tirole, Jean (1999): The Simple Economics of Open Source. Working Paper 7600. National Bureau of Economic Research, Cambridge/Mass. Lévi-Strauss, Claude (1997): Das wilde Denken. Suhrkamp Verlag, Frankfurt/M. Frz. Orig. 1962. Levy, Stephen (2001): Hackers. Heroes of the Computer Revolution. Penguin Books, New York, 3. Auﬂ. Locke, John (1967): Zwei Abhandlungen über die Regierung. Europäische Verlagsanstalt, Frankfurt/Wien. Luhmann, Niklas (1984): Soziale Systeme. Grundriß einer allgemeinen Theorie. Suhrkamp Verlag, Frankfurt/M. Luhmann, Niklas (1997): Die Gesellschaft der Gesellschaft. 2 Teilbände. Suhrkamp, Frankfurt/M. Lundstrom, David E. (1987): A few good men from Univac. MIT Press, Boston. Marx, Karl (1957): Aus der Kritik der Hegelschen Rechtsphilosophie, Dietz Verlag, Berlin, Bd. 1 von MEW, S. 201 – 333. Marx, Karl (1968): Auszüge aus James Mills Buch »Élémens d’économie politique«. In: Karl Marx/Friedrich Engels Werke. Ergänzungsband (MEW 41), Dietz Verlag, Berlin, S. 443 – 463. Marx, Karl (1979): Das Kapital. Kritik der Politischen Ökonomie. Bd. 1 Der Produktionsprozeß des Kapitals, Bd. 23 von MEW. Dietz Verlag, Berlin. Orig. 1867. Mauss, Marcel (1997): Die Gabe. Form und Funktion des Austauschs in archaischen Gesellschaften. In: Soziologie und Anthropologie, Fischer Taschenbuch Verlag, Frankfurt/M, Bd. 2, S. 9 – 144. Frz. Orig. 1925. McKusick, Marshall Kirk (1999): Twenty Years of Berkeley Unix: From AT&TOwned to Freely Redistributable. In: DiBona et al. (1999), S. 31 – 46. McLuhan, Marshall (1995): Die magischen Kanäle. Understanding media. Verlag der Kunst, Dresden/Basel. Amer. Orig. 1964. Merten, Klaus (1999): Einführung in die Kommunikationswissenschaft, Bd. 1/1: Grundlagen der Kommunikationswissenschaft. LIT, Münster.

250

Literaturverzeichnis

Metzinger, Thomas (1993): Subjekt und Selbstmodell. Die Perspektivität phänomenalen Bewußtseins vor dem Hintergrund einer naturalistischen Theorie mentaler Repräsentation. Ferdinand Schöningh, Paderborn. Milberg, William (2001): Decentering the market metaphor. In: Cullenberg et al. (2001), S. 407 – 430. Mockus, Audris, Fielding, Roy T. und Herbsleb, James D. (2002): Two Case Studies of Open Source Software Development: Apache and Mozilla. http://www.research.avayalabs.com/techreport/ALR-2002-003-paper.pdf. Download v. 17.05.2005. Münker, Stefan und Roesler, Alexander, (Hg.) (1997): Mythos Internet. Suhrkamp, Frankfurt/M. Musil, Robert (1978): Der Mann ohne Eigenschaften. Rowohlt, Reinbek. Original 1932. Nowotny, Helga, Scott, Peter und Gibbons, Michael (2001): Re-Thinking Science. Knowledge and the Public in an Age of Uncertainty. Polity Press (Blackwell), Cambridge. Olson, Mancur (1998): Die Logik des kollektiven Handelns. Kollektivgüter und die Theorie der Gruppen. Mohr Siebeck, Tübingen, 4. Auﬂ. Paul, Axel T., (Hg.) (1999): Ökonomie und Anthropologie. Studien des Frankreich-Zentrums der Albert-Ludwigs-Universität Freiburg; Bd. 5. Berlin Verlag Arno Spitz, Berlin. Polanyi, Karl (1944): The Great Transformation. Beacon Press, Boston. Poster, Mark (1997): Elektronische Identitäten und Demokratie. In: Münker und Roesler (1997), S. 147 – 170. Putnam, Hilary (1988): Representation and Reality. Bradford Book, Cambridge, Ma. Rammert, Werner (1995): Regeln der technikgenetischen Methode. Die soziale Konstruktion der Technik und ihre evolutionäre Dynamik. In: Technik und Gesellschaft: Jahrbuch (herausgegeben von Halfmann, Jost, Bechmann, Gotthard und Rammert, Werner), Campus Verlag, Frankfurt/New York, Bd. 8, S. 13 – 30.

Literaturverzeichnis

251

Rammert, Werner (1998a): Die Form der Technik und die Differenz der Medien. Auf dem Weg zu einer pragmatistischen Techniktheorie. In: Rammert (1998b), S. 293 – 326. Rammert, Werner, (Hg.) (1998b): Technik und Sozialtheorie. Campus Verlag, Frankfurt/New York. Rammert, Werner (2006): Die technische Konstruktion als Teil der gesellschaftlichen Konstruktion der Wirklichkeit. In: Tänzler et al. (2006), S. 13 – 30. Rammert, Werner et al. (1998): Wissensmaschinen. Soziale Konstruktion eines technischen Mediums. Das Beispiel Expertensysteme. Campus Verlag, Frankfurt/New York. Rautenberg, Ursula (1999): Das Werk als Ware. Der Nürnberger Kleindrucker Hans Folz. Internationales Archiv für sozialgeschichte der deutschen Literatur, 24(1):1 – 40. Raymond, Eric S. (2001a): A brief history of hackerdom. In: Raymond (2001b), S. 1 – 18. Raymond, Eric S. (2001b): The Cathedral and the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly, Sebastopol/CA, 2. Auﬂ. Raymond, Eric S. (2001c): Homesteading the Noosphere. In: The Cathedral and the Bazaar (herausgegeben von Raymond, Eric S.), O’Reilly, Sebastopol/CA, S. 65 – 112. 2. Auﬂ. Auch (und dt.): http://www.tuxedo.org/~esr/writings/ homesteading. Renn, Joachim (2006): Die Differenz der Medien. Die Ambivalenz systemtheoretischer Medienkonzeptionen als Indiz für eine notwendige Pragmatisierung der Systemtheorie. In: Medien der Gesellschaft – Gesellschaft der Medien (herausgegeben von Ziemann, Andreas), UVK Verlagsgesellschaft, Konstanz, S. 57 – 86. Rheingold, Howard (1994): Virtuelle Gemeinschaft: Soziale Beziehungen im Zeitalter des Computers. Addison-Wesley, Bonn/Paris. Amer. Orig. 1993. Rheingold, Howard (2000): The Virtual Community: Homesteading on the Electronic Frontier, revised edition. The MIT Press. Roesler, Alexander (1997): Bequeme Einmischung. Internet und Öffentlichkeit. In: Münker und Roesler (1997), S. 171 – 192.

252

Literaturverzeichnis

Rosa, Hartmut (2005): Beschleunigung. Die Veränderung der Zeitstrukturen in der Moderne. Suhrkamp, Frankfurt/M. Rudy, I. A. (1996): A critical review of research on electronic mail. European Journal of information systems, 4:198 – 213. Sahlins, Marshall (1972): Stone Age Economics. Aldine de Gruyter, New York. Sauer, Dieter und Döhl, Volker (1994): Arbeit an der Kette. Systemische Rationalisierung unternehmensübergreifender Produktion. Soziale Welt, 45:197 – 215. Schmidt, Christian (2006): Individualität und Eigentum. Zur Rekonstruktion zweier Grundbegriffe der Moderne. Campus Verlag, frankfurt/new york Auﬂ. Schmiede, Rudi (1996): Informatisierung, Formalisierung und kapitalistische Produktionsweise. Entstehung der Informationstechnik und Wandel der gesellschaftlichen Arbeit. In: Virtuelle Arbeitswelten. Arbeit, Produktion und Subjekt in der »Informationsgesellschaft« (herausgegeben von Schmiede, Rudi), Edition Sigma, Berlin, S. 15 – 47. Schneider, Hans Julius (1992): Phantasie und Kalkül. Über die Polarität von Handlung und Struktur in der Sprache. Suhrkamp, Frankfurt/M. Schütz, Alfred (1971): Wissenschaftliche Interpretation und Alltagsverständnis menschlichen Handelns. In: Alfred Schütz: Gesammelte Aufsätze I, Martinus Nijhoff, Den Haag, S. 3 – 54. Schütz, Alfred (1972): Das Problem der Rationalität in der sozialen Welt. In: Alfred Schütz: Gesammelte Aufsätze II, Martinus Nijhoff, Den Haag, S. 22 – 50. Schütz, Alfred (2003): Theorie der Lebenswelt. Die pragmatische Schichtung der Lebenswelt, Bd. V.1 von Alfred Schütz Werkausgabe. UVK Verlagsgesellschaft, Konstanz. Schütz, Alfred (2004a): Das Problem der Relevanz. In: Schütz (2004c), S. 57 – 249. Schütz, Alfred (2004b): Der sinnhafte Aufbau der sozialen Welt. Eine Einleitung in die verstehende Soziologie, Bd. II. von Alfred Schütz Werkausgabe. UVK Verlagsgesellschaft, Konstanz.

Literaturverzeichnis

253

Schütz, Alfred (2004c): Relevanz und Handeln 1. Zur Phänomenologie des Alltagswissens, Bd. VI.1 von Alfred Schütz Werkausgabe. UVK Verlagsgesellschaft, Konstanz. Sebald, Gerd (2004): Baudrillard, die Gabe und der 11. September. In: Postmoderne De/Konstruktionen. Ethik, Politik und Kultur am Ende einer Epoche (herausgegeben von Kollmann, Susanne und Schoedel, Kathrin), LIT, Münster, S. 123– 135. Sebald, Gerd (2005): Vergesellschaftungsprozesse in der »Free/Open Source-Softwareentwicklung«. In: Jäckel und Mai (2005), S. 91 – 103. Sebald, Gerd (2007): Person und Vertrauen. Mediale Konstruktionen in den Online-Kooperationen der Free/Open Source-Softwareentwicklung. In: Social Software. Formen der Kooperation in computerbasierten Netzwerken (herausgegeben von Jäckel, Michael und Stegbauer, Christian), VS-Verlag, Wiesbaden, S. 19 – 35. Simmel, Georg (1989): Philosophie des Geldes. Suhrkamp, Frankfurt/M. Orig. 1901. Simmel, Georg (1992): Soziologie. Untersuchungen über die Formen der Vergesellschaftung. Suhrkamp, Frankfurt/M. Band 11 der Gesamtausgabe. Srubar, Ilja (2006): Die Unwissensgesellschaft. Moderne nach dem Verlust von Alternativen. In: Tänzler et al. (2006), S. 139 – 154. Stallman, Richard (1999): The GNU Operating System and teh Free Software Movement. In: DiBona et al. (1999), S. 53 – 70. Stegbauer, Christian (2001): Grenzen virtueller Gemeinschaft. Strukturen internetbasierter Kommunikationsforen. Westdeutscher Verlag, Opladen. Stegbauer, Christian (2002): Reziprozität. Eine Einführung in soziale Formen der Gegenseitigkeit. Westdeutscher Verlag, Wiesbaden. Stegbauer, Christian und Rausch, Alexander (2001): Die schweigende Mehrheit - »Lurker« in internetbasierten Diskussionsforen. Zeitschrift für Soziologie, 30(1):48 – 64. Stehr, Nico (2001): Wissen und Wirtschaften. Die gesellschaftlichen Grundlagen der modernen Ökonomie. Suhrkamp, Frankfurt/M. Stiglitz, Joseph E. (2000): Economics of the Public Sector. Norton, New York.

254

Literaturverzeichnis

Sutter, Tilmann (1999): Medienkommunikation als Interaktion? Über den Aufklärungsbedarf eines spannungsreichen Problemfeldes. Publizistik, 44:288 – 300. Thiedecke, Udo, (Hg.) (2000): Virtuelle Gruppen. Charakteristika und Problemdimensionen. Westdeutscher Verlag, Opladen. Thimm, Caja (2001): Funktionale Stilistik in elektronischer Schriftlichkeit. Der Chat als Beratungsforum. In: Chat-Kommunikation. Sprache, Interaktion, Sozialität & Identität in synchroner computervermittelter Kommunikation. Perspektiven auf ein interdisziplinäres Forschungsfeld (herausgegeben von Beißwenger, Michael), Stuttgart, S. 255 – 278. Text online unter http://www. ikp.uni-bonn.de/ZfKM/newzfkm/ueberzfkm/forschung/chatberatung.pdf, Download v. 15.09.2005. Torvalds, Linus und Diamond, David (2001): Just for Fun: The Story of an Accidental Revolution. Harper Business, New York. Turkle, Sherry (1984): Die Wunschmaschine. Der Computer als zweites Ich. Rowohlt, Reinbek. Turkle, Sherry (1999): Leben im Netz. Identität in Zeiten des Internet. Rowohlt Tb., Reinbek. Tuten, Tracy L. (): Getting A Foot In the Electronic Door: Understanding Why People Read or Delete Electronic Mail. http://www.gesis.org/Publikationen/Berichte/ ZUMA_Arbeitsberichte/97/97_08.pdf. ZUMA-Arbeitsbericht Nr. 97/08. Tänzler, Dirk, Knoblauch, Hubert und Soeffner, Hans-Georg, (Hg.) (2006): Zur Kritik der Wissensgesellschaft. UVK Verlagsgesellschaft, Konstanz. Weber, Max (1972): Wirtschaft und Gesellschaft. Grundriss der verstehenden Soziologie. J. C. B Mohr (Paul Siebeck), Tübingen, 5. Auﬂ. Weber, Max (1986): Die römische Agrargeschichte in ihrer Bedeutung für das Staats- und Privatrecht, Bd. I,2 von Max Weber Gesamtausgabe. J. C. B. Mohr (Paul Siebeck), Tübingen. Weber, Max (1988): Die protestantische Ethik und der Geist des Kapitalismus. In: Gesammelte Aufsätze zur Religionssoziologie I, J.C.B. Mohr (Paul Siebeck), Tübingen, S. 1 – 206. Weber, Steven (2004): The Success of Open Source. Harvard University Press, Cambridge, Mass.

Literaturverzeichnis

255

Wehner, Josef (1997a): Interaktive Medien - Ende der Massenkommunikation?. Zeitschrift für Soziologie, 26(2):96 – 114. Wehner, Josef (1997b): Medien als Kommunikationspartner. Zur Entstehung elektronischer Schriftlichkeit im Internet. In: Gräf und Krajewski (1997), S. 125 – 149. Weltz, Friedrich und Ortmann, Rolf G. (1992): Das Softwareprojekt. Projektmanagement in der Praxis. Campus, Frankfurt/New York. Wenzel, Ulrich (2001): Computergestützte Kommunikation zwischen Interaktion und Interaktivität. Zeitschrift für qualitative Bildungs-, Beratungs- und Sozialforschung, 2(2):175 – 185. Whyte, William Foote (1996): Die Street Corner Society. Die Sozialstruktur eines Italienerviertels. De Gruyter, Berlin/New York. Williams, Sam (2002): Free as in Freedom. Richard Stallman’s Crusade for Free Software. O’Reilly, Sebastopol/Ca. Willke, Helmut (1998): Systemisches Wissensmanagement. Lucius & Lucius, Stuttgart. Willke, Helmut (2001): Atopia. Studien zur atopischen Gesellschaft. Suhrkamp, Frankfurt/M. Willke, Helmut (2002): Dystopia. Studien zur Krisis des Wissens in der modernen Gesellschaft. Suhrkamp, Frankfurt/M. Winkler, Hartmut (1997): Docuverse. Zur Medientheorie der Computer. Klaus Boer Verlag, o.O. Winkler, Hartmut (2004): Diskursökonomie. Versuch über die innere Ökonomie der Medien. Suhrkamp, Frankfurt/M. Winograd, Terry und Flores, Fernando (1986): Understanding Computers and Cognition. A New Foundation for Design. Addison-Wesley, Boston. Wittmann, Reinhard (1991): Geschichte des deutschen Buchhandels. C.H.Beck, München. Ziegler, Arne (2004): Textstrukturen internetbasierter Kommunikation. Brauchen wir eine Medientextlinguistik? OBST (Osnabrücker Beiträge zur Sprachtheorie), (68):159 – 175.

Die offene Tür

Die offene Tuer

Die offene Tür

Heldentum - eine offene Nichthuldigung

Die offene Gesellschaft ... 2

Offene Quantensysteme: Die Primas Lectures

Die offene VerschwÄrung Aufruf zur Weltrevolution

Offene und geschlossene Beschaftigungssysteme: Determinanten, Risiken und Nebenwirkungen

Offene Wunde Nahost. Israel, die Palästinenser und die US-Politik

Offene Wunde Nahost - Israel, die Palaestinenser und die US-Politik

Die offene Gesellschaft und ihre Feinde. Band 2. Falsche Propheten

Mars, Venus und Partnerschaft. Vertrautheit, Nähe und Liebe durch offene Kommunikation

Wirtschaft, Arbeit und Soziales. Offene und programmierte Aufgaben mit Lösungen, 3. Auflage

Die offene Gesellschaft und ihre Feinde. Band 1. Der Zauber Platons

Chancen für ein soziales Europa?: Die Offene Methode der Koordinierung als neue Regulierungsform

Wie Deutschland zum Leitanbieter für Elektromobilität werden kann: Statuts Quo - Herausforderungen - Offene Fragen

Wirtschaft, Arbeit und Soziales: Prüfungstraining für Bankkaufleute: Teil 2: Fälle und offene Aufgaben mit Lösungen, 4. Auflage

Offene Wissensökonomie

Die offene Tür

Die offene Tuer

Die offene Tür

Heldentum - eine offene Nichthuldigung

Die offene Gesellschaft ... 2

Offene Quantensysteme: Die Primas Lectures

Die offene VerschwÄrung Aufruf zur Weltrevolution

Offene und geschlossene Beschaftigungssysteme: Determinanten, Risiken und Nebenwirkungen

Offene Wunde Nahost. Israel, die Palästinenser und die US-Politik

Offene Wunde Nahost - Israel, die Palaestinenser und die US-Politik

Die offene Gesellschaft und ihre Feinde. Band 2. Falsche Propheten

Mars, Venus und Partnerschaft. Vertrautheit, Nähe und Liebe durch offene Kommunikation

Wirtschaft, Arbeit und Soziales. Offene und programmierte Aufgaben mit Lösungen, 3. Auflage

Die offene Gesellschaft und ihre Feinde. Band 1. Der Zauber Platons

Chancen für ein soziales Europa?: Die Offene Methode der Koordinierung als neue Regulierungsform

Wie Deutschland zum Leitanbieter für Elektromobilität werden kann: Statuts Quo - Herausforderungen - Offene Fragen

Wirtschaft, Arbeit und Soziales: Prüfungstraining für Bankkaufleute: Teil 2: Fälle und offene Aufgaben mit Lösungen, 4. Auflage

Recommend Documents