Management und Entwicklung von quelloffener Software

Transcription

Masterarbeit
im Studiengang Medienmanagement
der Fakultät Medien
an der HTWK Leipzig
Hochschule für Technik, Wirtschaft und Kultur (FH)
Thema:
M a n a g e m e n t u n d E n t w ick lu n g v o n q u e l l o f f e n e r S o f t w a r e
Eingereicht von:
P h ilip p Z in s
Zur Erlangung des akademischen Grades:
Master of Engineering
Erstprüfer/in:
Prof. Dr.-Ing. Jörg Bleymehl
Zweitprüfer/in:
Dipl.-Math. Uwe Birkemeyer
Eingereicht:
Leipzig, 16.09.2013
Bibliografische Beschreibung:
Zins, Philipp: Management und Entwicklung von quelloffener Software, 2013, Inhalt: 109
Seiten, Leipzig, Hochschule für Technik, Wirtschaft und Kultur, Fakultät Medien, Masterarbeit
Lizenz:
CC BY 3.0 DE (creativecommons.org/licenses/by/3.0/de/)
Referat:
Ziel dieser Arbeit ist es, die Entwicklung und das Management von quelloffener Software
vorzustellen. Neben einer Einführung in die Geschichte und Kultur der open-source
Community werden theoretische Modelle des Managements vorgestellt. In Fallstudien und in
Experteninterviews werden diese Modelle in die Praxis übertragen und zeigen somit das
Management von realen Projekten. Ein wichtiger Bestandteil dieser Arbeit ist die Widerlegung
des Mythos, dass quelloffene Software unentgeltlich ist. So ist ein vollständiges Kapitel den
Monetarisierungsmöglichkeiten für quelloffene Software gewidmet. Abschließend werden
Vor- und Nachteile der Entwicklung quelloffener Software aus Unternehmenssicht gegenübergestellt.
Inhaltsverzeichnis
I
INHALTSVERZEICHNIS
I n h a l t s v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I A b b i l d u n g s v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V D e f i n i t i o n s v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V I F a l l s t u d i e n v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V I I T a b e l l e n v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V I I I A b k ü r z u n g s v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I X D a n k s a g u n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X I 1 E i n l e i t u n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 H i n w e i s e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 H i n t e r g r ü n d e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Geschichtliche Entwicklung .......................................................................... 3 3.2 Freiheit oder Freibier? ................................................................................. 4 3.3 OSS im Web ............................................................................................... 6 4 K o n z e p t i o n u n d P l a n u n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Rollen ...................................................................................................... 7 4.1.1 Contributor ............................................................................................. 7 4.1.2 Committer .............................................................................................. 8 4.1.3 Reviewer ................................................................................................ 8 4.1.4 Project Lead ............................................................................................ 9 4.1.5 User ...................................................................................................... 9 4.2 Ziele ........................................................................................................ 9 4.3 Konkurrenzanalyse ................................................................................... 13 4.4 Zielgruppenanalyse .................................................................................. 21 4.5 Lizenz .................................................................................................... 25 4.5.1 General Public License ............................................................................. 27 4.5.2 Lesser General Public License .................................................................... 27 4.5.3 Affero General Public License .................................................................... 27 Inhaltsverzeichnis
II
4.5.4 Massachusetts Institute of Technology License ............................................. 28 4.5.5 Berkeley Software Distribution License ....................................................... 29 4.5.6 Apache License ...................................................................................... 29 4.5.7 Creative Commons .................................................................................. 29 4.6 Zusammenfassung .................................................................................... 30 5 E n t w i c k l u n g u n d O r g a n i s a t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 5.1 Hierarchie- und Organisationsmodelle .......................................................... 31 5.1.1 Organisationsmodelle nach Stürmer ........................................................... 32 5.1.1.1 „Single vendor open source projects“ ....................................................... 32 5.1.1.2 „Developer communities“ ....................................................................... 33 5.1.1.3 „User communities“ .............................................................................. 33 5.1.1.4 „Open source competence centers“ .......................................................... 34 5.1.2 Organisationsmodelle nach Prokop ............................................................ 35 5.1.2.1 „Wohlwollender Diktator“ ...................................................................... 35 5.1.2.2 „Gewählte Regierung“ ........................................................................... 36 5.1.2.3 Meritokratie ........................................................................................ 36 5.2 Funktionen und Rollen des Managements ...................................................... 37 5.2.1 Managementfunktionen nach Koontz/O’Donnell............................................ 37 5.2.2 Managementrollen nach Mintzberg ............................................................ 39 5.2.3 Managementkompetenzen nach Katz .......................................................... 42 5.3 Motivation .............................................................................................. 42 5.3.1 Erwartungs-Valenz-Theorie nach Vroom ...................................................... 44 5.3.2 Bedürfnishierarchie nach Maslow ............................................................... 45 5.3.3 Zwei-Faktoren-Theorie nach Herzberg ......................................................... 47 5.3.4 Job-Characteristics nach Hackman/ Oldham ................................................. 49 5.4 Entwicklungsmodelle ................................................................................ 51 5.4.1 Wasserfallmodell .................................................................................... 52 5.4.2 Spiralmodell nach Boehm ......................................................................... 52 5.4.3 Agile Softwareentwicklung ....................................................................... 53 5.4.4 Extreme Programming ............................................................................. 54 Inhaltsverzeichnis
5.4.5 5.5 III
Scrum .................................................................................................. 56 Technische Infrastruktur ............................................................................ 58 5.5.1 Versionsverwaltung ................................................................................ 59 5.5.2 Hosting-Dienste für Softwareprojekte ......................................................... 60 5.5.3 Issue-Tracking-System ............................................................................ 63 5.5.4 Management-Software ............................................................................ 65 5.5.5 Notizen und Dokumente ........................................................................... 67 5.5.6 Content Management Systeme ................................................................... 68 5.5.7 Webseiten und Blogs ............................................................................... 68 5.5.8 Build Systeme ........................................................................................ 69 5.5.9 Continuous Integration ........................................................................... 70 5.6 Zusammenfassung .................................................................................... 70 6 K o m m u n i k a t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 6.1 Webseiten und Blogs ................................................................................. 72 6.2 Mailinglisten und Foren ............................................................................. 74 6.3 Internet Relay Chats und Instant Messenger ................................................... 75 6.4 Roadmap ................................................................................................ 75 6.5 Zeitschriften und Onlinemagazine ................................................................ 76 6.6 Dokumentation ........................................................................................ 77 6.7 Soziale Netzwerke .................................................................................... 79 6.8 Veranstaltungen ...................................................................................... 81 6.9 Community Management ............................................................................ 84 6.10 Zusammenfassung .................................................................................... 90 7 M o n e t a r i s i e r u n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1 7.1 Software ................................................................................................ 91 7.2 Services ................................................................................................. 92 7.3 Synergien ............................................................................................... 92 7.4 Hosting .................................................................................................. 94 7.5 Support .................................................................................................. 94 Inhaltsverzeichnis
IV
7.6 Dual Licensing ......................................................................................... 94 7.7 Premium Content ..................................................................................... 95 7.8 Bounties ................................................................................................ 95 7.9 Donations ............................................................................................... 96 7.10 Funding ................................................................................................. 96 7.10.1 Crowdfunding ........................................................................................ 97 7.10.2 Venture Capital ...................................................................................... 98 7.10.3 Fördermittel .......................................................................................... 99 7.11 Sponsoring ............................................................................................ 100 7.12 Consulting ............................................................................................. 100 7.13 Werbung ............................................................................................... 101 7.14 Merchandising ........................................................................................ 101 7.15 Marketing .............................................................................................. 102 7.16 Zusammenfassung ................................................................................... 102 8 B e w e r t u n g f ü r U n t e r n e h m e n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 4 9 A u s b l i c k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 7 A n h a n g u n d N o t i z e n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 0 Gesprächsnotizen, Eric Teubert, Podlove ................................................................. 110 Gesprächsnotizen, Alexander Groß, MSpec, .NET User Group, Developer Open Space ......... 112 E-Mail-Auszug, Astro, node-xmpp ......................................................................... 114 Gesprächsnotizen, Marcus Krejpowicz und Tony Findeisen, rAppid.js ............................. 118 L i t e r a t u r v e r z e i c h n i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 0 S e l b s t s t ä n d i g k e i t s e r k l ä r u n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 1 Abbildungsverzeichnis
V
ABBILDUNGSVERZEICHNIS
Abbildung 1 - Logo der FSF ..................................................................................... 4 Abbildung 2 - Logo der OSI ..................................................................................... 5 Abbildung 3 - Logo der Creative Commons ................................................................ 29 Abbildung 4 – Managementfunktionen nach Koontz/O’Donnel ...................................... 38 Abbildung 5 – Bedürfnishierarchie nach Maslow ........................................................ 46 Abbildung 6 – Zwei-Faktoren-Theorie nach Herzberg .................................................. 48 Abbildung 7 – Popularität der Hosting-Dienste bei Google Trends .................................. 63 Abbildung 8 – Jira: Erstellung eines Tickets .............................................................. 64 Abbildung 9 – Trello: Projektansicht von Brackets mit Panning Boards ............................ 66 Abbildung 10 – Microsoft Project: Projektansicht mit Gantt Charts ................................. 66 Abbildung 11 – Android: Unveränderter Startbildschirm mit Google-Diensten .................. 93 Definitionsverzeichnis
VI
DEFINITIONSVERZEICHNIS
Definition 1 – Quelloffene Software (OSS) .................................................................. 6 Definition 2 – Management ................................................................................... 37 Definition 3 – Motivation ...................................................................................... 43 Definition 4 – Community ..................................................................................... 84 Fallstudienverzeichnis
VII
FALLSTUDIENVERZEICHNIS
Fallstudie 1 – The Document Foundation .................................................................. 12 Fallstudie 2 – Derby ............................................................................................ 14 Fallstudie 3 – Meteor ........................................................................................... 27 Fallstudie 4 – node-xmpp ..................................................................................... 29 Fallstudie 5 – Grunt ............................................................................................. 39 Fallstudie 6 – Joost de Valk ................................................................................... 51 Fallstudie 7 – Brackets ......................................................................................... 58 Fallstudie 8 – rAppid.js ........................................................................................ 79 Fallstudie 9 – .NET User Group und Developer Open Space ............................................ 84 Fallstudie 10 – Podlove ........................................................................................ 90 Fallstudie 11 – Ghost ........................................................................................... 98 Fallstudie 12 – MSpec ......................................................................................... 101 Fallstudie 13 – LiveCode ...................................................................................... 105 Tabellenverzeichnis
VIII
TABELLENVERZEICHNIS
Tabelle 1 – Steckbrief: Grunt ................................................................................. 16 Tabelle 2 - Steckbrief: Bootstrap ............................................................................ 17 Tabelle 3 - Steckbrief: Node.js ............................................................................... 18 Tabelle 4 - Steckbrief: AngularJS ............................................................................ 19 Tabelle 5 - Steckbrief: JavaScript Entwickler als Contributoren...................................... 22 Tabelle 6 - Steckbrief: JavaScript Entwickler als User .................................................. 23 Tabelle 7 – Managementrollen nach Mintzberg .......................................................... 41 Tabelle 8 – Übersicht von Hosting-Diensten für Softwareentwicklung ............................. 62 Tabelle 9 –Hosting-Diensten nach Kosten und Features ............................................... 62 Abkürzungsverzeichnis
ABKÜRZUNGSVERZEICHNIS
API
Application Programming Interface
ASF
Apache Software Foundation
CI
Continuous Integration
CLA
Contributor License Agreement
CMS
Content Management System
CVS
Concurrent Versions System
DRY
Don’t repeat yourself
FAQ
Frequently Asked Questions
FOSS
Free open-source Software
FSF
Free Software Foundation
GNU
GNU’s not Unix 1
IM
Instant Messaging
IRC
Internet Relay Chat
KISS
Keep it stupid simple
KPI
Key Performance Indicator
OASIS
Organization for the Advancement of Structured
Information Standards
ODF
OpenDocument Format
OSI
Open Source Initiative
OSS
Open-source Software
PMC
Project Management Committee
POSS
Professional open-source Software
SaaS
Software as a Service
SVN
Subversion
TDD
Test Driven Development
1
GNU ist ein rekursives Akronym. Das G steht wieder für GNU und hat keine weitere Bedeutung.
IX
Abkürzungsverzeichnis
TDF
The Document Foundation
USP
Unique Selling Proposition
VCS
Version Control System
X
Danksagung
DANKSAGUNG
Ich möchte meiner Familie und meinen Freunden danken, die mich in
allen Lebenslagen unterstützen und mir dieses Studium ermöglicht
haben. Ohne sie wäre diese Arbeit nicht entstanden.
Ein weiterer Dank gilt Mercateo, welche mir alle benötigten Mittel
zur Realisierung dieser Arbeit zur Verfügung gestellt haben. Dabei
möchte ich mich besonders bei meinem Betreuer Uwe Birkemeyer für
seine ausführliche Hilfe und Unterstützung bedanken. Als letztes
bedanke ich mich bei meinem Arbeitskollegen Thomas Gatz für sein
umfassendes Feedback.
XI
1 Einleitung
1
EINLEITUNG
Die Entwicklung quelloffener Software (im Folgenden als opensource software mit OSS abgekürzt) bietet aus Managementsicht
einige Besonderheiten gegenüber der Entwicklung proprietärer
Software.
Diese Arbeit soll dazu dienen, die Unterschiede zwischen der Entwicklung von OSS und proprietärer Software herauszubilden sowie
besondere Chancen, aber auch Risiken aufzudecken. Auf diese Weise
sollen Projektmanager, Entwickler und andere Stakeholder2 bei der
Realisierung von OSS bestmöglich unterstützt werden. Da OSS nicht
gleichbedeutend mit kostenloser Software ist und sehr erfolgreich
monetarisiert werden kann, wird sie nicht zuletzt für Unternehmen
von immer größerer Bedeutung.
Ob Software quelloffen oder geschlossen veröffentlicht werden
sollte, muss individuell entschieden werden. Die Pflege und Veröffentlichung von OSS ist mit viel Arbeit verbunden und nicht jedes
Projekt profitiert an anderen Stellen von diesem Mehraufwand.
Dennoch lohnt es sich diese Zeit zu investieren, sei es um Erfahrung
zu sammeln, Kontakte zu knüpfen oder gar Arbeitskraft auszulagern.
So fungiert diese Arbeit als nützliche Entscheidungshilfe für oder
gegen OSS.
2
stakeholder (englisch „Teilhaber“)
1
2 Hinweise
2
2
HINWEISE
Wie in technischen Themengebieten üblich werden innerhalb der
OSS-Kultur viele englische Fachbegriffe verwendet. Da die Mitarbeit
an OSS häufig sehr global stattfindet, sind Übersetzungen der Fachbegriffe eher selten. Um Missverständnissen in der Praxis vorzubeugen, werden im Rahmen dieser Arbeit englische Fachbegriffe
gegenüber ihren deutschen Übersetzungen bevorzugt. Natürlich
werden trotzdem alle Fachbegriffe bei ihrer Einführung ausführlich
erklärt.
Während der Entstehung dieser Arbeit wurden mehrere Experteninterviews mit Entwicklern von OSS durchgeführt. Die Inhalte dieser
Gespräche finden sich in den Kapiteln 4 KONZEPTION UND PLANUNG bis
7 M ONETARISIERUNG verteilt an thematisch passenden Stellen wieder.
Die vollständigen und zusammenhängenden Gesprächsnotizen befinden sich im Anhang.
Die Gesprächspartner der Interviews sind:
•
•
•
•
Eric Teubert, der Entwickler des Podcast Publishing Systems
Podlove3
Astro4, der ursprüngliche Autor der XMPP Bibliothek node-xmpp
für Node.js5
Alexander Groß, der aktuelle projektverantwortliche Entwickler
des Context/Specification Frameworks Machine.Specifications
(kurz MSpec) sowie Mitorganisator der .NET User Group Leipzig
und des Developer Open Space 6,7,8
Marcus Krejpowicz und Tony Findeisen, die Entwickler des
deklarativen JavaScript Web-Frameworks rAppid.js 9
Mit der Ausnahme des per E-Mail geführten Interviews mit Astro
wurden alle Interviews als persönliches Gespräch geführt.
3
vgl. http://podlove.org/, Stand: 01.07.2013
Astro möchte innerhalb dieser Arbeit nur unter seinem Pseudonym genannt werden. Dies ist ein in der OSS-Kultur
nicht unübliches Vorgehen und ich respektiere seinen Wunsch.
5
vgl. https://github.com/astro/node-xmpp, Stand: 22.08.2013
6
vgl. http://dotnet-leipzig.de/, Stand: 22.08.2013
7
vgl. http://devopenspace.de/, Stand: 22.08.2013
8
vgl. https://github.com/machine/machine.specifications, Stand: 22.08.2013
9
vgl. http://www.rappidjs.com/, Stand: 22.08.2013
4
3 Hintergründe
3
HINTERGRÜNDE
Die Erwartungshaltung von OSS kann sehr unterschiedlich ausfallen
und damit Projektentscheidungen beeinflussen. Aus diesem Grund
ist es wichtig die Hintergründe von OSS zu kennen, um ein Verständnis für die unterschiedlichen Definitionen zu erhalten und angemessen mit ihnen umgehen zu können.
3.1
GESCHICHTLICHE ENTWICKLUNG
Mit dem beginnenden Erfolg der Heimcomputer Ende der 1970er
Jahre veränderte sich das Verständnis der Beziehung zwischen Hardund Software. Zuvor wurden Computer in kleineren Stückzahlen
vertrieben und ihre Architektur unterschied sich stark, sodass
Software häufig nur auf einer bestimmten Hardware lief und mit
dieser zusammen ausgeliefert wurde. Hard- und Softwarehersteller
waren häufig ein und dieselbe Firma. Geschäftsmodelle basierten
hauptsächlich auf der Produktion und dem Vertrieb von Hardware,
nicht aber von Software, da diese kaum ohne entsprechende Hardware erworben werden konnte.10,11
Computerhersteller wurden in den folgenden Jahren mit mehreren
Problemen konfrontiert. Die Verbreitung von Heimcomputern verringerte die Anzahl an Hardwarearchitekturen und der zunehmende
Wechsel von Assemblersprachen zu universelleren populären
höheren Programmiersprachen wie C und C++ ermöglichten es Software zu schreiben, welche auf unterschiedlichen Hardwaresystemen
ausgeführt werden konnte.
Neben Computern wurden auch Datenträger für Privatanwender
kostengünstiger, sodass Software leichter von Endanwender zu Endanwender weitergereicht werden konnte. Computerhersteller waren
nicht mehr die einzige Bezugsquelle für Software. Durch neue
Softwarelizenzen und der Ausgabe von Software in Form von Binäranstatt Quellcode versuchten sie die Verbreitung von Software und
den Einsatz auf Fremdhardware zu unterbinden und so Einbrüchen in
den Einkünften vorzubeugen.12,13
Bevor Computer den privaten Haushalt erreichten, wurden sie fast
ausschließlich in der Wirtschaft, dem Militär und der Forschung
eingesetzt. Besonders der Bereich der Forschung entwickelte die
mitgelieferte quelloffene Software den eigenen Anforderungen ent-
10
u.a. durch die Vorstellung des Apple ][ und Commodore PER 2001 im Jahr 1977
vgl. Fogel, Producing Open Source Software, 2005, S. 5
12
z.B. mit Einführung der klassischen 3,5 inch HD Diskette 1987
13
11
3
3 Hintergründe
4
sprechend weiter, um diese verbesserte Software wiederum mit
anderen Forschungseinrichtungen zu teilen. Durch das Aufkommen
von Softwarelizenzen fürchteten sie weniger wirtschaftliche Probleme als viel mehr Behinderungen in der Forschung, der Bildung
und der sozialen Entwicklung, da das Bearbeiten und das Verteilen
von Fremdsoftware unterbunden und kriminalisiert wurde.14
Als Gegenbewegung gründete Richard Stallmann – ebenfalls aus der
Forschung stammend – 1983 das GNU Project zur Entwicklung eines
offenen unixähnlichen Betriebssystems sowie 1985 die Free Software Foundation (FSF) zur Unterstützung der Entwicklung freier
Software im Allgemeinen. Das primäre Ziel von GNU ist die Schaffung
eines Betriebssystems, welches ausschließlich aus freier Software
besteht. Stallmann gilt damit als Begründer der Freie-SoftwareBewegung. 15,16
A b b i l d u n g 1 - L o g o d e r F S F 17
3.2
FREIHEIT
ODER
FREIBIER?
Durch eine unglückliche Doppeldeutigkeit des Wortes frei entwickelten sich zwei unterschiedliche Auffassungen zum Begriff freie Software.
Diese werden von der FSF mit der häufig zitierten Phrase „free
speech, not [...] free beer“ (dt. „Meinungsfreiheit, nicht Freibier“)
beschrieben. Die FSF sieht Software demnach als ein allgemeines Gut
und Teil des sozialen Lebens, welches ähnlich schützenswert ist wie
die Meinungsfreiheit und genauso frei, d.h. quelloffen, sein sollte.
Frei im Sinne von Freiheit. Diese Auffassung ist häufig sehr restriktiv
und begrenzt die Kombination freier und geschlossener Software.18
Auf der andere Seite steht die Auffassung frei im Sinne von gratis zu
verstehen – wie Freibier. Diese Auffassung ist weniger restriktiv und
macht keine weiteren Annahmen über die Kombination von freier
und geschlossener Software. Freie Software zwingend als gratis
Software zu verstehen ist jedoch eine falsche Annahme. Im Umkehrschluss ist geschlossene Software auch nicht zwangsläufig kosten14
vgl. http://www.gnu.org/events/rms-nyu-2001-transcript.txt, Stand: 13.08.2013
16
vgl. http://www.gnu.org/gnu/about-gnu, Stand: 02.09.2013
17
vgl. http://www.gnu.org/graphics/fsf-logo.html, Stand: 04.07.2013
18
vgl. http://www.gnu.org/philosophy/free-sw.en.html, Stand: 12.06.2013
15
3 Hintergründe
pflichtig. Die FSF ermutigt Entwickler sogar dazu für freie Software
„so viel Geld zu verlangen wie sie wollen bzw. können“. 19
1998 gründete sich die Open Source Initiative (OSI) u.a. zur Lösung
dieser Problematik. Sie wollte die moralisierende Bedeutung von
freier Software nach der FSF von der eigentlichen Veröffentlichungsform der Software lösen und eine politisch bereinigte und marketingtaugliche Alternative erschaffen. Es entstand der Begriff opensource bzw. quelloffen. 20
A b b i l d u n g 2 - L o g o d e r O S I 21
Die OSI definiert den Begriff open-source in zehn Punkten:22
1. Die Software soll frei und ohne Hindernisse beliebig weitergegeben werden können.
2. Der Quellcode soll der Software beiliegen und jedem zugänglich
sein.
3. Die Modifizierung des Quellcodes ist erlaubt.
4. Modifizierungen zum originalen Quellcode müssen dokumentiert
werden.
5. Es dürfen keine Personen oder Gruppen von der Nutzung der
Software ausgeschlossen werden.
6. Die Lizenz darf keinen Einsatzzweck ausschließen.
7. Die Lizenz der Software muss ohne Hindernisse zugänglich sein.
8. Eine Lizenz darf sich nicht ausschließlich auf ein Produkt beziehen.
9. Die Lizenz darf die Nutzung einer anderen Software nicht ausschließen.
10. Die Lizenz muss technologieneutral sein und sich nicht auf eine
bestimmte Technologie beziehen oder eine andere ausschließen.
19
vgl. http://www.gnu.org/philosophy/selling.html, Stand: 02.09.2013
vgl. http://opensource.org/history, Stand: 17.05.2013
21
vgl. http://opensource.org/node/442, Stand: 04.07.2013
22
vgl. http://opensource.org/osd, Stand: 13.08.2013
20
5
3 Hintergründe
6
Innerhalb dieser Arbeit wird der Begriff quelloffene Software bzw.
OSS in einer vereinfachten Version nach OSI verwendet, um die
Doppeldeutigkeit von freier Software zu vermeiden:
Software, deren Quelltext für Menschen jederzeit verfügbar,
lesbar und verständlich ist und die ungehindert beliebig kopiert,
genutzt, verändert und weitergegeben werden kann, ist quelloffen.
Definition 1 – Quelloffene Software (OSS)
Sollte im Folgenden dennoch der Begriff freie Software verwendet
werden, wird er seinem ursprünglichen Sinn der FSF nach verstanden. In keinem Fall wird davon ausgegangen, dass die jeweilige
Software zwangsläufig gratis sein muss.
Anzumerken sei zum Schluss die Existenz der Formulierung free,
libre and open-source software, kurz FOSS bzw. FLOSS, welche die
beiden Lager der FSF und der OSI zu vereinen versucht. 23
3.3
OSS
IM
WEB
„The web [is] open-source by design.“24
Clientseitige Codekomponenten wie HTML, CSS oder JavaScript sind
im Web technisch bedingt für jeden Benutzer quelloffen. Es gibt
Werkzeuge um Code unleserlich zu gestalten, aber ebenso welche um
dies rückgängig zu machen. Da keiner dieser Komponenten als
Binärcode ausgeliefert wird, ist er aber für Menschen immer – mehr
oder weniger – lesbar.25,26
Da zusätzlich zu diesen technischen Hintergründen die meisten
Inhalte im Internet wie auch die Werkzeuge zur Erstellung dieser
gratis sind (ein einfacher Texteditor genügt) und das Internet durch
seine Anonymität ein Tummelplatz der freien Meinungsäußerung ist,
kann man sagen, dass OSS im Web durchaus eine spezielle Position
hat. Hier bündeln sich all die unterschiedlichen Ansichten zu OSS –
sei es Freiheit, Freibier oder einfach nur quelloffen.
Dies führt zu einer gewissen Erwartungshaltung von OSS-Projekten
im Web, welche u.a. Lizenzentscheidungen stark beeinflussen
können. Ein Beispiel für eine durch den Druck von Webentwicklern
durchgeführte Lizenzänderung befindet sich im Kapitel 4.5 LIZENZ.
23
vgl. https://fsfe.org/freesoftware/basics/comparison, Stand: 12.06.2013
vgl. Leutwyler, http://www.youtube.com/watch?v=bStff9X0oYI&t=5m22s, Stand: 17.05.2013
25
vgl. http://lisperator.net/uglifyjs/, Stand: 17.05.2013
26
vgl. https://github.com/einars/js-beautify, Stand: 17.05.2013
24
4 Konzeption und Planung
4
KONZEPTION
UND
7
PLANUNG
Vor der Veröffentlichung einer OSS müssen einige Vorentscheidungen getroffen werden. Zu diesen zählt auch die Festlegung auf
eine Lizenz. Da diese im Nachhinein nur abgeändert aber nicht
wieder zurück genommen werden kann, sollte die Wahl der Lizenz
wohlüberlegt sein.
Das folgende Kapitel beschäftigt sich deswegen mit Entscheidungen
und Überlegungen, die vor Projektbeginn durchgeführt werden
sollten.
4.1
ROLLEN
Personen, welche aktiv an OSS-Projekten mitarbeiten oder diese
verwenden, können verschiedenen Rollen zugewiesen werden. Eine
der wichtigsten Rollen, welche in der Form nicht bei geschlossener
Softwareentwicklung vorkommt, sind die Contributoren, welche umgangssprachlich am ehesten als ehrenamtliche Mitarbeiter umschrieben werden könnten.
Die im Folgenden vorgestellten Rollen wurden aus unterschiedlichen
Quellen zusammengefasst und variieren leicht in ihrer Bedeutung
und Bezeichnung. Sie lassen sich aber auf die meisten OSS-Projekte
übertragen. 27,28,29,30,31
4.1.1
CONTRIBUTOR
Ein Contributor32 ist eine Person, die etwas zu einem OSS-Projekt
beiträgt. Eine häufige Annahme ist, dass dieser Beitrag zwangsweise
in Form von Quellcode stattfinden muss, aber dies stimmt nicht.
Alles was dem Projekt hilft kann als Beitrag angesehen werden. Dazu
zählen:
•
•
•
•
•
•
27
die Verbesserung der Dokumentation
das Einreichen von Logos oder Grafiken
Supportleistungen
das Melden von Bugs
die Vergrößerung des Software-Ökosystems durch Plugins
Marketing in Form von Blogartikeln
vgl. http://source.android.com/source/roles.html, Stand: 26.06.2013
vgl. http://www.apache.org/foundation/how-it-works.html, Stand: 26.06.2013
29
vgl. http://www.eclipse.org/legal/committerguidelines.php, Stand: 26.06.2013
30
vgl. http://coding.smashingmagazine.com/2013/01/03/starting-open-source-project/, Stand: 26.06.2013
31
vgl. https://github.com/yui/yui3/wiki/Contributor-Model, Stand: 26.06.2013
32
contributor (englisch „Beitragende“)
28
Man nennt diese Beiträge auch Contributions. Besteht eine Contribution aus Quellcode, müssen Contributoren häufig direkt oder
indirekt einer Contributor License Agreement (CLA) zustimmen.
Diese Übereinstimmung regelt das Nutzungsrecht des übermittelten
Codes innerhalb des Projekts.
Ein Beispiel sei die Node.js CLA, welche elektronisch oder schriftlich
unterzeichnet werden kann und als Selbstständigkeitserklärung und
zur Rechteübertragung dient.33
Prinzipiell kann jeder Contributor eines OSS-Projekts werden,
allerdings haben sie keinen direkten Schreibzugriff auf die
originalen Projektdateien. Damit keine kritischen Fehler in die OSS
eingeschleust werden können, müssen die Veränderungen eines
Contributors durch einen Committer geprüft und genehmigt werden.
4.1.2
COMMITTER
Committer34 oder auch Verifier sind speziell autorisierte Contributoren. Sie erhalten einen direkten Schreibzugriff auf den Projektordner einer OSS. Während Contributoren Änderungen an der
Software einreichen und auf die Freigabe durch einen Committer
warten müssen, können Committer selbstständig und sofort Änderungen im Quellcode der Software durchführen.
In der Regel sind Committer ehemalige Contributoren, welche sich
über einen längeren Zeitraum aktiv und erfolgreich in einem Projekt
bewiesen haben und vom Reviewer zum Committer autorisiert
wurden.
4.1.3
REVIEWER
Reviewer 35 oder auch Approver sind erfahrene Committer, welche
Contributoren zu Committern ernennen oder ihnen diese Rang aberkennen können. Sie treffen strategisch wichtige Entscheidungen
für das OSS-Projekt und entscheiden welcher Quellcode zur OSS
hinzugefügt oder entfernt wird.
Reviewer werden vom Project Lead ernannt.
33
vgl. http://nodejs.org/cla.html, Stand: 13.08.2013
committer (englisch „Übertragende“)
35
reviewer (englisch „Prüfer“, „Gutachter“)
34
8
4.1.4
PROJECT LEAD
Project Leads 36 oder auch Tech Leads, Lead Developers, Project
Owner, Maintainer oder Chairs sind die Originalautoren des jeweiligen Quellcodes, welche ihre Rolle aber auch weiterreichen
können – vor allem wenn sie das Projekt verlassen. Sie besitzen die
höchste Entscheidungsgewalt in technischen und strategischen
Fragen, helfen bei der Qualitätssicherung, lösen Konflikte zwischen
anderen Projektmitgliedern, kommunizieren den Projektfortschritt
nach außen und lösen administrative Aufgaben innerhalb des
Projekts.
In kleinen Projekten übernimmt der Project Lead häufig die Aufgaben des Committers und Reviewers, sodass es praktisch lediglich
Contributoren und Project Leads gibt. Die Entwickler einer OSS
lassen sich somit in Gruppen mit und ohne Schreibrecht einteilen.
4.1.5
USER
User 37 sind die Endanwender der OSS. Je nachdem was die OSS
darstellt – ein Framework, eine Anwendung, etc. – sind User entweder andere Entwickler oder aber allgemeine Personen.
Neben den genannten Rollen kann es beliebig viele andere geben
mit eigenen projektspezifischen Namen und Aufgaben. Dies hängt
von der Projektgröße, der Hierarchie und der Organisation ab.
In manchen Fällen können auch Firmen eine der oben genannten
Rollen annehmen. Sie können als Sponsoren fungieren und die
nötige Infrastruktur, technische Unterstützung oder Rechtsbeistand
leisten (s. 7.11 SPONSORING). Dies macht sie zu einer Art Contributor.
Sie können aber auch Initiatoren einer OSS sein und die Rolle der
Project Leads besetzen, um strategische Entscheidungen zu treffen
(s. 5.1.1.1 „SINGLE VENDOR OPEN SOURCE PROJECTS“). Dies ist bspw. bei
Googles Android der Fall.
4.2
ZIELE
Wie beim klassischen Management ist es wichtig sich Zielstellungen
für die Entwicklung von OSS zu formulieren. Diese Ziele können
jedoch weitaus persönlicher und ihr Ausgang offener sein als bei geschlossener kommerzieller Software.
Während bei geschlossener kommerzieller Software die Rentabilität
und Gewinnoptimierung wichtige Zielstellungen sind, fallen diese
bei OSS häufig – aber nicht zwangsläufig – weg, besonders wenn
36
37
project lead (englisch „Projektleiter“, „Projektverantwortlicher“)
user (englisch „Nutzer“)
9
OSS-Projekte lediglich als Hobby betrieben werden oder sich
ausschließlich aus Spenden finanzieren (s. 7 M ONETARISIERUNG). Ein
OSS-Projekt kann auch ausschließlich altruistisch motiviert sein.
Aber welche Folgen ergeben sich daraus?
Angenommen die primäre Zielstellung eines Entwicklers ist es
„Problem X zu lösen“. Bisher existiert keine vorhandene Lösung
dieses Problems. Beginnt der Entwickler nun mit seiner Arbeit, so
kann es innerhalb dieses Zeitraums passieren, dass ein anderer
Entwickler einen Lösungsvorschlag zu Problem X veröffentlicht.
Im Konkurrenzkampf bei der Entwicklung proprietärer Software
hieße das, dass man als Gegenmaßnahme eine bessere, andere oder
günstigere Lösung veröffentlichen müsste. Dies entspricht den drei
generischen Wettbewerbsstrategien nach Michael Porter:38
•
•
•
Differenzierungsstrategie
Nischenstrategie
Kostenführerschaft (Preis-Mengen-Strategie)
Die Entwicklung quelloffener Software bietet jedoch noch mehr
Handlungsmöglichkeiten.
Da das primäre Ziel „Problem X zu lösen“ erreicht wurde – wenn auch
durch einen anderen Entwickler –, könnte das Projekt als erfolgreich
gelten und so abgeschlossen werden. Zumindest wenn kein weiteres
Ziel, wie das Erlangen eines Gewinns, formuliert wurde. Der Entwickler könnte aber auch die bestehende Lösung übernehmen und
auf dessen Basis eine bessere Lösung entwickeln oder seine Energie
in die Pflege der bestehenden Lösung stecken und sein eigenes
Projekt schließen.
Diese beiden Handlungswege sind ein integraler Bestandteil der
OSS-Kultur. Der Prozess, ein bestehendes Projekt zu nehmen und mit
eigenen Entwicklungen zu erweitern, wird als forken39 bezeichnet.
Die Bezeichnung des neu entstandenen Projekts lautet analog Fork.
Eine eigene flexible Zielstellung ist nicht nur wichtig um ein
erfolgreiches Projekt zu starten. Es ist genauso wichtig im Kopf zu
behalten, dass andere Entwickler ebenso vorgehen. Sich im Vorfeld
Gedanken darüber zu machen, wie man sein eigenes Projekt in ein
anderes migriert oder die Migration eines Fremdprojekts in das
eigene zulässt und ob man dies überhaupt möchte, kann später viel
Zeit sparen. Außerdem muss man im Kopf behalten, dass das Forken
des eigenen Projektes nicht als Ideenklau oder Kritik („Ich mache
dein Projekt besser!“) zu verstehen ist, sondern eher als
Bestätigung.
38
39
vgl. Schuh, Produktkomplexität managen: Strategien - Methoden - Tools, 2005, S. 56 ff.
to fork (englisch „abzweigen“, „abspalten“)
10
Aus der erwähnten Eigendynamik von OSS-Projekten ist bereits
herauszulesen, dass ein erfolgreiches Projekt viel Arbeit bedeutet.
Das Erstellen von Migrationsplänen, die Kontaktaufnahme zu
unbekannten Entwicklern und andere administrative Maßnahmen
stellen zeitaufwendige Arbeitsschritte dar, die nicht unmittelbar ein
besseres Produkt hervorbringen. Software kann relativ leicht
quelloffen veröffentlicht werden, aber ein Entwickler muss sich
fragen, was er damit erreichen möchte. Soll die Software von
anderen genutzt werden? Sollen andere die Software verbessern? In
beiden Fällen ist eine Dokumentation und Kommunikationsinfrastruktur vorteilhaft, um anderen Entwicklern die Nutzung zu
erleichtern. Dieser Aufwand muss – wie auch bei geschlossener
Software – mit dem Nutzen in einem guten Verhältnis stehen und
von jedem selbst entschieden werden.
Weitere Ziele von OSS können sein:40
•
•
•
•
•
•
•
•
40
„Kontrolle und Flexibilität“:
Bewahrung von Unabhängigkeit durch offene Datenformate
„Von der Avantgarde zum Mainstream“:
Sichern von Nischenmärkten, welche Wachstumsmärkte werden
können
„Sozialpsychologische Aspekte“:
Aufbau der eigenen Reputation, soziale Anerkennung und
Selbstverwirklichung
„Synergieeffekte“:
Mehr Kreativität durch Kooperation und durch Experimente mit
begrenzten Risiken
„Stabilität und Sicherheit“:
Dies sind keine allgemeingültigen Eigenschaften von OSS, aber
durch ihre Zugänglichkeit können Sicherheitslücken tendenziell
einfacher aufgedeckt werden.
„Abbruch und Neustart“:
OSS sichert die mögliche Weiterentwicklung über den Tod des
Autors hinaus.
Lernen und Weiterbildung
Erwirtschaftung von Geld (s. 7 M ONETARISIERUNG)
vgl. Prokop, Open Source Projektmanagement, 2010, S. 19 ff.
11
FALLSTUDIE
Die Stiftung The Document Foundation (TDF) betreut mit dem Ziel
der „Kontrolle und Flexibilität“ die quelloffene Office-Suite
LibreOffice sowie in Zusammenarbeit mit der Organization for the
Advancement of Structured Information Standards (OASIS) das
quelloffene Dateiformat OpenDocument (ODF). 41,42
Ihren Ursprung fand sie als Sun Microsystems, welche zuvor über
mehrere Jahre hinweg die quelloffene Office-Suite OpenOffice.org
betreuten, von Oracle übernommen wurde. Oracle ließ daraufhin
alle Contributoren darüber im Unklaren, wie die Betreuung der
OSS in Zukunft aussehen würde. Durch diesen Unmut entstand
LibreOffice als Fork von OpenOffice.org. Auf diesem Weg sollte vor
allem ein Vendor-Lock-In-Effekt vermieden werden, also eine
bindende und hinderliche Abhängigkeit zu einem Unternehmen.
Keine Firma, sondern die Community sollte die volle Kontrolle
über die Software besitzen. Als Stiftung ist sie vor weiteren
Übernahmen durch fremde Unternehmen geschützt und kann so –
im Gegensatz zu einer proprietären Software – die Weiterentwicklung sehr viel zukunftssicherer gestalten. Dies wirkt sich
wiederum förderlich auf ODF aus, welches das primäre Dateiformat
von LibreOffice ist. 43
ODF findet besonders in öffentlichen Einrichtungen immer mehr
Verbreitung. Sein Einsatz ist stabil, sicher, plattformunabhängig,
kostengünstig und bietet seinem Nutzer somit mehr Freiheiten bei
der Auswahl der benötigten Software als bei geschlossenen
Formaten, da es sowohl von vielen kostenpflichtigen als auch unentgeltlichen Programmen einfacher interpretiert werden kann.44
Fallstudie 1 – The Document Foundation
Diese teilweise ungenau formulierten Ziele können durch key performance indicators45 (KPIs) konkretisiert und parametrisiert werden.
Diese dienen dazu den Fortschritt und die Erreichung eines Zieles zu
messen. So könnte das Ziel „die eigene Reputation zu fördern“ daran
geknüpft sein, dass das OSS-Projekt bei GitHub (s. 5.5.2 H OSTINGDIENSTE FÜR SOFTWAREPROJEKTE) mehrfach favorisiert wird oder das Ziel
„Geld zu verdienen“ daran geknüpft sein, dass man pro Monat 50 €
über Spenden verdient. Startet man nun bspw. eine Marketing-
41
vgl. http://www.documentfoundation.org/, Stand: 13.08.2013
vgl. http://www.heise.de/open/meldung/The-Document-Foundation-tritt-OASIS-bei-1698800.html, Stand:
13.08.2013
43
vgl. http://listarchives.documentfoundation.org/www/announce/msg00000.html, Stand: 13.08.2013
44
vgl. http://www.bmi.bund.de/cln_156/SharedDocs/Pressemitteilungen/DE/2008/12/odf.html, Stand:
13.08.2013
45
key performance indicator (englisch „Leistungskennzahl“)
42
12
13
kampagne, so kann man messen, ob man sich den KPIs nähert oder
sich von ihnen entfernt. Dementsprechend können Aktionen bewertet und bei Misserfolg zukünftig vermieden werden.
Man beachte, dass die zuvor genannten Beispiele lediglich der Illustration dienen. Als betriebswirtschaftliche Kennzahl treten konkret
formulierte KPIs fast ausschließlich in gewinnorientierten OSSProjekten auf (s. 7 M ONETARISIERUNG)
4.3
KONKURRENZANALYSE
Der Begriff Konkurrent ist in der OSS-Kultur weit schwieriger zu
fassen als in der freien Wirtschaft. Prinzipiell kann jeder Konkurrent
auch ein Kooperationspartner sein. In den seltensten Fällen sehen
sich zwei verschiedene OSS-Projekte als echte Kontrahenten, welche
einander zu übertrumpfen versuchen. In den meisten Fällen verfolgen sie gemeinsame Ziele, die sie zusammen besser erreichen
können. Wenn zwei sich sehr ähnelnde OSS-Projekte jedoch nicht zu
einem größeren zusammengefasst werden können, hat dies möglicherweise historische oder politische Gründe.
Im zuvor genannten Fallbeispiel von The Document Foundation
entstand LibreOffice als Fork von OpenOffice.org durch die Übernahme von Sun Microsystems durch Oracle. Selbst nach dieser
Trennung wuchs der Unmut über Oracles Einfluss auf OpenOffice.org,
sodass sich der Konzern gezwungen sah das Projekt an die ehrenamtliche Apache Software Foundaton (ASF) abzugeben, wodurch
eine erneute Annäherung der beiden Projekte auf Codebasis wieder
möglich wurde. Solche Entwicklungen sind bei proprietärer Software
zwar nicht ausgeschlossen, treten mitunter aber durch das einfache
Forken von Projekten bei OSS häufiger auf.46,47
Konkurrenz kann somit aus unterschiedlichen Perspektiven definiert
werden. Die offensichtlichste Betrachtungsweise ist der Vergleich
von thematisch ähnlichen Projekten, weil sie die gleiche Problemstellung lösen wollen. Dies könnte z.B. der Vergleich mehrerer
Content Management Systeme (CMS, s. 5.5.6) wie WordPress, Drupal
oder Typo3 sein. In diesem Fall wäre es wichtig herauszufinden,
welche Unterschiede man zu den anderen Projekten aufweist. Stellt
man fest, dass man zu einem bestimmten Projekt kaum Unterschiede
besitzt, könnte man sich überlegen seine Arbeitszeit in das
bestehende Projekt zu stecken, anstatt ein neues zu erstellen.
Sowohl der Projektinitiator als auch andere Entwickler profitieren
von einer deutlichen Abgrenzung zu einem vermeintlich ähnlichen
46
vgl. http://www.netzwelt.de/news/84723-interview-thomas-krumbein-libreoffice-arbeit-oracle.html, Stand:
12.06.2013
47
vgl. http://www.golem.de/1106/83918.html, Stand: 12.06.2013
Konkurrenzprojekt. So können wichtige unique selling propositions48
(USPs) herausgebildet werden, die die Orientierung bei der Wahl
einer geeigneten Software verbessern.
FALLSTUDIE
Das Aufstellen von USPs dient nicht nur der eigenen Identifikation, sondern auch Marketingzwecken. Als das ambitionierte
Meteor, ein Framework für Echtzeitapplikationen, bei der Veröffentlichung vielfach in der Fachpresse erwähnt wurde, nutzte
dass sich ähnelnde Projekt Derby die Gelegenheit um detailliert
darzustellen, in welchen Punkten sie sich unterscheiden. Das
große öffentliche Interesse an Meteor half Derby seine eigene
Bekanntheit zu vergrößern. 49,50
Das besondere an diesem Artikel ist, dass sich die beiden Parteien
nicht als Feinde gegenüberstehen, sondern schlicht als zwei Projekte, die das gleiche Ziel auf unterschiedlichen Wegen erreichen
wollen. Der Blogartikel diente nicht der Bloßstellung des anderen
Projekts, sondern der Vorstellung der unterschiedlichen Philosophien.
So stehen beide Teams in Verbindung miteinander, um Erfahrungen auszutauschen und voneinander zu lernen.
Fallstudie 2 – Derby
Eine andere Perspektive um Konkurrenz zu definieren sind Projekte,
welche eine ähnliche Zielgruppe bedienen, aber thematisch eine
komplett andere Software sind. In diesem Fall besteht die Konkurrenz nicht darin möglichst viele Endanwender, sondern Contributoren zu gewinnen (s. 4.1 ROLLEN). So würde man bei erfolgreichen
OSS-Projekten analysieren, welche Kommunikationskanäle sie benutzen, wie die Dokumentation aufgebaut ist, wie sie sich finanzieren, etc., um erfolgreiche Konzepte zu übernehmen.
In beiden Fällen ist es wichtig zu verstehen, dass der Begriff
Konkurrenz innerhalb der open-source Kultur nicht synonym zu
Feind zu verwenden ist. Die Suche nach der Konkurrenz dient viel
mehr als Suche nach Projekten und Partnern mit ähnlichen Zielen,
welche zum Austausch von Erfahrungen genutzt werden können.
Im Folgenden werden die vier erfolgreiche OSS-Projekte Grunt,
Bootstrap, Node.js und AngularJS aus der Web und JavaScriptCommunity kurz analysiert. Diese Beispiele sollen illustrieren, nach
48
unique selling proposition (englisch „Alleinstellungsmerkmal“)
vgl. http://meteor.com/, Stand: 11.06.2013
50
vgl. http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/, Stand: 13.06.2013
49
14
welchen Aspekten ein Projekt untersucht werden kann und welche
Rückschlüsse man aus der Analyse schließen könnte:
15
Grunt
Typ
• Task runner
URL
• http://gruntjs.com/
Lizenz
• MIT License
Team
• 1 Lead Developer für Grunt (Ben Alman)
• 1 Lead Developer für offizielle Plugins (Tyler
Kellen)
• offen für Contributoren
Sponsoring
• Bocoup
Beschreibung
• Automatisiert Arbeitsschritte
• viele Plugins für Webentwickler für scaffolding,
building, lokale Server, etc.
Statistik
• GitHub: 5872 Stars, 595 Forks
(Stand: 14.06.2013)
• Sonstiges: 910 Plugins
Historie
• 23.03.2012: v0.3 - public
• 18.02.2013: v0.4 - major redesign
Technologie
• Node.js
Kommunikationskanäle
• GitHub (Repository, Issue-Tracker, Docs)
• Website (Docs), Blog (News)
• Twitter (News, verwandte Themen)
• IRC Channel (Support, Diskussion)
• StackOverflow #gruntjs (Support)
USPs
• große Auswahl an Plugins mit Fokus auf Webentwicklung (Backend und Frontend)
• sehr leicht zu konfigurieren
Sonstiges
• unterstützt die Entwicklung einer unabhängigen
Spezifikation zur Beschreibung von Tasks51
Tabelle 1 – Steckbrief: Grunt
51
vgl. https://github.com/node-task, Stand: 25.06.2013
16
Bootstrap
Typ
• Front-end framework
URL
• http://twitter.github.io/bootstrap/
• http://blog.getbootstrap.com/
Lizenz
• Apache License v2.0
Team
• 2 Lead Developer (Mark Otto, Jacob Thornton)
Sponsoring
• Twitter
Beschreibung
• CSS Framework für Responsive Design,
Scaffolding, Typografie und Grid System
• JavaScript basierte GUI Widgets
Statistik
(Stand: 25.06.2013)
• populärstes GitHub Projekt
Historie
• 19.08.2011: v1 - Desktop only
• 31.01.2012: v2 - Mobile Support
• 19.08.2013: v3 - Mobile first
Technologie
• Less, HTML, JavaScript
• GitHub (Repository, Issue-Tracker)
• Twitter (News, Support)
USPs
• extrem populär → gesicherte Entwicklung
• Mobile first
Sonstiges
• Ursprung: Twitters eigene Bedürfnisse 52
• nicht nur Framework, sondern auch Style Guide
• Credo: “Help awesome people do awesome
stuff.”
• Dokumentation mit Bootstrap selbst entwickelt
Tabelle 2 - Steckbrief: Bootstrap
52
vgl. http://alistapart.com/article/building-twitter-bootstrap, Stand: 25.06.2013
17
Node.js
Typ
• JavaScript Laufzeitumgebung
URL
• http://nodejs.org/
Lizenz
• MIT License
Team
• 1 Lead Developer (ursprünglich Ryan Dahl,
mittlerweile Isaac Z. Schlueter)
Sponsoring
• Joyent
Beschreibung
• eventbasiertes, nicht-blockendes I/O Modell für
datenintensive Netzwerkapplikationen
Statistik
(Stand: 25.06.2013)
• zweitpopulärstes GitHub Projekt
Historie
• 2009 erstmals vorgestellt 53
• kurz vor stabiler v1.0 54
Technologie
• JavaScript, C++
• GitHub (Repository, Issue-Tracker, Diskussion)
• 2 Mailinglisten (Diskussion, Support)
• IRC Channel (Support)
• Konferenz (News, Support, Diskussion)
USPs
• JavaScript auf dem Server
• sehr leichtgewichtig und modular
• sehr aktive Community
Sonstiges
• eigener Package Manager für Module: npm
• Google V8 als JavaScript Engine55
Tabelle 3 - Steckbrief: Node.js
53
vgl. http://www.youtube.com/watch?v=ztspvPYybIY, Stand: 25.06.2013
vgl. http://blog.strongloop.com/the-road-to-node-js-v1-0/, Stand: 15.08.2013
55
vgl. https://code.google.com/p/v8/, Stand: 25.06.2013
54
18
AngularJS
Typ
• Web App Framework
URL
• http://angularjs.org/
Lizenz
• MIT License
Team
• kein konkreter Lead Developer (Miško Hevery
letzter aktiver Originalautor mit Autorität)
Sponsoring
• Google
Beschreibung
• Templating mit two-way data binding (Models
aktualisieren View und umgekehrt)
• Model-View-Controller-Architektur
• ermöglicht Domain Specific Language (DSL)
Statistik
(Stand: 25.06.2013)
Historie
• Beginn: 2009 (noch nicht als OSS)
• 20.10.2010: v0.9 als OSS veröffentlicht
• 13.06.2012: v1.0
Technologie
• JavaScript
• GitHub (Repository, Issue-Tracker, Docs)
• Twitter, Google+ (News, verwandte Themen)
• Mailingliste (Diskussion)
• YouTube Channel (Support, Anleitungen)
• IRC Channel (Support)
USPs
• Dependency Injection
• Templates basieren auf HTML, nicht Strings
• großer Fokus auf Tests: Integration in Karma
Sonstiges
• Credo: Das Web so zeigen, als wäre es für
Applikationen entwickelt worden.
Tabelle 4 - Steckbrief: AngularJS
19
Diese vier Steckbriefe dienen nur als Beispiel, um eine mögliche
Vorgehensweise für detailliertere Analysen zu demonstrieren. Sie
reichen noch nicht aus, um statistisch valide Aussagen zu treffen.
Hätte man allerdings hinreichend viele Projekte analysiert, könnte
man erste Vermutungen anstellen:
•
•
•
•
•
•
Stehen hinter den meisten erfolgreichen OSS-Projekten größere
Firmen, welche die Entwicklung fördern?
Wird bei OSS aus dem Web Bereich größtenteils die MIT License
verwendet?
Ist GitHub die bevorzugte Plattform für open-source Webprojekte?
Ist Facebook für Entwickler ein irrelevanter Kommunikationskanal?
Benötigen OSS-Projekte zwangsläufig eine eigene Webseite um
erfolgreich zu sein?
etc.
Einige dieser Vermutungen lassen sich mit einer kurzen Recherche
weiter untermauern:
•
•
JavaScript ist mit 21% aller Projekte auf GitHub die dort am
meisten verbreitete Sprache. Die JavaScript-Community ist hier
demnach groß. 56
Nur eine Minderheit der Projekte auf GitHub wird unter einer
echten open-source Lizenz veröffentlicht. Von diesen ist die MIT
License jedoch die verbreitetste.57
Natürlich können OSS-Projekte noch auf weit mehr Charakteristiken
hin untersucht werden als den oben genannten. So könnten zusätzlich der Aufbau, die Präsentation und der Umfang der Dokumentationen analysiert werden, um die eigene Dokumentation bestmöglich aufzuarbeiten.
Durch die Analyse erfolgreicher OSS-Projekte kann man sehr viel
über deren Management lernen. Sie lohnt sich nicht nur zur Vorbereitung auf ein eigenes OSS-Projekt, sondern kann auch während
der Betreuung eines solchen durchgeführt werden z.B. wenn man
feststellt, dass das eigene Community Management problematisch
ist. In diesem Fall führt man speziell für diesen Punkt eine Analyse
durch.
Als letztes sei zu erwähnen, dass sich auch die Analyse eines
gescheiterten OSS-Projekts lohnen kann, um die Gründe für dessen
Misserfolg zu erfahren und so Problemen vorzubeugen.
56
57
vgl. https://github.com/languages, Stand: 25.06.2013
vgl. http://www.theregister.co.uk/2013/04/18/github_licensing_study/, Stand: 26.06.2013
20
4.4
ZIELGRUPPENANALYSE
Bei Zielgruppenanalysen stehen alle Personen, die mit einem OSSProjekt agieren, im Fokus der Analyse – nicht jedoch das Projekt
selbst. Eine Zielgruppenanalyse soll die Kommunikation zu dieser
verbessern und ihre Bedürfnisse aufdecken.
Bevor die Zielgruppen analysiert werden können, müssen sie definiert werden. In vielen Punkten sind die Zielgruppen die gleichen
Personen wie die Rollen innerhalb eines OSS-Projektes (s. 4.1
ROLLEN):
•
•
•
•
Contributoren, sowie Committer und Reviewer können zu einer
Zielgruppe zusammengefasst werden. Zur Vereinheitlichung
werden sie im Folgenden nur noch Contributoren genannt. Sie
bezeichnen Personen, welche zu Beginn außerhalb des Projekts
stehen, durch ihre Beiträge das Projekt verbessern und auf lange
Sicht ins Projekt integriert werden.
User sind diejenigen, die die OSS verwenden sollen. Da OSS in
vielen Fällen ein Problem lösen soll, welches die Contributoren
selbst haben, gehören sie in diesem Moment ebenfalls zu den
Usern. Sie können unter dieser Bedingung beiden Zielgruppen
zugeordnet werden.
Project Leads sind diejenigen, die die Zielgruppenanalyse durchführen und daher keine eigene Zielgruppe.
Die Presse kann ebenfalls als eine eigene Zielgruppe bezeichnet
werden. Ihr würde man bspw. einen schnellen Zugriff auf Logos
und Pressematerial des Projekts gewähren wollen.
Für die meisten OSS-Projekte sollten dies die wichtigsten Zielgruppen sein.
Je nach Projekt können diese Gruppen zusätzlich aus unterschiedlichen Interessengruppen zusammengesetzt sein: so können sich
Contributoren bspw. in Programmierer und Grafiker unterteilen von
denen jeder unterschiedliche Informationen benötigt. Die Bedürfnisse der jeweiligen (Unter-)Gruppe zu erkennen ist eine wichtige
Voraussetzung um die Kommunikation mit ihr zu verbessern.
Analog zur Konkurrenzanalyse kann eine beispielhafte Zielgruppenanalyse folgendermaßen ablaufen:
Gegeben sei ein JavaScript basiertes Web-Framework. Dieses soll
JavaScript Entwicklern bei der Erstellung von Webapplikationen
helfen. JavaScript Entwickler zählen demnach sowohl zur gewünschten Gruppe der Contributoren wie auch der User.
Welche Bedürfnisse müssen befriedigt werden, damit das Projekt
erfolgreich ist?
21
22
JavaScript Entwickler als Contributoren
Ziele
• lernen, Reputation aufbauen
• Projekt nach eigenen Willen lenken und
verbessern
Vorlieben
• MIT License für JavaScript Projekte
• lockerer Umgangston
• Node.js für Command Line Tools
• Grunt als Build Tool
• JSHint als Quality Tool
• GitHub als Hosting Platform
Abneigungen
• Browserinkompatibilitäten lösen
→ Hilfestellungen anbieten! Oder: Nur auf
moderne Browser konzentrieren
Probleme
• viele Alternative Sprachen zu JavaScript:
CoffeeScript, TypeScript, Dart, etc. 58
• kein etabliertes clientseitiges Package Management59
• Microframeworks ↔ große Frameworks 60
• sehr unterschiedliche Konventionen:
objektorientiert/funktional/prozedural,
imperativ/deklarativ, Code Style
→ strikte Projektkonvention erforderlich!
Sonstiges
• Konferenzen: Google IO , JSConf, JSConf.eu
• vielfach durch Mitarbeiter/Entwicklungen von
Google und Mozilla
→ News verfolgen! Google+ ist relevanter
Kommunikationskanal
• Prominenz: Paul Irish, Addy Osmani, Yehuda
Katz, John Resig, Douglas Crockford, Brendan
Eich, etc.
→ Für Marketing gewinnen?
Tabelle 5 - Steckbrief: JavaScript Entwickler als Contributoren
58
vgl. http://smthngsmwhr.wordpress.com/2013/02/25/javascript-and-friends-coffeescript-dart-and-typescript/,
Stand: 28.06.2013
59
vgl. http://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/, Stand:
28.06.2013
60
vgl. http://addyosmani.com/blog/prosconsmicroframeworks/, Stand: 28.06.2013
JavaScript Entwickler als User
Ziele
• Möchte schnell wissen, warum dieses Framework
besser als andere ist.
→ Vergleichbarkeit erhöhen durch Teilnahme an
TodoMVC 61
• Möchte schnell lernen wie man dieses Framework
verwendet.
→ übersichtliche und verständliche Dokumentation,
Beispiele, Cookbook
Vorlieben
• Performance
• Wartbarkeit
• Verständlichkeit
• Workflowoptimierung
• guter Support, starke Community, schneller Kontakt
→ einfachen Zugang zu Twitter und Co. ermöglichen
Abneigungen
• Fehler, Bugs
• inkonsistente API
• schwierige Migration zu neuen Versionen
• Browserinkompatibilitäten
Probleme
• nutzt lieber, was er gewohnt ist: jQuery
→ Können populäre Frameworks wiederverwendet
bzw. integriert werden?
• verwirrt von zu vielen ähnlichen Frameworks
→ genaue Abgrenzung zu anderen Frameworks verdeutlichen
Sonstiges
• kümmert sich nicht um interne Funktionsweise
Tabelle 6 - Steckbrief: JavaScript Entwickler als User
61
vgl. http://todomvc.com/, Stand: 28.06.2013
23
Vorausgesetzt die oben stehenden Mutmaßungen wurden durch
genügend Daten validiert, so können nun strategische Entscheidungen für das eigentliche Projekt getroffen werden:
JavaScript Entwickler als Contributoren:
o Verwende Grunt als Build Tool, nicht Ant!
o Wenn Command Line Tools erforderlich sind, dann am besten
Node.js basierte verwenden.
o Verwende GitHub als Hosting Plattform.
o Verwende die MIT License als Lizenz.
o Stelle verbindliche Code Styles und Konventionen durch
Quality Tools wie JSHint sicher.
• JavaScript Entwickler als User:
o Vergleiche dein Framework mit anderen Frameworks und
grenze es ab.
o Stelle eine umfangreiche Dokumentation bereit: Beispiele,
Erklärungen, Referenzen, etc.
o Biete Support auf beliebten Kommunikationskanälen an.
o Erfinde das Rad nicht neu! Wenn möglich, verwende populäre Frameworks.
•
Verschiedene Methoden helfen beim Zusammentragen der benötigten Daten, um solche Schlussfolgerungen zu treffen. Dies können
Umfragen und direkte Interviews mit den entsprechenden Zielpersonen sein. Der Kontakt zur Zielgruppe kann leicht über einschlägige
Foren, Communities oder einem direkten Anschreiben in einem
sozialen Netzwerk aufgenommen werden.
Die sogenannten Personae stellen ein Hilfsmittel dar, um die eigene
Perspektive zu wechseln und so ein Problem aus Sicht der Zielgruppe
zu betrachten. Zu diesem Zweck erstellt man möglichst detaillierte
Steckbriefe zu erfundenen Personen, welche Teil einer Zielgruppe
sind. Die Steckbriefe helfen dabei, sich besser in eine andere imaginäre Person hineinzuversetzen. So können die Bedürfnisse der Zielgruppe besser verstanden werden.62
Alternativ können einzelne Personen einer Zielgruppe auch fester
Bestandteil des OSS-Projekts werden. Initiator von Podlove ist Tim
Pritlove, einer der bekanntesten deutschen Podcaster. Er gehört zur
Zielgruppe von Podlove selbst, sammelt und stellt eigene Anforderungen an das Projekt und gibt diese den Entwicklern weiter.
Dadurch fungiert er als Visionär und Mentor innerhalb des Projekts.
Außerdem dient er selbst als Marketingkanal in dem er anderen
Podcastern vom Projekt erzählt und sein aufgebautes Netzwerk an
Hörern für Crowdfunding nutzt (s. 7.10.1 CROWDFUNDING).63
62
63
vgl. Adlin, Pruitt, The Essential Persona Lifecycle, 2010, S. 1
vgl. http://metaebene.me/blog/2013/02/27/podlove-crowdfunding-gestartet/, Stand: 15.08.2013
24
4.5
LIZENZ
Die Wahl der richtigen Lizenz stellt für viele Entwickler, die ihre
Software quelloffen veröffentlichen wollen, eine große Hürde da.
Sie sind teilweise sehr komplex, ihre Formulierungen richten sich an
Juristen und es ist teilweise schwer, ihre Unterschiede herauszufinden.
Umso schlimmer ist dieses Problem, da die Wahl der Lizenz eines der
wichtigsten Schritte auf dem Weg zu OSS ist. Wie Jeff Atwood
feststellt, ist Quellcode, welcher ohne Lizenz veröffentlicht wird,
automatisch urheberrechtlich geschützt. Die Nutzung des Codes ist
damit nicht erlaubt bzw. die Erlaubnis der Nutzung müsste von jeder
Person individuell beim Autor erfragt werden.64
Der Code wäre erst rechtlich legal nutzbar, wenn er gemeinfrei
werden würde. Dies passiert, wenn das Urheberrecht erlischt, was
nach deutschem Recht 70 Jahre nach dem Tod des Autors der Fall
wäre.65
Damit OSS frei genutzt und modifiziert werden kann, muss eine
Lizenz für die Veröffentlichung gewählt werden.
Analog zum unterschiedlichen Verständnis von freier Software
lassen sich Lizenzen für OSS in zwei große Gruppe einteilen:
•
•
freizügige permissive Lizenzen
strenge Lizenzen
Freizügige Lizenzen enthalten nur sehr wenige Beschränkungen.
Programmierer können den unter einer freizügigen Lizenz stehenden
Quellcode in der Regel nach eigenem Ermessen modifizieren und
einsetzen. Dies ist jedoch nicht mit Gemeinfreiheit gleichzusetzen,
da die freizügigen Lizenzen einzelne kleine Regeln zur Nutzung,
Verbreitung und Änderung der Software vorsehen. Zu ihnen kann
bspw. die zwingende Nennung des Originalautors gehören. Ein
wichtiger Vertreter der freizügigen Lizenz ist die MIT License.
Strenge Lizenzen werden hauptsächlich bei freier Software eingesetzt, welche frei im Sinne von Freiheit verstehen. Sie sollen
häufig sicherstellen, dass die Verwendung offenen Quellcodes
seinerseits wieder offenen Quellcode hervorbringen muss. Anders
formuliert: Verändert man Quellcode unter einer strengen Lizenz,
dann muss der neue Code ebenfalls unter derselben Lizenz veröffentlicht werden. Man nennt diesen Vorgang Copyleft und spricht
von einem viralen Effekt, da die Lizenz vererbt wird. Damit soll
sichergestellt werden, dass Änderungen und Verbesserungen freier
64
65
vgl. http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html, Stand: 02.09.2013
s. § 64 UrhG
25
Software nicht in geschlossener Software untergehen und der
Allgemeinheit vorenthalten werden. Freizügige Lizenzen stellen
solche Bedingungen nicht. Ein wichtiger Vertreter einer strengen
Lizenz ist die GPL License.66
Strenge Lizenzen klingen zunächst sehr attraktiv – OSS erstellt
wieder OSS. Aber viele Entwickler sind zunächst davon abgeschreckt,
da sie nicht einschätzen können, inwiefern sie Quellcode unter einer
strengen Lizenz in kommerziellen Projekten und geschlossener
Software einsetzen dürfen. Außerdem sind strenge Lizenzen tendenziell komplizierter als freizügige Lizenzen. Sie bestehen aus mehr
Klauseln, welche striktere Bedingungen beschreiben.
FALLSTUDIE
Wie unter 3.3 OSS IM W EB beschrieben, stellt das Web einen
besonderen Technologiebereich dar. Entwickler aus dem Web
Umfeld reagieren teilweise allergisch auf restriktive und strenge
Lizenzen, die sie in ihrer Freiheit einschränken. Man erkennt an
dieser Stelle wie problematisch die Definition von Freiheit ist.
Obwohl strenge Lizenzen die Freiheit schützen sollen, in dem
jeglicher Code quelloffen ist, so fühlen sich Entwickler in ihrer
Freiheit beschnitten, da sie mitunter keine geschlossene Software
erstellen dürfen. Projektmanager von OSS sollten diese Problematik kennen, um negativen Reaktionen entgegenzuwirken.
Ein Projekt, das dies schmerzhaft feststellen musste, ist Meteor.
Bei seiner Einführung war die Begeisterung von Endanwendern
über die technische Leistung des Frameworks zunächst groß, aber
Webentwickler waren von der Entscheidung das Projekt unter GPL
zu veröffentlichen zu verunsichert und machten ihrem Unmut in
Blogs und sozialen Netzwerken Luft. Reaktionen wie „as exciting
as Meteor is (VERY!), their approach to licensing kills it for me“
oder „now that it's GPL I will not be touching it with a ten foot
pole“ zweier Nutzer auf Hacker News zeigen die Enttäuschung bei
der Wahl der Lizenz. Der Blogger Olov Lassus stellt fest: „the web
developer community seems to prefer permissive licenses“.67,68
66
vgl. Prokop, Open Source Projektmanagement, 2010, S. 26
vgl. https://news.ycombinator.com/item?id=3836212, Stand: 11.06.2013
68
vgl. http://blog.lassus.se/2012/04/meteor-meets-nogpl.html, Stand: 22.08.2013
67
26
27
Letzten Endes musste Meteor durch den Druck der Entwicklergemeinde ihre Lizenz von GPL auf MIT umstellen. So ist das
Framework nun „free to use Meteor without restriction for both
open-source and closed-source applications“.69,70
Fallstudie 3 – Meteor
Anzumerken sei, dass Projekte mehrere Lizenzen besitzen können.
Dies kann dazu dienen die Lizenzkompatibilität zu fremder Software
zu erhöhen oder aber um eine Software für unterschiedliche Einsatzzwecke – z.B. kommerziell und nicht kommerziell – mit anderen
Restriktionen auszustatten (s. 7.6 DUAL LICENSING).71
Nichtjuristen finden unter ChooseALicense und tl;drLegal verständliche Erklärungen zu den Klauseln der gängigsten OSS-Lizenzen.72,73
Im Folgenden seien die wichtigsten Lizenzen aufgelistet:
4.5.1
GENERAL PUBLIC LICENSE
Die General Public License (GPL) entstammt dem GNU Projekt bzw.
der FSF und ist eine strenge Lizenz. Veränderte GPL-Werke müssen
ebenfalls wieder unter GPL veröffentlicht werden. Sie ist die erste
ihrer Art.74
4.5.2
LESSER GENERAL PUBLIC LICENSE
Die Lesser General Public License (LGPL) ist ähnlich der GPL und
entstammt ebenfalls dem GNU Projekt. Sie erlaubt die Verwendung
von LGPL-Software innerhalb von proprietärer Software, wenn der
offene Zugang zur LGPL-Software noch möglich ist. Diese Bedingung
kann u.a. mit dynamischen Programmbibliotheken erfüllt werden.
Sie wurde von der FSF als Alternative zu freizügigen Lizenzen
geschaffen. 75
4.5.3
AFFERO GENERAL PUBLIC LICENSE
Die Affero General Public License (AGPL) ist eine weitere Ableitung
der GPL und fügt dieser eine weitere Bedingung hinzu: „[W]ird ein
Programm auf einem Server ausgeführt und kommuniziert dort mit
69
vgl. https://news.ycombinator.com/item?id=3870700, Stand: 11.06.2013
vgl. http://www.meteor.com/blog/2012/04/20/mit-license-http-request-package-made-with-meteor, Stand:
22.08.2013
71
72
vgl. http://choosealicense.com/, Stand: 16.07.2013
73
vgl. http://www.tldrlegal.com/, Stand: 16.07.2013
74
vgl. http://www.gnu.org/licenses/gpl.html, Stand: 11.06.2013
75
vgl. http://www.gnu.org/licenses/lgpl-3.0.en.html, Stand: 26.06.2013
70
28
anderen Nutzern, muss der Server auch den entsprechenden Quellcode des ausgeführten Programms zum Herunterladen bereitstellen.
Wird eine modifizierte Programmversion ausgeführt, muss der Server
Nutzern Zugriff auf den modifizierten Quellcode geben.“ Normalerweise greift die GPL nur wenn Kopien des Quellcodes in Umlauf
gebracht werden. Dies ist bei einer serverseitigen Anwendung selten
der Fall. Modifiziert jemand eine GPL-lizensierte Software und führt
diese lediglich auf seinem eigenen Server aus, würden seine Änderungen nicht öffentlich sichtbar und ebenfalls GPL-lizensiert sein.
Dieser Umstand wird mit der AGPL geregelt. 76
4.5.4
MASSACHUSETTS INSTITUTE
OF
TECHNOLOGY LICENSE
Die Massachusetts Institute of Technology License (MIT License) ist
eine freizügige und sehr kurze Lizenz. Sie zählt zu den liberalsten
Lizenzen. Ihre einzige Bedingung ist, dass diese Lizenz nicht vom
Code getrennt werden darf. Ansonsten erlaubt sie jegliche Freiheiten zur weiteren Verwendung. Sie ist auch unter den Namen X11
License und Expat License bekannt. 77
FALLSTUDIE
Im Idealfall decken sich die Vorstellungen und Anforderungen der
Entwickler und der User über die bevorzugte Lizenz. Häufig gilt es
jedoch Kompromisse einzugehen.
Die Wahl der Lizenz für das Projekt node-xmpp von Astro fiel zunächst auf die GPL. Er identifiziert sich mit den Vorstellungen der
FSF und möchte die größtmögliche Offenlegung des Quellcodes
und Freiheiten für die User wahren. Da Technologien sehr schnell
veralten und ständig neu erfunden werden, sieht er keine große
Notwendigkeit darin, Quellcode vor anderen zu verstecken. Er
begründet dies auch mit der von Harold Abelson und Gerald
Sussman getroffenen Aussage: „Programs must be written for
people to read, and only incidentally for machines to execute.“ 78
Problematisch bei GPL ist jedoch, dass Contributions aus dem
kommerziellen Bereich durch ihre Firmenrichtlinien behindert
werden. Er hat sich deswegen für den Kompromiss entschieden,
Contributions höher zu gewichten als Freiheiten, wenn sein opensource Projekt eine Bibliothek für andere Entwickler ist. Deswegen
hat er node-xmpp auf die MIT License umgestellt.
76
vgl. http://www.gnu.org/licenses/why-affero-gpl.html, Stand: 28.08.2013
vgl. http://opensource.org/licenses/MIT, Stand: 11.06.2013
78
vgl. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html, Stand: 23.08.2013
77
Sollte es sich bei seinem OSS-Projekt jedoch um eine fertige
Anwendung für Endanwender handeln, so greift er bevorzugt auf
die GPL oder AGPL zurück.
Fallstudie 4 – node-xmpp
4.5.5
BERKELEY SOFTWARE DISTRIBUTION LICENSE
Die Berkeley Software Distribution License (BSD License) ähnelt der
MIT License. Sie verbietet aber zusätzlich die Verwendung der
Namen der Originalautoren als Werbemittel.79
4.5.6
APACHE LICENSE
Die Apache License ist der BSD License sehr ähnlich und führt als
weitere Bedingung ein, dass Änderungen in den Originaldateien
gekennzeichnet sein müssen.80
4.5.7
CREATIVE COMMONS
Da OSS nicht nur aus Quellcode, sondern auch aus Grafiken, Logos,
Sounds und Dokumentationen bestehen kann, werden für diese
Bereiche eigene Lizenzen verwendet. Die wichtigste Lizenz für Grafiken, Texte, etc. ist die Creative Commons (CC), welche wiederum
aus verschiedenen Modulen besteht. Die freizügigste Variante der CC
ist die CC BY. Sie erlaubt jegliche Verwendung, Bearbeitung und
Weitergabe einer Grafik, eines Textes, etc., so lange der ursprüngliche Autor weiter genannt wird.81
Diese Arbeit steht unter der Lizenz der CC BY.
A b b i l d u n g 3 - L o g o d e r C r e a t i v e C o m m o n s 82
79
vgl. http://opensource.org/licenses/bsd-license.php, Stand: 26.06.2013
vgl. http://opensource.org/licenses/Apache-2.0, Stand: 11.06.2013
81
vgl. http://creativecommons.org/licenses/, Stand: 12.09.2013
82
vgl. http://creativecommons.org/about/downloads, Stand: 04.07.2013
80
29
4.6
ZUSAMMENFASSUNG
In diesem Kapitel wurde Folgendes dargelegt:
•
•
•
•
•
•
•
•
Ein OSS-Projekt wird neben den ursprünglichen Autoren von
Contributoren entwickelt. Contributoren können z.B. zum Commiter aufsteigen, um Schreibrechte für das Projekt zu erhalten.
Contributions können jegliche Beiträge zu einem Projekt sein –
nicht nur Quellcode.
Forken bezeichnet das Abspalten eines OSS-Projekts.
Die Ziele der OSS-Entwickler sind sehr verschieden. Sie können
ideologischer, wirtschaftlicher oder persönlicher Natur sein.
Konkurrenten sind Projekte, die das gleiche Ziel auf unterschiedlichen Wegen erreichen wollen. Sie sind nicht im umgangssprachlichen Sinn gegeneinander agierende Kontrahenten.
Zur Zielgruppe eines OSS-Projekts zählen die User bzw. Endanwender ebenso wie die Contributoren.
Die Wahl einer entsprechenden Lizenz ist Voraussetzung zur Veröffentlichung und Verwendung einer OSS.
Lizenzen für OSS teilen sich in zwei Kategorien: freizügig und
streng.
30
5 Entwicklung und Organisation
5
ENTWICKLUNG
UND
ORGANISATION
Der Aufwand des Managements einer laufenden Entwicklung kann
durch verschiedene Hilfestellungen gering gehalten werden. Zu
diesen zählen Management- und Entwicklungsmodelle, welche Vorgaben zur Arbeitsweise festlegen, aber auch eine stabile Infrastruktur zur Erleichterung der alltäglichen Aufgaben.
Im folgenden Kapitel werden einige dieser Hilfen vorgestellt.
5.1
HIERARCHIE-
UND
ORGANISATIONSMODELLE
Das Projektmanagement bei der Entwicklung geschlossener kommerzieller Software wird klassischerweise über mehr oder weniger steile
Hierarchien gelöst. Aufgaben werden zur unteren Ebene der Entwicklern herunter gereicht und Verantwortlichkeiten wandern zur
oberen Ebene des Managements. Ein Blick auf die beteiligten Rollen
innerhalb eines OSS-Projekts (s. 4.1 ROLLEN) lässt zunächst
Ähnliches für die Entwicklung von OSS annehmen: unten stehen die
Contributoren, darüber die Committers und Reviewers und ganz
oben die Projects Leads.
Ist dem wirklich so? Gibt es bei OSS-Projekten nur starre und steile
Hierarchien? Lassen sich Softwareprojekte nicht ohne Hierarchien
lösen?
David Nalley, Mitglied bei Apache, beantwortet die Frage, von wem
ein OSS-Projekt überhaupt geleitet wird, eindeutig: „Largely by the
people doing the work.“83
Diejenigen, die die meiste Arbeit leisten, haben auch die größte
Entscheidungsgewalt. Für ihn existieren keine direkten Hierarchien
innerhalb von OSS, da die Autoritäten dynamisch vergeben werden.
Für Nalley ist dies ein wünschenswerter Zustand, da er innovative
Arbeit hervorbringe. Er unterscheidet hier aber klar zwischen
Innovation und Fortschritt und räumt ein, dass Hierarchien
möglicherweise mehr Fortschritt zur Folge hätten. Die Vergabe der
Autorität nach Arbeitsaufwand mache für Contributoren einen
großen Teil der Motivation aus (s. 5.3 M OTIVATION), da sie die
Richtung eines Projekts aktiv ändern könnten. Management bzw.
Führerschaft heißt für ihn die Arbeit der Contributoren so leicht wie
möglich zu gestalten – nicht selbst Designentscheidungen zu treffen
und Richtungen vorzugeben.
Dass diese Annahme nicht auf alle OSS-Projekte übertragbar sein
kann, zeigt bereits die klare Hierarchie in den zuvor erwähnten
83
vgl. http://opensource.com/business/11/2/leadership-open-source-communities, Stand: 01.07.2013
31
32
Rollen. Zudem kann Fortschritt in vielen Fällen ein wünschenswerteres Ziel sein als Innovation. Möglicherweise ist dies ein
Zeichen dafür, dass man in diesem Fall keine allgemeingültige
Aussage zur Beschreibung für die eine Hierarchie und Organisation
für OSS-Projekte treffen kann.
5.1.1
NACH
STÜRMER
Matthias Stürmer, Vorstandsmitglied der /ch/open, unterteilt OSSProjekte aus den zuvor genannten Gründen noch einmal in vier
Gruppen, wobei er das Zusammenspiel zwischen Firmen, Organisationen und Einzelpersonen als Contributoren als Kriterium nimmt:84
5.1.1.1
„SINGLE VENDOR OPEN SOURCE PROJECTS“
Wenn hinter der OSS eine einzelne Firma steht, spricht man von
„Single vendor85 open source projects“. Diese Firma behält das volle
Urheberrecht der Software und Contributoren übertragen ihr
Urheberrecht an ihren Quellcodeänderungen über entsprechende
CLAs an die Firma. Auf diese Weise kann die ursprüngliche Firma ihre
Software sowohl unter open-source als auch unter kommerziellen
Lizenzen verbreiten und weiter Einnahmen durch Lizenzverkäufe
generieren. Die entsprechende open-source Lizenz könnte bspw. die
Nutzung der Software auf andere OSS beschränken und erst der Kauf
einer kommerziellen Lizenz erlaubt den Einsatz mit proprietärer
Software.
Diese Art von OSS-Projekten steht durchaus in der Kritik, da die
Entscheidungsgewalt der Firma größer ist als die der Community und
es schwerer ist Contributoren zu finden, welche ihr Urheberrecht
abtreten würden. Dennoch können solche Projekte sehr erfolgreich
werden – ein Beispiel hierfür wäre MySQL.
„Single vendor open source projects“ können aber weiterhin geforkt
werden. So ist MariaDB ein Fork von MySQL. In diesem Fall darf nur
die GPL-lizensierte Version von MySQL geforkt und weiterentwickelt
werden und ist dadurch an GPL gebunden. Die Verwendung einer
kommerziellen Lizenz bleibt MySQL vorbehalten.86
Da die Entwicklung der OSS größtenteils innerhalb einer einzelnen
Firma stattfindet, kann man die reguläre Firmenhierarchie im Projekt
wiederfinden.
84
vgl. http://opensource.com/business/13/6/four-types-organizational-structures-within-open-sourcecommunities, Stand: 01.07.2013
85
vendor (englisch „Anbieter“, „Lieferant“, hier: „Firma“)
86
vgl. http://www.admin-magazine.com/Articles/MariaDB-vs.-MySQL, Stand: 02.07.2013
5.1.1.2
„DEVELOPER COMMUNITIES“
OSS von „Developer communities“ werden von beliebig vielen Contributoren entwickelt und in der Regel von einer gemeinnützigen
Organisation verwaltet, seltener von einzelnen Personen. Jeder Contributor verfolgt unterschiedliche Ziele mit der Partizipation an dem
Projekt, arbeitet an ihm aber freiwillig mit. Administrative Aufgaben
werden von der jeweiligen Organisation übernommen. So betreut
The Document Foundation die Software LibreOffice oder Mozilla den
Browser Firefox.87,88
Grundlegende Projektentscheidungen wie bspw. die Wahl der Lizenz
werden zwischen der Organisation und den Hauptcontributoren
getroffen. Das Urheberrecht liegt bei der Organisation, die zum Teil
aus den Hauptcontributoren besteht. Alle anderen Contributoren
unterzeichnen bei „Developer communities“ deswegen meistens
ebenfalls eine CLA.
Die Hierarchie in diesen Projekten ist sehr unterschiedlich und hängt
von der Infrastruktur und den Bedingungen der verwaltenden Organisation ab.
Auch wenn ein Teil der Entscheidungsgewalt der Contributoren abgegeben wird, erhalten sie dafür ebenbürtige Gegenleistungen wie
Rechtsbeistand. Außerdem verfolgen die verwaltenden Organisationen größtenteils gemeinnützige Ziele, sodass ihnen die Qualität
und der Fortbestand der OSS sehr wichtig ist – ganz im Sinne der
Contributoren. Als Beispiel sei wieder Mozilla genannt, die diesen
Anspruch in einem Manifest wiedergeben.89
5.1.1.3
„USER COMMUNITIES“
„User communities“ ähneln „Developer communities“ jedoch liegt
das Urheberrecht an einer OSS direkt bei den Contributoren und
nicht bei einer verwaltenden Organisation. Die Contributoren sind
dabei gleichzeitig die User der OSS. Sie verwalten sich selbst und
entscheiden gemeinsam über die weitere Entwicklung. Hier findet
sich am ehesten die von Nalley beschriebene hierarchielose Teamzusammensetzung.
„User communities“ können dennoch von anderen Firmen oder
Organisationen unterstützt werden z.B. wenn mehrere Firmen auf
ein größeres Ziel hin zusammenarbeiten ohne einer einzelnen Firma
oder Organisation ein größeres Stimmrecht als einer anderen zuzugestehen.
87
vgl. http://www.documentfoundation.org/, Stand: 02.07.2013
vgl. https://www.mozilla.org/de/contribute/, Stand: 02.07.2013
89
vlg. http://www.mozilla.org/de/about/manifesto/, Stand: 05.08.2013
88
33
Ein Beispiel hierfür wäre WHATWG, eine Arbeitsgruppe zur Entwicklung des HTML Standards zusammengesetzt aus verschiedenen
Webentwicklern, welche u.a. von Apple, Opera und Mozilla unterstützt werden.90
Ebenfalls zu einer „User community“ zählt die GENIVI Alliance, eine
Allianz mehrerer Autohersteller, deren Ziel die Entwicklung eines
offenen In-Vehicle Infotainment-Systems ist.91
Wichtig für Initiatoren eines „User communitiy“-Projekts ist die
Offenheit und die Bereitschaft, andere Meinungen von Contributoren zu tolerieren und anzunehmen, um erfolgreich zu sein. Sie
benötigen die Eigenschaft das Wohl des Projekts über persönliche
Vorlieben zu stellen. Andernfalls forken Contributoren das Projekt
und entwickeln komplett an den Interessen des Initiators vorbei.
5.1.1.4
„OPEN SOURCE COMPETENCE CENTERS“
„Open source competence centers“ betreuen selbst keine OSSProjekte, sondern dienen als Schnittstelle zwischen allen Stakeholdern von OSS. Sie können unterschiedliche Rollen einnehmen:
•
•
•
•
•
Aggregatoren:
Sammeln und Verbreiten von Neuigkeiten von OSS
Katalysatoren:
Zusammenbringen und fördern von Interessengemeinschaften
Mediatoren:
Vermitteln zwischen Firmen und Contributoren
Marketing:
Bewerben von OSS
Consulting:
Beratung von Firmen und Contributoren in der Nutzung und Entwicklung von OSS
Diese Liste stellt nur einen Auszug von möglichen Aufgabenfeldern
dar.
Beispiele für „Open source competence centers“ wären die Open
Source Business Alliance oder OSS Watch. Beide bieten Beratung für
den Einsatz von OSS an und versuchen ihre Verbreitung zu erhöhen.
Ihre Beratung richtet sich auch an Entwickler von OSS bezüglich der
Wahl der richtigen Lizenz oder eines Geschäftsmodells.92,93
90
vgl. http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F, Stand: 02.07.2013
vgl. http://www.genivi.org/, Stand: 15.08.2013
92
vgl. http://www.osb-alliance.de/, Stand: 03.07.2013
93
vgl. http://www.oss-watch.ac.uk/, Stand: 03.07.2013
91
34
35
Die Größe, der Aufbau, die Finanzierung und die Aktivitäten von
„Open source competence centers“ fallen sehr unterschiedlich aus
und können nicht verallgemeinert werden.
5.1.2
NACH
PROKOP
Michael Prokop, Entwickler des Linux-Live-Systems Grml, geht einen
anderen Weg und betrachtet drei mögliche Hierarchien für OSSProjekte, welche keine Unterscheidung zwischen Firmen oder
Contributoren als OSS-Projektmitglieder machen: 94,95
5.1.2.1
„WOHLWOLLENDER DIKTATOR“
Der „wohlwollende Diktator“ ist eine einzelne Person innerhalb des
OSS-Projekts, welche die Richtung der weiteren Entwicklung vorgibt.
Er trifft Entscheidungen auf Basis der Meinung von Experten,
etablierten Projektmitgliedern. Einwände gegen seine Entscheidungen können vorgetragen werden, jedoch haben Contributoren
nicht das Recht sie zu verhindern. Die Motivation dieser Hierarchie
ist nicht die Entmündigung der Contributoren, sondern die Begrenzung von unproduktiven Diskussionen. Ihr liegt die Vorstellung
zugrunde, dass es manchmal sinnvoller ist überhaupt eine Entscheidung zu treffen, als endlos über die beste Entscheidung zu
diskutieren.
Ein prominentes Beispiel für diesen Hierarchietyp ist Linus Torvald,
welcher als „wohlwollender Diktator“ für den Linux-Kernel fungiert.
Contributoren können Änderungen an Submodulen des Kernels bei
der zuständigen Person, dem Maintainer des Submoduls, beantragen. Diese machen eine Vorabprüfung, ob die Quellcodeänderungen übernommen werden können und sollten und geben erst
danach den Antrag an Linus Torvald weiter, welcher letztendlich die
Entscheidung trifft. Der ganze Prozess findet öffentlich statt und
kann jederzeit kommentiert werden, um Torvalds Entscheidung zu
beeinflussen.
Auch Astro sieht sich als „wohlwollender Diktator“ in seinen OSSProjekten: „Jedem steht es frei zu forken.“ Wer mit einer Entscheidung unzufrieden ist, kann das Projekt problemlos selbstständig weiterführen.
94
95
vgl. http://grml.org/, Stand: 03.09.2013
5.1.2.2
„GEWÄHLTE REGIERUNG“
Komplexere Hierarchien als beim „wohlwollenden Diktator“ findet
man bei der „gewählten Regierung“, welche bei Teams bzw. Organisationen auftritt, die mehr als eine OSS betreuen. Häufig wird die
Regierung durch ein gewähltes Komitee abgebildet.
Ein Beispiel für diesen Typ wäre die bereits erwähnte ASF. Pro
betreutes Projekt gibt es ein Project management committee (PMC)96
bestehend aus gewählten Contributoren, welche sich noch einmal in
PMC Member 97 und PMC Chair98 unterteilen, wobei ein PCM Chair eine
höhere Entscheidungsgewalt besitzt als ein PCM Member. Zusammen
bilden sie die Entscheidungshierarchie innerhalb eines ASF Projekts
ab. Zusätzlich werden jährlich neun Mitglieder in die Boards of
Directors gewählt, welche projektübergreifende Interessen der ASF
betreuen.
5.1.2.3
MERITOKRATIE
Der letzte Hierarchietyp nach Prokop ist die Meritokratie: die „Herrschaft der Verdienstvollen“. Sie deckt sich mit der eingangs vorgestellten Hierarchie nach Nalley. Alle OSS-Projekte, die sich aus
sich selbst heraus organisieren, können der Meritokratie zugeordnet
werden. Sie ist sehr dynamisch und vergibt Projektmitgliedern umso
mehr Stimmrecht, je mehr sie sich am Projekt beteiligen.
Ein Beispiel für eine Meritokratie ist die GNOME Foundation, welche
die Entwicklung der Desktop-Umgebung GNOME betreuen. Aber auch
die ASF spricht von sich selbst als Meritokratie – trotz gewähltem
PMC. Daran wird deutlich, dass der Übergang zwischen den einzelnen Organisationsformen fließend ist.99,100
Letztendlich ist festzuhalten, dass die korrekte Wahl einer Hierarchie stark vom eigentlichen Projekt abhängt:
•
•
•
96
Habe ich ein sehr großes Team? Dann ist die „gewählte
Regierung“ wohlmöglich der Meritokratie vorzuziehen.
Fehlt es mir an Visionen? Dann benötige ich eventuell einen
„wohlwollenden Diktator“.
Entsteht meine OSS aus kommerziellen Gründen innerhalb einer
Firma? Dann bleibt möglicherweise nur ein „Single vendor open
source project“ als einzige Auswahlmöglichkeit.
ähnlich einem Project Lead innerhalb der Apache Organisation
member (englisch „Mitglied“)
98
chair (englisch „Vorsitzender“)
99
vgl. https://wiki.gnome.org/Foundation/Charter, Stand: 15.08.2013
100
vgl. http://www.apache.org/foundation/how-it-works.html#meritocracy, Stand: 15.08.2013
97
36
•
37
Benötige ich eventuell Rechtsbeistand oder eine komplizierte
Infrastruktur? Dann wäre eine „Developer community“ ratsam.
5.2
FUNKTIONEN
UND
ROLLEN
DES
MANAGEMENTS
Das Management eines OSS-Projekts im umgangssprachlichen Sinne
ist in den meisten Fällen mit den Project Leads gleichzusetzen.
Dieses im deutschen Sprachgebrauch übliche Verständnis steht die
im angelsächsischen Raum verbreitete funktionale Perspektive
gegenüber, welche Management unabhängig von der ausführenden
Personen und dessen hierarchische Position anhand seiner Funktionen definiert:
„Management ist ein Komplex von Steuerungsaufgaben“, welche
betriebliche Funktionen wie bspw. Einkauf, Produktion und
Verkauf sichern und kontrollieren. Sie sind „auf jeder Hierarchiestufe zu erfüllen, wenn auch unterschiedlich nach Art und Umfang“.101
Definition 2 – Management
Im Folgenden seien wichtige Modelle zur Definition dieser Steuerungsaufgaben vorgestellt. Ziel dieser Modelle ist es die Mechanismen hinter komplexen Prozessen aufzudecken. Auf diese Weise
können Fehler und Probleme in Projekten besser erkannt und gelöst
werden.
5.2.1
MANAGEMENTFUNKTIONEN
NACH
K O O N T Z / O’D O N N E L L
Der klassische „Fünferkanon von Managementfunktionen“ der Professoren Harold Koontz und Cyril O’Donnell beschreibt fünf Funktionen, die in einem linear ablaufenden Prozess die iterative Arbeit
des Managements beschreiben. Dieses idealisierte Modell wird
basierend auf den Anfangsbuchstaben der Funktionen mit POSDC
abgekürzt: 102
1. Planung (planning):
Die Planung ist der Ausgangspunkt des Managementprozesses
und beinhaltet die Untersuchung was und wie etwas erreicht
werden soll. Sie definiert das Ziel.
2. Organisation (organizing):
Die Organisation stellt das Handlungsgefüge her, welches zur
Umsetzung des Ziels benötigten wird. Wichtiger Bestandteil
dieser Funktion ist die Definition von Aufgabeneinheiten und
101
102
vgl. Schreyögg, Koch, Grundlagen des Managements, 2010, S. 8
vgl. Schreyögg, Koch, Grundlagen des Managements, 2010, S. 9 ff.
38
Errichtung eines Kommunikationskanals zwischen allen Beteiligten.
3. Personaleinsatz (staffing):
Der Personaleinsatz beinhaltet die detaillierte Zuweisung von
Aufgabeneinheiten an entsprechende Personen, sowie die Beurteilung, den Erhalt und die Weiterbildung des Personals.
4. Führung (directing):
Die Führung konzentriert sich auf die Sicherstellung und Feinsteuerung der erfolgreichen Umsetzung durch das Verbessern
der Motivation sowie der Kommunikation und das Lösen von
Konflikten zwischen allen Beteiligten.
5. Kontrolle (controlling):
Innerhalb der Kontrolle werden die Ergebnisse gesammelt und
mit der ursprünglichen Zielsetzung verglichen. Negative Abweichungen müssen auf Korrekturmöglichkeiten hin untersucht
werden. Die Daten, die durch die Kontrolle entstehen, sind
Grundlage für den nächsten Managementprozess, der wieder bei
der Planung beginnt.
1. Planung
5. Kontrolle
4. Führung
2. Organisation
3. Personaleinsatz
A b b i l d u n g 4 – M a n a g e m e n t f u n k t i o n e n n a c h K o o n t z / O ’ D o n n e l 103
Abstrakte Modelle wie das der Managementfunktionen von Koontz
und O’Donnel lassen sich in der Regel nur teilweise auf die reale Welt
übertragen. Wie dies aussehen könnte soll das folgende Beispiel von
Grunt zeigen.
103
in Anlehnung an Managementfunktionen nach Koontz/O’Donnell
39
FALLSTUDIE
Grunt ist ein JavaScript-basiertes Automationstool, welches sich
primär auf Arbeitsschritte in der Webentwicklung konzentriert. Es
wurde ursprünglich von Ben Alman entwickelt.104
Bis Version 0.3 enthielt Grunt selbst interne Funktionen zur Automatisierung, welche bspw. einen Webserver starten konnten.
Eines der Ziele für Version 0.4 war eine bessere Skalierbarkeit.
Diese sollte durch eine erhöhte Modularisierung erreicht werden,
indem jede interne Automatisierungsfunktion als eigenständiges
offizielles Plugin veröffentlicht wird (Planung). Aus diesem Grund
wurden neue Repositories (s. 5.5.1 VERSIONSVERWALTUNG) angelegt:
ein allgemeines für alle offiziellen Plugins von Grunt und ein
weiteres für jedes Plugin selbst. So konnten alle Plugins unabhängig voneinander verwaltet werden (Organisation). Ben Alman
entwickelte die Grunt API weiter und übergab das Management
und die Aufsicht aller offiziellen Plugins an den Grunt Contributor
Tyler Kellen weiter, welcher die eigentliche Entwicklung eines
Plugins wiederum anderen Contributoren überließ (Personaleinsatz). Alman und Kellen kommunizierten das Konzept an alle
Contributoren und verwiesen Supportanfragen zu ehemals internen Funktionen an die Contributoren der neuen Plugins weiter
(Führung). Mittels Ticketsystem und Checklisten wurde die Entwicklung der Plugins, aber auch die Umstellung der Dokumentation gemessen und verglichen (Kontrolle). 105,106,107,108,109
Anschließend konnte Grunt als Version 0.4 veröffentlicht werden.
Mit der Aufstellung einer Roadmap für Version 0.5 begann eine
neue Planungsphase, sodass sich der Zyklus der Managementfunktionen wiederholt.110
Fallstudie 5 – Grunt
5.2.2
MANAGEMENTROLLEN
NACH
MINTZBERG
Koontz und O’Donnells Modell ist zwar weit verbreitet, jedoch durch
seine starke Vereinfachung kaum praxistauglich. Henry Mintzberg,
Professor für Betriebswirtschaftslehre und Management, hat in
empirischen Studien untersucht, inwiefern sich dieses Modell von
104
vgl. http://weblog.bocoup.com/introducing-grunt/, Stand: 16.08.2013
vgl. https://github.com/gruntjs/grunt-contrib/tree/18f375bc59fbbef25f8f32fe572cbfb7fad93002, Stand:
16.08.2013
106
vgl. http://weblog.bocoup.com/tearing-grunt-apart/, Stand: 16.08.2013
107
vgl. https://github.com/gruntjs/grunt/issues/549, Stand: 16.08.2013
108
109
110
vgl. https://github.com/gruntjs/grunt/wiki/Roadmap, Stand: 16.08.2013
105
der Realität unterscheidet. So sei der oben beschriebene Zyklus
keinesfalls geschlossen und hätte keinen fest definierten Anfang
bzw. kein fest definiertes Ende. Der reale Arbeitsalltag sei zu
zerstückelt von Ad-hoc-Aufgaben für einen einzelnen stringenten
Prozess. Einer der Hauptaufgaben sei die Kommunikation, welche
zuhören genauso einschließt wie zu befehligen und häufig müsse
man Entscheidungen treffen, ohne alle benötigten Informationen zu
besitzen.111
Aus diesen Untersuchungen heraus hat Mintzberg das flexiblere
Modell der zehn Managementrollen entwickelt, welche in drei
Gruppen gegliedert werden können:112
•
•
•
„interpersonelle Rollen“ zur Pflege von Beziehungen
„Informationsrollen“ zum Aufnehmen und Abgeben von Daten
„Entscheidungsrollen“ zum Steuern von Prozessen
Jede dieser Rollen besitzt andere Funktionen. Ein Manager kann
eine oder mehrere dieser Rollen zu unterschiedlichen Zeitpunkten
annehmen und so situationsbedingt folgende Funktionen erfüllen:
111
112
vgl. Schreyögg, Koch, Grundlagen des Managements, 2010, S. 13 f.
40
41
Kategorie
Rolle
Funktion
Interpersonelle
Rollen
Galionsfigur
(figurehead)
Symbolfigur nach außen und
innen
Vorgesetzter
(leader)
Mitarbeiter auswählen, leiten,
motivieren und trainieren
Vernetzer
(liasion)
Kontakte nach außen und innen
aufbauen und pflegen
Radarschirm
(monitor)
Informationen von innen und
außen suchen und sammeln
Sender
(disseminator)
Informationen innerhalb des
Teams verteilen
Sprecher
(spokesperson)
Informationen außerhalb des
Teams verteilen
Innovator
(entrepreneur)
Ideen für Verbesserungen initiieren und umsetzen
Problemlöser
(disturbance handler)
Konflikte schlichten und
Probleme lösen
Ressourcenzuteiler
(ressource allocator)
Ressourcen wie Zeit, Geld oder
Mannkraft an Aufgabenpakete
verteilen
Verhandlungsführer
(negotiator)
Verhandlungen bezüglich des
Projekts besuchen, leiten und
beeinflussen
Informationsrollen
Entscheidungsrollen
T a b e l l e 7 – M a n a g e m e n t r o l l e n n a c h M i n t z b e r g 113
113
in Anlehnung an Managementrollen nach Mintzberg
5.2.3
MANAGEMENTKOMPETENZEN
42
NACH
KATZ
Nachdem nun ein Funktionskatalog für Manager erstellt wurde, lohnt
es sich zu betrachten, welche Voraussetzungen ein Manager besitzen
muss, um diese Funktionen erfüllen zu können. Nach Robert Katz
benötigen Manager dafür drei Schlüsselkompetenzen, so genannte
skills:114
•
•
•
„Technische Kompetenz“:
Sie beschreibt das ausführliche Wissen über Techniken und
Methoden der Managementlehre und die Fähigkeiten, dieses
Wissen in der Praxis erfolgreich anzuwenden.
„Soziale Kompetenz“:
Sie beschreibt die Fähigkeit möglichst effektiv mit anderen
Menschen zusammenzuarbeiten, ihre Handlungsmotivation zu
kennen, kulturelle Unterschiede zu tolerieren bzw. zu würdigen
und sich in sie hineinzuversetzen.
„Konzeptionelle Kompetenz“:
Sie beschreibt die Fähigkeit komplexe Probleme zu strukturieren
und effektiv und effizient zu lösen. Bestandteile dieser Kompetenz sind eine hohe Lernfähigkeit, die Problembetrachtung
aus verschiedenen Perspektiven, flexibles und schnell anpassbares Planen sowie das Denken außerhalb der Box.
Alle drei Kompetenzen wirken unterschiedlich stark gewichtet zusammen und tragen so zum Gelingen einer Managementfunktion bei.
5.3
MOTIVATION
Die Motivation hinter OSS stellt eine ihrer größten Stärken dar. In
den meisten Fällen arbeiten Contributoren freiwillig, unentgeltlich
und in ihrer Freizeit am OSS. Ihre Motivation muss dementsprechend
hoch sein, um so viel Arbeit in ein Projekt zu stecken.
Erste Begründungen für die hohe Motivation wurden bereits unter
4.2 ZIELE genannt. Es lohnt sich jedoch ein detaillierter Blick in
gängige Motivationstheorien, damit die Motivation aller Projektmitglieder während der Entwicklung gefördert und einem Abflachen
entgegengewirkt wird.
114
Die Motivation beschreibt einen Beweggrund, die Befriedigung
eines Bedürfnisses, aus dem der Mensch heraus handelt. Dabei ist
das so genannte Anstrengungsniveau, also die Richtung, die
Stärke und die Dauer der Anstrengungen, die jemand auf sich
nimmt um ein Ziel zu erreichen, umso größer je höher die Motivation ist.115,116
Definition 3 – Motivation
Das heißt, dass Projektmitglieder umso produktiver arbeiten, je
höher ihre Motivation ist. Das Verbessern und Aufrechterhalten der
Motivation im Team ist damit ein wichtiges Ziel des Managements.
Man unterscheidet zwischen zwei Formen der Motivation:
•
•
intrinsische Motivation:
Sie ist die Motivation, die von innen kommt. Dabei werden
innere Bedürfnisse wie die Neugier oder der Wille etwas zu
lernen befriedigt.
extrinsische Motivation:
Sie ist die Motivation, die von außen kommt. In der Regel
entsteht sie durch externe Belohnungen wie das Gehalt, das man
vom Arbeitgeber bekommt.
Bei dieser Unterteilung ist wichtig zu beachten, dass intrinsische
Motivation im Allgemeinen ein größeres Anstrengungsniveau erreicht als extrinsische Motivation, letztere jedoch einfacher zu beeinflussen ist, da sie per Definition von außen kommt. So kann man
bspw. einfacher das Gehalt von einem Mitarbeiter erhöhen als die
Lust am Lernen.
Da Contributoren von OSS nur selten für ihre Arbeit entlohnt werden
und sie sich hauptsächlich aus persönlichen Gründen einem OSSProjekt widmen, ist ihre intrinsische Motivation tendenziell sehr
hoch.
Warum müssen Project Leads eines OSS dennoch so viel Fokus auf die
Motivation der Contributoren legen, wenn sie doch automatisch
hoch motiviert sind? Um die besten Contributoren in der OSSCommunity wird ebenso stark geworben wie um besten Mitarbeiter in
der freien Wirtschaft. Hat man schließlich gute Contributoren
gewonnen, möchte man sie auch so lange wie möglich an das Projekt
binden.
Aus diesem Grund werden im Folgenden Modelle vorgestellt, welche
dabei helfen sollen, die Motivation der Contributoren zu bewahren
und zu erhöhen.
115
116
vgl. Kulbe, Grundwissen Psychologie, Soziologie und Pädagogik, 2009, S. 64 f.
vgl. Jost, Organisation und Motivation, 2008, S. 98
43
5.3.1
ERWARTUNGS-VALENZ-THEORIE
44
NACH
VROOM
Die Erwartungs-Valenz-Theorie oder auch Valenz-InstrumentalitätsErwartungs-Theorie (VIE-Theorie) des Wirtschaftspsychologen Victor
Harold Vroom betrachtet die Verknüpfung zwischen individuellen
Wünschen der Mitarbeitermotivation (Individualziele) und den
betrieblichen Zielen (Organisationsziele).117
Seine Idee ist, dass Mitarbeiter aufbauend auf den Organisationszielen auf mindestens zwei Handlungswegen ihre Individualziele
erreichen wollen, welche aber von den Organisationszielen abweichen können. Mitarbeiter wählen einen Handlungsweg nach
seiner Attraktivität (Valenz) und der geschätzten Wahrscheinlichkeit, ob sie ihr Ziel darüber erreichen können (Erwartung bzw.
subjektive Wahrscheinlichkeit). Ob ein Organisationsziel dem Individualziel hinderlich oder förderlich ist wird als Instrumentalität
bezeichnet. Das folgende Beispiel soll dies verdeutlichen:
Ein Organisationsziel eines Unternehmens sei die überdurchschnittliche Produktivität der Mitarbeiter. Je produktiver ein Mitarbeiter
ist, desto mehr Lohn erhält er.
Eines der Individualziele von Mitarbeiter A ist es mehr Lohn zu
erhalten. Die Instrumentalität ist hoch, da das Organisationsziel
zum Individualziel führt. Allerdings bedeutet dies Überstunden und
Mitarbeiter A glaubt nicht, dass er noch produktiver arbeiten kann.
Die Valenz dieses Handlungsweges und die Erwartung an sein
Gelingen sind gering.
Mitarbeiter B glaubt, noch produktiver arbeiten zu können und da er
seine Arbeit liebt, machen ihm Überstunden Freude. Die Erwartung
und Valenz sind hoch. Allerdings ist sein größtes Individualziel die
Akzeptanz seiner Kollegen. Er möchte nicht der produktivste
Mitarbeiter sein und als Streber gelten. Die Instrumentalität ist
deswegen gering.
Mitarbeiter C wiederum möchte mehr Lohn und glaubt produktiver
arbeiten zu können. Er möchte sich dafür aber nicht anstrengen. Die
Instrumentalität und Erwartung sind bei ihm hoch, die Valenz jedoch
klein.
Am Beispiel wird deutlich, wie die Motivation der Mitarbeiter nach
der VIE-Theorie verbessert werden kann. Je genauer ich die Individualwünsche meiner Mitarbeiter bzw. Contributoren kenne, umso
besser kann ich meine Organisationsziele mit ihnen abgleichen und
erhöhe somit ihre Motivation.
Ein Lösungsvorschlag für dieses Beispiel könnte sein, dass Mitarbeiter A mehr Lohn erhält, in dem er eine Aufgabe mit mehr
117
45
Verantwortung und Risiko übernimmt, welche aber nicht unbedingt
schwierigere Arbeit und Überstunden beinhaltet. Mitarbeiter B
könnte andere produktive Teamkollegen bekommen, damit er sich
nicht als Streber fühlt und dadurch produktiver arbeitet. Für Mitarbeiter C könnte man versuchen die Valenz durch mehr Urlaub zu
erhöhen.
Bei OSS könnten Contributoren, die ihre Popularität steigern
möchten, vermehrt Marketingmaßnahmen wie das Verfassen von
Blogartikeln zugewiesen werden und anderen Contributoren, die vor
allem viel lernen möchten, die Implementierung experimenteller
neuer Funktionen.
In OSS-Teams, welche keine starke Hierarchie besitzen (s. 5.1.2.3
M ERITOKRATIE), ergeben sich diese Zuweisungen häufig automatisch.
Die meisten Contributoren übernehmen einfach die Aufgaben, die
ihren Individualzielen entsprechen. So lässt sich mit der VIE-Theorie
die hohe Motivation von Contributoren erklären.
Aufgabe des Managements ist in diesem Fall weniger die Verbesserung der Instrumentalität, sondern der Valenz und der
Erwartung in dem bspw. die Dokumentation für einen reibungslosen
Projekteinstieg verbessert wird.
5.3.2
BEDÜRFNISHIERARCHIE
NACH
MASLOW
Die Bedürfnishierarchie bzw. –pyramide des Psychologen Abraham
Maslow ordnet die Motivationsstärke dem sukzessiven Erreichen von
hierarchisch geordneten Bedürfnisklassen zu. 118
118
Wachstumsbedürfnisse
4. Wertschätzungsbedürfnisse
3. Soziale Bedürfnisse
Defizitbedürfnisse
Motivationsstärke
5. Selbstverwirklichung
46
2. Sicherheitsbedürfnisse
1. Physiologische Bedürfnisse
A b b i l d u n g 5 – B e d ü r f n i s h i e r a r c h i e n a c h M a s l o w 119
Die Bedürfnishierarchie besagt, dass Menschen danach streben Bedürfnisse zu befriedigen (Defizitprinzip) und dass Bedürfnisse aus
hierarchisch niedrigen Bedürfnisklassen vor höheren befriedigt
werden müssen (Progressionsprinzip). Die Motivationsstärke nimmt
bei der Befriedigung hierarchisch höherer Bedürfnisse zu.
Bedürfnisse lassen sich den folgenden fünf Bedürfnisklassen zuordnen:
1. Physiologische Bedürfnisse:
Sie ergeben sich aus überlebenswichtigen Grundvoraussetzungen für Menschen. Zu ihnen zählen Essen, Trinken, Kleidung,
Wohnung, etc.
2. Sicherheitsbedürfnis:
Es drückt das Verlangen nach Schutz gegenüber Unfällen, Raub,
Kriminalität, Krankheiten, etc. aus.
3. Soziale Bedürfnisse:
Zu ihnen zählt der Wunsch nach gemeinschaftlichem Leben,
Zusammengehörigkeit und sozialen Beziehungen.
4. Wertschätzungsbedürfnisse:
Sie stehen für den Wunsch nach Anerkennung, Achtung und
Vertrauen von anderen Personen, aber auch für Selbstachtung.
5. Selbstverwirklichung:
Sie ist die höchste Bedürfnisklasse und beinhaltet die Unabhängigkeit und die Entfaltung der eigenen Persönlichkeit.
Die Selbstverwirklichung und teilweise die Wertschätzungsbedürfnisse gruppiert Maslow zu den Wachstumsbedürfnissen, welche nie
abschließend befriedigt werden können. Deswegen gibt es auch
keine sechste Bedürfnisklasse. Die restlichen Bedürfnisklassen zählt
er zu den vollständig befriedigbaren Defizitbedürfnissen.
119
in Anlehnung an Bedürfnishierarchie nach Maslow
47
Nach Maslows Modell ist es für das Management wichtig, möglichst
viele hierarchisch niedrige Bedürfnisklassen möglichst gut zu
befriedigen, um hoch motivierte Mitarbeiter bzw. Contributoren zu
erhalten. Gerade bei OSS-Projekten ist es jedoch schwer, die unteren
zwei Bedürfnisklassen zu beeinflussen. Die dritte Klasse der sozialen
Bedürfnisse lässt sich hingegen aktiv gestalten. So können Manager
Konferenzen einberufen, damit sich aus den virtuellen Kontakten
eines OSS-Projekts auch reale Freundschaften entwickeln können.
Maslows Bedürfnispyramide ist nicht frei von Kritik. Hierarchisch
niedrige Bedürfnisklassen können und müssen nicht immer zu 100%
befriedigt werden. So besteht immer eine Gefahr durch Krankheiten,
welche das Sicherheitsbedürfnis beeinflusst. Der Grad, um wie viel
Prozent eine Bedürfnisklasse befriedigt sein muss, um zur nächsten
zu gelangen, ist von Person zu Person unterschiedlich. Die Hierarchie und Gewichtung der einzelnen Klassen können ebenfalls unterschiedlich sein. So sind für manche Menschen soziale Bedürfnisse
wichtiger als die eigene Sicherheit.
Neben der Motivation dient die Maslowsche Bedürfnispyramide auch
zur Bindung von Mitarbeitern bzw. Contributoren an das Unternehmen bzw. das OSS-Projekt: Je mehr Bedürfnisklassen innerhalb
des Unternehmens bzw. des OSS-Projekts befriedigt werden, umso
größer ist die Bindung.
So können soziale Bedürfnisse ausschließlich im privaten Umfeld
befriedigt werden und die Bindung bleibt gering oder sie können
zusätzlich innerhalb der Arbeit befriedigt werden und so eine hohe
Bindung erzeugen.
Die hohe Motivation von Contributoren in OSS-Projekten lässt sich
so auch mit der Maslowschen Bedürfnishierarchie erklären. Die
Teilnahme an OSS fördert nicht nur die Wertschätzung durch andere
Menschen, sondern auch die Selbstverwirklichung. Schließlich steht
es jedem Contributor frei ein fremdes Projekt nach eigenen Vorstellungen zu gestalten – durch Mitarbeit oder als Fork.
5.3.3
ZWEI-FAKTOREN-THEORIE
NACH
HERZBERG
Die Zwei-Faktoren-Theorie des Psychologen Frederick Herzberg
basiert auf der Annahme, dass Zufriedenheit (satisfiers) und
Unzufriedenheit (dissatisfiers) nicht die zwei Enden einer Skala
sind, sondern zwei verschiedenen Dimensionen entsprechen. 120
Nach Herzberg führt das lösen von Unzufriedenheit nicht automatisch zu Zufriedenheit, sondern zu Nicht-Unzufriedenheit. Das
Gleiche trifft umgekehrt auf Zufriedenheit zu.
120
•
•
48
Zufriedenheit:
Sie wird beeinflusst durch Motivatoren, welche sich auf die
Arbeit selbst beziehen. Zu ihnen zählen Erfolgserlebnisse, Anerkennung, die Arbeit an sich, Verantwortung, Karriere und die
Persönlichkeitsentfaltung. Motivatoren beziehen sich immer auf
den Arbeitsinhalt und die Selbstverwirklichung.
Unzufriedenheit:
Sie wird durch arbeitsinterne und -externe Hygienefaktoren beeinflusst. Zu ihnen zählen die Personalpolitik, der eigene Status,
die Kompetenz der Vorgesetzten, das Arbeitsklima, die Arbeitssicherheit, etc.
Daraus ergibt sich, dass eine hohe Motivationsstärke erst bei NichtUnzufriedenheit und Zufriedenheit entsteht:
Hygienefaktoren
Nicht-Unzufriedenheit
Zufriedenheit
Motivatoren
Nicht-Zufriedenheit
Unzufriedenheit
Motivationsstärke
A b b i l d u n g 6 – Z w e i - F a k t o r e n - T h e o r i e n a c h H e r z b e r g 121
Für Manager bedeutet dies, dass sie unabhängig von der Anzahl und
Qualität der Motivatoren (mehr Geld, mehr Urlaub, etc.) niemanden
motivieren können, wenn im Gegenzug keine Hygienefaktoren erfüllt
werden. Sie müssen sich somit der Verbesserung der Motivation im
gleichen Maß wie der Beseitigung der Unzufriedenheit widmen.
121
in Anlehnung an Zwei-Faktoren-Theorie nach Herzberg
49
Herzbergs Modell steht insofern in der Kritik, dass sie empirisch in
der Arbeitswelt nicht konsequent anwendbar ist. Der Grund dafür ist,
dass Motivatoren zu Hygienefaktoren werden können, wenn sie über
einen langen Zeitraum bedient wurden. Umgekehrt können Hygienefaktoren ebenfalls zu Motivatoren werden.
Ein Beispiel aus der OSS-Entwicklung ist, dass Anerkennung motivierend wirkt. Hat sich ein Entwickler jedoch an sie gewöhnt, so wird
er unzufrieden, wenn sie ausbleibt. In diesem Fall ist aus der Anerkennung als Motivator ein Hygienefaktor geworden.
5.3.4
JOB-CHARACTERISTICS
NACH
HACKMAN/ OLDHAM
Nach Greg Oldham und Richard Hackman bestehen Arbeitsaufgaben
aus fünf Dimensionen, welche zusammen die intrinsische Motivation
von Mitarbeitern bzw. Contributoren beeinflussen. Sie sind im JobCharacteristics-Model beschrieben:122,123
•
•
•
•
•
Aufgabenvielfalt (skill variety):
Wie viele unterschiedliche Fertigkeiten und Fähigkeiten werden
bei der Arbeit eingesetzt?
Ganzheitscharakter (task identity):
Kann man einen eigenständigen und individuellen Beitrag durch
die Arbeit am Endprodukt erkennen?
Bedeutungsgehalt (task significance):
Ist die Arbeit für andere Personen innerhalb oder außerhalb des
Projekts von Bedeutung?
Autonomie (autonomy):
Kann die Arbeit unabhängig von anderen Personen, zeitlichen
und sachlichen Begrenzungen durchgeführt werden?
Rückkoppelung (feedback):
Wie viele Ergebnisse und Auswirkungen der Arbeit werden dem
Verantwortlichen zurückgegeben?
Anhand dieser fünf Dimensionen lässt sich erneut die hohe
intrinsische Motivation von Contributoren erklären:
Der eigene Beitrag am Projekt ist in der Versionsverwaltung für
jeden sichtbar (hoher Ganzheitscharakter) und das Projekt kann
maßgeblich beeinflusst werden (hoher Bedeutungsinhalt). Die
Arbeit erfolgt sehr autonom ohne größere Restriktionen und Vorgaben. In Bug-Trackern und sozialen Netz–werken erhalten Contributoren viel Rückkoppelung. Die Aufgabenvielfalt kann nach
eigenem Ermessen gewählt werden. Wer nicht programmieren
möchte, pflegt die Dokumentation oder hilft im Support aus.
122
123
vgl. Ridder, Personalwirtschaftslehre, 2009, S. 224 f.
Aufgabe des Managements ist es alle fünf Dimensionen zu fördern,
um hochmotivierte Contributoren zu erhalten.
FALLSTUDIE
In einem Blogartikel beschreibt Joost de Valk, Contributor von
WebKit und Autor diverser quelloffener WordPress Plugins, was
ihn bei der Entwicklung von OSS motiviert und wie sich diese
Motivation im Laufe der Jahre verändert hat.
Er wurde erstmalig als OSS-Entwickler aktiv, als er automatisierte
Tests für WebKit schrieb. Warum? „Because it was fun!“ Er wollte
den eigentlichen WebKit-Entwicklern die Arbeit am Projekt erleichtern, damit diese schneller neue Funktionen implementieren
konnten. Seine damalige Motivation bestand aus einer Mischung
aus Spaß an seiner Arbeit und Eigennutz. Die Contributions führte
er in seiner Freizeit durch.
Im gleichen Zeitraum erstellte er mit dem CMS WordPress die Seite
CSS3.info. Für diese entwickelte er SEO Plugins, welche er
anschließend als open-source veröffentlichte. Die Arbeit an der
Seite und den Plugins vergrößerten seine Bekanntheit und Reputation, sodass er erstmalig Einnahmen durch seine OSS-Tätigkeit
erzielen konnte und als Sprecher für Konferenzen eingeladen
wurde. Daraus entstand eine gewisse Eigendynamik, da seine
Auftritte auf Konferenzen ebenfalls wieder seine Bekanntheit
vergrößerten.
Ab einem gewissen Punkt erwirtschaftete er mit seiner Arbeit an
OSS mehr Geld als durch seine reguläre Anstellung und beendete
deswegen sein Angestelltenverhältnis. Nun entwickelt er für
seinen Lebensunterhalt und aus purer Freude an OSS-Projekten.
In eigenen Worten: "I’m living a dream, seriously, and I wouldn’t
have been here without open source development.“ 124
Vergleicht man diese zeitliche Entwicklung bspw. mit der Maslow’schen Bedürfnishierarchie, so sieht man, dass die Motivation
bei seiner Arbeit mit OSS auf einem Top-Down-Weg von der
Selbstverwirklichung zunehmend auch die unteren Ebenen der
Defizitbedürfnisse ausfüllte. Für deren Erfüllung war zunächst
seine reguläre Anstellung nötig, welche zunehmend unwichtiger
wurde.
124
vgl. http://yoast.com/open-source-motivations-business/, Stand: 19.08.2013
50
51
Dieses Beispiel zeigt, dass die Entwicklung von OSS ein wichtiger
Lebensinhalt und Teil der Selbstverwirklichung eines Menschen
sein kann und damit als Sache an sich motivierend wirkt.
Fallstudie 6 – Joost de Valk
5.4
ENTWICKLUNGSMODELLE
Die Entwicklung von Software ist organisatorisch sehr komplex und
wird durch unbekannte und weltweit agierende Teammitglieder nicht
einfacher zu handhaben.
Aus diesem Grund haben sich beispielhafte Vorgehensweisen herausgebildet, um der Softwareentwicklung einen einheitlichen Ablauf zu
geben. Diese Vorgehensweisen nennt man Entwicklungsmodelle. Sie
sind je nach Größe und Zusammensetzung des Teams unterschiedlich
gut für ein Projekt geeignet.
Die gängigsten Entwicklungsmodelle seien im Folgenden kurz vorgestellt. Sie sollten als Muster betrachtet werden, die in der Praxis
nur begrenzt angewandt werden können. In der Realität wird man
immer Abwandlungen oder Mischformen finden, da sich diese
Modelle hauptsächlich an Programmierer richten, obwohl in der
Entwicklung noch mehr Personen wie Designer und Projektleiter
involviert sind.
In den Worten des Entwicklers James McCaffrey:125
„Ultimately [these methodologies] are all just labels. In reality most
software projects use certain aspects of all these methodologies [...]
and the most important part of success [...] [is] not a particular
methodology, but clear communication, hard work, and common
sense.“
125
vgl. http://jamesmccaffrey.wordpress.com/2006/04/11/agile-programming-vs-extreme-programming/, Stand:
10.07.2013
5.4.1
52
WASSERFALLMODELL
Das Wasserfallmodell beschreibt ein lineares und sequentielles TopDown-Vorgehen bei der Entwicklung von Software. Sie durchläuft die
folgenden Phasen:126
1.
2.
3.
4.
5.
6.
7.
8.
Systemanforderungen
Softwareanforderung
Analyse
Programmentwurf
Implementierung
Testen
Auslieferung
Wartung
Erst wenn eine Phase abgeschlossen ist, kann die nächste begonnen
werden.
Die Vorteile dieses Modells sind die klare Strukturierung und
zeitliche Planbarkeit der einzelnen Phasen, da die Phasentrennung
eindeutig und das Vorgehen linear ist.
Die Nachteile überwiegen jedoch die Vorteile. Die Vorgehensweise
ist zu starr und unflexibel. In den seltensten Fällen können alle
Anforderungen vor der Implementierung erfasst werden. Eine
spätere Korrektur der Anforderungen ist im Wasserfallmodell nicht
vorgesehen.
Da Anforderungen meist direkt von den Usern kommen und die
Contributoren während einer laufenden Phase das Projekt problemlos beitreten oder verlassen können, ist dieses Modell für die
dynamische Natur von OSS ungeeignet.
5.4.2
SPIRALMODELL
NACH
BOEHM
Das Spiralmodell nach Barry Boehm ist eine Weiterentwicklung des
Wasserfallmodells. Es besteht aus mehreren Phasen, die nacheinander und wiederholt abgeschritten werden:127
1.
2.
3.
4.
Planung
Risikoanalyse
Realisierung
Evaluierung
Beim Spiralmodell handelt es sich um einen iterativen Prozess. Alle
Phasen werden zyklisch erfasst und mit jedem Entwicklungsschritt
entfernt man sich von der ursprünglichen Planung.
126
127
Dass sich die endgültige Software von der ursprünglichen Planung
entfernt, wird als ein Vorteil angesehen, da die ursprüngliche Planung häufig unvollständig ist und sich Projektziele während der
Entwicklung ändern können.
Im Laufe des Spiralmodells entstehen mehrere Prototypen, die wiederum Grundlage zur Planung der nächsten Entwicklungsschritte
sind.
5.4.3
AGILE SOFTWAREENTWICKLUNG
Die agile Softwareentwicklung ähnelt in vielen Punkten dem Spiralmodell.128
Bei der agilen Softwareentwicklung handelt es sich mehr um eine
Philosophie als um ein eigenständiges Entwicklungsverfahren.
Nachfolgend werden jedoch noch konkrete Verfahren genannt, die
auf dieser Philosophie aufbauen.
Im Unterschied zum Spiralmodell stellt die agile Softwareentwicklung Vorgaben an die Dauer und die Priorität der einzelnen Phasen.
So sollen die Phasendurchgänge möglichst häufig und kurz und
somit sehr iterativ sein. Der Fokus der Entwicklung soll auf Kundenzufriedenheit und funktionsfähige Software liegen, welche in
kleinen Schritten um neue Funktionen erweitert wird.
Diese Philosophie ist im weit verbreiteten „Manifest für Agile
Softwareentwicklung“zusammengefasst:129
„[Wir schätzen:]
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.“
Die agile Softwareentwicklung verfolgt 12 konkrete Prinzipien: 130
•
•
•
•
•
128
Fokus auf Kundenzufriedenheit
Nutzen von Anforderungsänderungen zum Kundenvorteil
regelmäßige Auslieferung von Software
Zusammenarbeit zwischen Betriebswirtschaftlern und Entwicklern
hohe Motivation aller Beteiligten
vgl. Prokop, Open Source Projektmanagement, 2010, S. 44 f.
vgl. http://agilemanifesto.org/iso/de/, Stand: 09.07.2013
130
vgl. http://agilemanifesto.org/iso/de/principles.html, Stand: 09.07.2013
129
53
54
Bevorzugung von persönlichen Gesprächen zum Informationsaustausch
funktionierende Software als Maßstab für Fortschritt
schonende nachhaltige Arbeitsweise der Entwickler
Aufmerksamkeit auf Qualität und gutes Design
Einfachheit (unnötige Arbeit vermeiden)
Selbstorganisation von Teams
regelmäßige Überprüfung und Verbesserung dieser Prinzipien
•
•
•
•
•
•
•
Durch die Flexibilität, dem Streben nach Einfachheit, der Selbstorganisation und der iterativen Entwicklung ist die agile Softwareentwicklung für OSS gut geeignet.
Fehlende persönliche Gespräche müssen ggf. durch technische Hilfsmittel wie Videochats bestmöglich ersetzt werden.
5.4.4
EXTREME PROGRAMMING
Extreme Programming ist eine sehr konkrete Auslegung der agilen
Softwareentwicklung. Sie basiert auf drei Bestandteilen:131,132
vier Werten (values)
15 Prinzipien (principles)
12 Techniken (practices)
•
•
•
Da die Werte und Prinzipien des Extreme Programming dem Manifest
und den Prinzipien der agilen Softwareentwicklung ähneln werden
sie an dieser Stelle nicht näher vorgestellt. Die 12 Techniken stellen
jedoch eine praktische Umsetzung der Philosophie der agilen Softwareentwicklung dar, deren Betrachtung sich durch ihre Praxisnähe
lohnt:
Planning Game:
Während des Planning Games werden neue Anforderungen aufgenommen und abgeschätzt. Teammitglieder und User sind
gleichermaßen Teil des Planning Games.
Pair Programming:
Zwei Programmierer arbeiten gleichzeitig an einem Computer.
Einer programmiert und der andere fungiert als Beobachter und
hält zusätzlich störende Einflüsse von außen (Telefon, Postbote,
etc.) fern. Sie beraten sich gegenseitig.
Continuous Integration (CI):
Neuer Quellcode im Versionsystem durchläuft automatisch mehrere Tests. Sind diese Tests erfolgreich, wird der Code automa-
•
•
•
131
vgl. http://www.scrum-kompakt.de/grundlagen-des-projektmanagements/extreme-programming-xp/, Stand:
09.07.2013
132
•
•
•
•
•
•
•
•
•
tisch in die Software eingepflegt, welche daraufhin neu erstellt
wird.
Design Improvement/Refactoring:
Ein Teil der Entwicklungszeit wird dafür verwendet bestehenden
Quellcode wartbarer, verständlicher, lesbarer und erweiterbarer
zu machen, anstatt neue Funktionen einzubauen. Redundanz im
Code sollte vermieden werden. Dieses Prinzip wird als don’t
repeat yourself (DRY) bezeichnet.
Small Releases/Iterations:
Die Software sollte in kurzen Abständen mit nur kleinen
Funktionsänderungen neu veröffentlicht werden. Endanwender
erhalten schnell Updates und die Änderungen sind leichter zu
testen. Dies entspricht der release early, release often Maxime.
Simple Design:
Überflüssige Komplexität sollte vermieden werden. Dieser
Leitspruch ist auch als keep it simple stupid (KISS) bekannt.
Metaphor:
Da Software häufig zu komplex für alle Beteiligten ist, sollte die
Funktionsweise der Software durch entsprechende Metaphern
für alle einheitlich vereinfacht werden. Zu den Beteiligten zählt
auch der Endanwender!
Test Driven Development (TDD):
Tests werden geschrieben bevor, die erste Funktion implementiert wird. Im Folgenden soll TDD hohe Qualität und eine
möglichst fehlerfreie Software garantieren.
Collective Code Ownership:
Quellcode und Dokumentation gehört allen Entwicklern
gleichermaßen und darf von jedem Entwickler verändert werden.
Sustainable Pace:
Lange Arbeitszeiten bedeuten keine höhere Produktivität. Die
Wochenarbeitszeit sollte nicht mehr als 40 Stunden betragen.
Coding Standards:
Namenskonventionen, Einrückungsvarianten und andere Regeln
gelten projektweit für alle Entwickler.
Whole Team :
Es gibt keine externen Ressourcen bzw. Kompetenzen. Das
Wissen über die Implementierung der Software befindet sich
komplett im Team.
Hinweis: Der letzte Punkt ist der einzige, dessen Bedeutung sich
zwischen den Quellen gängiger Literatur unterscheidet. Die obige
Beschreibung entstammt Prokops Definition. Andere Quellen beschreiben das Prinzip des Whole Team unter der Annahme, dass der
Endanwender und der Kontakt zu ihm Bestandteil des Teams ist.
Teilweise sprechen diese Quellen deswegen nicht vom Whole Team
55
56
sondern vom On-site customer, einer durchaus realen Einzelperson
aus allen Endanwendern, die das Entwicklerteam berät.133,134
Extreme Programming ist für die Entwicklung von OSS sehr gut
geeignet. Qualitätskontrollen wie TDD, CI, Coding Standards, etc.
erleichtern einen schnellen dynamischen Wechsel der Projektmitglieder sowie die Integration von Contributions. Designprinzipien
wie KISS, schnelle Iterationen und ein Fokus auf Refactoring verbessern die Übersicht und Wartbarkeit des Quellcodes. Dies sind
Prinzipien, welche mit jedem zusätzlichen Entwickler an Bedeutung
gewinnen und von jedem größeren OSS-Projekt beachtet werden
sollten, um dessen Verwaltungsaufwand zu verringern.
Lediglich die fehlende regionale Nähe erschwert manche Praktiken.
Während Planning Games noch relativ gut virtuell in Videochats abgehalten werden können, ist echtes Pair Programming bei OSS kaum
möglich. In diesem Fall kann das Pair Programming aber durch
ähnliche Praktiken wie Code Reviews ersetzt werden.
5.4.5
SCRUM
Eine weitere Auslegung der agilen Softwareentwicklung ist Scrum.
Zusätzlich zum bestehenden Projektteam gibt es bei Scrum zwei
weiteren Rollen: den Scrum Master und den Product Owner. Alle drei
Parteien zusammen ergeben das Scrum Team .135,136
Der Beginn eines Scrum-Projekts liegt in der Vision der späteren
Software, welche vom Product Manager zusammen mit dem Kunden
entworfen wird. Die Vision überführt der Product Manager in
Anforderungen, die innerhalb eines initialen Product Backlogs
priorisiert werden. Die Anforderungen werden typischerweise als
sogenannte User Stories formuliert. User Stories sind unscharfe
Anforderungen aus der Sicht des Kunden. Ihre Unschärfe hat den
Vorteil, dass sie sich noch während des Projekts ändern können.137
Die Planung zur Umsetzung der hoch priorisierten User Stories
beginnt im Sprint Planning Meeting, in welchem der Product Owner
den aktuellen Product Backlog dem Projektteam vorstellt. Das
Projektteam schätzt, welche User Stories es im nächsten Sprint
abarbeiten kann und überträgt diese in eine Selected Backlog, in
welchem die User Stories für den nächsten Sprint fix sind. Die
restlichen User Stories im Product Backlog können sich jedoch
133
vgl.
http://www.oobeyagroup.com/images/ExtremeProgrammingAgileSoftwareDevelopmentLindstromJeffries.pdf,
Stand: 09.07.2013
134
vgl. http://martinfowler.com/bliki/OnsiteCustomer.html, Stand: 09.07.2013
135
vgl. Wirdeman, Scrum mit User Stories, 2011, S. 28 ff.
136
vgl. Gloger, Scrum, 2013, S. 11 ff.
137
vgl. Wirdeman, Scrum mit User Stories, 2011, S. 51
währenddessen ändern. Anschließend werden die User Stories des
Selected Backlog in einzelne Aufgabenpakete zerteilt. Es entsteht
das Sprint Backlog, welches die detaillierten Aufgaben des nächsten
Sprints beinhaltet. Mit diesem kann der aktuelle Sprintfortschritt
gemessen werden. Das ganze Meeting wird vom Scrum Master moderiert, welcher u.a. darauf achtet, dass nicht zu viele User Stories im
Selected Backlog enthalten sind.
Nach dem Sprint Planning Meeting schließt sich der eigentliche
Sprint an. Dieser ist der iterative Prozess innerhalb von Scrum.
Sprints sind Entwicklungsphasen mit einer fest definierten Länge
(1-4 Wochen) an deren Ende eine verwendbare Software entsteht.
Innerhalb dieser Phase arbeitet das Projektteam komplett autark.
Der Scrum Master achtet darauf, dass das Team nicht von außen
behindert wird. Eine besondere Form des Sprints ist der ReleaseSprint, an dessen Ende nicht nur eine verwendbare Software
entsteht, sondern eine, die auch an den Endanwender ausgeliefert
wird. In diesem Fall sind noch mehr Personen im Sprint involviert
(Marketing, Administratoren, Support, etc.). Am Ablauf oder an der
Qualität der Software ändert sich jedoch nichts.
Innerhalb des Sprints existiert ein weiterer iterativer Prozess: die
Daily Scrums. Sie dienen dazu, dass sich das Projektteam täglich zu
einer festen Zeit trifft, um sich gegenseitig zu synchronisieren und
den aktuellen Fortschritt zu messen. Sprints und Daily Scrums
wiederholen sich so lange das Projekt aktiv entwickelt wird.
Nach einem abgeschlossen Sprint finden zwei Meetings statt. Zuerst
beginnt das Sprint-Review , welches eine öffentliche Präsentation
der neuen verwendbaren Software darstellt. Zu diesem treffen sich
der Product Owner, der Scrum Master und das Projektteam, welche
um Stakeholder wie die Geschäftsführung oder Endanwender ergänzt
werden können. Sie begutachten die umgesetzten User Stories und
diskutieren Probleme bei der Umsetzung. Das Meeting sollte nicht
aufwendig vorbereitet werden – es wird nur die Software präsentiert.
Der Sprint wird endgültig mit der Sprint-Retrospektive geschlossen.
Das Ziel dieses Meetings ist die ständige Verbesserung des Entwicklungsprozesses und der Produktivität des Projektteams. Ein
wichtiger Bestandteil dessen ist die reibungslose Zusammenarbeit
innerhalb des Teams.
57
FALLSTUDIE
Das Scrum Prinzip wird erfolgreich von der open-source IDE
Brackets eingesetzt, einem OSS Projekt der Firma Adobe (s.
5.1.1.1 „SINGLE VENDOR OPEN SOURCE PROJECTS“).138
Teil des Entwicklungsprozesses von Brackets ist die tägliche
Kontrolle von Contributions als Teil des Daily Scrums. Dabei
erhalten externe Contributions eine höhere Priorität als die vom
Adobe Kernteam selbst. Die Länge der Sprints im Brackets Team
beträgt 12 Entwicklungstage. Zur Visualisierung der Backlogs
verwenden die Entwickler das Onlinetool Trello, welches die Überführung von User Stories aus dem Product Backlog in ein Sprint
Backlog ermöglicht (s. 5.5.4 M ANAGEMENT-SOFTWARE). Zusätzlich
gibt es unterschiedliche Backlogs für Adobe interne und externe
Teammitglieder.139,140,141
Am Ende eines Sprints trifft sich das Team zur Reviewphase. Durch
die teilweise überregional arbeitenden Teammitglieder wird diese
teilweise über Videochats durchgeführt.142
Vorteile dieses agilen und öffentlichen Entwicklungsprozesses
sind das zeitnahe Feedback der User und eine schnellere Reaktionsfähigkeit auf dieses Feedback.
Adam Lehman, der Project Lead von Brackets, führt als Beispiel
an, dass Brackets zunächst ausschließlich im Browser verwendet
werden sollte. Viele Nutzer stimmten dagegen und führten an,
dass sie lieber mit nativen IDEs arbeiten würden. Daraufhin
konnte das Brackets Team sehr schnell die Prioritäten ändern und
entwickeln Brackets nun innerhalb einer nativen Shell. 143,144
Fallstudie 7 – Brackets
5.5
TECHNISCHE INFRASTRUKTUR
Eine gut funktionierende technische Infrastruktur ist essentiell für
einen reibungslosen Entwicklungsprozess – egal ob bei OSS oder
geschlossener Software. Sie hängt jedoch stark von den Projektbedingungen ab und kann kaum verallgemeinert werden. So spielen
die Teamgröße, Art der Software, Vorkenntnisse der Contributoren
und Vorlieben der Zielgruppen eine entscheidende Rolle bei der
138
vgl. http://brackets.io/, Stand: 21.08.2013
vgl. http://blog.petermolgaard.com/2012/05/03/adobe-brackets-team-using-trello/, Stand: 10.07.2013
140
vgl. http://dev.brackets.io/preso/contribute/#/16, Stand: 10.07.2013
141
vgl. https://trello.com/b/LCDud1Nd/brackets, Stand: 21.08.2013
142
vgl. https://plus.google.com/113743469825932014075/posts/cSVyhkcrp8L, Stand: 21.08.2013
143
vgl. http://creativejs.com/2012/05/brackets-review/#comment-1901, Stand: 21.08.2013
144
vgl. https://github.com/adobe/brackets-shell/, Stand: 21.08.2013
139
58
Notwendigkeit und der Wahl der richtigen Werkzeuge.
Innerhalb dieses Kapitels ist es deswegen nicht möglich, alle
Werkzeuge im Detail vorzustellen. Dieses Kapitel dient viel mehr als
Grundlage zum Brainstorming: Welche Werkzeuge benötigt eigentlich mein Projekt?
5.5.1
VERSIONSVERWALTUNG
Die Versionsverwaltung ist eines der wichtigsten – vielleicht das
wichtigste – Werkzeug bei der Softwareentwicklung. Das Versionskontrollsystem (engl. Version Control System , VCS) erfasst Änderungen an Dateien und Dokumenten und speichert diese in einem
Archiv ab.145
Anhand der Änderung kann nicht nur abgelesen werden, was geändert wurde, sondern auch wer diese Änderung vorgenommen hat
und wann. Der Ursprung eines Fehlers lässt sich somit immer
zurückverfolgen und die Software lässt sich auf einen funktionierenden alten Stand zurücksetzen.
Im Wesentlichen besteht ein VCS aus den folgenden Bereichen:
•
•
•
•
•
•
•
•
•
145
Repository:
Das eigentliche Archiv des Projekts. Es speichert alle Daten und
Änderungen des Projekts.
Working Copy:
Eine lokale Kopie des Repositories. An dieser Kopie führt ein
Entwickler Änderungen im Quellcode durch.
Checkout:
Das Übertragen von Änderungen aus dem Repository in die
Working Copy.
Commit:
Das Übertragen von Änderungen aus der Working Copy in das
Repository.
Revision:
Ein spezieller Entwicklungsstand des Repositories.
Diff:
Unterschiede zwischen zwei Revisionen.
Conflict:
Sich überschneidende Änderungen innerhalb einer Datei.
Merge:
Das Auflösen eines Conflicts bzw. Vereinen verschiedener
Änderungen innerhalb einer Datei.
Branch:
Ein isolierte Version des Repositories oder der Working Copy.
59
60
Mehrere unabhängige Änderungen im Quellcode können jeweils
in einem eigenen Branch stattfinden ohne sich gegenseitig zu
beeinflussen.
VCS werden in zwei Hauptgruppen unterteilt: zentral oder verteilt.
Bei zentralen VCS liegt das Repository zentral auf einem Server.
Änderungen, die jedem Entwickler des Projekts zugänglich gemacht
werden sollen, werden mittels eines Commits auf das Repository und
damit auf den Server übertragen, sodass jeder auf diese zugreifen
kann. Bekannte Vertreter von zentralen VCS ist das veraltete Concurrent Versions System (CVS) und Subversion (SVN).
Bei verteilten VCS gibt es kein zentrales Repository auf das jeder
Entwickler zugreifen kann. Jeder Entwickler benutzt sein eigenes
lokales Repository und kann dieses mit anderen Repositories abgleichen. Diese können wiederum auf einem Server liegen. Ein Commit überträgt Änderungen der Working Copy zwar weiterhin in das
Repository, aber lediglich in das eigene. Möchte man Änderungen an
andere Entwickler weiterreichen, führt man einen sogenannten Push
durch. Da verteilte VCS ein lokaleres und unabhängigeres Arbeiten
ermöglichen, sind sie in vielen Fällen für OSS besser geeignet.
Bekannte Vertreter der verteilten VCS sind Git sowie Mercurial.
Zu den Daten, die innerhalb des VCS festgehalten werden sollten,
zählt vorrangig der Quellcode der Software. Des Weiteren sollten alle
für die Entwicklung der Software benötigten projektspezifischen
Dateien wie die Konfigurationsdateien des Build-Systems oder Testdateien im Repository liegen. Wichtige softwarebezogene Assets wie
Logos, Icons oder Fonts können mitunter auch im Repository
gespeichert werden. Teilweise werden auch Dokumentationen oder
Webseiten in Repositories gespeichert – je nach Größe sollten sich
diese aber in eigenen gesonderten Repositories befinden.
5.5.2
HOSTING-DIENSTE
FÜR
SOFTWAREPROJEKTE
Das Aufgabenspektrum moderner Hosting-Dienste für Softwareprojekte geht mittlerweile weit über das einfache Speichern und zur
Verfügung stellen von Quellcode hinaus. Sie unterscheiden sich im
Wesentlichen von der verwendeten Versionsverwaltung, dem Finanzierungsmodell, der zusätzlichen zur Verfügung gestellten Werkzeuge und der Integration eines sozialen Netzwerkes.
Des Weiteren ist ihre Community stark von den dort gehosteten Projekten und den Firmen, die den Hosting-Dienst betreuen, geprägt.
So steht hinter dem Hosting-Dienst CodePlex die Firma Microsoft,
die hier ihre eigenen OSS-Projekte wie TypeScript veröffentlicht.146
146
vgl. http://typescript.codeplex.com/, Stand: 11.07.2013
Im Folgenden werden fünf populäre Hosting-Dienste miteinander
verglichen:
61
62
Name
VCS
Firma
Gründung
Bitbucket 147
Git, Mercurial
Atlassian
2008
CodePlex 148
SVN, TFS, Git, Mercurial
Microsoft
2006
GitHub149
Git
GitHub, Inc
2008
Google Code 150
SVN, Git, Mercurial
Google
2006
SourceForge 151
CVS, SVN, Git, Mercurial
Dice Holdings
1999
Tabelle 8 – Übersicht von Hosting-Diensten für Softwareentwicklung
Name
Kosten
Features
Bitbucket
• frei: n-private Repositories mit
max. 5 Benutzern
• Kosten: nach Benutzerzahlen
für n-private Repositories
• Code Review
• Bug-Tracking
(Jira)
• Wiki System
• Team Organisation
CodePlex
• frei: OSS
•
•
•
•
GitHub
• frei: OSS
• Kosten: gestaffelt nach Anzahl
privater Repositories
• GitHub Enterprise: spezieller
Bezahldienst für eine eigene
GitHub Instanz
• Code Review (als
Pull Requests)
• Bug-Tracking
• Web Hosting
• Wiki System
• Team Organisation
Google Code
• frei: OSS
• Code Review
• Bug-Tracking
• Wiki System
SourceForge
• frei: OSS
•
•
•
•
•
•
Bug-Tracking
Wiki System
Mailinglisten
Forum
Bug-Tracking
Web Hosting
Wiki System
Mailinglisten
Forum
Team Organisation
Tabelle 9 –Hosting-Diensten nach Kosten und Features
147
vgl. https://bitbucket.org/, Stand: 11.07.2013
vgl. https://www.codeplex.com/, Stand: 11.07.2013
149
vgl. https://github.com/, Stand: 11.07.2013
150
vgl. https://code.google.com/intl/de/, Stand: 11.07.2013
151
vgl. http://sourceforge.net/, Stand: 11.07.2013
148
Die gegebenen Übersichten zeigen lediglich einen Ausschnitt der
eigentlichen Dienste. Im Detail unterscheiden sie sich beim Support,
der Benutzerfreundlichkeit, der Stabilität, den Analysetools, Onlineeditoren, etc.
Da alle genannten Dienste für OSS kostenlos sind ist der Preis in der
Regel kein ausschlaggebendes Kriterium bei der Wahl dieser. Git ist
die sicherste Wahl als VCS, da es von allen Diensten unterstützt wird.
Obwohl hinter Google Code und CodePlex zwei der bekanntesten ITFirmen stecken, findet die meiste Entwicklung wohl bei Bitbucket
und GitHub statt, weil sie durch Premium-Dienste für große Firmen
interessant werden – gerade GitHub, welches als einziger Dienst die
Möglichkeit einer lokaler Instanz mit Support bietet.
In der Tat ist GitHub der populärste der genannten Dienste und kann
fast ausschließlich wegen seiner großen Community als erste Wahl
in Betracht gezogen werden. Hinzu kommt das gute Tooling, welches
native Client-Applikationen beinhaltet.152,153,154
A b b i l d u n g 7 – P o p u l a r i t ä t d e r H o s t i n g - D i e n s t e b e i G o o g l e T r e n d s 155
Erst in Spezialfällen lohnt sich der Blick zu anderen Diensten. So ist
die C# Community unter CodePlex als Microsoft Dienst beispielsweise
besonders stark vertreten.156
5.5.3
ISSUE-TRACKING-SYSTEM
Issue-Tracking-Systeme, Bug-Tracker bzw. Ticket-Systeme bilden bestehende Probleme einer Software und Arbeitspakete der Entwickler
152
vgl. http://www.heise.de/developer/meldung/GitHub-populaerer-als-SourceForge-und-Google-Code1255416.html, Stand: 11.07.2013
153
vgl. http://windows.github.com/, Stand: 11.07.2013
154
vgl. http://mac.github.com/, Stand: 11.07.2013
155
vgl. http://goo.gl/26FKQ, Stand: 11.07.2013(X-Achse: Zeitraum von 2004 bis 2013, Y-Achse: absolutes
Suchinteresse relativ zum höchsten Suchaufkommen)
156
vgl. http://readwrite.com/2011/06/02/github-has-passed-sourceforge, Stand: 11.07.2013
63
ab. Die Probleme, Bugs bzw. Arbeitspakete werden in Tickets formuliert. Die Issue-Tracking-Systeme dienen dazu die Tickets zu erfassen, zu gruppieren, zu ordnen, zu priorisieren, ihren Bearbeitungsfortschritt zu messen und die Bearbeitung einer bestimmten
Person zuzuweisen. Sie dienen mitunter auch für Außenstehende als
zentrale Anlaufstelle um technische Fehler zu melden. Es obliegt
dem Projekt zu definieren, was ein Ticket ist. So können neben
offensichtlichen Fehlfunktionen der Software auch fehlende Features als Ticket erfasst werden.
Obwohl es nicht ihr primärer Einsatzzweck ist, können auch zielgerichtete Diskussionen in Form eines Ticket erstellt werden und
ersetzen damit einfache Mailinglisten oder Foren. Ein Beispiel dafür
wäre das „Diskussionsticket“ der nächsten Bootstrap-Iteration.157
Tickets können außerdem zu einem Sprint Backlog zusammengefasst
werden und so den Fortschritt eines Sprints messen (s. 5.4.5 SCRUM).
Die meisten Code-Hosting-Dienste enthalten bereits mehr oder
weniger komplexe Bug-Tracker. Bitbucket integriert beispielsweise
die eigenständige Software Jira, welche ebenfalls von Atlassian entwickelt wird.158
A b b i l d u n g 8 – J i r a : E r s t e l l u n g e i n e s T i c k e t s 159
Andere beliebte freie Issue-Tracking-Systeme sind Bugzilla, Redmine
und Mantis, welche statt der integrierten Lösung des Code-HostingDiensts genutzt werden können . 160,161,162
157
vgl. https://github.com/twitter/bootstrap/pull/6342, Stand: 12.07.2013
vgl. http://www.atlassian.com/de/software/jira, Stand: 12.07.2013
159
vom Autor aufgenommen
160
vgl. http://www.bugzilla.org/, Stand: 12.07.2013
161
vgl. http://www.redmine.org/, Stand: 12.07.2013
158
64
5.5.4
MANAGEMENT-SOFTWARE
Management-Software ist ein weitgefasster allgemeiner Begriff für
Software, die die Ausführung typischer Managementfunktionen vereinfacht. Ihr Funktionsumfang ist genauso breit gefächert wie die
Vorstellungen davon, welche Aufgaben Teil des Managements sind
(s. 5.2 FUNKTIONEN UND ROLLEN DES M ANAGEMENTS).
Zu den häufigsten Managementfunktionen gehört das Sammeln,
Gruppieren und Zuweisen von Arbeitspaketen. Dies kann über die
bereits erwähnten Issue-Tracking-Systeme erfolgen oder über Task
Manager bzw. ToDo Manager. Der Übergang zwischen einem IssueTracking-System und einem Task Manager ist fließend und sollte
nicht zu streng genommen werden. Erstere sind meist etwas technischer und supportorientierter, letztere in der Visualisierung der
Aufgaben häufig aufwendiger und managementorientierter.
Verbreitete Task Manager sind Wunderlist, Things und OmniFocus.
Für das Management von rAppid.js wird Asana verwendet.163,164,165,166
Ein Teil der Task Manager richtet sich an konkrete Entwicklungsmodelle wie Scrum (s. 5.4.5). In diesem Fall werden Arbeitspakete
häufig als Planning Boards dargestellt. Eine für OSS-Projekte
beliebte und freie Anwendung für Planning Boards ist Trello, genutzt
u.a. vom Brackets Team. Projekte, welche nach dem Wasserfallmodell (s. 5.4.1) entwickelt werden, können durch sogenannte
Gantt Charts visualisiert werden. Diese stellen zeitlich voneinander
abhängige Aufgaben in einem Balkendiagramm dar. Microsoft Project legt einen großen Fokus auf Gantt Charts und ist unter Windows
sowie im B2B-Bereich sehr verbreitet. 167,168,169
Durch die großen thematischen Überschneidungen lassen sich viele
Funktionen von Task Managern durch Plugins in Issue-TrackingSysteme integrieren. Planning Boards können in Jira mit der
offiziellen Erweiterung GreenHopper von Atlassian oder in GitHub
mit dem inoffiziellen Huboard hinzugefügt werden. 170,171
162
vgl. http://www.mantisbt.org/, Stand: 12.07.2013
vgl. http://www.6wunderkinder.com/wunderlist, Stand: 15.07.2013
164
vgl. http://culturedcode.com/things/, Stand: 15.07.2013
165
vgl. http://www.omnigroup.com/products/omnifocus/, Stand: 15.07.2013
166
vgl. https://asana.com/, Stand: 26.08.2013
167
vgl. https://trello.com/, Stand: 15.07.2013
168
vgl. https://trello.com/board/brackets/4f90a6d98f77505d7940ce88, Stand: 15.07.2013
169
vgl. http://office.microsoft.com/de-de/project/, Stand: 09.09.2013
170
vgl. http://www.atlassian.com/de/software/greenhopper, Stand: 15.07.2013
171
vgl. http://huboard.com/, Stand: 15.07.2013
163
65
66
Abbildung 9 – Trello: Projektansicht von Brackets mit Panning
B o a r d s 172
A b b i l d u n g 1 0 – M i c r o s o f t P r o j e c t : P r o j e k t a n s i c h t m i t G a n t t C h a r t s 1 73
Andere typische Aufgabengebiete von Management-Software sind
das Erstellen und Verwalten von Meetings. Kernpunkt dieser Aufgabe
ist eine gute Kalendersoftware, welche u.a. das Teilen von Terminen
mit anderen Personen sowie das Betrachten der Zeitressourcen von
Personen und Meetingräumen beinhaltet.
Eine Komplettlösung für diese Aufgabe wäre Microsoft Exchange. Für
einfache Zwecke genügt häufig Google Calendar. Wer lediglich einen
gemeinsamen Termin finden muss, findet mit Doodle oder Moreganize eine Lösung.174,175,176,177
172
vgl. https://trello.com/b/LCDud1Nd/brackets, Stand: 26.08.2013
vgl. http://review.techworld.com/applications/3404323/microsoft-project-2013-review/, Stand: 12.09.2013
174
vgl. http://www.microsoft.com/exchange/2010/de/de/, Stand: 15.07.2013
175
vgl. https://support.google.com/calendar/answer/2465776, Stand: 15.07.2013
173
Software als Komplettlösung wie Exchange, die das Verwalten und
Kommunizieren von Personen bzw. Personengruppen für unterschiedliche Zwecke sowie bereits genannte oder folgende Werkzeuge
beinhaltet, wird auch Groupware genannt. 178
5.5.5
NOTIZEN
UND
DOKUMENTE
Ein wichtiger Bestandteil von Planungsaufgaben ist häufig das Verfassen, Sammeln und Durchsuchen von Notizen bzw. Dokumenten.
Für diese Aufgaben kann auf klassische Schreibprogramme wie
Microsoft Word zurückgegriffen werden. Bei kollaborativen Arbeiten
empfiehlt sich die Nutzung von Cloud-Diensten wie Google Docs. 179,180
Software, welche weniger das eigenständige Verfassen als viel mehr
das Sammeln und Durchsuchen von Informationen ermöglicht,
wären nvAlt, Pocket oder Evernote. Sie können entweder komplett
textorientiert sein oder konsumieren jegliche Dokumentformate bis
hin zu Webseiten.181,182,183
Software, die sich auf das schnelle Verfassen von textbasierten
Notizen konzentriert, ist in den letzten Jahren durch die distractionfree 184 Bewegung immer beliebter geworden. Sie basiert darauf, dass
Software zur Eingabe von Text kaum oder keine grafische Benutzeroberfläche benötigt und Textauszeichnungen und -formatierungen
nur durch Text selbst stattfindet. Zu diesem Zweck werden spezielle
Auszeichnungssprachen wie Markdown angewandt.185,186
Beliebte Schreibprogramme für ablenkungsfreies Schreiben sind u.a.
Byword, ZenWriter und Ommwriter.187,188,189
176
vgl. http://www.doodle.com/, Stand: 15.07.2013
vgl. http://moreganize.ch/, Stand: 16.07.2013
178
vgl. https://webmail.eva.mpg.de/ox6/help/de_DE/guide.chap.intro.html, Stand: 15.07.2013
179
vgl. http://office.microsoft.com/de-de/word/, Stand: 15.07.2013
180
vgl. https://support.google.com/drive/answer/49008, Stand: 15.07.2013
181
vgl. http://brettterpstra.com/projects/nvalt/, Stand: 15.07.2013
182
vgl. http://getpocket.com/, Stand: 15.07.2013
183
vgl. https://evernote.com/intl/de/, Stand: 15.07.2013
184
distraction-free (englisch „ablenkungsfrei“)
185
vgl. http://lifehacker.com/5687616/best-distraction+free-writing-application, Stand: 15.07.2013
186
vgl. http://daringfireball.net/projects/markdown/, Stand: 15.07.2013
187
vgl. http://bywordapp.com/, Stand: 15.07.2013
188
vgl. http://www.beenokle.com/zenwriter.html, Stand: 24.07.2013
189
vgl. http://www.ommwriter.com/, Stand: 15.07.2013
177
67
5.5.6
CONTENT MANAGEMENT SYSTEME
Je umfangreicher die Verwaltung der Dokumente und je größer das
Team, welches diese Dokumente betrachtet und editiert, desto eher
stoßen die zuvor genannten Dokumentwerkzeuge an ihre Grenzen
und der Bedarf an echten CMS wächst.
CMS erlauben die komplexe Verwaltung von Daten jeglicher Art. Zu
ihren Funktionen zählen:
•
•
•
•
•
•
•
eine Nutzerverwaltung mit Berechtigungssystem,
die Möglichkeit Metadaten anzulegen,
die einfache Versionierung der Dokumente (ohne manuell zu
pflegendes VCS),
die Nutzung von verschiedenen Endgeräten zum Betrachten der
Dokumente,
die kollaborative Bearbeitung von Dokumenten,
Reviewfunktionen sowie
die Erweiterbarkeit durch Plug-ins.
Firmen verwenden CMS hauptsächlich innerhalb eines Intranets oder
zumindest mit entsprechenden Accounts als Zugangsbeschränkung
nach außen. Bei OSS-Projekten kann der Lesezugriff auf das CMS
durchaus komplett öffentlich sein.
Wiki-Software ist eine Sonderform der CMS, die sich zumeist am
populären Wikipedia orientiert und eine ähnliche Benutzeroberfläche verwendet.190
Immer mehr Wiki- und Management-Software übernehmen dabei
Konzepte sozialer Netzwerke wie bspw. Jive.191
Bekannte Wiki-Software sind Confluence und MediaWiki. Zu den
populärsten CMS zählen WordPress, TYPO3 und Drupal.192,193,194,195,196
5.5.7
WEBSEITEN
UND
BLOGS
Webseiten und Blogs überschneiden sich thematisch mit den zuvor
genannten CMS. Sie sind im Wesentlichen die öffentliche Präsentation der Inhalte, die mittels CMS erstellt wurden. Deswegen steht
190
vgl. http://www.wikipedia.org/, Stand: 15.07.2013
vgl. http://www.jivesoftware.com/social-business/solutions/social-intranet/, Stand: 15.07.2013
192
vgl. http://www.atlassian.com/de/software/confluence/, Stand: 15.07.2013
193
vgl. http://www.mediawiki.org/, Stand: 15.07.2013
194
vgl. http://wordpress.org/, Stand: 15.07.2013
195
vgl. http://typo3.org/, Stand: 15.07.2013
196
vgl. https://drupal.org/, Stand: 15.07.2013
191
68
in beiden Fällen häufig die gleiche Software dahinter. So ist WordPress zunächst als CMS speziell für Blogs entwickelt worden.197
Webseiten und Blogs können jedoch auch ohne CMS erstellt werden.
Teilweise wird dafür wieder auf die Code-Hosting-Dienste zurückgegriffen. So bietet GitHub mit dem GitHub Pages Service die Möglichkeit statische Webseiten zu hosten. Durch OSS wie Jekyll lassen
sich auf diese Weise selbst Blogs realisieren. Dieser Weg richtet sich
hauptsächlich an Entwickler, welche mit GitHub, Git und Command
Line Tools vertraut sind. Da die meisten Contributoren mehr oder
weniger erfahrene Entwickler sind, ist dies eine durchaus preiswerte,
robuste und flexible Alternative für OSS-Projekte um Webseiten zu
pflegen.198,199
Projekte, welche GitHub Pages nutzen, sind bspw. Font-Awesome
oder die MEAN Boilerplate.200,201
Unter 6 KOMMUNIKATION werden die inhaltlichen Unterschiede zwischen Webseiten und Blogs näher betrachtet.
5.5.8
BUILD SYSTEME
Build Systeme haben das primäre Ziel aus Quellcode eine kompilierte
auslieferbare Software zu erstellen. Je nach verwendeter Technologie und Einsatzzweck der Software kann dies u.a. folgende Punkte
enthalten:202
•
•
•
•
•
•
•
•
Kompilieren von Quellcode
Konkatenieren und Minifizieren von Skripten
Kopieren oder Löschen von Dateien bzw. Ordnern
Hinzufügen oder Entfernen von Metadaten
Komprimieren von Assets
Ersetzen von Texten
Umbenennen von Dateien bzw. Ordnern
Ausführen von Tests
Bekannte Build Systeme sind make, Ant, Gradle und Grunt.203,204,205,206
197
vgl. http://en.support.wordpress.com/introduction/, Stand: 15.07.2013
vgl. http://pages.github.com/, Stand: 15.07.2013
199
vgl. http://jekyllrb.com/, Stand: 15.07.2013
200
vgl. http://fortawesome.github.io/Font-Awesome/, Stand: 15.07.2013
201
vgl. https://github.com/linnovate/mean, Stand: 15.07.2013
202
vgl. http://www.cs.virginia.edu/~dww4s/articles/build_systems.html, Stand: 15.07.2013
203
vgl. https://www.gnu.org/software/make/, Stand: 15.07.2013
204
vgl. http://ant.apache.org/, Stand: 15.07.2013
205
vgl. http://www.gradle.org/, Stand: 15.07.2013
206
vgl. http://gruntjs.com/, Stand: 15.07.2013
198
69
Wichtig bei der Wahl des Build Systems ist die Beachtung des
technischen Ökosystems innerhalb dessen die OSS-Entwickelt wird
sowie die Zielgruppe der Contributoren. So wird Ant typischerweise
in Java-basierten Projekten verwendet und Grunt bei Node.js- und
Web-basierten Projekten. Dementsprechend richten sich Plugins
beider Build Systeme und die Erfahrung der Contributoren an das
jeweilige Ökosystem.
5.5.9
CONTINUOUS INTEGRATION
Vereinfacht ausgedrückt ist eine Continuous Integration (CI) ein
kontinuierlich laufendes Build System mit starker Integration in das
VCS. Die CI reagiert über sogenannte Hooks207 auf zu committenden
oder zu pushenden Quellcode im VCS in dem sie das Build System
aufruft. Taucht während des Build-Vorgangs ein Fehler auf, so wird
der Commit bzw. Push zurückgewiesen. Auf diese Weise wird das
Risiko verringert, dass fehlerbehafteter Quellcode in die endgültige
Software gelangt.
Für OSS-Projekte ist CI eine sinnvolle Erweiterung. Quellcodeänderungen von Contributoren können zu jeder beliebigen Tageszeit
durch die CI im Vorfeld kontrolliert werden. Fehler werden so frühzeitig entdeckt.
Bekannte CI-Server sind Jenkins und Travis. Die Projekte rAppid.js
und node-xmpp verwenden wegen der leichten Integration in GitHub
Travis als CI-Server.208,209
5.6
ZUSAMMENFASSUNG
•
•
•
•
207
OSS wird von Privatanwendern, Firmen und gemeinnützigen Organisationen entwickelt. Je nachdem welche Gruppe das Projekt
initiiert hat, kann ihre Zielstellung, Organisation und Hierarchie
sehr unterschiedlich ausfallen.
Die Abstimmung innerhalb von OSS-Projekten erfolgt in der Regel (wohlwollend) diktatorisch, demokatrisch oder meritokratisch.
Die Aufgaben des Managements decken Planung, Organisation,
Personaleinsatz, Führung und Kontrolle ab.
Das Management tritt in einer oder mehreren von bis zu zehn
managementspezifischen Rollen auf.
hook (englisch „Haken, hier: „Signal“, „Event“)
vgl. http://jenkins-ci.org/, Stand: 16.07.2013
209
vgl. https://travis-ci.org/, Stand: 16.07.2013
208
70
•
•
•
•
Die hohe Motivation der Contributoren ist einer der wichtigsten
Vorteile von OSS-Projekten und sollte entsprechend gefördert
werden.
Für OSS-Projekte eignen sich agile Entwicklungsmethoden wie
Scrum.
Die technische Infrastruktur von OSS ist sehr komplex und deckt
Bereiche des Managements, der Dokumentation und der
Qualitätssicherung ab. Viele Probleme werden jedoch durch
moderne Cloud-Dienste wie GitHub gelöst.
Die technische Infrastruktur einer OSS sollte sich an den
Erfahrungen der Contributoren orientieren.
71
6 Kommunikation
6
72
KOMMUNIKATION
Der größte Mehraufwand bei der Entwicklung einer OSS im Vergleich
zu einer proprietären Software entsteht bei der Kommunikation.
Projektmitglieder arbeiten nicht mehr im gleichen Raum und haben
sich häufig persönlich nie getroffen. Sie sprechen teilweise nicht in
ihrer Muttersprache miteinander und kennen möglicherweise nicht
die kulturellen Hintergründe des anderen. Der Aufwand einer
intensiven Kennenlernphase lohnt sich kaum – die Beteiligungsdauer eines Contributors kann sich auf einen einzelnen Tag beschränken. Außerdem beginnt die Kommunikation bereits vor der
ersten Contribution.
Um die Übersicht bei der Kommunikation zu bewahren werden im
folgenden Kapitel die gängigsten Kommunikationskanäle eines OSSProjekts vorgestellt. Es wird beschrieben welche Inhalte sie vermitteln sollten und an welche Zielgruppe sie sich richten. Zum
Abschluss wird der Community Manager vorgestellt, welcher für die
Pflege und Qualität dieser Kanäle verantwortlich ist.
6.1
WEBSEITEN
UND
BLOGS
Projektwebseiten sind häufig die zentrale Anlaufstelle jeglicher
Projektkommunikation, sei es nach außen (Presse, User) oder nach
innen (Contributoren) und zählen damit zu den wichtigsten Kommunikationskanälen. Sie enthalten Inhalte für alle Zielgruppen und
Stakeholder des Projekts. Auf Grund der Menge an Informationen,
die eine Webseite enthält, lohnt es sich sogenannte Contents Audits
bzw. Content Inventories anzulegen, also eine Auflistung aller Inhalte der Seite. Diese können zusätzlich nach Interessengruppen
und Wichtigkeit geordnet werden. 210
Bei der Entwicklung der Projektwebseite können die gleichen
Strukturen genutzt werden, die auch bei der Entwicklung der OSS
zum Einsatz kommen. So können aus den Content Audits Anforderungen bzw. User Stories erstellt werden, welche in Sprint Backlogs
festgehalten und in anschließenden Sprints abgearbeitet werden.
Dies ist jedoch mit einem gewissen Aufwand verbunden und eignet
sich nur für größere Projekte. Es ist auch möglich, dass sich ein
komplett anderes Team an Contributoren um die Webseite kümmert,
z.B. weil ein OSS-Projekt in C++ entwickelt wird und die C++ Contributoren wenig Erfahrung mit Webtechnologien haben.
Falls Content Audits und komplette Entwicklungsmodelle zu aufwändig für die Webseite sind, so genügt als Start ein einfaches
210
vgl. http://uxmastery.com/how-to-conduct-a-content-audit/, Stand: 16.07.2013
6 Kommunikation
Brainstorming und eine Checkliste an Anforderungen, die die Webseite erfüllen muss:211
•
•
•
•
•
•
•
•
•
•
Was macht diese Software eigentlich?
Wo kann ich die Software downloaden?
Für welches Betriebssystem ist die Software? Kann ich die
Software überhaupt nutzen?
Wann war das letzte Update der Software?
Wo finde ich einen Kontakt zu den Entwicklern?
Wie kann ich als Contributor am Projekt teilnehmen?
Wo finde ich Logos und anderes Pressematerial?
Wo melde ich Bugs?
Wo finde ich die Dokumentation?
Wie finde ich Informationen (Suchfeld)?
Zusätzlich zur Webseite verwenden viele Projekte einen Blog,
welcher für zeitlich geordnete Nachrichten und Ankündigungen verwendet wird. Hier werden Informationen zu neuen Releases, Vorstellungen zu spannenden Projekte und aufbereitete Changelogs
veröffentlicht. Kommentarformulare ermöglichen zudem einfache
Nachfragen zu einem Thema.
Neben der Erstellung der Webseite sind klassische SEO und Marketing Aufgaben von Bedeutung. Warum sollte man eine Webseite oder
die OSS-Entwickeln, wenn sie niemand findet?
SEO ist ein zu breites Feld, um innerhalb dieser Arbeit genauer
darauf einzugehen. Wichtige Ausgangspunkte guter SEO Arbeit sind
ein sauberes Markup und nützliche Metainformationen wie XML
Sitemaps, um eine gute Indexierbarkeit für Suchmaschinen zu ermöglichen. Dazu gehört u.a. der Verzicht auf proprietäre Formate
wie Flash. Wichtig sind ebenfalls eine hohe Erreichbarkeit und
Stabilität der Server sowie eine gute Performance, welche bspw.
mittels Googles PageSpeed-Tools getestet werden kann. Auch stabile
und lesbare URLs verbessern die Reichweite der Webseite. In den
letzten Jahren wurden außerdem Responsive Designs für mobile
Endgeräte und die Integration in soziale Netzwerke wichtiger. 212,213
Egal wie lang die Liste an SEO Maßnahmen ist, wichtig ist die
Messbarkeit der Reichweite der Webseite. Dies erfolgt mit Webanalysewerkzeugen. Zu den populärsten SEO Analysewerkzeugen
zählen Google Analytics und Piwik.214,215
211
vgl. https://developers.google.com/speed/pagespeed/, Stand: 16.07.2013
213
vgl. http://www.clickminded.com/seo-checklist/, Stand: 16.07.2013
214
vgl. http://www.google.com/analytics/, Stand: 16.07.2013
215
vgl. http://de.piwik.org/, Stand: 16.07.2013
212
73
6 Kommunikation
6.2
MAILINGLISTEN
74
UND
FOREN
Einen direkteren Austausch von Informationen als Webseiten ermöglichen Mailinglisten und Foren. Diese können unterschiedliche
Schwerpunkte haben z.B. die Besprechung zukünftiger Funktionen
oder das Anbieten von Support.
E-Mails sind dabei meist der kleinste gemeinsame Nenner aller
Kommunikationsmittel. Um eine E-Mail zu schreiben, muss in der
Regel niemand eine zusätzliche Software installieren, einen neuen
Account anlegen oder ein neues Programm erlernen. Die Kommunikation über E-Mails funktioniert asynchron. Zur Beantwortung einer
E-Mail kann sich ein Nutzer beliebig viel Zeit nehmen und andere
Nutzer sehen nicht, ob man gerade online ist oder nicht.
Öffentliche E-Mailkommunikation mit vielen Personen gleichzeitig
sollte über Mailinglisten-Software wie GNU Mailman oder Google
Groups erfolgen, welche An- und Abmeldevorgänge als Schutz vor
Spam bieten. 216,217
Mailinglisten sind Foren sehr ähnlich, was die Art der Kommunikation nach Themen angeht. Foren sind jedoch meist in sich
geschlossene Systeme, welche eigene Accounts erfordern. Dies ermöglicht speziellere und häufig frei anpassbare Funktionen, die
innerhalb der Foren eingesetzt werden können. Eine bekannte
erweiterbare Forensoftware ist phpBB.218
Je nach Umfang der Kommunikationsmöglichkeiten des IssueTracking-Systems kann dieses durchaus auch als rudimentäres Forum
betrachtet werden, in welchem jedes „Thema“ ein „Issue“ repräsentiert.
Es können auch existierende Foren zu Diskussionszwecken verwendet werden. Eines der bedeutendsten Supportforen für Entwickler ist StackOverflow .219
Verwendet man ein Forum eines Drittanbieters, verliert man jedoch
ein gewisses Maß an Kontrolle über die dort verfassten Daten. Nicht
immer lassen sich die Daten im Nachhinein exportieren und sichern.
Durch ihre Öffentlichkeit und beliebig große Anzahl an Nutzern
laufen Mailinglisten und Foren Gefahr Opfer des Bikesheddings220 zu
werden. Die Metapher des Bikesheddings beschreibt eine sinnlose
Diskussion, in welcher sich jeder Gesprächsteilnehmer darüber einig
ist einen Fahrradschuppen zu bauen, aber jeder eine andere Farbe
216
vgl. http://www.gnu.org/software/mailman/, Stand: 16.07.2013
vgl. https://groups.google.com/, Stand: 16.07.2013
218
vgl. https://www.phpbb.com/, Stand: 16.07.2013
219
vgl. http://stackoverflow.com/, Stand: 16.07.2013
220
bike shed (englisch „Fahrradschuppen“)
217
6 Kommunikation
75
für die Wände verwenden möchte. Da man sich nicht auf eine Farbe
einigen kann, wird endlos weiter diskutiert und der Fahrradschuppen somit nie gebaut. Es ist Aufgabe des Project Leads oder
des Community Managers (s. 6.9) nicht zielführende Diskussionen zu
unterbinden. 221
6.3
INTERNET RELAY CHATS
UND INSTANT
MESSENGER
Falls der asynchrone Kommunikationsstil von Mailinglisten und
Foren für ein Gespräch nicht ausreicht, werden Internet Relay Chats
(IRCs) oder Instant Messenger (IMs) eingesetzt. Sie können im Zweifelsfall ein Gespräch unter vier Augen ersetzen und ermöglichen
einen schnellen Informationsaustausch.
IRCs sind textbasierte Chatsysteme mit unbegrenzter Teilnehmerzahl. Sie sind deswegen meistens öffentlich zugängliche Diskussionsorte zu einem bestimmten Thema, ermöglichen aber auch das
Versenden privater Nachrichten.
Aufwendigere private Unterhaltungen zwischen einer begrenzten
Teilnehmerzahl lassen sich durch IMs realisieren. So lassen sich
abhängig vom gewählten IM Video- und Audioübertragungen, Dateitransfers sowie das Einbinden von Bildern direkt im Chatfenster
realisieren. IMs eignen sich damit ideal für kurze Nachfragen, aber
auch für längere Abstimmungen mit einzelnen Personen.
Bekannte IRC-Clients sind mIRC, Pidgin und Adium . Verbreitete IMs
sind Skype, Google Hangouts und Facetime.222,223,224,225,226,227
Für Unternehmen interessant ist das IM-ähnliche und kostenpflichtige Campfire, welches komplett webbasiert ist und für
Gruppenchats optimiert wurde.228
6.4
ROADMAP
Eine Roadmap ist der Entwicklungszeitplan einer OSS. Dieser kann
grob oder detailliert formuliert und öffentlich oder privat sein.
Es ist ratsam eine Roadmap in irgendeiner Form öffentlich zu präsentieren. Dies gibt allen Usern einer OSS die Gewissheit, dass sich
221
vgl. http://bikeshed.com/, Stand: 25.07.2013
vgl. http://www.mirc.com/, Stand: 22.07.2013
223
vgl. http://pidgin.im/, Stand: 22.07.2013
224
vgl. https://www.adium.im/, Stand: 22.07.2013
225
vgl. http://www.skype.com/de/, Stand: 22.07.2013
226
vgl. http://www.google.com/hangouts/, Stand: 22.07.2013
227
vgl. http://www.apple.com/de/mac/facetime/, Stand: 22.07.2013
228
vgl. http://campfirenow.com/, Stand: 22.07.2013
222
6 Kommunikation
76
die Software noch weiterentwickelt und in welche Richtung diese
Entwicklung geht. Innerhalb der Roadmap sollten nur dann konkrete
Termine genannt werden, wenn diese mit Sicherheit eingehalten
werden können. Andernfalls sind die User enttäuscht.
Es können auch problemlos mehrere Roadmaps gleichzeitig geführt
werden: eine öffentliche und eine private. So kann die private
Roadmap zur besseren Planung der Entwicklung detaillierter sein
und die User sind nicht enttäuscht, wenn sich der Einbau einer
Funktion verspätet, da sie es nicht erfahren.
Nicht jedes Projekt benötigt dabei eine dedizierte Roadmap in
textlicher oder tabellarischer Form. Je nachdem wie sie aufgebaut
sind, repräsentieren Issue-Tracking-Systeme oder Planning Boards
eine Art von Roadmap. So können Tickets und Aufgabenpakete
festen Meilensteinen zugeordnet werden und zeigen einen zeitlichen
Ablauf der Entwicklung. In diesem Fall sollten die Systeme bzw.
Boards jedoch gut gepflegt und entsprechend beschriftet sein, damit
sie von allen Usern schnell erfasst werden können.
6.5
ZEITSCHRIFTEN
UND
ONLINEMAGAZINE
Ein weiterer wichtiger Kommunikationskanal sind Zeitschrift und
Onlinemagazine. Die Relevanz klassischer Printzeitschriften ist in
den meisten Fällen nur bei größeren OSS-Projekten gegeben. So gibt
es mehrere Magazine, welche sich komplett mit Linux auseinander
setzen. Aber auch über rAppid.js wurde bereit in der dotnetpro
berichtet. Eine OSS-nahe populäre Zeitung ist die c't des Heise Zeitschriften Verlags, welche je nach Thema auch kleinere Projekte vorstellt.229,230,231,232
Mehr Erfolg auf Veröffentlichung eines Artikels über die eigene OSS
versprechen dagegen Onlinemagazine wie heise online, Golem oder
t3n. Durch geringere Produktionskosten können online mehr Artikel
zu unterschiedlichen Themen veröffentlicht werden. 233,234,235,236
Für kleine Projekte ist es sinnvoll befreundete Blogger über eine OSS
schreiben zu lassen. Viele Entwickler sind selbst Blogger, welche
wiederum andere Blogger kennen. Ab einer gewissen Zahl an Contri-
229
vgl. http://www.linux-magazin.de/, Stand: 22.07.2013
vgl. http://www.linux-user.de/, Stand: 22.07.2013
231
vgl. http://blog.rappidjs.com/2013/08/article-about-rappidjs-in-dotnetpro.html, Stand: 26.08.2013
232
vgl. http://www.heise.de/ct/, Stand: 22.07.2013
233
vgl. http://www.heise.de/, Stand: 22.07.2013
234
vgl. http://www.golem.de/, Stand: 22.07.2013
235
vgl. http://t3n.de/, Stand: 22.07.2013
236
vgl. http://suite101.com/article/print-vs-online-magazines-a155014, Stand: 04.09.2013
230
6 Kommunikation
butoren ist ein kleines Blogging-Netzwerk für ein OSS ein Selbstläufer. Diese Eigendynamik kann beschleunigt werden, indem man
selbst als Blogautor tätig wird und eigene Artikel verfasst. Damit ist
nicht unbedingt ein Blog über das Projekt selbst gemeint, sondern
ein eigenständiger Blog, welcher sich auch mit anderen verwandten
Themen beschäftigen kann.
6.6
DOKUMENTATION
Unabhängig vom eigentlichen Kanal ist die Dokumentation der OSS
der wichtigste Inhalt, der vermittelt werden sollte. Je nach Art und
Umfang der OSS kann die Pflege der Dokumentation aufwändiger
sein als die eigentliche Entwicklung der Software.
Die Dokumentation richtet sich an unterschiedliche Zielgruppen. Sie
richtet sich an neue User, welche eine Installationsanleitung benötigen, genauso wie an erfahrene User, die die spezifische Signatur
einer Funktion suchen. Sie richtet sich aber ebenso an Contributoren, welche bspw. den Code Style Guide nachlesen möchten.
Typische Formen einer Dokumentation sind: 237
•
•
•
•
•
237
238
API-Referenz:
Eine Auflistung aller Entwicklungsschnittstellen mit Erklärungen
zu ihrem Einsatz. Sie ist besonders für Contributoren wichtig
oder wenn die Zielgruppe der User selbst Entwickler sind.
Frequently Asked Questions (FAQ):
Sollte eine bestimmte Frage eines Users oder Contributoren
mehrfach an den Autoren gestellt werden, sollte er diese mit
einer Antwort unmittelbar innerhalb eines öffentlichen FAQs
festhalten. Taucht die Frage ein weiteres Mal auf, kann er so auf
das FAQ verweisen und spart Zeit.
Guidelines:
Guidelines richten sich in der Regel an Contributoren. Hier
werden unter anderem die Coding Style Konventionen festgehalten.
Handbuch:
Handbücher beinhalten die zuvor genannten Punkte in ausführlich beschriebener textlicher Form. Druckausgaben eines Handbuchs, erscheinen häufig in Kooperation mit einem Verlag wie
bei Pro Git. Handbücher versuchen alle bzw. die meisten
Problemfälle einer OSS abzudecken.238
How-to:
Ein How-to ähnelt einem kurzen Handbuch. So beschriebt es
vgl. Prokop, Open Source Projektmanagement, 2010, S. 201 f.
vgl. http://git-scm.com/book/de, Stand: 22.07.2013
77
6 Kommunikation
•
•
•
•
•
•
ebenfalls eine Problemlösung in Form eines Fließtexts. Es ist
meist mit einem Beispiel verbunden und richtet sich häufig an
Laien.
Knowledge Base:
Eine Knowledge Base ist das Referenzverzeichnis zu jeglicher Art
von Dokumentationen. Es verweist auf FAQs, Guidelines oder
How-tos gleichermaßen. Hierfür ist meist die Wiki-Software
zuständig (s. 5.5.6).
Manpage:
Manpages sind speziell aus dem Unix-Umfeld stammende knappe
Beschreibung der Verwendung eines Software.
Online-Hilfe:
Die Online-Hilfe bezeichnet in diesem Fall eine kontextsensitive
Hilfesuche in der Knowledge Database bei der Verwendung der
Software selbst.
Referenzkarten:
Sie beschreiben in kurzen Zusammenfassungen wichtige
Funktionen der Software. Durch ihre geringe Größe können sie
ausgedruckt am Arbeitsplatz verwendet werden. Sie sind auch
unter dem englischen Begriff cheat sheet bekannt.
Screencasts:
Screencasts sind How-tos sehr ähnlich, jedoch nicht textbasiert
sondern in Videoform. Besonders die Bedienung komplexer
Oberflächen lässt sich häufig innerhalb eines Videos besser
demonstrieren als per Text.
Tutorials:
Tutorials sind weniger problembezogen als ein How-to und
richten sich an Fortgeschrittene und Laien gleichermaßen um
einen Überblick über die Verwendung der Software zu schaffen.
Eine genaue Trennung zwischen Tutorials und How-tos fällt
schwer, jedoch sind Tutorials häufiger aufeinander aufbauend
gestaltet als How-tos und bekommen damit den Charakter eines
kurzen Handbuches.
Eine weitere von Prokop nicht genannte Dokumentationsform sind
Snippets. Snippets sind in der Regel kurze Auszüge eines Quellcodes, die einen bestimmten Problemfall lösen. Durch ihre Kürze
sind sie häufig selbsterklärend. Eine Zusammenfassung von Snippets, die auch etwas ausführlicher ausfallen können, nennt man
Cookbook. GitHub bietet einen speziellen Snippet Service namens
Gists innerhalb dessen Snippets versioniert und kommentiert werden
können.239
239
vgl. https://gist.github.com/, Stand: 22.07.2013
78
6 Kommunikation
FALLSTUDIE
Einige Bereiche der Dokumentation eines Projekts können sehr
stark automatisiert werden. Bei rAppid.js wird bspw. die komplette Dokumentation der API über Metadaten im Quellcode generiert. Um den Dokumentationsaufwand gering zu halten, müssen
Entwickler kreativ sein.
Für rAppid.js wurde deswegen der Service try.rappidjs.com entwickelt. Bei diesem Dienst handelt es sich um einen Editor, der die
Bearbeitung und das Anlegen neuer Dateien innerhalb des
Browsers ermöglicht, um so schnell einfache Demoapplikationen
mit rAppid.js zu entwickeln. Der Dienst soll in Zukunft stark ausgebaut werden, um bspw. das Speichern und Teilen der Prototypen zu ermöglichen. Die dabei entstehenden Code Snippets
können dann in anderen Bereichen der Dokumentation als Beispiel verwendet werden oder aber bei Supportanfragen ein
Problem besser beschreiben. Da der Editor mit rAppid.js selbst
entwickelt wurde, dient er gleichzeitig als Machbarkeitsstudie und
Aushängeschild des Frameworks und führte zum Einbau neuer
Features.
Fallstudie 8 – rAppid.js
Die Dokumentation sollte immer aktuell sein, egal in welcher Form
sie präsentiert wird. Für den User stellt es einen gewissen Aufwand
dar, nach der Lösung eines Problems zu suchen. Hat er dies getan
und die Dokumentation stellt sich als falsch heraus, so ist er frustriert.
Inhalte, die eine Dokumentation abdecken sollte, sind u.a. Anwendungsbeschreibungen, Installationshinweise, Integrationshinweise
in andere Systeme, Einstellungs- und Monitoringmöglichkeiten,
sowie Migrations- und Wartungsanleitungen.240
6.7
SOZIALE NETZWERKE
Soziale Netzwerke erfüllen die gleiche Funktion wie klassische
Mundpropaganda. Im Idealfall geben sie eine Nachricht nach dem
Schneeballprinzip weiter. Auf dem Weg dahin können Meinungen
ausgetauscht, neue Kontakte geknüpft, Contributoren gefunden und
User Feedback eingesammelt werden. Eine Win-win-Situation für
alle.
Da dieses System so reizvoll ist, ist es dementsprechend überlaufen.
Nachrichten, die ein Rezipient als nutzlos empfindet, werden als
240
79
6 Kommunikation
Rauschen oder Spam bezeichnet. Dieses Rauschen ist innerhalb
sozialer Netzwerke sehr groß.
Um eine Nachricht innerhalb eines Netzwerkes über eigene Kontakte
hinaus zu verbreiten, müssen deswegen wichtige Multiplikatoren
bzw. Meinungsmacher gefunden werden. Sie sind Autoritätspersonen innerhalb der Netzwerke und fungieren als natürliche Spamfilter. Nachrichten, welche von Multiplikatoren weitergegeben
werden, werden als sinnvoll und nützlich erachtet. Das Identifizieren von Multiplikatoren ist in der Regel einfach. Es sind diejenigen
Personen, die am häufigsten zitiert werden und die die meisten
Follower/Freunde/Leser besitzen. Teilweise werden von den Communities auch Listen der wichtigsten Multiplikatoren ihrer jeweiligen
Technologie erstellt und veröffentlicht, da jeder davon profitiert,
gute und wichtige Nachrichten zu erhalten. Webentwickler finden
bspw. unter Front-end Rescue wichtige Multiplikatoren.241,242
Hat man die benötigten Multiplikatoren identifiziert, müssen sie
noch die entsprechende Nachricht weitergeben. Für diesen Weg gibt
es allerdings keine goldene Regel. Multiplikatoren sind genau
deswegen bedeutend für ein Netzwerk – sie geben nicht jede
beliebige Nachricht weiter. Damit sie eine Nachricht als wichtig
erachten, muss sie es auch wirklich sein. Sie dienen damit als
Kontrollinstanzen des eigenen Projekts. Wenn sie eine OSS für unwichtig erachten, ist sie es vielleicht auch und ihr Entwicklungsaufwand wäre unnötig.
Eine weitere Möglichkeit wäre es selbst zu einem Multiplikator zu
werden. Dies ist mit viel Aufwand verbunden, jedoch nicht unmöglich. Möglicherweise ist man selbst oder ein Contributor bereits
ein Multiplikator. Der zuvor genannte Tim Pritlove, einer der Initiatoren von Podlove (s. 4.4 ZIELGRUPPENANALYSE), ist bspw. ein wichtiger
Multiplikator innerhalb der deutschen Podcast Community.
Um soziale Netzwerke als Marketingkanal zu nutzen, ist es wichtig
darauf zu achten, welche Zielgruppe das Netzwerk bedient.
Während Facebook sich vornehmlich an private Kontakte richtet und
eventuell noch als Auftritt für Firmen und Projekte dienen kann,
findet man hier weniger aktive Entwickler für Unterhaltungen.
Twitter eignet sich wiederum wegen der Kürze der Nachrichten gut
für unpersönliche Kommunikation nach außen und beherbergt viele
Entwickler. Google+ besitzt aus historischen Gründen viele aktive
Webentwickler, da viele Google Mitarbeiter dieses Netzwerk nutzen.
Andere Netzwerke, die sich eher an private Kontakte orientieren,
241
242
vgl. http://uptodate.frontendrescue.org/, Stand: 22.07.2013
80
6 Kommunikation
wären Pinterest oder Foursquare. Das Netzwerk LinkedIn richtet sich
im Gegensatz dazu an geschäftliche Kontakte. 243,244,245,246,247,248,249
Neben der Einteilung von sozialen Netzwerken in private und geschäftliche Kontakte können sie auch thematisch gruppiert werden.
So richtet sich StackOverflow an supportsuchende Entwickler und
GitHub an Entwickler, welche Projekte und Code austauschen
möchten. Diese Einteilungen können beliebig fein sein. CodePen
richtet sich bspw. ausschließlich an Webentwickler, welche Code
austauschen möchten. Je spezialisierter ein Netzwerk ist, desto
höher ist zwar die Relevanz, aber desto geringer ist auch die Streuwirkung. Dies sollte immer mit bedacht werden.250,251,252
Eine weitere Einteilungsmöglichkeit von Netzwerken richtet sich
nach kulturellen und historischen Gegebenheiten. So ist Orkut von
Google eine in Deutschland kaum bekannte Alternative zu Facebook,
welche jedoch in Brasilien und Indien sehr beliebt ist. XING
wiederum ist eine in Deutschland sehr beliebte Alternative zu
LinkedIn. 253,254,255,256
Im Allgemeinen gilt: Die Größe von sozialen Netzwerken ist Fluch
und Segen zugleich. Um gegen das hohe Rauschen an Informationen
anzukommen, hilft es nur hochwertige und nützliche Inhalte zu
veröffentlichen. Sie sollten sich direkt an die Zielgruppe richten und
deswegen die Wahl des Netzwerkes beeinflussen. Es hilft wichtige
Informationen weiterzugeben und anderen zu helfen, um so selbst
ein bestmöglicher Multiplikator zu werden.
6.8
VERANSTALTUNGEN
Veranstaltungen sind eine gute Möglichkeit, um ein OSS-Projekt bekanntzumachen und andere Entwickler persönlich kennenzulernen.
243
vgl. https://www.facebook.com/, Stand: 22.07.2013
vgl. https://twitter.com/, Stand: 22.07.2013
245
vgl. https://plus.google.com/, Stand: 22.07.2013
246
vgl. http://lifehacker.com/5842997, Stand: 22.07.2013
247
vgl. https://pinterest.com/, Stand: 22.07.2013
248
vgl. https://de.foursquare.com/, Stand: 22.07.2013
249
vgl. https://linkedin.com, Stand: 22.07.2013
250
vgl. http://stackoverflow.com/, Stand: 22.07.2013
251
vgl. https://github.com/, Stand: 22.07.2013
252
vgl. http://codepen.io/, Stand: 22.07.2013
253
vgl. http://orkut.com, Stand: 22.07.2013
254
vgl. http://social-networking-websites-review.toptenreviews.com/orkut-review.html, Stand: 22.07.2013
255
vgl. http://www.xing.com/, Stand: 22.07.2013
256
vgl. http://peopleandmedia.wordpress.com/2012/02/04/xing-versus-linkedin-fakten-zu-den-karrierenetzwerken/, Stand: 22.07.2013
244
81
6 Kommunikation
Konferenzen sind meist mehrtägige Veranstaltungen auf denen
Vorträge präsentiert und Seminare durchgeführt werden. Als Redner
wird man dabei entweder eingeladen oder man muss sich bewerben.
Allerdings kann man auch einfach als Teilnehmer der Konferenz
Werbung für seine OSS machen, in dem man aktiv andere Teilnehmer
anspricht.
Thematisch kann eine Konferenz sehr breit gefasst sein oder sich an
einer kleineren Zielgruppe orientieren. Während sich bspw. die
FOSS.IN OSS-Projekten im Allgemeinen widmet, konzentriert sich die
JSConf auf Projekte mit JavaScript.257,258
Konferenzen sind häufig mit hohen Teilnehmerkosten verbunden.
Dafür wird garantiert, dass die Vorträge und Seminare eine hohe
Qualität aufweisen und jeder Teilnehmer wirklich da sein will. Dies
ist keine Nebensächlichkeit: Konferenzteilnehmer wollen von neuen
Projekten, Themen und interessanten Personen erfahren. Sie sind
dementsprechend offen und motiviert.
Eine kostengünstigere und ungezwungenere Alternative zu Konferenzen sind so genannte BarCamps. Sie bezeichnen sich auch als
Un-Konferenzen. Die Idee hinter BarCamps ist, dass sie von den
Anwesenden selbst organisiert werden und dementsprechend jeder
als Redner auftreten kann. Eine Agenda aller Präsentationen und
Workshops wird in der Regel erst am Eröffnungstag selbst erstellt –
nach Abstimmung aller Teilnehmer. Sie sind zudem in der Regel
kostenlos. 259,260,261
Interessante und neue OSS-Projekte können innerhalb eines
BarCamps somit informell und schnell präsentiert werden.
Noch informeller als BarCamps sind Community-Treffen. Dies sind
meist überregionale Treffen von Interessengruppen, welche sich
bisher nur virtuell oder flüchtig kennen. Im Gegensatz zu Konferenzen und BarCamps steht das persönliche Kennenlernen von
Gleichgesinnten im Vordergrund. Der Austausch über Neuigkeiten
ergibt sich dabei von selbst.
Ein Beispiel eines Community-Treffens ist die BeerJS, ein Treffen von
JavaScript Entwicklern in diversen amerikanischen Städten. Sie
finden in öffentlichen Bars statt, sodass das Halten von Vorträgen
im Wesentlichen von vornherein ausgeschlossen wird. Der Name des
Treffens verdeutlichen den informellen Charakter.262
257
vgl. http://foss.in/, Stand: 22.07.2013
vgl. http://jsconf.com/, Stand: 22.07.2013
259
vgl. http://t3n.de/news/grosser-barcamp-uberblick-alle-un-konferenzen-255252/, Stand: 23.07.2013
260
vgl. http://www.barcampsaigon.org/info/, Stand: 23.07.2013
261
vgl. http://systemscamp.org/was-ist-ein-barcamp/, Stand: 23.07.2013
262
vgl. https://github.com/beerjs, Stand: 23.07.2013
258
82
6 Kommunikation
Eine weitere Veranstaltungsform sind die sogenannten User Groups,
welche ebenfalls eine Interessensgruppe repräsentieren. Sie sind
informell, kostenlos und von den Teilnehmern selbst organisiert.
Anders als Community-Treffen finden User Groups häufig in kürzeren
Abständen, in kleineren Gruppen und regionaler statt. Treffen
können stammtischartig in der Kneipe stattfinden und komplett aus
spontanen Gesprächen bestehen oder aber die Teilnehmer halten
sich gegenseitig Vorträge und geben Workshops.
Die Leipziger JavaScript User Group trifft sich bspw. einmal im
Monat. Bei einem Treffen hält ein Teilnehmer einen Vortrag, über
dessen Thema zuvor abgestimmt wurde.263
Die zuvor genannten Veranstaltungsformen dienen einer groben
Klassifizierung. In der Praxis sind die Übergänge zwischen ihnen
fließend. Ein kleines Community-Treffen könnte bspw. als große
User Group angesehen werden. Die Klassifizierung sollte deswegen
nicht zu streng betrachtet werden.
FALLSTUDIE
Seit 2006 ist Alexander Groß Mitorganisator der Leipziger .NET
User Group, welche sich ungefähr einmal im Monat trifft. Durch
die User Group konnte er viel Erfahrung im Bereich der Moderation und der Eventplanung lernen und betreute über die Jahre
immer mehr Events. So begleitete er als Organisator zweimal die
.NET Summer Camps in Leipzig.
Nach dieser Erfahrung wuchs sein Wunsch eine Un-Konferenz zu
veranstalten, um den Organisationsaufwand klassischer Konferenzen zu verringern. Anstatt Sprecher zu kontaktieren, eine
Agenda aufzustellen, Slots zu reservieren und Notfallpläne zu
entwickeln, falls ein Sprecher ausfällt, werden beim Developer
Open Space alle Themen von den Teilnehmern selbst entwickelt
und vorgetragen. Die Veranstaltung begann ursprünglich als .NETspezifisches Treffen, deckt aber mit ihren jetzigen bis zu 180
Teilnehmer alle Themenbereiche der Softwareentwicklung ab.
Damit bei so vielen Teilnehmern die Diskussionen trotzdem noch
zielführend sind, werden immer wieder neue Moderationskonzepte wie die Fishbowl oder das World-Café getestet. Ist jemand
trotzdem nicht mit der Themenfindung zufrieden, empfiehlt
Alexander das „Gesetz der zwei Füße“: gehe zu einer anderen
Gruppe, die sich gerade mit einem anderen Thema beschäftigt.
Das ist bei Un-Konferenzen nicht unhöflich, sondern erwünscht.
„Bleibe nur so lange du etwas lernen oder beitragen kannst!“ und
263
vgl. http://leipzigjs.github.io/, Stand: 23.07.2013
83
6 Kommunikation
lernen kann man bei einer Un-Konferenzen auf dem Flur und in
der Kaffeepause ebenso wie bei einer Präsentation.
Als wichtigste Motivation der Teilnehmer an einer Un-Konferenz
sieht er neben dem Lernen auch das Netzwerken.
Fallstudie 9 – .NET User Group und Developer Open Space
Für Marcus Krejpowicz und Tony Findeisen zählen Präsentationen auf
Veranstaltungen zum wichtigsten Kommunikationskanal. Trotz Vorstellungen von rAppid.js in Web- und Printmedien, welche eine
wesentlich höhere Reichweite haben, ist das Feedback auf Veranstaltungen am ausführlichsten und persönlichsten.
6.9
COMMUNITY MANAGEMENT
Die zuvor vorgestellten Kommunikationskanäle besitzen alle bestimmte Besonderheiten und sollten je nach Anforderung angewandt werden. Nach Betrachtung aller Kanäle sollte jedoch deutlich
sein, dass eine gute Projektkommunikation unmöglich nur über
einen Kanal durchgeführt werden kann. So wie ein Projekt über
mehrere Kanäle Informationen verteilt, so konsumiert eine einzelne
Person diese ebenfalls über mehrere Kanäle. Es ist demnach wichtig,
dass über alle Kanäle hinweg ein einheitliches Community Management betrieben wird.
Eine Community ist eine Gruppe im soziodynamischen Sinn. Dies
sind Gruppen bestehend aus mindestens zwei Personen, welche
häufig und über einen längeren Zeitraum direkt miteinander in
Kontakt treten.
Sie verfolgen ein gemeinsames Ziel und gleiche Interessen,
wodurch ein Zugehörigkeitsgefühl entsteht. Dabei sind „Gruppen
keine einfache Addition von Individuen [...], sondern soziale
Einheiten mit speziellen Interaktionsprozessen“.264
Definition 4 – Community
Das Gegenteil einer Gruppe im soziodynamischen Sinn ist eine zufällig zusammengestellte Gruppe ohne Zugehörigkeitsgefühl. Solch
eine Gruppe ist bspw. die Warteschlange an einer Kasse.
Eine OSS-Community umfasst Contributoren und User gleichermaßen. Gerade bei der Initiierung eines OSS-Projekts sollte darauf
geachtet werden, dass das Entstehen einer Community ein Prozess
ist, welcher mehrere Phasen durchläuft. In jeder Phase verhält sich
264
84
6 Kommunikation
die Community anders. Nach Bruce Tuckman besteht dieser Entwicklungsprozess aus exakt vier Phasen: 265
1. Formierungsphase (forming):
In dieser Phase lernen sich die Gruppenmitglieder kennen. Sie
prüfen sich auf Gemeinsamkeiten und entwickeln dabei Sympathie oder Antipathie. Unsicherheit herrscht vor.
2. Sturmphase (storming):
Nach dem Kennenlernen aller Teilnehmer entstehen erste Konflikte darüber, wer die Gruppe anführt. Machtkämpfe entstehen
und können die Auflösung der Gruppe bedeuten.
3. Normierungsphase (norming):
Aufbauend auf den vorherigen Machtkämpfen bilden sich feste
Strukturen und Rollen innerhalb der Gruppe heraus. Gruppenmitglieder wünschen sich Harmonie und kooperieren miteinander.
4. Reifephase (performing):
Die letzte und produktivste Phase beginnt. Die Kommunikation
und die Arbeitsabläufe untereinander werden optimiert. Die
Gruppe agiert als Einheit, um ein gemeinsames Ziel zu erreichen.
Durch das Beitreten neuer Mitglieder kann die Gruppe wieder zurück
in die Sturmphase versetzt werden.
Die Stärke des Gruppenzusammenhalts wird als Kohäsion bezeichnet. Je stärker die Kohäsion, desto geringer die Gefahr, dass die
Gruppe bei einem Konflikt zerbricht. Mitglieder einer hoch kohäsiven Gruppe sind zufrieden und motiviert. Sie messen der Gruppe
eine hohe Bedeutung in ihrem Leben zu. In gewisser Weise ist diese
Gruppe Teil ihrer Persönlichkeit. Dieses Identitätsdenken wird innerhalb von Firmen als Unternehmenskultur bezeichnet. Eine positive
Unternehmenskultur führt damit zu einer höheren Kohäsion.266
Die Homogenität einer Gruppe steht ebenfalls im festen Zusammenhang mit der Kohäsion. Folgende Charakteristika ergeben sich
dabei: 267
•
•
•
265
Je höher die Kohäsion ist, um so mehr gleichen sich die
Gruppenteilnehmer untereinander an.
Wenig konforme Mitglieder stoßen auf Ablehnung. Diese ist um
so größer, je höher die Kohäsion ist.
Neue Mitglieder werden nur aufgenommen, wenn sie möglichst
konform mit der Gruppe sind.
267
266
85
6 Kommunikation
•
•
•
•
Die Höhe der Kommunikation und der Kohäsion innerhalb der
Gruppe stehen in direktem Zusammenhang.
Hoch kohäsive Gruppen zeigen sich anderen gegenüber eher als
feindselig. Die Abgrenzung nach außen ist stärker.
Kleine Gruppen sind kohäsiver als große.
Je stärker die Abhängigkeit der Teilnehmer untereinander ist
desto höher ist die Kohäsion.
Aufgabe des Community Managers ist es die Kohäsion der Community
zu verbessern, um die Zufriedenheit und Produktivität zu steigern
und gleichzeitig die dabei entstehenden Gefahren, wie die frühzeitige Ablehnung eines neuen Mitglieds, gering zu halten.
Der Community Manager muss eine reibungslose und möglichst
konfliktfreie Kommunikation ermöglichen. Es ist seine Aufgabe, dass
Inhalte im entsprechenden Kommunikationskanal seiner Zielgruppe
leicht auffindbar und aktuell sind. Er muss außerdem den Austausch
von Informationen über mehrere Untergruppen hinweg koordinieren. Für die Contributoren filtert er das Feedback der User, um keine
alten oder doppelten Beschwerden aufzunehmen. In umgekehrter
Richtung erklärt er den User leicht verständlich die technischen
Entscheidungen der Contributoren. Eine Community Manager gibt
den unsichtbaren Kommunikationswegen zwischen diesen Gruppen
ein Gesicht und agiert als zentrale Schnittstelle der Kommunikation.
Seine Präsenz erleichtert neuen Communitymitgliedern die Orientierung. Gleichzeitig entstehen dadurch enge Abhängigkeiten. Fühlen
sich User einem Community Manager sehr verbunden, so können sie
ein OSS-Projekt schnell verlassen, sobald auch der Community
Manager das Projekt verlässt. Es ist dabei ratsam die Arbeit auf
mehrere Community Manager zu verteilen.
Zu seinem Aufgabenbereich zählt das Qualitätsmanagement der
Inhalte, die auf den unterschiedlichen Kommunikationskanälen
ausgegeben werden. Sie sollten aktuell und einheitlich sein sowie
frei von Rechtschreib- und Verständnisfehlern. Festgehaltene Verhaltensregeln, die sogenannte Netiquette, sorgen für einen höflichen und respektvollen Umgangston. Richtet sich das Projekt an
ein internationales Publikum, sollte der Community Manager darauf
achten, dass möglichst alle Beteiligten auf Englisch kommunizieren.
Die wichtigste Aufgabe des Community Managers ist das Lösen von
Konflikten innerhalb der Community. Dabei muss er zunächst
positive Konflikte, welche zu konstruktivem Feedback führen
können, von negativen und zerstörerischen Konflikten trennen.
Anschließend muss er letztere möglichst ohne Verluste wie dem
Austritt eines Mitglieds aus der Community lösen. Friedrich Glasl
entwarf ein Phasenmodell der Konflikteskalation, um Konflikte
besser einschätzen und auf sie reagieren zu können.
86
6 Kommunikation
Innerhalb dieses Modells findet ein Konflikt immer zwischen zwei
Parteien statt. Der Konflikt kann bis zu neun Stufen durchlaufen,
wobei die entstehenden Schäden mit jeder Stufe zunehmen. Ziel des
Community Managers ist es deswegen den Konflikt auf einer
möglichst niedrigen Stufe zu lösen. Zu diesem Zweck können die
neun Phasen in drei Ebenen unterteilt werden, welche den Konfliktausgang näher beschreiben, sowie in fünf Interventionsmethoden
zur Lösung des Konflikts. 268,269,270
Die neun Phasen der Konflikteskalation sind:
1. Verhärtung:
Die Differenzen zwischen den Parteien werden zum ersten Mal
bewusst wahrgenommen. Die Meinungen verhärten sich, aber
der Wunsch und der Glaube an die Kooperation überwiegen
einem Konkurrenzdenken.
2. Debatte:
Zwischen den Parteien findet eine Polarisation und Abgrenzung
statt. Gegenargumente werden kaum noch wahrgenommen. Die
Parteien wechseln kontinuierlich zwischen Kooperation und
Konkurrenz.
3. Taten:
Die Parteien glauben nicht mehr daran den Konflikt durch Gespräche zu lösen. Sie setzen ihre Meinung in die Tat um und
versuchen dadurch Stärke zu demonstrieren.
4. Koalitionen:
Jede Partei wirbt um neue Anhänger um ihre Überlegenheit zu
demonstrieren. Die gegnerische Partei wird zum Feind erklärt.
Objektive Wahrnehmungen sind nicht mehr möglich.
5. Gesichtsverlust:
Der Feind soll öffentlich bloßgestellt und diffamiert werden. Der
öffentliche Angriff gilt häufig als point of no return.271
6. Drohstrategien:
Die Parteien drohen untereinander mit Sanktionen und führen
sie durch. Erste große Schäden entstehen.
7. Scharmützel:
Angriffe werden nun ohne Drohung durchgeführt.
8. Krieg:
Mittlerweile ist nicht mehr das Durchsetzen der eigenen Überzeugung das Ziel, sondern die Vernichtung des Feindes.
268
vgl. Weh, Enaux, Konfliktmanagement: Konflikte kompetent erkennen und lösen, 2008, S. 62 f.
270
vgl. Meinholz, Förtsch, Führungskraft Ingenieur, 2010, S. 402 ff.
271
point of no return (englisch „Punkt ohne Wiederkehr“)
269
87
6 Kommunikation
9. Gemeinsam in die Abgrund:
Für die Zerstörung des Feindes wird die Selbstvernichtung in
Kauf genommen.
Die Einteilung der Konflikteskalationsphasen in Ebenen lautet:
1. Win-win:
In den Phasen 1–3 können beide Parteien noch gewinnen.
2. Win-lose:
In den Phasen 4–6 kann nur noch eine Partei gewinnen.
3. Lose-lose:
In den Phasen 7–9 kann keine Partei mehr gewinnen.
Je nach Phase lassen sich eine oder mehrere Interventionsmöglichkeiten durchführen:
1. Moderation:
In den Phasen 1–3 kann ein Moderator als Konfliktlöser eingesetzt werden. Er dient den Parteien als Hilfe zur Selbsthilfe
indem er Gespräche neutral überwacht und regt Lösungsvorschläge in Zusammenarbeit mit beiden Parteien an. Die Gespräche sind sachlich orientiert.
2. Prozessbegleitung:
In den Phasen 3–5 sollen durch eine Prozessbegleitung aktuelle
Probleme und verhärtete Ansichten erkannt und gelockert
werden. Im Gegensatz zum Moderator betrachtet der Prozessbegleiter die Gespräche nicht mehr ausschließlich von außen,
sondern nimmt auch an ihnen teil.
3. Mediation/Vermittlung:
In den Phasen 5–7 muss die Konfliktlösung über einen Vermittler
stattfinden, da die Parteien nicht mehr direkt kooperieren
können. Der Mediator muss von beiden Parteien anerkannt sein
und handelt Kompromisse aus.
4. Schiedsverfahren:
In den Phasen 6–8 entscheiden nicht mehr die Parteien, sondern
ein neutraler Richter über die beste Konfliktlösung. Seine Aufgabe besteht aus einer gründlichen Untersuchung der Ausgangssituation und der Wahl und Umsetzung der Lösung.
5. Machteingriff:
In den Phasen 7–9 kann ein Machteingriff angewandt werden.
Dieser kann komplett gegen den Willen und ohne Berücksichtigung der beiden Parteien erfolgen. Er bedarf auch nicht
ihrer Zustimmung. Hierbei handelt es sich nicht mehr um eine
echte Konfliktlösung, sondern ausschließlich um eine Schadensbegrenzung.
Gerade in großen OSS-Projekten lohnt sich deswegen der Einsatz
eines oder mehrerer dedizierter Community Manager, um die Kom-
88
6 Kommunikation
munikation zu koordinieren. Projekte, die Community Manager erfolgreich einsetzen, sind u.a. MySQL und Qt.272,273
FALLSTUDIE
Am Podcast Publishing System Podlove beteiligen sich viele verschiedene Personengruppen von Programmierern bis technikaffinen Podcastern. Das Projekt besteht neben dem PublishingWerkzeug aus einem Webplayer und mehreren Spezifikationen.
Eric Teubert erklärt, welche Kommunikationskanäle für Unterprojekte und verschiedene Kommunikationspartner verwendet
werden.
Je ein Trello Board (s. 5.5.4 M ANAGEMENT-SOFTWARE) dient zur
Kommunikation der Vision des Podlove Publishers und des
Webplayers nach außen. Auf GitHub (s. 5.5.2 H OSTING-DIENSTE FÜR
SOFTWAREPROJEKTE) werden Probleme und Aufgaben in Form von
Issues gesammelt. Leider bietet GitHub neben „Offen“ und
„Geschlossen“ keine weiteren Status für Issues wie „In Bearbeitung“ an. Der Kommunikationsaufwand ist hier deswegen manchmal größer als nötig. Über Twitter und App.net wird – teilweise
mit privaten Accounts – wichtiges Feedback gesammelt. Skype
dient durch seine Verbreitung als internes Chatsystem. Das
asynchrone Verhalten von E-Mails hatte für Teambesprechungen
nicht mehr ausgereicht. Über Mailinglisten werden aber noch
abstrakte Themen wie die Spezifikationen geklärt. Ein Blog dient
zur Verbreitung von Neuigkeiten und allgemeinen Projektinformationen. Über unregelmäßige Podcasts werden weitere
Informationen zum Projektstand diskutiert. 274,275,276,277
Eric Teubert rät als Kommunikationskonzept „etwas [zu wählen]
was für dich funktioniert“, weil man gerade zu Beginn häufig
alleine entwickelt und zu viele Gedanken über die Kommunikation
auch kontraproduktiv sein können.
272
274
vgl. http://podlove.org/, Stand: 25.08.2013
275
vgl. https://github.com/podlove/podlove-publisher/issues, Stand: 25.08.2013
276
vgl. https://trello.com/b/mFPdgi1P/podlove-web-player, Stand: 25.08.2013
277
vgl. https://trello.com/b/zB4mKQlD/podlove-publisher, Stand: 25.08.2013
273
89
6 Kommunikation
Obwohl es für ein OSS-Projekt eher ungewöhnlich ist, findet bei
Podlove ein großer Teil der Kommunikation auf deutsch statt, da
viele Projektmitglieder deutschsprachig sind und sich das Projekt
vermehrt an die deutsche Podcast Community richtet.
Fallstudie 10 – Podlove
6.10 ZUSAMMENFASSUNG
•
•
•
•
•
•
•
Es gibt asynchrone und synchrone Kommunikationskanäle.
Erstere eignen sich für lang- und letztere für kurzfristige und
dringende Absprachen.
Ein Großteil der internen Kommunikation findet öffentlich statt.
Die Dokumentation ist ein für Contributoren sehr wichtiger
Kommunikationskanal, dessen Erstellung mit viel Aufwand
verbunden ist.
Multiplikatoren eines bestimmten Ökosystems helfen bei der
Verbreitung der OSS.
Zur Verbesserung der Kommunikation und einer effektiveren
Entwicklung lohnt sich der Einsatz eines dedizierten Community
Managers.
Aufgabe des Community Managers sind die Koordination und
Qualitätssicherung der Informationen in den Kommunikationskanälen sowie das Erkennen und Abwenden von Konflikten.
Ziel der Kommunikation ist die Bildung einer hoch kohäsiven
Community.
90
7 Monetarisierung
7
MONETARISIERUNG
OSS wurde lange Zeit mit kostenloser Software (s. 3.2 FREIHEIT ODER
FREIBIER?) gleichgesetzt. Seit einigen Jahren wird jedoch deutlich,
dass OSS um komplette Geschäftsmodelle herum entwickelt werden
kann. Es gibt viele Gründe, warum man für OSS Geld verlangen
sollte. Neben dem Verdienen von Geld für den Lebensunterhalt der
Entwickler müssen für die Entwicklung benötigte Soft- und Hardware
finanziert werden. Ein weiterer Grund gilt dem Schaffen von Sicherheit und Seriosität: Software, welche Geld kostet, wird länger entwickelt und supported – so die Mutmaßung. Dies ist insbesondere im
B2B-Umfeld wichtig.
Die Möglichkeit einer Bezahlung der OSS z.B. in Form von Spenden
erweitert auch den Kreis der Contributoren. Eine Person, welche OSS
nutzt, aber weder Entwickler noch Grafiker ist und keinen Weg findet
sich am Projekt zu beteiligen, kann dies zumindest auf diese Weise
schaffen. Dies deckt sich mit der zuvor aufgestellten Definition: „Ein
Contributor ist eine Person, die etwas zu einem OSS-Projekt beiträgt.“ (s. 4.1.1 CONTRIBUTOR) Dieses Etwas kann auch Geld sein.
Welche Gründe auch zur Monetarisierung von OSS führen – kommerzielle OSS sind ein fester Bestandteil der Technikindustrie geworden.
Geschäftsmodelle, welche komplett auf der Entwicklung von OSS
aufbauen, nennt man Professional OSS, kurz POSS. Erfolgreiche
Vertreter der POSS-Bewegung sind MySQL und Red Hat.278,279,280
Im Folgenden seien Möglichkeiten der Monetarisierung von OSS genannt, die einzeln oder in Kombination verwendet werden können.
7.1
SOFTWARE
Obwohl der Quellcode frei zugänglich ist, kann OSS wie normale
Software verkauft werden.
Zwischen dem öffentlichen Quellcode und der verwendbaren
Software können beliebig viele und komplexe Schritte stattfinden.
Der Quellcode muss gefunden, aus dem VCS ausgecheckt und die
Software anschließend kompiliert werden. Für manche Nutzer einer
OSS sind dies zu viele Schritte, um sie selbstständig durchzuführen.
Für sie kann eine fertig kompilierte Software zum Kauf angeboten
werden. Obwohl es theoretisch für sie möglich ist ohne zusätzliche
Kosten die Software zu verwenden, willigen sie aus praktischen
278
vgl. http://wiki.pentaho.com/display/BEEKEEPER/1.+Why+Professional+Open+Source+Software, Stand:
31.07.2013
279
vgl. http://www.mysql.com/, Stand: 31.07.2013
280
vgl. http://www.redhat.com/, Stand: 31.07.2013
91
7 Monetarisierung
Gründen dem Kauf zu. Dieser dient letzten Endes lediglich als
Abkürzung.
Ein Beispiel für diesen Finanzierungsweg ist LiveReload, welches
sowohl im Mac App Store zum Kauf wie auch auf GitHub kostenlos
zum selbstständigen Kompilieren angeboten wird.281,282
7.2
SERVICES
Ein verbreiteter Monetarisierungsweg für OSS ist das Anbieten
zusätzlicher entgeltlicher Dienste, welche die OSS um ihre Funktionen erweitern oder sie in die Cloud auslagert. Die Software wird in
diesem Fall vom Entwickler der OSS auf seiner eigenen Infrastruktur
ausgeführt und gewartet, aber sie wird vom Kunden bedient. Dies
nennt man auch Software as a Service, kurz SaaS.
Die angebotenen Services können sehr unterschiedlich aussehen.
PhoneGap von Adobe stellt ein OSS-Framework dar, welches die
Entwicklung von Apps mittels Webtechnologien für unterschiedliche
Plattformen ermöglicht. Eines der dabei stattfindenden Entwicklungsschritte ist die Kompilierung der Apps, welche für viele verschiedene Plattformen entsprechend lang ausfällt und teilweise an
die Entwicklungsumgebung gebunden ist. Adobe bietet deswegen
den kommerziellen PhoneGap Build Service an, welcher diesen Kompilierungsschritt in die Cloud auslagert. So können alle Zielplattformen parallel kompiliert werden. Ein Entwickler unter Windows
kann somit auch iOS-Apps erstellen. 283
Ein weiteres Beispiel wäre die Cloud9 IDE. Sie wird quelloffen
entwickelt, aber ihre Benutzung findet über einen teilweise entgeltlichen Internetdienst direkt im Browser statt. Der Anwender erspart
sich somit die Installation, Wartung und zukünftige Aktualisierungen.284,285
7.3
SYNERGIEN
Eine schwer messbare und aufwendige Möglichkeit der Monetarisierung von OSS stellt das Aufbauen von Synergien zwischen verschiedenen Produkten einer Firma dar. Die OSS finanziert sich dabei nicht
selbst, sondern über andere Produkte der Firma, deren Verkauf sich
durch die Verbreitung der OSS steigert.
281
vgl. https://itunes.apple.com/us/app/livereload/id482898991?mt=12, Stand: 31.07.2013
vgl. https://github.com/livereload/LiveReload2, Stand: 31.07.2013
283
vgl. https://build.phonegap.com/, Stand: 31.07.2013
284
vgl. https://github.com/ajaxorg/cloud9, Stand: 31.07.2013
285
vgl. https://c9.io/, Stand: 31.07.2013
282
92
7 Monetarisierung
Eine Firma, die viel auf Synergieeffekte setzt, ist Google. Google
nahm 2012 50,2 Mrd. US$ ein. Davon stammen 43,7 Mrd. US$ allein
aus Werbeeinnahmen – hauptsächlich über das Internet. Es ist in
Googles Sinn möglichst vielen Menschen einen Zugang zum Internet
zu ermöglichen und sie an Google-Dienste zu binden, um die Verbreitung von Werbung über Google zu maximieren.286
Mit den OSS Chrome, Chrome OS und Android hat Google mehrere
Plattformen geschaffen, welche die Entwicklung von Webtechnologien fördern und den Zugang zum Internet erleichtern. Die enge
Verzahnung zwischen Google-Diensten und Android lässt sich bereits auf einem unveränderten Startbildschirm des Betriebssystems
erkennen: 287,288
Abbildung 11 – Android: Unveränderter Startbildschirm mit GoogleD i e n s t e n 289
Während sich die Google-spezifischen Apps manuell anordnen
lassen, ist ihre Deinstallation nicht immer möglich und auch die
Google-Suchleiste ist nicht ohne Softwareanpassungen entfernbar.
Ihre Benutzung führt automatisch zu einer Suchergebnisseite,
286
vgl. http://investor.google.com/financial/tables.html, Stand: 31.07.2013
vgl. http://www.chromium.org/, Stand: 31.07.2013
288
vgl. http://source.android.com/, Stand: 31.07.2013
289
vgl. http://www.digitaltrends.com/cell-phone-reviews/google-nexus-4-review/, Stand: 31.07.2013
287
93
7 Monetarisierung
welche wiederum Werbung enthält. Je höher die Verbreitung von
Android, desto höher die Einnahmen durch Werbung und somit die
Abhängigkeit zu anderen Google-Diensten.
7.4
HOSTING
Zu den häufigeren Monetarisierungsmöglichkeiten zählt das Anbieten einer Hosting-Lösung für eine OSS. Das Hosting von Software
ist häufig mit viel Aufwand und Erfahrung verbunden und stellt
damit gerade für Privatanwender eine große Hürde dar. Aus diesem
Grund bieten viele Firmen die Möglichkeit an ihre Software gegen
Bezahlung zu hosten. Da die Software quelloffen ist, steht es aber
jedem Nutzer frei, den Aufwand des Hostings selbst zu betreiben.
Ein Beispiel für diese Art der Monetarisierung sind WordPress und
Piwik.290,291
7.5
SUPPORT
Ebenfalls sehr verbreitet ist die Variante für OSS bezahlten Support
anzubieten. Dieser kann einzelne Bereiche wie das Aufsetzen, die
Wartung oder die Verwendung der Software enthalten oder sich an
Erreichbarkeiten und Verbindlichkeiten orientieren. So kann ein 24Stunden-Support teurer sein als ein zeitlich unverbindlicher Support. Ebenso kann der Kommunikationsweg per Telefon teurer sein
als per Mail, weil er direkter ist. Der Support ist insbesondere für die
Zielgruppe der Geschäftskunden wichtig, da diese aus finanziellen
Gründen möglichst zeitnah Hilfe benötigen.
Sencha, Entwickler mehrerer teilweise als OSS veröffentlichter JavaScript Frameworks, bietet einen mehrstufigen entgeltlichen Supportdienst an, welcher u.a. frühzeitigen Zugriff auf Bug-Fixes, CodeReviews und Telefonsupport beinhaltet.292
7.6
DUAL LICENSING
Unter Dual Licensing versteht man den Vorgang ein und dieselbe
Software sowohl unter einer open-source- als auch einer kommerziellen Lizenz zu vertreiben, wobei letztere durch ein Entgelt erworben werden können. Auf diese Weise können Firmen die OSS in
Kombination mit geschlossener Software verwenden.
290
vgl. https://signup.wordpress.com/signup/, Stand: 02.08.2013
vgl. http://piwik.org/hosting/, Stand: 02.08.2013
292
vgl. http://www.sencha.com/support/, Stand: 02.08.2013
291
94
7 Monetarisierung
Projekte, die auf Dual Licensing setzen, sind MySQL, Qt und Berkeley
DB.293,294,295
7.7
PREMIUM CONTENT
Premium Content in Form von Add-Ons, Plugins oder Themes stellen
eine weitere Finanzierungsmöglichkeit von OSS dar. Auf diese Weise
lässt sich der Funktionsumfang eines Produktes erweitern oder aber
personalisieren. Die Entwickler von WordPress bieten bspw. mit Akismet ein zusätzliches entgeltliches Plugin an, um Spam abzuwehren. 296
Eine OSS kann auch zusammen mit kommerziellen Erweiterungen als
komplett neue Distribution verkauft werden. So bietet Adobe ihre
open-source IDE Brackets ebenfalls unter dem Namen Edge Code CC
an, welche Teil einer kommerziellen Cloud Lösung ist.297
Der Mix von freien und entgeltlichen Inhalten wird als Freemium
bezeichnet, eine Zusammensetzung aus Free und Premium. Eine
andere Bezeichnung lautet open core software – eine Software, die
nur im Kern quelloffen ist. 298
7.8
BOUNTIES
Die meisten der bisher genannten Monetarisierungsmöglichkeiten
richten sich hauptsächlich an OSS-Projekte, die von Firmen betreut
werden. Eine neue Form der Finanzierung, welche auch in kleinen
OSS-Projekten gut angewandt werden kann, sind Bounties.299
Bounties sind finanzielle Entlohnungen für den Einbau einer konkreten Funktion oder dem Lösen eines konkreten Fehlers. Entwickler
haben keinen direkten Einfluss auf die Menge und Höhe an Bounties,
da sie von Mitgliedern der Community ausgeschrieben werden. Durch
die zusätzlich geringe Verbreitung können Bounties kaum als primäre Einnahmequelle verwendet werden.
Sie haben allerdings den Vorteil, dass sie für die Community eine
einfache Möglichkeit darstellen die Richtung eines Projekts zu
beeinflussen, ohne selbst an der OSS mitzuentwickeln.
293
vgl. http://www.mysql.com/about/legal/licensing/oem/, Stand: 02.08.2013
vgl. http://qt-project.org/products/licensing, Stand: 02.08.2013
295
vgl. http://www.oracle.com/technetwork/database/berkeleydb/downloads/licensing-098979.html, Stand:
02.08.2013
296
vgl. https://akismet.com/plans/, Stand: 02.08.2013
297
vgl. http://html.adobe.com/edge/code/, Stand: 02.08.2013
298
vgl. http://www.linuxinsider.com/story/66807.html, Stand: 07.08.2013
299
bounties (englisch „Belohnungen“)
294
95
7 Monetarisierung
Eine Plattform, die das Erstellen von Bounties ermöglicht, ist
BountySource. Sie integriert sich in bestehende Issue-TrackingSysteme wie GitHub oder Trac. Auf diesem Weg wird das Lösen eines
konkreten Tickets mit einer von der Community gespendeten Summe
entlohnt.300
7.9
DONATIONS
Eine Donation ist eine klassische Spende. Sie kann finanzieller, aber
auch sachlicher Natur sein. Für die Abwicklung finanzieller Spenden
gibt es mehrere technische Lösungen, welche z.B. über PayPal
realisiert werden. Es existieren auch komplette Plattformen, die
komplexe Abläufe wie das Spenden in Intervallen ermöglichen. Zu
ihnen zählen Flattr und GitTip. Auch Astro und Podlove nehmen
Spenden über Flattr an. 301,302,303,304,305,306
Spenden finden insbesondere bei eingetragenen Vereinen und
kleinen Entwicklergruppen, den Developer und User Communities (s.
5.1.1 ORGANISATIONSMODELLE NACH STÜRMER), statt. Ein prominentes
Beispiel ist die Mozilla Foundation, welche u.a. die Entwicklung des
Browsers Firefox betreut. Sie finanzieren sich hauptsächlich über
Spenden und versprechen durch ihre Arbeit im open-source Umfeld
die Erschaffung von Standards und der Bewahrung eines freien
Internets.307,308
7.10 FUNDING
Der Begriff des Fundings beschreibt wortwörtlich übersetzt jegliche
Art von Finanzierung eines Projekts. In der Regel wird unter Funding
jedoch speziell die Finanzierung zu Beginn einer neuen Projektphase
verstanden wie die Gründung eines neuen Unternehmens oder die
Entwicklung einer neuen Software. Das liegt daran, dass das Funding
vor allem als Vorfinanzierung eingesetzt wird, so lange sich das
Projekt noch nicht durch eigene Maßnahmen finanzieren kann. Es ist
jedoch nicht per se auf den Anfang einer Projektphase beschränkt.
Fundings können einen internen oder externen Ursprung besitzen.
Bei einem internen Ursprung werden sie z.B. über Ersparnisse der
300
vgl. https://www.bountysource.com/learn, Stand: 02.08.2013
302
vgl. https://www.paypal.com/de/cgi-bin/webscr?cmd=p/xcl/rec/donate-intro-outside, Stand: 02.08.2013
303
vgl. http://flattr.com/, Stand: 02.08.2013
304
vgl. https://www.gittip.com/, Stand: 02.08.2013
305
vgl. https://flattr.com/profile/Astro, Stand: 26.08.2013
306
vgl. http://flattr.com/thing/607995/Podlove, Stand: 26.08.2013
307
vgl. https://sendto.mozilla.org/page/contribute/join-mozilla?source=MozOrg-join, Stand: 05.08.2013
308
vgl. http://www.mozilla.org/de/about/manifesto/, Stand: 05.08.2013
301
96
7 Monetarisierung
Projektgründer aufgebracht. Fundings mit einem externen Ursprung
können in drei Formen unterschieden werden:
•
•
•
Funding durch Privatpersonen mit Crowdfunding
Funding durch Unternehmen mit Venture Capital
Funding durch den Staat und die öffentliche Hand mit Fördermitteln
7.10.1 CROWDFUNDING
Crowdfunding ist ein noch recht junger Begriff, welcher vor allem
durch die Plattform Kickstarter weltweit bekannt wurde. Er bezeichnet die Finanzierung durch möglichst viele Privatpersonen, die
sogenannte Crowd. Dieser Vorgang findet dezentral, vorrangig über
das Internet, statt. Ein realer Kontakt zwischen den privaten Investoren und den Projektinitiatoren ist dabei die Ausnahme.309
Crowdfunding ist aus vielerlei Hinsicht sehr attraktiv. Die Projektinitiatoren erhalten frühzeitig Feedback darüber, ob ihre Idee bei
den Nutzern ankommt. Sie haben dabei weitestgehend freie Hand
bei ihren Rahmenbedingungen und behalten zumeist die Hoheit
über ihr Projekt. Die geforderten Rückgaben an die privaten Investoren sind übersichtlich und bestehen häufig aus der Zurverfügungstellung des zu entwickelnden Produkts, Mitspracherecht bei Prototypen, Merchandising und bevorzugtem Support. Eine echte Gewinnausschüttung wie bei klassischen Investoren findet nicht statt.310
Der Prozess ist auch aus Sicht des Community Managements (s. 6.9)
interessant, da die frühe Beteiligung der Community am Projekt die
Bindung und die Gruppenkohäsion fördert. Die Community steuert
einen wesentlichen Beitrag zum Erfolg des Projekts bei und trägt
gesteigerte Erwartungen.
Nachteile sind, dass es unbekannte Projektinitiatoren schwer haben
private Investoren von ihrer Idee zu begeistern. Durch die begrenzten Finanzierungsmöglichkeiten von Privatpersonen gegenüber Firmen ist die Höhe des Fundings bei Crowdfunding häufig
kleiner als über das klassische Venture Capital. Außerdem reagieren
Privatpersonen häufig noch empfindlicher auf Projektverzögerungen
und -probleme als Unternehmen, da diese weniger Verständnis für
interne Vorgänge besitzen auf das fertige Produkt als Vergütung
warten anstatt auf den Erfolg des Projekts. Solche Diskrepanzen
entstehen, wenn Privatpersonen die Investitionen in ein Projekt mit
dem Kauf eines Produkts gleichsetzen. Dies führte bereits häufig zu
Konflikten innerhalb der Community. Das soziale Phänomen des
309
310
vgl. http://www.kickstarter.com/, Stand: 05.08.2013
vgl. http://www.kickstarter.com/help/school#creating_rewards, Stand: 05.08.2013
97
7 Monetarisierung
98
songenannten Shitstorms droht – der Super-GAU für jeden Community Manager, in welchem sich die Community lautstark, aggressiv
und ohne Vernunft gegen das Projekt wendet. 311,312
FALLSTUDIE
Eine durch Crowdfunding finanzierte OSS ist die Bloggingplattform Ghost.313
Aktuelle Bloggingplattformen fallen häufig in zwei Extreme:
entweder sind sie technisch einfach zu bedienen, aber funktional
sehr überladen wie WordPress oder aber sie sind funktional
leichtgewichtig, aber technisch komplex zu bedienen wie Octopress. Ghost soll das Beste aus beiden Welten sein: gut bedienbar,
leichtgewichtig und funktional. Mit dieser Konkurrenzanalyse
(s. 4.3) präsentierte das Ghost Team ihr Projekt auf Kickstarter.
Die Marketingkampagne setzte einen großen Fokus auf OSS. Ghost
nutzt intern viele OSS-Projekte und wird unter MIT License
veröffentlicht. Dies wird Vorteil gegenüber WordPress herausgestellt. Außerdem wird sich das Projekt als gemeinnütziger Verein
eintragen lassen, um die Unabhängigkeit des Projekts sicherzustellen. 314,315
Insgesamt wurden durch das Crowdfunding über 200.000 € zur
Erstfinanzierung gewonnen. Da Ghost später unter MIT Lizense
veröffentlich wird, setzt das zukünftige Finanzierungsmodell auf
einen Premium Hosting Dienst (s. 7.4).
Fallstudie 11 – Ghost
Auch Podlove wird teilweise durch Crowdfunding finanziert und
konnte auf diesem Weg bereits 6000 € einnehmen. 316
7.10.2 VENTURE CAPITAL
Venture Capital ist Kapital, welches von Beteiligungsgesellschaften
einem Unternehmen zur Verfügung gestellt wird. Beteiligungsgesellschaften können Einzelpersonen oder Firmen sein. Diese Fundingmethode wird verwendet, wenn klassische Kreditfinanzierungen
durch Sicherheitsbedenken nicht durchgeführt werden können. Es
wird deswegen auch Risikokapitel genannt. Risikokapitalgeber
refinanzieren ihre Investitionen, indem sie zu einem späteren
311
vgl. http://www.kickstarter.com/blog/kickstarter-is-not-a-store, Stand: 05.08.2013
vgl. http://money.cnn.com/2012/12/18/technology/innovation/kickstarter-ship-delay/index.html, Stand:
05.08.2013
313
vgl. http://tryghost.org/, Stand: 22.08.2013
314
vgl. http://www.kickstarter.com/projects/johnonolan/ghost-just-a-blogging-platform, Stand: 05.08.2013
315
vgl. http://octopress.org/, Stand: 22.08.2013
316
vgl. http://der-lautsprecher.de/ls011-podlove-publisher bei 6:22 Minuten, Stand: 05.08.2013
312
7 Monetarisierung
99
Zeitpunkt, wenn das Unternehmen profitabel ist, ihre Unternehmensanteile mit hoher Rendite verkaufen. Dies kann bei einem
Börsengang, einer Fremdübernahme durch ein anderes Unternehmen oder durch den Rückkauf der Anteile durch die zuvor
finanzierte Firma selbst stattfinden.317
Wie unter 4.2 ZIELE beschrieben, kann eines der Ziele von OSS das
Sichern eines wertvollen Nischenmarktes sein. Dies ist mit dem eingangs erwähnten Risiko verbunden, welches viel Gewinn verspricht,
aber klassische Kreditfinanzierungen nicht zulässt. Venture Capital
wird deswegen immer häufiger Bestandteil von OSS-Projekten. Der
Finanzierungsspielraum der Risikokapitalgeber ist häufig sehr groß.
So erhielt Puppet Labs, Entwickler einer open-source Automationslösung, 30 Mio. $ Venture Capital vom Unternehmen VMware. Ein
anderes Beispiel ist Meteor, ein quelloffenes Node.js Framework,
welches 11 Mio. $ durch mehrere Beteiligungsgesellschaften einnahm. Obwohl dies Einzelbeispiele sind, zeigen sie das wirtschaftliche Potenzial von OSS.318,319
7.10.3 FÖRDERMITTEL
Eine weitere Methode des Fundings sind Fördermittel aus öffentlicher Hand oder von privaten Stiftungen. Sie können direkt für die
Entwicklung von OSS oder allgemein für Existenzgründungen gelten.
Ein bekanntes Förderprogramm des Bundesministeriums für Wirtschaft und Technologie ist EXIST. Es richtet sich an alle Gründer in
Deutschland.
Manche Förderprogramme sind regional und thematisch beschränkt.
So trifft die Förderung durch das Programm BayTOU ausschließlich
für Neugründungen technologieorientierter Unternehmen in Bayern
zu. Ein weiteres Beispiel wäre das österreichische Förderprogramm
Netidee, welches ausschließlich für OSS gilt und die Beteiligung von
Schülern zulässt.320,321,322
317
vgl. Jungwirth, Wissensabhängige Strategiewahl in der Venture-Capital-Industrie, 2006, S. 5 f.
vgl. http://www.informationweek.com/cloud-computing/infrastructure/vmware-invests-30-million-in-puppetlabs/240146864, Stand: 06.08.2013
319
vgl. http://www.meteor.com/blog/2012/07/25/meteors-new-112-million-development-budget, Stand:
06.08.2013
320
vgl. http://www.exist.de/, Stand: 06.08.2013
321
vgl. http://www.startup-in-bayern.de/themenmenue/foerderung/zuschuesse/foerderungtechnologieorientierter-unternehmensgruendungen.html, Stand: 06.08.2013
322
vgl. http://derstandard.at/1375625792451/Netidee-Eine-Million-Euro-fuer-Internet-Geistesblitze, Stand:
06.08.2013
318
7 Monetarisierung
7.11 SPONSORING
Eine Art der Finanzierung, welche sich besonders für OSS-Projekt
ohne ein beteiligtes Unternehmen eignet, ist das Sponsoring. Das
Sponsoring bezeichnet das Aufbringen von Geld- oder Sachleistungen oder die Bereitstellung eigener Entwickler eines Unternehmens für ein Projekt. Der Sponsor erhält als Gegenwert eine
bessere Außenwirkung und Werbung. Teilweise kann er das Projekt
auch beeinflussen, sichert aber auf jeden Fall dessen Erhalt. Dies
kann für ihn zusätzlich von Vorteil sein, wenn er selbst Endbenutzer
des Projekts ist. Manchmal dient das Sponsoring auch einem Erfahrungsaustausch. 323,324
Für rAppid.js konnten Marcus Krejpowicz und Tony Findeisen auf die
Räumlichkeiten ihres Arbeitgebers Spreadshirt zurückgreifen. Im
Gegenzug erhielt Spreadshirt die Möglichkeit ein komplexes WebFramework für eigene Applikationen zu verwenden, dessen Autoren
in den eigenen Büroräumen sitzen.325
7.12 CONSULTING
Consulting bezeichnet eine tiefgreifende Beratung und ist eine
aktivere Form des Supports. Während der Support bereits bei einem
einzelnen Nutzer über einen kurzen Zeitraum und bei einem einzelnen Problem greift, richtet sich das Consulting zumeist an eine
Gruppe von Personen – einem Teil eines Unternehmens – und einer
Reihe von Problemen – innerhalb eines Entwicklungsprozess – über
einen längeren Zeitraum. Der Berater, also derjenige der das Consulting betreibt, begleitet die zu beratende Gruppe proaktiv und häufig
vor Ort im Unternehmen. So sollen Probleme nicht erst beim Auftreten behandelt, sondern im Vorfeld möglichst vermieden werden.
Ein wichtiger Bestandteil des Consultings ist die Schulung der
Mitarbeiter des Unternehmens zu einem Thema.326
Beim Consulting handelt es sich um einen ressourcenintensiven und
komplexen Supportprozess, welcher dementsprechend kostspielig
ist. Da die Entwickler einer OSS das größte Wissen über ihre eigene
Software besitzen, sind sie die erste Wahl um für die Software
Consulting zu betreiben. Die Autoren und wichtigsten Contributoren
einer OSS gründen deswegen nicht selten Consulting Agenturen, um
ihre Arbeit an der OSS zu finanzieren. Dies eignet sich jedoch meist
nur dann, wenn die OSS von Unternehmen und nicht ausschließlich
von Privatpersonen eingesetzt wird.
323
vgl. http://lwn.net/Articles/222773/, Stand: 06.08.2013
vgl. http://www.aoemedia.com/open-source-sponsoring.html, Stand: 06.08.2013
325
vgl. http://blog.spreadshirt.net/de/2013/08/13/meet-a-spreader-tony-und-marcus/, Stand: 26.08.2013
326
vgl. Weßel, Basiswissen Consulting, 2013, S. 20
324
100
7 Monetarisierung
Bekannte Consulting Agenturen für die OSS-Projekte Node.js und
CouchDB sind The Node Firm respektive The Couch Firm.327,328
FALLSTUDIE
Ziel des MSpec Frameworks ist die Vereinfachung von SoftwareTests. Als Maintainer des Projekts hat Alexander Groß viel Erfahrung im Bereich TDD gesammelt. Mit seinem Einsatz als
Sprecher der .NET User Group und auf anderen Konferenzen
konnte er sein Wissen an andere weitergeben und seine Bekanntheit als Experte in diesem Thema vor allem in der .NET Community
erhöhen.
Mittlerweile ist er mit der Consulting-Agentur GROSSWEBER
selbstständig. Seine Arbeit an MSpec sieht er definitiv als Wettbewerbsvorteil und Alleinstellungsmerkmal: „TDD-Schulungen von
jemandem der selbst ein TDD-Framework betreut.“ Seine langjährige Arbeit in diesem Bereich und seine Bekanntheit schaffen
Vertrauen.
Im Nachhinein ist es schwer zu sagen, wie sehr seine Tätigkeit im
OSS-Umfeld den Weg in seine Selbstständigkeit beeinflusst hat,
aber durch seine bereits vorhandene Reputation ist es definitiv
einfacher geworden.
Fallstudie 12 – MSpec
7.13 WERBUNG
Auch über Werbung können OSS-Projekte Geld generieren. Neben
der üblichen Bannerwerbung könnte dies z.B. durch Affiliate Links
erfolgen. Das sind Links, die Nutzer zu einem Shop führen und dabei
eine Provision zurückgeben, wenn der Nutzer dort einkauft.
Beworbene Produkte sollten natürlich mit der OSS in Verbindung
stehen und könnten bspw. Sachbücher zu diesem Thema sein.
Werbung kann auch Teil des Sponsorings sein. So tritt das Unternehmen Bocoup sowohl als Sponsor als auch als Verteiler für
Werbebanner bei dem OSS-Projekt Grunt auf.329
7.14 MERCHANDISING
Merchandising von OSS-Projekten kann eine gute zusätzliche Einnahmequelle sein. Dabei erfüllt Merchandising zusätzlich Ziele des
Marketings und Community Managements: Logos auf T-Shirts und
Tassen verbreiten die Reichweite des Projekts und auch die Kohäsion
327
vgl. http://thenodefirm.com/, Stand: 06.08.2013
vgl. http://thecouchfirm.com/, Stand: 06.08.2013
329
vgl. http://gruntjs.com/, Stand: 06.08.2013
328
101
7 Monetarisierung
der Gruppe verbessert sich, da Mitglieder der Community bereits
optisch erkannt werden können. Dabei wird das Merchandising meistens über einen Zwischenhändler vertrieben, der einen Teil des
Erlöses einnimmt oder aber als Sponsor auftritt. OSS-Projekte wie
Joomla, Piwik oder Icinga betreiben Merchandising. Es gibt auch
Onlineshops wie DevSwag, welche komplett darauf ausgerichtet sind
Fanartikel für OSS zu vertreiben und einen Teil der Einnahmen an die
Projekte zurückzugeben.330,331,332,333
7.15 MARKETING
Die Entwicklung und Veröffentlichung von OSS als Marketingkanal
generiert keine direkten Einkünfte, kann aber die Verbreitung
anderer Produkte oder Projekte eines Unternehmens fördern. Dieser
Effekt ist sehr ähnlich den Synergien (s. 7.3). Die einzelnen Projekte
stehen jedoch in keinem direkten Zusammenhang zueinander und
verursachen keine Wechselwirkungen. Bootstrap, das CSS-Framework von Twitter, steht bspw. in keinem direkten Zusammenhang mit
dem eigentlichen Onlinedienst. Die Beliebtheit des Frameworks
beeinflusst jedoch die Außenwirkung auf Entwickler positiv. Dadurch
sind sie möglicherweise eher geneigt einen Twitter Client zu entwickeln, welcher wiederum mehr Benutzer an die Plattform binden
könnte.
Auch einzelne Entwickler profitieren durch das Marketing, das OSS
verursacht. So wirkt sich die Beteiligung an OSS-Projekten positiv
auf das eigene Portfolio aus. Manche Unternehmen wie die Berliner
Agentur 6wunderkinder setzen bei einer Bewerbung sogar Erfahrung
und Einsatz in OSS-Projekten voraus! 334
Dies ist auch die Auffassung von Astro: „OSS hilft einem bei der
Jobsuche“ und kann so indirekt Gewinn erwirtschaften.
7.16 ZUSAMMENFASSUNG
•
•
330
Die Monetarisierung von OSS kann direkt für die Software
oder indirekt über andere Dienste oder Produkte erfolgen.
Manche Monetarisierungswege eignen sich für kleinere
Entwicklergruppen eher als für große von Unternehmen
geleitete OSS-Projekte und umgekehrt.
vgl. http://opensourcejoomla.spreadshirt.de/, Stand: 06.08.2013
vgl. http://www.ooshirts.com/piwik, Stand: 06.08.2013
332
vgl. https://www.icinga.org/merchandise/, Stand: 06.08.2013
333
vgl. http://devswag.com/, Stand: 06.08.2013
334
vgl. https://masterbranch.com/job/javascript-developer-6wunderkinder-berlin/1340, Stand: 06.08.2013
331
102
7 Monetarisierung
•
•
•
Die wirtschaftlich profitable Entwicklung von OSS hängt
stark vom Geschäftsmodell eines Unternehmens ab.
Entwickler und Endanwender sind stolz auf die Nutzung vom
OSS. Sie sind dazu bereit Finanz- und Sachspenden aufzubringen und Merchandising zu erwerben.
Die Entwicklung von OSS ermöglicht bessere Jobangebote.
103
8 Bewertung für Unternehmen
8
BEWERTUNG
FÜR
UNTERNEHMEN
Mit dem zuvor gesammelten Wissen lassen sich nun folgende unternehmensrelevanten Merkmale zum Management und zur Entwicklung
von OSS festhalten:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
OSS-Projekte besitzen neben Usern eine weitere Zielgruppe:
Contributoren.
OSS-Projekte können von Contributoren geforkt, verändert
und auch wieder zusammengefügt werden. Ihr Beitrag an der
OSS muss rechtlich geklärt werden.
Die Wahl der Lizenz ist wichtig und teilt sich in strenge und
freizügige Lizenzen.
Der Führungsstil kann autoritär, demokratisch oder meritokratisch orientiert sein.
An OSS-Projekten beteiligen sich Unternehmen, gemeinnützige Vereine und Privatpersonen gleichermaßen.
Die Managementfunktionen bei OSS-Projekten sind prinzipiell identisch zu Projekten mit geschlossener Software.
Die Motivation von Contributoren ist tendenziell höher als
die von Angestellten.
Das Entwicklungsmodell von OSS sollte agil sein.
Die technische Infrastruktur sollte sich an den Vorlieben der
Contributoren orientieren.
Gutes Kommunikationsmanagement ist wichtig und aufwendig, da Contributoren räumlich getrennt arbeiten und
unterschiedliche Erfahrungsstände und kulturelle Konventionen besitzen.
Die Community gibt frühzeitig Feedback über Projektentscheidungen.
OSS kann potentiell mehr Wissen kumulieren und so in
schnellerer Entwicklung und besserer Wartung resultieren.
Die hohe Reichweite von OSS ist gut für das Marketing und
verbessert die Außenwirkung.
Die Monetarisierungsmöglichkeiten reichen von kostenpflichtigem Support bis zu Spenden und ihre Eignung ist
sehr projektspezifisch.
Für Unternehmen ergeben sich daraus unterschiedliche Vor- und
Nachteile. Profit aus OSS zu schlagen ist schwer und der OSS-Weg
sollte nicht blind gegangen werden. Zuvor muss genau untersucht
werden, welche Probleme existieren und ob sie durch OSS gelöst
werden können. Dabei ist es wichtig zu beachten, dass OSS selten
die alleinige Lösung darstellt. Entscheidend ist ihr Zusammenspiel
mit anderen Bereichen des Unternehmens.
104
105
FALLSTUDIE
Um die Reichweite ihrer Plattform LiveCode zu verbessern startete
die Firma RunRev eine große Marketingkampagne, um die Umstellung auf eine open-source Lizenz anzukündigen. Dies war aber
nicht die einzige Maßnahme, die sie ergriffen haben. Die Marketingkampagne nutzten sie zusätzlich, um über Crowdfunding
neues Kapital zu generieren. Außerdem entwickelten sie ein
separates Lizenzmodell für kommerzielle Projekte, sodass ihr
Geschäftsmodell im Einklang zur neuen Lizenz stand. Das Resultat
sind über eine halbe Mio. € Einnahmen durch das Crowdfunding
und eine Erhöhung der Downloadzahlen um bis zu 1000%.335,336
Fallstudie 13 – LiveCode
Dieses Beispiel zeigt bereits, dass der gewinnbringende Einsatz von
OSS ein sehr komplexer Vorgang ist. Das Geschäftsmodell des Unternehmens und der Weg in die open-source Kultur müssen zueinander
passen. Außerdem muss der zusätzliche Aufwand, der bspw. durch
die Kommunikation entsteht, fest eingeplant werden. Ein schlecht
geführtes OSS-Projekt kann sonst sehr schnell kontraproduktiv
wirken und zu einer schädlichen Resonanz führen. Für Unternehmen,
die im OSS-Bereich unerfahren sind, ist es ratsam erst kleine Projekte zu veröffentlichen. Manche Untersuchungen besagen sogar,
dass große und komplexe Projekte tendenziell besser in geschlossenen Systemen gelöst werden können, da in diesen restriktiver über
einheitliche Standards entschieden werden kann.337,338
Trotz des Mehraufwandes bietet OSS zu viel Potenzial um sie zu
ignorieren. Die Entwicklung von OSS fördert gezwungenermaßen
den Einsatz guter, einfacher und moderner Standards. Wichtige
Konzepte der agilen Softwareentwicklung wie ausführliche Tests und
aktives und frühes Einsammeln von Nutzerfeedback entstehen auf
einem natürlichen Weg. OSS kann sowohl zur Abgrenzung zu bestehenden Konkurrenten verwendet werden, die weiterhin geschlossene Software entwickeln, aber auch zu Annäherungen führen. So
stehen AT&T, Canonical, HP, IBM , Cisco und viele anderen Unternehmen über die OpenStack Foundation in Verbindung.339
Nach Paul Graham wird die Qualität von proprietärer Software durch
zu viele Abhängigkeiten, Regeln und Grenzen beeinflusst. Allein das
335
vgl. http://www.kickstarter.com/projects/1755283828/open-source-edition-of-livecode, Stand: 08.08.2013
vgl. http://livecode.com/blog/2013/06/19/transitioning-to-being-an-open-source-company/, Stand:
08.08.2013
337
vgl. http://www.cmswire.com/cms/information-management/open-source-vs-proprietary-software-there-is-noclear-winner-021752.php, Stand: 08.08.2013
338
vgl. http://www.securityweek.com/size-matters-when-open-source-code-quality-better-proprietary-software,
Stand: 08.08.2013
339
vgl. http://www.openstack.org/foundation/companies/, Stand: 08.08.2013
336
OSS-Ökosystem unterliegt einem völlig darwinistischem Prinzip: die
beste Software setzt sich durch.340
Aber ist OSS wirklich die bessere Software?
340
vgl. http://paulgraham.com/opensource.html, Stand: 08.08.2013
106
9 Ausblick
9
107
AUSBLICK
In der Tat ist Qualität mittlerweile eines der wichtigsten Merkmale
von OSS. Die jährliche „Future of Open Source Survey“ von Black
Duck Software zeigt, dass Qualität der Hauptgrund für die Wahl von
OSS ist. So zeichnet sich OSS durch zahlreiche Features und einer
größeren Sicherheit aus. An zweiter Stelle steht die Vermeidung
eines Vendor-Lock-in-Effekts und an dritter Stelle die erhöhte
Flexibilität durch ein größeres Angebot an Software. Erst später
folgen geringere Kosten als Begründung. Da es demnach schwieriger
wird sich über die Qualität und den Preis der Software von der
Konkurrenz zu differenzieren, müssen neue Geschäftsmodelle mit
neuen USPs entworfen werden – wie z.B. das Anbieten des besten
Services. Der Wechsel zu OSS dient demnach nicht zuletzt der
Risikominderung. Einen Teil des eigenen Softwareportofolios als OSS
zu veröffentlichen verringert die Gefahr, durch die eigenen einseitigen Geschäftsmodelle von der Konkurrenz überrannt zu werden.
Auf der Gegenseite stehen laut der Umfrage Unerfahrenheit mit OSS,
komplexere Wartung und Lizenzbedenken als größte Hürden in die
OSS-Welt.
Ebenfalls untersucht wurde die Monetarisierung von OSS. So sind die
größten Einnahmequellen für OSS-orientierte Geschäftsmodelle besserer Support (s. 7.5) und zusätzliche Services (s. 7.2). 341,342
In welchem starken Wandel sich die Geschäftsmodelle von Softwarefirmen aktuell befinden illustriert das Beispiel des Traditionskonzerns Adobe. Das Unternehmen hat im Frühjahr 2013 angekündigt
ihre weitreichende Softwarepalette nicht mehr über ein Kauf-,
sondern nur noch ausschließlich über ein Mietmodell zu veräußern.
Für Adobe bedeutet dies ein stetiges Einkommen im Gegensatz zu
periodischen Einnahmen jeweils bei der Veröffentlichung einer
neuen Softwareversion. Das Preisschild und die Versionsnummer
einer Software werden nebensächlicher. Der Kunde erhält im Gegenzug ein stets aktuelles und in ständiger Entwicklung befindliches
Produkt. Dies korrespondiert durchaus mit Geschäftsmodellen von
OSS. 343,344
341
vgl. http://www.blackducksoftware.com/news/releases/seventh-annual-future-open-source-survey-resultsshow-culture-quality-and-growth, Stand: 08.08.2013
342
vgl. http://www.slideshare.net/blackducksoftware/the-2013-future-of-open-source-survey-results, Stand:
08.08.2013
343
vgl. http://www.adobe.com/cc/letter.html, Stand: 08.08.2013
344
vgl. http://thenextweb.com/insider/2013/05/06/after-nearly-10-years-adobe-abandons-its-creative-suiteentirely-to-focus-on-creative-cloud, Stand: 08.08.2013
9 Ausblick
108
Erfahrung in der Entwicklung von OSS zu sammeln, kann in Zukunft
die Expansion eines Unternehmens sichern. Innerhalb der Softwareentwicklung herrscht ein Fachkräftemangel. Dabei gibt es weltweit
viele aktive open-source Programmierer, die Erfahrung mit räumlich
getrennter Arbeit und internationaler Kommunikation haben. Unternehmen, die sich diesem Fachkräftemarkt verschließen, verzichten
womöglich auf wichtige Mitarbeiter. Dabei wird die sogenannte
Remote Work, Telearbeit bzw. das Home Office bei Arbeitnehmern
und -gebern immer beliebter. Laut dem Bundesverband Bitkom
arbeiten bereits 21% aller Berufstätigen in Deutschland ausschließlich von zu Hause.345,346,347
Aber auch beim Remote Working gilt: Es muss zum Geschäftsmodell
und der Unternehmenskultur passen. Die Vor- und Nachteile dieser
Arbeitsform werden zurzeit hitzig diskutiert. Während Yahoo im
Frühjahr 2013 Home Office für alle Angestellten verbot ging Microsoft den umgekehrten Weg und erlaubte es für alle. Welches Potenzial Remote Working birgt, zeigen Erfolgsgeschichten wie die von
MySQL. So können nicht nur neue Mitarbeiter weltweit gesucht
werden, auch bestehende Mitarbeiter werden nicht durch einen
Umzug verloren. Größter Pluspunkt könnte aber das 24/7-Supportmodell sein: Da die Entwickler von MySQL weltweit agieren, können
zu jeder Tageszeit Fragen entgegengenommen und Bugs gefixt
werden. Ohne Outsourcing wäre das nur möglich, wenn man in jeder
Zeitzone eine Niederlassung gründen würde… 348,349,350
Nicht zuletzt gilt OSS unter Entwicklern als sexy! Sowohl der
weltweit am meisten genutzte Browser als auch das verbreitetste
mobile Betriebssystem sowie die am häufigsten verwendete
Servertechnologie sind OSS. Der Einsatz und die Entwicklung von
OSS erhöht die Attraktivität des eigenen Unternehmens.351,352,353
Zuletzt sei zu erwähnen, dass ein weiterer Bereich der open-source
Kultur in den letzten Jahren extrem an Popularität gewonnen hat:
das Entwickeln von Hardware. Als Maker Movement wird die neue
345
vgl. http://www.arbeitsagentur.de/nn_27030/zentraler-Content/Pressemeldungen/2013/Presse-13-003.html,
Stand: 08.08.2013
346
vgl. http://davidfischer.github.io/gdc2/#languages/All, Stand: 08.08.2013
347
vgl. http://www.bitkom.org/de/presse/8477_75865.aspx, Stand: 08.08.2013
348
vgl. http://www.nytimes.com/2013/02/26/technology/yahoo-orders-home-workers-back-to-theoffice.html?hpw, Stand: 09.08.2013
349
vgl. http://www.faz.net/aktuell/wirtschaft/unternehmen/home-office-fuer-microsoft-darf-man-ueberallarbeiten-12317332.html, Stand: 09.08.2013
350
351
vgl. http://www.webpronews.com/chrome-overtakes-ie-as-the-worlds-most-used-browser-2012-05, Stand:
09.08.2013
352
vgl. http://techcrunch.com/2013/08/07/in-the-smartphone-wars-its-ios-vs-android-and-windows-phone-vsthe-rest/, Stand: 09.08.2013
353
vgl. http://news.netcraft.com/archives/2013/07/02/july-2013-web-server-survey.html, Stand: 09.08.2013
9 Ausblick
109
Begeisterung bezeichnet, unter der Privatpersonen Konzepte und
Ideen zum Bau von Hardware austauschen und diskutieren. Ausgelöst wurde diese Bewegung durch erheblich günstigere Verkaufspreise und einfachere Handhabung von 3D-Druckern und PhysicalComputing-Plattformen wie Arduino. Auch wenn sich diese Arbeit
auf Software bezogen hat, lassen sich alle beschriebenen Prinzipien
auf Hardware übertragen.354,355,356,357
In Zukunft werden Hardwarehersteller einen ähnlichen Wandel
durchlaufen wie er derzeit bei Softwareunternehmen stattfindet.
Von selbstgebauten WLAN Radios bis zu Möbeln aus dem 3D-Drucker:
viele Produkte, für die man früher in ein Geschäft gegangen wäre,
könnten in Zukunft mit einer Anleitung aus dem Internet selbstständig hergestellt werden.358,359
354
vgl. http://www.raisinggeeks.com/blog/maker-movement/, Stand: 09.08.2013
vgl. http://makezine.com/2013/06/03/why-the-maker-movement-is-here-to-stay/, Stand: 09.08.2013
356
vgl. http://www.nytimes.com/2010/09/14/technology/14print.html, Stand: 09.08.2013
357
vgl. http://www.arduino.cc/, Stand: 09.08.2013
358
vgl. http://www.instructables.com/id/Build-your-own-Wifi-radio/, Stand: 09.08.2013
359
vgl. http://www.nytimes.com/2013/06/20/technology/personaltech/home-3-d-printers-to-make-things-youneed-or-just-like.html, Stand: 09.08.2013
355
Anhang und Notizen
ANHANG
UND
NOTIZEN
Im Anhang befinden sich alle Gesprächsnotizen der Interviews. Die
Inhalte der Gespräche befinden sich in aufgearbeiteten Auszügen im
Fließtext des Hauptteils.
GESPRÄCHSNOTIZEN, ERIC TEUBERT, PODLOVE
Gespräch vom 16.04.2013 über Podlove und WordPress. Eric Teubert
ist Entwickler von Podlove und arbeitete bei der Agentur Inpsyde,
welche die deutsche WordPress-Community betreuen.
•
F r a g e : Stelle dich bitte kurz vor.
•
Inspyde seit zwei Jahre, PHP WordPress Entwickler, Informatik Masterstudent,
Masterarbeit Echtzeit Kollaboration (Netzwerkarchitektur), eigenes Open
Source Projekt Podlove Podcast Workflow, Hilft Podcasts zu erstellen,
persönlicher Kontakt zu Tim Pritlove Deutschlands bekanntesten Podcaster,
dadurch besondere Anforderungen um sich von anderen Podcast Open Source
Projekten abzusetzen, dient als Mentor/Marketing, plant Testphasen, Crowdfunding (bewusst gegen eine Crowdfunding-Plattform entschieden) und
Kommunikationskanäle, Crowddonation, kurzzeitig andere, im Gespräch mit
Instacast um Spezifikiationen zu Erwirken, immer noch alpha, 200 aktive
Nutzer, jetzt entsteht Dokumentation, Migrationshilfe für alte PodcastPlugins, Migrations-Assistent, immer wieder zurück zur Nutzerperspektive
(Wie ist der Workflow? Wie verwende ich als Podcaster das Plugin?), ein Hauptentwickler, sonst nur kleine Contributoren, öfter nein sagen bei Feature
Request, nicht den Nutzer fragen was sie gerne hätten, vor der Veröffentlichung Umfrage gemacht (Seit ihr mit Podcast-Plugins zufrieden? Ja, schon
generell…) aber als das neue Plugin kam waren alle begeistert weil die Nutzer
nicht wussten, was sie brauchten, nutzt Trello (aber die Projektgröße wird zu
groß), Podlove Subprojekte Publisher, Webplayer und Spezifikation (3
Projekte, 3 GitHub Repos)
•
Kommunikationskanäle:
•
Issues in GitHub: read/write, einfache Liste, es fehlen Status (in Bearbeitung,
Released) → es gibt nur Open/Closed und Labels
•
Features in Trello: read only, big picture, zwei Boards für Publisher/Webplayer
•
Twitter/App.Net: Feedback (teilweise auf privaten Accounts), wichtig!
•
Skype: als internen Chat (nur gewählt, weil es jeder hat), Mail reicht nicht, da
asynchron
•
Mailingliste: abstraktere Sicht, Software/Spezifikation (=geschlossen) (mit
zwei Meetings), weniger los
•
Podlove.org/Blog: nur Announcements
•
Podcasts: sehr unregelmäßig, Updates zum Stand
•
Kommunikationskanal: Wähle etwas was für dich funktioniert (weil man lange
alleine entwickelt), internes/externes Projektmanagementtool (soll ich mich
110
Anhang und Notizen
organisieren oder soll es etwas nach außen kommunizieren?), was nach
außen?
•
F r a g e : Ideale Größe für ein Softwareteam?
•
1: keine Diskussion, 2: man wird auf dem Boden der Tatsachen zurückgeholt,
3: Diskussion arten aus, wenn gleichberechtigt
•
von Anfang an als open-end geplant, aber Milestones zur Gliederung
•
early adopter sind wichtig! kamen von alleine
•
S t a r t z e i t p u n k t : unklar (kurze geschlossene Entwicklungszeit, baldige Veröffentlichung, man konnte es rudimentär benutzen)
•
V e r ö f f e n t l i c h u n g s g r u n d : so schnell wie möglich Feedback holen (aber
auch von Projekt zu Projekt unterschiedlich), Stand des Projektes muss
kommuniziert werden
•
L i z e n z : MIT
•
F r a g e : Seit wann und auf welche Art beteiligst du dich an open source
Projekten?
•
etwas Rails, Freund von Ruby
•
kleine Bugfixes in einem Ruby Gem, WordPress
•
F r a g e : Welche Faktoren spielen für dich eine Rolle, damit du dich dafür bzw.
dagegen entscheidest dich an einem open source Projekt zu beteiligen?
•
viele Tickets teilweise mit vielen Patches, die niemand merged
•
tausende offene Tickets
•
das Gefühl es passiert nicht viel
•
viele WordPress Features sind auf Wordpress.com ausgelegt (von Automatic),
aber nicht auf WordPress selbst als OSS-Projekt, Ticket-Fixing ans Marketing
gerichtet anstatt an Entwickler
•
F r a g e : Was sind die Stärken bzw. die Schwächen von WordPress (als CMS)?
•
globale Variablen als Problem
•
URL-Strukturen sind schwer zu ändern, unflexibel
•
best practices fehlen
•
Dokumentation ist schwierig (Codex) (hilft nur, wenn du weißt was du
brauchst, aber auch schon nicht mehr wenn du weißt was die Funktion macht)
•
Codex und In-Code Dokumentation deckt sich nicht
•
action/filtern: action ist ein filter, action ändert die Variablen nicht
•
F r a g e : Welche Tools, Werkzeuge, Plattformen und Kommunikationskanäle
verwendest du bei deiner Arbeit?
•
Terminal, Sublime Text, SVN/Git, viele Hilfsscripte, (Less, Sass Problem unter
Windows? Problem weil keine Best Practices), Dateistruktur
•
F r a g e : Wie zufrieden bist du mit WordPress' Plugin-System? Besitzt es
besondere Stärken oder Schwächen?
•
gibt kein Dependency Managament, Plugins dürfen sich nicht bedingen
•
Theme Features (simples dependency Management)
•
F r a g e : Verwendest du in deinen Projekten viele AJAX-Funktionalitäten oder
auch Echtzeit-Anwendungen? Wenn ja, in welchem Bereich? Wenn nein,
hättest du gerne welche verwendet?
•
Dropdown/Tabs dynamisch befüllen
•
Ajax ist einfach nicht wirklich vorgesehen
111
Anhang und Notizen
•
112
mobile first (was Datenübertragung angeht) ist nicht vorgesehen in WordPress
(Ajax)
GESPRÄCHSNOTIZEN, ALEXANDER GROß, MSPEC, .NET
USER GROUP, DEVELOPER OPEN SPACE
Gespräch vom 19.08.2013 über Machine.Specifications (MSpec), die
.NET User Group Leipzig und den Developer Open Space. Alexander
Groß ist Entwickler von MSpec und Mitorganisator der .NET User
Group Leipzig und des Developer Open Space . Er ist Consultant bei
und Mitbegründer von GROSSWEBER.
•
•
Alexander Groß, 33 Jahre, programmiert seit 12, seit 2007 professionell, seit
drei Jahren GROSSWEBER, als Software Entwickler/Berater, Begleitung von
Teams, Bsp. SCRUM/TTD, CI (TeamCity), ReSharper
•
F r a g e : Seit wann und warum entwickelst du open-source Software?
•
2005/2006: Blogging Engine "Das Blog"; das erste OSS-Projekt, Fluent
NHybernate ein paar Commits, kleine eigene Projekte
•
Mit welchen Tools arbeitest du?
•
ReSharper, IntelliJ (RubyMine), TeamServer
•
F r a g e : Stelle Machine.Specifications bitte kurz vor.
•
Aaron Jensen eigentlicher Autor, Seattle. .NET Entwickler, hat bei Rails RSpec
gesehen. (2007), deswegen MSpec für .NET entworfen, Alex 2008 mit Testing
beschäftigt, MSpec sehr natürlich sprachig (Context → Specification),
schneller lernbar
•
ReSharper: Testing, Refactoring für VisualStudio (auch OpenSource), Test
Runner von ReSharper hatte kein Mspec Support, erste Contribution: Repo
zuerst als SVN bei Assembler, dann zu Git bei GitHub, Git Repo geclonet und
ReSharper Support als erste Contribution
•
Contribution: Reporting, Navigation
•
Maintainer geworden als Jensen .NET verlassen hat, 2010/2011, Alex war zu
der Zeit der Hauptcontributor
•
Contribution meist klein, selten groß; behandeln meist Dokumentation,
Contributions über Pull Requests, Kontakt zur Community über Bug Meldungen
(GitHub Issues), Problem: Contributoren melden Bugs, die sie selbst fixen
könnten, wollen sich nicht beteiligen
•
alle 3 Monate 2 Pull Requests, CI Support um Tests durchzuführen, Alex: alle 2,
3 Wochen Updates
•
als Gegenleistung: Vorträge, Credibility für Testing (in .NET Community),
~70.000 mal heruntergeladen
•
Ziele: eigene Benutzung, Neugier, Spaß, lernen; heute: Consulting als TDD
Schulung
von
jemanden
der
auch
ein
TDD
Framework
betreut,
Wettbewerbsvorteil/Alleinstellungsmerkmal für Consulting
•
zum Gang in die Selbstständigkeit war die Credibility schon vorhanden
•
F r a g e : Welche Bedingungen stellst du an Contributions? (Tests, Code Style
Konventionen...?)
Anhang und Notizen
•
Code Style: wird durch ReSharper definiert, Problem: Intendation (.NET
meistens Tabs mit 4 Spaces Breite, aber Mspec hat 2 Spaces)
•
F r a g e : Welche Kommunikationskanäle benutzt ihr intern/extern? (GitHub
Issues, Trello, Twitter, Mailinglisten, Skype...?)
•
neu: Anthony Must... neuer Contributor der viel Doku macht; noch keine
großen Absprachen aber Skype/Google Talk Kontakt
•
StackOverflow als Support, Issues für Fehler
•
Mailingliste: für nichts... Changelogs
•
sonst: ein, zwei Personen von JetBRains (CitizenMap, Cropp...?), sie helfen
bei neuen Versionen von ReSharper
•
Sonstiges:
•
Lizenzen (MIT und MS-PL) vom ursprünglichen Autoren festgelegt
•
kein großes internes Management
•
noch kein Crowdfunding Gedanke für Refactoring (Refactoring wäre aufwendig)
•
aufsetzende Projekte: machine.fake
•
F r a g e : Stelle die .NET User Group und den Developer Open Space bitte kurz
vor.
•
.NET User Group: ursprünglicher Gründer Torsten Weber
•
Alex irgendwann dazugestoßen, immer noch dabei
•
ineta (internation NET community) organisiert Sprecher für User Group, 200€
für Reisekosten für Sprecher bezahlt von ineta/MicroSoft
•
Ort für Treffen wird von Firma gesponsert, ungefähr einmal im Monat Treffen
•
2007: .NET Summer Camp Konferenz für Studenten mit Sprechern organisiert
(insgesamt 2x durchgeführt)
•
F r a g e : Warum habt ihr euch für eine Unkonferenz ohne Teilnehmergebühren
entschieden?
•
Konferenz mit Sprechern zu organisieren ist schwer: Sprecher kontaktieren,
Agenda organisieren, Slots reservieren Notfallpläne
•
seit 2008: verlockend beim Open Space: die Leute, die da sind, machen ihr
Programm selbst, erstes Treffen: so 70 Leute, letztes Jahr 180
•
prinzipiell: morgens um 9 Treffen, etwas Organisation über Ablauf, dann
Themenfindung
•
Methode: WordCafe - abends treffen, 7 Leute an einem Tisch sprechen über
eine spezielle Technologie, erhalten Notizen; 8 Minuten lang diskutieren die
Personen untereinander, dann Wechseln die Personen den Tisch (2 bis 3 mal
gewechselt); vollgeschrieben Zettel als Input für den nächsten Tag
•
FishBowl als Diskussionsmethode
•
Gesetz der zwei Füße: kannst gehen, wenn dich etwas nicht interessiert (lieber
Gespräch auf dem Gang suchen, anstatt anderen Vortrag zu hören); Idee:
Konferenz nur aus Kaffeepausen, weil die den meisten Gespräche dort statt
finden
•
F r a g e : Wie hat sich das Event in den letzten Jahren verändert?
•
ursprünglich nur für .NET, jetzt allgemein
•
F r a g e : Welche Motivation haben deiner Meinung nach die Teilnehmer?
Netzwerken, Lernen...?
113
Anhang und Notizen
114
•
Motivation der Teilnehmer: 50:50 - lernen und netzwerken
•
F r a g e : Welche Motivation steckt für dich dahinter?
•
Motivation der Organisatoren: aus Spaß, aber natürlich auch netzwerken und
Credibility
•
Sonstiges
•
als Sprecher unterwegs (~2 Konferenzen im Jahr)
•
Finanzierung: vorwiegend Crowdfunding, einige Sponsoren, ein fünfstelliger
Betrag = plusminus Null
•
Gäste aus Österreich und Schweiz
E-MAIL-AUSZUG, ASTRO,
NODE-XMPP
Auszug der E-Mail vom 19.08.2013 über node-xmpp. Astro ist
Entwickler von node-xmpp und bereits lange als OSS-Entwickler
tätig.
•
•
Ich programmiere seit ich elf bin, da es mich reizt Maschinen tun zu lassen was
ich ihnen formuliere. Dazu benötigt man kein motorisches Geschick, sondern
nur logisches Denken. Mit 19 bin ich auf den C3D2 (lokaler Ableger des Chaos
Computer Clubs) gestoßen, wo ich seitdem sehr viel Zeit verbringe und viele
Freunde gefunden habe. Tatsächlich gehöre ich zu einigen wenigen, die dort
viele Generationswechsel mitgemacht haben. Mit der Hackerethik kann ich
mich sehr gut identifizieren. Die Wahl des Studiums war schon immer
sonnenklar für mich: Informatik. Da habe ich trotz aussercurriculärer Projekte
ein FH-Diplom erhalten. Ich bin jetzt 28. Meine Brötchen verdiene ich mit drei
Tagen/Woche Administration. Daneben halte ich das lokale Chaos mit am
laufen und versuche übers Jahr ein, zwei Projekte anzustoßen, damit sie
ähnlich populär werden wie node-xmpp. Mit Software drücke ich mich aus.
•
F r a g e : Seit wann und warum entwickelst du open-source Software?
•
Ich habe mit 14 begonnen Linux zu benutzen und die Offenheit sehr
geschätzt. Ohne wäre es wesentlich schwieriger gewesen Technologie zu
erlernen, zu beherrschen und zu verändern. Code online zu stellen habe ich
ungefähr mit 18 begonnen, später noch wesentlich mehr. Zum einen musste
ich als Programmierer genug Durchblick und Selbstvertrauen entwickeln, zum
anderen wurden mir die Gründe für Offenheit (s.u.) erst nach und nach klar.
•
F r a g e : An welchen Projekten hast du bereits gearbeitet?
•
Das habe ich nicht umfassend im Kopf. Ein kleiner Patch in linux-util sorgt
dafür, dass mein Name bei so ziemlich jedem installierten Linux auf Platte
liegt. Da war Fame die Motivation. :-) xmpp4r, collectd, ejabberd, node.js
connect, weil ich sie nutzte. Daneben einige Zusatzprojekte zu von mir
verwendeter Software: ruby-ixp als Client-Library für WMII, socksify-ruby für
Tor, remcached für memcached, mehrere Client-Implementationen für
collectd. Wenn persönliche Freunde Projekte haben, dann ist das auch
nochmal Motivation. Viele meiner Projekte sind Eigenenentwicklungen, denn
eigener Code stinkt am wenigsten (man kennt ihn am besten). Das ist nicht
Anhang und Notizen
besonders
positiv,
115
sondern
Not-invented-here.
Generell
sollte
jeder
Programmierer mehr Code von anderen lesen. Dabei kann man nur lernen.
•
F r a g e : Welche Technologien interessieren dich persönlich?
•
Rechnernetze, denn sie ermöglichen das zauberhafte Kommunizieren über
Distanzen.
Angefangen hat das mit IRC-Bots. Dann habe ich viele Spielsachen mit Jabber
gebaut und war ein paar Jahre in der XMPP Standards Foundation. Leider habe
ich mit der Zeit festgestellt, dass vielen Technologieexperten gar nichts an
Dezentralität und offenen Spezifikationen liegt; viel weniger interessiert sich
die breite Bevölkerung dafür.
Was noch übrig bleibt als offenes System im Internet ist File-Sharing. Deshalb
habe ich allmählich auf BitTorrent umgeschwenkt, auch wenn Auftragsarbeit
bei Instant Messaging wesentlich einfacher zu bekommen ist.
•
F r a g e : Mit welchen Tools arbeitest du?
•
git & Github. Letzteres ist zwar ein bedenkliches Monopol, hat jedoch die
Open Source-Entwicklung mit einigen Mechanismen erleichtert. Ausserdem
bleibt bei git die Datenportabilität gewahrt, was bei Github leider nur auf den
Code selbst zutrifft.
Statt einem File-Manager nutze ich zsh mit prezto. Klicken in GUIs lässt mich
schnell ermüden.
Als Editor nutze ich Emacs. Der ist wenig angepasst, da ich auch auf DefaultKonfigurationen zurecht kommen möchte.
Alle anderen Tools richten sich nach Programmiersprache und deren
Laufzeitumgebungen. Bei node sind das vor allem node.js selbst, und der
Paketmanager npm. Zum Testen wird mocha genutzt, das hatte mir wohl am
besten gefallen.
•
F r a g e : Warum hast du das node-xmpp als open-source Software veröffentlicht?
•
Ich bin da ziemlich fundamental: was will ich mit einem inflexiblen Binary
Blob? Dem kann ich nicht trauen, und der Autor steht seinen Nutzern keine
Freiheiten zu; im Sinne der GPL-Freiheiten. Ich bin ein starker Befürworter
Code nach ein paar Jahren mit Zwang zu veröffentlichen. Die Technologie ist
jung und wird ständig neu erfunden. Dabei häufen wir eine unglaubliche
Menge an technologischer Schuld an. Das wird einem bewusst wenn man hört
und sieht wie lange Systeme eigentlich eingesetzt werden, und was noch
immer an völlig obsoleter Technologie am laufen ist, in kritischen Systemen!
Mich wundert, wie das so viele andere ignorieren können. Mein Lieblingszitat
dafür finde ich leider nicht wieder. Ich glaube es war von Knuth. "Code wird
geschrieben um von Menschen gelesen, und nur nebenbei um von Maschinen
interpretiert zu werden." Es fehlt die Fragestellung nach der Motivation:
node.js war jung, und der große Vorteil daran ist, ist daß es ein Clean Slate
ist. Dementsprechend gab es nur wenige stümperhafte Versuche XMPP zu
implementieren. Hier sah ich die Gelegenheit einiges richtig zu machen und
habe angefangen alles zu implementieren was man für XMPP-Verbindungen
braucht, auf Basis eines schnellen Parsers (node-expat) und mit eigener
kleinen DOM-Implementierung (ltx). Entwickler die nicht so im Jabber-
Anhang und Notizen
116
Protokoll stecken war das natürlich zu technisch. Aber da kamen dann später
Abstraktionsbibliotheken die auf node-xmpp aufsetzen.
•
F r a g e : Welche Bedingungen stellst du an Contributions? (Tests, Code Style,
Konventionen...?)
•
Wenn ein Projekt so klein ist wie meine, dann freut man sich über
Contributoren.
Bedingungen
wären
da
sehr
hinderlich.
Code
Style
Konventionen kann ich selbst nachpflegen. Tests werden gern gesehen, aber
da bin ich selbst nicht sehr diszipliniert.
•
F r a g e : Wie organisiert sich das Projekt? (Demokratische Abstimmungen,
Vorgaben vom Autor, jeder trägt bei was er kann...?)
•
Ich bin der Benevolent Dictator. Jedem steht es frei zu forken.
•
Frage:
Hattet
ihr
Probleme
innerhalb
des
Projekts?
(Unnötige
Diskussionen, beleidigte Contributoren...?)
•
Bei node-expat (gehört quasi zu node-xmpp) gab es einen Pull Request mit
einem wenig benötigtem Feature, welches zu mehr Code und ein bisschen
mehr Speicherverbrauch geführt hätte. Der Submitter wollte das nicht so ganz
akzeptieren, aber naja: https://github.com/astro/node-expat/pull/13
•
F r a g e : Warum hast du dich ursprünglich für GPL entschieden und warum hast
du später auf MIT gewechselt?
•
Prinzipiell sind mir die Freiheiten wichtig. Mir ist der Unterschied zwischen
OSS und Freier Software bekannt. Allerdings sehe ich dass viele Beiträge aus
dem kommerziellen Bedarf stammen. Diese Leute winseln dann gleich rum: sie
suchten Code der etwas spezielles tut, fanden den bei mir, und können ihn
aufgrund ihrer Firmenrichtlinien nicht nutzen. Am Ende gebe ich den
Contributions mehr Gewicht als den Freiheiten, allerdings nur bei Libraries.
Wenn es fertig benutzbare Anwendungen sind, greife ich sehr gern zur GPL
oder auch mal zur AGPL. Entwickler aus dem kommerziellen Umfeld hassen
mich dafür. War es Auftragsarbeit, dann hat der Auftraggeber das Wort.
•
F r a g e : Welche Kommunikationskanäle benutzt ihr intern/extern? (GitHub
Issues, Trello, Twitter, Mailinglisten, Skype...?)
•
Github, Treffen auf Konferenzen. Wobei ich kommerzielle Konferenzen wegen
der Eintrittspreise ziemlich ätzend finde. Manchmal versuche ich kostenlos
oder als Speaker reinzukommen. Aber ich bin da Inkludist und mag eher
Community-Veranstaltungen,
insbesondere
den
Chaos
Communication
Congress.
•
F r a g e : Nutzt ihr Managementtools wie z.B. Trello?
•
Github
•
F r a g e : Nutzt ihr ein bestimmtes Entwicklungsmodell? (Wasserfallmodell,
Spiralenmodell, Scrum...?)
•
Feature-driven
•
F r a g e : Wie ist eure Dokumentation aufgebaut und was habt ihr alles
dokumentiert? (API, Beispiele, Installationsanleitung, Build Prozess...)
•
Eine Library ist für Programmierer. Die sollten den Code auch lesen können,
was auch gleich für potentielle Contributoren sorgt. Ein guter Einstieg ist
dafür sehr wichtig. Deshalb habe ich die Grobstruktur in der README
Anhang und Notizen
117
festgehalten, welche auch auf der Projekt-Homepage auf Github angezeigt
wird. Daneben gibt es Beispiel-Code für die häufigsten Anwendungsfälle.
•
F r a g e : Welche Tools nutzt ihr und warum? (Warum GitHub, warum Travis,
etc.)
•
Github: s.o.
•
Travis: weil es sehr einfach für node.js-Projekte auf Github war. Ich denke
aber, die zwei Sekunden zum Testen sollte man auch vor dem Commit noch
haben.
•
F r a g e : Warum hast du deine Rolle als Project Lead abgegeben? Wie lief diese
Umstellung ab?
•
Persönliches Desinteresse (s.o.). Ich habe die Entwicklung schleifen lassen,
was gar nicht gut war und mir auch zu der Zeit ein schlechtes Gewissen
gemacht hat. Die Bug Reports haben sich getürmt, und mir fehlte auch der
Überblick jemanden als Maintainer zu ernennen. Bei node.js selbst hatte sich
auch einiges geändert (Streams2), was ich wenig verfolgt hatte. Da konnte ich
also gar nicht helfen. Dann habe ich mit Lloyd Watkin jemanden entdeckt, der
viel damit anstellt. Ihn habe ich dann auf der RealtimeconfEU persönlich
gefragt,
ob
er
das
Projekt
und
die
dazugehörigen
(ltx,
node-
{expat,stringprep}) übernehmen möchte. Das bot sich zu der Zeit an, sonst
hätte ich ihm eine Mail geschrieben. Es tut durchaus weh keine Zeit und kein
Interesse mehr zu finden für ein nettes Projekt was auch mal Nutzer hat.
Natürlich sorge ich mich um Codequalität und Integrität, aber so diszipliniert
bin ich nun wieder selbst auch nicht.
•
F r a g e : Übernimmst du noch Aufgaben für das Projekt?
•
Nur Administrativa, wie Push-Berechtigungen auf Github & npm dem neuen
Maintainer einzuräumen.
•
F r a g e : Gibt es eine spannende Anekdote aus diesem oder einem anderen OSSProjekt, die du erzählen möchtest?
•
Lob fühlt sich immer gut an, deshalb sollte man damit auch nicht sparen.
Wenn man länger mit jemandem zusammen gearbeitet hat, dann ist die
öffentliche Lobpreisung dessen Natur nochmal etwas besonders schönes. Oder
wenn man jemanden kennenlernt, und einem erstmal für Code gedankt wird.
Wobei ich mir vorstellen kann, dass sich das nicht nur auf Code beschränkt,
aber das ist eben was ich im Internet mache. Es stimmt mich traurig dass
prominente Vertreter (Torvalds, de Raadt) ihren respektlosen Umgang mit
intelligenten Menschen zu Schau stellen. Menschen machen Fehler. Es ist
noch kein Meister vom Himmel gefallen.
•
F r a g e : Wurdest du bereits für deine Arbeit an OSS entlohnt? (z.B. in Form von
Spenden?)
•
https://flattr.com/profile/Astro
•
Bitlove.org läuft seit Juni 2012 und an die 900 Euro dafür flattred bekommen.
Zwei Mal auch Direktüberweisungen; allerdings ist der Dienst nicht wirklich
verwendbarer Code.
•
Das war Auftragsarbeit für einen ehemaligen, OSS-freundlichen Arbeitgeber:
https://github.com/astro/node-collectdout, sowas gibt es gelegentlich im
Internet, aber Normalität ist es leider nicht. Ich vermute daß Copyleft-
Anhang und Notizen
118
Lizenzen da helfen könnten. Und noch Big news: OSS hilft einem bei der
Jobsuche.
GESPRÄCHSNOTIZEN, MARCUS
FINDEISEN, RAPPID.JS
KREJPOWICZ
UND
TONY
Gespräch vom 22.08.2013 über rAppid.js. Marcus Krejpowicz und
Tony Findeisen sind Entwickler von rAppid.js und arbeiten bei
Spreadshirt, welche das Framework auch intern nutzen.
•
F r a g e : Stellt euch bitte kurz vor.
•
Tony Findeisen, in BA Leipzig Informatik studiert, Ausbildung zum
Softwaretechnologen, 26 Jahre, 7. Klasse Taschenrechner Programmierung,
VB6 angefangen (ActiveX Controls), auch Usability interessiert, auch ASP.NET,
Flex (deswegen Inspiration XAML bei rAppid.js)
•
Marcus, TU Dresden Medieninformatik, in der 9. Klasse Programmierung,
vorher HTML/CSS + PhotoShop, dann Webanwendungen, erst mit CakePHP
•
F r a g e : An welchen Projekten habt ihr bereits gearbeitet?
•
backbone-ui, flow.js (Kontrollfluss, TDD entwickelt, Server + Client), inherit.js
(Typisierung und Vererbung)
•
Frage: Welche Technologien interessieren euch persönlich?
•
JavaScript, Node.js, (AS3 als Sprache), MongoDB
•
F r a g e : Stellt rAppid.js bitte kurz vor.
•
Web-Framework für Echtzeit Webapplikationen
•
deklarative Views mit XAML
•
RequireJS, Underscore, Moment.js → nur Libraries die 100%ig den Anforderungen erfüllen, sonst selbst schreiben
•
Konzepte: TDD, Modulare Komponenten,
•
ab IE7 zuverlässig
•
für großskalierte Applikationen
•
rAppid.js Doc Command: generiert Schema, etc.
•
F r a g e : Wie arbeitet ihr zusammen als zwei Project Leads?
•
Probleme → an Whiteboard durchgesprochen → dann Programmierung
•
Features abarbeiten, Inspiration: Flex
•
F r a g e : Welche Bedingungen stellt ihr an Contributions? (Tests, Code Style
Konventionen...?)
•
bisher keine Contributions, noch keine Contributing Richtlinien vorhanden
•
derzeit kein aktives verfolgtes Ziel, da Entwicklung zu zweit gut läuft
•
trotz Blogposts, Social Media, etc., bisher kaum Feedback
•
Ausnahme Veranstaltungen: auf Berlin.JS und apps.berlin.js gutes Feedback
bekommen, bei Open IT 2x vorgestellt (von Spreadshirt gehostet)
•
Artikel auf DailyJS (aktiv angeschrieben) und dotnetpro (nicht aktiv
angeschrieben)
•
rAppid.js vor allem für einen selbst geschrieben, man steht 100%ig dahinter
•
F r a g e : Warum habt ihr euch für die MIT License entschieden?
•
zuerst CC BY, dann Überlegung GPL oder MIT → GPL wäre Problem für
Spreadshirt gewesen
Anhang und Notizen
•
Welche Kommunikationskanäle benutzt ihr intern/extern? (GitHub Issues,
Trello, Twitter, Mailinglisten, Skype...?)
•
Twitter, GitHub, Seite + Blog, E-Mail
•
F r a g e : Welche Tools nutzt ihr?
•
Asana mit ToDo-Listen, TDD (Unit Tests mit Mocha, Komponententests,
WebDriver Tests), Travis CI, GitHub, SourceLabs, IntelliJ, Chrome als
Debugging Tool, nginxNutzt ihr ein bestimmtes Entwicklungsmodell?
(Wasserfallmodell, Spiralenmodell, Scrum...?)
•
nicht speziell Scrum, aber agil-artige Entwicklung
•
F r a g e : Welche Rolle spielt Spreadshirt für das Projekt?
•
Spielraum gestellt (Zeit, Räumlichkeiten, etc.) zur freien Entwicklung und
Entscheidung
•
private Entwicklung des Frameworks
•
schnellere Entwicklung möglich, dankbar angenommen
•
Spreadshirt: Nährboden für Idee, Inspiration durch andere Mitarbeiter, echter
Anwendungsfall
•
F r a g e : Zukunftspläne?
•
in die Appentwicklung gehen mit Software as a Service
•
rAppid.js weiter ausreizen, schnelle neue Iterartionen
•
attraktiver gestalten: leichterer Einstieg, besseres Design + Logos, etc.
119
Literaturverzeichnis
LITERATURVERZEICHNIS
Abelson, Harold; Sussman, Gerald Jay; Structure and Interpretation of Computer
Programs, http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html, Stand:
23.08.2013
Adler, Charles: Kickstarter Is Not a Store,
http://www.kickstarter.com/blog/kickstarter-is-not-a-store, Stand: 05.08.2013
Adlin, Tamara; Pruitt, John: The Essential Persona Lifecycle, Morgan Kaufmann,
2010, 1. Auflage
Alman, Ben: Introducing Grunt, http://weblog.bocoup.com/introducing-grunt/,
Stand: 16.08.2013
Alman, Ben: Help us write documentation for 0.4!,
https://github.com/gruntjs/grunt/issues/549, Stand: 16.08.2013
Alman, Ben: final 0.4.0 checklist, https://github.com/gruntjs/grunt/issues/663,
Stand: 16.08.2013
Atwood, Jeff: Pick A License, Any License,
http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html,
Stand: 02.09.2013
Babcock, Charles: VMware Invests $30 Million In Puppet Labs,
http://www.informationweek.com/cloud-computing/infrastructure/vmwareinvests-30-million-in-puppet-labs/240146864, Stand: 06.08.2013
Backaitis, Virginia: Open Source vs. Proprietary Software: There is No Clear Winner,
http://www.cmswire.com/cms/information-management/open-source-vsproprietary-software-there-is-no-clear-winner-021752.php, Stand: 08.08.2013
Bartholomew, Daniel: MariaDB vs. MySQL, http://www.adminmagazine.com/Articles/MariaDB-vs.-MySQL, Stand: 02.07.2013
Bazon, Mihai: UglifiyJS, http://lisperator.net/uglifyjs/, Stand: 17.05.2013
Beck, Kent; u.a.: Manifest für Agile Softwareentwicklung,
http://agilemanifesto.org/iso/de/, Stand: 09.07.2013
Beck, Kent; u.a.: Prinzipien hinter dem Agilen Manifest,
http://agilemanifesto.org/iso/de/principles.html, Stand: 09.07.2013
Bradford, K. T.: GOOGLE NEXUS 4 REVIEW, http://www.digitaltrends.com/cellphone-reviews/google-nexus-4-review/, Stand: 31.07.2013
Brors, Dieter: The Document Foundation tritt OASIS bei,
http://www.heise.de/open/meldung/The-Document-Foundation-tritt-OASIS-bei1698800.html, Stand: 13.08.2013
Chacon, Scott: Book, http://git-scm.com/book/de, Stand: 22.07.2013
Corbet, Jonathan: Who wrote 2.6.20?, http://lwn.net/Articles/222773/, Stand:
06.08.2013
Dahl, Ryan: Original Node.js presentation,
http://www.youtube.com/watch?v=ztspvPYybIY, Stand: 25.06.2013
DeBergalis, Matt: MIT license, HTTP request package, Made With Meteor,
http://www.meteor.com/blog/2012/04/20/mit-license-http-request-packagemade-with-meteor, Stand: 22.08.2013
Denmead, Ken: Why the Maker Movement is Here to Stay,
http://makezine.com/2013/06/03/why-the-maker-movement-is-here-to-stay/,
Stand: 09.08.2013
Dixon, James: 1. Why Professional Open Source Software,
http://wiki.pentaho.com/display/BEEKEEPER/1.+Why+Professional+Open+Source+
Software, Stand: 31.07.2013
120
Enaux, Claudius; Weh, Saskia-Maria: Konfliktmanagement: Konflikte kompetent
erkennen und lösen, Haufe-Lexware, 2008. 4. Auflage
Findeisen, Tony: Article about rAppid:js in dotnetpro magazine,
http://blog.rappidjs.com/2013/08/article-about-rappidjs-in-dotnetpro.html,
Stand: 26.08.2013
Finley, Klint: Github Has Surpassed Sourceforge and Google Code in Popularity,
http://readwrite.com/2011/06/02/github-has-passed-sourceforge, Stand:
11.07.2013
Fischer, David: Open source contributions by location,
http://davidfischer.github.io/gdc2/#languages/All, Stand: 08.08.2013
Fitzpatrick, Jason: Best Distraction-Free Writing Application?,
http://lifehacker.com/5687616/best-distraction+free-writing-application, Stand:
15.07.2013
Fogel, Karl: Producing Open Source Software, O’Reilly Media, 2005, 1. Auflage
Förtsch, Gabi; Meinholz, Heinz: Führungskraft Ingenieur, Vieweg+Teubner Verlag,
2010, 1. Auflage
Fowler, Martin: OnsiteCustomer,
http://martinfowler.com/bliki/OnsiteCustomer.html, Stand: 09.07.2013
Germain, Jack: Open Core Debate: The Battle for a Business Model,
http://www.linuxinsider.com/story/66807.html, Stand: 07.08.2013
Gloger, Boris: Scrum, Carl Hanser Verlag, 2013, 4. Auflage
Graham, Paul: What businesses can learn from open souce,
http://paulgraham.com/opensource.html, Stand: 08.08.2013
Griffith, Tommy: The 2013 SEO Checklist, http://www.clickminded.com/seochecklist/, Stand: 16.07.2013
Gruber, John: Markdown, http://daringfireball.net/projects/markdown/, Stand:
15.07.2013
Ihlenfeld, Jens: Oracle überträgt Openoffice an die ASF,
http://www.golem.de/1106/83918.html, Stand: 12.06.2013
Ivanov, Anton: JavaScript and Friends: CoffeeScript, Dart and TypeScript,
http://smthngsmwhr.wordpress.com/2013/02/25/javascript-and-friendscoffeescript-dart-and-typescript/, Stand: 28.06.2013
„janw“: Build your own Wifi radio, http://www.instructables.com/id/Build-yourown-Wifi-radio/, Stand: 09.08.2013
Jeffries, Ron; Lindstrom, Lowell: Extreme Programming and Agile Software
Development Methodologies,
http://www.oobeyagroup.com/images/ExtremeProgrammingAgileSoftwareDevelop
mentLindstromJeffries.pdf, Stand: 09.07.2013
Jost, Peter: Organisation und Motivation, Gabler Verlag, 2008, 2. Auflage
Jungwirth, Carola: Wissensabhängige Strategiewahl in der Venture-CapitalIndustrie, Deutscher Universitätsverlag, 2006, 1. Auflage
Kamp, Poul-Henning: Why Should I Care What Color the Bikeshed Is?,
http://bikeshed.com/, Stand: 25.07.2013
Kellen, Tyler: Docs for 0.4, https://github.com/gruntjs/grunt/issues/480, Stand:
16.08.2013
Kellen, Tyler: Tearing Grunt Apart, http://weblog.bocoup.com/tearing-gruntapart/, Stand: 16.08.2013
Koch, Jochen; Schreyögg, Georg: Grundlagen des Managements, Gabler Verlag,
2010, 2. Auflage
121
Knop, Carsten: Für Microsoft darf man überall arbeiten,
http://www.faz.net/aktuell/wirtschaft/unternehmen/home-office-fuer-microsoftdarf-man-ueberall-arbeiten-12317332.html, Stand: 09.08.2013
Kulbe, Anette: Grundwissen Psychologie, Soziologie und Pädagogik, Kohlhammer,
2009, 2. Auflage
Lassus, Olov: Meteor meets NoGPL, http://blog.lassus.se/2012/04/meteor-meetsnogpl.html, Stand: 22.08.2013
Lehman, Adam: OUR DEVELOPMENT PROCESS,
http://dev.brackets.io/preso/contribute/#/16, Stand: 10.07.2013
Lehman, Adam: Kommentar zu Brackets Review,
http://creativejs.com/2012/05/brackets-review/#comment-1901, Stand:
21.08.2013
Lehman, Adam: Google+ Post,
https://plus.google.com/113743469825932014075/posts/cSVyhkcrp8L, Stand:
21.08.2013
Leutwyler, Markus: How to get rich (quick) with JS,
http://www.youtube.com/watch?v=bStff9X0oYI&t=5m22s, Stand: 17.05.2013
Linares, Lean; u.a.: HOW TO KEEP UP TO DATE ON FRONT-END TECHNOLOGIES,
http://uptodate.frontendrescue.org/, Stand: 22.07.2013
McAllister, Neil: Study: Most projects on GitHub not open source licensed,
http://www.theregister.co.uk/2013/04/18/github_licensing_study/, Stand:
26.06.2013
McCaffrey, James: Agile Programming vs. Extreme Programming,
http://jamesmccaffrey.wordpress.com/2006/04/11/agile-programming-vsextreme-programming/, Stand: 10.07.2013
Miller, Claire Cain; Rampell, Catherine: Yahoo Orders Home Workers Back to the
Office, http://www.nytimes.com/2013/02/26/technology/yahoo-orders-homeworkers-back-to-the-office.html?hpw, Stand: 09.08.2013
Miller, Kevin: Transitioning to Being an Open Source Company,
http://livecode.com/blog/2013/06/19/transitioning-to-being-an-open-sourcecompany/, Stand: 08.08.2013
Moelgaard, Peter: THE BRACKETS TEAM… USING TRELLO,
http://blog.petermolgaard.com/2012/05/03/adobe-brackets-team-using-trello/,
Stand: 10.07.2013
„mrd“: Meet a Spreader: Tony und Marcus,
http://blog.spreadshirt.net/de/2013/08/13/meet-a-spreader-tony-und-marcus/,
Stand: 26.08.2013
Nalley, David: Leadership in open source communities,
http://opensource.com/business/11/2/leadership-open-source-communities,
Stand: 01.07.2013
Naumann, Stephan: XING versus LinkedIn – Fakten zu den Karriere-Netzwerken,
http://peopleandmedia.wordpress.com/2012/02/04/xing-versus-linkedin-faktenzu-den-karriere-netzwerken/, Stand: 22.07.2013
Neumann, Alexander: GitHub populärer als SourceForge und Google Code,
http://www.heise.de/developer/meldung/GitHub-populaerer-als-SourceForgeund-Google-Code-1255416.html, Stand: 11.07.2013
Noguchi, Brian; Smith, Nate: Our take on Derby vs. Meteor,
http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/, Stand:
13.06.2013
o.A.: Willkommen Wunderlist, http://www.6wunderkinder.com/wunderlist, Stand:
15.07.2013
o.A.: Adium, https://www.adium.im/, Stand: 22.07.2013
122
o.A.: Creative Cloud and the future of the creative process.,
http://www.adobe.com/cc/letter.html, Stand: 08.08.2013
o.A.: Adobe Edge Code CC (Preview) Code the web.,
http://html.adobe.com/edge/code/, Stand: 02.08.2013
o.A.: Akismet API key signup, https://akismet.com/plans/, Stand: 02.08.2013
o.A.: Welcome to the Android Open Source Project!, http://source.android.com/,
Stand: 31.07.2013
o.A.: Project Roles, http://source.android.com/source/roles.html, Stand:
26.06.2013
o.A.: We back Open Source entirely!, http://www.aoemedia.com/open-sourcesponsoring.html, Stand: 06.08.2013
o.A.: How the ASF works, http://www.apache.org/foundation/how-it-works.html,
Stand: 26.06.2013
o.A.: Welcome Apache Ant, http://ant.apache.org/, Stand: 15.07.2013
o.A.: FaceTime für den Mac, http://www.apple.com/de/mac/facetime/, Stand:
22.07.2013
o.A.: LiveReload,
https://itunes.apple.com/us/app/livereload/id482898991?mt=12, Stand:
31.07.2013
o.A.: Fachkräfteengpässe verstärken sich – das zeigt die aktuelle BA-Analyse,
http://www.arbeitsagentur.de/nn_27030/zentralerContent/Pressemeldungen/2013/Presse-13-003.html, Stand: 08.08.2013
o.A.: Arduino, http://www.arduino.cc/, Stand: 09.08.2013
o.A.: Do great things, https://asana.com/, Stand: 26.08.2013
o.A.: Confluence, http://www.atlassian.com/de/software/confluence/, Stand:
15.07.2013
o.A.: Greenhopper, http://www.atlassian.com/de/software/greenhopper, Stand:
15.07.2013
o.A.: Jira, http://www.atlassian.com/de/software/jira, Stand: 12.07.2013
o.A.: What is a Barcamp?, http://www.barcampsaigon.org/info/, Stand:
23.07.2013
o.A.: ZenWriter, http://www.beenokle.com/zenwriter.html, Stand: 24.07.2013
o.A.: Bitbucket, https://bitbucket.org/, Stand: 11.07.2013
o.A.: Fast ein Drittel aller Berufstätigen rund um die Uhr erreichbar,
http://www.bitkom.org/de/presse/8477_75865.aspx, Stand: 08.08.2013
o.A.: Seventh Annual Future of Open Source Survey Results Show Culture, Quality
and Growth Driving an Open Revolution,
http://www.blackducksoftware.com/news/releases/seventh-annual-future-opensource-survey-results-show-culture-quality-and-growth, Stand: 08.08.2013
o.A.: Bountysource, https://www.bountysource.com/learn, Stand: 02.08.2013
o.A.: Brackets, http://brackets.io/, Stand: 21.08.2013
o.A.: nvALT, http://brettterpstra.com/projects/nvalt/, Stand: 15.07.2013
o.A.: Bugzilla, http://www.bugzilla.org/, Stand: 12.07.2013
o.A.: Byword 2, http://bywordapp.com/, Stand: 15.07.2013
o.A.: Cloud9 IDE, https://c9.io/, Stand: 31.07.2013
o.A.: Team collaboration with real time chat., http://campfirenow.com/, Stand:
22.07.2013
123
o.A.: Choosing an OSS license doesn’t need to be scary,
http://choosealicense.com/, Stand: 16.07.2013
o.A.: The Chromium Projects, http://www.chromium.org/, Stand: 31.07.2013
o.A.: CodePlex, https://www.codeplex.com/, Stand: 11.07.2013
o.A.: Welcome to TypeScript, http://typescript.codeplex.com/, Stand: 11.07.2013
o.A.: Downloads, http://creativecommons.org/about/downloads, Stand:
04.07.2013
o.A.: Mehr über die Lizenzen, vgl. http://creativecommons.org/licenses/, Stand:
12.09.2013
o.A.: Things 2 for Mac, http://culturedcode.com/things/, Stand: 15.07.2013
o.A.: Netidee: Eine Million Euro für Internet-Geistesblitze,
http://derstandard.at/1375625792451/Netidee-Eine-Million-Euro-fuer-InternetGeistesblitze, Stand: 06.08.2013
o.A.: Developer Open Space Leipzig, http://devopenspace.de/, Stand: 22.08.2013
o.A.: DevSwag, http://devswag.com/, Stand: 06.08.2013
o.A.: The Document Foundation, http://www.documentfoundation.org/, Stand:
13.08.2013
o.A.: OpenOffice.org Community announces The Document Foundation,
http://listarchives.documentfoundation.org/www/announce/msg00000.html,
Stand: 13.08.2013
o.A.: Doodle vereinfacht die Terminfindung, http://www.doodle.com/, Stand:
15.07.2013
o.A.:.NET User Group Leipzig, http://dotnet-leipzig.de/, Stand: 22.08.2013
o.A.: Drupal, https://drupal.org/, Stand: 15.07.2013
o.A.: Committer Due Diligence Guidelines,
http://www.eclipse.org/legal/committerguidelines.php, Stand: 26.06.2013
o.A.: Ihr virtuelles Gedächtnis, https://evernote.com/intl/de/, Stand: 15.07.2013
o.A.: EXIST ist bundesweit und zielgenau, http://www.exist.de/, Stand:
06.08.2013
o.A.: Facebook, https://www.facebook.com/, Stand: 22.07.2013
o.A.: Flattr, http://flattr.com/, Stand: 02.08.2013
o.A.: Astro, https://flattr.com/profile/Astro, Stand: 26.08.2013
o.A.: Podlove, http://flattr.com/thing/607995/Podlove, Stand: 26.08.2013
o.A.: FOSS.IN, http://foss.in/, Stand: 22.07.2013
o.A.: FourSquare, https://de.foursquare.com/, Stand: 22.07.2013
o.a.: GENIVI, http://www.genivi.org/, Stand: 15.08.2013
o.A.: Pocket, http://getpocket.com/, Stand: 15.07.2013
o.A.: GitHub, https://github.com/, Stand: 11.07.2013
o.A.: Gists, https://gist.github.com/, Stand: 22.07.2013
o.A.: Leipzig.js, http://leipzigjs.github.io/, Stand: 23.07.2013
o.A.: LinkedIn, https://linkedin.com, Stand: 22.07.2013
o.A.: Introducing GitHub for Mac, http://mac.github.com/, Stand: 11.07.2013
o.A.: Quickly publish beautiful pages for you and your projects.,
http://pages.github.com/, Stand: 15.07.2013
124
o.A.: Introducing GitHub for Windows, http://windows.github.com/, Stand:
11.07.2013
o.A.: brackets-shell, https://github.com/adobe/brackets-shell/, Stand:
21.08.2013
o.A.: cloud9, https://github.com/ajaxorg/cloud9, Stand: 31.07.2013
o.A.: node-xmpp, https://github.com/astro/node-xmpp, Stand: 22.08.2013
o.A.: beerjs, https://github.com/beerjs, Stand: 23.07.2013
o.A.: JS Beautifier, https://github.com/einars/js-beautify, Stand: 17.05.2013
o.A.: Roadmap, https://github.com/gruntjs/grunt/wiki/Roadmap, Stand:
16.08.2013
o.A.: grunt-contrib, https://github.com/gruntjs/gruntcontrib/tree/18f375bc59fbbef25f8f32fe572cbfb7fad93002, Stand: 16.08.2013
o.A.: Top Languages, https://github.com/languages, Stand: 25.06.2013
o.A.: MEAN Stack, https://github.com/linnovate/mean, Stand: 15.07.2013
o.A.: LiveReload, https://github.com/livereload/LiveReload2, Stand: 31.07.2013
o.A.: machine.specifications,
https://github.com/machine/machine.specifications, Stand: 22.08.2013
o.A.: node-task, https://github.com/node-task, Stand: 25.06.2013
o.A.: Issues, https://github.com/podlove/podlove-publisher/issues, Stand:
25.08.2013
o.A.: Contributor Model, https://github.com/yui/yui3/wiki/Contributor-Model,
Stand: 26.06.2013
o.A.: Font Awesome The iconic font designed for Bootstrap,
http://fortawesome.github.io/Font-Awesome/, Stand: 15.07.2013
o.A.: Gittip, https://www.gittip.com/, Stand: 02.08.2013
o.A.: Preface: Why a GNOME Foundation?,
https://wiki.gnome.org/Foundation/Charter, Stand: 15.08.2013
o.A.: Über das GNU-Betriebssystem, http://www.gnu.org/gnu/about-gnu, Stand:
02.09.2013
o.A.: Logo der Free Software Foundation, http://www.gnu.org/graphics/fsflogo.html, Stand: 04.07.2013
o.A.: GNU GENERAL PUBLIC LICENSE, http://www.gnu.org/licenses/gpl.html,
Stand: 11.06.2013
o.A.: GNU LESSER GENERAL PUBLIC LICENSE, http://www.gnu.org/licenses/lgpl3.0.en.html, Stand: 26.06.2013
o.A.: Warum die GNU Affero GPL, http://www.gnu.org/licenses/why-afferogpl.html, Stand: 28.08.2013
o. A.: What is free software?, http://www.gnu.org/philosophy/free-sw.en.html,
Stand: 12.06.2013
o.A.: Freie Software verkaufen, http://www.gnu.org/philosophy/selling.html,
Stand: 02.09.2013
o.A.: Mailman, the GNU Mailing List Manager,
http://www.gnu.org/software/mailman/, Stand: 16.07.2013
o.A.: GNU Make, https://www.gnu.org/software/make/, Stand: 15.07.2013
o.A.: Golem, http://www.golem.de/, Stand: 22.07.2013
o.A.: Google Trends Github, SourceForge, CodePlex, Bitbucket, "Google Code",
http://goo.gl/26FKQ, Stand: 11.07.2013
125
o.A.: Professionelle Webanalysen., http://www.google.com/analytics/, Stand:
16.07.2013
o.A.: Hangouts, http://www.google.com/hangouts/, Stand: 22.07.2013
o.A.: Google Code, https://code.google.com/intl/de/, Stand: 11.07.2013
o.A.: V8 JavaScript Engine, https://code.google.com/p/v8/, Stand: 25.06.2013
o.A.: Make the Web Faster, https://developers.google.com/speed/pagespeed/,
Stand: 16.07.2013
o.A.: Willkommen bei Google Groups!, https://groups.google.com/, Stand:
16.07.2013
o.A.: 2013 Financial Tables, http://investor.google.com/financial/tables.html,
Stand: 31.07.2013
o.A.: Google+, https://plus.google.com/, Stand: 22.07.2013
o.A.: Welcome to Google Calendar,
https://support.google.com/calendar/answer/2465776, Stand: 15.07.2013
o.A.: Docs, Sheets, and Slides, https://support.google.com/drive/answer/49008,
Stand: 15.07.2013
o.A.: What is Gradle?, http://www.gradle.org/, Stand: 15.07.2013
o.A.: Grml Live Linux, http://grml.org/, Stand: 03.09.2013
o.A.: GRUNT The JavaScript Task Runner, http://gruntjs.com/, Stand: 15.07.2013
o.A.: Heise, http://www.heise.de/, Stand: 22.07.2013
o.A.: c’t, http://www.heise.de/ct/, Stand: 22.07.2013
o.A.: GitHub issues made awesome, http://huboard.com/, Stand: 15.07.2013
o.A.: Welcome to the Icinga Merchandise Store!,
https://www.icinga.org/merchandise/, Stand: 06.08.2013
o.A.: Transform your plain text into static websites and blogs.,
http://jekyllrb.com/, Stand: 15.07.2013
o.A.: Jenkins, http://jenkins-ci.org/, Stand: 16.07.2013
o.A.: THE INTRANET IS DEAD. LONG LIVE THE SOCIAL INTRANET.,
http://www.jivesoftware.com/social-business/solutions/social-intranet/, Stand:
15.07.2013
o.A.: JSConf, http://jsconf.com/, Stand: 22.07.2013
o.A.: KickStarter, http://www.kickstarter.com/, Stand: 05.08.2013
o.A.: Defining Your Project,
http://www.kickstarter.com/help/school#creating_rewards, Stand: 05.08.2013
o.A.: Next Generation LiveCode (Open Source),
http://www.kickstarter.com/projects/1755283828/open-source-edition-oflivecode, Stand: 08.08.2013
o.A.: Linux Magazin, http://www.linux-magazin.de/, Stand: 22.07.2013
o.A.: LinuxUser, http://www.linux-user.de/, Stand: 22.07.2013
o.A.: Mantis Bug-Tracker, http://www.mantisbt.org/, Stand: 12.07.2013
o.A.: JavaScript Developer, https://masterbranch.com/job/javascript-developer6wunderkinder-berlin/1340, Stand: 06.08.2013
o.A.: Welcome to MediaWiki.org, http://www.mediawiki.org/, Stand: 15.07.2013
o.A.: Meteor, http://meteor.com/, Stand: 11.06.2013
o.A.: Project, http://office.microsoft.com/de-de/project/, Stand: 09.09.2013
o.A.: Word, http://office.microsoft.com/de-de/word/, Stand: 15.07.2013
126
o.A.: Exchange, http://www.microsoft.com/exchange/2010/de/de/, Stand:
15.07.2013
o.A.: mIRC, http://www.mirc.com/, Stand: 22.07.2013
o.A.: Das Mozilla-Manifest, http://www.mozilla.org/de/about/manifesto/, Stand:
05.08.2013
o.A.: Mozilla 15 Jahre besseres Internet, https://www.mozilla.org/de/contribute/,
Stand: 02.07.2013
o.A.: Join Mozilla For a better Web and a better world,
https://sendto.mozilla.org/page/contribute/join-mozilla?source=MozOrg-join,
Stand: 05.08.2013
o.A.: MySQL, http://www.mysql.com/, Stand: 31.07.2013
o.A.: Commercial License for OEMs, ISVs and VARs,
http://www.mysql.com/about/legal/licensing/oem/, Stand: 02.08.2013
o.A.: Kapitel 1. Einstieg in die Groupware,
https://webmail.eva.mpg.de/ox6/help/de_DE/guide.chap.intro.html, Stand:
15.07.2013
o.A.: July 2013 Web Server Survey,
http://news.netcraft.com/archives/2013/07/02/july-2013-web-serversurvey.html, Stand: 09.08.2013
o.A.: Interview: Thomas Krumbein von LibreOffice zur Arbeit mit Oracle,
http://www.netzwelt.de/news/84723-interview-thomas-krumbein-libreofficearbeit-oracle.html, Stand: 12.06.2013
o.A.: NodeJS Contributor License Agreement ("Agreement"),
http://nodejs.org/cla.html, Stand: 13.08.2013
o.A.: Octopress, http://octopress.org/, Stand: 22.08.2013
o.A.: OmmWriter, http://www.ommwriter.com/, Stand: 15.07.2013
o.A.: OmniFocus for Mac, http://www.omnigroup.com/products/omnifocus/,
Stand: 15.07.2013
o.A.: Custom Piwik T-Shirts!, http://www.ooshirts.com/piwik, Stand: 06.08.2013
o.A.: History of the OSI , http://opensource.org/history, Stand: 17.05.2013
o.A.: Apache License, Version 2.0, http://opensource.org/licenses/Apache-2.0,
Stand: 11.06.2013
o.A.: The BSD 2-Clause License, http://opensource.org/licenses/bsd-license.php,
Stand: 26.06.2013
o.A.: The MIT License (MIT), http://opensource.org/licenses/MIT, Stand:
11.06.2013
o.A.: OSI Logo Files, http://opensource.org/node/442, Stand: 04.07.2013
o.A.: The Open Source Definition, http://opensource.org/osd, Stand: 13.08.2013
o.A.: Companies Supporting The OpenStack Foundation,
http://www.openstack.org/foundation/companies/, Stand: 08.08.2013
o.A.: Oracle Berkeley DB Licensing Information,
http://www.oracle.com/technetwork/database/berkeleydb/downloads/licensing098979.html, Stand: 02.08.2013
o.A.: Orkut, http://orkut.com, Stand: 22.07.2013
o.A.: Open Source Business Alliance, http://www.osb-alliance.de/, Stand:
03.07.2013
o.A.: OSS Watch, http://www.oss-watch.ac.uk/, Stand: 03.07.2013
127
o.A.: Spenden, https://www.paypal.com/de/cgibin/webscr?cmd=p/xcl/rec/donate-intro-outside, Stand: 02.08.2013
o.A.: Adobe PhoneGap Build, https://build.phonegap.com/, Stand: 31.07.2013
o.A.: THE #1 FREE, OPEN SOURCE BULLETIN BOARD SOFTWARE,
https://www.phpbb.com/, Stand: 16.07.2013
o.A.: Pidgin, http://pidgin.im/, Stand: 22.07.2013
o.A.: Pinterest, https://pinterest.com/, Stand: 22.07.2013
o.A.: Piwik Webanalyse befreien, http://de.piwik.org/, Stand: 16.07.2013
o.A.: Piwik Hosting, http://piwik.org/hosting/, Stand: 02.08.2013
o.A.: Podlove, http://podlove.org/, Stand: 01.07.2013
o.A.: Qt Licensing, http://qt-project.org/products/licensing, Stand: 02.08.2013
o.A.: The Maker Movement, http://www.raisinggeeks.com/blog/makermovement/, Stand: 09.08.2013
o.A.: rAppid.js,http://www.rappidjs.com/, Stand: 22.08.2013
o.A.: Red Hat, http://www.redhat.com/, Stand: 31.07.2013
o.A.: Redmine, http://www.redmine.org/, Stand: 12.07.2013
o.A.: Extreme Programming (XP), http://www.scrum-kompakt.de/grundlagen-desprojektmanagements/extreme-programming-xp/, Stand: 09.07.2013
o.A.: Support Sencha, http://www.sencha.com/support/, Stand: 02.08.2013
o.A.: The 2013 Future of Open Source Survey Results,
http://www.slideshare.net/blackducksoftware/the-2013-future-of-open-sourcesurvey-results, Stand: 08.08.2013
o.A.: Egal, wo Sie oder Ihre Freunde sich aufhalten – mit Skype bleiben Sie in
Kontakt., http://www.skype.com/de/, Stand: 22.07.2013
o.A.: Orkut Review, http://social-networking-websitesreview.toptenreviews.com/orkut-review.html, Stand: 22.07.2013
o.A.: SourceForge, http://sourceforge.net/, Stand: 11.07.2013
o.A.: Open Source Software und Joomla! CMS,
http://opensourcejoomla.spreadshirt.de/, Stand: 06.08.2013
o.A.: StackOverflow, http://stackoverflow.com/, Stand: 16.07.2013
o.A.: Programm zur Förderung technologieorientierter Unternehmensgründungen,
http://www.startup-inbayern.de/themenmenue/foerderung/zuschuesse/foerderungtechnologieorientierter-unternehmensgruendungen.html, Stand: 06.08.2013
o.A.: Was ist ein Barcamp?, http://systemscamp.org/was-ist-ein-barcamp/, Stand:
23.07.2013
o.A.: t3n, http://t3n.de/, Stand: 22.07.2013
o.A.: The Couch Firm, http://thecouchfirm.com/, Stand: 06.08.2013
o.A.: The Node Firm, http://thenodefirm.com/, Stand: 06.08.2013
o.A.: tl;dr Legal, http://www.tldrlegal.com/, Stand: 16.07.2013
o.A.: TodoMVC, http://todomvc.com/, Stand: 28.06.2013
o.A.: Travis, https://travis-ci.org/, Stand: 16.07.2013
o.A.: Trello, https://trello.com/, Stand: 15.07.2013
o.A.: Trello Brackets, https://trello.com/b/LCDud1Nd/brackets, Stand:
21.08.2013
128
o.A.: Podlove Publisher, https://trello.com/b/zB4mKQlD/podlove-publisher,
Stand: 25.08.2013
o.A.: Podlove Web Player, https://trello.com/b/mFPdgi1P/podlove-web-player,
Stand: 25.08.2013
o.A.: Just a blogging platform., http://tryghost.org/, Stand: 22.08.2013
o.A.: Twitter, https://twitter.com/, Stand: 22.07.2013
o.a.: TYPO3, http://typo3.org/, Stand: 15.07.2013
o.A.: FAQ, http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F, Stand:
02.07.2013
o.A.: Wikipedia, http://www.wikipedia.org/, Stand: 15.07.2013
o.A.: WordPress.org, http://wordpress.org/, Stand: 15.07.2013
o.A.: Introduction to WordPress.com,
http://en.support.wordpress.com/introduction/, Stand: 15.07.2013
o.A.: WordPress, https://signup.wordpress.com/signup/, Stand: 02.08.2013
o.A.: Meteor meets NoGPL, https://news.ycombinator.com/item?id=3836212,
Stand: 11.06.2013
o.A.: Meteor is now MIT licensed,
https://news.ycombinator.com/item?id=3870700, Stand: 11.06.2013
o.A.: Xing, http://www.xing.com/, Stand: 22.07.2013
O’Leary, Amy: 3-D Printers to Make Things You Need or Like,
http://www.nytimes.com/2013/06/20/technology/personaltech/home-3-dprinters-to-make-things-you-need-or-just-like.html, Stand: 09.08.2013
O’Nolan, John: Ghost: Just a Blogging Platform,
http://www.kickstarter.com/projects/johnonolan/ghost-just-a-bloggingplatform, Stand: 05.08.2013
Osmani, Addy: The Pros And Cons Of JavaScript Micro-Frameworks,
http://addyosmani.com/blog/prosconsmicroframeworks/, Stand: 28.06.2013
Otto, Mark: Building Twitter Bootstrap, http://alistapart.com/article/buildingtwitter-bootstrap, Stand: 25.06.2013
Otto, Mark: WIP: Bootstrap 3, https://github.com/twitter/bootstrap/pull/6342,
Stand: 12.07.2013
Pardee, Matt: The Road to Node.js v1.0, http://blog.strongloop.com/the-road-tonode-js-v1-0/, Stand: 15.08.2013
Pash, Adam: Social Network Faceoff: Facebook vs. Twitter vs. Google+,
http://lifehacker.com/5842997, Stand: 22.07.2013
Patterson, Sean: Chrome Overtakes IE as the World’s Most Used Browser,
http://www.webpronews.com/chrome-overtakes-ie-as-the-worlds-most-usedbrowser-2012-05, Stand: 09.08.2013
Pepitone, Julianne: Why 84% of Kickstarter's top projects shipped late,
http://money.cnn.com/2012/12/18/technology/innovation/kickstarter-shipdelay/index.html, Stand: 05.08.2013
Pritlove, Tim; u.a.: LS011 Podlove Publisher, http://der-lautsprecher.de/ls011podlove-publisher bei 6:22 Minuten, Stand: 05.08.2013
Pritlove, Tim: Podlove-Crowdfunding gestartet,
http://metaebene.me/blog/2013/02/27/podlove-crowdfunding-gestartet/,
Stand: 15.08.2013
Prokop, Michael: Open Source Projektmanagement, Open Source Press, 2010, 1.
Auflage
129
Rashid, Fahmida: Size Matters: When Open Source Code Quality is Better than
Proprietary Software, http://www.securityweek.com/size-matters-when-opensource-code-quality-better-proprietary-software, Stand: 08.08.2013
Ridder, Hans-Gerd: Personalwirtschaftslehre, Kohlhammer, 2009, 3. Auflage
Scales, Mat: The State of Javascript Package Management,
http://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-packagemanagement/, Stand: 28.06.2013
Schießle, Björn: Free Software, Open Source, FOSS, FLOSS - same same but
different, https://fsfe.org/freesoftware/basics/comparison, Stand: 12.06.2013
Schmidt, John: Meteor's new $11.2 million development budget,
http://www.meteor.com/blog/2012/07/25/meteors-new-112-milliondevelopment-budget, Stand: 06.08.2013
Schuba, Johannes: Großer BarCamp-Überblick: Alle Un-Konferenzen in
Deutschland, Österreich und der Schweiz, http://t3n.de/news/grosser-barcampuberblick-alle-un-konferenzen-255252/, Stand: 23.07.2013
Schuh, Günther: Produktkomplexität managen: Strategien - Methoden - Tools, Carl
Hanser Verlag, 2005, 2. Auflage
Spencer, Donna: How to Conduct A Content Audit, http://uxmastery.com/how-toconduct-a-content-audit/, Stand: 16.07.2013
Stallman, Richard: Free Software: Freedom and Cooperation,
http://www.gnu.org/events/rms-nyu-2001-transcript.txt, Stand: 13.08.2013
Stürmer, Matthias: Four types of open source communities,
http://opensource.com/business/13/6/four-types-organizational-structureswithin-open-source-communities, Stand: 01.07.2013
Suh, Annie: Print vs Online Magazines, http://suite101.com/article/print-vsonline-magazines-a155014, Stand: 04.09.2013
de Valk, Joost: Open Source, Motivations & Business, http://yoast.com/opensource-motivations-business/, Stand: 19.08.2013
Vance, Ashlee: 3-D Printing Spurs a Manufacturing Revolution,
http://www.nytimes.com/2010/09/14/technology/14print.html, Stand:
09.08.2013
Waldinger, Markus: Microsoft Project 2013 review,
http://review.techworld.com/applications/3404323/microsoft-project-2013review/, Stand: 12.09.2013
Weber, Harrison: After nearly 10 years, Adobe abandons its Creative Suite entirely
to focus on Creative Cloud, http://thenextweb.com/insider/2013/05/06/afternearly-10-years-adobe-abandons-its-creative-suite-entirely-to-focus-on-creativecloud, Stand: 08.08.2013
Weßel, Christa: Basiswissen Consulting, mitp, 2013, 1. Auflage
Wilhelm, Axel: http://techcrunch.com/2013/08/07/in-the-smartphone-wars-itsios-vs-android-and-windows-phone-vs-the-rest/, Stand: 09.08.2013
Williams, Dan: Overview of Build Systems,
http://www.cs.virginia.edu/~dww4s/articles/build_systems.html, Stand:
15.07.2013
Wirdeman, Ralf: Scrum mit User Stories, Carl Hanser Verlag, 2011, 2. Auflage
Zakas, Nicholas: Starting An Open-Source Project,
http://coding.smashingmagazine.com/2013/01/03/starting-open-sourceproject/, Stand: 26.06.2013
130
Selbstständigkeitserklärung
131
SELBSTSTÄNDIGKEITSERKLÄRUNG
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig
und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe.
Stellen, die wörtlich oder sinngemäß aus Quellen entnommen
wurden, sind als solche kenntlich gemacht.
Diese Arbeit wurde in gleicher oder ähnlicher Form noch keiner
anderen Prüfungsbehörde vorgelegt.
Leipzig, 16.09.2013
Unterschrift

Management und Entwicklung von quelloffener Software

Transcription

Similar documents

Grundlagen der Betriebswirtschaftslehre (BWL 1)

Anhangband Kompetenzen und exzessive Nutzung bei

Verdoppelung der Hilfe – Halbierung der Armut

mobile marketing - Smarter Service

Der Magic Quadrant für Infrastrukturlösungen zur x86

- Die Toolbox zum AGE

- Heftarchiv - Internet World Business

Startup Toolbox

Übersicht über SAP R/3-Standardreports

Motivationstheorien - Marketing Coaching

e-lhs - BaFin

E-Lehrbuch – BWL einfach und schnell

Leistungsorientierte Bezahlung Leistungsorientierte Bezahlung

abraham maslow - Social