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

---

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

2

---

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.

3

---

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

4

---

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.

5

---

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).

6

---

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

7

---