Motivationale Grundlagen von Open-Source Software
Ralph Spitzer
*
, Jürgen Noll
, Udo Brändle
*
Mag. Ralph Spitzer, Fasangasse 39/5/10, 1030 Wien, Österreich
Univ.-Ass. Dr.Dr. Jürgen Noll (Kontaktautor), Fakultät für Wirtschaftswissenschaft, Universität Wien,
Brünner Straße 72, 1210 Wien, Österreich
Dr. Udo Brändle, Kommunalkredit Austria AG, 1092 Wien, Türkenstraße 9
2
Inhaltsverzeichnis
Zusammenfassung ... 3
1 Einleitung ... 4
2 Ökonomische
Motivationsfaktoren ... 6
2.1 Persönlicher
Bedarf ... 6
2.2 Karrierebezogene
Motive ... 8
3 Psychologische
Motivationsfaktoren... 9
3.1 Das
Flow-Erlebnis ... 10
3.2
Selbstbestimmungstheorie und Open Source Entwicklung... 11
4 Soziologische
Motivationsfaktoren ... 13
4.1
Reputation Die FOSS Gemeinschaft als Geschenkgesellschaft ... 13
4.2 Politische
Motive... 16
5
Bisherige empirische Untersuchungen ... 17
6 Eigene
Studie... 18
6.1 Datenmaterial... 18
6.2 Datenaufbereitung ... 19
6.3
Extraktion der Motivationsfaktoren... 19
6.4 Ergebnisse... 20
6.4.1
Demographische und personenbezogene Daten... 21
6.4.2 Karrierebezogene
Beweggründe... 24
6.4.3 Politische
Motive... 26
6.4.4
Intrinsische Motivation und Kompetenz ... 28
6.4.5 Statusorientierte
Motive ... 29
6.4.6 Persönlicher
Nutzen... 31
6.4.7 Regionale
Unterschiede
in den Motivationsfaktoren ... 32
7 Zusammenfassender
Ausblick... 33
Literaturverzeichnis... 35
3
Zusammenfassung
Wir präsentieren theoretische Überlegungen sowie empirische Resultate zu der
Frage, warum erfahrene Programmierer unentgeltlich an Projekten zur
Entwicklung von Software teilnehmen. Dabei zeigt sich, dass nur ein
Zusammenspiel ökonomischer, psychologischer und soziologischer
Erklärungsansätze ein gutes Bild von der tatsächlichen (durchschnittlichen)
Motivationsstruktur der Teilnehmer ergibt. Karrierebezogene Motive können
eine solche Entwicklung nur bedingt erklären. Der Aufbau von Reputation und
politische Motive erscheinen gelegentlich als bessere Ansätze. Dies wird durch
unsere empirische Studie bestätigt. Intrinsische Motivation wie die intellektuelle
Herausforderung ist in einer durch Autonomie und Selbstbestimmung
gekennzeichneten Gemeinschaft sehr wichtig. Die Programmierer wollen nicht
nur Software nach ihren eigenen Vorstellungen gestalten, sondern eine gute
Reputation in der Community erlangen. Wenn dabei noch ein Erfolg gegen die
großen kommerziellen Softwarehersteller gelingt, motiviert das die
Programmierer weiter.
4
1 Einleitung
Die Idee von ,,Freier und Open-Source Software" (kurz: FOSS) entwickelte sich
anfangs aus dem Bedürfnis vieler Programmierer, vorhandene Software nach den
eigenen Anforderungen weiterentwickeln zu können. Um solche Änderungen
durchführen zu können, muss jedoch der so genannte Quellcode verfügbar sein. Das ist
jedoch bei kommerzielle Software nicht der Fall, welche nur in Form eines Binärcodes
vertrieben wird und daher ausschließlich vom jeweiligen Anbieter geändert werden
kann. Man nennt solche Software proprietär. Des weiteren ist für die Vornahme von
Programmänderungen selbst bei offenem Quellcode rechtlich eine Erlaubnis des
ursprünglichen Urhebers erforderlich (vgl. Arkenbout et al. 2004). Daher entstanden
insbesondere mit der zunehmenden Verbreitung des Internets ab Mitte der 90er Jahre
immer mehr Projekte, in deren Rahmen sowohl der Quellcode offengelegt blieb und
jedermann das Recht zur Weiterentwicklung eingeräumt wurde. Die Free Software
Foundation (FSF) ist beispielsweise eine der Institutionen, die sich für freie, quelloffene
Software einsetzt, die neben der freien Weiterverbreitung und offenem Quelltext unter
anderem auch ein Diskriminierungsverbot gegenüber Personen, Gruppen und auch
Anwendungsgebieten gewährleisten sollte. Angesichts der aktuellen Debatte über
Software-Patente erhalten Fragen, welche Faktoren eine Rolle spielen, um in solchen
in der Regel unentgeltlichen Projekten mitzuwirken, neuen Auftrieb.
Ganz allgemein gesprochen ist Software ein Informationsgut. Daher sind damit nach
Shapiro/Varian (1999) einige Eigenschaften verbunden. Informationsgüter
kennzeichnen sich in der Kostenstruktur durch hohe Fixkosten und sehr niedrige
variable Kosten. Weiters ist Software ein Erfahrungsgut, sodass der Konsument erst
nach der Benutzung erkennen kann, ob das Gut seinen Erwartungen entspricht.
Zusätzlich erfüllt FOSS die Eigenschaften eines öffentlichen Guts und dem damit
einhergehenden sozialem Dilemma. Weil es bei öffentlichen Gütern per definitionem
nicht möglich ist, jemanden von dessen Nutzung auszuschließen, kann jeder darauf
hoffen, dass das Gut von anderen bereitgestellt wird, ohne zu dieser Bereitstellung
etwas beitragen zu müssen. Die dominante Strategie jedes Teilnehmers ist es daher,
abzuwarten und nichts zu tun, was konsequenterweise dazu führen müsste, dass das Gut
von niemandem zur Verfügung gestellt wird und dieser Markt zusammenbricht (Noll
2002). Diese ökonomischen Gesetzmäßigkeiten, die häufig unter den Begriff des
5
Trittbrettfahrens oder free-riding subsumiert werden, machen die freiwillige
unentgeltliche Teilnahme an FOSS-Projekten noch weiter erklärungsbedürftig.
Die riesige Anzahl frei verfügbarer Programme, die unterschiedlichste
Anwendungsbereiche abdecken, legt jedoch den Schluss nahe, dass dieses
Trittbrettfahren die Produktion von FOSS nicht merklich zu behindern scheint. Denn im
Gegensatz zum Allmendeproblem erleiden die Projektteilnehmer keinen Schaden durch
die Nutzung Dritter, da bei digitalen Gütern keine Übernutzung erfolgen kann.
Da FOSS oft von Personen entwickelt wird, die sich persönlich nicht kennen, und
geographisch weit verbreitet wohnen, sind die vorhandenen sozialen Bindungen relativ
schwach ausgeprägt und unabhängig von der Gruppengröße. Für FOSS spielt damit die
Anzahl der Trittbrettfahrer keine bedeutende Rolle, solange eine kleine Kerngruppe
erhalten bleibt, die die Entwicklung aktiv vorantreibt und die Vision eines gemeinsamen
Ziels aufrechterhalten kann.
Um erklären zu können, warum ein öffentliches Gut wie FOSS von privaten
Entwicklern auf freiwilliger Basis zur Verfügung gestellt wird - ,,why should thousands
of top-notch programmers contribute freely to the provision of a public good"
(Lerner/Tirole 2000) - muss vor allem die Frage nach der Motivation dieser Entwickler
beleuchtet werden. Die Beweggründe der Entwickler zur Teilnahme mögen sehr
heterogen sein und bilden den Gegenstand unserer weiteren Untersuchungen. Wir
schlagen eine Einteilung der Motivationsfaktoren in ökonomische, psychologische und
soziologische Erklärungsansätze vor.
6
2 Ökonomische
Motivationsfaktoren
Erklärungsversuche aus ökonomischer Sicht bauen auf dem Konzept der Kosten-
Nutzen-Abwägung durch die Teilnehmer auf. Entwickler werden sich an einem FOSS-
Projekt beteiligen, wenn der zu erwartende Nutzen die Kosten übersteigt. Wesentliche
Motivationsfaktoren sind demzufolge die Notwendigkeit, eine Lösung für ein
bestehendes technisches Problem zu finden (persönlicher Bedarf) oder erhoffte
karrierebezogene Vorteile (karrierebezogene Motive).
2.1 Persönlicher Bedarf
,,Every good work of software starts by scratching a developer's personal itch."
(Raymond 2000a). Viele der prominentesten FOSS-Projekte zielten in ihren Anfängen
gar nicht auf das ab, was sie nun darstellen. So war Linux anfangs nicht als
Betriebssystem geplant, sondern von seinem ,,Entwicklungsvater" Linus Torvalds als
Programm zum Lesen von Emails gedacht. Dieses und viele andere Projekte zeigen auf,
dass FOSS-Projekte entstanden sind, weil Benutzer mit vorhandenen Lösungen
unzufrieden waren. Die Tatsache, dass Software für den persönlichen Bedarf
geschrieben wird, hat damit drei wichtige Implikationen.
Erstens handeln die entsprechenden Entwickler rational und folgen ihren eigenen
Interessen. Zweitens kann man annehmen, dass die Menge an Software, die von einem
bestimmten Programmierer produziert wird, beschränkt ist. Der dritte Punkt ist die
Übereinstimmung der Interessen von Entwicklern und Anwendern (Hars/Ou 2001).
Beide sind an einem verbesserten Produkt interessiert und im Sinne einer Pareto-
Verbesserung bereit, Anstrengungen in die Entwicklung zu investieren.
Kommerzielle Hersteller hingegen bieten aus Kostengründen oft nur wenige Versionen
ihres Produktes an, die so gestaltet sind, dass sie die Bedürfnisse von
,,durchschnittlichen" Verbrauchern abdecken. Konsumenten, deren Bedürfnisse nicht
ausreichend zufrieden gestellt werden, können entweder den Hersteller mit
individuellen Anpassungen beauftragen, oder zur Selbsthilfe greifen, und ein Produkt
neu entwickeln bzw. bei bestehenden Produkten Anpassungen vornehmen (Franke und
von Hippel 2003).
7
Welchen Nutzen ziehen aber Teilnehmer eines FOSS-Projekts daraus, denn wenn ein
Programm oder Teile davon für den eigenen Gebrauch entwickelt werden, dann sind die
Entwicklungskosten bereits versenkt. Der Entwickler hat dann zwei Möglichkeiten, den
Code veröffentlichen oder nicht veröffentlichen. Im Falle einer Veröffentlichung
entstehen Transaktionskosten, in diesem Zusammenhang Veröffentlichungskosten.
Kollock (1999) weist auf die geringe Höhe dieser Kosten hin und beschreibt das Umfeld
der FOSS-Entwicklung als ,,low cost situation". Als Projektinitiator hingegen können
diese Kosten einen größeren Faktor ausmachen, denn das Programm muss dokumentiert
werden, eine technisch funktionierende Lösung muss so überarbeitet werden, dass
daraus ein herzeigbarer Programmcode wird, nicht zuletzt aufgrund des damit
einhergehenden möglichen Reputationsverlusts.
Dem steht der erwartete Nutzen aus der Verfügbarkeit des Quellcodes entgegen, der es
den Nutzern erlaubt, Fehler selbst zu beseitigen und das Programm an die eigenen
Bedürfnisse anzupassen (Raymond 2000a). Die so entstehenden Verbesserungen fließen
zum Teil wieder an den Projektinitiator zurück, da eine zentrale Verwaltung des Codes
für die Teilnehmer von Vorteil sein kann. Viele Programmierer begrüßen die
Verfügbarkeit des Quellcodes, weil sie auf der Arbeit anderer aufbauen und diese
erweitern und verbessern können, ohne das Rad neu erfinden zu müssen (Gosh et al.
2002).
Ob es für einen Entwickler sinnvoll ist, seinen Code freizugeben, hängt vom Wert
(gering oder hoch) und den Eigenschaften des Programmcodes (komplementär oder
eigenständig) ab. Komplementäre Codes mit geringem Wert (beispielsweise kleine
Patches), die aus nur wenigen Zeilen Code bestehen, sind für sich alleine nutzlos und
haben nur dann einen Wert, wenn sie in das Programm integriert werden.
Bei komplementärem Code mit hohem Wert hängt es von der Lizenz des zugrunde
liegenden Programms ab, ob und wie der Code veröffentlicht wird. Handelt es sich um
ein Programm, das unter einer wenigerer restriktiven Lizenz vertrieben wird, dann hat
der Entwickler die Wahl, seine Entwicklung entweder proprietäre Software oder als
FOSS zu vertreiben. Bei einem eigenständigen Programm mit geringem Wert ist die
kommerzielle Nutzung zwar rechtlich möglich, aber nicht sinnvoll. Hat jedoch das
eigenständige Programm einen hohen Wert, hängt es vom Geschäftsmodell des
Entwicklers ab, ob es als FOSS oder proprietär vertrieben wird. Eine Freigabe des
0 comments