Open Hardware - Open Source Battery

Open Hardware
Autor: Enno Wichmann
Datum: 25.12.2010
Quelle: : http://www.opensourcebattery.org/docs/OpenHardware.pdf
Abstract:
Die Allgegenwärtigkeit von Open Source Software demonstriert das Potential der Entwicklungs- und
Distributionsmethode Open Source, die auf dem freien Zugang zum Quellcode einer Software beruht.
Vorliegende Arbeit untersucht, inwieweit die Methode Open Source auch auf materielle Güter (Hardware)
angewendet werden kann. Ausgangspunkt ist dabei der Begriff Open Source Software, der grundlegend erläutert
wird, und auf seine Anwendbarkeit hin auf materielle Güter geprüft wird. Im Mittelpunkt stehen hier die
Übertragung des Begriffs des Quellcodes auf Hardware und am Beispiel bereits bestehender Open Hardware
Projekte die Anwendung der speziellen Open Source Softwarelizenzen.Ergänzend findet eine ökonomische
Einordnung der Güter statt, deren Quellcode uneingeschränkt genutzt werden darf. Abschließend liefert der
Autor ein Anwendungsbeispiel in Form eines fiktiven Open Source Akkus zur Elektromobilität, in dem die
Ergebnisse veranschaulicht werden sollen.
Copyright:
Open Hardware von Enno Wichmann steht unter einer Creative Commons Namensnennung-Weitergabe unter
gleichen Bedingungen 3.0 Unported Lizenz.
Über diese Lizenz hinausgehende Erlaubnisse können Sie unter http://www.opensourcebattery.org erhalten.
Inhaltsangabe
1 Einleitung............................................................................................................................... 1
1.1 Einführung.................................................................................................................. 1
1.2 Quellenlage ................................................................................................................ 2
1.3 Aufbau und Methodik................................................................................................. 3
2 Open Source Software.......................................................................................................... 5
2.1 Geschichte der Computer- und Softwareindustrie.....................................................5
2.1.1 Entwicklungsgeschichte der Softwareindustrie.............................................5
2.1.2 UNIX..............................................................................................................6
2.1.3 Hacker und Free Software..............................................................................7
2.1.4 GNU/Linux.................................................................................................... 8
2.2 Software als immaterielles digitales Gut.................................................................... 9
2.3 Free Software und Open Source Software................................................................. 9
2.3.1 Free Software.............................................................................................. 10
2.3.2 Open Source Software..................................................................................11
2.3.3 Verwendung des Begriffs für die vorliegende Arbeit...................................15
2.4 Lizenzen....................................................................................................................16
2.4.1 Softwarelizenzen.......................................................................................... 16
2.4.2 Open Source Softwarelizenzen.................................................................... 16
2.4.2.1 Klassifikation................................................................................... 16
2.4.2.2 Restriktive Lizenzen........................................................................ 17
2.4.2.3 Permissive Lizenzen........................................................................ 18
2.4.2.4 Public Domain................................................................................. 19
2.4.2.5 Mehrfachlizenzierung...................................................................... 19
2.4.3 Rolle der Lizenzen in der Open Source Software Entwicklung..................20
2.5 Durchführung eines Open Source Projekts.............................................................. 21
2.5.1 Wie funktioniert ein Open Source Projekt................................................... 21
2.5.1.1 Entstehung....................................................................................... 21
2.5.1.2 Forking.............................................................................................22
2.5.1.3 Trittbrettfahrerproblem.................................................................... 23
2.5.1.4 Zusammensetzung der Communities...............................................24
2.5.1.5 Kommunikation innerhalb der Community.....................................25
2.5.1.6 Produktion........................................................................................26
2.5.1.7 Distribution...................................................................................... 28
2.5.1.8 Modularisierung...............................................................................29
II
2.5.2 Motivation.................................................................................................... 30
2.5.2.1 Motivation der Entwickler............................................................... 31
2.5.2.2 Motivation der Initiatoren................................................................34
3 Open Hardware................................................................................................................... 36
3.1 Open Hardware als Äquivalent zur Open Source Software.....................................36
3.1.1 Quellcode..................................................................................................... 36
3.1.2 Anwendung.................................................................................................. 38
3.1.3 Besonderheit bei der Hardware im Hinblick auf ihr Endprodukt................38
3.1.4 Lizenzen....................................................................................................... 39
3.1.5 Patente.......................................................................................................... 41
3.1.6 Zwischenergebnis.........................................................................................41
3.2 Projekte..................................................................................................................... 42
3.2.1 Arduino.........................................................................................................44
3.2.2 OpenSPARC.................................................................................................44
3.2.3 RepRap / MakerBot......................................................................................45
3.2.4 FREE BEER.................................................................................................46
3.2.5 Whirlwind Wheelchair................................................................................. 46
3.2.6 Bug Labs...................................................................................................... 47
3.2.7 Open Design – Ronen Kadushin.................................................................. 47
3.2.8 VIA Open Book............................................................................................48
3.2.9 Welche Quellcodes werden verwendet.........................................................48
3.2.10 Bereitstellung des Quellcodes.................................................................... 50
3.2.11 Welche Lizenzen werden verwendet.......................................................... 50
3.2.12 Produktion und Distribution der Produkte................................................. 53
4 Ökonomische Aspekte des Modells Open Source.............................................................55
4.1 Fragestellung............................................................................................................ 55
4.1.1 Allmende und Öffentliches Gut....................................................................55
4.1.2 Gabe, Tausch, Transfer ................................................................................56
4.2 Grenzen geistigen Eigentums................................................................................... 58
4.2.1 Der Zweck geistigen Eigentums.................................................................. 58
4.2.2 Dilemma der Informationsökonomie........................................................... 59
4.2.3 Tragedy of the Anticommons....................................................................... 61
4.2.4 Monopol und bestreitbare Märkte................................................................ 63
4.3 Positive Aspekte des Open Source Modells............................................................. 64
4.3.1 Markteffekte von Open Source Produkten...................................................65
III
4.3.1.1 Standards und Kompatibilität.......................................................... 65
4.3.1.2 Netzwerkeffekt.................................................................................66
4.3.1.3 Pfadabhängigkeit und Lock-in-Effekt.............................................68
4.3.2 Effekte auf Unternehmen............................................................................. 69
4.3.2.1 Komplementärgüter......................................................................... 71
4.3.2.2 Substitutionsgüter............................................................................ 72
4.3.2.3 Wissenstransfer und User Innovation.............................................. 73
4.3.2.4 Strategische Anwendung................................................................. 76
4.3.3 Verwendung von Open Source Produkten...................................................77
4.3.4 Risiken und Chancen für Unternehmen bei Open Hardware Projekten.......79
4.3.4.1 Risiken für Unternehmen.................................................................79
4.3.4.2 Problem Kopie................................................................................. 80
4.3.4.3 Chancen für Unternehmen............................................................... 82
5 Beispiel: Open Source Akku...............................................................................................84
5.1 Problem.....................................................................................................................84
5.2 Lösung...................................................................................................................... 86
6 Fazit...................................................................................................................................... 89
Anhang I: Übersicht Interviews ..........................................................................................93
Anhang II: Datenmaterial.................................................................................................... 94
Literaturverzeichnis............................................................................................................108
IV
1 Einleitung
1.1
Einführung
Die vorliegende, mit dem Begriff „Open Hardware“ überschriebene Arbeit, untersucht, ob die
Prinzipien der Open Source Software auf materielle Güter angewandt werden können.
Open Source Software ist eng mit der Entwicklung des Internets verbunden. Die Entwicklung
des Internets trug maßgeblich dazu bei, dass erfolgreich Programme verbreitet wurden, die
durch die Methode Open Source entwickelt wurden und heute von vielen Menschen
angewendet werden. So wurde für die vorliegende Arbeit das Office-Programm OpenOffice
verwendet, dessen Quelltext im Jahre 2000 veröffentlicht wurde. Beim Kern des
Betriebssystems des hierfür verwendeten Apple Computers handelt es sich ebenfalls um ein
Stück Open Source Software.
Indem das Internet als Plattform einer verteilten und kollaborativen Entwicklungsarbeit dient,
bildet es eine elementare Säule in der Entwicklung von Open Source Programmen. Global
vernetzt, können Programmierer, unabhängig von ihrem Wohnort, an der Entwicklung eines
Computerprogramms teilnehmen.
Doch genau wie die Open Source Software von der erfolgreichen Verbreitung des Internets
profitieren konnte, so profitierte das Internet durch die Anwendung von Open Source
Software (Wechselwirkung). Bei einem erheblichen Teil der Software, die das Internet
betreibt, handelt es sich um Open Source Software. Seit 1996 ist das Open Source Programm
Apache HTTP Server die am häufigsten verwendete Server-Software, die in der Regel auf
Rechnern betrieben wird, deren Betriebssysteme ebenfalls Open Source Software sind (Linux,
BSD). Weil Open Source Software uneingeschränkt genutzt werden kann, stehen die Mittel
zum Betreiben von Webseiten damit jedem offen.
Internet und Open Source Software bilden somit eine Symbiose: Das Internet fördert die
Entwicklung von Open Source Software und trägt zu dessen Verbreitung bei. Zugleich basiert
das Internet auf Open Source Software. Weiterentwicklungen und Verbreitung dieser
Technologien kommen dann wiederum dem Internet zu gute.
Die offene Struktur des Internets und die freie Verfügbarkeit der notwendigen Technologien
bildeten die Grundlage für den Erfolg des World Wide Web (WWW), das 1990 entstand. In
weniger als 15 Jahren drang das WWW in nahezu jeden Bereich des gesellschaftlichen
Lebens vor und verdrängte proprietäre Netzwerke wie BTX in Deutschland oder Minitel in
Frankreich.
1
Das erfolgreiche Rezept des Internets ist die uneingeschränkte Möglichkeit der Partizipation.
Wer auch immer eine Idee hat, kann sich am WWW beteiligen und kann es um neue
Funktionen erweitern. Innovationen finden zu einem erheblichen Maße durch die Nutzer
selbst statt. Es scheint unmöglich, dass ein Unternehmen ein vergleichbares Kommunikationsnetz mit einem annähernd großen Funktionsumfang selbst hätte herstellen können.
Es stellt sich die Frage, ob das gleiche Rezept auch auf materielle Güter angewendet werden
kann, wenn der Innovationsprozess eines Gutes in die Hände derer gelegt würde die es später
auch nutzen würden.
Open Source bedeutet, dass der Quellcode eines Programmes durch jeden genutzt und
weiterverarbeitet werden darf. Der Quellcode eines materiellen Gutes ist das Wissen, das
benötigt wird, um diese Gut herzustellen.
Software wurde bislang überwiegend durch das Urheberrecht bzw. das Copyright geschützt.
Einige Hersteller proprietärer Software bemühen sich gerade für eine stärkere Anwendung
von Patenten auf
Softwareinnovationen, um ihre Produkte besser gegen Konkurrenten
schützen zu können. In ihrer Argumentation verweisen sie dabei auf das seit über 100 Jahren
bestehende Modell des Schutzes technischer Innovationen durch Patente.
Mit dieser Arbeit soll gezeigt werden, dass das erfolgreiche Modell der
Open Source
Software Entwicklung auf den Bereich der technischen Innovationen ange-wendet werden
kann. Unter der Prämisse, dass die Symbiose zur Open Source Software den Erfolg des
Internets begründet, können dann auch unter der Verwendung der Prinzipien des offenen
Wissenstransfers und der freien Partizipation ähnliche Entwicklungssprünge auf anderen
Gebieten als der Softwareentwicklung erreicht werden?
1.2
Quellenlage
Die Frage, ob Nichtsoftware unter den gleichen Bedingungen entwickelt und vertrieben
werden kann wie Open Source Software, wurde in den letzten 20 Jahren von verschieden
Seiten bereits aufgeworfen und zum Teil unterschiedlich beantwortet. In der Literatur wurde
dieses Thema jedoch kaum behandelt und fand erst in den letzten Jahren in einigen Artikeln
Erwähnung.
Da die Thematik dieser Arbeit eine tiefere Auseinandersetzung mit der Thematik der Open
Source Software fordert, zu der in den letzten Jahren, insbesondere ab der Jahrtausendwende,
viel publiziert wurde, sollen diese Publikationen dazu dienen, ein Verständnis für das Prinzip
Open Source zu erarbeiten.
2
Aufgrund der geographischen Konzentration der Softwareentwicklung
in den USA und
Westeuropa, finden sich hier die meisten – überwiegend englischsprachigen – Publikationen
zum Thema Open Source.
Das Thema erfordert einen interdisziplinären Zugang. Da es sich bei Open Source Software
auch um ein Wirtschaftsgut handelt, muss die zentrale Frage, wie die Form des
Wissenstransfers der Open Source Software auch auf die Entwicklung von Nicht-Software
übertragen werden kann, neben dem informationswissenschaftlichen Blickwinkel mindestens
auch aus ökonomischer Perspektive untersucht werden. Die Verwendung spezieller Lizenzen
in der Open Source Software machen auch eine Einbeziehung der Rechtswissenschaften
notwendig.
1.3
Aufbau und Methodik
Ziel dieser Arbeit ist die Untersuchung der Anwendbarkeit der Prinzipien der Open Source
Software auf Nicht-Software, weshalb im zweiten Kapitel zum Verständnis der Prinzipien der
Open Source Software ein grundlegender Einblick in die Entwicklung der Computer- und
Softwareindustrie geliefert werden soll. Ergänzend findet eine Beschreibung der Methode
Open Source statt, in der beispielhaft die Durchführung von Open Source Software Projekten
geschildert wird.
Im dritten Kapitel wird der Begriff „Open Hardware“ geklärt, wobei die im vorangegangenen
Teil der Arbeit erlangten Erkenntnisse auf ihre Anwendbarkeit hin geprüft werden.
Anschließend werden Projekte vorgestellt, die das Prinzip Open Source bereits auf materielle
Güter anwenden.
Das vierte Kapitel liefert eine ökonomischen Analyse des Prinzips Open Source, wobei
dargestellt wird, welche Auswirkungen das Prinzip Open Source auf bestehende
Marktprozesse haben kann und aus welchen Gründen Unternehmen von offenen
Innovationsprozessen profitieren können. Abschließend werden die gewonnen Erkenntnisse
der vorangegangen Kapitel im fünften Kapitel an einem fiktiven Beispiel-Projekt verdeutlicht.
Das Datenmaterial, das für die Untersuchung der Anwendung von Open Source Prinzipien bei
bereits bestehenden Nichtsoftware-Projekten benötigt wurde, wurde mit der Durchführung
von Experteninterviews erhoben. Experten sind in diesem Zusammenhang Personen, die
Open Hardware Projekte initiiert haben oder leitende Aufgaben Open Hardware Projekten
übernehmen. Aufgrund der erst jungen Entwicklung des Themas war die Anzahl der in Frage
kommenden Projekte sehr gering. In Betracht kamen 15 Projekte, von denen lediglich 5
Projekte verwertbare Daten liefern konnten. Die Auswertung der Interviews erfolgte mittels
3
qualitativer Inhaltsanalyse.
Die Befragungen erfolgten schriftlich und in standardisierter, aber offener Form. Die Projekte
sollten nach grundlegenden Eigenschaften untersucht werden, weshalb ein standardisierter
Satz an Fragen am geeignetsten schien. Die Fragen verteilten sich auf die Bereiche
Motivation, Praxis, Urheberrecht und Wirtschaft. Um den befragten Personen dennoch die
Gelegenheit zu geben, Besonderheiten ihres Projekts in die Antworten einfliessen zu lassen,
wurden die Fragen möglichst offen gestellt.
Die Interviews wurden wegen der Internationalität der Projekte schriftlich durchgeführt. Der
überwiegende Teil der Projekte befand sich ausserhalb Deutschlands, hier mit dem
Schwerpunkt USA. Eine persönliche Befragung vor Ort war dadurch ausgeschlossen. Von
einer Befragung per Telefon wurde aus zwei Gründen abgesehen: es sollten potentielle
Missverständnisse vermieden werden, die sich allein durch die Fremdsprache im laufenden
Gespräch hätten ergeben können. Zum anderen ermöglichte die Schriftform, auf Fragen
ruhiger und reflektierter zu antworten.
Der asynchrone Gesprächsablauf einer schriftlichen Befragung erschien darum als beste
Lösung. Auf die einmal gegebenen Antworten konnte mit gezielten Gegenfragen reagiert
werden.
Eine Anonymisierung der Projekte findet nicht statt, da sich alle Projekte mit der
namentlichen Darstellung einverstanden erklärten.
Da es sich bei den untersuchten Projekten um Projekte handelt, die in der Regel gut
dokumentiert sind und sich nach außen transparent präsentieren, konnten auch Daten zu
Projekten erhoben werden, bei denen keine direkte Befragung möglich war.
4
2 Open Source Software
Um den Begriff Open Hardware als Äquivalent zum Begriff der Open Source Software
verwenden zu können, soll in diesem Kapitel ein grundlegendes Verständnis des Begriffs
Open Source Software geschaffen werden.
Dabei wird zunächst kurz die Entwicklungsgeschichte des Computers umrissen, die eng mit
der Entstehungsgeschichte der Software verbunden ist. Dabei konkurriert der Begriff der
Open Source Software mit dem älteren Begriff der Free Software. Obwohl beide Begriffe die
gleichen Methoden anwenden – den freien Zugang zum Quellcode eines Computerprogramms
– unterscheiden sie sich stark in ihren grundlegenden Motiven im Hinblick auf den Grund der
Veröffentlichung. Um die Begriffe voneinander abzugrenzen, werden deshalb die jeweiligen
Entstehungsgeschichten der beiden Modelle ausführlich geschildert.
2.1
2.1.1
Geschichte der Computer- und Softwareindustrie
Entwicklungsgeschichte der Softwareindustrie
Die Entwicklungsgeschichte der Softwareindustrie ist untrennbar verbunden mit der
Entwicklung der Computers. Das moderne Computerzeitalter beginnt Mitte der 40er Jahre des
20. Jahrhunderts mit der Entwicklung des Digitalcomputers, wobei die kommerzielle
Produktion von Computern in den 1950er Jahren begann (vgl. Tannenbaum, 2009, S. 38ff.).
Bis weit in die 1960er Jahre wurde der Computermarkt allein von Hardwareherstellern
dominiert. Der Begriff Software als Beschreibung eines Computerprogramms wurde erstmals
von John W. Turkey im Jahr 1958 benutzt (vgl. Stiegler und Roesler, 2005, S.82). Software
wurde als kostenlose Zugabe zur Hardware durch die Hersteller geliefert, ein Copyright
wurde nicht beansprucht. Die Software war quelloffen und konnte durch die Nutzer verändert
und frei getauscht werden, so dass Softwareprogrammierer diese Software verbesserten oder
sie speziellen Bedürfnissen anpassten. Die so modifizierte Software wurde untereinander
ausgetauscht.
Damalige Software war in Maschinensprache geschrieben und funktionierte ausschließlich
auf den Maschinen eines Herstellers. Die Verfügbarkeit von Software durch ihre starke
Verbreitung und die freiwillige Verbesserung durch Programmierer, diente den Herstellern als
Verkaufsargument für ihre teure Hardware, so dass die Hardwarehersteller, durch die
Zurverfügungstellung der quelloffenen Software profitierten. War eine Software für ein
System nicht vorhanden, hätte sie von Grund auf neu geschrieben werden müssen.
5
2.1.2
UNIX
In den 1960er Jahren begann der Programmierer Ken Thompson in den Bell Laboratories
(Bell Labs), eine Forschungs- und Entwicklungseinrichtung des Telekommunikationsunternehmens AT&T, mit der Entwicklung eines neuartigen Betriebssystems, dass auf jeder
Plattform lauffähig sein sollte. Die erste Version dieses Betriebssystems, UNIX, entstand
1969.
1971 führte AT&T UNIX als standardmäßiges Betriebssystem auf seinen Rechnern ein. Da es
AT&T zu dieser Zeit kartellrechtlich verboten war, UNIX kommerziell zu vermarkten, boten
die Bell Labs Kopien der Software Universitäten zum Selbstkostenpreis an (vgl. Kirkwood,
2004, S. 287 und Rosenberg, 2000, S. 30). Daraufhin konnten die Universitäten, die auch den
Quellcode der Software erhielten, an UNIX Weiterentwicklungen und Verbesserungen
vornehmen. Um das Betriebssystem UNIX herum entwickelte sich schnell eine Community
von freiwilligen Entwicklern, deren Änderungsvorschläge in die offizielle Version mit
einflossen.
An der University Berkeley etablierte sich das akademisches Zentrum der UNIXEntwicklung, das 1977 in einer eigenen Distribution, der „Berkeley Software Distribution“,
kurz BSD, mündete. Distribution bezeichnet in diesem Zusammenhang die Zusammenstellung verschiedener Softwarekomponenten zu einem Komplettpaket.
1982 wurde AT&T aufgrund eines Gerichtsurteils in mehrere Unternehmen aufgeteilt. AT&T
konnte sich nach der Zerschlagung auch ausserhalb des Telekommunikationsmarktes
unternehmerisch betätigen (vgl. Teupen, 2007, S.39 und AT&T, 2010), so dass AT&T das
Unternehmen Unix System Laboratories (USL) gründete, das sich mit der kommerziellen
Vermarktung des Produkts UNIX befasste. Obwohl es schon seit 1980 rechtlich möglich war,
das Copyright auch auf den Code von Software anzuwenden (Kizza, 2010, S. 123 f.), blieb
der UNIX-Quellcode bis zur Gründung von USL frei verfügbar.
Danach durfte der UNIX-Quellcode nicht mehr frei weitergegeben werden. Für die
Verwendung des UNIX-Codes verlangt AT&T von nun an Lizenzgebühren. Mit der Zeit
entstanden neben BSD und AT&Ts eigenem System auch kommerzielle Distributionen anderer
Hersteller. Um sich von der Konkurrenz abheben zu können, entwickelten die Hersteller für
ihre Distributionen proprietäre Zusätze. Die Distributionen wurden untereinander zunehmend
inkompatibel; die ursprünglich einheitliche UNIX-Welt spaltete sich in unterschiedliche
Entwicklungszweige auf.
6
2.1.3
Hacker und Free Software
Während der 1970er Jahre war das Artificial Intelligence Lab (AI Lab) des Massachusetts
Institute of Technology (MIT) das Zentrum der Hackergemeinde. Hacker nannten sich die
Technik-Freaks, die seit Ende der 1950er Jahre versuchten die Möglichkeiten der damaligen
Computer auszuschöpfen und zu erweitern. Ein bekannter Ausspruch verdeutlich ihre
Bestrebungen:
„It wasn't meant to do this but I can make it do this!“ (Rosenberg, 2000, S.6)
Ihr gemeinsames Selbstverständnis, die sog. Hackerethik, wurzelte in den gesellschaftlichen
Entwicklungen der damaligen Zeit und stellte den freien Zugang zu Informationen in den
Vordergrund. Die Existenz einer an Freiheit und Antiautorität orientierten Ethik, die
insbesondere in Steven Levys Werk „Hackers“ (Levy, 2001) formuliert ist und
Arbeitseinstellung von einer Vielzahl von Programmiern wurde, mündete später in der Idee
des Open Source.
1971 begann der Student Richard M. Stallman seine Arbeit am MIT und wurde Teil der
Hackergemeinschaft1.
Die Entwicklung des Editors EMACS durch Stallmann, das vielleicht erste Open Source
Programm, verdeutlicht wie die Hackerethik seine Arbeitsweise bestimmte. Die offene
Struktur des EMACS ermöglichte es anderen Programmierern, Zusätze für das Programm zu
schreiben. Stallman reichte das Programm frei weiter und stellte umgekehrt die Bedingung,
dass alle Erweiterungen an ihn zurückgereicht werden müssen, um die Entwicklung des
Editors zu unterstützen.
„As I shared it, it was their duty to share; to work with each other rather than against!“
(Richard M. Stallman, n.d.)
EMACS entwickelte sich zunehmend zum Standard-Editor und zeigte, welches Potential der
sog. Hacker-Geist, freie Weitergabe, Entwicklung und Verbreitung, birgt. Anfang der 1980er
Jahre fand ein Generationswechsel sowohl bei Programmierern, die eine Anwendung des
Copyright auf Software in stärkerem Maße akzeptierten, sowie in der Technik statt. Die
modernen Systeme, die zunehmend die alten Maschinen an den Universitäten ersetzten,
wurden nur noch mit eigenen proprietären Betriebssystemen ausgeliefert. Erhältliche
Software war dadurch fast nur noch proprietär verfügbar.
1 Steven Levy beschreibt Richard Stallman in der Ausübung der Hackerethik als geradezu militant (Levy 2001,
S. 415).
7
Stallman beschloss daraufhin, ein eigenes freies Betriebssystem zu entwickeln. Er benannte es
mit dem rekursiven Akronym GNU, „Gnu is not UNIX“ (GNU, n.d.). GNU sollte zwar
funktional äquivalent zu UNIX sein, jedoch keine Zeile des durch AT&T geschützten UNIXCode enthalten. UNIX besaß zur angestrebten verteilten Entwicklung bereits eine große
Nutzer- und Entwicklungsgemeinschaft und bestand aus einer Architektur, die es ermöglichte,
dass die vielen kleineren Softwareteile unabhängig voneinander entwickelt werden konnten.
Nach Austritt aus dem MIT gründete
Richard M. Stallman 1985 die Free Software
Foundation (FSF), welche Distribution und Finanzierung des Betriebssystems übernehmen
sollte.
Obwohl die GNU-Software kostenlos über einen ftp-Server verfügbar war, wurde sie auch auf
Datenträgern zum Kauf angeboten. EMACS war so zum Beispiel für 150 Dollar erhältlich
(Rosenberg, 2000, S.11). Aus den Einnahmen wurden Programmierer für das GNU-Projekt
angestellt.
Die produzierte Software war ein „Public Good“, und damit frei von jeglichem Copyright
(vgl. Stallman, n.d.). Es bestand die Gefahr, dass Dritte den Code auch nach nur marginalen
Änderungen zu ihren Gunsten durch das Copyright sichern konnten. Im Zuge dieser
Problematik entwickelte Richard Stallman den Gedanken des „Copyleft“, einer Art
Umkehrung des Copyright, und daraus die „General Public Licence“ (GPL) (GNU, 2007),
eine spezielle Lizenz, um den frei verfügbaren Quellcode davor zu schützen, zukünftig unter
einen Rechtsschutz zu fallen, der es verbieten würde, diesen Code frei zur Verfügung zu
stellen.
2.1.4
GNU/Linux
Der finnische Student Linus Torvalds entwickelte auf Basis des UNIX-Klons MINIX einen
eigenen Betriebssystem Kernel. Der Quellcode des durch Andrew S. Tanenbaum für die Freie
Universität Amsterdam (Vrije Universiteit Amsterdam) Entwickelte MINIX war frei
verfügbar.
Am 17. September 1991 veröffentlichte Linus Torvalds sein Ergebnis mit dem Namen Linux
und der Versionsnummer 0.01 auf einem ftp-Server seiner Universität. Torvalds verbesserte
das System stetig, und stellte immer die neueste Version auf dem Server zum Download zur
Verfügung. Die Version 0.02 folgte bereits Anfang Oktober, also nur wenige Wochen später.
Torvalds berichtet in Newsgroups von seinem Projekt, ein eigenes Betriebssystem zu
erstellen, und lud Interessenten zur Mitarbeit ein.
Anfangs wurde Linux unter einer eigenen Lizenz veröffentlicht, die unter anderem eine
8
kommerzielle Nutzung verbot. Torvalds entschloss sich, den Entwicklern von Linux mehr
Freiheiten einzuräumen, und stellte Linux 1992 unter die GPL des GNU-Projekts.
Linux war kein vollständiges Betriebssystem, sondern bildete nur einen so genannten Kernel,
der innere Kern eines Betriebssystem. Nachdem Torvalds Linux durch die GPL lizenzierte,
handelte es dabei um Freie Software. Das war der Schritt, um beide Projekt vereinigen zu
können. GNU und Linux bilden zusammen das freie Betriebssystem GNU/Linux.
2.2
Software als immaterielles digitales Gut
Die Besonderheit des digitalen Gutes Software ist, dass es verlustfrei reproduzierbar ist. Da
Kopien mit dem Original identisch sind, können sie wiederum als Vorlage für weitere Kopien
herangezogen werden. Digitale Güter sind daher praktisch unendlich skalierbar und ihre
Produktionskosten entsprechend gering.
Daraus ergibt sich, dass digitale Güter einfach, schnell und verlustfrei weitergegeben werden
können. Wird eine Software durch Person A an Person B weitergegeben, kann sie von A
anschließend weiterhin genutzt werden. Man spricht hier von einer Nicht-Rivalität im
Konsum (vgl. Mundhenke, 2007, S. 23). Bei der Weitergabe materieller Güter entsteht immer
ein Verzicht bei dem Weitergebenden. Folglich handelt es sich bei Software um ein
immaterielles Gut.
Aus ökonomischer Sicht betragen die Grenzkosten für immaterielle Güter annähernd Null.
Mit Grenzkosten werden die Kosten bezeichnet, die durch die Produktion eines zusätzlichen
Stückes eines Gutes entstehen (Samuelson, Nordhaus, 2007, S. 219 ff.). Belaufen sich die
Kosten der Produktion des ersten Stück eines Gutes auf 1000 Euro und die Produktion von 2
Stück auf 1001 Euro, so betragen die Grenzkosten des Gutes genau 1 Euro. Die 1000 Euro
des ersten Stücks beinhalten auch die Fixkosten der Produktion, beispielsweise die Miete des
Produktionsgebäudes, den Lohn der Angestellten, die Kosten für Energie und die Kosten für
Forschung und Entwicklung.
Weil sich jede weitere Kopie eines immateriellen Gutes praktisch kostenlos herstellen liesse,
betragen ihre Grenzkosten folglich annähernd Null.
2.3
Free Software und Open Source Software
Der Begriff Open Source Software hat sich zu einem Sammelbegriff entwickelt, unter dem
sich quelloffene Software gruppiert, deren Lizenzen aber zum Teil unterschiedliche
Auswirkungen auf Anwender und Entwickler haben können. Die Open Source Community
spaltet sich in zwei Lager auf, entlang deren Grenzen auch die Diskussion um die
Namensgebung von Open Source Software verläuft.
9
Einerseits existiert ein eher ideologisch ausgerichtetes Lager, das sich um die FSF formiert,
und welches den Namen Free Software nutzt. Das eher pragmatisch orientiert Lager
verwendet den Begriff Open Source Software.
2.3.1
Free Software
Free Software ist der deutlich ältere Begriff und wurde Anfang der 1980er Jahre durch
Richard Stallman geprägt. Die FSF, die sich auf die Hacker Ethik der 1960er und 1970er
beruft, versteht sich als soziale Bewegung, was das folgende Zitat verdeutlicht, und das
bereits eine Abgrenzung zum Begriff Open Source Software vorwegnimmt:
„Nearly all open source software is free software. The two terms describe almost the same
category of software, but they stand for views based on fundamentally different values.
Open source is a development methodology; free software is a social movement. For the
free software movement, free software is an ethical imperative, because only free software
respects the users' freedom. By contrast, the philosophy of open source considers issues in
terms of how to make software “better”—in a practical sense only. It says that nonfree
software is an inferior solution to the practical problem at hand. For the free software
movement, however, nonfree software is a social problem, and the solution is to stop using
it and move to free software.“
(Stallman, n.d. a)
Die FSF benennt vier Freiheiten, die Software erfüllen muss, um Free Software zu sein.
Freiheit 02:
The freedom to run the program, for any purpose.
(Die Freiheit, das Programm zu jedem Zweck ausführen zu können.)
Freiheit 1:
The freedom to study how the program works, and change it to make it do what you wish.
(Die Freiheit, ein Programm zu untersuchen, wie es funktioniert, und zu verändern, damit
es macht, was du willst.)
Freiheit 2:The freedom to redistribute copies so you can help your neighbour.
(Die Freiheit, Kopien zu verbreiten, so dass du deinem Nachbarn helfen kannst.)
Freiheit 3:
The freedom to distribute copies of your modified versions to others. By doing this you can
2 Weil in der Informatik nummerierte Indizes häufig mit einer 0 beginnen, beginnt auch hier die Nummerierung
mit einer 0.
10
give the whole community a chance to benefit from you changes.
(Die Freiheit, veränderte Versionen eines Programmes zu verbreiten. Dadurch kann die
Gemeinschaft von deinen Verbesserungen profitieren)
Für Freiheit 1 und 3 ist der Zugang zum Quelltext einer Software zwingend erforderlich. Eine
Software, die nicht alle der genannten Freiheiten erfüllt, wird als unfrei bezeichnet.
Ein Kritikpunkt, der oft im Zusammenhang mit dem Begriff der Free Software angebracht
wird, ist die Zweideutigkeit des Wortes „free“. In der englischen Sprache bedeutet es sowohl
„frei“ als auch „kostenlos“, was hinsichtlich der Kostenlosigkeit dazu führen könnte, dass
Unternehmen von einer Investition abgeschreckt werden. Tatsächlich aber erlauben die
Regeln der FSF sogar den Verkauf von Free Software. Richard Stallman und GNU reagierten
auf diesen Konflikt mit dem Ausspruch:
„Free Software is a matter of liberty, not price. To understand the concept, you should
think of free as in free speach, not as in free beer.“
(GNU, 2010)
2.3.2
Open Source Software
So, wie die FSF mit der Person Richard Stallmans verbunden ist, steht für die Open Source
Software der Name Eric S. Raymond. Raymond stellte am 27. Mai 1997 auf einem Linux
Kongress in Würzburg seinen Essay „The Cathedral and the Bazaar“ (Raymond 2001) vor, in
dem er seine Beobachtungen beschrieb, die er bei der Entwicklung des Linux Kernels und der
Leitung des eigenen Open Source Projekts fetchmail sammelte.
Kern seines Essays ist der Vergleich zweier Entwicklungsmethoden, die Raymond durch die
Metaphern der Kathedrale und des Basars verdeutlicht. Die Kathedrale symbolisiert den
Entwicklungsansatz des Top-Downs, in dem vor dem Beginn der Entwicklung einer Software
die Formulierung eines konkreten Ziels liegt; dieses Ziel gibt dann die folgenden
Entwicklungsschritte fest vor. Im Gegensatz dazu beginnt die Methode des Bottom-Ups mit
der Entwicklung der untergeordneten Teilen, aus denen ein Programm bestehen soll; das
Große Ganze ergibt sich erst zum Schluss aus der Verbindung der fertigen Teile.
Raymond stellt mit diesem Vergleich das GNU-Projekt Richard Stallmans dem aus seiner
Sicht erfolgreicheren Linux-Projekt Linus Torvalds gegenüber. Stallman gibt die Entwicklung
der GNU-Software vor, veröffentlicht wird immer nur der Quellcode einer fertigen Version
einer Software. Im Gegensatz dazu verhält sich die Entwicklergemeinde des Linux-Projekts
wie ein chaotischer Basar, in der jeder Programmierer wie ein Händler agiert und sein
11
Produkt, ein Stück Programmcode, anbieten kann.
Linus Torvalds, der als Leiter des Linux Projekts fungiert, veröffentlicht neben den offiziellen
Versionen des Linux Kernels zusätzlich den noch nicht fertig gestellten Entwicklungsstand
der Software. Die Veröffentlichungen der Codes erfolgen dadurch ziemlich häufig, wodurch
mehrmals täglich Veröffentlichungen erfolgen können, auch wenn diese sich nur wenig
unterscheiden.
Raymond bezeichnet diese Praxis als „Linus' Law“, denn durch die häufige und frühe
Veröffentlichung des Quellcodes bereits im Entwicklungsstadium, wird das Programm einer
großen Zahl Betatestern zugeführt, so dass Fehlfunktionen (Bugs) schneller identifiziert, in
Bugreports öffentlich dokumentiert, von Entwicklern schneller behoben werden können (vgl.
Raymond, 2001, S.28-38).
Zwei Zitate sollen das Verständnis Raymonds von Open Source Software und seine
Abgrenzung zu den Ideen der FSF verdeutlichen:
„The Linux world behaves in many aspects like a free market of an ecology, a collection of
selfish agents attempting to maximise utility, which in the process produces a selfcorrecting spontaneous order more elaborate and efficient than any amount of central
plannig could have achieved.“
(Ramyond, 2001, S.52)
„Perhaps in the end the open-source culture will triumph not because cooperation is
morally right or software 'hoarding' is morally wrong (assuming you believe the latter,
which neither Linus nor I do), but simply because the closed-source world cannot win an
evolutionary arms race with open-source communities that can put order of magnitude
more skilled time into a problem.“
(Raymond, 2001, S.54)
Insbesondere im zweiten Zitat wird der eher pragmatische Ansatz Raymonds deutlich. Eine
Software Open Source zu entwickeln versteht Raymond als überlegenes Entwicklungsprinzip.
Moralische Motive, wie Richard Stallman sie mit der Free Software verfolgt, spielen
hingegen keine Rolle.
Die unter anderen durch Raymond gegründete Open Source Initiative nimmt auf ihrer
Webseite3 folgende Selbstdefinition vor:
3 http://www.opensource.org/, letzter Aufruf: 17.12.2010
12
„Open source is a development method for software that harnesses the power of
distributed peer review and transparency of process. The promise of open source is better
quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lockin.“
Motiviert durch den Essay Raymonds beschloss die Firma Netscape 1998, den Quellcode
ihres Internetbrowsers Navigator zu veröffentlichen, welches zunehmend durch Microsofts
Internet Explorer vom Markt verdrängt wurde. Es entstand das Mozilla Projekt welches die
Weiterentwicklung des Browser nun unter Open Source Bedingungen fortführen sollte,
wodurch der Browser Firefox entstand, der nach dem Internet Explorer mittlerweile der
weltweit am häufigsten genutzte Browser ist (StatCounter, 2010).
Im Zuge der Entstehung des Mozilla Projekts gründeten Eric Raymonds und einige Mitstreiter
die schon erwähnte Open Source Initiative (OSI). Sie wählten den Namen Open Source, um
sich von dem als zu ideologisch empfundenen Charakter der FSF zu distanzieren. Allein das
Entwicklungsprinzip sollte in den Vordergrund gestellt und Unternehmen für ein Engagement
gewonnen werden.
Die OSI entwickelt keine eigenen Lizenzen, zertifiziert aber Lizenzen anderer Initiativen.
Dafür hat die OSI einen eigenen Katalog an Richtlinien entwickelt, dem Open Source
Lizenzen erfüllen müssen. Die GPL der FSF ist, weil sie diese Richtlinien erfüllt, ebenfalls
eine durch die OSI zertifizierte Lizenz.
Die OSI nennt in ihrer Open Source Definition zehn Richtlinien (OSI, n.d.), die eine Open
Source Lizenz erfüllen muss:
1. Freie Weitergabe:
Die Lizenz darf niemanden in seinem Recht einschränken, die Software als Teil eines
Software-Pakets, das Programme unterschiedlichen Ursprungs enthält, zu verschenken
oder zu verkaufen. Die Lizenz darf für den Fall eines solchen Verkaufs keine Lizenzoder sonstigen Gebühren vorschreiben.
2. Quellcode:
Das Programm muss den Quellcode beinhalten. Die Weitergabe muss sowohl für den
Quellcode als auch für die kompilierte Form zulässig sein. Wenn das Programm in
irgendeiner Form ohne Quellcode weitergegeben wird, so muss es eine allgemein
bekannte Möglichkeit geben, den Quellcode zum Selbstkostenpreis zu bekommen,
vorzugsweise als gebührenfreien Download aus dem Internet. Der Quellcode soll die
Form eines Programms sein, die ein Programmierer vorzugsweise bearbeitet.
13
Absichtlich unverständlich geschriebener Quellcode ist daher nicht zulässig.
Zwischenformen des Codes, so wie sie etwa ein Präprozessor oder ein Konverter
(„Translator“) erzeugt, sind unzulässig.
3. Abgeleitete Software:
Die Lizenz muss Veränderungen und Derivate zulassen. Außerdem muss sie es
zulassen,
dass
die
solcherart
entstandenen
Programme
unter
denselben
Lizenzbestimmungen weitervertrieben werden können wie die Ausgangssoftware.
4. Unversehrtheit des Quellcodes des Autors:
Die Lizenz darf die Möglichkeit, den Quellcode in veränderter Form weiterzugeben,
nur dann einschränken, wenn sie vorsieht, dass zusammen mit dem Quellcode so
genannte „Patch files“ weitergegeben werden dürfen, die den Programmcode bei der
Kompilierung verändern. Die Lizenz muss die Weitergabe von Software, die aus
verändertem Quellcode entstanden ist, ausdrücklich erlauben. Die Lizenz kann
verlangen, dass die abgeleiteten Programme einen anderen Namen oder eine andere
Versionsnummer als die Ausgangssoftware tragen.
5. Keine Diskriminierung von Personen oder Gruppen:
Die Lizenz darf niemanden benachteiligen
6. Keine Einschränkung bezüglich des Einsatzfeldes:
Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten
Bereich einzusetzen. Beispielsweise darf sie den Einsatz des Programms in einem
Geschäft oder in der Genforschung nicht ausschließen.
7. Weitergabe der Lizenz:
Die Rechte an einem Programm müssen auf alle Personen übergehen, die diese
Software erhalten, ohne dass für diese die Notwendigkeit bestünde, eine eigene,
zusätzliche Lizenz zu erwerben.
8. Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein:
Die Rechte an dem Programm dürfen nicht davon abhängig sein, ob das Programm
Teil eines bestimmten Software-Paketes ist. Wenn das Programm aus dem Paket
herausgenommen und im Rahmen der zu diesem Programm gehörenden Lizenz
benutzt oder weitergegeben wird, so sollen alle Personen, die dieses Programm dann
erhalten, alle Rechte daran haben, die auch in Verbindung mit dem ursprünglichen
Software-Paket gewährt wurden.
14
9. Die Lizenz darf die Weitergabe zusammen mit anderer Software nicht einschränken:
Die Lizenz darf keine Einschränkung enthalten bezüglich anderer Software, die
zusammen mit der lizenzierten Software weitergegeben wird. So darf die Lizenz z.B.
nicht verlangen, dass alle anderen Programme, die auf dem gleichen Medium
weitergegeben werden, auch quelloffen sein müssen.
10. Die Lizenz muss technologieneutral sein:
Kein Teil der Lizenz darf eine bestimmte Technologie oder Schnittstelle voraussetzen.
(Eigene Übersetzung)
(Übersetzung: Debian GNU/Linux Anwenderhandbuch, n.d.)
Mit ihrer Definition gibt die OSI einen präzisen Rahmen vor, innerhalb dessen sich eine Open
Source Software Lizenz bewegen darf. Die OSI listet 67 Lizenzen auf, die diesen Richtlinien
entsprechen (OSI, n.d. a). Viele dieser Lizenzen stammen von Unternehmen, die eigene
Lizenzen verfassten haben, um sie in eigenen Open Source Projekten anzuwenden, so z.B.
von Microsoft, Apple und Nokia.
Unterscheidungsmerkmale zwischen den Lizenzen sind meist der Geltungsbereich der Lizenz
auf den weitergegebenen Quellcode und die Kombinationsmöglichkeiten mit Software, die
unter anderen Lizenzen lizensiert sind. Abhängig von ihrer Lizenz dürfen einige Open Source
Programme mit proprietärer Software kombiniert werden, was für andere wiederum
unmöglich ist.
2.3.3
Verwendung des Begriffs für die vorliegende Arbeit
Mit der Free Software Foundation und der Open Source Initiative wurden die wichtigsten
Protagonisten der Open Source Community genannt. Die FSF verfasste mit der GPL die erste
und bis heute am häufigsten verwendete Open Source Lizenz 4, die OSI hat ein Regelwerk
verfasst, welches Open Source Lizenzen erfüllen müssen, um als Open Source Lizenz gelten
zu dürfen.
In den vorangegangenen Abschnitten wurden die Motive dieser beiden Fraktionen erklärt und
ihre Auffassung des Prinzips verdeutlicht, das entweder als Free oder Open Source Software
benannt wird. Open Source Software ist dabei der weitaus globalere Begriff, schließt er doch
unterschiedliche Auslegungen des zugrunde liegenden Prinzips ein. Das wird dadurch
deutlich, dass es sich bei Free Software um eine Teilmenge der Open Source Software
4 Auf der Open Source Plattform sourceforge.org ist die GPL mit 965 Projekten die am meist verwendete
Lizenz. Auf Platz zwei und drei folgen die GPL der Version 3.0 mit 85 und die LGPL mit 53 Projekten. Mit 16
Projekten folgt die BSD License als erste nicht GNU-Lizenz auf Platz vier. (Stand: Dezember 2010)
15
handelt. Im weiteren Verlauf der Untersuchung wird ausschließlich der Begriff Open Source
Software verwendet, der den Begriff Free Software einschließt. Sollte in dieser Arbeit die
Bezeichnung Free Software verwendet werden, ist auch explizit von dem Begriff Free
Software die Rede.
Für den Titel der vorliegenden Arbeit wurde – in Anlehnung an den Begriff Open Source –
der Begriff „Open Hardware“ gewählt, und dabei dem Begriff „Free Hardware“ vorgezogen.
Dadurch sollt auch dem weiteren Begriffsraum der Open Source Software Rechnung
getragen werden. Open Hardware soll damit als Äquivalent zur Open Source Software
betrachtet werden, weil die Prinzipien der Open Source Software insgesamt auf ihre
Anwendbarkeit zur Hardware untersucht werden.
2.4
Lizenzen
2.4.1
Softwarelizenzen
Das Copyright und die daraus abgeleiteten Software Lizenzen spielen in der Realisierung der
Open Source Lizenzen eine zentrale Rolle. 1980 erlaubte eine Reform des Copyrights in den
USA (Kizza, 2010, S. 123 f.), Software als literarische Werke zu betrachten, wodurch
Software mittels des Copyrights geschützt werden konnte 5.
Die
Anwendung
des
Copyrights
auf
Software
und
die
Zunahme
proprietärer
Computerprogramme, die sich dadurch auszeichnen, dass die Einsicht in ihren Quellcode
ausgeschlossen ist, war schließlich der Auslöser für die Entstehung von Free Software. Erst
das Copyright ermöglicht auch die Anwendung der Lizenzen der Free Software und später der
Open Source Software Bewegung.
2.4.2
Open Source Softwarelizenzen
2.4.2.1
Klassifikation
Lerner und Tirole (2002, S. 2) klassifizieren Open Source Lizenzen anhand zweier Merkmale:
1. Der Quellcode eines modifizierten Programms muss im Fall einer Distribution
wiederum veröffentlicht werden.
2. Der Quellcode des Programms darf nur mit Quellcode vermischt werden, der unter
selben Lizenz veröffentlicht wurde.
Die erste Eigenschaft wird als Copyleft bezeichnet, die Zweite als Reziprozität. Erfüllt eine
Lizenz die erste Eigenschaft, so gilt sie als restriktiv. Erfüllt eine Lizenz beide Eigenschaften
gilt sie als hochrestriktiv. Lizenzen, die keine der Eigenschaften erfüllen, werden als
5 Seit 1993 ist es auch in Deutschland möglich, Computerprogramme urheberrechtlich schützen zu lassen.
16
unrestriktiv oder permissiv bezeichnet.
Copyleft ist eine spezielle Form des Copyrights. Ein Urheber, der sein Werk unter einer
Copyleft-Lizenz veröffentlicht, bedient sich weiterhin seines Copyrights, indem er
vorschreibt, unter welchen Bedingungen sein Werks zukünftig verwendet werden darf, so dass
Modifikationen ebenfalls zwingend veröffentlicht werden müssen. Copyleft ist daher kein
Verzicht auf Copyright. Der Verzicht auf das Urheberrecht würde auch den Verlust jeglichen
Einflusses auf das Werk bedeuten. Ein in diesem Sinne freies Werk könnte nicht mehr vor
einer späteren kommerziellen Verwertung durch Dritte geschützt werden.
Im deutschen Recht ist ein vollständiger Verzicht des Urhebers auf seine Urheberrechte
ohnehin nicht möglich. Eine Lizenz, die dies beabsichtigen würde, könnte im Geltungsbereich
des deutschen Urheberrechts keine Rechtswirkung entfalten (vgl. Teupen 2007, S. 56).
Ziel des Copylefts ist es, die besonderen Bedingungen, unter denen eine Open Source
Software veröffentlicht wurde, auch für Weiterentwicklungen des Programms durchzusetzen.
Einmal frei gegebenes Wissen soll dadurch niemals wieder nicht-frei gemacht werden
können.
Reziprozität wird auch als virale Eigenschaft (Mundie, 2001) bezeichnet. Reziproke Lizenzen
verlangen, dass unter ihr veröffentlichte Software nur mit Software kombiniert werden darf,
die unter den selben Lizenzbedingungen veröffentlicht wurde (siehe GPL § 5, Condition c
(GNU, 2007)). Dadurch wird verhindert, dass eine freie Software ihre besonderen
Lizenzbedingungen verliert, wenn sie mit Software kombiniert wird, die unter anderen
Lizenzbedingungen veröffentlicht wurde.
Copyleft und Reziprozität führen dazu, dass ein Stück Quellcode niemals seine Lizenz
verlieren kann und immer ein Stück Open Source Software bleiben wird. Möchte ein
proprietäres Softwareprojekt auf Software zurückgreifen, welches unter einer hochrestriktiven
Lizenz veröffentlicht wurde, muss es ebenfalls diese Lizenz annehmen und ebenfalls zu Open
Source Software gemacht werden.
Im weiteren Verlauf dieser Arbeit wird zur Klassifikation von Lizenzen auf dieses Model von
Lerner und Tirole zurückgegriffen werden.
2.4.2.2
Restriktive Lizenzen
Ein typisches Beispiel für eine hochrestriktive Lizenz ist die GPL. Sie beinhaltet das Prinzip
des Copyleft und ist reziprok. Dadurch müssen Veränderungen der Software, die durch die
GPL geschützt sind, aufgrund des Copylefts wiederum unter der GPL veröffentlicht werden.
17
Im Falle einer Zusammenführung zweier Programme, von denen eines durch die GPL
geschützt wird, verlangt die Reziprozität der GPL, dass auch das Resultat durch die GPL
geschützt werden muss.
Durch die Reziprozität kann es durchaus zu Konflikten kommen, insbesondere, wenn
Programme eigenen Lizenzen unterliegen, die ihrerseits Regeln definieren, die im Falle einer
Zusammenführung eingehalten werden müssen (siehe BSD-Lizenz im folgenden Abschnitt).
So existieren eine Reihe von Lizenzen, die zur GPL inkompatibel sind.
Auch für ein Unternehmen, das für eine eigene Software eine proprietäre Lizenz verwenden
möchte, müsste im Fall einer Zusammenführung die eigene Lizenz zugunsten der GPL
aufgeben.
Mit der LGPL (Lesser General Public Licence) bietet die FSF auch eine restriktive Lizenz an.
Sie erfüllt nur die Copyleft Regel. Unter der LGPL veröffentlichte Software kann darum auch
mit Software anderer Lizenzen kombiniert werden. Üblicherweise wird sie für
Programmbibliotheken verwendet (Sammlungen von Funktionen) auf die andere Programme
zugreifen können. Eine unter der LGPL veröffentlichte Programmbibliothek darf darum auch
von proprietärer Software genutzt werden.
2.4.2.3
Permissive Lizenzen
Bekanntestes Beispiel für eine permissive Lizenz ist die BSD-Lizenz. Die BSD-Lizenz, die für
das gleichnamige UNIX-Betriebssystem entwickelt wurde, ist eine der frühesten Open Source
Lizenzen.
Die BSD-Lizenz ist nicht reziprok und enthält auch kein Copyleft. Software, die unter der
BSD-Lizenz veröffentlicht wird, darf kopiert und verändert werden und kann auch mit Code
kombiniert werden, der unter einer fremden Lizenz steht. Weiterentwicklungen des
Quelltextes dürfen, müssen aber nicht, veröffentlicht werden. Damit schließt die BSD-Lizenz
eine proprietäre Nutzung mit ein.
Bedingung hingegen ist, dass der Copyrightvermerk und die Lizenzbedingungen des
ursprünglichen Programms genannt werden müssen. BSD-lizensierte Software wurde in der
Vergangenheit oft als Vorlage für proprietäre Softwareprojekte genutzt. Bekanntes Beispiel
hierfür ist das Betriebssystem Solaris von Sun Microsystems (heute Oracle), welches aus dem
Quellcode von BSD-UNIX abgeleitet wurde.
Ein Zusatz der ursprünglichen Lizenz, nachdem auch Werbematerialien eines abgeleiteten
Programms mit einem bestimmten Copyright Vermerk versehen werden mussten, verhinderte
18
eine Kompatibilität mit der GPL, so dass eine aus einer BSD-lizensierten Software
abgeleiteten Software nicht der GPL unterstellt werden konnte. In der neuesten Version der
BSD-Lizenz („New BSD Licence“)(OSI, n.d. b) wurde auf diesen Zusatz verzichtet.
2.4.2.4
Public Domain
Im angloamerikanischen Rechtsraum werden Werke, die keinem Copyright unterstehen, als
Public Domain bezeichnet (Mundhenke, 2007, S. 46). Im Unterschied zum Copyleft hat der
Status des Public Domain keinerlei Auswirkungen auf abgeleitete Werke. Bei von Werken der
Public Domain abgeleiteten Werken ist es darum möglich, Lizenzbedingungen hinzuzufügen;
Nutzungsrechte zukünftiger Anwender könnten dadurch beschnitten werden (Taubert, 2006,
S. 26).
2.4.2.5
Mehrfachlizenzierung
Hochrestriktive Lizenzen machen es Unternehmen häufig schwer, Open Source Software zu
verwenden, oder sich an Open Source Software zu beteiligen. Ein Lizenzierungsmodell, das
eine Koexistenz proprietärer und Open Source Software ermöglicht, ist das Modell der
Mehrfachlizenzierung. Dabei wird ein Produkt sowohl unter einer Open Source Lizenz, als
auch einer proprietären Lizenz veröffentlicht.
Anwender können in diesem Fall wählen, unter welcher Lizenz sie ein Produkt beziehen
möchten. Für das proprietäre Produkt werden in der Regel Lizenzgebühren verlangt, es kann
aber – im Gegensatz zu dem unter der Open Source Lizenz stehenden – in ein kommerzielles
Softwareprojekt eingebunden oder durch proprietäre Zusätze ergänzt werden. Entscheidende
Voraussetzung für dieses Modell ist, dass das lizenzierende Unternehmen alleiniger
Rechteinhaber ist, wodurch es zu Konflikten mit der Open Source Community kommen kann.
Weiterentwicklungen, die in der Community entwickelt wurden, können nur dann auch in den
proprietären Teil des Projekts fließen, wenn der Entwickler seine Rechte an das Unternehmen
überträgt (vgl. Mundhenke, 2007, S. 131). Dabei besteht die Gefahr, dass sich das Projekt bei
fehlender Zusammenarbeit zwischen Unternehmen und Community, in zwei Teile aufspaltet.
Ein bekanntes Beispiel für eine Mehrfachlizenz ist die Datenbank MySQL6 der Firma Oracle
(urspr. MySQL AB), welche unter einer kommerziellen Lizenz und der GPL angeboten wird.
Beide Produkte beinhalten den gleichen Funktionsumfang. Die Entwicklung von MySQL
erfolgt stark zentral, werden Ergänzungen in das Projekt aufgenommen werden, die in der
Community erfolgten, so geschieht das nur über eine schriftliche Rechteübertragung an
Oracle („Oracle Contributor Aggreement“ (Oracle, n.d.)). Die Ergänzungen können dann
durch Oracle sowohl in der GPL als auch an der proprietären Version genutzt werden.
6 http://www.mysql.com/, letzter Aufruf: 17.12.2010
19
Der Eigentümer eines mehrfachlizenzierten Werks hat allerdings keinen Einfluss auf parallele
Entwicklungen, da er mit einer Lizenz wie der GPL jegliche Kontrolle über den Code
aufgegeben hat. Oracle kann zwar kontrollieren, wie sich ihr eigenes Projekt
weiterentwickelt, nicht aber, ob sich autonome Unterprojekte, sogenannte Forks, vom Projekt
abspalten (vgl. hierzu auch Abschnitt 2.5.1.2). Um eine Abspaltung zu verhindern muss sich
ein Unternehmen in dieser Situation immer auch im Sinne der Community verhalten, um die
gegenseitige Vertrauensbasis nicht zu verletzen.
2.4.3
Rolle der Lizenzen in der Open Source Software Entwicklung
Die aus dem Copyright bzw. dem Urheberrecht abgeleiteten Open Source Software Lizenzen
nehmen in der Welt der Free und Open Source Software eine zentrale Rolle ein. Für die Free
Software dient die GPL als rechtliches Instrument, um zu verhindern, dass einmal
freigegebenes Wissen in Zukunft wieder unfrei gemacht werden kann. Die Open Source Welt
bedient sich dieses Instruments, um die besondere Entwicklungsumgebung zu schaffen
(s. Abschnitt 2.5).
Der größte Teil der Entwickler in Open Source Projekten arbeitet freiwillig und unentgeltlich
(auf die Motivation der Entwickler wird in Abschnitt 2.5.2 eingegangen). Eine Copyleft
Lizenz garantiert, dass jeder über dass gesamte Wissen des Projekts verfügen kann, und dass
das Wissen, das ein Entwickler in das Projekt einfließen lässt, auch zukünftig frei bleibt
(s. Abschnitt 2.4.2.2). Durch eine Copyleft Lizenz wird jeder zu einem gleichberechtigten
Miteigentümer des Projektwissens – es wird zu einem öffentlichen Gut (vgl. hierzu Abschnitt
4.1.1). Würde im Gegensatz dazu das Wissen eines Projekts einer einzelnen Person oder eines
Unternehmens zustehen, würde der Anreiz sinken Zeit und Aufwand in ein Projekt zu
investieren, ohne einen entsprechenden Gegenleistung dafür zu erhalten.
Die Open Source Lizenz wirkt wie ein für alle Mitglieder der Community verbindlicher
Vertrag, der die Community zusammenhält und sie entstehen lässt.
Lerner und Tirole haben untersucht, wie sich verschiedene Ausprägungen von Lizenzen auf
ihre Projekte auswirken, und welche Lizenz unter den gegebenen Voraussetzungen bei der
Initialisierung eines Projekts die meiste Wirkung entfaltet. Maßgeblich sind hierbei die
Attraktivität eines Projekts (bezogen auf den Anreiz für Entwickler, sich an einem Projekt zu
beteiligen) und die zu erwartenden Gewinne und Verluste. Gewinne und Verluste können
sowohl materiell als auch immateriell sein (vgl. Lerner und Tirole, 2002, S. 16).
Anhand einer empirischen Studie über die auf der Webseite des Open Source Portals
20
SourcForge7 gelisteten Open Source Projekte, fanden Lerner und Tirole auch heraus, dass
Projekte mit hoher Attraktivität häufiger permissive Lizenzen verwenden (z.B. die BSDLicence). Projekte mit niedrigerer Attraktivität hingegen verwenden mit höherer
Wahrscheinlichkeit eine restriktive Lizenz. Projekte, die Produkte für Entwickler entwickeln
sind dabei in der Regel attraktiver, als Projekte, die Produkte für Endbenutzer entwickeln
(Lerner und Tirole, 2002, S. 2).
Permissive Lizenzen können aber eine Verschiebung der Motivations- und Anreizsituation der
Programmierer bewirken. Diesen Punkt werfen Tirole und Lerner in einer Untersuchung aus
dem Jahr 2000 auf (2000, S.42). Bestehe nämlich eine Koexistenz zwischen offener und
proprietärer Software, so könne sich ein Programmierer dazu ermutigt fühlen, seine Beiträge
zukünftig nicht mehr frei zu veröffentlichen, wenn er glaubte, ein Modul entwickelt zu haben,
welches auch hohen kommerziellen Profit abwerfen könnte.
2.5
Durchführung eines Open Source Projekts
Die Existenz, Verwendung und Verbreitung von Open Source Software beweist, dass Nutzer
komplexe Produkte erstellen, produzieren und verbreiten können. Sie unterstützen andere
Nutzer bei der Verwendung der Produkte und bieten nachträgliche Updates an, damit sich die
Produkte neuen Erfordernissen anpassen. Eric von Hippel nennt diese Nutzer „User
Innovation Communities“ (2006, S.14).
Wie die Koordination komplexer Projekte unter einer hierarchisch flach geregelten Struktur
ablaufen, wird im folgenden Abschnitt betrachtet.
2.5.1
2.5.1.1
Wie funktioniert ein Open Source Projekt
Entstehung
Ein Open Source Projekts beginnt mit seiner Initialisierung. Der Initiator kann im Prinzip jede
Person sein, die eine Idee verwirklicht, oder ein Problem lösen möchte. Eric S. Raymond
nennt in seinem Essay „The Cathedral and the Bazaar“ (Raymond, 2001) 19 Regeln, die in
einem erfolgreichen Open Source Projekt eingehalten werden müssen. Raymonds erste Regel
bezieht sich gleich auf den Beginn eines Projekts:
„I. Every good work of software starts by a developer's personal itch“
(Raymond, 2001, S. 23)
Raymond sieht eine Überlegenheit von Open Source Projekten gegenüber konventionellen
Projekten vor allem darin, dass ihre Entwickler durch ein persönliches Interesse geleitet
werden. Entwickler konventioneller Projekte lösen hingegen gegen Geld nur die Probleme
7 http://sourceforge.net/, letzter Aufruf: 17.12.2010
21
anderer (2001, S. 59 f.).
Der Initiator muss zu Beginn einen gewissen Teil an Vorarbeit leisten, um Aussenstehenden
den Zweck und das Ziel des Projekts zu signalisieren. Lerner und Tirole (2000, S. 29)
sprechen hier von einer „kritischen Masse“, die bereittstehen muss, damit die Community
reagiert. Dabei solle der Initiator aber nicht zu viele Aufgaben selbständig erledigen, denn
damit Mitarbeiter für ein Projekt gewonnen werden können, sollten noch genügend
„spannende“ Aufgaben bereitstehen, die übernommen werden können.
Nachdem ein Projekt die schwierige Anfangsphase bewältigt hat, hat sich im günstigen Fall
eine Gruppe von Personen um dieses Projekt gebildet, die sich an einer Weiterentwicklung
des Projekts beteiligen. Sie bilden dann die sog. Community. Auch wenn die Hierarchien in
Open Source Projekten oft sehr flach sind, gibt es immer eine Person, die die Leitung des
Projekts übernimmt. Diese Person wird als Maintainer bezeichnet (Sebald, 2008, S. 209).
In der Regel ist der Initiator eines Projekts zunächst auch der Maintainer. Seine Aufgabe ist
es, das Ziel eines Projektes vorzugeben und zu entscheiden, welche Beiträge in das Projekt
aufgenommen werden. Der Maintainer verfügt dadurch über eine gewisse Autorität. Er kann
Beiträge oder Vorschläge von Personen aus der Community ablehnen.
2.5.1.2
Forking
Der Maintainer besitzt in einem Open Source Projekt rein formal die Autorität, strukturelle
Entscheidungen treffen zu können. Sein Einfluss ist jedoch dadurch beschränkt, dass sich
jedes Mitglied der Community abspalten, und Maintainer eines eigenen Projekts werden kann.
Das Abspalten neuer Projekte wird als Forking bezeichnet (Grassmuck, 2002, S. 240) und ist
elementarer Bestandteil des Open Source Entwicklungsprozesses.
Forking kann sich sowohl negativ als auch positiv auf ein Open Source Projekt auswirken.
Orientieren sich die aufgespaltenen Projekte an einem gemeinsamen Kern und bleiben
dadurch zueinander kompatibel, bedeutet Forking durchaus eine Stärke. Die Forks würden in
diesem Fall das Einsatzspektrum des Kerns erweitern und die Anzahl möglicher Anwender
und die Größe der Community erhöhen.
Allerdings besteht auch die Gefahr, dass durch Forking aufgespaltete Projekte untereinander
zunehmend inkompatibel werden. Wissen, welches in einem Projekt entwickelt wird, kann
dann im anderen Projekt nicht verwendet werden. Es entsteht eine Spaltung der Community –
das Potential aller beteiligten Entwickler kann dann nicht mehr sinnvoll genutzt werden.
Der Maintainer eines Projekts wird versuchen, die Bildung möglicher Forks und das
22
Abwandern von Mitgliedern der Community zu verhindern. Ein guter Maintainer gestaltet die
Entscheidungsprozesse eines Projekts offen und transparent und versucht, alle Mitglieder der
Community aktiv einzubinden. Der Maintainer muss dann unter Umständen Entscheidungen
treffen, die nicht seinen eigenen Plänen entsprechen. Tut er das nicht, erhöht sich mit
wachsender Unzufriedenheit innerhalb der Community die Wahrscheinlichkeit für die
Entstehung eines erfolgreichen Forks (vgl. Lerner, Tirole, 2003, S. 31).
2.5.1.3
Trittbrettfahrerproblem
Der Quellcode eines Open Source Projekts ist ein Kollektivgut. Er ist nicht-rival und niemand
kann von einer Verwendung ausgeschlossen werden (vgl. hierzu Abschnitt 4.1.1).
Bei einem kollektiven Gut besteht die Gefahr, des Trittbrettfahrerproblems (engl. Free Rider
Problem). Es beschreibt das Verhalten von Individuen, die zwar ein Kollektivgut nutzen, weil
sie dadurch einen individuellen Gewinn erzielen können, aber nichts zum Kollektivgut
beitragen, wenn für sie dadurch individuelle Kosten entstehen (vgl. Braun, 1999, S. 106).
Im Bereich Open Source Software können Trittbrettfahrerprobleme auf zwei Ebenen
beobachtet werden: auf Ebene der Anwender und auf Ebene der Entwickler. In der Regel
werden Open Source Software Programme von deutlich mehr Personen genutzt, als
entwickelt8. Anwender profitieren von Open Source Software, indem sie ein Programm
kostenlos nutzen können. Zu einer Gegenleistung sind sie nicht verpflichtet.
Auf der Ebene der Entwickler findet sich das Trittbrettfahrerproblem in Situationen wieder, in
denen Entwickler vor der Entscheidung stehen, ein persönlich gewünschtes Modul selbst zu
entwickeln, oder darauf zu warten, dass diese Aufgabe durch einen anderen Entwickler der
Community übernommen wird.
Bei komplexen Projekten existieren immer Aufgaben, die sich durch eine für Entwickler hohe
Attraktivität auszeichnen, bspw. weil es sich um besonders interessante Aufgaben handelt
oder weil sich durch ihre Bearbeitung besonders hohes Prestige erzielen lässt. Für die Lösung
dieser Aufgaben werden sich mit hoher Wahrscheinlichkeit schnell mehrere Entwickler
zusammenfinden.
Bei weniger attraktiven Aufgaben besteht hingegen die Gefahr, dass sie unbearbeitet liegen
bleiben. Diese weniger attraktiven Aufgaben können dabei für den weiteren Fortlauf des
Projekts durchaus entscheidend sein. Da sich alle Entwickler freiwillig beteiligen, existiert
aber keine Autorität, die eine Bearbeitung anweisen kann.
8 Unter der Prämisse, dass Open Source Software mindestens von ihren Entwicklern genutzt werden. Jeder
weitere Nutzer würde dann dann das Auftreten des Trittbrettfahrerproblems bedeuten.
23
Jeder Entwickler wird mit einer individuellen Kosten-Nutzen-Analyse entscheiden, ob er ein
gewünschtes Modul selbst entwickelt oder abwartet. Mit ansteigender Größe der Community
wächst die Wahrscheinlichkeit, dass ein bestimmtes Modul durch einen anderen Entwickler
beigesteuert wird, der in ihm einen höheren Netto-Gewinn sieht. Gleichzeitig steigt mit der
Größe der Community aber auch der Anreiz zu warten. Ein Free-Riding scheint dann aus
Sicht der Mitglieder häufig als günstigere Alternative (vgl. Mundhenke, 2007, S.73).
Nach Mundhenke (2007, S.74) lohne sich ein Warten jedoch oft nicht, da aufgrund der
Heterogenität der Entwickler in einem Projekt die Wahrscheinlichkeit ziemlich gering sei,
dass durch einen anderen Entwickler ein individuell gewünschtes Feature beigesteuert werde.
Da das Warten für einen Entwickler bei langer Dauer unwirtschaftlich sein könne, entstehe
jedoch wiederum ein Anreiz, sich aktiv am Entwicklungsprozess zu beteiligen. Da keiner der
beteiligten Entwickler wisse, ob ein fehlendes Modul überhaupt durch eine andere Person
geliefert werde, bestehe auch die Gefahr, dass es gar nicht geliefert werde. Dieser Fall würde
für den Entwickler, sofern er das Modul nicht selbst beisteuert, einen Ausstieg aus dem
Projekt bedeuten.
Eine Untersuchung über die Motivation von Entwicklern in Open Source Projekten durch
Bitzer et. al. (2006) liefert eine spieltheoretische Betrachtung dieses Problems. Werde ein
Modul letztlich durch einen individuellen Entwickler geliefert so erweise sich für alle anderen
Mitglieder der Community das Warten als die beste Strategie. Für den liefernden Entwickler
wäre eine sofortige Entwicklung des Moduls hingegen die beste Strategie gewesen.
Bitzer et. al. stellten aber fest, dass eine Entwicklung von Modulen eher früher als später
stattfinde. Der Entwickler, der das Modul schließlich beisteuere, zeichne sich dadurch aus,
dass er das größte Verlustgefälle zwischen „jetzt programmieren“ und „aussteigen“ aufweise
(vgl. Bitzer et. al., 2006, S.166).
2.5.1.4
Zusammensetzung der Communities
Communities von Open Source Software Projekte bestehen im Durchschnitt aus 300-400
Mitgliedern, von denen sich aber nur ca. 20-30 Personen ständig aktiv an der
Entwicklungsarbeit beteiligen (sog. Contributoren) (vgl. Sebald, 2007, S.174).
Hierbei ist zu beachten, dass die Unterschiede in der Mitgliederzahl beträchtlich sein können.
Viele Projekte bestehen oft nur aus wenigen Entwicklern, wohingegen prominentere Projekte
weitaus größere Zahlen aufweisen können. Nach einer Untersuchung der Community des
Linux Kernels durch die Linux Foundation9 (2009) vom August 2009 waren an der
9 http://www.linuxfoundation.org/, letzter Aufruf: 17.12.2010
24
Entwicklung der Kernels der Version 2.6.30 über 1100 Personen beteiligt.
In dieser Untersuchung wird deutlich, dass sich die Entwickler unterschiedlich stark am
Projekt beteiligen. Die genannten 1100 Personen haben alle mindestens einen Beitrag geleistet
und zählen damit zu den Contributoren des Projekts. Ungefähr ein Drittel davon hat dabei
genau einen Beitrag geleistet. Die 10 aktivsten Contributoren leisteten insgesamt 12% aller
Beiträge, die 30 Aktivsten 25%.
Eine Untersuchung des Apache Projekts durch Mockus et. al. (2000, S. 5) kommt sogar noch
zu einer noch stärkeren Diskrepanz zwischen der Zahl der Mitglieder der Community und der
Anzahl der Personen, die sich tatsächlich am Entwicklungsprozess beteiligen. Demnach
steuerten die 15 wichtigsten Programmierer zwischen 83% und 91% aller geleisteter
Änderungen bei.
Bei dem weitaus größeren Teil der Community handelt es sich dann um sog. Lurker. So
werden Personen genannt, die zwar eingeschriebene Mitglieder eines Projekts sind, und die EMails der Mailinglisten erhalten, die sich aber an der Entwicklung und den Diskussionen
nicht beteiligen (Sebald, 2007, S. 131 ff.).
2.5.1.5
Kommunikation innerhalb der Community
Die Kommunikation zwischen den Mitgliedern der Community spielt eine entscheidende
Rolle in der Organisation von Open Source Projekten. Der dezentrale und kollaborative
Charakter der Projekte erfordert für den Wissenstransfer, dass die Kommunikationsmittel für
jeden verfügbar sind, und eine für jeden verständliche Sprache gewählt wird. Die Offenheit
von Open Source Projekten soll sich nicht nur auf das entwickelte Wissen erstrecken, sondern
schließt die Community mit ein. Aus der Offenheit folgt, dass jeder, der einen Beitrag leisten
kann, die Möglichkeit erhalten soll, diesen Beitrag in das Projekt einfließen zu lassen.
Das Internet bietet die Möglichkeit einer globalen Zusammenarbeit an gemeinsamen
Projekten. Viele Communities sind daher international zusammengesetzt. Ein Schwerpunkt
liegt hier auf Nordamerika und Europa (Red Hat, 2009). In den meisten Open Source
Projekten wird daher in englischer Sprache kommuniziert.
Abweichungen gibt es häufig nur in kleineren Projekten, die dann meist auf ein Land
beschränkt bleiben. Für diese Projekte bleibt dann die Möglichkeit, eine globale
Entwicklergemeinde nutzen zu können, ausgeschlossen.
Doch auch die englische Sprache kann eine Barriere bedeuten. Nichtenglischsprachige
Entwickler haben teilweise Schwierigkeiten, sich an Diskussionen innerhalb der Community
25
zu
beteiligen.
Ihre
eigenen
Interessen
finden
dabei
unter
Umständen
weniger
Berücksichtigung, weil sie sich weniger stark an den Entscheidungsprozessen beteiligen
können (vgl. Sebald, 2007, S. 125).
Mailinglisten werden als Kommunikationsmedium in fast allen Open Source Projekten
genutzt. Die Kommunikation über Mailinglisten erfolgt durch E-Mails und verläuft dadurch
asynchron. Das Senden und Empfangen von Nachrichten kann zeitlich getrennt liegen,
wodurch für eine Antwort ein größeres Zeitfenster zur Verfügung steht. Diese Eigenschaft ist
besonders bei globalen Entwicklergemeinden von Vorteil, da aufgrund der unterschiedlichen
Zeitzonen gemeinsame Arbeitszeiten schwer zu organisieren wären.
Neben Mailinglisten kommen Internet Relay Chats (IRC) zum Einsatz. Im Unterschied zu
Mailinglisten verläuft die Kommunikation hier nahezu synchron. Das Zeitfenster für eine
Antwort ist entsprechend klein, wodurch eine schnellere Kommunikation zwischen den
Teilnehmern möglich ist. Ein Problem kann unter Umständen so schneller gelöst werden. In
der Regel dient IRC neben Mailinglisten nur als unterstützendes Kommunikationsmittel.
Durch Mailinglisten können größere Gruppen angesprochen werden; IRC werden darum eher
für schnelle individuelle Besprechungen genutzt.
In den 1980er Jahren waren Newsgroups ein weit verbreitetes Mittel zur Kommunikation in
verteilten Entwicklergemeinschaften. Die wohl bekannteste Newsgroup ist Usenet (Unix User
Network). Newsgroups sind heutigen Internetforen sehr ähnlich, unterscheiden sich aber
darin, dass die News dezentral gesammelt werden. Nutzer von Newsgroups benötigten eine
Software (Newsreader), die veröffentlichte News sammelt und anzeigt.
Viele Open Source Projekte verfügen über Webseiten, in denen das Projekt vorgestellt wird.
Über diese Projektseiten erfolgt oft auch die Kontaktaufnahme zwischen Entwicklern und
Projekt. Ein Entwickler kann sich über die genutzten Kommunikationskanäle erkundigen und
sich gegebenenfalls für die bereitgestellten Mailinglisten anmelden.
Häufig werden Projektseiten in Form von Wikis geführt. Wikis sind eine spezielle Form von
Webseiten, deren Inhalte durch ihre Nutzer selbst erstellt werden (Beispiel: die Online
Enzyklopädie Wikipedia10). Wikis bieten den Vorteil, dass sie, genau wie auch der Quellcode
des Projekts, kollaborativ bearbeitet werden können. Projekt Wikis dienen oft auch der
Dokumentation der Projekte.
2.5.1.6
Produktion
Für die Entwicklung von Software innerhalb eines Open Source Software Projekts wird nur
10 http://www.wikipedia.org, letzter Aufruf: 17.12.2010
26
eine geringe Zahl an Werkzeugen benötigt.
Elementar sind hierbei der Computer und der Zugang zum Internet. Da es sich bei Software
um reinen Text handelt, reicht für das Schreiben eines Computerprogramms im Grunde
genommen ein einfacher Texteditor aus. Mit einem Compiler wird der Programmcode
ausführbar gemacht. Der menschenlesbare Text aus dem Texteditor wird dabei in eine für den
Prozessor verständliche Form überführt.
Zur Arbeitserleichterung stehen umfangreiche Entwicklungsumgebungen (IDE), wie bspw.
das Open Source Software Programm Eclipse11, zur Verfügung, die Editor und Compiler
vereinen und die dabei helfen, komplexe Projekte zu strukturieren. IDEs verfügen oft über
zusätzliche Werkzeuge, die das Programmiren und die Zusammenarbeit mit anderen
Entwicklern in einem Projekt erleichtern.
Das wohl wichtigste Werkzeug zur Organisation eines kollaborativen Projekts ist die
Versionsverwaltung. Hierbei wird ein Softwareprojekt zentral, im sogenannten Repository,
verwaltet. Werden Veränderungen am Quelltext oder an der Struktur des Projekts
vorgenommen, merkt sich das Programm den Verlauf der Veränderungen. Ein Entwickler
kann so immer auf ältere Versionen des Quelltextes zugreifen und verschieden Versionen
einer Datei miteinander vergleichen. Gängige Programme zur Versionsverwaltung sind CVS
(Concurrent Versions System) und Apache Subversion.
Die Versionsverwaltung spielt eine entscheidende Rolle in der Organisation einer verteilten
Zusammenarbeit der Entwickler in Open Source Projekten. Programme zur Versionsverwaltung nutzen üblicherweise eine Client-Server-Architektur, in dem das Repository als
zentraler Speicherort eines Projekts dient, der von dem Maintainer verwaltet wird. Hierbei
gibt es aber auch Unterschiede. Die durch Linus Torvalds entwickelte Versionsverwaltungssoftware GIT verfügt über eine dezentrale Struktur. Anstelle eines zentralen Repositories
verfügt jeder Nutzer über das komplette Repository, das lokal auf seinem Computer
gespeichert ist.
Um die Funktionsweise der Versionsverwaltung besser erklären zu können, wird hier aber nur
auf die zentrale Versionsverwaltung eingegangen. Will sich ein Entwickler an einem Projekt
beteiligen, greift er mit dem Client auf das Repository zu und lädt die aktuelle Version des
Projekts auf seinen Computer herunter. Änderungen und Weiterentwicklungen nimmt der
Entwickler zunächst an seiner lokalen Kopie vor. Möchte er einen eigenen Beitrag zum
Repository beisteuern, fertigt er einen Patch an. Der Patch wird durch die Versionsverwaltung
11 http://www.eclipse.org/, letzter Aufruf: 17.12.2010
27
erstellt, die den durch den Entwickler veränderten Code mit dem Ausgangscode vergleicht.
Das Programm registriert, welche Codeteile entfernt und welche hinzugefügt werden müssen,
damit das Repository auf den Stand des Entwicklers gebracht werden kann. Der Maintainer
erhält mit dem Patch schließlich nur eine Datei, die die zu tätigen Veränderungen enthält, Mit
Hilfe der Versionsverwaltung kann der Maintainer die Änderungen automatisch in das
Repository einpflegen.
Bei größeren Projekten ist es nicht unüblich, dass mehrere Entwickler gleichzeitig einen
bestimmten Teil des Projektcodes bearbeiten. Es besteht die Gefahr das dabei Konflikte durch
inkompatible Codefragmente entstehen. Sollte der Code im Repository beim Erstellen des
Patches durch einen Entwickler bereits durch einen anderen Entwickler verändert worden
sein, fordert die Versionskontrolle den Entwickler auf, die Veränderungen in seinem Code zu
berücksichtigen.
2.5.1.7
Distribution
Die im vorigen Abschnitt angesprochen Werkzeuge zur Versionsverwaltung dienen auch zur
Distribution des Quellcodes eines Open Source Software Programms, schließlich sind über
das Repository alle Versionen des Projekts abrufbar. Verfügt ein Anwender über den
entsprechenden Client der Versionsverwaltung, kann der Quellcode der gewünschten Version
auf einen Computer geladen werden. Um das Programm nutzen zu können, muss es vorher
aus dem Quellcode kompiliert werden, um es für den Prozessor ausführbar zu machen.
Alternativ wird der Quellcode des Projekts oft auch per ftp (File Transfer Protocol) angeboten.
Auch hierfür wird ein Client benötigt, der heute bereits in vielen Webbrowsern integriert ist.
In der Regel werden neben dem Quellcode auch bereits kompilierte Versionen des Programms
angeboten. Viele Projekte bieten auch auf ihren Projekt Webseiten ihr Produkt zum Download
an (http).
Eine besondere Rolle nimmt SourceForge12 ein. SourceForge ist sowohl eine Webseite, als
auch eine Software zur Verwaltung von Open Source Projekten. Ähnlich einem Webhoster,
der Dienste für den Betrieb von Webseiten vermietet, können über Sourceforge Dienste zur
Verwaltung von Open Source Software Projekten gemietet werden.
Laut eigenen Angaben werden auf SourceForge 260000 Projekte verwaltet, an denen sich
insgesamt 2,7 Millionen Entwickler beteiligen (Sourceforge, n.d.). Sourceforge richtet sich
einerseits an Entwickler, die ein neues Projekt initiieren möchten, oder sich an einem Projekt
beteiligen möchten. Andererseits bietet Sourceforge den Projekten aber auch eine
12 http://sourceforge.net/, letzter Aufruf: 17.12.2010
28
Distributionsplattform. Personen, die Open Source Software nutzen möchten, können hier
komfortabel, bspw. abhängig von Betriebssystem und Anwendungsgebiet, nach Software
suchen und sie herunterladen. Anwender können, ähnlich wie auf anderen Distributionsplattformen, die von ihnen genutzten Programme bewerten.
2.5.1.8
Modularisierung
Ein wichtiger Faktor, der den Erfolg von Open Source Projekten beeinflussen kann, ist ihre
Fähigkeit zur Modularisierung. In der Softwareentwicklung bezeichnet dies die Möglichkeit,
verschiedene Teile eines Programms durch unterschiedliche Teams bearbeiten zu lassen
(Pomberger, Pree, 2004, S. 131). Modularität vereinfacht dadurch die Organisation komplexer
Entwicklungsprojekte.
Lerner und Tirole (2000, S. 37) machen die anfänglich wenig modulare Struktur des Mozilla
Projekts nach der Veröffentlichung des Sourcecodes dafür verantwortlich, dass sich zu Beginn
nur wenige Programmierer an einer Weiterentwicklung beteiligten. Erst die Umstrukturierung
des gesamten Codes durch Netscape ermöglichte es Open Source Software Entwicklern,
Beiträge auch nur zu individuellen Teilen der Software beizusteuern.
Benkler (2007, S.69) beschreibt das Potential der Modularität anschaulich durch das NASA
ClickWorker Projekt. Komplexe Aufgaben, hier die Identifizierung Kratern auf der
Marsoberfläche, wurden in kleine Teilaufgaben unterteilt. Diese Teilaufgaben konnten nun
anstelle von ausgebildeten Wissenschaftlern auch von Amateuren übernommen werden. Das
Lösen der Teilaufgaben konnte von Amateuren innerhalb weniger Minuten vorgenommen
werden.
Auch am Wikipedia Projekt wird das Prinzip der Modularität deutlich. Kein Entwickler muss
sich mit der gesamten Enzyklopädie beschäftigen, sondern nur mit dem Teil, für den er sich
interessiert. Er kann bspw. einen Artikel, einen Absatz eines Artikels oder die Korrektur eines
Rechtschreibfehlers beisteuern. In jedem Fall kann er durch seinen Beitrag das Gesamtwerk
fortentwickeln.
Benkler (2007, S.101) bezeichnet den Grad der Modularität als Granularität, wobei mit
steigender Granularität
die Größe der Module sinke. Ihre Größe beeinflusse Zeit und
Aufwand, die ein Entwickler aufwenden müsse, um eine Aufgabe zu erledigen. Der Grad der
Granularität könne daher auf die Anzahl möglicher Teilnehmer, die sich an einem Projekt
beteiligen, Einfluss ausüben. Sind die Module zu groß, steige die Eintrittsschwelle für neue
Entwickler. Sie müssen mehr Zeit und Aufwand aufwenden, und häufig auch über mehr
Vorwissen verfügen, um sich an einem Projekt beteiligen zu können.
29
2.5.2
Motivation
Benkler (2007, S. 60) beschreibt Open Source als ein Arbeits- und Organisationsmodel, in
dem lose kooperierende Individuen ein Netzwerk bilden, wobei in einer Form kollektiven
Handelns Gemeingüter, also Güter, von deren Verwendung niemand ausgeschlossen werden
kann, entstehen. Dieses Netzwerk sei nicht auf Marktsignale oder geschäftsführende
Anweisungen angewiesen.
Die Wirtschaftswissenschaften waren in der Vergangenheit stets davon überzeugt, dass
Gemeingüter unterentwickelt bleiben müssten, weil niemand individuelle Kosten in etwas
investieren würde, ohne nicht auch eine entsprechende Gegenleistung dafür zu erhalten.
Garret Hardin (1968) verwendet hierfür den Begriff „Tragedy of the Commons“.
Das
Beispiel
der
Open
Source
Software
Entwicklung,
und
insbesondere
ihrer
hervorstechenden Projekte, wie das des Linux Kernels oder des Apache Webservers, zeigt
aber, dass diese losen Netzwerke aus freiwilligen und sich unentgeltlich beteiligenden
Entwicklern langfristig Bestand haben. Sie ermöglichen dabei sogar eine kontinuierliche
Entwicklung eines Produkts. Der Webbrowser Firefox13 oder der E-Mail Client Thunderbird14
der Mozilla Foundation sind Beispiele dafür, dass in Open Source Projekten Produkte mit
hohem Innovationspotential entstehen können, die konkurrierenden kommerziellen Produkten
in ihrer Qualität mindestens ebenbürtig sind.
Die Frage, warum sich gut ausgebildete Personen ohne eine direkte Gegenleistung mit viel
Engagement und hohem zeitlichen Aufwand an Open Source Projekten beteiligen, war
häufiger Bestandteil wissenschaftlicher Untersuchungen der letzten Jahre. Diese Frage nach
der
Motivation
der
Entwickler
wurde
dabei
gleichermaßen
von
Personen
aus
sozialwissenschaftlichen wie wirtschaftswissenschaftlichen Bereichen gestellt.
Bevor einige Erklärungsmodelle in diesem Abschnitt erläutert werden, werden die an Open
Source Projekten beteiligten „Personen“ klassifiziert. Folgend Parameter dienen der
Unterscheidung:
•
Handelt es sich um den Initiator eines Projekts, oder einen regulären Teilnehmer?
•
Ist der Teilnehmer eine individuelle Person oder ein Unternehmen?
Hieraus ergeben sich folgende vier Gruppen:
1. Der individuelle Entwickler, der sich an einem Open Source Projekt beteiligt
13 http://www.mozilla.org/firefox/, letzter Aufruf: 17.12.2010
14 http://www.mozillamessaging.com/de/, letzter Aufruf: 17.12.2010
30
2. Der Initiator – ein individueller Entwickler, der entscheidet, ob er sein Projekt
zukünftig proprietär oder open source entwickelt
3. Ein Unternehmen, das sich an Open Source Projekten beteiligt
4. Ein Unternehmen, das entscheidet, ein Produkt zukünftig open source zu entwickeln
Im Folgenden werden die Motive für eine Engagement der ersten beiden Gruppen dargelegt.
Effekte, die auch ein Unternehmen zu einem Engagement in Open Source Projekten anregen
könnten, werden in Abschnitt 4.3 behandelt.
2.5.2.1
Motivation der Entwickler
Ein einfaches Erklärungsmodel für das Phänomen Open Source ist das des altruistischen
Hackers. Open Source Softwareentwicklung verhält sich dabei wie Art Geschenkkultur („gift
culture“ (Raymond, 2001, S. 116)), in der der Programmierer frei von monetären Zwängen
und ökonomischen Regeln seine Arbeit einem großen Ganzen beisteuert.
Viel Beachtung fand die Veröffentlichung „Some Simple Economics of Open Source“ von
Lerner und Tirole (2000). Mit ihrer Untersuchung wollten Lerner und Tirole zeigen, dass auch
das Engagement der Open Source Entwickler durchaus von einen erwarteten persönlichen
Nettogewinn beeinflusst werde. Ein Entwickler beteilige sich unter Einsatz seiner Zeit und
seines Wissens nämlich nur dann an einem Projekt, wenn er für seinen Aufwand eine
Gegenleistung erhalte. Gegenleistungen könnten dabei sofort, aber auch verspätet erfolgen.
Bei einer Beteiligung an Open Source Projekten erfolgt die Gegenleistung in der Regel
verzögert. Die Gewinne, die durch Lerner und Tirole identifiziert wurden, sprechen zwei
Anreize der Entwickler an – den Karriereanreiz („career concern incentive“) und den
Reputation Anreiz („ego gratification incentive“). Beide Anreize sind „signaling incentives“.
Entwickler erzeugen durch ihre Arbeit an Open Source Projekten eine signalisierende
Wirkung auf Dritte, und demonstrieren dadurch ihre Leistung und Talent. Die erhofften
Gewinne resultieren schließlich in besseren Job-Angeboten und höherer Anerkennung in der
Open Source Community (vgl. Lerner und Trirole, 2000, S. 20 ff.).
Open Source Projekte sind aufgrund ihres frei verfügbaren Codes für jeden transparent.
Innerhalb des Projekts ist daher ersichtlich, welcher Entwickler welchen Beitrag geleistet hat.
Den Entwicklern bietet sich daher die Möglichkeit, mit ihrer Arbeit potentiellen Arbeitgebern
ihre Fähigkeiten zu demonstrieren und zu offerieren.
Die Signalisierung von Fähigkeiten innerhalb der Community wird umgangssprachlich als
Egoboo bezeichnet. Dieser Begriff leitet sich aus dem Ausdruck „ego boost“ ab, und entstand
31
ursprünglich in der Science Fiction Szene der 1950er Jahre. Üblicherweise fand ein Name in
einem Fanzine (Fan-Magazin) dann Erwähnung, wenn eine Person etwas Positives zur
Gemeinschaft beigetragen hatte (vgl. Raymond, 2001, S. 53).
In Open Source Communities wird der Begriff äquivalent gebraucht. Der Egoboost ist größer,
je wichtiger der Beitrag zur Gemeinschaft war, und je renommierter das Projekt ist.
Lerner und Tirole vergleichen hier die Open Source Softwareentwicklung mit dem
Wissenschaftsbetrieb (2000, S. 22). Auch hier käme es bei der Veröffentlichung von
Forschungsergebnissen zur signalisierenden Wirkung. Die Veröffentlichung in einer
renommierten
und
weit
verbreiteten
Fachpublikation
stärke
die
Reputation
des
Wissenschaftlers innerhalb seiner Disziplin. Zugleich erhöhe eine bessere Reputation die
Chancen auf einen attraktiven Forschungsauftrag.
Dass Lerner und Tirole das Engagement der Entwickler allein auf ihre signalisierende
Wirkung, und dadurch auf extrinsische Motive beschränken, wurde von verschiedenen
Publikationen kritisiert (Bitzer et. al. (2007), Mundhenke (2007), Taubert (2006)). Aus ihrer
Sicht liessen sie die viel wichtigere Rolle intrinsischer Motive zu sehr ausser Acht.
Die intrinsische Motivation beschreibt den Antrieb einer Person, eine Tätigkeit nur um ihrer
selbst willen zu tun (vgl. Deci, Ryan, 1985, S. 5). Extrinsische Motive liegen vor bei externen
Belohnungen, aber auch der Abwendung eines Übels. Die im obigen Beispiel genannte
Aussicht auf einen attraktiven Forschungsauftrag oder eine bessere Reputation sind somit
extrinsische Motive.
Die Kritik ist durchaus berechtigt, weil das Model Lerners und Tirols nicht ausreichend
erklärt, warum sich Programmierer auch an unbekannten Projekten beteiligen. Auf
Sourceforge sind mehr als 260000 Projekte gelistet, von denen nur ein Bruchteil so bekannt
ist, als dass eine Beteiligung an ihnen eine signalisierende Wirkung entfalten könnte
(vgl. auch Bitzer et. al. 2006, S.3).
Bitzer et. al. rücken darum intrinsische Faktoren in den Mittelpunkt und identifizieren drei
elementare Motivationen: (a) den eigenen Bedarf an einer bestimmten Software, (b) die
Freude am Spielen („Homo Ludens“) und (c) die Freude am Schenken („gift culture“ –
Schenkökonomie). Die ersten beiden Faktoren treffen auch auf Entwickler zu, die ihr Produkt
nicht Open Source entwickeln lassen möchten, weshalb dem dritten Faktor laut Bitzer et. al.
die entscheidende Rolle zukommen müsse (zu den Motiven der Initiatoren eines Open Source
Projekts vgl. Abschnitt 2.5.2.2).
32
Für einen Entwickler, der sich an einem fremden Projekt beteiligt, stellt sich die Frage, ob er
einen Beitrag veröffentlichen soll gar nicht, sondern nur, ob er sich überhaupt an einem Open
Source Projekt beteiligt. Damit akzeptiert er auch dessen Regeln. Ein Programmierer würde
in jedem Fall programmieren, von daher sind die zu leistenden Kosten, die er mit der
Beteiligung an einem Open Source Projekt erbringen müsste, ziemlich gering. Bestehende
Open Source Projekte bieten dann auch noch eine Gelegenheiten, bei denen er „mitspielen“
kann. Handelt es sich dabei auch noch um ein Programm, auf das er angewiesen ist, erfüllt
seine Arbeit auch noch einen praktischen Nutzen.
In einer Untersuchung durch Lakhani und Wolf (2002, S.14) gaben eine Vielzahl der
Entwickler von Open Source Software an, ihr Engagement auch als intellektuelle Anregung
und zur Verbesserung der eigenen Fähigkeiten zu nutzen. Das deckt sich wiederum mit dem
durch Bitzer et. al. in Zusammenhag gebrachten Begriff des Homo Ludens (Bitzer et. al.,
2007, S.161), wonach der Mensch insbesondere im Spiel seine Fähigkeiten erlerne.
Der Begriff der Schenkökonomie stammt aus den Sozialwissenschaften und wurde schon
häufiger mit dem Begriff Open Source in Zusammenhang gebracht (Rheingold, 2000;
Raymond, 2001). Die Schenkökonomie bezeichnet ein soziales System, in dem Güter und
Dienstleistungen weitergegeben werden, ohne dass eine direkte Gegenleistung dafür verlangt
wird (Adloff, Mau, 2005, S. 130). Meist handelt es sich dabei um eine Form des reziproken
Altruismus (Adloff, Mau, 2005, S. 35); auch wenn zunächst keine Gegenleistung erkennbar
ist, wird sich der Beschenkte in der Regel zu einem späteren Zeitpunkt nach dem Prinzip der
Solidarität für ein erhaltenes Geschenk erkenntlich zeigen.
Das Prinzip des reziproken Altruismus und der allgemeinen Solidarität ist dabei durchaus auf
Open Source Communities übertragbar. Ein Entwickler leistet auch deshalb einen Beitrag zu
einem Projekt, und nimmt dadurch eigene Aufwände in Kauf, weil er erwarten kann, dass
andere Entwickler ebenfalls Beiträge leisten werden, aus denen er dann persönlichen Nutzen
ziehen könnte. Mundhenke (2007, S.72) interpretiert das gegenseitige Vertrauen der Akteure
als „dauerhafte Lösung des Gefangenendilemmas“.
Die Motivation der Entwickler kann deshalb aus einer Kombination aus intrinsischen und
extrinsischen Motiven beschrieben werden. Eine Person betätigt sich als Entwickler, weil sie
Erfüllung an dieser Tätigkeit empfindet. Und sie beteiligt sich auch deshalb an Open Source
Projekten, weil sie einen persönlichen Nutzen daraus ziehen kann.
Interessant ist hierbei noch die Erkenntnis der Untersuchung Lakhanis und Wolfs (2002,
S.19), wonach sich ein überwiegender Teil (83%) der Open Source Software Community
33
stark oder zum Teil mit der sog. Hackerethik identifiziert.
Hieraus kann geschlossen werden, dass sich die Verinnerlichung derer Ideale unmittelbar
darauf auswirkt, wie ein Entwickler seine Arbeit, und damit verbundene Kosten und Nutzen,
bewertet. Ein Engagement für ein Open Source Projekt erfolgt dann vermutlich eher, als es
bei einer Ablehnung der sog. Hackerethik der Fall wäre.
2.5.2.2
Motivation der Initiatoren
Anders, als der individuelle Entwickler, steht der Initiator eines Projekts vor der
Entscheidung, ob er sein Projekt zukünftig exklusiv oder Open Source entwickeln soll. Mit
der Initiierung eines Open Source Projekts verliert er die Möglichkeit einer exklusiven
Nutzung seines Wissens. Die Möglichkeit der Forks könnte ausserdem dazu führen, dass er
seine bislang führende Rolle innerhalb des Projekt an fremde Entwickler verliert.
Die Entscheidung, eine Innovation zukünftig Open Source zu entwickeln ist also für den
Initiator zunächst mit hohen Aufwänden verbunden. Er verzichtet auf größtmögliche
zukünftige Gewinne und riskiert den Verlust der alleinigen Kontrolle über das Projekt. Im
Gegenzug gewinnt der Initiator die Vorzüge eines Open Source Projekts: eine globale
Gemeinschaft an freiwilligen Entwicklern, die sich, wenn sich sich für das Projekt
interessieren, an einer Weiterentwicklung des Projekts beteiligen werden.
Mundhenke (2007, S.74) führt eine Untersuchung Andrew Watermans 15 aus dem Jahr 2003
an, in der Waterman die Entscheidungsfindung anhand eines einfachen Kosten-NutzenVergleichs untersucht. Demnach entstehen in einem proprietären Projekt Kosten für
Produktion und Distribution; auf der Nutzenseite sieht Waterman den unmittelbar privaten
Nutzen durch das Produkt, sowie die möglichen Erlöse durch seinen Verkauf.
Die Wahrscheinlichkeit, ein Projekt Open Source zu entwickeln steige mit der Anzahl
möglicher Mitentwickler und einem dadurch entstehenden Reputationsgewinn. Zudem steige
die Wahrscheinlichkeit je geringer die erwartbare Nachfrage bzw. der erzielbare Marktwert
des Produkts wäre. Bei einem hohen erwartbaren Marktpreis und einer nur geringen Anzahl
möglicher Mitentwickler sinke hingegen die Wahrscheinlichkeit, dass eine Innovation Open
Source entwickelt würde.
Von Hippel (2006, S.10) zeigt, dass gerade individuelle Entwickler von einer kommerziellen
Verwertung ihrer Innovation kaum profitieren können. Auch von Hippel führt hier
Transaktions- und Distributionskosten an die zunächst der Initiator tragen müsse, wenn er ein
Projekt proprietär entwickeln würde. Eine freie Veröffentlichung der Innovation, bzw. die
15Waterman A. 2003. Motivations to Develop Software as Open Source, SIEPR, Stanford University
34
Nutzung einer Open Source Lizenz, ist daher meist die einzig praktische Möglichkeit.
Zusätzlich kann er dann von den positiven Effekten einer freien Veröffentlichung profitieren.
Taubert (2006, S.142) nennt auch eine fehlende Handlungsalternative. Die Möglichkeit einer
proprietären Entwicklung stehe für eine Vielzahl von Software Projekten praktisch gar nicht
zur Verfügung. Demnach werden manche Softwareentwickler vor die Entscheidung gestellt,
entweder freie Software zu veröffentlichen, oder eben gar keine Software mehr zu entwickeln.
Die oben genannten Modelle bieten eine theoretische Erklärung. In der Praxis wird sich ein
Initiator aber immer nur dann für eine zukünftige Open Source Entwicklung seines Projekts
entscheiden können, wenn ihm die Open Source Prinzipien geläufig sind. Eine Vielzahl von
Initiatoren von Open Source Projekten werden ihre Entscheidung vermutlich auch getroffen
haben, ohne sie vorher einer Kosten-Nutzen-Analyse unterzogen zu haben. Die Entscheidung
basierte allein aus dem Vorzug der Methode Open Source gegenüber der proprietären
Entwicklung. Beispielhaft sei hier Richard Stallman mit seinem GNU Projekt genannt.
35
3 Open Hardware
3.1
Open Hardware als Äquivalent zur Open Source Software
Der Begriff Open Hardware ist noch sehr jung, und entstand als Äquivalent zum Begriff
Open Source Software aus individuellen Projekten oder Initiativen heraus. Wann der Begriff
zum ersten Mal verwendet wurde, ist schwer ermitteln. Genauso wie im Bereich der Free und
Open Source Source Software, gibt es auch für diesen Begriff verschiedene Benennungen. So
wird z.B. auch von Open Source Hardware (Freedomdefined.org., n.d.) oder Free Hardware
(Stallman, 1999) gesprochen.
Der Begriff Open Hardware soll dabei die Übertragung der Prinzipien der Open Source
Hardware auf materielle Güter bezeichnen. Inwieweit
der Begriff Open Hardware als
Äquivalent zum Begriff Open Source Software verwendet werden kann, wird in den
folgenden Abschnitten geklärt.
In den vorangegangenen Kapiteln wurde der Begriff Open Source Software erläutert, wobei
auf die Entstehung des Begriffs, den Zusammenhang mit speziellen Open Source Lizenzen
und die Durchführung von Open Source Projekten eingegangen wurde.
In diesem Kapitel wird untersucht, inwiefern die aus den Prinzipien Open Source Software
gewonnenen Erkenntnisse auf eine Anwendbarkeit auf Nicht-Software, und im Speziellen auf
materielle Güter, genutzt werden können. Des weiteren werden Projekte vorgestellt, die das
Prinzip Open Source bereits auf materielle Güter anwenden.
3.1.1
Quellcode
Elementares Prinzip der Open Source Software ist die öffentliche Zugänglichkeit des
Quellcodes eines Projekts.
Die OSI schreibt in ihrer Open Source Definition vor, dass der Quellcode in einer Form
vorliegen muss, die von einem Entwickler üblicherweise bearbeitet wird:
„[…]. The source code must be the preferred form in which a programmer would modify
the program.[…]“ (OSI, n.d.)
Der Unterschied zwischen Software- und Hardwareprojekten besteht vor allem darin, dass für
Hardware keine einheitliche Beschreibungsform existiert. Unterschiedliche Formen von
Hardware werden meist auch durch unterschiedliche Formen beschrieben. Die Beschreibung
einer Software erfolgt hingegen immer durch Text.
Im günstigsten Fall handelt es sich bei dem Quellcode einer Hardware ebenfalls um Text, die
36
wie ein Stück Software mit einer gängigen Versionsverwaltung oder innerhalb eines Wikis
gepflegt werden kann. Mit zunehmender Komplexität der Hardware reicht ein Text jedoch
kaum aus, so dass aufwendige Baupläne erforderlich sind. Die zunehmende Verwendung von
Computern in den Entwicklungs- und Produktionsprozessen materieller Güter können dabei
aber zu einer Veränderung des Aggregatzustandes Hardware beitragen. Durch digital
Prototyping wird die Entwicklung physischer Güter der Softwareentwicklung nämlich
zunehmend ähnlicher.
"In a sense, hardware is becoming much more like software, up to the point where you
actually fabricate an object, …" (v. Hippel zitiert in Anderson, 2010, S. 64)
Der gesamte Entwicklungsprozess eines Gutes, vom konzeptionellen Design über die
technischen Realisierung bis hin zur Erstellung eines Prototyps kann dabei durch CAD
Programme
(Computer
Aided
Design)
vollständig
am
Computer
erfolgen.
Die
Zusammenarbeit der am Entstehungsprozess beteiligten Disziplinen wird dadurch vereinfacht,
dass in jedem Arbeitsschritt auf die gleichen Datensätze zurückgegriffen werden kann.
Und auch der Herstellungsprozess kann zunehmend automatisiert werden. Mit der
Verwendung von Austauschformaten können aus einem digitalen Prototypen die Maschinen
zur Herstellung einer physischen Instanz gesteuert werden (CAM – Computer Aided
Manufacturing).
Dadurch, dass Hardware von der Entstehung bis zur Herstellung allein als digitale
Beschreibung vorliegen kann, wird Hardware zu Software. Erst ihre Instanzen werden
materielle Güter sein, vorher ist sie Information, die digital abgebildet werden kann.
Wichtigste Säule der Open Source Software Entwicklung ist die uneingeschränkte
Verfügbarkeit des Source Code. Um diese Eigenschaft auf Open Hardware Projekte zu
übertragen, ist es auch erforderlich, dass ihr Quellcode in Formaten vorliegt, die von jedem
verwendet werden können. Die Verwendung standardisierter Formate verhindert dann, dass
potentielle Entwickler von einer Partizipation ausgeschlossen werden.
Somit umfasst der Quellcode einer Hardware alle Informationen, die zu ihrer Herstellung
erforderlich sind.
Diese Informationen müssen in digitaler Form vorliegen, damit sie kostengünstig und
verlustfrei vervielfältigt werden können. Zudem müssen sie ein Format besitzen, das durch
jeden weiterverarbeitet werden kann. Erfüllt der Quellcode einer Hardware diese
Voraussetzungen, ist er für eine kollaborative Entwicklungsarbeit geeignet und erfüllt die
37
Maßstäbe der Open Source Software Definition.
3.1.2
Anwendung
Das elementare Prinzip der Methode Open Source ist der freie Informationsaustausch. Er
bedingt den offenen Innovationsprozess.
Der Ursprung der Open Source Software liegt, wie in Abschnitt 2.1.3 aufgezeigt, in der
Hacker Kultur der 1960er und 1970er Jahre, in der, auch mangels Schutzrechte, der Quellcode
von Computerprogrammen offen untereinander ausgetauscht wurde.
Überraschenderweise findet eine Adaption dieser Prinzipien auf Hardware bereits statt, und
zwar in der Do-It-Yourself (DIY) Bewegung der letzten Jahre. Hier entstehen, meist auf
Initiative von Einzelpersonen, technische und handwerkliche Produkte. Über private Blogs
oder DIY Plattformen16 werden Bauanleitungen verschiedener Produkte (Quellcode der
Hardware) weitergegeben. Das hier veröffentlichte Wissen fliesst dann wiederum in neue
Produkte oder Weiterentwicklungen ein. Internet Plattformen wie Etsy17 oder Dawanda18
bieten sogar Distributionsplattformen an, auf denen Produkte dieser Zusammenarbeit verkauft
werden können.
Die DIY Bewegung der letzten Jahre, die sich von früheren DIY Bewegungen darin
unterscheidet, dass die Community Mitglieder untereinander austauschen, wohingegen
damals die Weitergabe von bspw. Bauanleitungen kommerziell oder innerhalb der Familie
erfolgte, spiegelt in einer gewissen Weise das, was die Hacker Kultur für die Open Source
Software war, wider. Insbesondere zeichnet sie sich durch eine eher spontane
Organisationsstruktur aus, die die ihr bereitstehenden technischen Möglichkeiten nutzt, um
Innovation zu schaffen und zu verbreiten.
Genau wie der Hacker Kultur damals, fehlt der DIY Bewegung heute eine formale Struktur
und ein artikuliertes Ziel. Für die Open Source Software wurde fand diese Formalisierung
zuerst mit der Entstehung des Begriffs der Free und später der Open Source Software statt.
Für Open Hardware findet dieser Formalisierungsprozess gerade statt.
3.1.3
Besonderheit bei der Hardware im Hinblick auf ihr Endprodukt
Software ist ein immaterielles digitales Gut (siehe Abschnitt 2.2.). Diese Eigenschaft trifft
sowohl auf den Quellcode einer Software, als auch auf das letztliche Produkt, das ausführbare
Computerprogramm, zu.
16 http://makezine.com/, letzter Aufruf: 17.12.2010
17 http://www.etsy.com/, letzter Aufruf: 17.12.2010
18 http://de.dawanda.com/, letzter Aufruf: 17.12.2010
38
Im Unterschied dazu wird in einem Open Hardware Projekt aus dem Quellcode (bspw.
Bauanleitung) ein materielles Gut entwickelt. Die Eigenschaften der verlustfreien
Reproduzierbarkeit und der Nicht-Rivalität bei Open Source Software treffen bei der
Hardware nur auf den Quellcode des Projekts zu, nicht aber auf das resultierende Produkt.
Das Produkt eines Open Hardware Projekts kann wie ein konventionelles Gut verkauft
werden.
Die Produktion eines Open Hardware Projekts ist im Unterschied zur Open Source Software
Produkten nicht trivial, sondern mit hohem Aufwand verbunden, da hier Rohstoffe und
physische Werkprozesse zum Einsatz kommen müssen. Der Grad des Aufwandes richtet sich
dabei nach der Komplexität des Produkts. Meist kann ein Open Hardware Produkt nur unter
industriellen Bedingungen hergestellt werden.
Der Preis eines Open Hardware Produkts wird sich wie der einer Open Source Software den
Grenzkosten seiner Herstellung angleichen. Die Grenzkosten des immateriellen Gutes
Software sind, wie im Abschnitt 2.2 dargelegt, annähernd Null. Die Grenzkosten eines
Hardware Produkts liegen wegen des Aufwandes seiner Produktion und der verwendeten
Rohstoffe immer über Null. Ein Open Hardware Produkt wird folglich zu einem positiven
Preis auf dem Markt angeboten werden müssen, um die Produktionskosten zu erwirtschaften.
Die Produktion eines Open Hardware Produkts kann von jedem übernommen werden, der
über die nötigen Produktionsmittel verfügt, wobei das Produktionsmittel Wissen in Form des
Quellcodes des Projekts für jeden frei verfügbar ist.
3.1.4
Lizenzen
Die Anzahl bereits bestehender Open Hardware Lizenzen für den Quellcode lässt sich nicht
ermitteln. Ein zentrales Verzeichnis für derartige Lizenzen besteht nicht, so dass jede Person
oder jedes Projekt eigene Bedingungen in einer Lizenz festlegen kann.
Die einzige speziell für Hardware ausgelegte Open Source Lizenz, die mittlerweile einen
gewissen Bekanntheitsgrad erreicht hat, ist die TAPR Open Hardware Licence des Tucson
Amateur Packet Radio Projekt (vgl. TAPR, 2007). Neben einer Anwendung in diesem Projekt
findet sie mindestens auch noch im Open Graphics Project19 Verwendung. Seit 2007 liegt die
TAPR Open Hardware Licence in der Version 1.0 vor.
Eine geeignete Alternative stellen die Lizenzen der Organisation Creative Commons20 dar, die
eine Reihe von Lizenzen entwickelt hat, die auf beliebige digitale Dokumente angewendet
19 http://wiki.opengraphics.org/, letzter Aufruf: 17.12.2010
20http://creativecommons.org/, letzter Aufruf: 17.12.2010
39
werden können. Vorraussetzung zur Anwendung einer Creative Commons Lizenz ist, dass das
zu lizensierende Werk dem Copyright/Urheberrecht unterliegen kann.
Das Ergebnis eines Open Hardware Projekts ist nicht das Produkt selbst, sondern das Wissen,
wie dieses Produkt hergestellt werden kann. Dieses Wissen liegt in Form digitaler Dokumente
vor, die eine Beschreibung des Produkts liefern. Da es sich bei ihnen grundsätzlich um den
Ausdruck einer Idee handelt, können sie durch das Copyright/Urheberrecht geschützt werden.
Sie erfüllen dadurch die hinreichenden Bedingungen zur Anwendbarkeit der Creative
Commons Lizenzen.
Die Creative Commons ShareAlike-Lizenz (Creative Commons, n.d.) entspricht dabei am
ehesten den Copyleft Lizenzen der Open Source Software. Diese Lizenz erlaubt die
Verbreitung, die Vervielfältigung und die Veränderung eines Werks, wenn das Ergebnis
wiederum unter der gleichen Lizenz verbreitet wird.
Erstaunlicherweise lässt auch die GPL, die als reine Software Lizenz angelegt wurde, einen
gewissen Spielraum offen, um was es sich bei Software handeln muss:
1. The GNU General Public License is a free, copyleft license for software and other
kinds of works.
[GPL, Preamble]
2. „The licenses for most software and other practical works […]“
[GPL, Preamble]
3. „'The Program' refers to any copyrightable work licensed under this License.“
[GPL, Terms and Conditions, 0. Definitions]
4. „The 'source code' for a work means the preferred form of the work for making
modifications to it.“
[GPL, Terms and Conditions, 1. Source Code]
(GNU, 2007)
Die GPL spricht zwar von Software, enthält jedoch durch die Formulierungen „other kinds of
works„ (1.) und „other practical works“ ( 2.) genug Spielraum für eine Anwendung auch auf
Nicht-Software. Dadurch, dass eine Anwendbarkeit der GPL auf Nicht-Software demnach
nicht per se ausgeschlossen wird, kann gefolgert werden, dass die Anwendung der GPL auch
auf Quellcode von Hardware grundsätzlich möglich wäre. Wie die Lizenzen der Creative
Commons fordert die GPL von einem Werk die Anwendbarkeit des Copyrights/Urheberrechts
(3.). Diese Eigenschaft trifft auf die den Quellcode bildenden Dokumente einer technischen
40
Innovation ebenso zu (vgl. Abschnitt 3.1.1).
Während die Durchsetzungsfähigkeit der GPL für Software bereits erfolgreich erstritten
werden konnte (LG München, 19.05.2004, Az. 21 O 6123/4), ist es hinsichtlich der
Anwendbarkeit der GPL auf eine Nicht-Software zu einer Auseinandersetzung vor Gericht
bislang noch nicht gekommen.
3.1.5
Patente
Im Rahmen eines Open Hardware Projekts können die auf dem Copyright beruhenden Open
Source Lizenzen nur auf den Quellcode einer technischen Innovation angewendet werden,
nicht aber auf die Innovation selbst. Die Schutzrechte geistigen Eigentums sehen hierfür die
Verwendung von Patenten vor. Die Verwendung von Patenten erweist sich innerhalb von
Open Hardware Projekten jedoch als kaum durchführbar.
Eine Erfindung muss zum Zeitpunkt eines Patenantrags neu sein (§ 1 Patentgesetz) und darf
nicht Stand der Technik sein (§ 3 Patentgesetz). Zwingender Weise darf sie deshalb bis zu
diesem Zeitpunkt nicht veröffentlicht worden sein. Häufiges Veröffentlichen von
Entwicklungszuständen ist aber eine elementare Eigenschaft im Entwicklungsprozess von
Open Source Projekten („Linus' Law“, Abschnitt 1.3.2), weil nur so erreicht werden kann,
dass alle beteiligten Entwickler über alles vorhandene Wissen verfügen. Die Verwendung von
Patenten wird durch einen kollaborativen und verteilten Entwicklungsprozess faktisch
ausgeschlossen.
Ergänzend dazu hat die Nichtverwendung von Patenten auch eine ideellen Hintergrund. Open
Hardware Projekte haben sich mit der Wahl, ein Produkt durch eine Open Source Methode zu
entwickeln, gerade auch für einen Gegenentwurf zum konventionellen Forschungs- und
Entwicklungsmodell entschieden, welches durch die Anwendung geistiger Eigentumsrechte
eine exklusive Nutzung von Wissen anstrebt.
3.1.6
Zwischenergebnis
Grundlage des offenen Innovationsprozesses der Open Source Software bilden die besonderen
Eigenschaften ihres Quellcodes. Der Quellcode einer Open Source Software muss für jede
Person verfügbar und veränderbar sein, und Veränderungen am Quellcode müssen
weiterverbreitet werden dürfen.
Durch die Anwendung spezieller, auf dem Copyright/Urheberrecht basierender Lizenzen wird
garantiert, dass der Quellcode diese Eigenschaften auch nach Veränderungen behält. Copyleft
und Reziprozität sind dabei nicht zwingend.
41
In Abschnitt 3.1.1 wurde definiert, dass der Begriff Quellcode auch auf Hardware anwendbar
ist. Der Quellcode einer Hardware umfasst dabei alle Informationen, die zur Herstellung der
Hardware notwendig sind.
In Abschnitt 3.1.4 wurde gezeigt, dass der Quellcode von Hardware durch das Copyright
geschützt werden kann. Damit erfüllt der Quellcode die notwendigen Bedingungen, um mit
Lizenzen versehen zu werden, die auch die zukünftige Offenheit garantieren können.
Die Prinzipien der Open Source Software im Hinblick auf die freie Verfügbarkeit des
Quellcodes müssen somit nicht auf Software beschränkt bleiben und können auch auf
Hardware angewendet werden. Der Begriff Open Hardware stellt in dieser Hinsicht das
Äquivalent des Begriffs Open Source Software dar.
Eine Besonderheit zeichnet Open Hardware gegenüber Open Source Software aus, indem ihre
Produkte immer zu einem positiven Preis verkauft werden können. Die Grenzkosten des
immateriellen Gutes Software betragen immer Null. Open Hardware Projekte entwickeln
hingegen ein materielles Gut. Die Grenzkosten von Open Hardware Produkten werden
folglich über Null liegen.
Am 23. September 2010 fand in New York (USA) der Open Hardware Summit21 statt, der als
erste umfassende Konferenz zum Thema Open Hardware erdacht war. Hieran beteiligt waren
Protagonisten der Open Hardware, wie Massimo Banzi (Arduino), Peter Semmelhack (Bug
Labs) oder Chris Anderson (Wired, DIYdrones). Ziel dieser Konferenz war neben der
Werbung für Open Hardware die Erstellung einer einheitlichen Open Hardware Definition
(OSHW) (Freedomdefined.org, n.d).
3.2
Projekte
Die erste Erfindung, bei der bewusst auf den Schutz eines Patents verzichtet wurde, um sie
der Allgemeinheit zur Verfügung zu stellen, ist vermutlich die Daguerreotypie.
Im Jahr 1839 bot der französische Start den Erfindern der Daguerreotypie, ein frühes
Fotografie-Verfahren, die Zahlung einer Pension an, wenn diese im Gegenzug alle
technischen Details des Verfahrens der Öffentlichkeit zugänglich machten. Dieser Handel
ging auf die Initiative des Physikers und Mitglied der Pariser Akademie der Wissenschaften
François Arago zurück, der die Daguerreotypie zu einem Geschenk Frankreichs an die Welt
machen wollte. Kunst und Wissenschaft sollten damit vorangetrieben werden:
„… la France, ensuite, dote noblement le monde entier d’une découverte qui peut tant
21 http://www.openhardwaresummit.org/, 17.12.2010
42
contribuer aux progrès des arts et des sciences.“ (Arago, 1854, S. 458)
Das von den Erfindern Louis Jacques Mandé Daguerre und Nicéphore Nièpce geschriebene
Handbuch wurde in kurzer Zeit in zahlreiche Sprachen übersetzt. Daraufhin entstanden
weltweit Studios für Daguerreotypie. Parallel dazu entwickelte sich eine Foto-Industrie, die,
aufgrund der frei verfügbaren Informationen, den Markt mit Fotoapparaten und Objektiven
belieferte. Bis in die 1850er Jahre konnte sich die Daguerreotypie als die vorherrschende
Fotografie-Technik behaupten (Hiebler, 2003, S. 297).
Auch der 1981 von IBM auf den Markt gebrachte Personal Computer (PC) 5150 stellt in
gewisser Weise ein Open Hardware Produkt dar. Die Besonderheit war, dass sich dieser
Computer allein aus Standardkomponenten zusammensetzte und IBM sich das System nicht
schützen ließ. Dadurch konnten PCs auch durch Dritthersteller gebaut werden. Der IBMkompatible PC entwickelte sich so innerhalb weniger Jahre zu einem inoffiziellen
Industriestandard. Firmen wie Compaq und Dell entstanden, deren Geschäftsmodell darin
bestand, IBM-kompatible PCs zu bauen und zu verkaufen.
IBMs direkter Konkurrent zu Beginn der 1980er Jahre war die Firma Apple, die 1977 den
Apple II mit großem Erfolg auf den Markt brachte. Anfang der 1980er Jahre existierten auf
dem Markt noch verschiedene Systeme in der Klasse der Personal Computer, doch die
Systeme von Apple und IBM setzten sich schließlich durch. Anders als IBM verfolgte Apple
für seine Computer ein geschlossenes System, indem Soft- und Hardware nur aus einer Hand
angeboten werden.
IBM baut zwar heute keine PC's mehr, doch konnte sich sein 1981 eingeführtes System bis
heute behaupten. Heute besitzt es einen Marktanteil von über 90% (Net Applications, 2010).
Seit ihrem Umstieg auf Intel Prozessoren im Jahr 2006 handelt es sich bei Apple Computern
genaugenommen ebenfalls um IBM-kompatible PCs.
Erste Open Hardware Projekte, die bewusst die Prinzipien der Open Source Software
adaptierten, entstanden erst in den 2000er Jahren, wie z.B. das Arduino oder das OpenSPARC
Projekt. In den letzten beiden Jahren 2009/2010 ist die Anzahl von Open Hardware Projekten
sprunghaftangestiegen22 . Eine genaue Zahl lässt sich auch hier nur schwer ermitteln.
Im Folgenden sollen einige Projekte vorgestellt werden, die zur Untersuchung des Begriffs
Open Hardware in dieser Arbeit herangezogen wurden.
22 Aus eigener Beobachtung des Autors.
43
3.2.1
Arduino
Das Arduino Projekt wurde 2005 durch Massimo Banzi und David Cuartielles, Dozenten des
damaligen Interaction Design Instituts in Ivrea (Interaction Design Institute Ivrea - IDII),
Italien, gegründet. Ihr Ziel war es, dem Wunsch ihrer Studenten nach einer preiswerten und
einfach zu programmierenden Microcontroller Plattform nachzukommen. Diese Plattform
sollte vor allem für Kunstprojekte genutzt werden können.
Es entstand ein Microcontroller mit eigener Entwicklungsumgebung, die auf einem Computer
ausgeführt werden muss. Die in dieser Entwicklungsumgebung geschriebenen Programme,
können auf den Microcontroller übertragen und ausgeführt werden. Mit dem Microcontroller
können dann, wenn er durch Sensoren oder Eingabegeräte erweitert wurde, verschiedenste
Eingangssignale weiterverarbeit werden. Die Entwicklungsumgebung basiert auf den Open
Source Projekten Processing23 und Wiring24.
Die erste Serie von Arduinos wurde mit einem Startkapital von 3000 Euro bei einem kleinen
Chiphersteller produziert. Das Design des Boards wurde unter einer Creative Commons
Lizenz veröffentlicht, die vorschreibt, dass Weiterentwicklungen unter den gleichen
Bedingungen weitergegeben werden müssen. Die Entwicklungsumgebung steht, genau wie
ihr Ursprünge Processing und Wiring, unter der GPL.
Arduino erlaubt Dritten, das Design des Boards zu nutzen, um eigene Microcontroller
herzustellen. Der Name „Arduino“ ist aber geschützt. Seine Nachahmungen müssen darum
unter einem anderen Namen angeboten werden.
Die Arduino Microcontroller werden auch in vielen Open Hardware und DIY Projekten
genutzt. Zum Beispiel verwendet der RepRap Arduino-kompatible Microcontroller. Das
Projekt DIYdrones25 von Chris Andersons, dem Chefredakteur der Wired26, das sich mit der
Entwicklung von unbemannten ferngesteuerten Flugobjekten beschäftigt, nutzt den Arduino
ebenfalls in mehreren Teilprojekten als zentrale Steuerungseinheit.
3.2.2
OpenSPARC
Im Dezember 2005 veröffentlichte Sun Microsystems (Sun) das Design ihres Mikroprozessors
UltraSPARC T1 und initiierten damit das Projekt OpenSPARC. Der „Source Code“ des
Prozessors ist in Verilog verfasst. Verilog ist eine Hardwarebeschreibungssprache (HDL –
Hardware Description Language), die dazu genutzt wird Operationen integrierter Schaltungen
23http://www.processing.org, letzter Aufruf: 17.12.2010
24http://wiring.org.co/, letzter Aufruf: 17.12.2010
25 http://diydrones.com/, letzter Aufruf: 17.12.2010
26 http://www.wired.com/, letzter Aufruf: 17.12.2010
44
zu beschreiben. Spezielle Software Werkzeuge ermöglichen das Simulieren und Testen von
durch HDLs beschriebener Hardware. Sun veröffentlicht entsprechende Werkzeuge ebenfalls
im Rahmen des OpenSPARC Projekts.
Im März 2006 stellte Sun den Source Code des Projekts unter die GPL. Auch der Nachfolger
des T1, der T2, ist seit Dezember 2007 Teil des OpenSPARC Projekts.
Sun ist für sein starkes Engagement im Open Source Software Bereich bekannt, und bietet mit
www.sunsource.net eine Plattform für Entwickler an, auf der von Sun unterstützte Open
Source Projekte organisiert werden können. Das OpenSPARC Projekt und die mit ihr
verbundenen Projekte werden ebenfalls hierüber verwaltet.
Im Rahmen dieser Arbeit ist auch zum OpenSPARC Projekt Kontakt aufgenommen worden.
Wegen der Firmenübernahme Suns durch Oracle hatten bereits einige Mitarbeiter, die am
OpenSPARC Projekt beteiligt waren, die Firma verlassen, und ein Interview mit einem
Beteiligten konnte nicht mehr durchgeführt werden. Die Zukunftsaussichten für des
OpenSPARC Projekt sind aufgrund der Übernahme ungewiss
3.2.3
RepRap / MakerBot
RepRap und MakerBot entwickeln sogenannte 3D-Drucker, die zum Rapid-Prototyping
genutzt werden. Beim Rapid-Prototyping handelt es sich um ein additives Fertigungsverfahren, bei dem auf digitale Konstruktionsdaten, meist CAD-Daten, zurückgegriffen wird.
Dabei bewegt sich ein Druckkopf über eine Arbeitsplattform und erstellt aus Fäden
geschmolzenen Kunststoffs ein dreidimensionales Objekt. Der RepRap stellt ein Versuch dar,
eine sich selbst reproduzierende Maschine zu konstruieren. Alle für die Konstruktion eines
RepRaps notwendigen Kunststoffteile können durch einen RepRap hergestellt werden.
Das RepRap Projekt wurde 2005 durch Dr. Adrian Bowyer an der Universität von Bath,
England, gegründet. Die Pläne, die für die Konstruktion des Geräts benötigt werden, sowie
die Software für seinen Betrieb stehen unter der GPL.
Das 2009 in New York, USA, gegründete Unternehmen MakerBot Industries (MakerBot)
stellt den 3D Drucker Cupcake CNC her. Der Cupcake CNC stammt vom RepRap ab, sein
Schwerpunkt liegt aber stärker auf eine einfach zu handhabende Maschine, mit Verzicht auf
seiner selbständigen Reproduzierbarkeit. MakerBot ist auch für die Online Plattform
Thingiverse27 verantwortlich, die als eine Art Open Hardware- und DIY-Plattform dient.
Mitglieder tauschen hier Daten und Designs aus, die sowohl im Rahmen des Cupcake CNC's,
aber auch in anderen kollaborativen Open Hardware Projekten entstanden sind.
27 http://www.thingiverse.com/, letzter Aufruf: 14.12.2010
45
MakerBot veröffentlicht alle für den Bau des Cupcake nötigen Dateien unter der GPL.
3.2.4
FREE BEER
FREE BEER entstand aus dem Projekt Vores Øl, das von Studenten der IT University of
Copenhagen, Dänemark, und der Künstlergruppe Superflex initiiert wurde. Ziel des Projekts
war es zu zeigen, wie das Prinzip Open Source auch außerhalb der digitalen Welt angewandt
werden kann. Superflex überführte Vores Øl schließlich in das FREE BEER Projekt. Die
Anwendung des Open Source Prinzips auf ein Rezept für Bier ist dabei eine Anspielung auf
den Ausspruch Richard Stallmans, dass das „Free“ in Free Software wie das „Free“ in Free
Speech und nicht wie in Free Beer zu verstehen sei.
Das Rezept des FREE BEERs wird unter einer Creative Commons Share Alike Lizenz
veröffentlicht und liegt bereits in seiner vierten Version vor. Das Bier darf von jedem
Unternehmen hergestellt und verkauft werden. Veränderungen am Rezept müssen unter der
gleichen Lizenz veröffentlicht werden, unter der auch das ursprüngliche Rezept veröffentlicht
wurde.
3.2.5
Whirlwind Wheelchair
Whirlwind Wheelchair wurde 1980 durch Ralf Hotchkiss gegründet, der seit einem Unfall auf
einen Rollstuhl angewiesen ist. Ziel seines Projekt ist es, einen robusten und einfach
reparierbaren Rollstuhl zu entwickeln, der insbesondere in schwächer entwickelten Ländern
produziert und genutzt werden kann. Bis heute ist ein Netzwerk regionaler, durch Whirlwind
Wheelchair zertifizierter, Hersteller in Lateinamerika, Afrika und Süd-Ost-Asien entstanden,
die laut Homepage (Whirlwind Wheelchair, n.d.) jährlich bis zu 12000 Rollstühle herstellen.
Das Design der Rollstühle wird unter Public Domain veröffentlicht. Weitere Rollstühle
werden zusätzlich auch von kleineren Werkstätten, hier vor allem in Entwicklungsländern,
produziert.
Whirlwind Wheelchair unterscheidet sich von anderen in dieser Arbeit besprochenen
Projekten dahingehend, dass es keinen Source Code zum Download zur Verfügung stellt und
sich bei der Realisierung ihres Konzepts von Open Hardware nicht an Open Source Software
orientiert. Ursache hierfür ist unter anderem, dass dieses Projekt zeitlich vor Free und Open
Source Software entstanden ist.
Whirlwind Wheelchair verfolgt das Prinzip eines „transparenten Designs“. Die Rollstühle
sollen dadurch einfacher reparier- und modifizierbar sein. Der Wissenstransfer erfolgt durch
den Erwerb eines Rollstuhls. Weil das Design nicht geschützt ist – es steht unter Public
Domain – darf der Rollstuhl nachgebaut werden.
46
Whirlwind Wheelchair möchte keine anonyme Offenheit anbieten („Not open anonymously“),
sondern strebt eine Partnerschaft mit den Produzenten seines Rollstuhls an. Möchte jemand
den Rollstuhl kopieren, leistet Whirlwind Wheelchair auf Anfrage technische Hilfe in Form
von technischen Zeichnungen (Quellcode der Hardware) und ihrer langjährigen Erfahrung.
3.2.6
Bug Labs
Die New Yorker Firma Bug Labs wurde 2007 gegründet und bietet ein modulares System zum
Aufbau technischer Geräte an. Initial für den Aufbau der Firma war die Frustration, die der
spätere Gründer Peter Sammelhack bei der Konstruktion eines eigenen GPS Moduls erfuhr.
Dieses Vorhaben erwies sich als zu kompliziert, da alle möglichen Lösungen komplexes
Vorwissen voraussetzten. Daraus entstand die Idee, eine Plattform an Modulen zu entwickeln,
die einfach miteinander kombiniert werden können, um neue Geräte entstehen zu lassen. Die
Plattform besteht inzwischen aus einem Hauptmodul, das als zentrale Steuerungseinheit dient,
und Modulen, die als Schnittstellen zu externen Geräten oder zu Sensoren dienen, und
mittlerweile auch aus einem GPS Modul. Über einfache Steckverbindungen können die
einzelnen Module miteinander verbunden werden.
Das Betriebssystem des Hauptmoduls basiert auf Linux. Bug Labs bietet ein Software
Development Kit (SDK) an, um Programme zur Steuerung der Funktionen der Module zu
entwickeln.
Neben der für den Betrieb der Module notwendigen Software (Betriebssystem, SDK und
Treiber), bietet Bug Labs sämtliche Informationen zur Hardware zum Download an. Die CAD
Dateien der Modulgehäuse, sowie die Schaltpläne und die GERBER Dateien der
elektronischen Komponenten werden unter der GPL, bzw. Creative Commons Lizenzen
(Attribution Share-Alike) veröffentlicht.
Bug Labs bietet die Module über einen eigenen Online Shop zum Verkauf an; dennoch
können Dritte die durch Bug Labs veröffentlichten Informationen nutzen, um die Module
eigenständig herzustellen, zu verändern oder zu verkaufen. Die Lizenzbedingungen der GPL
und der Creative Commons Lizenz müssen dabei eingehalten werden.
3.2.7
Open Design – Ronen Kadushin
Der israelische und in Berlin arbeitende Designer Ronen Kadushin initiierte im Jahr 2006 sein
Open Design28 Projekt.
Kadushin veröffentlicht auf seiner Webseite Informationen zu seinen Werken, die daraufhin
durch Dritte erstellt werden können. Bei diesen Werken handelt es sich überwiegend um
28 http://www.ronen-kadushin.com/Open_Design.asp, letzter Aufruf: 17.12.2010
47
Möbel (Stühle, Tische, Regale).
Die Informationen werden als CAD-Dateien bereitgestellt, die dazu genutzt werden können,
die Einzelteile der Möbel durch eine CNC-Fräse (Computerized Numerical Control) aus
Metallblechen ausschneiden zu lassen.
Kadushin veröffentlicht alle Informationen unter einer Creative Commons (AttibutionNonCommercial-ShareAlike-Lizenz ). Eine kommerzielle Nutzung der Daten ist nur nach
Absprache mit dem Designer möglich.
3.2.8
VIA Open Book
Im Mai 2008 veröffentlichte der taiwanesische Technologie Konzern VIA Technologies (VIA)
das OpenBook. VIA ist ein Hersteller von Grafik- und Soundchips, Prozessoren und
Mainboards. Bei dem OpenBook handelte es sich um ein sogenanntes Netbook, einer Klasse
kleiner, leichter und kostengünstigen Laptops.
Das OpenBook soll ein Referenz Design darstellen. Die CAD Dateien des Gehäuses wurden
unter einer Creative Commons Lizenz veröffentlicht, wodurch das äußere Design des
Netbooks durch Dritte verändert werden durfte. Mit dem OpenBook will VIA OEM
Computerhersteller (Original Equipment Manufacturer) ansprechen, die bei der Herstellung
ihrer Produkte auf fertige Systemkomponenten anderer Hersteller. Auf Basis des OpenBooks
sollen dies OEM Hersteller ein eigenes Netbook anbieten können.
Dabei warb VIA mit der Möglichkeit, dass Hersteller die Entwicklungskosten und die
Produktionseinführungszeit reduzieren können, wenn sie auf das Referenzdesign des
Netbooks zurückgriffen und nur noch die äußere Hülle ihren Wünschen anpassen müssten.
Die nötigen Systemkomponenten würden dann von VIA geliefert werden.
3.2.9
Welche Quellcodes werden verwendet
Die Quellcodes der beschriebenen Projekte und auch die Quellcodes heutiger Hardware liegen
oftmals in elektronischer Form vor (vgl. Digital Prototyping, Abschnitt 3.1.1). Um ein
möglichst hohes Maß an Offenheit zu garantieren, wurden für den Quellcode Datenformate
gewählt, die vorzugsweise zur Bearbeitung dieses Typs Hardware verwendet werden. Im
Folgenden wird ein Überblick geliefert werden, welche Datenformate von den untersuchten
Projekten genutzt werden.
Die Projekte Bug Labs, MakerBot und Ronen Kadushin bieten .dxf (Drawing Interchange
Format) Dateien an. Dxf ist ein Dateiformat des CAD Programms AutoCAD der Firma
Autodesc, welches zum Informationsaustausch zwischen verschiedenen CAD Programmen
48
dient, aber auch zur Maschinensteuerung verwendet werden kann. Das .dxf-Format kann von
allen gängigen CAD-Programmen gelesen und verarbeitet werden.
Projekt
Beschreibung
Format des Quellcodes
EAGLE
Lizenz
Arduino
Microcontroller
Creative Commons Share
Alike
Bug Labs
Modulare
.dxf
Hardwarekomponenten GERBER
GPL
Creative Commons Share
Alike
FREE BEER
Bier
Text
Creative Commons Share
Alike
MakerBot
3D Drucker
.dxf
EAGLE
GERBER
GPL
OpenSPARC
Mikroprozessor
Verilog
GPL
RepRap
3D Drucker
EAGLE
GERBER
GPL
Open Design – Ronen
Kadushin
Möbel
.dxf
Creative Commons NonCommercial Share Alike
VIA OpenBook
Netbook
CAD
Creative Commons Share
Alike
Whirlwind Wheelschair
Rollstuhl
-
Public Domain
Tabelle 1: Übersicht der untersuchten Projekte
Arduino, Bug Labs, MakerBot und RepRap bieten zudem EAGLE und GERBER Dateien an.
GERBER Dateien werden im Datenaustausch zwischen CAD und CAM bei der Herstellung
elektronischer Leiterplatten (PCB – Printed Circuid Boards) genutzt. EAGLE (Einfach
Anzuwendender Grafischer Layout Editor) ist ein Programm der Firma CadSoft, die einen
einfachen Editor zur Erstellung von PCBs darstellt, und sich zwar vorwiegend an Hobby
Entwickler richtet. EAGLE ist in der Lage, PCBs in GERBER Format auszugeben.
OpenSPARC veröffentlicht seine Informationen in der Hardwarebeschreibungssprache
Verilog, welche neben VHDL die am meisten verbreitete Sprache ist, die im
Entwicklungsprozess von Mikroprozessoren Verwendung findet. Verilog kann auch zur
Erstellung von Testumgebung und zum Debugging, dem Identifizieren von Fehlern,
verwendet werden.
Bei den beschriebenen Formaten handelt es sich ausschließlich um binäre Datenformate. Im
Unterschied zu reinen Textformaten, wie sie für den Quellcode von Software verwendet
werden, können Versionsverwaltungen für binäre Daten nur begrenzt eingesetzt werden. Die
Versionsverwaltung binärer Dateien ist zwar möglich, doch können die inhaltlichen
Unterschiede zwischen zwei verschiedenen Versionen nicht kenntlich gemacht werden.
Die Projekte Bug Labs, MakerBot und RepRap stellen zudem Wikis zur Verfügung, in denen
49
Informationen zu den Projekten kommuniziert werden.
3.2.10
Bereitstellung des Quellcodes
Der überwiegende Teil der untersuchten Open Hardware Projekte stellen ihren Quellcode per
http-Download auf ihren Webseiten zur Verfügung. Ausnahmen bilden RepRap, die ihren
Quellcode durch Sourceforge hosten lassen und Whirlwind Wheelchair, die, wie bereits
dargestellt, gar keine Downloads anbieten, sondern ihren Quellcode nur auf Anfrage abgeben.
Projekte, die auch Software verwenden, nutzen die üblichen aus Open Source Software
Projekten bekannten Distributionswege.
Bug Labs, MakerBot und RepRap verwenden svn-Repositories. MakerBot lässt sein
Repository durch Google Code2930 hosten. RepRap, bietet, wie schon den Quellcode zu seiner
Hardware, über Sourceforge31 an. Bug Labs verwaltet seinen Code in einem eigenen
Repository. Das Arduino Projekt nutzt die Software Git zur Versions-verwaltung seiner
Software und lässt diese darum durch die auf Git spezialisierte Plattform GitHub hosten32.
Auffällig ist, dass ein überwiegender Teil der Open Hardware Projekte ihren Quellcode mit
Hilfe der gleichen Mittel veröffentlicht, wie es die Projekte der Open Source Software tun.
Teilweise werden dabei sogar die auf Open Source Software Projekte spezialisierten
Distributionsplattformen verwendet (SourceForge und GitHub). Beinhaltet ein Open
Hardware Projekt auch einen Software-Teil, wird dieser als ein typisches Open Source
Software Projekt entwickelt.
3.2.11
Welche Lizenzen werden verwendet
Alle, mit Ausnahme von Whirlwind Wheelchair, in dieser Arbeit untersuchten Projekte,
verwenden entweder Lizenzen aus dem Open Source Software Bereich oder der Creative
Commons (siehe Tabelle 1).
MakerBot, RepRap und OpenSPARC verwenden die GPL für die veröffentlichten
Informationen zur Hardware, und für die notwendige Software. Die Software wird verwendet,
um die Hardware zu betreiben (MakerBot, RepRap) oder um die Hardwareinformationen
effizient zu nutzen und bearbeiten zu können (OpenSPARC).
Die Projekte OpenSPARC und RepRap, bzw. die leitenden Personen dieser Projekte, verfügten
bereits vor dem aktuellen Projekt über Erfahrungen mit Open Source Software Projekten.
29 http://code.google.com/, letzter Aufruf: 17.12.2010
30 http://code.google.com/p/makerbot/, letzter Aufruf: 17.12.2010
31 http://sourceforge.net/projects/reprap/, letzter Aufruf: 17.12.2010
32 http://github.com/arduino/Arduino, letzter Aufruf: 17.12.2010
50
Dies lässt den Schluss zu, dass sich dieser Einfluss auf die Auswahl einer geeigneten Lizenz
für ein Open Hardware Projekt ausgewirkt hat, weil die dominierende Open Source Software
Lizenz gewählt wurde.
Sun war lange als Unterstützer von Open Source Projekten aktiv und hat mit OpenOffice ein
proprietäres Computerprogramm in ein Open Source Projekt überführt. Adrian Bowyer von
RepRap nennt sein Engagement für Linux als Motiv, weshalb er RepRap als ein Open Source
Projekt entwickelt („I've used Linux more or less since it started“, P5).
Eine Besonderheit stellt das Projekt MakerBot dar, bei dem es sich um einen Zweig des
Projekts RepRap handelt. Da RepRap die GPL verwendet, werden auch seine Derivate die
GPL verwenden müssen.
Das Open Design Projekt Ronen Kadushins und das FREE BEER Projekt verwenden
Lizenzen der Organisation Creative Commons, um ihre Werke zu schützen. Wie das Projekt
Whirlwind Wheelchair besitzen diese Projekte keinen Softwareanteil. Eine weniger enge
Verknüpfung zur Open Source Software Entwicklung könnte begründen, weshalb in diesen
Projekten eine Lizenz aus dem Open Content Bereich einer Softwarelizenz, wie der GPL,
vorgezogen wurde.
FREE BEER verwendet eine Attribution Share Alike Lizenz. Das Share Alike entspricht dem
Copyleft. Attribution schreibt vor, dass der ursprüngliche Urheber im Fall einer Veränderung
des Dokuments weiterhin genannt werden muss. Ronen Kadushin verwendet eine Attribution
Non-Commercial Share Alike Lizenz, sie entspricht damit der des FREE BEER Projekts,
schließt aber zusätzlich eine kommerzielle Verwendung der veröffentlichten Informationen
aus.
Bug Labs veröffentlicht Software und Hardware Informationen. Sämtliche Software wird
unter der GPL veröffentlicht. Für die Art und Weise, wie die Hardware Informationen
lizensiert werden, liefert Bug Labs auf ihrer Internetseite eine ausführliche Erklärung:
„We generally license these materials to you under GPLv3. Open source software licenses
do not always provide a great fit for these kinds of materials, but our goal is to track the
principles of open source software as much as we can. When we license these materials
under GPLv3, the “source code” is the file format that can be manipulated by the relevant
tool—such as the CAD design tool, rather than the resulting layout document.“
(Bug Labs, n.d.)
Bug Labs fügt eine ergänzende Definition des Begriffs Open Source hinzu. Demnach handelt
51
es sich bei Source Code nur um die Dateien, die mit Hilfe eines üblichen Werkzeugs weiterhin
bearbeitet werden können. CAD Dateien müssen in einem Datenformat vorliegen, welches
auch durch ein CAD Programm bearbeitet werden kann. Eine aus einem CAD Entwurf
exportierte PDF Datei würde darum nicht als Source Code verstanden werden.
Diese Definition deckt sich mit der Source Code Definition und der Herleitung des Begriffes
des Quellcodes einer Hardware in dieser Arbeit (3.1.1).
Neben der GPL verwendet Bug Labs für einige Dokumente, insbesondere für PDFs, eine
Creative Commons Attribution Share Alike Lizenz.
Whirlwind Wheelchair nimmt wiederum eine Sonderrolle ein. Informationen sollen nicht
anonym weitergegeben werden und stehen daher auch nicht zum Download bereit.
Stattdessen sollen Informationen in persönlichen Netzwerken vermittelt werden. Whirlwind
Wheelchair verwendet daher auch keines der gängigen Copyleft Lizenzmodelle, sondern nutzt
das Prinzip des Public Domains.
Generell lässt sich sagen, dass die untersuchten Projekte mit dem Problem der Lizenzwahl
eher pragmatisch umgehen („There is none. It's all computer files, and they are all
copyright“, RepRap). Durch die Befragung sollte geklärt werden, ob sich die Projekte für die
Zukunft eine spezielle Open Hardware Lizenz wünschten. Hier waren die Auffassungen
geteilt. Nur zwei Projekte äußerten einen positiven Wunsch (Bug Labs, Whirlwind
Wheelchair), wohingegen die übrigen Projekte keine, oder zumindest keine dringende
Notwendigkeit einer speziellen Lizenz sehen. Dabei verweisen sie auf den funktionierenden
Status Quo („No. In practice all the open licences are used to mean the same thing“, RepRap;
„Maybe, depends on many factors, but everything seems to be working out ok for now.“,
MakerBot).
Bug Labs spricht sich klar für eine spezielle Open Hardware Lizenz aus und begründet den
Wunsch mit der Unschärfe bestehender Lizenzen. Die existierenden Open Source Lizenzen
lassen auf Hardware Projekte bezogen immer einen Interpretationsspielraum offen. Dieser
Spielraum könnte im Ernstfall sowohl für, aber auch gegen ein Projekt („open companies“)
ausgelegt werden.
„Yes! Currently the licence isn't defined whatsoever. Which means all the licences are
interpretted wihtout any standardization. This is questionable as it can work both for and
against open companies. The ambigous behaviour of the licence leaves a lot to be
determindes by interpretation, which of cource vary.“ (Bug Labs)
52
Bug Labs war einer der Initiatoren des Open Hardware Summits33 am 23. September 2010 in
New York (USA). Auf diesem Kongress wurde unter anderem ein Entwurf für eine Open
Hardware Definition (Freedomdefined.org, n.d.) erarbeitet. Es ist daher denkbar, dass auf
Basis dieser Plattform eine spezielle Lizenz für Open Hardware Programme erarbeitet wird.
Durch seinen Background nimmt das Projekt Whirlwind Wheelchair auch zu diesem Thema
eine Sonderrolle ein:
„I think that a licence will help people become aware of the possibilities. Something like
creative commons that allows people to stipulate conditions of the usage of their hardware.
I think that licenses will encourage more people to participate in open source hardware,
but ideally shouldn't be needed.“ (Whirlwind Wheelchair)
Der Nutzen einer Lizenz läge demnach vor allem in seiner Wirkung auf Personen, die bisher
nur wenig Erfahrungen zu der Thematik Open Hardware sammeln konnten. Sie können
dadurch ermutigt werden sich für dieses Thema zu engagieren. Aus Sicht Whirlwind
Wheelchairs sollten Lizenzen aber idealerweise gar nicht nötig sein. Das deckt sich auch mit
der Lizenzierungspolitik des Projekts, welches das Prinzip des Public Domain nutzt –
Whirlwind Wheelchair verzichtet also auf jegliche Lizenz.
Patente spielen in den untersuchten Projekten keine Rolle.
Im Ergebnis kann festgehalten werden, dass eine spezielle Open Hardware Lizenz nur
teilweise gewünscht wird. Langfristig könnte die Entwicklung einer entsprechenden Lizenz
aber durchaus als sinnvoll betrachtet werden, um stärkere Rechtssicherheit zu schaffen und
um verstärkt auf die Möglichkeit der Entwicklungsform der Open Hardware aufmerksam zu
machen.
3.2.12
Produktion und Distribution der Produkte
Im Unterschied zur Open Source Software entstehen aus dem Quellcode der Open Hardware
materielle Güter, die aufwendig produziert werden müssen und zu einem positiven Preis
verkauft werden können (vgl. Abschnitt 3.1.3).
MakerBot und Bug Labs unterhalten auf ihren Webseiten Online Shops, in denen sie ihre
Produkte zum Kauf anbieten. MakerBot bietet in seinem Shop Eigenbau-Kits ihres 3DDruckers und zusätzliche Einzel- und Ersatzteile an, die für den Betrieb der benötigt werden 34.
Bug Labs verkauft seine Produkte ebenfalls in einem eigenen Shop, die sie durch zwei Firmen
33 http://www.openhardwaresummit.org/, letzter Aufruf: 17.12.2010
34 http://store.makerbot.com/, letzter Aufruf: 17.12.2010
53
herstellen lassen35.
Auch das Arduino Projekt lässt seine Microcontroller durch eine externe Firma herstellen,
verkauft diese aber nicht direkt an Endkunden. Arduino veröffentlicht auf seiner Webseite ein
Verzeichnis mit Händlern, über die das Produkt bezogen werden kann 36.
35 http://store.buglabs.net/, letzter Aufruf: 17.12.2010
36 http://arduino.cc/en/Main/Buy, letzter Aufruf: 17.12.2010
54
4
Ökonomische Aspekte des Modells Open Source
4.1
Fragestellung
„Reciprocity is a key element of any market-based culture, but the arrangement I'm
describing feels to me more like a kind of gift economy in which people do things for one
another out of a spirit of building something between them, rather than a spreadsheetcalculated quid pro quo. When that spirit exists, everybody gets a little extra something, a
little sparkle, from their more practical transactions; different kinds of things become
possible when this mind-set pervades. Conversely, people who have valuable things to add
to the mix tend to keep their heads down and their ideas to themselves when a mercenary
or hostile zeitgeist dominates an online community.“
(Rheingold, 2000, S.49)
Viele Publikationen der letzten Jahre, die sich mit dem Thema Open Source Software
beschäftigten, stellten die Frage, wie das Phänomen Open Source gesellschaftlich und
ökonomisch einzuordnen sei. Die freiwillige und unentgeltliche Einbringung von Beiträgen zu
einem Open Source Projekt wird dabei auch oft als eine Form des Gabentausches – gift
culture – gedeutet (s.o. Howard Rheingold).
In den folgenden Abschnitten werden einige ökonomische Begriffe erläutert werden, die zur
Erklärung des Prinzips Open Source herangezogen werden können.
4.1.1
Allmende und Öffentliches Gut
Eine Möglichkeit der ökonomischen Einordnung könnte das Modell Allmende und
Öffentliches Gut bieten. Dabei handelt es sich um ein Gut der Allmende (engl. common good)
nach wirtschaftswissenschaftlicher Auffassung dann, wenn potentielle Nachfrager von seiner
Nutzung nicht ausgeschlossen werden können, die Nutzungsansprüche der Nachfrager jedoch
rivalisieren (Dorn et al., 2010, S. 184).
Gängige Beispiele für Allmendegüter sind Meeresfische oder die Nutzung öffentlicher
Straßen. Meeresfische dürfen von jeder Person gefischt werden. Öffentliche Straßen dürfen
von jeder Person genutzt werden (im Unterschied zu privaten Straßen). Die potentiellen
Nutzer rivalisieren untereinander. Bspw. wäre der Bestand der Fische durch eine
Überfischung bedroht und die Anzahl der Verkehrsteilnehmer einer Straße zu einem
bestimmten Zeitpunkt begrenzt, so dass einVerkehrsstau droht. In beiden Fällen kann das Gut
durch weitere Nutzer nicht mehr genutzt werden, obwohl sie dazu berechtigt wären.
Die Tragik der Allmende (engl. Tragedy of the Commons (Hardin, 1968)) beschreibt ein
55
Modell, nach dem eine frei verfügbare aber knappe Ressource nicht effektiv gegen eine
Übernutzung geschützt ist. Jeder Nutzer versucht in diesem Fall maximalen persönlichen
Gewinn durch eine Nutzung des Gutes zu erzielen. Da aber der kurzfristige Gewinn für jeden
Einzelnen wichtiger ist, als die erst langfristig spürbar werdenden Kosten der Übernutzung,
besteht bei steigender Zahl der Nutzer die Gefahr einer Erschöpfung des Guts (vgl. Hardin,
1968, S. 1244). Die Ressource wird schließlich knapp.
Im Unterschied dazu verhalten sich Öffentliche Güter (engl. public good) in ihren
Nutzungsansprüchen nicht rivalisierend (Dorn et al., 2010, S. 184). Ursache hierfür ist meist,
dass das Vorkommen dieser Güter so groß ist, dass eine Verknappung praktisch nicht möglich
ist.
Abgesehen von einer mündlichen Weitergabe war Wissen lange Zeit an physische Datenträger
gebunden. Im digitalen Zeitalter kann Wissen nahezu körperlos transferiert werden. Wissen,
genau wie Software, ist daher ein immaterielles Gut. Wird ein immaterielles Gut von einem
Nutzer an einen anderen weitergegeben, so kann der ursprüngliche Nutzer das Gut weiterhin
nutzten, so dass die Nachfragenden nicht in ihrer Nutzung rivalisieren. Immaterielle Güter
unterliegen keiner Abnutzung, können verbrauchsfrei genutzt und kostenlos vervielfältigt
werden.
Unterliegen immaterielle Güter keinen Mechanismen der Ausschließlichkeit, z.B. Lizenzen,
Patenten oder Kopierschutz, handelt es sich bei ihnen um Öffentliche Güter.
Als Ergebnis kann festgehalten werden, dass es sich bei dem Wissenskorpus eines Open
Source Projekts um ein Öffentliches Gut handelt.
4.1.2
Gabe, Tausch, Transfer
Sebald (2008) strengt eine Abgrenzung zwischen dem Model der „offenen Wissensökonomie“
(S. 226), die bei dem Prinzip der Open Source Software angewendet wird, und der
herkömmlichen Warenökonomie an. Dabei untersucht er die Begriffe des Markt- und des
Gabentauschs auf ihre Anwendbarkeit und stellt sie schließlich dem Begriff des Transfers
gegenüber.
Nach Ansicht Sebalds kann der Begriff des Tausches jedoch nicht auf das Prinzip der offenen
Wissensökonomie angewendet werden, der „eben den, wie abstrakt auch immer vermittelten,
Bezug von auf Warenförmiges (oder in Warenform gebrachtes) bezogenen Handlungssequenzen aufeinander impliziert“ (2008, S. 229). Bei einem Tausch zwischen zwei Akteuren
bedeuten diese Handlungssequenzen, dass zunächst ein Verlust durch den Akt des Gebens
entstehen muss, der mit dem Akt des Nehmens ausgeglichen wird. Voraussetzung hierfür sei,
56
dass beide Akteure in einem Eigentumsverhältnis zu dem Objekt stehen, das getauscht werden
soll (vgl. Sebald, 2008, S. 229).
Da es sich bei dem Quellcode um ein öffentliches Gut handelt (vgl. Abschnitt 4.1.1), zu dem
keinerlei Eigentumsverhältnisse bestehen, kann der Begriff des Tauschs in diesem Fall nicht
greifen. Im Falle des Entwicklers, der einen Beitrag zu einem Quellcode leisten möchte,
existiert kein zweiter Akteur, mit dem er einen Tausch vollziehen könnte. Auch ein Verzicht
tritt, aufgrund einer Nicht-Rivalität (vgl. Abschnitt 4.1.1), nicht ein. Hierbei ist es unerheblich,
ob es sich um einen Markttausch handelt, bei dem Leistung und Gegenleistung direkt
erfolgen, und bei dem das Aufwiegen der Werte im Mittelpunkt stehen, oder einem
Gabentausch, bei dem die Gegenleistung in der Regel nicht sofort zu erfolgen hat, und bei
dem der Akt des Tausches vielmehr der Schaffung und Erhaltung sozialer Beziehungen dient
(vgl. auch Reinhard, 2006, S. 269).
Stattdessen sieht Sebald im Transfer einen sinnvollen Erklärungsansatz (2008, S. 234 ff.).
Anders als beim Tausch, verlaufe ein Transfer unilateral. Bezogen auf das Modell Open
Source, ist neben dem gebenden Entwickler kein weiterer Akteur nötig. Der Begriff des
Transfers verlange auch keinen Verzicht des Gebenden auf eine weitere Nutzung des
transferierten Gutes (vgl. Sebald, 2008, S.234 ff).
Sebald macht drei Typen des Transfers im Open Source Prozess ausfindig:
1. die Zugänglichmachung des Wissens, z.B. auf einem öffentliche Server
2. Verwendung durch Dritte
3. Feedback (Bugreports, Patches, etc.) durch Dritte
Im wissenschaftlichen Kontext findet der Begriff des Wissenstransfers Verwendung. Eine
Parallele zwischen dem Wissenschaftsbetrieb und den Methoden der Open Source
Communities wurde bereits von Lerner und Tirole (2000) aufgezeigt, die auf Ähnlichkeiten in
den Anreizsituationen hinwiesen.
Auf Ähnlichkeiten zwischen Wissenschaftsbetrieb und Open Source Communities verweist
auch Benkler (2007, S.63) – Open Source Entwickler und Wissenschaftler arbeiten stark
dezentralisiert, entscheiden nach eigenem Interesse und müssen keinen Marktmechanismen
gehorchen. Mit dem Modell Transfer lässt sich der Beitrag eines Entwicklers aus
ökonomischer Sicht als Transfer von Wissen in einen Wissenspool einordnen, wobei der
Wissenspool in diesem Fall öffentliches Gut ist.
Als Ergebnis bleibt festzustellen, dass es sich bei der Leistung von Beiträgen zum Quellcode
57
eines Open Source Projekts (Open Source Software oder Open Hardware) um einen
Wissenstransfer handelt. Der Transfer verläuft dabei in beide Richtungen, vom Entwickler
zum Projekt und vom Projekt zum Entwickler.
Bei Open Hardware Projekten findet ein Wissenstransfer nur in Bezug auf den Quellcode
statt. Das Resultat dieses Quellcodes ist ein materielles Gut (vgl. Abschnitt 3.1.3), das dann
im Sinne eines Markttausches gehandelt werden wird.
4.2
Grenzen geistigen Eigentums
Das Modell Open Source stellt sowohl für Software als auch für Hardware einen
Gegenentwurf zum Modell des Geistigen Eigentums dar. Durch Open Source wird Wissen zu
einem öffentlichen Gut (s. Transfermodell), wohingegen geistige Eigentumsrechte andere
Personen ausschließen.
Der Schutz des geistigen Eigentums erscheint heute obligatorisch, obwohl es sich um ein
relativ junges Werkzeug handelt. In Europa setzte sich der Schutz des immateriellen Gutes des
Wissens erst im Laufe des 19. Jahrhunderts umfassend durch (Westinghouse in Rockman,
2004, S. 57). Davor blieben Wissen und Information meist ungeschützt.
In Deutschland wurde erst 1877 ein einheitliches Patentrecht gegen zum Teil erheblichen
Widerstand eingeführt. Bereits 1863 sprach sich der „6. Kongreß deutscher Volkswirthe“
gegen die Einführung von Patenten aus:
„In Erwägung, daß Patente den Fortschritt der Erfindung nicht begünstigen, vielmehr
deren Zustandekommen erschweren, daß sie die rasche allgemeine Anwendung nützlicher
Erfindungen hemmen, daß sie die den Erfindern selbst im Ganzen mehr Nachtheil als
Vortheil bringen und daher eine höchst trügerische Form der Belohnung sind, beschließt
der Kongreß deutscher Volkswirthe zu erklären: dass Erfindungspatente dem Gemeinwohl
schädlich sind“
(vgl. Kurz, 2000, S.354)
Urheberrechte entstanden in Frankreich (droit d'auteur) und England (Copyright) im
ausgehenden 18. Jahrhundert (Löhr, 2010, S. 43). In Preußen galt ein Urheberrecht ab 1837
welches im Zuge der Reichsgründung 1871 einheitlich auf den deutschen Raum ausgedehnt
wurde (Löhr, 2010, S. 44). Die Abschnitte 5.2.2. und 5.2.3. gehen auf die Grenzen dieser
Schutzmodelle ein.
4.2.1
Der Zweck geistigen Eigentums
Der Schutz geistigen Eigentums ist vielfältig – Patente schützen technische Innovationen, das
58
Urheberrecht literarische, wissenschaftliche oder künstlerische Werke. Daneben existieren
Schutzrechte für Namen, Marken, Produktdesign und sogar für geografische Herkunftsangaben.
Der Schutz des geistigen Eigentums dient dem Zweck, die generelle Nachahmungsfreiheit für
bestimmt Fälle zu beschränken.
Innovationen sind in der Regel mit hohen Entwicklungskosten verbunden. Wären
Nachahmungen von Innovationen gestattet, wäre der Anreiz höher, eine fremde Innovation
nachzuahmen, als eine eigene zu entwickeln, so dass in Folge Investitionen in die
Entwicklung weiterer Innovation zu sinken drohen. Innovationen stellen wegen des
möglichen Fortschritts einen gesellschaftlichen Gewinn dar, so dass eine Gesellschaft daran
interessiert ist, auch zukünftig Innovationen hervorzubringen.
Als Investitionsanreiz werden durch den Staat für eine bestimmte Zeit Nachahmungen durch
Dritte nicht gestattet, so dass der Entwickler als Monopolist auf dem Markt agieren kann.
Dies gibt ihm die Möglichkeit, die getätigten Investitionen gegenzufinanzieren, so dass in der
Gesamtbetrachtung der Schutz des geistigen Eigentums eine Art Belohnung für die Innovation
darstellt.
4.2.2
Dilemma der Informationsökonomie
Bei Wissen und Information handelt es sich um immaterielle Güter. Finden sie in einer
digitalen Repräsentation ihren Ausdruck, sind sie wie Software verlustfrei und nahezu
kostenlos reproduzierbar (vgl. auch Abschnitt 2.2), weil die Grenzkosten ihrer Produktion
nahezu Null betragen.
Aus gesellschaftsökonomischer Sicht sollte der Preis eines Gutes dem Wert seiner
Grenzkosten entsprechen, was in einer Marktsituation unter funktionierendem Wettbewerb
auch erreicht wird. Liegt der Preis eines Gutes nämlich über seinen Grenzkosten, wird ein
Konkurrent das gleiche Produkt auch zu einem günstigeren Preis noch rentabel auf dem Markt
anbieten können. Nähert sich der Preis eines Gutes seinen Grenzkosten nicht an, etwa weil ein
Wettbewerb durch ein Monopol verhindert wird, zahlt der Konsument einen zu hohen Preis,
was eine Senkung der gesellschaftlichen Wohlfahrt zur Folge hätte (vgl. Samuelson und
Nordhaus, 2007, S.289).
Hieraus ergibt sich nun ein Dilemma bei immateriellen Gütern. Obwohl immaterielle Güter
aufgrund ihrer Grenzkosten kostenlos angeboten werden müssten, können durch ihre
Produktion hohe Kosten entstanden sein, z.B. durch Forschung und Entwicklung. Der
Produzent kann den Wert seiner Produktentwicklung dann nicht mehr abschöpfen (der Wert
59
ist nicht internalisierbar (vgl. Samuelson, Nordhaus, 2007, S. 284)). In der Folge würde der
Anreiz in zukünftige Innovationen sinken, insbesondere dann, wenn der Innovationsprozess
mit hohen Kosten verbunden wäre.
Die soziale Rentabilität einer Erfindung ist jedoch in der Regel höher, als der internalisierbare
private Gewinn (vgl. Samuelson, Nordhaus, 2007, S.284). Die Gesellschaft soll von der
Produktion neuen Wissens profitieren, weshalb die sozialen Kosten, die durch die Gewährung
der temporären Monopole entstehen, relativiert werden können. Auch die Subventionierung
von Forschung und Bildung durch öffentliche Gelder folgt der Intention, eine höhere soziale
Rentabilität durch neue Innovation zu schaffen.
Hier tritt nun ein zusätzliches Dilemma ein. Da Innovation immer auf bereits bestehendem
Wissen beruht, nimmt das Innovationspotential mit der Stärke der Schutzmechanismen wieder
ab (vgl. hierzu Benkler, 2007, S.38). Der Schutzmechanismus besteht darin, Wissen in
stärkerem Maße wirtschaftlich verwerten zu können. Wird für die Schaffung von
Innovationen bereits bestehendes Wissen benötigt, und ist dieses Wissen geschützt, so
erhöhen sich die Kosten für Innovationen durch stärkere Schutzmechanismen zusätzlich.
Dieses zweite Dilemma mündet wieder im ersten. Stärkere Schutzmechanismen erhöhen die
Produktionskosten von Wissen, und führen so zu einem noch stärkeren Missverhältnis
zwischen Produktions- und Grenzkosten.
Zusammenfassend ist festzuhalten, dass Mechanismen zum Schutze geistigen Eigentums,
obwohl sie auf den ersten Blick eine Reduzierung der sozialen Wohlfahrt verursachen, eine
Berechtigung finden, weil sie einen Anreiz schaffen, mehr Innovationen zu produzieren. Der
soziale Gewinn durch Innovationen liegt höher, als der durch sie erzielbare private Gewinn.
Auf den zweiten Blick ist aber festzustellen, dass die gleichen Mechanismen dazu führen
können, dass das Innovationspotential wieder abnimmt, weil die Kosten für Innovationen
durch geistige Eigentumsrechte steigen, und die ursprüngliche Situation weiter verschärft
wird.
Lässt ein Unternehmen geschütztes Wissen in seinen Innovationsprozess einfließen, entstehen
ihm dadurch zusätzliche Transaktionskosten. Mit Transaktionskosten sind in diesem
Zusammenhang Kosten gemeint, die der Innovator aufbringen muss, um einen
Nutzungsvertrag zwischen ihm und dem Eigentümer des Wissens zustande kommen zu
lassen. Ferner entstehen auf Seiten des Staates Kosten zur Unterhaltung eines Apparates, der
das rechtliche Gefüge zum Schutze geistigen Eigentums erstellt und kontrolliert. Diese
Kosten müssen von der Gemeinschaft gezahlt werden.
60
4.2.3
Tragedy of the Anticommons
Der Begriff Tragedy of the Anticommons stammt aus einem Aufsatz von Michael Heller
(1998) und ist eine Umkehrung Hardins Begriff der Tragedy of the Commons (Tragik der
Allmende)(Hardin, 1968). Er beschreibt die Situation, in der eine Innovation nicht genutzt
werden kann, weil das ihr zugrunde liegende Wissen verschiedenen Eigentümer gehört. Jeder
der Eigentümer kann andere von der Nutzung der Innovation ausschließen, aber keiner
verfügt über das Recht, die Innovation tatsächlich zu nutzen.
Ein anschauliches Beispiel für diese Tragik liefert von Hippel (2006, S.114) mit der fiktiven
Erfindung eines Schaukelstuhls. Wenn Person A einen Schaukelstuhl erfindet, indem er
Wippen an einen Stuhl montiert, dessen Patent durch Person B gehalten wird, und Person A
lässt sich die Erfindung des Schaukelstuhls ebenfalls patentieren, so kann der Schaukelstuhl
nur dann produziert werden, wenn sich beide beteiligten Personen über die Lizenzgebühren
einig werden. Findet aber keine Einigung zwischen Patentinhabern statt, bleibt der Stuhl
ungebaut.
Von Hippel (2006, S.114) macht hierfür das Wesen des Patentrechts verantwortlich. Das
Patentrecht sei so konstruiert, dass es den Inhaber eines Patents nur ermächtige, andere von
der Nutzung einer technischen Innovation auszuschließen. Die tatsächliche Nutzung einer
Innovation könne durch ein Patent jedoch nicht garantiert werden.
Die Verhinderung einer Innovation bedeute aus volkswirtschaftlicher Sicht eine Verringerung
der sozialen Wohlfahrt (vgl. Samuelson, Nordhaus, 2007, S.284). Die Innovation kommt aber
nur dann zustande, wenn sich alle beteiligten Parteien über die Lizenzgebühren einig werden.
Der Prozess der Lizenzierung ist in der Praxis mit Transaktionskosten verbunden, die den
Innovationsprozess dann zusätzlich verteuern. Je stärker die Fragmentierung einer Innovation
durch bereits geschütztes Wissen ist, desto unwahrscheinlicher wird dadurch die Realisierung
eines daraus resultierenden Produkts (vgl. Heller und Eisenberg, 1998).
Heller und Eisenberg (1998) befürchten ein hohes Risiko einer Tragedy of the Anticommons
in der biomedizinischen Forschung in den USA. Große Teile der Forschungsergebnisse sind
in privater Hand, insbesondere, weil Universitäten in der Vergangenheit dazu ermuntert
wurden, ihre durch öffentliche Forschung erlangten Erkenntnisse zu patentieren, um sie
anschließend in den privaten Sektor transferieren zu können. Die hohe Fragmentierung bspw.
biomedizinischen Wissens durch Patente, verbunden mit hohen Transaktionskosten, könne
dazu führen, dass ein innovatives Medikament aufgrund zu hoher Kosten nicht realisiert
werden kann.
61
Die starke Verwebung sich überlappender Patente wird auch als patent thicket (Patentdickicht)
bezeichnet. Ein Patentdickicht kann gezielt durch ein Unternehmen aufgebaut worden sein,
indem es um eine zentrale Innovation errichtet wurde. Konkurrierende Firmen können
dadurch von einer Forschung auf diesem Bereich abgehalten werden (vgl. v. Hippel, 2006, S.
114).
Das Beispiel der Tragedy of the Anticommons zeigt, dass die eigentliche Absicht des
Patentrechts, private Investitionen in Forschung und Entwicklung anzuregen, um
Innovationen zu fördern, in der Praxis leicht umgedreht werden kann. Das Mittel Schutz des
geistigen Eigentums kann in diesen Fällen als Werkzeug missbraucht werden, um
Innovationen zu verhindern.
Bessen und Hunt (2004, S. 28) zeigen in einer Untersuchung, dass Softwarefirmen, die ihr
Budget für den Schutz ihres geistigen Eigentums erhöhten, ihr Budget für Forschung und
Entwicklung gleichzeitig reduzierten, so dass daraus geschlossen werden kann, dass das
Interesse, weitere Innovationen zu schaffen, abnimmt, wenn bereits entwickelte Innovationen
durch geeignete Schutzmechanismen wirtschaftlich genutzt werden können.
Die vorangegangenen Beispiele legen den Schluss nahe, dass mit der Stärke des Schutzes, die
das Patentrecht dem Inhaber eines Patents einräumt, um die Nutzung einer Innovation durch
andere zu verhindern, die Gefahr einer Mittel-Zweck-Umkehr entsteht. Das Ziel, innovative
Produkte anzubieten, rückt zugunsten einer rein strategischen Positionierung am Markt in den
Hintergrund.
Prominentes Beispiel für dieses Verhalten ist der Softwarehersteller Caldera der nach der
Übernahme der Firma Santa Cruz Operation eine große Anzahl von Rechten am UNIX-Code
besaß. Caldera verklagte – nach einer Umbenennung in SCO Group37– Unternehmen, die an
der Entwicklung des Linux Kernels beteiligt waren wegen der Verletzung von
Urheberrechten. Die Entwicklung eigener Produkte rückte infolgedessen in den Hintergrund.
Dem gegenüber steht, dass sich Patente oftmals als ineffektiv erweisen. Ein Patent kann nicht
garantieren, dass jemals Gelder für getätigte Investitionen zurückfließen, ist aber selbst mit
Aufwand und weiteren Kosten verbunden. Von Hippel (2006, S. 84 f.) sieht darin einen
Grund, weshalb sich Patente für kleinere und mittlere Unternehmen oftmals als unpraktisch
erweisen. Von Hippel stützt diese Aussage mit einer Untersuchung aus dem Jahr 1987, in der
650 Leiter von Forschungs- und Entwicklungsabteilungen angaben, Patente als ineffizient zu
empfinden.
37 http://www.sco.com, letzter Aufruf: 17.12.2010
62
Die Bewahrung von Firmengeheimnissen sieht von Hippel dabei ebenfalls als eine wenig
effektive Strategie an, einen Innovationsvorsprung am Markt zu garantieren, denn mögliche
Konkurrenten würden wegen ihres ähnlichen Wissenstandes schnell in der Lage sein, die
Innovation einzuholen. Die Veröffentlichung gewonnenen Wissens erweise sich dann
schließlich als einzige praktische Lösung. Dem Innovator entsteht dadurch in der Regel kein
großer Verlust, aber im Gegenzug kann er durch die mit der Veröffentlichung verbundenen
Nebeneffekte profitieren.
4.2.4
Monopol und bestreitbare Märkte
Bei einem Monopol handelt es sich um eine Marktsituation, in der für ein ökonomisches Gut
nur ein Anbieter existiert (Siebert, Lorz, 2007, S. 134).
Um ein natürliches Monopol handelt es sich, wenn nur ein Unternehmen den Markt
kostendeckend bedienen kann (Siebert, Lorz, 2007, S. 137). Sie treten häufig dann auf, wenn
die Produktion eines Gutes bei geringen Produktionskosten mit hohen Fixkosten verbunden
ist, und Markteintrittsbarrieren für neue Marktteilnehmer dadurch sehr hoch sind. Beispiele
hierfür sind Unternehmen im Bereich der Wasser- oder Energieversorgung oder
Telekommunikationsunternehmen. Sie müssen eine aufwändige Infrastruktur bereithalten, um
ihr Produkt anbieten zu können.
Bei einem Quasi-Monopol existieren zwar mehrere Anbieter für ein Produkt, doch aufgrund
starker Wettbewerbsvorteile nimmt ein Hersteller eine marktbeherrschende Rolle ein.
Vorstellbar für so einen Wettbewerbsvorteil wäre zum Beispiel die Nutzung eines De-factoStandards.
Natürliche Monopole sind deswegen problematisch, weil Monopolisten aufgrund eines
fehlenden Konkurrenzdrucks wenig innovationsfreudig und oft inneffektiv sind. Da ihre
Produkte auf jeden Fall am Markt abgesetzt werden können, besteht keine Notwendigkeit,
Produkt oder Produktionsprozess zu optimieren. Investitionen würden aus unternehmerischer
Sicht keinen Vorteil bringen, weil ein Verbesserung des Produkts nicht unbedingt einen
erhöhten Absatz zur Folge hätte. Womöglich würden Investitionen den zu erwartenden
Gewinn sogar reduzieren.
Aufgrund fehlender Konkurrenten können Monopolisten den Preis ihrer Produkte nahezu frei
bestimmen. Der Preis des Gutes liegt folgerichtig darum häufig über den Grenzkosten der
Produktion.
Liegt der Preis eines Gutes aufgrund eines Monopols über seinen Grenzkosten, spricht man
aus volkswirtschaftlicher Sicht von einem Wohlfahrtsverlust (engl. Deadweight-Loss) (vgl.
63
Samuelson, Nordhaus, 2007, S. 289 f.). Die Konsumenten sind gezwungen, für ein Produkt
einen höheren Preis zu zahlen, als sie es in einem Polypol, also bei mehreren Anbietern im
Wettbewerb, müssten. Da mit der Höhe des Preises gleichzeitig der Absatz eines Produktes
am Markt sinkt, entsteht eine Unterversorgung auf Seiten der Konsumenten.
Dieser durch Monopole verursachte Wohlfahrtsverlust begründet die marktregulierenden
Eingriffe, die die Gesellschaft durch das Kartellrecht vornehmen kann, um eine dominierende
Stellung eines Unternehmens am Markt zu verhindern.
Die Theorie der bestreitbaren Märkte sagt aus, dass Monopole keiner Regulierung bedürfen,
sofern noch ein potentieller Wettbewerb möglich sei. Diese Situation ist dann gegeben, wenn
ein freier Markteintritt durch potentielle Konkurrenten möglich ist (Siebert, Lorz, 2007, S.
147).
Diese
möglichen
Konkurrenten
zwingen
den
Monopolisten
dann
ebenfalls
zu
wettbewerblichem Verhalten. Setzt ein Monopolist den Preis seines Produkts zu hoch an,
würde er potentielle Konkurrenten zu einem Markteintritt reizen, weil diese das Produkt
günstiger anbieten und dennoch Gewinne erzielen könnten.
Ein Monopol muss aber nicht zwangsläufig schlecht sein und kann für Konsumenten
durchaus Vorteile haben. Bei einem Polypol wird der Markt für eine technische Lösung unter
mehreren Konkurrenten aufgeteilt. Sind die konkurrierenden Produkte untereinander
inkompatibel, folgt daraus ein verringertes Potential an Interoperabilität unter den
Konsumenten. Ein Monopol, das durch seine marktdominierende Position einen De-factoStandard setzt, kann im Gegensatz dazu für die Gesellschaft von höherem Wert sein
(vergleiche hierzu auch die Erklärungen zu Standards und Netzwerkeffekten in Abschnitt
5.3.1.).
4.3
Positive Aspekte des Open Source Modells
Die Akteure des freien Marktes lassen sich einfach klassifizieren – es gibt Produzenten und
Konsumenten. Wichtiges Merkmal des Produzenten ist, dass er über die Produktionsmittel
verfügt, die ihn die Herstellung eines Gutes ermöglichen. Der Konsument nutzt diese Güter.
Inwieweit diese Unterscheidung in einem Markt, der sich den Methoden des Open Source
bedient, getroffen werden kann, soll hier untersucht werden. Das Produktionsmittel Wissen ist
hier ein öffentliches Gut und kann von jedem genutzt werden, wobei die Grenzen zwischen
Konsumenten und Produzenten verschwimmen, weil jedes Individuum beide Rollen
übernehmen darf.
64
Für Open Hardware Projekte gilt dieser Aspekt sogar noch stärker als bei Open Source
Software Projekten. Die Produktion eines Computerprogramms aus seinem Quellcode ist
trivial. Einziges weiteres Produktionsmittel, dass neben dem Quellcode notwendigerweise
benötigt wird, ist der Computer. Der Computer wird dabei sowohl für die Produktion, als auch
für den Konsum benötigt.
Die Produktion von Hardware ist mit hohem Aufwand verbunden, da Rohstoffe und
Werkzeuge eingesetzt werden. Mit der Komplexität der Hardware steigt auch der
Produktionsaufwand und ist unter Umständen nur noch unter industriellen Bedingungen
realisierbar. Die Herstellung von Mikroprozessoren, wie sie zum durch die im OpenSPARC
veröffentlichten Informationen möglich wäre, können bspw. nur von Spezialisten
übernommen werden.
Jede Person (auch jedes Unternehmen) hat bei einem Produkt, das auf einem offenen
Quellcode beruht, die Freiheit zu entscheiden, ob sie es über einen Fremdhersteller (wenn
dieser existiert) bezieht oder ob sie das Produkt selbst produziert. Wird mit dem Produkt
eigener Bedarf gestillt, agiert die Person als Konsument. Produziert die Person das Produkt
selbständig und distribuiert es zusätzlich, agiert die Person als Produzent und Konsument
zugleich. Produziert eine Person das Produkt, um den Bedarf Dritter zu stillen, übernimmt sie
die Rolle eines reinen Produzenten.
4.3.1
4.3.1.1
Markteffekte von Open Source Produkten
Standards und Kompatibilität
Ein Standard bezeichnet eine allgemein anerkannte Übereinkunft darüber, wie etwas
hergestellt oder durchgeführt wird. Standards werden einerseits durch Regeln oder Normen
bestimmt und von nationalen oder internationalen Organisationen festgelegt 38.
Die Verwendung einheitlicher Standards erhöht die Kompatibilität von Produkten
konkurrierender Hersteller. Aus gesellschaftlicher Sicht ist die Kompatibilität technischer
Lösungen erstrebenswert, weil sie die Interaktion von Individuen, im Bereich dieser
technischen Lösung, ermöglicht. Aus einem höheren Grad an Kompatibilität folgt ein
stärkeres Potential zur Vernetzung untereinander. Inkompatibilität führt entsprechend zu
parallelen und untereinander nicht interagierenden Netzwerken. Offene Standards reduzieren
die Gefahr einer Zersplitterung des Marktes.
Andererseits entwickeln sich Regeln und Normen aus der praktischen Anwendungen heraus
38 Bspw. DIN (Deutsches Institut für Normung) in Deutschland oder ISO (International Organization for
Standardization) im internationalen Bereich.
65
Erreichen sie dabei eine hinreichende Marktdurchdringung, spricht man von De-factoStandards (vgl. Mundhenke, 2007, S. 168 ff.).
Die Durchsetzung von De-facto-Standards erfolgt durch die am Markt beteiligten
Produzenten entweder kooperativ oder kompetitiv. Bei einer Kooperation einigen sich die
Teilnehmer auf eine gemeinsame und zukünftig zu nutzende Lösung. In der kompetitiven
Standardfindung setzt sich eine technische Lösung gegenüber anderen im direkten
Wettbewerb durch. Setzt sich dabei ein geschlossener Standard durch, droht eine dominante
Marktposition des Gewinners nach dem Prinzip „The winner takes it all“ (vgl. zum Ganzen
Mundhenke, 2007, S.26).
Verfügt ein Unternehmen schon über ein eigenes, ausreichend großes Netzwerk, sinkt der
Nutzen durch die Verwendung gemeinsamer Standards. Bei einer marktbeherrschenden
Position wirkt ein geschlossener De-facto-Standard wie eine Markteintrittsbarriere, wodurch
mögliche Konkurrenten vom Markteintritt abgehalten werden können.
Open Source Projekte können die Durchsetzung gemeinsamer Standards fördern, indem sie
eine kooperative Plattform bieten, an der alle interessierten Protagonisten an einer
gemeinsamen Schnittstelle teilnehmen können. Ein Unternehmer der ein zum Open Source
Projekt konkurrierendes Produkt anbietet hat die Möglichkeit, sein Produkt an die offenen
Schnittstellen des Open Source Produkt anzupassen. Alternativ kann er Wissen in das Open
Source Projekt einfliessen lassen, so dass das Open Source Produkt mit seinem Produkt
interagieren kann. Dabei handelt es sich um die Offenlegung von Schnittstellen durch ein
Unternehmen.
Ein Open Source Projekt ist allerdings kein Garant für die Durchsetzung eines Standards auf
dem Markt, sondern kann eher als eine Einladung an alle beteiligten Protagonisten verstanden
werden. Die tatsächliche Erarbeitung ist dabei vom Willen der Marktteilnehmer zu
gemeinsamen Schnittstellen abhängig.
Beteiligt sich ein Unternehmen an einem Open Source Projekt, welches das Potential besitzt,
einen De-facto-Standard zu etablieren, so kann das Unternehmen aktiv am Standardisierungsprozess mitwirken. Insbesondere bei Basistechnologien kann ein Unternehmen die
Marktposition seiner Produkte so verbessern.
4.3.1.2
Netzwerkeffekt
Unter einem Netzwerkeffekt versteht man eine positive Rückkopplung auf Nutzen und Wert
eines Produkts, wenn die Anzahl seiner Nutzer steigt. Nach erreichen einer kritischen Masse,
wächst die Anzahl der Nutzer exponentiell. Man unterscheidet zwischen direkten und
66
indirekten Netzwerkeffekten (vgl. zum Ganzen Shuen, 2008, S. 31 ff.).
Bei einem direkten Netzwerkeffekt entsteht der Mehrwert für einen Nutzer an einem Gut
allein aus dessen Verbreitung (Shuen, 2008, S. 32). Ein Beispiel hierfür ist das Telefon: je
stärker das Kommunikationsmedium Telefon verbreitet ist, desto mehr Personen kann ein
Einzelner mit seinem Gerät erreichen. Der Nutzen des Geräts steigt mit den sich im Umlauf
befindlichen Geräten, und damit auch der individuelle Wert des Gerätes für seinen jeweiligen
Eigentümer.
Von einem indirekten Netzwerkeffekt spricht man, wenn der Mehrwert eines Gutes nicht
allein auf seine Verbreitung zurückzuführen ist, sondern auch auf das Angebot
komplementärer Produkte und Dienstleistungen (Shuen, 2008, S. 32). Komplementäre
Produkte werden durch offene und gemeinsame Schnittstellen begünstigt. Je größer dieses
Angebot ist, desto höher ist der Nutzen eines Gutes. In der Regel bedingen sich direkte und
indirekte Netzwerkeffekte gegenseitig.
Ein technisch schlechteres Produkt kann von der Nachfrageseite her einem technisch
überlegenerem Produkt durchaus vorgezogen werden, wenn sein Gesamtnutzen durch
indirekte Netzwerkeffekte höher bewertet wird. Anschauliches Beispiel ist hierfür Apples
iPhone39, das von der Fachpresse konkurrierenden Geräten oft als unterlegen bewertet wurde,
wenn allein die technischen Werte betrachtet wurden. Parallel zum iPhone entwickelte Apple
seinen App Store, ein Online Marktplatz für iPhone Programme, den sogenannten Apps, und
stellte Softwareentwicklern eine komfortable Entwicklungsumgebung zur Erstellung eigener
Apps bereit.
Mit steigender Anzahl dieser Apps nahm der Funktionsumfang des iPhones zu und überstieg
aus Sicht des Kunden den Wert eines vielleicht technisch überlegeneren, aber aufgrund
fehlender Zusatzprogramme weniger funktionalen Konkurrenzprodukts.
Dass es sich beim iPhone um einen indirekten Netzwerkeffekt handelt wird deutlich, weil es
zu konkurrierenden Produkten kompatibel ist, denn Telefonate und die Versendung von SMS
und E-Mails zu fremden Geräten bleiben möglich. Der Nutzer profitiert darum nicht direkt
von der Verbreitung des iPhones, sondern vom Angebot an komplementären Gütern, nämlich
den Apps.
Apples App Store zeigt, dass Netzwerkeffekte als Markteintrittsbarrieren wirken können. Weil
die angebotenen Programme ausschließlich auf dem iPhone anwendbar sind, verhält sich der
App Store wie ein geschlossener Standard. Für weitere Anbieter ist es in diesem Fall
39http://www.apple.com/iphone/, 25.11.2010
67
schwierig, ein Produkt in den Markt einzubringen, wenn bereits starke geschlossene
Netzwerke bestehen (vgl. auch Mundhenke, 2007, S.29).
Der App Store profitiert hier von einem direkten Netzwerkeffekt. Viele Entwickler entwickeln
ihre Programme primär für den App Store und das iPhone, weil durch die starke Verbreitung
des iPhones, eine höheres Nachfragepotential, und dadurch auch höhere Gewinne, zu
erwarten sind. Der Aufwand, das Programm zusätzlich für eines der konkurrierenden
Netzwerke zu programmieren, wird dann häufig nicht mehr in Kauf genommen.
Untereinander konkurrierende Marktteilnehmer können dabei durchaus von einem
gemeinsamen Netzwerkeffekt profitieren. Vorraussetzung hierfür ist die Kompatibilität der
konkurrierenden Produkte, die durch die gemeinsame Nutzung der Standards erreicht wird.
Im Beispiel der Telefone profitieren Telefonhersteller vom direkten Netzwerkeffekt der sich
bereits im Umlauf befindlichen Telefone. Dabei ist es unerheblich, ob es sich bei diesen
Telefonen um eigene Produkte oder um Konkurrenzprodukte handelt. Die Anwesenheit eines
direkten Konkurrenten erweist sich dann sogar als Vorteil, wenn sie einen gemeinsamen
nutzbaren Netzwerkeffekt anregt, der letztlich einem höheren Absatzpotential der Produkte
beider Hersteller dient.
4.3.1.3
Pfadabhängigkeit und Lock-in-Effekt
Die Pfadabhängigkeit beschreibt eine Situation, bei der die in Frage kommenden Lösungen in
einem Entscheidungsprozess von in der Vergangenheit getroffenen Entscheidungen bestimmt
werden (vgl. Ackermann, 2001, S. 57 ff.). Möglicherweise sind die Gründe der vorangegangenen Entscheidungen in der aktuellen Situation nicht mehr relevant.
Ist ein Pfadwechsel nicht mehr möglich, weil die Wechselkosten zu hoch sind, spricht man
von einem Lock-in (Peters, 2010, S. 50). Ein Unternehmen kann durch einen Lock-in im
ungünstigsten Fall zu unrentablem Verhalten gezwungen sein.
Der Lock-in-Effekt wird von auch Unternehmen gezielt angewendet, um Kunden an ihre
Produkte oder Services zu binden. Beispielhaft hierfür ist die Taktik von Druckerherstellern,
die ihre Drucker zu sehr geringen Preisen anbieten. Da jeder Hersteller einen eigenen
Standard für die benötigten Patronen entwickelt hat, ist der Kunde gezwungen, in Zukunft die
– oftmals sehr teuren – Patronen des Druckerherstellers zu kaufen.
Die Verwendung von Open Source Produkten kann die Gefahr anbieterspezifischer Lock-ins
reduzieren, weil der Quellcode des Produkts offen ist und uneingeschränkt genutzt werden
kann. Sollte ein Anbieter eines Open Source Produkts eine benötigte Anpassung oder
Weiterentwicklung nicht leisten können, so steht es dem Nutzer frei, diese selber
68
vorzunehmen oder von einem Dritten vornehmen zu lassen. Auf Software trifft diese
Abhängigkeit
von einem
Hersteller viel stärker
zu, da
eine Anpassung
eines
Computerprogramms, wenn man nicht über seinen Quellcode verfügt, nahezu unmöglich ist
(vgl. auch Mundhenke, 2007, S.97).
Open Source Produkte helfen durch freien Quellcode und offene Schnittstellen die
Abhängigkeit zu einem Hersteller zu reduzieren, doch können auch sie das Auftreten von
Lock-in Effekten nicht verhindern. Auch bei der Nutzung von Open Source Produkten
entstehen Kosten, die einen späteren Wechsel unrentabel machen könnten.
Für Open Source Produkte fallen im Vergleich zu proprietären Produkten zwar keine
Lizenzgebühren an, doch in der Regel entstehen Kosten bei ihrer Inbetriebnahme und späterer
Wartung. Man spricht hier von „Total Cost of Ownership“ (Brügge et al., 2004, S. 116 ff.).
4.3.2
Effekte auf Unternehmen
Das Geschäftsmodell konventioneller Unternehmen besteht gewöhnlich darin, durch
Forschung und Entwicklung gewonnenes Wissen in ein Produkt einfließen zu lassen, welches
auf dem freien Markt angeboten wird. Um seine Marktposition gegenüber Mitbewerbern zu
stärken, wird das Unternehmen versuchen, gewonnenes Wissen durch Patente, Urheberrechte
oder Geschäftsgeheimnisse schützen lassen, um Nachahmungen durch Konkurrenten zu
verhindern. Der Erfolg des Produkts führt zu Gewinnen, wobei getätigte Investitionen
zurückgewonnen werden.
Auf den ersten Blick erscheint eine Zusammenarbeit zwischen Unternehmen und Open
Source Projekten daher kaum vorstellbar. Zu unterschiedlich sind ihre grundsätzlichen
Zielsetzungen. Ein wirtschaftlich handelndes Unternehmen entwickelt Produkte, die auf dem
freien Markt finanziell verwertet werden müssen; Open Source Projekte aber entwickeln
öffentliche Güter, von deren Nutzung niemand ausgeschlossen werden soll und kann.
In der Vergangenheit standen sich manche Protagonisten beider Lager geradezu feindlich
gegenüber. Richard Stallman versteht Free Software nicht als eine alternative Form der
Softwareentwicklung, sondern als eine politisch ethische Alternative und kritisiert dabei auch
den als zu industrienah empfunden Kurs der Open Source Initiative.
Bill Gates hingegen beschwerte sich bereits 1976 in seinem „Open Letter to Hobbyists“
(Blinkenlights, n.d.) über das Tauschen von Software, und bezeichnete ihn als Diebstahl. In
jüngerer Vergangenheit benannte Gates in einem Interview Personen, die sich für die
Abschaffung des Rechts auf geistiges Eigentum einsetzen als moderne Kommunisten
(„modern-day sort of communists“ (CNET, 2005)). Das ehemalige SAP Vorstandsmitglied
69
Shai Agassie bezeichnete Open Source als „Intellectual property socialism“ (ZDNet, 2005),
Steven Ballmer, seit 2000 CEO von Microsoft, benannte Linux und die GPL als
Krebsgeschwür („Linux is a cancer that attaches itself in an intellectual property sense to
everything it touches“ (Linux Online, 2001)).
Dass sich eine Vielzahl von Unternehmen in der Vergangenheit an Open Source Projekten
beteiligt oder diese gar initiiert hat, zeigt, dass wirtschaftlich handelnde Unternehmen
durchaus an Open Source Produkten interessiert sind und Open Source Projekte zum
wirtschaftlichen Erfolg eines Unternehmens beitragen können.
Ein typisches Modell für eine Zusammenarbeit ist die Kooperation zwischen einem
Hardwarehersteller und einem Open Source Software Projekt. Prominentes Beispiel hierfür ist
das Unternehmen IBM, welches ihre Server auch mit dem Betriebssystem Linux ausliefert.
Seit 1998 unterstützt IBM die Entwicklung des Linux Kernels auf verschiedenen Ebenen
(IBM, n.d.), indem finanzielle Mittel sowie Beiträge firmeninterner Programmierer bereit
gestellt werden und indem Software unter Open Source Lizenzen veröffentlicht wird.
Hardware und Betriebssystem verhalten sich zueinander komplementär – sie ergänzen sich in
ihrem Nutzen. Der Nutzen des einen Teils steigt durch Verknüpfung mit dem anderen Teil.
IBM erhöht durch die Verwendung von Linux den Nutzen seiner Server für seine Kunden.
Diese sparen die Kosten für ein kommerzielles Betriebssystem und verfügen aufgrund der
Offenheit des Codes über mehr Kontrolle über Software und Hardware.
Von Weiterentwicklungen im Linux Projekt können Nutzer Linux betriebener IBM Server
direkt profitieren, auch wenn diese gar nicht durch IBM geleistet wurden. Durch ein eigenes
Engagement in Open Source Projekten kann IBM Nutzen und Wert seiner Produkte zusätzlich
erhöhen.
IBM ist ein Beispiel dafür, wie vielfältig das Engagement von Unternehmen für Open Source
Projekten – unterteilt in die wesentlichen Aspekte – aussehen könnte:
•
Patronage, das Unternehmen unterstützt ein Projekt finanziell oder durch das
Bereitstellen von Infrastruktur, wie z.B. Räume und Technik
•
Entwicklung, das Unternehmen beteiligt sich aktiv mit eigenen Mitarbeitern an der
Entwicklung.
•
Veröffentlichung, das Unternehmen veröffentlicht eigenen Source Code.
•
Spenden
70
Die Unterstützung von Open Hardware Projekten kann in den gleichen Kategorien erfolgen.
4.3.2.1
Komplementärgüter
Als komplementäre Güter bezeichnet man sich ergänzende Güter. Unterschieden wird dabei
zwischen vollkommenen und unvollkommenen Komplementen (Pindyck, Rubinfeld, 2009,
S. 54).
Vollkommene Komplemente ergänzen sich notwendigerweise und werden zusammen
nachgefragt, wohingegen unvollkommene Komplemente auch einzeln genutzt und
nachgefragt werden. Hard- und Software sind beispielsweise vollkommene Komplemente.
Software kann ohne Hardware nicht ausgeführt werden und Hardware erhält erst durch den
Einsatz von Software ihre Funktion. Wiener Würstchen und Senf sind hingegen
unvollkommene Komplemente – ein Wiener Würstchen kann auch ohne Senf gegessen
werden und Senf findet in der Küche noch eine Reihe anderer Einsatzmöglichkeiten.
Die Stärke der komplementären Rückkopplung kann innerhalb komplementärer Paare
durchaus asymmetrisch ausfallen. Vermutlich würde der Verbrauch von mehr Wiener
Würstchen gleichzeitig den Verbrauch von Senf erhöhen, wohingegen mehr Senf nicht auch
zwingender Weise eine Steigerung im Verzehr von Wiener Würstchen zur Folge hätte. Weil
ein Senfhersteller aber direkt vom Würstchenverbrauch betroffen ist, ist er an ihrem starken
Verzehr interessiert. Wirbt ein Senfhersteller für den Konsum von Wiener Würstchen,
unterstützt er gleichzeitig den Verkauf seines Produkts.
Der Zusammenhang zwischen indirekten Netzwerkeffekten durch komplementäre Produkte
und die fördernde Wirkung von Open Source Projekten auf Standards wurde in den vorigen
Abschnitten erörtert. Ein wirtschaftlich denkendes Unternehmen verfolgt das Ziel, den Absatz
seines Produkts zu erhöhen.
Das Beispiel IBM zeigt, wie ein Unternehmen die komplementäre Beziehung zu einem Open
Source Projekt nutzen kann, um den Wert seines Produkt zu steigern. Dazu muss das
Unternehmen sein Produkt soweit ändern, dass es Kompatibilität zu einem bestehenden Open
Source Projekt erlaubt. Alternativ kann das Unternehmen das Open Source Projekt durch
eigenes Wissen und Engagement so erweitern, dass es mit dem eigenen Produkt kombinierbar
ist.
Durch den Transfer des Unternehmenswissens in den als öffentliches Gut wirkenden
Wissenskörper des Open Source Projekts, öffnet das Unternehmen den Zugang zu seinem
Produkt, verliert aber ein gewisses Maß an Kontrolle über sein Produkt. Der Ausschluss
anderer ist dann kaum noch möglich. Doch die sinkende Ausschließbarkeit geht mit einem
71
steigenden Einsatzspektrum des Produkts einher, welches direkt in einer größeren Zahl an
Nachfragern resultieren kann – der Absatz seines Produkt steigt.
Dadurch, dass ein Unternehmen sein Produkt gezielt als Komplement zu einem Open Source
Projekt positioniert, kann das Unternehmen die sich um das Projekt versammelte Community
als möglichen Absatzmarkt gewinnen. Die Community profitiert im Umkehrschluss davon,
dass sie das Produkt des Unternehmens als Anwendungsplattform ihres Produkts verwenden
können.
Ein ähnliches, aber nicht ganz freiwilliges Beispiel, beschreibt Sebald (2007). Die Firma
Siemens brachte 2004 eine Set-Top-Box heraus, die dafür gedacht war, digitales terrestrisches
Fernsehen (DVB-T) zu empfangen. Als Betriebssystem verwendete das Gerät eine
modifizierte Linux Version. Durch einen gerichtlichen Vergleich mit der FSF wurde Siemens
dazu gezwungen, diese spezielle Linux Version zu veröffentlichen.
Dadurch, dass sie nun auf das Betriebssystem Einfluss nehmen konnten, war es Entwicklern
aus der Linux Community möglich, das Einsatzspektrum der Set-Top-Box um Fähigkeiten zu
erweitern, die von Siemens für dieses Gerät nie vorgesehen waren (z.B. ftp-Server,
Webserver). Für Siemens bestand letztlich der unfreiwillige Vorteil darin, dass sie die
Zielgruppe ihres Produkts um diese Entwickler erweitern konnte (vgl. Sebald, 2007, S. 207
f.).
4.3.2.2
Substitutionsgüter
Als Substitutionsgüter werden Güter bezeichnet, die denselben Bedarf von Konsumenten
abdecken – ein Gut kann durch sein Substitut ersetzt werden (Pindyck, Rubinfeld, 2009, S.
54). Die Nachfrage substituierender Güter, wird direkt durch ihren Preis gesteuert (Pindyck,
Rubinfeld, 2009, S. 116). Wenn die Güter A und B Substituenten sind, und der Preis von A
steigt, so steigt die Nachfrage an Gut B. Sinkt der Preis von Gut A, sinkt die Nachfrage an
seinem Substitut.
Man unterscheidet zwischen perfekten und imperfekten Substitutionsgütern (vgl. Pindyck,
Rubinfeld, 2009, S. 115 ff.). Perfekte Substitutionsgüter können untereinander ausgetauscht
werden, ohne dass der Konsument Abstriche in der Qualität in Kauf nehmen muss (Beispiel
Softdrinks: Coca Cola und Pepsi Cola). Als imperfekte Substitutionsgüter werden Güter
bezeichnet,
die
zwar
den
selben
Zweck
erfüllen,
dabei
aber
unterschiedliche
Qualitätsmerkmale aufweisen (Beispiel Musikmedien: CD und MC).
In Abschnitt 5.3.1.2. wurde dargestellt, dass die Existenz konkurrierender Produkte im freien
Markt positiven Einfluss auf den Absatz eines Unternehmens nehmen kann, wenn dadurch ein
72
direkter Netzwerkeffekt angeregt werden kann. Vorraussetzung hierfür ist, dass die
Substituenten untereinander kompatibel sind und ihre Nutzer ein gemeinsames Netzwerk
bilden können.
Mustonen (2005) untersuchte, unter welchen Bedingungen ein Unternehmen dazu bereit ist,
ein sein Produkt substituierendes Open Source Projekt („substitute copyleft program“) zu
unterstützen. Bei einem schwachen Netzwerkeffekt auf dem Markt kann ein Unternehmen
durch die Unterstützung des Open Source Projekts profitieren. Das Unternehmen wird
versuchen eine Kompatibilität zwischen seinem Produkt und dem Open Source Projekt zu
erreichen. Dieser Effekt kann bereits bei einer kleinen Open Source Community erreicht
werden und verstärkt sich zunehmend mit ihrer Größe.
Besteht hingegen bereits ein starker Netzwerkeffekt und ist die Community des Open Source
Projekts sehr klein, wird ein Unternehmen versuchen, das konkurrierende Open Source
Projekt vom Markt fernzuhalten. Das Unternehmen wird sein Produkt aus diesem Grund zu
einem niedrigen Preis anbieten (vgl. Mustonen 2005, S.124).
4.3.2.3
Wissenstransfer und User Innovation
Bei der Überführung von Wissen in ein Open Source Projekt findet ein Wissenstransfer statt
(siehe Abschnitt 5.1.4). Der Entwickler transferiert sein durch ihn generiertes Wissen in einen
frei verfügbaren Wissenspool – das Wissen wird zu einem öffentlichen Gut. Durch diesen
Transfer geht die Möglichkeit einer exklusiven Nutzung dieses Wissens verloren.
Wird das freigegebene Wissen unter einer Copyleft Lizenz veröffentlicht, wird ein
bidirektionaler Wissensfluss festgelegt – Veränderungen und Weiterentwicklungen, die durch
Dritte vorgenommen werden, müssen wiederum veröffentlicht werden.
Die Freigabe von Wissen verhält sich dann wie eine Form des Outsourcings, ein
Auslagerungsprozess. Diese Auslagerung findet auf zwei Ebenen statt – ein Outsourcing in
Forschung und Entwicklung und ein Outsourcing der Produktion.
Lässt ein Entwickler sein Wissen in ein Open Source Projekt einfliessen, entweder durch
Initiierung eines neuen Projekts oder durch Inkorporierung in ein bestehendes Projekt, wird es
einer heterogenen und globalen Entwicklergemeinschaft zugänglich. Ein Auftrag zur
Weiterentwicklung erfolgt aber nicht. An einer Weiterentwicklung werden sich ausschließlich
Personen beteiligen, die an diesem Wissen persönlich interessiert sind. Diese Weiterentwicklungen fließen in das Projekt zurück und können auch vom ursprünglichen Entwickler
verwertet werden. Raymond begründet gerade hierin einen qualitativen Vorteil von Open
Source Software.
73
„We’re proving not only that we can do better software, but that joy is an asset.“
(Raymond, 2001, S.60)
Das Outsourcing von Produktion sowie Forschung und Entwicklung durch die
Veröffentlichung von Wissen nennt auch von Hippel (2006). Ein Unternehmen, dass eine
technische Innovation entwickelt, die für den Produktionsprozess genutzt wird, z.B. eine
Maschine, und diese Innovation im Sinne eines Open Source Projekts veröffentlicht wird,
kann dann das Unternehmen von möglichen Weiterentwicklung dieser Innovation durch die
Open Source Community profitieren.
Bei dem die Innovation beschreibenden Quellcode handelt es sich um ein öffentliches Gut.
Dritte verfügen dadurch über die Möglichkeit, das auf der Innovation beruhende Produkt
herzustellen und auf dem freien Markt anzubieten – in diesem Fall eine Maschine.
Kann eine Fremdfirma diese Maschine zu einem günstigeren Preis anbieten, als die
ursprüngliche Firma für eine eigene Herstellung aufbringen würde, würde diese Firma auf
eine eigene Herstellung verzichten und stattdessen das Produkt der Fremdfirma erwerben. Die
innovative Firma profitiert in diesem Fall von der Nachahmung seiner Innovation (vgl. von
Hippel, 2006, S.87).
Die Wahrscheinlichkeit für das Auftreten einer solchen Situation ist nicht gering.
Serienproduktion und optimierte Produktionsprozesse wirken sich positiv auf den Preis aus,
mögliche Konkurrenten unterstützen diese Wirkung zusätzlich. Das als öffentliches Gut
verfügbare Wissen schafft einen bestreitbaren Markt, der den Markteintritt zusätzlicher
Hersteller erleichtert.
Ergänzend kommt hinzu, dass auch der Produzent eines auf einem Open Source Projekt
beruhenden Produkts, die Pflichten eines Herstellers übernehmen muss. Er muss die
Gewährleistung für Funktionstüchtigkeit seines Produkts gewähren und haftet für eventuelle
Fehlfunktionen.
Faktisch findet durch Wissenstransfer eine Form des Outsourcings statt. Der Unternehmer
behält nach einer Veröffentlichung weiterhin das Recht, die Maschine selbst herzustellen.
Dem Unternehmer entsteht also durch die Veröffentlichung kein Verlust, er kann aber von
möglichen Effekten profitieren.
Wie bereits in Abschnitt 5.3.1.1 beschrieben, kann ein Unternehmen mit Wissenstransfer in
ein Open Source Projekt auch das Ziel verfolgen, die Kompatibilität des Open Source
Produkts hinsichtlich des eigenen Produkts zu erreichen. Der Wissenstransfer trägt dann zur
74
Etablierung offener Standards bei, die eine Entstehung gemeinsamer Netzwerke fördern. Von
Hippel sieht in der Stimulierung von Netzwerkeffekten den größten Anreiz für Unternehmen,
ihre Innovationen zu veröffentlichen (vgl. v. Hippel, 2006, S.87).
Der Begriff der User Innovation wurde von dem Ökonom und Professor der MIT Sloan
School of Management40 Eric von Hippel in seinem Buch „Democratizing Innovation“
(v. Hippel, 2006) geprägt. Bug Labs benannten eines ihrer Produkte nach seinem Namen, dem
BUGvonHippel41.
Von Hippel beschreibt eine häufige Diskrepanz zwischen den Bedürfnissen, die ein
hergestelltes Produkt erfüllen soll, und den tatsächlichen Bedürfnissen der User. Von Hippel
macht dafür den internen und auf eine Massenproduktion ausgelegten Innovationsprozess der
Unternehmen verantwortlich – es wird versucht ein Produkt zu entwickeln, dass sich am
größten Marktsegment orientiere. Diese „Few Size Fits All“-Strategie berge die Gefahr, dass
eine große Menge an Nutzern unbefriedigt zurückgelassen werde (vgl. v. Hippel, 2006, S.5).
Als Folge sieht von Hippel (2006, S.108) das häufige Scheitern von Innovationen auf dem
Markt – der Erfolg innovativer Produkte läge bei weniger als 30%. Demgegenüber stehe ein
Anteil von 10% bis 40% an Nutzern, die erworbene Produkte nachträglich modifizieren, um
sie an ihre Bedürfnisse anzupassen.
Den Apache Webserver stellt von Hippel dem konventionellen Modell der Produktentwicklung gegenüber. 90% der untersuchten Personen, die einen Apache Webserver einsetzen,
nutzten Veränderungen, um ihn an individuelle Bedürfnisse anzupassen. Diese Personen seien
dann mit dem Produkt signifikant zufriedener („significantly more satisfied“) (vgl. von
Hippel, 2006, S.4 f.).
Bessere Produkte könnten entwickelt werden, wenn die späteren Nutzer in den
Entwicklungsprozess einbezogen werden. Nutzer können dabei Individuen aber auch
Unternehmen sein.
Eine besondere Stellung nehmen nach von Hippel dabei die Lead User ein. Sie lassen sich
dadurch charakterisieren, dass ihre Bedürfnisse denen des Massenmarkts vorauseilen. Von
Lead Usern angestrebte Innovationen seien deswegen häufig auch für die übrigen Nutzer
interessant. Von Hippel hat eine Methode entworfen, wie Lead Users von Unternehmen
ausfindig gemacht werden können, um ihre Ideen in den Entwicklungsprozess einzubeziehen.
Der Anreiz für einen Nutzer, sein Wissen (seine User Innovation), frei zu veröffentlichen, läge
40 http://mitsloan.mit.edu/, letzter Aufruf: 18.12.2010
41 http://store.buglabs.net/Product-Catalog/BUGvonHippel, letzter Aufruf: 18.12.2010
75
darin, dass der Hersteller eines Produkts diese Innovation aufnehmen, und in Form eines
Wissenstransfers, in sein Produkt inkorporieren kann. Bei Weiterentwicklungen des Produkts
wird auch automatisch die freigegebene Innovation mitentwickelt.
Von Hippels Begriff der User Innovation ist kein Äquivalent des Open Source Begriffs. Als
exemplarische Vorbilder für Innovative Communities, Netzwerke aus innovativen Nutzern, die
die Geschwindigkeit und die Effektivität des Innovationsprozess weiter vorantreiben, nennt
von Hippel aber die Projekte der Free und Open Source Software (v. Hippel, 2006, S.99).
4.3.2.4
Strategische Anwendung
Nicht ungewöhnlich ist die Unterstützung von Open Source Projekten durch Unternehmen,
um eine strategische Wirkung auf dem Markt zu erzielen. Bereits besprochen wurden bisher
einige Markteffekte, wie z.B. Standards und Netzwerkeffekte, die durch eine Unterstützung
gezielt angeregt werden können. Ein eigenes Produkt soll dadurch besser am Markt
positioniert werden.
Denkbar ist aber auch die Unterstützung eines Open Source Projekts, um die Position eines
anderen Marktteilnehmers zu schwächen, insbesondere, wenn dieser mit seinem Produkt eine
dominierende Marktposition einnimmt. Durch die Unterstützung eines Substituts dieses
Produktes, kann der Hersteller dazu gezwungen werden, seinen Preis den neuen Verhältnissen
am Markt anzupassen.
Die Übernahme der Firma StarDivision durch Sun im Jahre 1999 und die Initiierung des Open
Source Projekts OpenOffice kann als so eine strategische Absicht verstanden werden.
OpenOffice beinhaltet den Quellcode des schon 1998 frei gegebenen Code des OfficeProgramms StarOffice.
Sun versuchte dadurch ein Office-Programm neben Microsofts dominierendem MS Office zu
etablieren. Da OpenOffice, im Gegensatz zu MS Office, plattformübergreifend eingesetzt
werden kann, ermöglicht OpenOffice eine Interoperabilität zwischen unterschiedlichen
Betriebssystem auf Ebene der Büroanwendungen.
Sun bot mit Solaris ein eigenes Betriebssystem an. Office-Programme stellen ein
Komplement zu einem Betriebssystem dar. Fehlende Kompatibilität zu Office-Programmen
anderer Betriebssysteme, hier vor allem auch Windows, hätte für Solaris einen erheblichen
Marktnachteil bedeutet.
Für Microsoft bestand hingegen kaum ein Anreiz, einen MS Office substituierendes Open
Source Projekt zu unterstützen, da ihr Produkt bereits von einem starken Netzwerkeffekt
76
profitieren konnte und nahezu einen De-facto-Standard darstellte. Weil Betriebssystem und
Büroanwendung komplementär zueinander sind, profitierte Microsofts Betriebssystem
Windows im gleichen Maße von diesem Netzwerkeffekt.
4.3.3
Verwendung von Open Source Produkten
Das Wissen eines Open Source Projekts ist uneingeschränkt nutzbar – jeder hat die
Möglichkeit, Open Source Produkte anzuwenden, als Ware herzustellen oder sie als Basis
einer Dienstleistung zu verwenden.
Die einfachste Form einer Verwendung eines Open Source Produkt ist vermutlich seine
Einbettung in den Produktivbetrieb eines Unternehmens. Beispielhaft für die Verwendung von
Open Source Software Produkten ist die Verwendung von Linux als Betriebssystem oder des
Office Programms OpenOffice. Auf Seiten der Open Hardware wäre die Nutzung von
Maschinen oder Bauteilen, die auf einem Open Source Projekt beruhen vorstellbar – z.B. die
Steuerung von Prozessen über Microcontroller des Arduino Projekts.
Die Vorteile für ein Unternehmen liegen auf der Hand. Die Nutzung verlangt keine
Lizenzgebühren, und die Offenheit des Quellcodes ermöglicht eine Anpassung des Produkts
an individuelle Bedürfnisse (User Innovation).
Der Vorteil einer Anpassung an eigene Bedürfnisse geht mit der Verpflichtung zu höherer
Eigeninitiative einher. Das gilt insbesondere für Open Hardware Produkte; während eine
Software nur kompiliert werden muss, und meistens schon als ausführbares Programm
vorliegt, muss eine Hardware erst aus Rohstoffen hergestellt werden.
Hinzu kommt, dass für Open Source Produkte keine haftbaren Personen existieren, schließlich
handelt es sich bei ihrem Quellcode um öffentliche Güter. Die Verwendung von Open Source
Produkten erfolgt darum auf eigenes Risiko. Mögliche Schäden durch Fehlfunktionen müssen
also vom Nutzer selbst getragen werden
Die Abwägung, ob ein Open Source Produkt ein proprietäres ersetzten soll, muss unter
Betrachtung aller anfallender Kosten getroffen werden – Total Cost of Ownership (TCO).
Entscheidend wird dann nicht sein, wie günstig ein Produkt in seiner Anschaffung ist,
sondern, wie viel es am Ende seiner Einsatzzeit gekostet haben wird. Die TCO für ein Open
Source Produkt könnte, trotz fehlender Lizenzgebühren, auch über dem des proprietären
Substituts liegen.
Ein Unternehmen, das als Hersteller eines Open Source Produkts auftritt, kann diese Lücke
füllen. Die Basis des Produkts ist ein Open Source Projekt. Das Unternehmen wird durch
77
Serienproduktion und optimierte Produktionsprozesse die Herstellungskosten im Vergleich zu
einem Nutzer, der das Produkt für den eigenen Gebrauch produziert, reduzieren können. Im
Gegenzug muss er die Funktionstüchtigkeit seiner Produkte gegenüber seinen Kunden
gewährleisten. Ergänzend kann das Unternehmen Services und Dienstleistungen anbieten,
beispielsweise Montage und Wartung, und kann dadurch den Wert seines Produkts zusätzlich
steigern. Ziel dieses Unternehmens ist es, die TCO auf Seiten seiner Kunden zu reduzieren.
Vorbild für diese Art der Verwendung von Open Source Produkten sind die Anbieter von
Linux Distributionen. Der Linux Kernel allein ist nur für Experten verwendbar; um ihn
produktiv nutzen zu können, muss er zunächst um erforderliche Werkzeuge, bspw. eine
Benutzeroberfläche, ergänzt werden. Die Anbieter einer Linux Distribution machen sich diese
Einschränkung zu Nutze, indem sie umfangreiche Softwarepakete anbieten, deren Basis der
Linux Kernel ist. Der Funktionsumfang dieser sogenannten Distributionen entspricht gängiger
Betriebssysteme. Da es sich bei Distributionen weiterhin um Open Source Software handelt,
müssen sie von ihren Erstellern kostenlos zum Download angeboten werden. Distributionen
werden oft in Kombination mit komplementären Gütern verkauft, z.B. zusammen mit
Handbüchern. Oder es werden Dienstleistungen angeboten, die Nutzer der Software in
Anspruch nehmen können.
Der Autor dieser Arbeit hat mit einem ähnlichen Modell sein Studium finanziert. Als
selbständiger Webentwickler hat er Kunden Content Management Systeme (CMS) für
Webseiten verkauft. Diese CMS wurden in Open Source Projekten entwickelt und müssen in
der Regel an die speziellen Erfordernisse der Webseite, die sie betreiben sollen, angepasst
werden.
Das Geschäftsmodell des Autors bestand darin, ein frei verfügbares Produkt an die
individuellen Wünsche eines Nutzers anzupassen. Sollten während der Nutzung
Fehlfunktionen auftreten, wird sich der Nutzer nicht an das Open Source Projekt wenden,
sondern an den programmierenden Dienstleister.
MakerBot Industries nutzen ein ähnliches Modell. MakerBots 3D-Drucker basiert auf dem
RepRap, dessen Fork es bildet. RepRaps Quellcode wurde zu einem vermarktungsfähigen
Produkt ergänzt. MakerBot verkauft über einen eigenen Shop Baukästen, die alle zum Aufbau
des Druckers benötigten Teile enthalten. Zusätzlich werden auch Produkte angeboten, die die
Standardfunktionen des Druckers ergänzen. Als Hersteller und Händler muss MakerBot die
Funktionstüchtigkeit der angebotenen Teile gewährleisten.
Doch nicht jede Person, die einen 3D-Drucker von Zeit zu Zeit verwendet, möchte auch
78
gleich einen besitzen. Die Anschaffung eines Bausatzes ist mit Kosten verbunden und sein
Aufbau erfordert handwerkliches Geschick. Ein Unternehmen könnte Beschaffung, Aufbau
und Wartung eines 3D-Druckers übernehmen und die Dienstleistung des Druckens verkaufen.
Das Unternehmen verwendet in diesem Fall dass Open Source Produkt als Produktionsmittel
und bietet auf dieser Basis einen Service an.
Der Erfolg des Internets basiert ganz erheblich auf diesem Modell: Die technische Basis des
Internets bilden die Webserver, die durch das TCP/IP Protokoll untereinander verbunden sind.
Durch den Erfolg des World Wide Web entstand das Geschäftsmodell des Webhosters.
Webhoster sind private Unternehmer, die über Webserver verfügen, und deren Rechenleistung
und Speicherplatz sie an Kunden vermieten.
Viele Webhoster bieten ihren Kunden den sogenannten LAMP-Stack an. LAMP ist ein
Akronym für Linux Apache MySQL und PHP/Perl/Python. Jeder Teil des Akronyms steht für
ein Open Source Software Projekt. LAMP bedeutet, dass der Server von Linux und dem
Apache Webserver betrieben wird, und über die Datenbank MySQL sowie über mindestens
eine der Programmiersprachen PHP, Perl oder Python verfügt.
Das Produktionsmittel des Webhosters ist eine physischer Webserver, der durch Open Source
Software betrieben wird.
Auch bedeutend größere Unternehmen nutzen Open Source Produkte, um ihre Leistungen
anbieten zu können. Die Grundlage der Suchmaschine Google42 bildete noch im Jahr 2003 ein
Cluster aus 150000 handelsüblichen PCs, die durch eine modifizierte Version des
Betriebssystems Linux betrieben wurden (Barroso et al., 2003).
4.3.4
4.3.4.1
Risiken und Chancen für Unternehmen bei Open Hardware Projekten
Risiken für Unternehmen
Die Nachteile, die für ein Unternehmen auftreten, wenn es sein Wissen frei veröffentlicht,
liegen auf der Hand – es verliert die Möglichkeit der exklusiven Nutzung. Durch den Verzicht
auf die Durchsetzung geistiger Eigentumsrechte können Nachahmungen nicht mehr
verhindert werden.
Da die Mitarbeit an Open Source Projekten rein freiwillig ist, kann bei der Initiierung eines
Open Source Projekts nicht garantiert werden, dass sich andere an einer Weiterentwicklung
des Wissens beteiligen werden. Im ungünstigsten Fall bedienen sich zwar Dritte am
veröffentlichten Wissen und nutzen es zu eigenen Zwecken, lassen aber keine eigene Arbeit in
das Projekt zurückfliessen (Trittbrettfahrer Problem).
42 http://www.google.com, letzter Aufruf: 18.12.2010
79
Aber auch eine starke Beteiligung externer Entwickler an einem Projekt kann für ein sich als
Maintainer betätigendes Unternehmen problematisch sein. Abschnitt 4.1.2. zeigt, dass die
Führungsrolle des Maintainers innerhalb des Projekts beschränkt ist. Das Potential eines Open
Source Projekts wird ganz entscheidend durch seine Community bestimmt, die sich aus sich
freiwillig beteiligenden Individuen zusammensetzt. Um diese Entwickler zu halten, und um
ein Forking zu verhindern, muss der Maintainer deren Wünsche und Ziele bei der Ausrichtung
des Projekts berücksichtigen.
Benkler (2007, S.125) vergleicht eine Open Source Community in diesem Zusammenhang
mit der Gans, die goldene Eier legt. Ein Unternehmen das versucht, die Entwicklung
innerhalb eines Open Source Projekts zu stark nach eigenen Wünschen ausrichtet, störe das
Motivationsgerüst der Community. Das Unternehmen könne die Gans dadurch töten.
Ein Unternehmen, dass ein Open Source Projekt initiiert, muss sich darüber im klaren sein,
dass es sich den sozialen Regeln der Community unterwerfen muss. Es gibt dadurch einen
Teil seiner Kontrolle ab. Zu einem gewissen Grad begibt sich das Unternehmen dadurch in die
Abhängigkeit externer Entwickler.
4.3.4.2
Problem Kopie
Ein Gedankenspiel soll eine potentielle Schwachstelle einer Anwendung des Open Source
Modells auf Hardware zeigen: Nachahmungen von Open Source Produkten sind generell
erlaubt.
Open
Hardware
Produkte
können
dadurch
als
identische
Kopien
von
unterschiedlichen Herstellern angeboten werden. Als Folge entwickelt sich ein ideal
bestreitbarer Markt. Die Produzenten werden gezwungen, den Preis ihrer Produkte an die
Grenzkosten ihrer Produktion anzugleichen. Ein weiterer Produzent kann ein Open Hardware
Produkt nur noch dann erfolgreich auf dem Markt anbieten, wenn er die Grenzkosten des
Produkts senken kann.
Unter der Prämisse, dass jeder Hersteller den Produktionsprozess und die Ausgaben für
benötigte Rohstoffe zu gleichen Bedingungen optimieren kann, wird der Hersteller die
niedrigsten Grenzkosten erreichen können, der seine Produkte zu den geringsten
Lohnstückkosten herstellen kann.
Ein Hersteller, der ein Produkt unter hohen Arbeitsstandards durchführt, hat zwangsläufig
höhere Lohnstückkosten als ein Hersteller, der diese Standards nicht berücksichtigt. Hier
besteht nun die Gefahr, dass sich auf dem durch Open Hardware geförderten bestreitbaren
Markt letztlich immer der Hersteller durchsetzen wird, der ein Produkt unter den
schlechtesten Arbeitsbedingungen produziert.
80
Die Schutzmechanismen geistigen Eigentums könnten durch einen Hersteller in diesem Fall
dazu eingesetzt werden, neben allen anderen Nachahmungen, eben auch „billige Kopien“ vom
Markt fernzuhalten.
Wie bereits in dieser Arbeit aufgeworfen, erfordern Open Source Projekte von ihren
Anwendern oftmals mehr Eigeninitiative und Eigenverantwortung. In diesem Fall handelt es
sich bei dem Konsumenten eines Open Hardware Produkts um einen Anwender. Durch seine
Kaufentscheidung kann er entscheiden, unter welchen Bedingungen ein Produkt produziert
werden soll.
Hierbei ist wichtig zu beachten, dass es sich bei dem Produkt eines Herstellers nur um eine
Instanz des Open Hardware Produkts handelt. Das Wissen um das Projekt ist Grundlage
dieses Produkts, die letztliche Adaption bleibt dem Hersteller überlassen. Er kann den Wert
seines Produkt zum Beispiel dadurch erhöhen, indem er höherwertige Rohstoffe einsetzt und
unter höheren Qualitätsstandards produzieren lässt.
Um den Konsumenten die Möglichkeit zu geben, zwischen Open Source Produkten
verschiedener Hersteller zu unterscheiden, können die Hersteller Marken (Trademarks)
verwenden, um sich und ihre Produkte zu kennzeichnen.
Marken sichern Unverwechselbarkeit. Im Unterschied zu Patenten und Urheberrecht dienen
sie nicht dazu, die Nachahmung von Wissen zu verhindern, sondern die Herkunft eines
Produkts zu belegen – die Marke eines Produkt signalisiert dem Kunden den Hersteller des
Produkts. Marken stellen darum keinen Widerspruch zu den Ideen der Free und Open Source
Software dar.
Von den untersuchten Firmen nutzen Bug Labs, MakerBot, OpenSPARC und Whirlwind
Wheelchair Marken, die am United States Patent and Trademark Office (UPTSO) registriert
sind.
Mit der Verwendung einer Marke ermöglicht ein Hersteller von Open Source Produkten, dass
diese durch den Kunden eindeutig mit der Herstellerfirma assoziiert werden können. Der
Kunde kann sich dann bewusst für das Produkt eines bestimmten Herstellers entscheiden.
Die Gefahr des Preisdumping besteht mit der Existenz von Marken zwar nach wie vor, doch
gibt insbesondere die Transparenz von Open Source Projekten Herstellern die Gelegenheit,
ihre Produkte von Produkten anderer Hersteller auch durch sekundäre Eigenschaften
abzugrenzen.
Open Hardware kann in diesem Fall sogar einen Vorteil bedeuten, weil sich der Konsument
81
wie im Fall proprietärer Produkte nicht mehr allein für oder gegen ein bestimmtes Produkt
entscheiden muss. Im Fall von Open Hardware kann der Konsument wählen, unter welchen
Bedingungen sein Produkt hergestellt worden sein soll. Er kann sich dann zwar weiterhin für
das günstigste Produkt entscheiden, oder aber für eines, dessen Produzent seinen Angestellten
faire Löhne zahlt und deren Krankenversicherung finanziert oder CO2-neutral produziert.
4.3.4.3
Chancen für Unternehmen
Den Risiken einer Veröffentlichung von Wissen in einem Open Source Projekt stehen die
Chancen gegenüber, die ein Unternehmen nutzen kann. Die wichtigsten Effekte, auf die ein
Unternehmen durch eine Beteiligung einwirken kann, sind sicherlich der Wissenstransfer und
mögliche Netzwerkeffekte.
Ein Unternehmen gewinnt mit der Veröffentlichung von Wissen und der Organisation einer
verteilten globalen Entwicklung externe Entwickler, die sich an der Weiterentwicklung des
Wissens beteiligen können. Da der Wissenstransfer in Open Source Projekten bidirektional
verläuft, fließt neues Wissen zurück in das Unternehmen. Die Motivation der Entwickler, die
sich ausschließlich freiwillig beteiligen, führt zu einer besonderen Qualität ihrer Beiträge,
indem sie Wissen einbringen, dass eigenen Zielen und Wünschen folgt. Ein Unternehmen
gewinnt dadurch Einblick in die Bedürfnisse seiner Kunden, indem es Forschung und
Entwicklung in die Hände späterer Nutzer legt (User Innovation).
Offene Forschungs- und Entwicklungsplattformen fördern die Entstehung offener Standards.
Setzt sich ein offener Standard am Markt durch, kann ein Unternehmen durch Mitarbeit an
einem Open Source Projekt eigene Wünsche in diesen Standard einbringen. Ein Unternehmen
gewährleistet damit die Kompatibilität konkurrierender Produkte zu seinen eigenen.
Eine verteilte Entwicklungsarbeit, insbesondere wenn sich auch verschiedene Unternehmen
daran beteiligen, kann sich insbesondere dann positiv auswirken, wenn es sich um junge
Innovationen handelt. Kosten für Forschung und Entwicklung werden dann auf mehrere
Schultern verteilt. Dadurch, dass mehr Wissen in die Entwicklung einfließen kann, können
resultierende Produkte schneller zur Marktreife gebracht werden.
Gemeinsame Standards und eine herstellerübergreifende Kompatibilität fördern dabei Bildung
von Nutzer-Netzwerken, die auf einer gemeinsamen technischen Basis interagieren können.
Erreichen Netzwerke eine ausreichende Größe, profitieren Unternehmen, die diese Netzwerke
mit Produkten beliefern können, von Netzwerkeffekten.
Die Wirkung von Netzwerkeffekten ist vor allem dann kostbar, wenn Märkte noch jung und
klein sind. Bietet ein Unternehmen ein Produkt für einen noch kleinen Markt an, kann es
82
nützlich sein, diesen Markt nicht allein bedienen zu wollen. Durch Öffnung seines Wissens
fördert ein Unternehmen das Auftreten von Nachahmerprodukten konkurrierender Hersteller.
Durch größeres Angebot und Preisvarianz kann die Nachfrage nach einem neuen und noch
unbekannten Produkttyp gesteigert werden, und der Markt an Potential gewinnen.
83
5 Beispiel: Open Source Akku
Anhand eines Gedankenspiels soll dass Potential von Open Source Hardware und die in dieser
Arbeit gewonnen Erkenntnisse veranschaulicht werden. Das Beispiel beschäftigt sich mit dem
Produkt des Akkus, der in der Elektromobilität zukünftig eine wichtige Rolle spielen könnte.
5.1
Problem
Der Markt der Elektromobilität befindet sich heute noch in einem Entstehungsstadium. Viele
Fragen sind noch offen, es gibt weder gefestigten Strukturen noch wurden Standards gesetzt.
Diese Ausgangssituation bietet für viele Unternehmen die Gelegenheit, in einen neuen Markt
mit neuen innovativen Produkten vorzudringen. Schafft es ein Unternehmen mit seiner
Lösung, unter Nutzung von Netzwerkeffekten, einen Standard zu setzen, so bietet sich die
Chance, letztlich den gesamten Markt zu bedienen („The winner takes it all“).
Die Besonderheit des Akkus und an der Elektromobilität sind, dass auch Neuerungen in der
Infrastruktur stattfinden werden. Das weit verzweigte Netz an Tankstellen, das die Energie für
herkömmliche Fahrzeuge bereit hält, muss durch ein Äquivalent für elektrisch betriebene
Fahrzeuge ergänzt oder ersetzt werden. Hierbei vollzieht sich auch ein Wechsel der
Energielieferanten, mglw. weg von den Mineralölkonzernen hin zu den Energieversorgungsunternehmen. Wie diese Infrastruktur für Elektrofahrzeuge aussehen wird, ist eine bisher
ungeklärte Frage – gibt es Zapfsäulen, an denen das Fahrzeug angeschlossen und geladen
werden kann, gibt es Induktionsschleifen im Asphalt, durch die während des Fahrt oder
während des Parkens Energie zum Auto transferiert wird oder gibt es Austauschstationen, wo
in wenigen Minuten ein verbrauchter Akku gegen einen neuen ausgetauscht wird?
Jede Lösung erfordert ein spezielles Design der Fahrzeuge, damit es mit der vorhandenen
Infrastruktur genutzt werden kann. Zunächst werden vermutlich mehrere Lösungen parallel
angeboten werden, die untereinander inkompatibel sein könnten. Schließlich werden sich
dann eine oder wenige Lösungen durchsetzen und einen De-facto-Standard ausformen.
Vorstellbar wäre, dass ähnlich wie beim Links- und Rechtsverkehr, geografische
Segmentierungen entstehen könnten, je nach Zusammenspiel von Automobilherstellern,
Infrastrukturanbietern und Energiekonzernen.
Momentan engagieren sich Automobilhersteller, Akkuhersteller und Anbieter von
Infrastrukturlösungen in eigenen Forschungs- und Entwicklungsprojekten oder bilden
untereinander Allianzen. Das Ergebnis sind proprietäre Lösungen, in denen die Autos einen
Verbund mit ihrem Stromspeicher bilden und auf eine bestimmte Infrastruktur nutzen können.
Beispiel für eine bereits weit entwickelte Lösung bietet die Allianz von Renault-Nissan und
84
Better Place43 – Better Place errichtet ein Netz aus Tauschstationen für Akkus und RenaultNissan die passenden Fahrzeuge.
Abgesehen von Grundlagenforschungen an Universitäten, finden Forschung und Entwicklung
untereinander abgeschlossen in den Unternehmen statt; Wissenstransfer findet nur innerhalb
der Allianzen statt. Grund hierfür ist der Wunsch, entwickelte Innovationen durch Patente zu
schützen, um sie exklusiv auf dem Markt anbieten zu können.
Wie oben bereits beschrieben, werden sich langfristig nur wenige Lösungen durchsetzen
können. Für die heute forschenden Unternehmen besteht daher das Risiko, dass sich geleistete
Investitionen als vergeblich erweisen können, wenn sie sich mit ihrer Lösung nicht am Markt
behaupten können. Hinzu käme, dass unterlegende Unternehmen, um ihre Produkte weiterhin
auf dem Markt anbieten zu können, die Lösung konkurrierender Unternehmen in ihre
Produkte einbauen müssen, da diese von den Käufern gewünscht werden – sie müssen sich
den erfolgreichen Netzwerken anschließen, was mit Lizenzgebühren verbunden sein wird.
Beispielhaft hierfür sind die Formatkriege zwischen Betamax und VHS oder HD DVD und
Blu-ray Disc.
Diese Vorgehensweise, einen noch jungen Markt aufzubauen, wird sich aus mehreren
Gründen als ineffektiv erweisen und mit Verlusten für das Gemeinwohl verbunden sein.
Durch die Abgeschlossenheit der konkurrierenden Forschungsprojekte wird oftmals doppelte
Forschung betrieben, wodurch unnötige Kosten durch redundantes Wissen entstehen. Als
Folge des Wettkampfs zwischen den verschiedenen Lösungsmodellen entstehen hohe Verluste
auf Seiten der unterlegenen Unternehmen und die Gefahr einer freien Preisgestaltung auf
Seiten der letztlich erfolgreichen Unternehmer.
Möglicherweise entsteht die Situation der „Tragedy of the Anticommons“ – womöglich reicht
dass Wissen, über dass die Menschheit verfügt bereits aus, um effektive Akkus zu
konstruieren und mit einer sinnvollen Infrastruktur zu verbinden. Doch die Segmentierung des
Wissens in untereinander konkurrierenden Forschungsprojekten führt dazu, dass keiner
Einblick in das bereits verfügbare Wissen erlangen kann, oder dass Wissenssegmente
aufgrund von urheberrechtlichen Gründen nicht miteinander verknüpft werden können.
Der Verlust für das Gemeinwohl besteht letztlich darin, dass Innovationen mit höheren Kosten
und höheren Preisen verbunden sein könnten, dass fehlende Verknüpfungen zwischen
Wissenssegmenten zu verzögerten Innovationen führen oder dass Innovationen durch die
Tragedy of the Anticommons ganz verhindert werden.
43http://www.betterplace.com/, 7.12.2010
85
5.2
Lösung
Der Akku eignet sich deshalb besonders gut für eine Entwicklung innerhalb eines Open
Source Projekts, weil es sich bei ihm um ein Modul handelt. Er kann getrennt von Karosserie
und Elektromotor entwickelt und hergestellt werden. Weil Baumaße und Schnittstellen offen
dokumentiert sein werden, können Automobilhersteller den Open Source Akku in das Design
ihrer Produkte inkorporieren.
Meines Erachtens ist das in dieser Arbeit entworfene Modell einer Open Hardware
Entwicklung, in dem ein Akku in einem für jeden offenen Netzwerk entwickelt wird, besser
geeignet. Das Projektwissen ist öffentliches Gut und darf von jedem eingesehen, bearbeitet
und verwendet werden. Folgende Vorteile birgt das Modell Open Hardware:
1. Bündelung von Wissen:
Alle beteiligten Unternehmen, Forschungseinrichtungen und individuelle Entwickler
lassen ihr Wissen in einen gemeinsamen Wissenspool fließen. Durch diesen
Wissenstransfer kann neues Wissen entstehen und doppelte Forschung vermieden
werden. Unter optimalen Voraussetzungen können in kürzerer Zeit bessere Ergebnisse
erzielt werden. Das Risiko von Fehlinvestitionen sinkt.
2. Vermeidung der Tragedy of the Anticommons:
Niemand kann von der Nutzung des Wissens ausgeschlossen werden. Dadurch werden
Situationen vermieden, in denen Wissen deshalb nicht verknüpft werden kann, weil
keine Einigung zwischen den geistigen Eigentumsrechten verschiedener Parteien an
unterschiedlichen Wissenssegmenten getroffen wird, oder weil eine solche Einigung
die Nutzung einer Innovation unrentabel machen.
3. Offene Standards:
Das Ergebnis des Open Source Projekts wird ein Akku sein, dessen Schnittstellen und
Spezifikationen offen dokumentiert sind und von jedem verwendet werden dürfen.
Unternehmen die komplementäre Produkte oder Leistungen anbieten, können ihre
Produkte kompatibel zum Open Source Produkt gestalten. Automobilhersteller können
ihre Fahrzeuge so entwickeln, dass der Akku in den Karosserien eingebaut werden
kann und der Elektroantrieb über passende Schnittstellen mit Energie versorgt wird.
Akkuhersteller können passende Akkus liefern und Anbieter von Infrastrukturlösungen
können ihre Lösungen auf den Open Source Akku maßschneidern.
4. Unabhängigkeit:
86
Ein Unternehmer, der den Open Source Akku in sein Produkt inkorporiert, ist auf
keinen Zulieferer oder eine Allianz angewiesen. Er kann den Akku durch ein
beliebiges Unternehmen herstellen lassen, oder die Herstellung des Akkus selbst
übernehmen. Ein Konsument, der ein Open Source Akku kompatibles Fahrzeug
erwirbt, genießt die selben Vorteile. Ein Lock-in kann vermieden werden.
5. Gemeinsamer Netzwerkeffekt:
Durch Kompatibilität entstehen Netzwerke aus zueinander komplementären
Produkten. Kann ein Produkt in einem solchen Netzwerk genutzt werden, steigt sein
Wert aus Sicht des Konsumenten. Mit der Anzahl der beteiligten Unternehmen steigt
daher der Wert des Netzwerk des Open Source Akkus der komplementären Produkte
und Services. Liegt der Wert über dem eines proprietären Netzwerks, wird sich der
Kunde für das Netzwerk des Open Source Akkus entscheiden.
Die Entwicklung des Akkus in einem Open Source Projekt bietet sich an, weil er als Modul
entwickelt und hergestellt werden kann. Für den Elektromotor ist es unerheblich, was genau
ihn mit Energie versorgt, solange die physischen Schnittstellen und die nötige Spannung
stimmen.
Alle bereits heute zur Elektromobilität forschenden Unternehmen können durch einem Open
Source Akku profitieren und dabei weiterhin ihre Ziele verfolgen. Der Automobilhersteller
möchte Autos verkaufen, der Akkuhersteller diese Autos mit Akkus ausstatten und der
Anbieter von Infrastruktur möchte schließlich mit Strom betriebene Fahrzeuge mit Energie
versorgen. Alle Parteien streben dabei an, letztlich das erfolgreichste und damit größte
Netzwerk zu bedienen.
Mit einer Beteiligung am Open Source Akku geht jeder eine Allianz mit einem offenen
Netzwerk ein, das mit jedem weiteren Teilnehmer an Stärke gewinnt. Durch eine gemeinsame
Entwicklung wird Wissen gebündelt und werden Ressourcen eingespart. Unternehmen die die
Entwicklung einer eigenen Lösung zugunsten des Open Source Akkus verzichten, reduzieren
die Gefahr von Fehlinvestitionen.
Der Nutzer elektronisch betriebener Fahrzeuge profitiert maßgeblich von einem Open Source
Akku. Parallele inkompatible Netzwerke bedeuten für ihn einen Verlust, da er mit seinem
Produkt nur ein Netzwerk nutzen könnte. Genau wie heute jedes Auto jede Tankstelle
anfahren kann, sollte auch für die Elektromobilität eine Infrastruktur angestrebt werden, die
alle verfügbaren Fahrzeuge komfortabel mit Energie versorgen kann.
87
Statt eines Wettbewerbs zwischen Netzwerken fördert der Open Source Akku den Wettbewerb
zwischen Produkten innerhalb eines Netzwerkes. Es entsteht ein bestreitbarer Markt mit
geringen Eintrittsbarrieren, wodurch die Gefahr monopolartiger Strukturen am Markt
verhindert werden kann. Gleichzeitig wird die Unabhängigkeit des Nutzers gestärkt. Die
Hersteller werden zu wettbewerbsorientierten Verhalten gezwungen, was zu sinkenden
Preisen bei höherer Qualität führt.
Das Geschäftsmodell der Firma Better Place44 besteht darin, dass sie ein Netz von
Tauschstationen für Akkus bereithält, die ein Fahrer eines elektrisch betriebenen Fahrzeugs
bei niedrigem Ladestand des Akkus ähnlich einer herkömmlichen Tankstelle anfahren kann,
und an denen sein leerer Akku in wenigen Minuten gegen einen vollen ausgetauscht wird.
Better Place strebt an, auch mit Batterien verschiedenen Typs operieren zu können. Dadurch
versuchen sie, ihr Netzwerk für Teilnehmer anderer Netzwerke offen zu halten bzw. in andere
Netzwerke vorzudringen. Für Better Place ergibt sich daraus das Problem, dass sie ihre
Stationen so anpassen müssen, dass diese mit Batterien möglichst vieler Hersteller umgehen
können, was zu höheren Entwicklungskosten führt.
Das Geschäftsmodell erfordert, dass die Tauschstationen immer eine gewisse Zahl von Akkus
vorrätig haben müssen, um sie gegen die leeren Akkus ihrer Kunden austauschen zu können.
Mit der zunehmenden Zahl an tauschbaren Akkus unterschiedlicher Typen und Hersteller
steigt zugleich der logistische Aufwand.
Je mehr Autos mit demselben Akkutyp betrieben werden, desto wahrscheinlicher ist die
erfolgreiche Realisierung dieses Geschäftsmodells. Better Place muss daher ein großes
Interesse an einem standardisierten Akku haben, so dass diese Unternehmen ein optimaler
Kandidat für ein infrastrukturelles Unternehmen, das sich an der Entwicklung eines Open
Source Akkus beteiligen könnte.
Das Modell Open Hardware bietet die Chance, dass, wenn alle Beteiligten ihre gesamte
Energie in ein gemeinsames und jedem offen stehendes Netzwerk investieren würden, und
dabei das Ziel vor Augen hätten, dieses gemeinsame Netzwerk zum Erfolg zu verhelfen,
anstatt ihre Energie darauf zu verwenden, fremde Netzwerke zu verdrängen, der Wechsel von
brennstoffbetriebenen zu elektrischen Fahrzeugen schneller und für das Gemeinwohl
kostengünstiger erreicht werden könnte.
44 http://www.betterplace.com/, letzter Aufruf: 17.12.2010
88
6 Fazit
Die leitende Frage der vorliegenden Arbeit war, ob die Prinzipien der Open Source Software
Entwicklung auch auf Hardware übertragen werden können.
Alle untersuchten Aspekte haben gezeigt, dass die für Software entwickelten Prinzip Open
Source – modifiziert – auf Hardware angewandt werden können. Dies ist der Fall, weil es
auch bei Open Hardware einen Quellcode gibt, Open Source Lizenzen genutzt werden können
und bereits Projekte existieren, die das Prinzip Open Source anwenden.
Voraussetzung ist zunächst, dass ein Äquivalent zum Quellcode der Open Source Software
auch für materielle Güter existiert. Im Mittelpunkt des Modells Open Source Software steht
der frei verfügbare Quellcode einer Software. Er darf genutzt, verändert und vervielfältigt
werden. Veränderungen des Quelltextes dürfen wiederum veröffentlicht werden. Spezielle
Open Source Lizenzen sorgen dafür, dass diese Bedingungen durchgesetzt werden und auch
für zukünftige Versionen erhalten bleiben – der Quellcode wird zu einem öffentliche Gut.
Ein Quellcode, der unter diesen Bedingungen veröffentlicht wird, ermöglicht die
uneingeschränkte Partizipation freiwilliger Entwickler. Sie bilden die Grundlage für die
Entstehung verteilter kooperativer Netzwerke, die Open Source Communities.
Gezeigt wurde, dass alles Wissen, das benötigt wird, um ein materielles Gut herzustellen, der
Definition des Quellcodes genügt. Für eine verteilte kooperative Arbeitsweise ist dabei von
Vorteil, dass die Entwicklung und Fertigung von materiellen Gütern durch Computer erfolgt.
Der Quellcode der Hardware liegt dadurch in digitalen Dateiformaten vor, die verlustfrei und
nahezu kostenlos reproduziert werden können.
Um eine uneingeschränkte Partizipation zu ermöglichen ist es erforderlich solche
Dateiformate zur Repräsentation des Quellcodes zu nutzen, die von potentiellen Entwicklern
üblicherweise zur Bearbeitung des jeweiligen Gutes verwendet werden. Eine Besonderheit
materieller Güter ist dabei, dass unterschiedliche Güter auch unterschiedliche Arten der
Beschreibung bedürfen. Der Quellcode von Software hingegen ist immer Text.
Zur Überprüfung einer praktischen Anwendbarkeit der Methode Open Source auf materielle
Güter wurden bereits existierende Open Hardware Projekte untersucht. Sie demonstrieren die
besonderen Anforderungen an den Quellcode. Nahezu alle Projekte veröffentlichen ihr Wissen
in gängigen Formaten. Für CAD Daten wird das übliche Austauschformat .dxf verwendet,
Projekte, für Leiterplatinen (PCBs – printed circuit boards) werden EAGLE und GERBER
Dateien genutzt, die auch von einfachen Editoren in diesem Bereich verarbeitet werden
89
können. Schematische Darstellungen werden üblicherweise in PDFs angeboten.
Ein erprobtes Äquivalent zu den gängigen Lizenzen der Open Source Software existiert
hardwareseitig noch nicht. Stattdessen wird auf die gängigen Software Lizenzen (GPL) oder
auf Lizenzen des Open Content Bereichs (Creative Commons) zurückgegriffen.
Da es sich beim Quellcode der Open Hardware Projekte um Computerdateien handelt, ist das
Copyright/Urheberrecht grundsätzlich auf sie anwendbar. Damit erfüllen sie die
Vorraussetzungen, um auch durch die obigen Lizenzen geschützt zu werden. Die Lizenzen der
Creative Commons sind dahingehend konzipiert worden, digitale Inhalte zu schützen. Sie
eignen sich daher auch zum Schutz der in Open Hardware Projekten erzeugten Informationen.
Die GPL lässt in ihrer Definition des Quellcodes erstaunlicherweise einen so großen
Deutungsraum offen, dass sie nicht allein auf den Quellcode von Computerprogrammen
beschränkt bleibt, sondern auch für Hardware verwendet werden kann.
Patente finden keine Verwendung. Um eine Innovation patentieren zu können muss sie neu
sein und darf zum Zeitpunkt der Patentierung nicht bereits publiziert worden sein. Die
Methode Open Source besteht aber gerade darin, dass Wissen des Projektes möglichst weit
und möglichst oft zu veröffentlichen. Eine spätere Patentierung ist damit ausgeschlossen.
Die Existenz des Projekts MakerBot zeigt, dass auch die grundlegenden Eigenschaften der
Open Source Communities auf Hardware Projekte erhalten bleiben. Eine Besonderheit ist die
Möglichkeit des Forkings – das Abspalten eines parallelen Entwicklungszweigs eines
bestehenden Projekts. Bei MakerBot handelt es sich um einen Fork des Projekts RepRap.
Die ökonomische Analyse ergab, dass die Vorteile der Open Source Software Entwicklung
ebenso der Entwicklung von Hardware Produkten dienen können.
Die lizenzkostenfreie Weitergabe des Quellcodes in der Open Source Software schließt eine
kommerzielle Nutzung nicht aus. Dabei könnte eine Open Source Software sogar verkauft
werden doch führt die freie Verfügbarkeit des Quellcodes zwangsläufig dazu, dass das
Programm kostenlos angeboten werden wird. Genau genommen findet eine Annäherung des
Verkaufspreises an die Grenzkosten des Programms statt – die Grenzkosten für das digitale
immaterielle Gut betragen Null.
Bei Open Hardware findet diese Annäherung ebenfalls statt. Doch anders als bei einem Open
Source Software Projekt ist das Produkt eines Open Hardware Produkts ein materielles Gut.
Seine Produktion ist mit Aufwand und der Verwendung von Rohstoffen verbunden. Ein Open
Hardware Produkt muss schließlich zu einem positiven Preis verkauft werden.
90
Bei genauer Betrachtung stellt ein Open Hardware Markt dabei einen nahezu optimal
bestreitbaren Markt dar. Dadurch dass der Quellcode eines Open Hardware Produkts
öffentliches Gut ist, sind die Markteintrittsbarrieren sehr gering. Jeder darf den Quellcode
nutzen, um das Produkt herzustellen und um es auf dem Markt anzubieten. Ein Markteintritt
eines weiteren Produzenten wird dabei nur dann stattfinden, wenn er das Produkt zu einem
geringeren Preis als die bereits bestehenden Anbieter anbieten kann. Monopolpreise sind
ausgeschlossen, um ein Open Hardware Produkt erfolgreich am Markt anbieten zu können,
muss sich sein Preis ebenfalls an den Grenzkosten seiner Produktion orientieren.
Die fehlende Möglichkeit einer exklusiven Nutzung einer Innovation bedeutet für
kommerzielle Unternehmen erst einmal einen Nachteil und auf den ersten Blick scheint es
wenig plausibel, dass sich ein Unternehmen an Open Hardware Projekten beteiligen sollte.
Doch die Offenheit des Innovationsprozesses birgt auch für profitorientierte Firmen durchaus
Potential.
Anstatt Wissen aufgrund eines auf eine spätere Patentierung ablaufenden Innovationsprozesses, nach Unternehmen zu segmentieren, entsteht in den Open Source Communities ein
zentraler Wissensknoten. Jeder darf etwas beitragen, jeder darf ihn nutzen. Da die Mitarbeit
individueller Entwickler freiwillig erfolgt, werden sich vornehmlich Personen beteiligen, die
sich für eine spezielle Innovation interessieren – üblicherweise sind sie auch die späteren
Nutzer. Es erfolgt ein Wissenstransfer von den späteren Nutzern in den Wissensknoten und
von den Konsumenten zu den Produzenten.
Je mehr Wissen dabei von unterschiedlichen Seiten zusammengetragen wird, desto stärker ist
das Innovationspotential. Da jeder Beitrag freiwillig erfolgt, wird einer Tragedy of the
Anticommons entgegengewirkt und die Transaktionskosten sind niedrig. Es erfolgt eine
schnellere
Wissensdiffusion
und
der
offene
Entwicklungsprozess
unterstützt
die
Herausbildung offener Standards und gemeinsamer Schnittstellen.
Eine Marktsituation mit niedrigen Eintrittsbarrieren und offenen Standards bietet ein hohes
Potential für mögliche Netzwerkeffekte, indem alternative und komplementäre Güter
angeboten werden können. Aufgrund gemeinsamer Kompatibilität wird ein gemeinsames
Netzwerk genutzt und unter Mithilfe aller aufgebaut. Diese Eigenschaft ist dann besonders
wertvoll, wenn Märkte noch jung sind. Das Anwendungsbeispiel eines Open Source Akkus
sollte dies demonstrieren.
Im Mai 2010 hat die Bundesregierung die „Nationale Plattform Elektromobilität“
beschlossen. 500 Millionen Euro des Konjunkturprogramms II sollen direkt in die Förderung
91
der Elektromobilität fließen, und im Rahmen einer Forschungsförderung sollen diese Mittel
dazu genutzt werden, um die Entwicklung der Batterietechnik und den Aufbau von
Infrastruktur voranzutreiben (BMWI, 2009).
Diese Initiative zeigt, dass der Markt der Elektromobilität, der sich in Entstehung befindet,
bereits schwer umkämpft ist. Es besteht die Gefahr, dass sich nur wenige Unternehmen
durchsetzen werden, und dass sich die Verlierer unter hohen Kosten diesen Netzwerken
anschließen müssten. Ein Unternehmen, das mit einem eigenen Netzwerk im Wettbewerb
unterlag, wird die Kosten geleisteter Entwicklungsarbeit nicht mehr einspielen können und
vermutlich für die Verwendung fremder Lizenzen zahlen. Die soziale Wohlfahrt würde in
diesem Fall sinken.
Mit dem Beispiel des Open Source Akkus wurde gezeigt, dass das Modell eines Open
Hardware
Projekte
insbesondere
für
diesen
Markt
prädestiniert
scheint.
Statt
Ressourcenverschwendung um die geistigen Eigentumsrechte möglicher Innovationen zu
betreiben, sollten alle vorhandenen Mittel dafür verwendet werden, ein gemeinsames,
globales Netzwerk aufzubauen. Für einen Automobilhersteller bedeutet ein globales Netzwerk
gleichzeitig einen globalen Absatzmarkt.
92
Anhang I: Übersicht Interviews
Projekt
Beschreibung
Experte
Standort
Datum
1
Open Design – Ronen
Kadushin
Möbel
Initiator des
Projekts
Deutschland
05.01.10
2
RepRap
3D-Drucker
Initiator des
Projekts
Großbritannien
04.03.10
3
Whirlwind Wheelchair
Rollstuhl
Geschäftsführer
der Firma
USA
23.02.10
4
MakerBot
3D-Drucker
Initiator des
Projekts
USA
28.04.10
5
Bug Labs
Modulare
Mitarbeiter der
Hardwarekomponenten Firma
USA
21.06.10
93
Anhang II: Datenmaterial
Interview: Open Design – Ronen Kadushin
I am interested in the motivation behind the decision
developing a product open source.
I was trying to find a way to design and produce stuff
independantly.
Describe your way to Open Hardware.
What do you expect from Open Hardware?
(Advantages / Disadvantages)
It can develop into a serious alternative to make things
that will better reflect a real world situation while
giving individuals freedom of creating, and living of it.
No disadvantages, only different risks.
Why don't you develop your product in a traditional
way?
I do, for clients and where it is not relevant (e.g.
expensive tooling investment). But it is just more fun
and easily rewarding to do Open Design.
Software is text. OSS Development benefits from the
fact that text is easy to share, to administrate and to
work on.
Digital production files (dxf) of the whole product,
with text and pictorial assembly instructions.
I would like to find out how remote and collaborative
development can work on non-software either.
What kind of knowledge is "open" in your project and
in what kind of form do you provide it?
I would like you to describe the workflow inside the
community.
It's a small community, but we all get to know each
other and use other's attitudes and work as an
inspiration and an energy source.
Which portion takes community in development?
Make an estimation if you don't know an exact
number.
5% maybe,in development, but being part of a
community is also an incentive for development.
Who is the community? How many members are part
of it?
About 3-5 professional designers, 50 young/student
designers, 5 dedicated web platforms for sharing and
communicating.
Do you accept forks of your project and do some
already exist? If No, why don't you accept forks?
A design process, whatever for, welcomes forks.
Do you tolerate a production of your product by
another manufacturer? Is your product already made
by another manufacturer? (Advantages /
Disadvantages)
Yes, it is produced by other users whom sometimes
send me pictures of what they did. I enjoy it a lot.
94
OSS Licenses use copyright to save open knowledge
from being licensed proprietary again.
Creative Commons attribution- non commercial –
share alike 3.0
I am interested in how knowledge that is not covered
by copyright can be saved.
How do you save your knowledge? Do you use special
Open Source Licenses?
What is about patents?
I have non.
Do you think special Open Source Hardware Licenses
are needed? Please explain your decision.
Not really. I would like though, a greater interest of
CC in physical products copyrights.
Publishing knowledge Open Source means to abandon the right to use this knowledge exclusively. But an
exclusive use of knowledge means competitive
advantage. Is Open Source Hardware not
economically?
How can economical advantages be achieved by Open
Source Hardware?
Interview: RepRap
I am interested in the motivation behind the decision
developing a product open source.
I've used Linux more or less since it started.
Describe your way to Open Hardware.
What do you expect from Open Hardware?
(Advantages / Disadvantages)
Freedom to work at my own pace on what I like, and
to publish everything as soon as it is done.
Why don't you develop your product in a traditional
way?
It's a self-copying machine. I'd only sell one...
Software is text. OSS Development benefits from the
fact that text is easy to share, to administrate and to
work on.
All the CAD designs, software and documentation is
under the GPL.
I would like to find out how remote and collaborative
development can work on non-software either.
What kind of knowledge is "open" in your project and
in what kind of form do you provide it?
95
I would like you to describe the workflow inside the
community.
We all do more or less what we like, and it seems to
come together...
Which portion takes community in development?
Make an estimation if you don't know an exact
number.
Proportion as opposed to what? I guess 100%
Who is the community? How many members are part
of it?
The RepRap community. I don't know how many
people there are in it.
Do you accept forks of your project and do some
already exist? If No, why don't you accept forks?
Yes – I encourage them.
Do you tolerate a production of your product by
another manufacturer? Is your product already made
by another manufacturer? (Advantages /
Disadvantages)
Yes, and yes.
OSS Licenses use copyright to save open knowledge
from being licensed proprietary again.
There is none. It's all computer files, and they are all
copyright.
I am interested in how knowledge that is not covered
by copyright can be saved.
How do you save your knowledge? Do you use special
Open Source Licenses?
What is about patents?
Expired for our project.
Do you think special Open Source Hardware Licenses
are needed? Please explain your decision.
No. In practice all the open licences are used to mean
the same thing. I find the debates between the
proponents of one as opposed to another risible.
Publishing knowledge Open Source means to abandon A research team of everyone who wants to be on it...
the right to use this knowledge exclusively. But an
exclusive use of knowledge means competitive
advantage. Is Open Source Hardware not
economically?
How can economical advantages be achieved by Open
Source Hardware?
96
Interview: Whirlwind Wheelchair
I am interested in the motivation behind the decision
developing a product open source.
Describe your way to Open Hardware.
What do you expect from Open Hardware?
(Advantages / Disadvantages)
Whirlwind Wheelchair has been involved in collecting
information about wheelchair designs appropriate to
riders in resource limited environments for over 30
years. We believe that the best way to design products
is to ask the users to participate in the design and
implementation. We generally call this user-driven or
user-based design. By collecting designs from people
around the world, and testing them in the facilities and
with different users in the networks of wheelchair
manufacturers, we're able to integrate iterative design
with rapid prototyping. It is critical that we get
feedback on designs from users and manufacturers, so
we place the designs in the public domain. It is
important to note that we share some of the written
materials, including the technical drawing set, only
with organizations with which we have relationships.
We avoid unrestricted distribution of the most
technical information to ensure that we can have the in
depth conversations that are needed to ensure quality
products.
I expect:
*Access to the discussions or dialogue around the
technology, and some forum to document the
collective experience (not necessarily facilitated by the
developer, however)
*an expectation that the user evaluates the OH.
Why don't you develop your product in a traditional
way?
I think we do develop products in a traditional manner.
Most of the "hardware" technology used in the world
is shared freely, from hand agricultural tools to load
carrying devices. I think a shift to privatization of
information is a shift from traditional technology
application.
We also get better design feedback from users by
making the products open source, which helps us
integrate different users' experiences into something
that I like to call a global body of knowledge, that
anyone can then have access to.
97
Software is text. OSS Development benefits from the
fact that text is easy to share, to administrate and to
work on.
I would like to find out how remote and collaborative
development can work on non-software either.
What kind of knowledge is "open" in your project and
in what kind of form do you provide it?
Open:
Physical design: You can buy a wheelchair and copy it.
We try to design products to be transparent, primarily
so the users can repair and modify as needed. This has
the added benefit of leading to a replicable product.
We ask that if you want to copy the chair and
manufacture it in volume, you work with us because
we can offer advice and years of experience in
wheelchair design criteria, and information about what
can be changed and what needs to stay the same in the
design, including geometry, materials, and production
methods.
Not open anonymously but still open with relationship:
drawing set with technical specification and Quality
Assurance documentation and tolerances, to help
ensure that larger manufacturers will have a
conversation with us about technical specification and
the lessons we've learned over the years.
I would like you to describe the workflow inside the
community.
Ralf Hotchkiss has personal connections to dozens of
wheelchair builder around the world, and checks in
periodically for new ideas and suggestions.
Whirlwind sets up new wheelchair shops when
contracts stipulate. We often train wheelchair riders in
wheelchair manufacture, in this case, and in the
process of doing so ask for design feedback and
suggestions.
Whirlwind partners with established manufacturers to
produce wheelchairs that can be sold locally or
distributed regionally. In this way we both work with
small disabled peoples' organizations (DPOs) that
collaborate with us on the user issues, and with
manufactures who produce higher volume, who
collaborate with us on manufacturing issues.
Which portion takes community in development?
Make an estimation if you don't know an exact
number.
I don't understand this question.
98
Who is the community? How many members are part
of it?
Wheelchair riders around the world.
A network of about 20 small wheelchair shops around
the world.
A network of about 4 medium sized wheelchair
manufacturers (20-50 employees)
A design network that includes many wheelchair riders
around the world, and about 10 staff and volunteers in
San Francisco at our office.
Do you accept forks of your project and do some
already exist? If No, why don't you accept forks?
Yes. We like to think of every wheelchair manufacturer
as a fork of the larger project that we are also a part
of--working to make sure that people have the mobility
they need.
We also help students get started on design projects
related to mobility and technology provision.
Do you tolerate a production of your product by
another manufacturer? Is your product already made
by another manufacturer? (Advantages /
Disadvantages)
Yes, see above.
OSS Licenses use copyright to save open knowledge
from being licensed proprietary again.
Technical drawings for the RoughRider product have
copyright protection.
I am interested in how knowledge that is not covered
by copyright can be saved.
Documentation such as information on distributing
wheelchairs safely, carving pressure relief cushions,
etc, is in the public domain or uses a Creative
Commons Licence.
How do you save your knowledge? Do you use special
Open Source Licenses?
What is about patents?
No.
Do you think special Open Source Hardware Licenses
are needed? Please explain your decision.
I think that a license will help people become aware of
the possibilities. Something like creative commons
that allows people to stipulate conditions of the use of
their hardware. I think that licenses will encourage
more people to participate in open source hardware,
but ideally shouldn't be needed.
99
Publishing knowledge Open Source means to abandon
the right to use this knowledge exclusively. But an
exclusive use of knowledge means competitive
advantage. Is Open Source Hardware not
economically?
*You can get better products through improved
collaboration
*Plan to make money from something other than
intellectual property protection, for example from
managing the information but not the information
itself. For example, Whirlwind asks for a percentage of
wheelchair sales from partner factories that can afford
How can economical advantages be achieved by Open it and when Whirlwind brings customers to the factory,
but not from the factories that cannot afford to share
Source Hardware?
revenue.
A whole lot of information was brought to the product
from the "outside community" as you say. We do not
use this language because the riders and builders are
the developers often. We facilitate collaborative
design, including testing and idea synthesis and
manufacturability and training. So it's a constant back
and forth for basic design. however, the manifestation
of this particular wheelchair, the Roughrider, happened
before I began working for the organization.
I'm copying Ralf Hotchkiss, who was the chief
engineer of the RoughRider. Ralf, perhaps you can
respond to this one question if you have the time?
Simplified:
requisite knowledge comes from our experts, gathered
from wheelchair riders around the world. wheelchair is
designed overtime in a variety of communities, but put
together into a replicable product in san francisco.
designs are shared with different wheelchair builders
around the world, sometime with a manufacturing
contract, sometimes given out freely and left to the
wind. then we get feedback from riders and builders
and the clinicians who are involved in fitting and
repairs. In my opinion we need more of this
information.Then we reincoporate this into the design
evolution---though we do utilize "Design freeze" for at
least a couple years at a time.
Does that answer your question? Ralf, feel free to
chime in.
100
What percentage of the knowledge you own today was Some days the input is all from the interior, some days
gained by exterior (maybe the better word)
al from the exterior. Sometimes Whirlwind's interior
developers? Can you make an estimation of that?
works for months on new designs, only to be told later
by the exterior that our developments are of no value
because, while the new technology may work well, the
exterior will not build it - the benefits of the new
technology have not been found to be worth the
trouble. The best estimate that i can give is that,
because our design process could not work without
both interior and exterior participants, the effective
value of the input is 50/50%. The quantity of the input
from each side is more like 50% +/- 30%.
Interview: MakerBot
I am interested in the motivation behind the decision
developing a product open source.
I wake up in the morning and walk to work and make
it happen!
Describe your way to Open Hardware.
What do you expect from Open Hardware?
(Advantages / Disadvantages)
I expect that we will share things and that people will
build on what we share and share them too!
Why don't you develop your product in a traditional
way?
Sharing is more fun.
Software is text. OSS Development benefits from the
fact that text is easy to share, to administrate and to
work on.
We share all the designs for our machine and we do
that on Thingiverse. DXFs to board files to parts lists.
I would like to find out how remote and collaborative
development can work on non-software either.
What kind of knowledge is "open" in your project and
in what kind of form do you provide it?
I would like you to describe the workflow inside the
community.
Things get done and then modified and shared.
Which portion takes community in development?
Make an estimation if you don't know an exact
number.
Not quantifiable.
Who is the community? How many members are part
of it?
The community is a varied and around the world. I'm
going to estimate 5000 people range from enthusiasts
to hard core pillars of the community.
101
Do you accept forks of your project and do some
already exist? If No, why don't you accept forks?
Forks happen, all we ask is that you continue to share
your source files so we can all learn from each other.
Do you tolerate a production of your product by
another manufacturer? Is your product already made
by another manufacturer? (Advantages /
Disadvantages)
We're not cool with someone else making our machine
with our name on it, so we've got MakerBot
trademarked.
OSS Licenses use copyright to save open knowledge
from being licensed proprietary again.
GPLv3
I am interested in how knowledge that is not covered
by copyright can be saved.
How do you save your knowledge? Do you use special
Open Source Licenses?
What is about patents?
Not interested in them.
Do you think special Open Source Hardware Licenses
are needed? Please explain your decision.
Maybe, depends on many factors, but everything
seems to be working out ok for now.
Publishing knowledge Open Source means to abandon The community really owns the ideas and that
the right to use this knowledge exclusively. But an
encourages participation and innovation.
exclusive use of knowledge means competitive
advantage. Is Open Source Hardware not
economically?
How can economical advantages be achieved by Open
Source Hardware?
102
Interview: Bug Labs
I am interested in the motivation behind the decision
developing a product open source.
Describe your way to Open Hardware.
Our founder and CEO, Peter Semmelhack, wanted a
small GPS unit around 2001. GPS devices didn't exist
at that time in mass, and any that did exist didn't have
the user experience he was looking for. When he
couldn't buy the GPS device he wanted, he thought no
problem I'll just make one. Although growing up
tinkering with Heath Kits and taking devices apart,
hardware was harder than he remembered. He couldn't
build one from scratch easily. He began to look for
toolkits on the market that allowed him to prototype a
gadget and these also took advanced prior knowledge.
Peter saw a void for a needed product that would allow
people to create their own gadgets. Since a lot of
frustration when building his own GPS system was
from proprietary hardware companies, and from
Peter's background in open-source software, it was a
natural fit to create an open platform for innovation.
103
What do you expect from Open Hardware?
(Advantages / Disadvantages)
Advantages:
Innovation becomes more democratized!
There is a saying 'Two heads are better than one'. In
this case a community of heads are better than one :)
Sharing allows for better innovation, more
documentation, and the ability to build off other
peoples creations.
Promotes for a better lifespan of the product meaning
the product can live on even if the company is no
longer around.
Disadvantages:
Often consumers think open source should be free.
Hardware is very costly to produce. So the mindset
around open-source needs to be influenced a bit.
Open Hardware companies are still small at this point
in the game. This means:
Manufacturers are often not willing to talk to small
companies.
Lead times are parts horrendous because vendors have
bigger companies to please.
Why don't you develop your product in a traditional
way?
It didn't make sense when our goal was to democratize
innovation and make a product for people to build and
customize their own hardware.
104
Software is text. OSS Development benefits from the
fact that text is easy to share, to administrate and to
work on.
I would like to find out how remote and collaborative
development can work on non-software either.
What kind of knowledge is "open" in your project and
in what kind of form do you provide it?
Our software is in the GPL
Our CAD files for housings are under CC and
available on our website
Our schematics for each BUGmodule is under CC and
available on our website
Our Gerber files for each BUGmodule is under CC
and available on our website
Our BOM (Build-of-Materials) for each module is also
posted online
Drivers are in our SVN online
The connector pinout is open and documentation is
online
We post the data sheets from our chip vendors
Resources:
http://bugcommunity.com/wiki/index.php/Hardware
http://svn.buglabs.net/
I would like you to describe the workflow inside the
community.
For software, it's mainly pushing things to the SVN.
For hardware, there's a lot of design rework and
feedback from the community to take it which
sometimes make us respin boards. We often involve
people from the community to come up with new
modules and design them. It's a very cyclical process
rather than linear. Some modules come straight out of
the community, some are made in conjunction with
Bug and community members. Often members end up
meeting here and drawing things up with us to sketch
out basic ideas then either take the module and build it
from there or contract us to build it.
105
Which portion takes community in development?
Make an estimation if you don't know an exact
number.
If this is asking what portion of hardware is created by
the community, I'd say 30%.
Who is the community? How many members are part
of it?
Our community is largely developers and R&D labs.
Probably 100 active hardware members... We have
~1600 members total.
Do you accept forks of your project and do some
already exist? If No, why don't you accept forks?
Yes we do, and yes some already exist.
Do you tolerate a production of your product by
another manufacturer? Is your product already made
by another manufacturer? (Advantages /
Disadvantages)
We don't manufacture our own product, so yes,
currently it is manufactured by 2 manufacturers. We
would tolerate a third party manufacturing them as
well as long as they stayed within the open source
guidelines.
OSS Licenses use copyright to save open knowledge
from being licensed proprietary again.
We don't use any special licenses. We are in
conjunction with several other open hardware
companies writing community norms to support an
equivilent to the GPL or CC for hardware. This group
formed from a meeting day at Eyebeam, hosted by
Ayah Bdeir.
I am interested in how knowledge that is not covered
by copyright can be saved.
How do you save your knowledge? Do you use special
Open Source Licenses?
What is about patents?
We don't have any patents.
Do you think special Open Source Hardware Licenses
are needed? Please explain your decision.
Yes! Currently the license isn't defined whatsoever.
Which means all the licenses are interpretted without
any standardization. This is questionable as it can work
both for and against open companies. The ambiguous
behaviour of the license leaves a lot to be determined
by interpretation, which of course can vary.
106
Publishing knowledge Open Source means to abandon
the right to use this knowledge exclusively. But an
exclusive use of knowledge means competitive
advantage. Is Open Source Hardware not
economically?
Economical advantiges from open source hardware
include dropping the pricing of hardware through
competition by many people working towards one
achievement. If someone can produce our product
cheaper and better, that would be excellent; it still fits
our goal of attempting to make hardware innation
accessible and helps more people afford our product.
How can economical advantages be achieved by Open
Source Hardware?
107
Literaturverzeichnis
Ackermann, Rolf (2001): Pfadabhängigkeit, Institutionen und Regelform. Tübingen: Mohr
Siebeck.
Adloff, Frank; Mau, Stefen (2005): Vom Geben und Nehmen: Zur Soziologie der
Reziprozität. Frankfurt/Main: Campus Verlag.
Alfred, Randy (2008): Aug. 19, 1839: Photography Goes Open Source. Online verfügbar
unter: http://www.wired.com/thisdayintech/2010/08/0819daguerre-publicizes-photoprocess/ (17.12.2010).
Anderson, Chris (2010): Atoms Are the New Bits. In: Wired, 18.02, S. 59-66 und 105-107.
Arago, François (1854): Œuvres complètes de François Arago. Leipzig: T. O. Weigel.
ASF (n.d.): How the ASF works. Online verfügbar unter:
http://www.apache.org/foundation/how-it-works.html (17.12.2010).
AT&T (2010): Milestones in AT&T History. Online verfügbar unter:
http://www.corp.att.com/history/milestones.html (17.12.2010).
Barroso, Luiz A.; Dean, Jeffrey; Hölzle, Urs (2003): Web Search for a Planet: The Google
Cluster Architecture. In: IEEE Micro 23(2), S. 22-28. Online verfügbar unter:
http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/d
e//papers/googlecluster-ieee.pdf (17.12.2010).
Benkler, Yochai (2007): The Wealth of Networks: How Social Production Transforms
Markets and Freedom. New Haven, London: Yale University Press.
Bessen, James (2004): The Software Patent Experiment. In: Business Review, Q3, S. 22-32.
Bessen, James (2005): Open Source Software: Free Provisions of Complex Private Goods.
Online verfügbar unter: http://www.researchoninnovation.org/opensrc.pdf
(17.12.2010).
Bitzer, Jürgen; Schrettl, Wolfram; Schröder, Philip J.H. (2007): Intrinsic motivation in open
source software development. In: Journal of Comparative Economics, Volume 35,
Issue 1, S. 160-169.
Blinkenlights (n.d.): An Open Letter to Hobbyists. Online verfügbar unter:
http://www.blinkenlights.com/classiccmp/gateswhine.html (17.12.2010).
BMWI (2009): Bundeskabinett: Deutschland soll zum Leitmarkt für Elektromobilität werden.
Pressemitteilung vom 18.09.2010, Online verfügbar unter:
http://www.bmwi.de/BMWi/Navigation/Presse/pressemitteilungen,did=309868.html
(17.12.2010).
Braun, Dietma (1999): Theorien rationalen Handelns in der Politikwissenschaft: Eine
108
kritische Einführung. Hemsbach: Leske + Budrich.
Brügge, Bernd; Harhoff, Dietmar; Picot, Arnold; Creighton, Oliver; Fiedler, Marina; Henkel,
Joachim (2004): Open-Source-Software: Eine ökonomische und technische Analyse.
Springer: Berlin.
Buchtala, Rouven (2007): Determinanten der Open Source Software-Lizenzwahl: Eine
spieltheoretische Analyse. Frankfurt: Peter Lang.
Bug Labs (n.d.): License. Online verfügbar unter: http://www.buglabs.net/license
(17.12.2010).
CNET (2005): Newsmaker: Gates taking a seat in you den. Online verfügbar:
http://news.cnet.com/Gates-taking-a-seat-in-your-den---page-4/2100-1041_35514121-4.html (17.12.2010).
Creative Commons (n.d.): Attribution-SharAlike 3.0 Unported. Online verfügbar unter:
http://creativecommons.org/licenses/by-sa/3.0/ (17.12.2010)
Debian GNU/Linux Anwenderhandbuch (n.d.): Die Definition quelloffener Software. Online
verfügbar unter: http://debiananwenderhandbuch.de/freiesoftware.html (17.12.2010).
Deci, Edward L.; Ryan, Richard M. (1985): Intrinsic Motivation and Self-Determination in
Human Behaviour. New York: Plenum Press.
DiBona, Chris. et al. (1999): Open Sources: Voices from the Open Source Revolution.
Sebastopol: O'Reilly Media.
Dorn, Dietmar; Fischbach, Rainer; Letzner, Volker (2010): Volkswirtschftslehre 2:
Volkswirtschaftstheorie und -politik. München: Oldenbourg Wissenschaftsverlag.
Evers, Steffen (2008): Ein Modell der Open-Source-Entwicklung. Dissertation. Online
Verfügbare unter: http://deposit.ddb.de/cgi-bin/dokserv?
idn=992457327&dok_var=d1&dok_ext=pdf&filename=992457327.pdf (17.12.2010).
Freedomdefined.org (n.d.): OSHW draft. Online verfügbar unter:
http://creativecommons.org/licenses/by-sa/3.0/ (17.12.2010).
Ghosh, Rishab A. (2005): CODE, Collaborative Ownership and the Digital Economy.
Camebridge: The MIT Press.
Gläser, Jochen; Laudel, Grit (2009): Experteninterviews und qualitative Inhaltsanalyse. 4.
Aufl. Wiesbaden: Vs Verlag für Sozialwissenschaften.
GNU (n.d.): The GNU Manifesto. Online verfügbar unter:
http://www.gnu.org/gnu/manifesto.html (17.12.2010).
GNU (2007): GNU General Public Licence. Online verfügbar unter:
http://www.gnu.org/licenses/gpl.html (17.12.2010).
GNU (2010): The Free Software Definition. Online verfügbar unter:
109
http://www.gnu.org/philosophy/free-sw.html (17.12.2010).
Grassmuck, Volker (2002): Freie Software. Bonn: Bundeszentrale für politische Bildung.
Hardin, Garret (1968): The Tragedy of the Commons. In: Science, Vol. 162, No. 3859, S.
1243-1248. Online verfügbar unter:
http://www.sciencemag.org/content/162/3859/1243.full.pdf (17.12.2010).
Helfrich, Silke (2009): Wem gehört die Welt?: Zur Wiederentdeckung der Gemeingüter.
München: oekom verlag / Berlin: Heinrich-Böll-Stiftung. Online verfügbar unter:
http://www.boell.de/downloads/economysocial/Netzausgabe_Wem_gehoert_die_Welt.
pdf (17.12.2010).
Heller, Michael. A. (1998): The Tragedy of the Anticommons: Property in the Transition from
Marx to Markets. In: Harvard Law Review, 111(3), S. 621-688.
Heller, Michael A.; Eisenberg, Rebecca S. (1998): Can Patents Deter Innovation? The
Anticommons in Biomedical Research. In: Science, Vol. 280 no. 5364, S. 698-701.
Online verfügbar unter: http://www.sciencemag.org/content/280/5364/698.full
(17.12.2010).
Hiebler, Heinz (2003): Hugo von Hofmannsthal und die Medienkultur der
Moderne.Würzburg: Königshause & Neumann.
Hippel, Eric von (2006): Democratizing Innovation. Cambridge: The MIT Press.
IBM (n.d.): Open Source at IBM. Online verfügbar: http://www03.ibm.com/linux/ossstds/oss/ossindex.html (17.12.2010).
Institut für Rechtsfragen der Freien und Open Source Software (2005): GPL kommentiert und
erklärt. Köln: O'Reilly.
Kelly, Kevin (2009): The New Socialism. In: Wired, 17.06, S. 116-121.
Kirkwood, John B. (2004): Antitrust Law and Economics. Amsterdam (u.a.): Elsevier
Kizza, Prof. Joseph M. (2010): Ethical and Social Issues in the Information Age. London:
Springer-Verlag.
Kurz, Peter (2000): Weltgeschichte des Erfindungsschutzes: Erfinder und Patente im Spiegel
der Zeiten. Hrsg. von der Patentanwaltskammer zum hunderjährigen Jubiläum des
Gesetzes betreffend die Patentanwälte. Köln: Heymanns.
Lakhani, Karim R.; Wolf, Bob; Bates, Jeff; DiBona, Chris (2002): The Boston Consulting
Group Hacker Survey. Online verfügbar unter:
http://ftp3.au.freebsd.org/pub/linux.conf.au/2003/papers/Hemos/Hemos.pdf
(17.12.2010).
Lerner, Josh; Tirole, Jean (2000): The Simple Economics of Open Source. Online verfügbar
unter: http://www.people.hbs.edu/jlerner/simple.pdf (17.12.2010).
110
Lerner, Josh; Tirole, Jean (2002): Scope of Open Source Licensing. Online verfügbar unter:
http://opensource.mit.edu/papers/lernertirole2.pdf (17.12.2010).
Levy, Steven (2001): Hackers: Heroes of the Computer Revolution. New York: Penguin
Books.
Linux Foundation (2009): Linux Kernel Development. Online verfügbar unter:
https://www.linuxfoundation.org/sites/main/files/publications/whowriteslinux.pdf
(17.12.2010).
Linux Online (2001): Excerpts from a Chicago Sun-Times interview with Steve Ballmer,
CEO of Microsoft. Online verfügbar unter:
http://www.linux.org/news/2001/06/01/0003.html (17.12.2010).
Löhr, Isabelle (2010): Die Globalisierung geistiger Eigentumsrechte: Neue Strukturen
internationaler Zusammenarbeit 1886-1952. In: Kritische Studien zur
Geschichtswissenschaft, Band 195, Göttingen: Vandenhoeck & Ruprecht.
Mockis, Audris; Fielding, Roy T.; Herbsleb, James (2000): A Case Study of Open Source
Software Development: The Apache Server. In: Proceedings of the 2000 International
Conference on Software Engineering. ICSE 2000 the New Millennium (2000), S.263272. Online verfügbar unter: http://www.mockus.us/papers/apache.pdf (17.12.2010).
Mohr, Hans (1999): Wissen – Prinzip und Ressource. Berlin (u.a.): Springer.
Mundhenke, Jens (2007): Wettbewerbswirkungen von Open-Source-Software und offenen
Standards auf Softwaremärkten. Berlin: Springer.
Mundie, Craig (2001): The Commercial Software Model. Transkription eines Vortrags an der
„New York University Stern School of Business“, 3 Mai 2001, online verfügbar unter:
http://www.microsoft.com/presspass/exec/craig/05-03sharedsource.mspx
(17.12.2010).
Mustonen, Mikko (2003): Copyleft – The economics of Linux and other open source
software. In: Information Economics and Policy, 15(1), S. 99-121.
Mustonen, Mikko (2005): When Does a Firm Support Substitute Open Source Programming?.
In: Journal of Economics & Management Strategy, 14(1), S. 121-139. Online
verfügbar unter: http://onlinelibrary.wiley.com/doi/10.1111/j.14309134.2005.00036.x/pdf (17.12.2010)
Net Applications (2010): Operating System Market Share. Online verfügbar unter:
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8
(17.12.2010).
Norton, Quinn (2006): Give 'em a (Working) Hand. Online verfügbar unter:
http://www.wired.com/gadgets/mods/news/2006/09/71797 (17.12.2010).
111
Odendahl, Manuel; Finn, Julian; Wenger, Alex (2009): Arduino- Physical Computing für
Bastler, Designer und Geeks. Köln: O'Reilly Verlag.
Oracle (n.d.): Oracle Contributor Agreement. Online verfügbar unter:
http://oss.oracle.com/oca.pdf (17.12.2010).
OSI (n.d.): The Open Source Definition. Online verfügbar unter:
http://www.opensource.org/docs/osd (17.12.2010).
OSI (n.d. a): Licenses by Name. Online verfügbar unter:
http://www.opensource.org/licenses/alphabetical (17.12.2010).
OSI (n.d. b): The BSD License. Online verfügbar: http://www.opensource.org/licenses/bsdlicense.php (17.12.2010).
Peters, Prof. Dr. Ralf (2010): Internet-Ökonomie. Heidelberg (u.a.): Springer.
Pindyck, Robert; Rubinfeld, Daniel (2009): Mikroökonomie. München: Pearson Studium.
Pomberger, Gustav; Pree, Wolfgang (2004): Software Engineering. München, Wien: Carl
Hanser Verlag.
Raymond, Eric S. (2001): The Cathedral and the Bazaar: Musings On Linux And Open
Source By An Accidental Revolutionary. Revised Edition, Sebastopol: O'Reilly Media.
Red Hat (2009): Open Source Activity Map. Online verfügbar unter:
http://www.redhat.com/about/where-is-open-source/activity/ (17.12.2010).
Reinhard, Wolfgang (2006): Lebensformen Europas: Eine historische Kulturanthropologie.
München: C. H. Beck.
Rheingold, Howard (2000): The Virtual Community: Homesteading on the Electronic
Frontier. Revised Edition, Cambridge: The MIT Press.
Ritchie, Dennis M. (1993): The Development of C Language. Vortrag auf der „Second
History of Programming Languages Conference“ (Cambridge, April 1993). Online
verfügbar unter: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html (17.12.2010).
Rockman, Howard B. (2004): Intellectual Property Law for Engineers and Scientists. New
Jersey: John Wiley & Sons.
Rosenberg, Donald. K. (2000): Open Source: Unauthorised White Papers. Foster City: IDG
Books.
Samuelson, Paul A.; Nordhaus, William. D. (2007): Volkswirtschaftslehre. Das internationale
Standardwerk der Makro- und Mikrökonomie. Landsberg am Lech: mi-Fachverlag.
Sebald, G. (2007): Offene Wissensökonomie. Wiesbaden: Vs Verlag für Sozialwissenschaften.
Shuen, Amy (2008): Die Web 2.0-Strategie: Innovative Geschäfte im Internet. Köln: O'Reilly
Verlag.
Siebert, Horst; Lorz, Oliver (2007): Einführung in die Volkswirtschaftslehre. Stuttgart: W.
112
Kohlhammer.
Sietmann, R. (2009): Rip. Mix. Publish. Der Wissenschaft steht ein radikaler Wandel im
Umgang mit Forschungsdaten bevor, c't, 14, S. 154-161.
SourceForge (n.d.): About. Online verfügbar unter: http://sourceforge.net/about (17.12.2010).
Spindler, Prof. Dr. Gerald. (2003): Rechtsfragen der Open Source Software. Im Auftrag des
Verbandes der Softwareindustrie Deutschland e.V. Online Verfügbar unter:
http://lehrstuhl-spindler.uni-goettingen.de/pub/web/fileadmin/studie_final.pdf
(17.12.2010).
Spinner, Helmut. F. (1998): Die Architektur der Informationsgesellschaft. Berlin: Philo
Verlagsgesellschaft mbH.
Stallman, R. (1999): Richard Stallman On "Free Hardware". Online verfügbar unter:
http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-22-005-05-NW-LF
(17.12.2010).
Stallman, Richard M. (n.d. a): Why Open Source misses the point of Free Software. Online
verfügbar unter: http://www.gnu.org/philosophy/open-source-misses-the-point.html
(17.12.2010).
Stallman, Richard M. (n.d.): The EMACS Full-Screen Editor. Online verfügbar unter:
http://www.lysator.liu.se/history/garb/txt/87-1-emacs.txt (17.12.2010)
StatCounter (2010): StatCounter Global Stats. Online verfügbar unter:
http://gs.statcounter.com/ (17.12.2010)
Stegbauer, Christian (2002): Reziprozität: Einführung in die soziale Form der Gegenseitigkeit.
Wiesbaden: Westdeutscher Verlag.
Stiegler, Bernd; Roesler, Alexander (2005): Grundbegriffe der Medientheorie. Paderborn:
Wilhelm Fink Verlag.
Tanenbaum, Andrew. S. (2009): Moderne Betriebssysteme. München: Pearson Studium.
TAPR (2007): The TAPR Open Hardware License. Online verfügbar unter:
http://www.tapr.org/ohl.html (17.12.2010).
Taubert, Niels C. (2006): Produktive Anarchie? Netzwerke freier Softwareentwicklung.
Bielefeld: Transcript.
Teupen, Christian (2007): "Copyleft" im deutschen Urheberrecht: Implikationen von Open
Source Software (OSS) im Urhebergesetz. Berlin: Duncker & Humblot.
Viesel, Edward (2006): Freiheit statt Freibier: Geschichte und Praxis der freien digitalen Welt
- mit einer Einführung in Linux. Münster: Unrast Verlag.
Williams, Sam (2002): Free as in Freedom. Richard Stallman's Crusade for Free Software.
Sebastopol: O'Reilly.
113
Whirlwind Wheelchair (n.d.): About Whirlwind Wheelchair. Online verfügbar:
http://www.whirlwindwheelchair.org/about.htm (17.12.2010).
ZDNet (2005): SAP slams open source 'socialism'. Online verfügbar:
http://www.zdnet.co.uk/news/application-development/2005/11/11/sap-slams-opensource-socialism-39236750/ (17.12.2010).
114