Maik Hetmank 2

Unser Kopf ist rund, damit das Denken die Richtung

Vorbemerkungen:

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.

Maik  Hetmank  3

Inhaltsverzeichnis

Tabellen- und  Abbildungsverzeichnis.  4

1  Einleitung.  5

2  Terminologien und Definitionen.  8

2.1  Typen von Software - Eine Gegenüberstellung.  8

2.2  Lizenzmodelle Freier Software.  10

2.3  Verschiedene Auffassungen über Freie Software.  12

3  Motive für die Mitarbeit in Open Source-Projekten.  15

3.1  Intrinsische Motivation.  16

3.2  Extrinsische Motivation.  18

3.3  Validität der Motive.  19

4  Eigenbedarf und Community - Ein Spiel mit Unbekannten.  23

4.1  Bereitstellung von Gütern - Ein Beispiel.  23

4.1.1  Die herkömmliche Mühle.  23

4.1.2  Die offene Mühle.  25

4.1.3  Erweiterung des Funktionsumfangs.  27

4.2  Private Bereitstellung von Open Source Software.  28

4.2.1  Was spricht für Open Source?  28

4.2.2  (Open Source) Software: Ein öffentliches Gut?  29

4.2.3  Der „Markt“ für Open Source Software.  32

4.2.4  Die Trittbrettfahrerproblematik in Open Source Projekten.  34

4.2.5  Möglichkeit der Entstehung redundanter Entwicklungen.  38

5  Open Source Software als Signal.  40

5.1  Signalisieren.  40

5.2  Rahmenbedingungen des Signalisierens durch Open Source Software.  43

5.2.1  Glaubwürdigkeit und Wert der Signale.  44

5.2.2  Möglichkeiten firmeninterner Lösungen des Informationsdefizits.  47

5.3  Signalproduktion durch Open Source Beiträge.  48

5.3.1  Konkurrenz um Signale: Das Modell von Lee, Moisa und Weiss.  49

5.3.2  Auswirkungen des Signalisierens auf den Software Markt: Das Modell  

von  Leppämäki und Mustonen.  55

5.4  Diskussion der Ergebnisse.  65

5.4.1  Sichtbarkeit der Beiträge.  65

5.4.2  Überinvestition in Signale.  67

5.4.3  Problematik hoher Externalitäten.  68

5.4.4  Relevanz des Signalisierens.  70

5.4.5  Produktivitätssteigerndes Signalisieren.  73

5.4.6  Open Source als Screening-Möglichkeit.  74

6  Zusammenspiel unterschiedlicher Motivationen.  76

7  Effizienz- und Wohlfahrtswirkungen von Open Source Software.  80

7.1  Effizienz und Wohlfahrt der Bereitstellung öffentlicher Güter.  80

7.2  Externe Wohlfahrtseffekte des Signalisierens.  86

8  Fazit.  89

Literaturverzeichnis   93

Maik  Hetmank  4

Tabellen- und  Abbildungsverzeichnis  

Tabelle 1:  Typen von Software.  9

Tabelle 2:  Überblick über Softwarelizenzen.  11

Tabelle 3:  Übersicht über Open Source Geschäftsmodelle.  18

Tabelle 4:  Motive für die Mitarbeit in Open Source Projekten.  20

Tabelle 5:  Öffentliche, private und Klubgüter.  31

Abbildung  1: Die Trittbrettfahrerproblematik bei Open Source Software.  36

Abbildung  2: Vereinfachte Struktur des Signalspiels am Arbeitsmarkt.  42

Abbildung  3: Externe Effekte von Open Source auf dem Gütermarkt.  58

Abbildung  4: Rückwirkungen positiver externer Effekte von Open Source  

Software.   60

Abbildung  5: Direkte und indirekte externe Effekte.  61

Abbildung  6: Anreizinkompatibilitäten  77

Maik Hetmank Einleitung 5

1 Einleitung

„Fast jeder nutzt Open-Source-Produkte...“ (Fordahl, 2004) lautete eine Schlagzeile 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 öffentliches 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 Marktanteil von Open Source zu messen, da wegen der kostenlosen Downloadmöglichkeiten nahezu keine Verkaufszahlen vorliegen, dennoch wird versucht aus den Zugriffsstatistiken 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 unangefochten 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 Berechnungen).

Hieraus wird ersichtlich, dass Open Source Software zunehmend an Bedeutung sowohl im privaten als auch im öffentlichen Bereich gewinnt und auf proprietäre

Maik Hetmank Einleitung 6

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 zunä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 Eingrenzung 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 Relevanz 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.

Maik Hetmank Einleitung 7

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.

Maik Hetmank Terminologien und Definitionen 8

2 Terminologien und Definitionen

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 ökonomischen Betrachtung der Motivation zur Entwicklung von Open Source Software, die unterschiedlichen Typen von Software sowie daraus folgernd die verschiedenen Arten von Lizenzen Freier bzw. von Open Source Software darzustellen.

2.1 Typen von Software - Eine Gegenüberstellung

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 Programmiersprache 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. ¹ Der Binärcode stellt somit für den Nutzer eine „Black-Box“ dar, in der das Wissen (die Funktionsweise des Programms) effektiv eingeschlossen ist. Aus diesem Grund ist die Einsehbarkeit des Quelltextes einer Software 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 Freiheit (z.B. Redefreiheit) gemeint. Eine der wichtigsten Eigenschaften Freier bzw. von Open Source Software ist, dass das Wissen, welches in der Software steckt,

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 Kom-mentare 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.

Maik Hetmank Typen von Software - Eine Gegenüberstellung 9

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 Zusammenstellen zu einer Distribution ² 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.

2 Unter einer Distribution versteht man eine Zusammenstellung von Software und Software-

komponenten, welche in der zugehörigen Gesamtheit weitergegeben wird.

Maik Hetmank Typen von Software - Eine Gegenüberstellung 10

Tabelle 1: Typen von Software

Quelle: Eigene Darstellung in Anlehnung an OSI, 2004b und Berlecon Research, 2002, S. 11 f.

Maik Hetmank Lizenzmodelle Freier Software 11

2.2 Lizenzmodelle Freier Software

„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 Software nun aber nicht einfach auf die so genannten „Property Rights“, sondern stellt die Software gezielt unter den Schutz des Urheberrechts, um zukünftige Einschrä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 jedes 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

Maik Hetmank Lizenzmodelle Freier Software 12

nicht mehr zu entfernen ist. Grassmuck (2002) nennt sie hingegen eher „impfend“, da sie aus oben genannten Gründen vor Freiheitsentzug schützt ³ (vgl. Grassmuck, 2002, S. 284 f.).

^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- 3Ausfü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.

Maik Hetmank Lizenzmodelle Freier Software 13

stimmte Softwarebibliotheken ⁴ 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 Hilfs-oder 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 variierten 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 Software ⁵ (Shareware, Freeware und Public Domain) sowie kommerzielle Software mit aufgeführt.

2.3 Verschiedene Auffassungen über Freie Software

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 einheitlichen Kontext zu ordnen und zu bewerten, ist in diversen Konzepten zu beobach-

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.

Maik Hetmank Verschiedene Auffassungen über Freie Software 14

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 kompatiblen Lizenzen (vgl. Reiter, 2004, S. 5).

Die Verfechter der BSD-artigen Lizenzen sehen die Freiheit eher von der Sichtweise, 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 Restriktionen bei der Weitergabe und Modifikation auferlegen (vgl. Deutsch, 1996, S. 2 f.). Es wird z.B. auch darauf verwiesen, dass in vielen Projekten mit BSDartigen 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-Lizenz 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,

Maik Hetmank Verschiedene Auffassungen über Freie Software 15

dürfen den geschützten Titel „OSI Certified“ ⁶ 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 Lizenzen 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. BerliOS, 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öglichen Markthandel nahezu vollständig erodiert.

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

ter, 2004, S. 4).

Maik Hetmank Motive für die Mitarbeit in Open Source-Projekten 16

3 Motive für die Mitarbeit in Open Source-Projekten

Open Source Software wird in der Regel von einer Gemeinschaft von Programmierern 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 ver- schiedener Motive in eine der beiden Kategorien diskutiert.

Maik Hetmank Intrinsische Motivation 17

3.1 Intrinsische Motivation

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ß machen 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

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, welche sich zumeist nicht persönlich kennen, sondern nur über das Internet kommunizieren, 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 unmittelbare Gegenleistung zu erwarten.

Altruismus

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,

Maik Hetmank Intrinsische Motivation 18

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 Bewegung 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 investiert wird (vgl. Luthiger, 2004, S. 97). Das Engagement kann dann soweit führen, 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

Maik Hetmank Intrinsische Motivation 19

sich ein Gefühl von Stolz, ein Leistungs-, Erfolgs- oder Kompetenzerlebnis ein (vgl. Eckert u.a., 1991, 204 f.).

3.2 Extrinsische Motivation

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

Tabelle 3: Übersicht über Open Source Geschäftsmodelle

Quelle: Eigene Darstellung in Anlehnung an Raymond, 2000b, S. 13 ff. und Leiteritz, 2004

Maik Hetmank Extrinsische Motivation 20

Source und speziell mit unter der GPL stehender Software nachhaltig Erträge erwirtschaftet 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 Raymond, 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 Reputation als Signal am Arbeitsmarkt oder zur Anwerbung von Risikokapital genutzt werden. Auf den Aspekt des Signalisierens wird in Kapitel 5 ausführlicher eingegangen.

Lernen

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.

3.3 Validität der Motive

Die oben genannten Motive lassen sich hinsichtlich ihrer tatsächlichen Bedeutungen 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-