Tabellen- und Abbildungsverzeichnis
1 Einleitung
2 Terminologien und Definitionen
2.1 Typen von Software - Eine Gegenüberstellung
2.2 Lizenzmodelle Freier Software
2.3 Verschiedene Auffassungen über Freie Software
3 Motive für die Mitarbeit in Open Source-Projekten
3.1 Intrinsische Motivation
3.2 Extrinsische Motivation
3.3 Validität der Motive
4 Eigenbedarf und Community - Ein Spiel mit Unbekannten
4.1 Bereitstellung von Gütern - Ein Beispiel
4.1.1 Die herkömmliche Mühle
4.1.2 Die offene Mühle
4.1.3 Erweiterung des Funktionsumfangs
4.2 Private Bereitstellung von Open Source Software
4.2.1 Was spricht für Open Source?
4.2.2 (Open Source) Software: Einöffentliches Gut?
4.2.3 Der „Markt“ für Open Source Software
4.2.4 Die Trittbrettfahrerproblematik in Open Source Projekten
4.2.5 Möglichkeit der Entstehung redundanter Entwicklungen
5 Open Source Software als Signal
5.1 Signalisieren
5.2 Rahmenbedingungen des Signalisierens durch Open Source Software
5.2.1 Glaubwürdigkeit und Wert der Signale
5.2.2 Möglichkeiten firmeninterner Lösungen des Informationsdefizits
5.3 Signalproduktion durch Open Source Beiträge
5.3.1 Konkurrenz um Signale: Das Modell von Lee, Moisa und Weiss
5.3.2 Auswirkungen des Signalisierens auf den Software Markt: Das Modell von Leppämäki und Mustonen
5.4 Diskussion der Ergebnisse
5.4.1 Sichtbarkeit der Beiträge
5.4.2 Überinvestition in Signale
5.4.3 Problematik hoher Externalitäten
5.4.4 Relevanz des Signalisierens
5.4.5 Produktivitätssteigerndes Signalisieren
5.4.6 Open Source als Screening-Möglichkeit
6 Zusammenspiel unterschiedlicher Motivationen
7 Effizienz- und Wohlfahrtswirkungen von Open Source Software
7.1 Effizienz und Wohlfahrt der Bereitstellungöffentlicher Güter
7.2 Externe Wohlfahrtseffekte des Signalisierens
8 Fazit
Literaturverzeichnis
1. Zum Ausdruck der Geschlechter sei gesagt, dass in der Regel beide gemeint sind. Nicht verwendet werden sprachliche Notkonstruktionen, wie etwa „MitarbeiterInnen“. Ich finde sie stören durch das große „I“ nur den Lesefluss und das gewohnte Schriftbild.
2. Eine Bemerkung vorweg zur Zitiertechnik von Internetseiten. Ich mache auch Gebrauch von Quellenmaterial, das nicht in gedruckter Form, sondern nur elektronisch im Internet veröffent- licht wurde. Einen allgemein anerkannten Standard für das wissenschaftliche Zitieren von On- line-Publikationen gibt es jedoch (noch) nicht. Quellen aus dem Internet werden nach folgenden Muster zitiert:
Autor (Jahr), Titel des Beitrags, http://www.adresse.de/Pfad/Dokument
Des Weiteren ist es zumeist nicht möglich bei Internetseiten, etwa im html-Format, Seiten- angaben festzulegen. Dies können je nach verwendetem Browser, Drucker, Betriebssystem und Seiteneinstellungen voneinander abweichen. In diesem Fall können innerhalb der gekürzten Quellenangaben im Text Seitenzahlen nur dann aufgeführt werden, wenn der Beitrag in einem Dateiformat veröffentlicht wurde, welches eine eindeutige bzw unveränderbare Seitennumme- rierung gewährleistet (z.B. PDF).
3. Diese Arbeit wurde vollständig mit Open Source Software geschrieben. Verwendet wurde OpenOffice.org 1.1.2 auf Kanotix Bug Hunter 05/2004 Release, ein Debian GNU/Linux System basierend auf Knoppix-Technologie.
Tabelle 1: Typen von Software
Tabelle 2: Überblick über Softwarelizenzen
Tabelle 3: Übersicht über Open Source Geschäftsmodelle
Tabelle 4: Motive für die Mitarbeit in Open Source Projekten
Tabelle 5:öffentliche, private und Klubgüter
Abbildung 1: Die Trittbrettfahrerproblematik bei Open Source Software
Abbildung 2: Vereinfachte Struktur des Signalspiels am Arbeitsmarkt
Abbildung 3: Externe Effekte von Open Source auf dem Gütermarkt
Abbildung 4: Rückwirkungen positiver externer Effekte von Open Source Software
Abbildung 5: Direkte und indirekte externe Effekte
Abbildung 6: Anreizinkompatibilitäten
„Ich habe keine Lösung, aber ich bewundere das Problem.“ (Ashleigh Brilliant)
„Fast jeder nutzt Open-Source-Produkte...“ (Fordahl, 2004) lautete eine Schlagzei- le bei stern.de vom 04.08.2004. Open Source Software ist mittlerweile so weit verbreitet, dass nahezu jeder (und sei es nur unbewusst) auf sie zurückgreift. So laufen z.B. die Computer von Google mit GNU/Linux, 40 % der e-mail Server mit dem Open Source Programm Sendmail (vgl. Fordahl, 2004) und fast 68 % der Web Server mit Apache. Bei den aktiven Web Servern sind es sogar fast 70 %, Tendenz steigend (vgl. Netcraft, 2004). Auch im sonst eher trägen Behörden- und Verwaltungsapparat wird zunehmend auf Open Source gesetzt. Auf starkesöffent- liches Interesse stießen hier vor allem die Beschlüsse der Stadträte in Schwäbisch Hall und München ihre Verwaltung komplett auf Linux umzurüsten (vgl. z.B. Heise News, 2003a, 2004b sowie 2004c) sowie jene der brasilianischen Regierung künftig Open Source Software zu bevorzugen undöffentlich finanzierte Software unter eine Open Source Lizenz zu stellen (vgl. Heise News 2003b und 2003c).
Aber auch im Desktop-Bereich der Heimanwender scheint Open Source Software langsam an Bedeutung zu gewinnen. Zwar ist es generell schwierig den Marktan- teil von Open Source zu messen, da wegen der kostenlosen Downloadmöglich- keiten nahezu keine Verkaufszahlen vorliegen, dennoch wird versucht aus den Zu- griffsstatistiken von Webseiten Informationen über den Verbreitungsgrad der Web-Browser und Betriebssysteme zu erlangen. Hierbei wird deutlich, dass der Internet Explorer sowie Windows aus dem Hause Microsoft weiterhin unange- fochten den Markt dominieren, jedoch Anteile gegenüber Open Source Produkten einbüßen. So verlor die Browserfamilie von Microsoft im September 2004 gegen- über dem Vorjahr knapp zwölf Prozentpunkte und fiel auf 74,8 %. Der freie Browser Mozilla legte im gleichen Zeitraum fast um die selbe Größenordnung auf 17,7 % zu. Im Betriebssystemmarkt dominiert weiterhin die Windowsfamilie mit über 90 % den Markt, verlor aber zum August 2004 3,6 Prozentpunkte binnen eines Jahres. Das freie Betriebssystem GNU/Linux steigerte hingegen seinen Marktanteil von 2,4 auf drei Prozent (vgl. W3Schools, 2004, eigene Berech- nungen).
Hieraus wird ersichtlich, dass Open Source Software zunehmend an Bedeutung sowohl im privaten als auch imöffentlichen Bereich gewinnt und auf proprietäre Softwarefirmen Konkurrenzdruck ausübt. Vor diesem Hintergrund scheint es angebracht zu untersuchen, warum Open Source Software entwickelt wird und aus welchen Motiven sich Entwickler mit der Erstellung von für jedermann kostenlos erhältlichen Programmen beschäftigen. Diese Arbeit soll daher eineökonomische Erklärung für die Anreize der Mitarbeit an Open Source Projekten liefern.
Um einen Zugang zur Thematik Open Source Software zu schaffen, soll dargelegt werden, was dieser Begriff eigentlich beinhaltet. Hierzu werden in Kapitel 2 zu- nächst die unterschiedlichen Typen von Software voneinander abgegrenzt. Des Weiteren werden einige Lizenzmodelle freier Software vorgestellt und Gründe für die zum Teil umstrittenen Definitionen Freier bzw. von Open Source Software dargelegt.
Die Grundlage für die weiteren Untersuchungen bildet in Kapitel 3 die Ein- grenzung und Definition der unterschiedlichen Motive, die hinter einer Mitarbeit an Open Source Projekten stehen können. Hierbei werden mögliche intrinsische sowie extrinsische Motivationen kurz dargestellt und auf ihre empirische Rele- vanz hin überprüft.
Ausgehend von der Überlegung, dass ein Engagement nutzenbringend sein soll, werden die Implikationen der Bereitstellung desöffentlichen Gutes „Open Source Software“ aus Gründen des Eigenbedarfs untersucht. In Kapitel 4 werden dabei zunächst die grundlegenden Unterschiede, die mit der Erstellung proprietärer bzw. quelloffener Software verbunden sind, an einem einfachen Beispiel dargestellt. Darauf aufbauend soll dargelegt werden, welche Besonderheiten sich bei der Open Source Entwicklung ergeben und welche Auswirkungen z.B. die Trittbrettfahrerproblematik auf die Entwicklungsanreize hat.
Im 5. Kapitel werden schließlich verzögerte monetäre Anreize der Open Source Entwicklung untersucht. Hierbei wird erläutert, unter welchen Bedingungen der Aufbau von Reputation in Open Source Projekten ein Signal für die Programmierfähigkeiten der Entwickler darstellt und welche Auswirkungen dies wiederum auf den Softwaremarkt haben kann.
Kapitel 6 soll schließlich prüfen, ob die verschiedenen, in den vergangenen Kapiteln dargestellten, Motivationsformen untereinander anreizkompatibel sind. Anschließend sollen dann in Kapitel 7 mögliche Effizienz- und Wohlfahrtswirkungen, die sich aus den in dieser Arbeit behandelten Entwicklungsanreizen ergeben, untersucht werden.
Abschließend soll nochmals kurz dargelegt werden, welchen Beitrag die einzelnen Kapitel zu der Fragestellung dieser Arbeit, ob die Mitarbeit an Open Source Projekten alsökonomisch rationales Verhalten erklärt werden kann, geleistet haben. Es sollte dort auch gelungen sein aufzuzeigen, dass sichökonomische Erklärungsmodelle für das Verständnis der Motivation der Entwickler Freier Software als durchaus praktikabel erwiesen haben.
„Von jeder Sache gibt es zwei einander widersprechende Auffassungen.“ (Protogoras)
Es gibt viele Arten von Software: Nicht jede kostenlose ist Freie bzw. Open Source Software, genausowenig muss jede Software, welche verkauft wird, gleichzeitig proprietär sein. Es scheint daher zunächst angebracht, vor derökono- mischen Betrachtung der Motivation zur Entwicklung von Open Source Software, die unterschiedlichen Typen von Software sowie daraus folgernd die verschie- denen Arten von Lizenzen Freier bzw. von Open Source Software darzustellen.
Grundsätzlich unterscheidet man zwei Arten von Software: Proprietäre sowie Freie bzw. Open Source Software. Der wesentliche Unterschied besteht in der Einsehbarkeit des Quellcodes, den operativen Anweisungen in einer Programmier- sprache an den Computer. Dieser Quelltext (source code) wird mit Hilfe eines Compilers in einen für den Computer lesbaren Binär- bzw. Objektcode umge- wandelt. Die Kompilierung des Quellcodes ist grundsätzlich ein nicht rückgängig machbarer Prozess.1 Der Binärcode stellt somit für den Nutzer eine „Black-Box“ dar, in der das Wissen (die Funktionsweise des Programms) effektiv einge- schlossen ist. Aus diesem Grund ist die Einsehbarkeit des Quelltextes einer Soft- ware von so entscheidender Bedeutung, da der Quellcode die Voraussetzung dafür ist, Veränderungen an der Software vornehmen zu können.
Proprietäre (herstellerspezifische) Software wird im Allgemeinen nur in einer für bestimmte Prozessorplattformen vorkompilierten Form ausgeliefert und für ihren Gebrauch muss ein Entgelt an den Hersteller entrichtet werden. Ist der Gebrauch unentgeltlich, so spricht man auch von so genannter Freeware; das „free“ bezieht sich hier auf frei im Sinne von gratis (z.B. Freibier).
Im Gegensatz dazu ist mit „free“ bei „Free Software“ eher frei im Sinne von Frei- heit (z.B. Redefreiheit) gemeint. Eine der wichtigsten Eigenschaften Freier bzw. von Open Source Software ist, dass das Wissen, welches in der Software steckt, also der Quellcode, frei verfüg- und veränderbar ist. Weiterhin lassen sich vier wesentliche Grundeigenschaften Freier Software aufzählen:
1. Das Programm darf ohne Beschränkungen benutzt werden.
2. Der Benutzer hat die Freiheit zu studieren, wie das Programm arbeitet, und darf es an die eigenen Bedürfnisse anpassen.
3. Die Software darf ohne Einschränkungen kopiert und weitergegeben werden, so dass auch andere sie nutzen können.
4. Das Programm darf verändert werden und mit diesen Veränderungen weitergegeben werden, so dass auch andere davon profitieren (vgl. z.B. Grassmuck, 2002, S. 233).
Open Source Software muss jedoch nicht zwingend gratis abgegeben werden. So sind neben Gebühren für das Kopieren der Software auch der Verkauf von mit der Software verbundenen Zusatzleistungen, wie Support und Garantien, oder das Zu- sammenstellen zu einer Distribution2 erlaubt. Der Quellcode der einzelnen Open Source Pakete muss jedoch frei zugänglich bleiben (vgl. z.B. Grassmuck, 2002, S. 285).
In Tabelle 1 sollen die verschieden Typen von Software in Abgrenzung hinsichtlich der Zugänglichkeit des Quelltextes und der Preisgestaltung veranschaulicht werden. Die weiteren Eigenschaften Freier als auch herkömmlicher Software ergeben sich aus den Lizenzbedingungen, also den vertraglichen Rechten und Pflichten, unter denen sie veröffentlicht wird.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Typen von Software
Quelle: Eigene Darstellung in Anlehnung an OSI, 2004b und Berlecon Research, 2002, S. 11 f.
„Software ist in Deutschland durch § 2 Abs. 1 Satz 1 UrhG rechtlich ge- schützt. Dies betrifft insbesondere das Erstveröffentlichungsrecht (§ 12 UrhG). Die Autorin kann ihr Werk unter frei gewählten Bedingungen veröf- fentlichen, die in einer Lizenz, also einem Privatvertrag zwischen der Ur- heberin und dem Verwerter oder dem Endbenutzer festgelegt werden.“ (Grassmuck, 2002, S. 275)
Software ohne Schutz durch das Urheberrecht (in diesem Fall spricht man auch von Public Domain) kann von jedem ohne Einschränkung genutzt werden. Um eine unbeschränkte Nutzung der Software zu ermöglichen, verzichtet Freie Soft- ware nun aber nicht einfach auf die so genannten „Property Rights“, sondern stellt die Software gezielt unter den Schutz des Urheberrechts, um zukünftige Ein- schränkungen durch Besitzrechte an der Software zu verhindern. Im folgenden werden die drei wichtigsten Lizenzen Freier Software vorgestellt.
Die älteste Lizenz ist die der Berkeley Software Distribution (BSD-Lizenz). Sie erlaubt die Verwendung, Weiterverarbeitung sowie den Vertrieb der Software mit oder ohne Veränderungen, sowohl im Quell- als auch im Binärcode, solange der Copyrightvermerk und der Lizenztext mitverbreitet werden. Allerdings schreibt die BSD-Lizenz nicht explizit vor, dass abgeleitete Software ebenfalls im Quelltext verfügbar sein muss. Das Derivat muss zwar unter dieselbe Lizenz gestellt werden, womit auch das Recht weitergegeben wird, diese im Quelltext zu verbreiten, es besteht jedoch keine Verpflichtung zu letztgenanntem (vgl. FreeBSD, 1994 sowie Grassmuck, 2002, S. 279 ff.). Was geschehen soll, wenn jemand den Quelltext seiner Veränderungen oder Erweiterungen nicht veröffentlichen will, lässt der Lizenztext offen.
Diese Unklarheit beseitigt die GNU General Public Licence (GPL), welche explizit vorschreibt, dass Derivate der Software nicht nur unter die gleiche Lizenz gestellt werden, sondern auch, dass der Quellcode zugänglich sein muss. Die GPL ist sogar noch restriktiver, denn sie erlaubt eine Verlinkung von GPL lizensierter Software mit anderer Software nur dann, wenn diese ebenfalls unter der GPL bzw. einer zur GPL kompatiblen Lizenz steht. In der Konsequenz bedeutet das, dass je- des Programm, welches Teile GPL lizensierten Codes enthält, ebenfalls unter die GPL Lizenz fällt (vgl. FSF, 1991). „Ziel dieser [...] Klausel ist es, eine Privatisierung von kollektiv erzeugtem Wissen zu verhindern [...].“ (Grassmuck, 2002, S. 284 f.) Die GPL-Lizenz wird deshalb auch häufig als „infektiös“ bzw. „virenartig“ bezeichnet, da sie sich in den Programmcode hineinfrisst und daraus nicht mehr zu entfernen ist. Grassmuck (2002) nennt sie hingegen eher „impfend“, da sie aus oben genannten Gründen vor Freiheitsentzug schützt3 (vgl. Grassmuck, 2002, S. 284 f.).
Abbildung in dieser Leseprobe nicht enthalten
a Shareware ist nur für einen Testzeitraum kostenlos
b i.d.R. kein Quellcode verfügbar. Bei Public Domain ist i.d.R. der Quellcode verfügbar, aber nicht verpflichtend. c Es besteht keine Verpflichtung sondern nur das Recht zur Veröffentlichung des Quellcodes. d Eine Verknüpfung hätte zur Folge, das die verknüpfende Software ebenfalls unter die GPL fallen würde.
Tabelle 2: Überblick über Softwarelizenzen
Quelle: Eigene Darstellung in Anlehnung an Grassmuck, 2002, S. 275 ff. sowie Berlecon Research, 2002, S. 14 ff.
Aufgrund der sehr restriktiven Lizenzpolitik der GPL wurde die GNU Library/Lesser General Public License (LGPL) als Spezialfall der GPL für be- stimmte Softwarebibliotheken4 eingeführt. Sie erlaubt, dass Freie Software LGPL lizensierte Bibliotheken einlinkt, ohne dass das entstehende Gesamtwerk selbst den Bedingungen der LGPL unterstehen muss. Als Grund wird in der LGPL angegeben, dass bei Bibliotheken die Grenzen zwischen einfachem Gebrauch und Veränderung verschwimmen. Hierbei ist man der Auffassung, dass, wenn ein Programm mit einer Bibliothek verlinkt wird ohne diese zu verändern, dies einer einfachen Benutzung der Bibliothek entspricht, ähnlich der Benutzung eines Hilfsoder Anwendungsprogramms (vgl. FSF, 1999).
Neben diesen drei Lizenzen Freier Software gibt es noch eine Vielzahl weiterer offener Lizenzen, welche jedoch zum großen Teil die bestehenden Lizenztexte va- riierten und mit einer individuellen Note versahen. Einen Überblick über die wichtigsten Eigenschaften verschiedener Softwarelizenzen gibt Tabelle 2. Zum Vergleich wurden hierbei die benachbarten Konzepte Freier Software5 (Share- ware, Freeware und Public Domain) sowie kommerzielle Software mit aufgeführt.
Die beiden Lizenzfamilien, BSD und GPL, stammen aus Universitäten und besitzen den gleichen Grundgedanken:öffentlich finanziertes Wissen gehört allen. Dennoch verfolgen sie in zwei elementaren Eigenschaften ihrer Lizenzen, nämlich dem Verhältnis zu proprietärem Code und dem Status abgeleiteter Werke, äußerst unterschiedliche Auffassungen darüber, welche Lizenz „freier“ ist.
Auf der einen Seite gibt es die GPL, die strikt untersagt, dass GPL-Code in nicht GPL-kompatiblen Code integriert werden darf und verlangt, dass modifizierte Werke wieder unter der GPL stehen müssen (so genanntes „Copyleft“: einmal frei immer frei). Dem gegenüber steht die BSD-Lizenz, die so ziemlich jegliche Art der Verwendung ihrer Software zulässt. Solange der Copyrighthinweis erhalten bleibt, darf BSD-lizensierte Software in andere, auch proprietäre Software integriert sowie Veränderungen privatisiert werden.
Der Versuch, die unterschiedlichen Auffassungen der Lizenzen in einem einheit- lichen Kontext zu ordnen und zu bewerten, ist in diversen Konzepten zu beobach- ten. Allerdings spiegeln auch diese zumeist die Sichtweise der ihr nahestehenden Lizenz wieder. So klassifiziert die Free Software Foundation (FSF) danach, ob es sich um Freie Software, um Copyleft und um GPL kompatible Software handelt. Der FSF geht es vor allem um den Schutz bzw. die Bewahrung der Freiheiten der Software, also darum, dassöffentliches Wissen auch weiterhinöffentlich bleibt (vgl. FSF, 2002). Reiter (2004) spricht daher auch von stark schützenden (GPL), schwach schützenden (LGPL), nicht schützenden (BSD) sowie nicht GPL kompa- tiblen Lizenzen (vgl. Reiter, 2004, S. 5).
Die Verfechter der BSD-artigen Lizenzen sehen die Freiheit eher von der Sicht- weise, dass jeder Nutzer die Möglichkeit hat, mit den Code zu machen, was er will, ihn also auch zu privatisieren. Deutsch (1996) nennt die BSD-Lizenzen in seiner Klassifikation daher auch „unbeschränkte Lizenzen“, da sie keine Restrik- tionen bei der Weitergabe und Modifikation auferlegen (vgl. Deutsch, 1996, S. 2 f.). Es wird z.B. auch darauf verwiesen, dass in vielen Projekten mit BSD- artigen Lizenzen eine fruchtbare Zusammenarbeit mit Firmen stattfindet und daher die restriktiven Bedingungen der GPL gar nicht nötig sind (vgl. Hohndel, 1999). Grassmuck (2002) erwidert hierauf allerdings, dass die „'sehr, sehr freie' BSD-Li- zenz erlaubt [...], dass Microsoft so frei war, große Mengen FreeBSD-Code in Windows zu verwenden. Das Monopol ist dadurch in keiner Weise geschmälert worden. Kein Nutzer hat dadurch mehr Freiheit gewonnen. Würde FreeBSD unter der GPL stehen, hätte Microsoft es nicht verwenden dürfen oder Windows wäre heute freie Software.“ (Grassmuck, 2002, S. 299, vgl. weiterführend eine Gegen- überstellung der Positionen zu den unterschiedlichen Lizenzen in Grassmuck, 2002, S. 293 ff.)
Als Alternative zu dem „ideologisch“ vorbelasteten Begriff „Freie Software“ versuchte die Open Source Initiative (OSI) mit der Open Source Definition (OSD) eine allgemeinere Richtlinie zur Bewertung von Lizenzen zu etablieren. Lizenzen, welche die Kriterien der OSD erfüllen, unter anderem
- freie Redistribution,
- zugänglicher Quellcode,
- Modifikationen der Software zulassen und ermöglichen, dass diese unter den gleichen Lizenzbedingungen verteilt werden sowie, dass der Quell- code weiterhin zugänglich ist, dürfen den geschützten Titel „OSI Certified“6 tragen. Die OSD stellt somit einen Standard oder ein Gütesiegel für Open Source Software dar und sowohl die GPL als auch die BSD-Lizenz sind OSI zertifiziert (vgl. OSI, 2004a und 2004b).
Es bleibt somit festzuhalten, dass die verschiedenen Aussagen der einzelnen Li- zenzen auf eine unterschiedliche Sichtweise des Begriffs Freiheit zurückzuführen sind. Aus der Sicht des Individuums ist sicherlich die BSD-Lizenz, aus Sicht der Gemeinschaft jedoch eher die GPL, die Lizenz mit dem größtem Freiheitsgrad. In dieser Arbeit soll jedoch auf diesen Umstand nicht weiter eingegangen werden. Des Weiteren werden die Begriffe Freie und Open Source Software der Einfachheit halber synonym gebraucht, dabei wird, wenn nicht anders erwähnt, die Version im Sinne der GPL gemeint sein. Dies hat vor allem drei praktische Gründe: Zum einen ist die GPL die verbreitetste Lizenz Freier Software (vgl. Ber- liOS, 2003), des Weiteren bezieht sich die meiste Literatur zu diesem Thema auf sie und in dieser Arbeit wird deshalb aus Kompatibilitätsgründen auf sie Bezug genommen. Drittens hat die GPL auch die weitreichendstenökonomischen Folgen: Einige Aussagen haben nur unter der GPL Gültigkeit, da sie einen mög- lichen Markthandel nahezu vollständig erodiert.
„Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall.“ (Friedrich Dürrenmatt)
Open Source Software wird in der Regel von einer Gemeinschaft von Program- mierern entwickelt, in den meisten Fällen jedoch, ohne dass diese eine finanzielle Entschädigung erhalten. Was motiviert Entwickler und Nutzer trotzdem an einem Projekt mitzuarbeiten, obwohl sie dafür nicht bezahlt werden und von dessen Ergebnis sie auch ohne Mitarbeit profitieren könnten? Sind sie Altruisten oder verbirgt sich dahinter doch ein rationales undökonomisches Kalkül?
Nach Lerner und Tirole (2000) beschäftigt sich ein Entwickler nur dann mit Open Source Software, wenn ihm daraus ein positiver Nettonutzen entsteht. Dieser setzt sich aus aktuellem und zukünftigem Nutzen zusammen, wobei ersterer direkter monetärer sowie eigener Nutzen abzüglich seiner Opportunitätskosten sein kann. Als zukünftig werden dagegen z.B. Karriereaussichten und Anerkennung genannt (vgl. Lerner und Tirole, 2000, S. 14 f.).
In diesem Kontext lässt sich eine Reihe von Motiven nennen, welche eine Mitarbeit in Open Source Projekten begründen könnten. Hierzu zählen u.a.: - Unternehmensgewinne
- Arbeitslöhne
- Ausbildung
- Reputation
- Signalwirkung
- Eigennutzung
- Identifikation mit der Community
- Spaß
- Altruismus
In Anlehnung an z.B. Osterloh, Rota und Kuster (2003) lassen sich diese möglichen Motive in die beiden Oberkategorien intrinsische und extrinsische Motivationen einteilen.
Im Folgenden soll zunächst eine Einteilung und kurze Erläuterung der einzelnen Motivgründe erfolgen. Im Anschluss wird anhand ausgewählter empirischer Studien ihre Relevanz überprüft und eine mögliche Problematik der Zuordnung verschiedener Motive in eine der beiden Kategorien diskutiert.
Wenn eine Tätigkeit aus innerem Antrieb um ihrer selbst willen erfolgt, so wird sie intrinsisch genannt. Alle Aktivitäten, die betrieben werden, weil sie Spaßma- chen und nicht von außen durch eine Belohnung oder Drohung herbeigeführt werden müssen, können intrinsisch motiviert sein (vgl. Zimbardo, 1992, S. 378).
Eigenbedarf ist zumeist der initiale Grund, weshalb sich ein Individuum mit Open Source beschäftigt. Nach der Erkenntnis, dass eine bestimmte Applikation fehlt, kann (falls vorhanden) nach alternativer kommerzieller oder aber Open Source Software gesucht werden. Entsprechen diese nicht (vollkommen) den eigenen Bedürfnissen, kann über eine Mitarbeit an einem bestehenden Open Source Projekt nachgedacht werden. Eine weitere Möglichkeit besteht in der Erstellung einer neuen Software, welche dann möglicherweise veröffentlicht wird und andere Entwickler ermuntert, an diesem Projekt mitzuarbeiten. Unter welchen Prämissen dies geschehen kann, wird in Kapitel 4 dargestellt.
Identifikation mit der Community
Auch in der an sich anonymen Welt der Open Source Nutzer und Entwickler, wel- che sich zumeist nicht persönlich kennen, sondern nur über das Internet kommuni- zieren, besteht ein Bedürfnis nach sozialen Bindungen, ein Wunsch nach Zugehö- rigkeit zu einer Gruppe und der Identifikation mit ihren Zielen. Diese können ganz unterschiedlicher Art sein und reichen von der Auffassung, dass Quellcode offen sein soll bis hin zu auch ideologischen Aussagen, wie der generellen Ablehnung von Microsoft. Aber auch ganz profane Dinge können Ziele der Gruppe sein. Hierunter kann z.B. die Bereitschaft in der Community fallen, anderen zu helfen, weil einem vielleicht selber in der Vergangenheit geholfen wurde, ohne eine un- mittelbare Gegenleistung zu erwarten.
Altruistisch verhält man sich, wenn man das Wohl und die Interessen anderer über das eigene stellt. Diese besondere Verhaltensform lässt sich z.B. bei Müttern be- obachten, die ihre Kinder versorgen und beschützen (vgl. Zimbardo, 1992, S. 372). Im Open Source Bereich kann Altruismus z.B. aus einer ideologischen Haltung begründet werden, also etwa der Ansicht folgend, dass durch Open Source Software die Freiheit der Menschen zunimmt und dieses ein beschützens- und bewahrenswerter Zustand ist. Auch das Bedürfnis, der Open Source Bewe- gung etwas zurückzugeben, weil selbst viel Open Source Software verwendet wird bzw. wurde, kann altruistisch motiviert sein (vgl. Luthiger, 2004, S. 96 f.).
Bei letzterem Argument ist jedoch fraglich, ob dieses Verhalten wirklich auf Altruismus zurückzuführen ist und nicht vielmehr eher eine Art „Tausch“, also eine zwar vertraglich nicht zugesicherte, aber freiwillige verspätete Rückzahlung an die Gemeinschaft darstellt. Selbst unter der Annahme, dass das Ausmaßdes Zurückgebens die eigene Nutzung übersteigt, kann hier wohl eher von „sozialem Verhalten“ und Identifikation mit den Zielen der Community gesprochen werden.
Vor diesem Hintergrund ist ersichtlich, dass das Motiv des Altruismus nur äußerst schwer zu definieren ist. Wenn man von der sehr strengen Auffassung ausgeht, dass altruistische Handlungen keinerlei persönliche Befriedigung oder Nutzen verursachen dürfen, so bleibt fraglich, ob Altruismus überhaupt existiert. Selbst das Verhalten von Müttern ihren Kindern gegenüber kann stattdessen als angeborener „Mutterinstinkt“ betrachtet werden.
Genannt werden soll das Motiv in diesem Zusammenhang, trotz fehlendem empirischen Nachweis, da es in einigen Arbeiten z.B. bei Luthiger (2004) explizit erwähnt wurde, sowie von manch anderen Autoren (z.B. Ghosh, 1998, bzw. Lerner und Tirole, 2000) die Frage aufgeworfen wurde, ob die Beschäftigung mit Open Source altruistisch motiviert sei.
Spaß
Als letzter hier genannter intrinsischer, aber trotzdem sehr wesentlicher Mo- tivationsfaktor, ist die Begeisterung, der Spaßan der Mitarbeit an einem Open Source Projekt zu nennen. Ein selbstgestelltes Problem wird zum Ansporn und mobilisiert Phantasie- und Leistungsressourcen (vgl. Eckert u.a., 1991, S. 205). Im Gegensatz zu kommerziellen Softwarefirmen kann hierbei selbst anhand eigener Kenntnisse und Vorlieben ausgesucht werden, in welche Projekte wie viel Zeit in- vestiert wird (vgl. Luthiger, 2004, S. 97). Das Engagement kann dann soweit füh- ren, dass das Gefühl für die Zeit verloren geht und bis in die Morgenstunden an der Lösung des Problems gearbeitet wird. Hat man es dann endlich geschafft, stellt sich ein Gefühl von Stolz, ein Leistungs-, Erfolgs- oder Kompetenzerlebnis ein (vgl. Eckert u.a., 1991, 204 f.).
Wird sich einer Tätigkeit nicht aus innerem Antrieb gewidmet, sondern aufgrund der daraus folgenden Konsequenzen, so spricht man von extrinsischer Motivation. Hierbei kann es sich sowohl um positive (Belohnung) oder aber um negative (Drohung oder Bestrafung) Verstärkungen handeln (vgl. Zimbardo, 1992, S. 378 und Edelmann, 2000, S. 257 f.). Im Rahmen der hier zu behandelnden Frage der Mitarbeit in Open Source Projekten liegt die extrinsische Motivation vor allem in der Erwartung alternativer Einkommen in Form von z.B. Weiterbildung oder dem Signalisieren am Arbeitsmarkt.
Direkter monetärer Nutzen
Neben den Anreizen durch verzögerte Auszahlungen sind natürlich auch direkte Einkünfte durch Unternehmergewinne, Arbeitslöhne oder Gratifikationen Formen einer extrinsischen Motivation. Hierbei stellt sich jedoch die Frage, wie mit Open
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3: Übersicht über Open Source Geschäftsmodelle
Quelle: Eigene Darstellung in Anlehnung an Raymond, 2000b, S. 13 ff. und Leiteritz, 2004
Source und speziell mit unter der GPL stehender Software nachhaltig Erträge er- wirtschaftet werden können, da für jeden die Software kostenlos erhältlich ist. Fasst man jedoch Software als Dienstleistung und nicht als Produkt auf (vgl. Eben Moglen in golem.de, 2004, S. 1) bzw. schließt sich der Auffassung an, dass nicht der Warenwert sondern der Gebrauchswert das entscheidende Kriterium einer Software ist (vgl. z.B. Raymond, 2000b, S. 4 ff.), so lassen sich diverse Open Source Geschäftsmodelle identifizieren, welche in Tabelle 3 kurz dargelegt werden (eine detailliertere Darstellung dieses Themas findet sich z.B. in Ray- mond, 2000b, S. 13 ff., Berlecon Research, 2002, S. 41 und Leiteritz, 2004).
Signal- und Reputationserwerb
Eine weitere Möglichkeit der Motivation liegt nicht in einer sofortigen, sondern in einer eventuellen verspäteten Monetarisierbarkeit des Engagements in einem Open Source Projekt. Hierbei lässt sich aus dem Projekt heraus durch Erfassung der Qualität und der Quantität der Beiträge sowie des Status des Entwicklers die Reputation des Beteiligten genau abbilden. Unter der Annahme, dass die jeweilige Produktivität des Entwicklers für Außenstehende nicht erkennbar ist, kann Repu- tation als Signal am Arbeitsmarkt oder zur Anwerbung von Risikokapital genutzt werden. Auf den Aspekt des Signalisierens wird in Kapitel 5 ausführlicher einge- gangen.
Open Source Projekte eignen sich jedoch auch, um von erfahrenen Entwicklern bei der Bewältigung anstehender Probleme unterstützt zu werden und von ihnen zu lernen. Probleme, Fehler und Lösungsvorschläge werden unmittelbar durch die Mitglieder des Projekts (peer group) diskutiert, analysiert und ausprobiert (peer review). Die sich einstellenden Lerneffekte kommen allen zu gute und hiervon kann eventuell auch beruflich profitiert werden.
Die oben genannten Motive lassen sich hinsichtlich ihrer tatsächlichen Bedeu- tungen für die Entwickler und Mitarbeiter an Open Source Projekten untersuchen. Hierbei können drei Ergebnisse festgehalten werden: Erstens lassen sich einige Motive, je nach Ursächlichkeit entweder intrinsisch und/ oder extrinsisch auf- fassen, zweitens lässt sich die Relevanz der meisten Motivgründe aufgrund empi- rischer Untersuchungen nicht von der Hand weisen (vgl. Tabelle 4), wobei sie drittens aber nicht unbedingt als alleiniger Grund für die Mitarbeit gesehen werden dürfen.
Die erstgenannte Problematik ließe sich durch eine detailliertere Unterteilung der Motive beheben. So kann z.B. Lernen unter der Prämisse der beruflichen Fortbil- dung als extrinsische Motivation bzw. im Falle des „Lernens für das Leben“ aus innerem also intrinsischem Antrieb heraus gesehen werden. Gerade die in- trinsische Lernmotivation ist in der Lernpsychologie zum Teil umstritten (vgl. Edelmann, 2000, S. 258 oder Zimbardo, 1992, S. 378). In diesem Kapitel sollte allerdings vielmehr hervorgehoben werden, dass es sowohl extrinsische als auch intrinsische Motive geben kann, die zur Mitarbeit an Open Source Projekten anregen und dass diese auch ausökonomischer Sicht betrachtet werden können.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 4: Motive für die Mitarbeit in Open Source Projekten (Angaben in Prozent)
Quelle: Eigene Darstellung, Hars und Ou, 2001, S. 6 f., Lakhani und Wolf, 2003, S. 10 ff. und Ghosh u.a., 2002, S. 43 ff.
Intrinsische Motive, wie Eigenbedarf aber auch Spaß, stiften den von Lerner und Tirole (2000) genannten eigenen Nutzen. Soweit also hierdurch ein positiver Nettonutzen entstünde, wäre dies ein möglicher Erklärungsansatz für die Bereit- schaft zur Open Source Mitarbeit. Wichtig ist, dass hierbei alle Dimensionen des Nutzens betrachtet werden, also auch die immateriellen. Problematischer scheint in diesem Zusammenhang eine alleinige Erklärung durch die eher ideologisch angehauchten intrinsischen Motive „Identifikation mit der Community“ oder aber „Altruismus“ zu sein. In empirischen Studien, die sich mit den Motivations- gründen der Beteiligung an Open Source Projekten beschäftigen, werden diese zum Teil bestätigt, jedoch meist im Einklang mit anderen Motiven genannt (vgl. Tabelle 4). Sie dürfen also nicht isoliert betrachtet werden sondern nur unter Berücksichtigung des Zusammenspiels mit anderen Motiven.
Vergleicht man die Nennungen der unterschiedlichen Motive, so fällt auf, dass die monetären Aspekte, Entlohnung und Reputation, im Vergleich zu den intrinsischen Motiven relativ selten angeführt wurden. Der Grund hierfür könnte in der Tatsache liegen, dass die Gruppe, welche vorrangig diese Motive hat, in der Stichprobe „unterrepräsentiert“ ist.
Nach einer Untersuchung von Dempsey (2002) steuerten 91 % der Entwickler nur ein bis zwei Beiträge zu Open Source Projekten bei. Lediglich 0,53 % leisteten mehr als zehn bzw. 2,2 % mehr als fünf Beiträge, trugen aber zu mehr als 6 % bzw. 13 % zum Gesamtergebnis bei (vgl. eigene Berechnungen auf Basis der Un- tersuchungen von Dempsey u.a., 2002, S. 71).7 Wird diese Erkenntnis in die obigen Ergebnisse mit einbezogen, können diese relativiert werden. So haben z.B. Hars und Ou (2001) untersucht, inwieweit die Nennungen der Motive mit dem Engagement bzw. dem geleistetem Aufwand zusammenhängen. Hierbei zeigte sich, dass die beiden monetären Motive sowie der Eigenbedarf mit 0,3 bis 0,36 wesentlich stärker als die restlichen Motive (0,12 bis 0,19) mit dem Grad des Auf- wands korreliert sind (vgl. Hars und Ou, 2001, S. 6 f.).
In Verbindung mit der schon erwähnten Studie von Dempsey u.a. (2002) lässt sich somit festhalten, dass Entwickler mit wenigen Beiträgen, sogenannte „Hobby- oder Freizeitprogrammierer“, eher intrinsisch motiviert sind und neue Fähigkeiten erlernen möchten. Erfahrenere, qualifiziertere Entwickler, welche dement- sprechend auch mehr Beiträge leisten, sind hingegen mehr an Motiven interessiert, aus denen sich ein realer Ertrag erwirtschaften lässt. Eine dichotome Aufteilung in intrinsisch und extrinsisch motivierte Entwickler lässt sich jedoch nicht feststellen (vgl. hierzu auch die Motivationsgründe untergliedert nach Programmierertypen von Lakhani und Wolf, 2003, S. 10 ff.). Des Weiteren sollten die Motive der Entwickler nicht isoliert, sondern unter Beachtung dessen, dass auch andere Beweggründe für sie ausschlaggebend sind, betrachtet werden.
„Um ein tadelloses Mitglied einer Schafherde sein zu können, muss man vor allem ein Schaf sein.“ (Albert Einstein)
Der zumeist initiale Grund, warum sich mit Software beschäftigt wird, ist der eigene Bedarf nach einem benötigten Programm oder einer Funktion. Aus- gangspunkt für die Entwicklung einer Software ist demnach das Bedürfnis eines Einzelnen. Wahrscheinlich werden jedoch auch andere Menschen gerade ein ähnliches Problem haben, welches sich mit beliebig reproduzierbarer Software lö- sen lässt. In diesem Kapitel soll dargelegt werden, warum es für einen Entwickler eine lohnende Alternative sein kann, ein Produkt der Allgemeinheit in Form von Open Source Software zur Verfügung zu stellen und dieses gemeinsam mit anderen Mitgliedern der Open Source Gemeinschaft zu entwickeln. Zunächst sollen jedoch die unterschiedlichen Bereitstellungsformen von Gütern an einem einfachen Beispiel erläutert werden. Hierbei wird allerdings auch schon auf einige Besonderheiten im Bezug zum Softwaremarkt eingegangen.
Es sei angenommen, dass eine mittelalterliche Dorfgemeinschaft existiert, deren gemeinsames Bedürfnis es ist, ihr geerntetes Getreide nicht mehr per Hand son- dern mit Hilfe einer Mühle zu mahlen.8 Als Lösungsmöglichkeit bieten sich für die Dorfmitglieder folgende Alternativen an: Einer oder mehrere Mitglieder der Dorfgemeinschaft bauen eine für sich selbst mit der Absicht, falls sie gut ist, ihre Dienste an die anderen zu verkaufen. Sie könnten aber auch jemanden beauftragen eine zu bauen, welcher dann deren Dienste gegen Entgelt zur Verfügung stellt. Als letzte Möglichkeit bleibt ihnen natürlich, die Mühle gemeinsam zu bauen und zu nutzen.
Beginnen wir mit der „proprietären“ Mühle, also der ersten Alternative. Die Dorf- gemeinschaft beauftragt einen externen Handwerker mit dem Bau einer Mühle bzw. es findet sich jemand, der den Bedarf nach einer erkannt hat und diese er- richten will. Der Handwerker wird nun, da er zwar weißwie man eine Mühle baut, aber nicht die Einzelheiten (Steine hauen, Nägel schmieden) perfekt bewerkstel- ligen kann, Menschen anstellen müssen, die diese Aufgaben für ihn erledigen. Jene haben nur den Anreiz gute Leistungen zu erbringen, solange sie dafür ange- messen entlohnt werden. Sie werden also darauf achten, dass ihr Auftraggeber mit ihnen zufrieden ist und natürlich auch Arbeiten verrichten, von denen sie wissen, dass sie weniger sinnvoll sind. Der Handwerker hingegen hat den Anreiz, so wenig finanzielle Mittel wie möglich zu verwenden, um Einnahmen zu erzielen. Trotz aller Widrigkeiten9 wird die Mühle nach einiger Zeit stehen und Getreide mahlen können. Zwar wird sie nicht unbedingt exakt dem Bedürfnis der Bauern entsprechend, aber sie können ihr Korn mahlen, womit sie zumindest ihren Haupt- zweck erfüllt.
Die Dorfmitglieder werden das Angebot in der Mühle ihr Korn zu mahlen annehmen, da sie es sonst selber per Hand mahlen müssten. Natürlich werden sie für die ihnen zur Verfügung gestellten Dienste bezahlen müssen, was sie bis zu einer bestimmten Grenze auch dann tun werden, wenn der Handwerker sein Monopol ausnutzt und die Preise erhöht.
Weil sie es gewohnt sind bei diesem Handwerker ihr Korn mahlen zu lassen, werden sie es auch dann weiter tun, wenn ein Konkurrent eine zweite Mühle baut. Sie würden nur dann eventuell wechseln und die Investition in andere, für diese Mühle genormte, Korn- und Mehlsäcke auf sich nehmen, wenn der Konkurrent wesentlich billiger und qualitativ grundlegend besser ist als der ursprüngliche An- bieter.
Da die Mühle, wie schon dargelegt, nicht genau den Bedürfnissen der Bauern ent- spricht, könnte auch einer aus ihrer Mitte auf die Idee kommen, selber eine zu bauen. Er weiß, was er, und eventuell auch, was andere in der Dorfgemeinschaft von einer guten Mühle erwarten. Sein Problem wird aber sein, dass er sie nur „nebenbei“ bauen kann, da er sonst keine Zeit mehr hätte, sich um seinen Lebens- unterhalt, also die Bestellung der Felder, zu kümmern.
[...]
1 Bestenfalls mit sehr großen Anstrengungen durch Dekompilierung lässt sich der Quellcode an- nähernd rekonstruieren. Hierbei würden u.a. die zum Verständnis des Codes wichtigen Kommentare fehlen, so dass im Grunde die Dekompilierung mindestens mit dem gleichen Aufwand verbunden ist wie die ursprüngliche Codierung, aber keine genaue Kopie des originalen Quelltextes wiederhergestellt werden kann. Hinzu kommt noch, dass bei vielen proprietären Softwarelizenzen Dekompilierung verboten ist.
2 Unter einer Distribution versteht man eine Zusammenstellung von Software und Software- komponenten, welche in der zugehörigen Gesamtheit weitergegeben wird.
3 Ausführlicher wird auf den unterschiedlichen Umgang bzw. die Definition von Freiheit in Kapi- tel 2.3 eingegangen. Zur Frage der Gültigkeit der GPL nach deutschem Recht vgl. Grassmuck, 2002, S. 286 ff. sowie Heise News, 2004d.
4 „Eine 'Bibliothek' ist eine Sammlung von Softwarefunktionen und/ oder Daten, die einfach mit Anwendungsprogrammen (welche einige der Funktionen und Daten nutzen) verbunden werden können, um dadurch ausführbare Programme zu erzeugen.“ (FSF, 1999, eigene Übersetzung)
5 Ein ausführlicher Überblick über erwähnte und alle weiteren Lizenzmodelle findet sich z.B. bei FSF, 2002 oder Grassmuck, 2002, S. 275 ff.
6 Ursprünglich sollte „Open Source“ als eingetragene, geschützte Marke von der OSI vergeben werden. Ein Markenschutz für den Begriff „Open Source“ ist jedoch nicht erlangbar (vgl. Reiter, 2004, S. 4).
7 Zu diesen Ergebnissen muss folgendes hinzugefügt werden: In der Studie von Dempsey u.a. (2002) wurde die Gesamtanzahl der Beiträge nicht genannt. Diese bewegen sich nach eigenen Berechnungen zwischen 3508 und 3629, wobei bei den obigen Berechnungen ein Mittelwert von 3569 Gesamtbeiträgen gewählt wurde. In einer vorhergehenden Studie weisen Dempsey u.a. (1999) hingegen 4184 Gesamtbeiträge aus. Diese lassen sich jedoch anhand der Anzahl der Autoren und der ihnen zugewiesenen Anzahl an Beiträgen nicht rekonstruieren, so dass auch hier maximal 3629 Gesamtbeiträge errechnet werden können (vgl. hierzu die Angaben in Dempsey u.a., 1999, S. 10). Franck und Jungwirth (2001) kommen, auf Grundlage dieser Zah- len, deshalb zu anderen Ergebnissen. Sie scheinen die vakanten Beiträge der Autoren mit mehr als 10 Einzelbeiträgen aus der Differenz der Gesamtbeiträge und der restlichen Beiträge er- mittelt zu haben. Hieraus ergibt sich dann, dass die 13 Autoren, welche mehr als zehn Beiträge leisteten einen Anteil von 20% an den Gesamtbeiträgen haben (vgl. Franck und Jungwirth, 2001, S. 3 f.). Dieses Ergebnis steht jedoch nicht konträr zu obiger Aussage, dass die Anzahl der Einzelbeiträge über die Autoren nicht gleichverteilt ist. Es würde die Ansicht eher noch ver- stärken, dass einige wenige eine überdurchschnittliche Anzahl an Beiträgen zu den Open Source Projekten beisteuern.
8 Ausgangspunkt für die Entwicklung des folgenden Beispiels ist Jäger (2002).
9 Die angeführten Widrigkeiten sind nur als Beispiel gedacht, was in der Herstellung suboptimal verlaufen kann. Die Liste ließe sich beliebig erweitern, aber auch kürzen.
