Zusammenfassung
1 Einleitung
2 Ökonomische Motivationsfaktoren
2.1 Persönlicher Bedarf
2.2 Karrierebezogene Motive
3 Psychologische Motivationsfaktoren
3.1 Das Flow-Erlebnis
3.2 Selbstbestimmungstheorie und Open Source Entwicklung
4 Soziologische Motivationsfaktoren
4.1 Reputation – Die FOSS Gemeinschaft als Geschenkgesellschaft
4.2 Politische Motive
5 Bisherige empirische Untersuchungen
6 Eigene Studie
6.1 Datenmaterial
6.2 Datenaufbereitung
6.3 Extraktion der Motivationsfaktoren
6.4 Ergebnisse
6.4.1 Demographische und personenbezogene Daten
6.4.2 Karrierebezogene Beweggründe
6.4.3 Politische Motive
6.4.4 Intrinsische Motivation und Kompetenz
6.4.5 Statusorientierte Motive
6.4.6 Persönlicher Nutzen
6.4.7 Regionale Unterschiede in den Motivationsfaktoren
7 Zusammenfassender Ausblick
Literaturverzeichnis
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.
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 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.
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).
„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).
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 Programms wird begünstigt, wenn das Programm in Konkurrenz zu anderen Produkten steht (Shy 2001). Durch eine Freigabe des Codes kann die Verbreitung gefördert werden, um dann in Dienstleistung rund um das Produkt einen Konkurrenzvorteil herauszuschlagen. Weiters ist die Suche nach geeigneten Partnern oder potentiellen Käufern schwierig und zeitaufwendig, was man sich durch FOSS erspart.
Raymond (2002a) weist darauf hin, dass sich die im FOSS-Umfeld erworbene Reputation positiv auf die Berufsaussichten einzelner Programmierer auswirken kann. Lerner und Tirole (2000) geben diesem Motivationsfaktor mehr Einfluss.
In vielen technischen und künstlerischen Bereichen ist jedoch die Qualität der Arbeit für Außenstehende schwer zu beurteilen. Da der Arbeitsmarkt durch asymmetrische Information geprägt ist, kann der Arbeitgeber die Qualität der Arbeitsnehmer nicht direkt beobachten. Ausbildung und Zertifikate können in diesem Zusammenhang im Sinne von Spence (1973) als Signal dienen, um dieses Problem der Informationsasymmetrie zu lösen. Lee et al. (2003) weisen darauf hin, dass die Information über die Fähigkeit der einzelnen Entwickler innerhalb der FOSS-Community weniger ungleich verteilt ist, als zwischen den Entwicklern auf dem Arbeitsmarkt, da die Programmierer untereinander die Qualifikation ihrer Kollegen am besten einschätzen können. Unternehmen können sich auf diese Einschätzung verlassen und Entwickler mit hoher Reputation anstellen. Kompetente Entwickler können sich im FOSS-Umfeld leichter von durchschnittlichen Kollegen abheben. Jeder Codeblock kann genau seinem Erzeuger zugeordnet werden (Lerner und Tirole 2000).
Jeder zusätzliche Entwickler übt in zweifacher Hinsicht externe Effekte auf andere Entwickler aus. Einerseits erhöht sich mit der Zahl der Entwickler der Wert des Signals, andererseits sinkt aber die Wahrscheinlichkeit für den einzelnen, ein Signal senden zu können (Lee et al. 2003). Im Falle von konkurrierenden Beiträgen verschiedener Entwickler kommt es zu einer „Winner takes all“-Situation. Da nur ein Beitrag in den Quellcode aufgenommen werden kann, geht der Verlierer leer aus. Dies verringert die Wahrscheinlichkeit, ein Signal senden zu können.
Hars und Ou (2001) weisen auf einen möglichen Konflikt hin: Das Verbessern eines FOSS-Programms heute, kann das Potential für zukünftige Einnahmen durch Dienstleistungen rund um das Projekt verringern, weil weniger Anpassungen und Support notwendig sind.
In der Psychologie gibt es zahlreiche Zugänge zum Thema Motivation (vgl. beispielsweise Heckhausen 1989 oder Herkner 1991). Für die Beurteilung der Motivation der FOSS-Entwickler erscheint das Konzept von intrinsischer und extrinsischer Motivation geeignet. Die primäre Frage lautet, ob die Entwickler durch externe Belohnungen motiviert sind oder durch einen inneren Antrieb an Projekten teilnehmen.
Über die extrinsische und intrinsische Motivation gibt es keine einheitliche Auffassung, wobei aber „allen Konzeptionen gemein ist, dass intrinsisches Verhalten um seiner selbst oder eng damit zusammenhängender Zielumstände willen erfolgt, dass es nicht bloßes Mittel zu einem andersartigen Zweck ist“ (Heckhausen 1989, S. 608).
Deci (1975) unterscheidet zwischen internen (intrinsic motivation) und externen Motivationsfaktoren (external rewards). Durch intrinsische Motivation haben Menschen den Anreiz, eine Tätigkeit um ihrer selbst willen durchzuführen. Aus der Durchführung ziehen sie einen unmittelbaren Nutzen, nämlich die Befriedigung persönlicher Bedürfnisse. Intrinsisches Verhalten beinhaltet Spontaneität, Neugier und Interesse an den unmittelbaren Gegebenheiten der Umwelt. Extrinsische Motivation bewirkt, dass eine Aufgabe wegen einer externen Belohnung oder Bestrafung durchgeführt wird. Die Tätigkeit ist ein Mittel zum Zweck. Dazu gehört in der Regel die berufliche Tätigkeit von Menschen, der der Entlohnung wegen nachgegangen wird.
Intrinsische Motive wurden in der Literatur zu FOSS anfänglich nur am Rande berücksichtigt, obwohl die FOSS-Community immer auf deren Wichtigkeit hingewiesen hat ( vgl. Raymond 2000a).
Die Unterscheidung von intrinsischen und extrinsischen Faktoren ist aber kein leichtes Unterfangen (Frey/Osterloh 1997). Ob eine Aktion aus einem inneren Antrieb heraus oder mit einem bestimmten Ziel vor Augen unternommen wird, hängt nicht nur von der Persönlichkeit der Entwicklers, sondern auch von seiner momentanen Situation ab.
[...]
