Interaktionsmuster in OpenSource Communities
Open Source - eine Alternative zu traditionellen Geschäftsmodellen?
©2009
Diplomarbeit
106 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Besonders die rasante Entwicklung der Computer und Informationstechnologien haben die modernen Gesellschaften nachhaltig verändert. Vielfältige virtuelle Gemeinschaften sind durch die neuen Kommunikationsformen des Internet entstanden. Welche Rolle diese virtuellen communities gegenüber traditionell lokal orientierten Gemeinschaften spielen, ist heute nur in Ansätzen verstanden.
Innerhalb virtueller Gemeinschaften nehmen Open Source-Communities1 eine Sonderstellung ein. Während virtuelle Spielergruppen, Chats oder Themen-Foren vornehmlich dem Vergnügen oder Wissensaustausch dienen, wird in Open Source-Projekten ein reales Marktprodukt entwickelt. Die Projektmitglieder arbeiten freiwillig an Software, die zwar kostenlos vertrieben wird, aber auf dem Markt gegen Konkurrenzprodukte bestehen muss.2 Dadurch bringen Open Source-Projekte sozialwissenschaftliche Themen wie Arbeitsteilung, Arbeitsorganisation, Marketingstrategien, Qualitätskontrolle etc. ins Spiel, welche sich über die meisten anderen freiwilligen Internetgemeinschaften nicht abgreifen lassen.
Für Unternehmen sind Open Source-Strukturen interessant, weil dort starkes Innovationspotenzial vermutet wird. Außerdem scheinen in diesen Arbeitsprozessen jene Probleme elektronischer Informations- und Kommunikationstechnik gelöst, auf die traditionelle Unternehmensstrukturen noch keine Antwort gefunden haben. Telearbeit ist beispielsweise für Unternehmen reizvoll, weil sich durch das Internet Transaktionskosten verringern lassen. Doch die Einführung dieser Arbeitsmethode bringt Probleme mit sich. Die neuen Organisationsstrukturen divergiert zum Teil erheblich mit bestehenden und setzen Konfliktpotenzial frei. Auch Abseits der Telearbeit hat elektronische Kommunikationsunterstützung via Email Einzug in Unternehmen gehalten und entfaltet Veränderungspotenziale. Mit Verweis auf die Bedeutung von Geschwindigkeit in einer globalisierten Welt, sprechen Kuhn/Thielmann vom Erfordernis des Echtzeitunternehmens, in welchem Daten ohne Zeitverzögerung in Echtzeit in den wohl organisierten, betrieblichen Datenpool integriert werden. Umstrukturierungen von Daimler Chrysler hin zum Echtzeitunternehmen zeigten, dass es nicht ausreicht, elektronisch vermittelte Kommunikation als reinen Bestandteil des Kerngeschäftsprozesses zu nutzen, sie muß vollständig darin eingebettet werden. Open Source-Projekte stellen als hauptsächlich elektronisch vermittelte Produktionsweise ein Modell […]
Besonders die rasante Entwicklung der Computer und Informationstechnologien haben die modernen Gesellschaften nachhaltig verändert. Vielfältige virtuelle Gemeinschaften sind durch die neuen Kommunikationsformen des Internet entstanden. Welche Rolle diese virtuellen communities gegenüber traditionell lokal orientierten Gemeinschaften spielen, ist heute nur in Ansätzen verstanden.
Innerhalb virtueller Gemeinschaften nehmen Open Source-Communities1 eine Sonderstellung ein. Während virtuelle Spielergruppen, Chats oder Themen-Foren vornehmlich dem Vergnügen oder Wissensaustausch dienen, wird in Open Source-Projekten ein reales Marktprodukt entwickelt. Die Projektmitglieder arbeiten freiwillig an Software, die zwar kostenlos vertrieben wird, aber auf dem Markt gegen Konkurrenzprodukte bestehen muss.2 Dadurch bringen Open Source-Projekte sozialwissenschaftliche Themen wie Arbeitsteilung, Arbeitsorganisation, Marketingstrategien, Qualitätskontrolle etc. ins Spiel, welche sich über die meisten anderen freiwilligen Internetgemeinschaften nicht abgreifen lassen.
Für Unternehmen sind Open Source-Strukturen interessant, weil dort starkes Innovationspotenzial vermutet wird. Außerdem scheinen in diesen Arbeitsprozessen jene Probleme elektronischer Informations- und Kommunikationstechnik gelöst, auf die traditionelle Unternehmensstrukturen noch keine Antwort gefunden haben. Telearbeit ist beispielsweise für Unternehmen reizvoll, weil sich durch das Internet Transaktionskosten verringern lassen. Doch die Einführung dieser Arbeitsmethode bringt Probleme mit sich. Die neuen Organisationsstrukturen divergiert zum Teil erheblich mit bestehenden und setzen Konfliktpotenzial frei. Auch Abseits der Telearbeit hat elektronische Kommunikationsunterstützung via Email Einzug in Unternehmen gehalten und entfaltet Veränderungspotenziale. Mit Verweis auf die Bedeutung von Geschwindigkeit in einer globalisierten Welt, sprechen Kuhn/Thielmann vom Erfordernis des Echtzeitunternehmens, in welchem Daten ohne Zeitverzögerung in Echtzeit in den wohl organisierten, betrieblichen Datenpool integriert werden. Umstrukturierungen von Daimler Chrysler hin zum Echtzeitunternehmen zeigten, dass es nicht ausreicht, elektronisch vermittelte Kommunikation als reinen Bestandteil des Kerngeschäftsprozesses zu nutzen, sie muß vollständig darin eingebettet werden. Open Source-Projekte stellen als hauptsächlich elektronisch vermittelte Produktionsweise ein Modell […]
Leseprobe
Inhaltsverzeichnis
René Lehnert
Interaktionsmuster in OpenSource Communities
Open Source - eine Alternative zu traditionellen Geschäftsmodellen?
ISBN: 978-3-8366-4560-7
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2010
Zugl. Universität Duisburg-Essen, Standort Duisburg, Duisburg, Deutschland,
Diplomarbeit, 2009
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2010
ii
Abstract
Diese Diplomarbeit geht der Frage nach, welche strukturellen Prinzipien dem Open
Source Projekt KDE zugrunde liegen und inwieweit diese auf traditionelle
Unternehmensstrukturen übertragbar sind. Im ersten empirischen Teil werden
Projektbeteiligungen von Mitgliedern untersucht. Die Ergebnisse untermauern die
Annahme einer Reputationsökonomie. Der zweite empirische Teil hebt auf die
Strukturen in einer KDE-Mailingliste ab. Im Gegensatz zu traditionellen
Unternehmensstrukturen scheint elektronische Kommunikation die realweltliche
Organisationshierarchie
stärker
abzubilden
und
eine
Umkehr
klassischer
Informationsmacht
stattgefunden
zu
haben.
Dabei
wird
nicht
mehr
Informationszurückhaltung, sondern breite und häufige Kommunikation vom System
belohnt. Die Mailingliste weist eine relativ stabile Zentrum-Peripherie-Struktur, bei der
sich intensive Kommunikation hauptsächlich auf das Zentrum beschränkt. Den Zugang
zum Zentrum scheint eine Kleingruppenobergröße zu limitieren. Während in
traditionellen
Unternehmen
meist
parallele
Zusammenarbeits-
und
Kommunikationsstrukturen angestrebt werden, wird für Open Source-Projekte die
These herausgearbeitet, dass gemeinsame Kommunikation nicht vornehmlich durch
Zusammenarbeit, sondern durch eine vorhandene Reputationsökonomie initiiert wird.
Dadurch lösen sich für Open Source-Projekte Divergenzprobleme zwischen formaler
und informeller Struktur auf. Desweiteren wird die Kommunikation während zweier
zyklischer KDE-Produktionsphasen untersucht, einer eher zentralisierten und einer
eher kreativen Phase. Die zentralisierte Produktionsphase führt zu einer stärker
zentralisierten Kommunikationsstruktur, die kreative Phase zu einer Verdichtung und
Intensivierung von Kommunikation. Dieser Zyklus von Verdichtung und Zerstreuung
wiederholt sich während des Beobachtungszeitraumes regelmäßig im Sinne einer von
Marcel Mauss (1974) beschriebenen Morphologie des sozialen Raumes. Dies führt zur
These,
dass
Open
Source-Projekte
im
Gegensatz
zu
traditionellen
Unternehmensstrukturen das Grundbedürfnis des Menschen nach Nähe und Ferne
strukturell eingewebt haben.
Hinweis:
In dieser öffentlichen Version wurden aus Datenschutzgründen die Namen der
KDE-Akteure durch deren Nummern im Kdecore03-06-1m-year.net-Datensatz bzw.
durch "xxx" ersetzt. Bei Interesse an eigenen Untersuchungen können die
Datensätze bei René Lehnert (lehnert.rene[at]web.de) oder bei Sam Zeini
(http://zeini.collide.info) erfragt werden.
iii
Inhalt
1 Problemstellung und Zielsetzung ...
1.1 Das Sozialwissenschaftliche Interesse an Open Source Communities ...
1.2 Aufbau der Arbeit ...
2 Datenerhebung und Analysesoftware ...
2.1 Datenerhebung ...
2.2 Verwendete Analysesoftware ...
3 Verwendete Netzwerkanalytische Maßzahlen und Verfahren ...
4 Die Bedeutung von Reputation in Open Source Projekten ...
4.1 Bisherige Forschungsergebnisse zur Reputation in Open Source
Projekten ...
4.2 Tätigkeitsbezogener Reputationserwerb ...
4.3 Projektbezogener Reputationserwerb ...
4.4 Kommunikationsbezogener Reputationserwerb ...
4.5 Kapitel-Resümee ...
5 Die statische Struktur der KDE-Mailingliste ...
5.1 Email-Kommunikation in Unternehmen ...
5.2 Power Law Verteilung in Emailnetzen ...
5.3 Vernetzung nach Kommunikationsintensität ...
5.4 Zentrum und Peripherie in der Kommunikation ...
5.4.1 Festlegung eines Zentrums ...
5.4.2 Kommunikation zwischen Zentrum und Peripherie ...
5.4.3 Kommunikation zwischen Zentrum und Neulingen ...
5.5 Arbeits- und Kommunikationsstruktur im Vergleich ...
5.6 Sozialkapital in einer Reputationsökonomie ...
5.6.1 Das Konzept des Sozialkapitals ...
5.6.2 Sozialkapital in KDE ...
5.6.3 Formalisierung und Informalisierung in Unternehmen und Open
Source-Projekten ...
5.7 Kapitel-Resümee ...
1
1
3
4
4
6
7
11
11
13
16
18
21
22
22
23
25
27
27
29
30
31
34
34
36
41
42
iv
6 Dynamiken der KDE-Emailkommunikation ...
6.1 Auftrittsäugigkeiten von Threads ...
6.2 Netzwerkstabilität im KDE Mailingnetz ...
6.2.1 Teilnehmerfluktuationen auf Makroebene ...
6.2.2 Teilnehmerfluktuationen auf Mikroebene ...
6.2.3 Kommunikationsverhalten von Neulingen ...
6.3 Dynamiken von Zentrum und Peripherie ...
6.3.1 Positionale Analysen der Zentrums-Peripheriestruktur ...
6.3.1.1 Positionale Halbjahres-Analyse ...
6.3.1.2 Positionale Analyse nach Moving Structure Ansatz ...
6.3.1.3 Limitierung des Zentrumszuwachses ...
6.3.1.4 Das Zentrum und seine Kleingruppengröße ...
6.3.2 Überbrückungsfunktion des Zentrums ...
6.4 Struktureller Wandel während verschiedener Produktionsphasen ...
6.4.1 Netzwerkmaßzahlen während der Produktionsphasen ...
6.4.2 Positionale Analyse der Produktionsphasen ...
6.4.3 Soziale Morphologie des virtuellen Raumes ...
6.4.3.1 Soziale Morphologie der Inuit ...
6.4.3.2 Gemeinsamkeiten der soziale Morphologie der Inuit
und der KDE-Gemeinschaft ...
6.4.3.3 Bedeutung sozialer Morphologie für
Unternehmensstrukturen ...
6.5 Kapitel-Resümee ...
7 Abschlussdiskussion ...
7.1 Zusammenfassung der empirischen Ergebnisse ...
7.2 Die Übertragbarkeit von Open Source- auf traditionelle
Unternehmensstrukturen ...
I Literaturverzeichnis ...
II Abbildungs- und Tabellenverzeichnis ...
III Anhang ...
43
43
43
45
47
49
51
51
51
54
58
60
61
64
66
67
70
70
71
74
75
76
76
77
V
IX
XII
1
1 Problemstellung und Zielsetzung
1.1 Das sozialwissenschaftliche Interesse an Open Source Communities
,,Besonders
die
rasante
Entwicklung
der
Computer
und
Informationstechnologien haben die modernen Gesellschaften nachhaltig
verändert. Vielfältige virtuelle Gemeinschaften sind durch die neuen
Kommunikationsformen des Internet entstanden. Welche Rolle diese virtuellen
,communities' gegenüber traditionell lokal orientierten Gemeinschaften spielen,
ist heute nur in Ansätzen verstanden." (Krempel 2008: 219).
Innerhalb virtueller Gemeinschaften nehmen Open Source-Communities
1
eine
Sonderstellung ein. Während virtuelle Spielergruppen, Chats oder Themen-Foren
vornehmlich dem Vergnügen oder Wissensaustausch dienen, wird in Open Source-
Projekten ein reales Marktprodukt entwickelt. Die Projektmitglieder arbeiten freiwillig an
Software, die zwar kostenlos vertrieben wird, aber auf dem Markt gegen
Konkurrenzprodukte bestehen muss.
2
Dadurch bringen Open Source-Projekte
sozialwissenschaftliche
Themen
wie
Arbeitsteilung,
Arbeitsorganisation,
Marketingstrategien, Qualitätskontrolle etc. ins Spiel, welche sich über die meisten
anderen freiwilligen Internetgemeinschaften nicht abgreifen lassen.
Für Unternehmen sind Open Source-Strukturen interessant, weil dort starkes
Innovationspotenzial vermutet wird (vgl. Heinrich et al. 2006: 1, Diedrich 2007: 1,
Brand/Holtgrewe 2007: 25f). Außerdem scheinen in diesen Arbeitsprozessen jene
Probleme elektronischer Informations- und Kommunikationstechnik gelöst, auf die
traditionelle Unternehmensstrukturen noch keine Antwort gefunden haben. Telearbeit
ist beispielsweise für Unternehmen reizvoll, weil sich durch das Internet
Transaktionskosten verringern lassen (vgl. Gehle 2003: 12). Doch die Einführung
dieser Arbeitsmethode bringt Probleme mit sich. Die neuen Organisationsstrukturen
divergiert zum Teil erheblich mit bestehenden und setzen Konfliktpotenzial frei (vgl.
1
Die Szene kann in zwei Flügel unterschieden werden, in Idealisten der ,,Freien Software" um
Richard M. Stallmann und in Pragmatiker der ,,Open Source" um Eric S. Raymond (vgl.
Brand/Holtgrewe 2007: 33f). KDE ist dem pragmatischen Flügel zuzuordnen (vgl. KDE
Announcements 2000). Deshalb wird in dieser Arbeit der Terminus ,,Open Source" gewählt.
2
Die Sicherstellung von Open Source-Software als nichtkommerzielles Produkt garantieren
diverse Lizenzen. Diese verhindern Patentierungen und die Vereinnahmung durch den Markt.
www.opensource.org/licenses
2
ebd.: 205-207, 256, 261). Auch Abseits der Telearbeit hat elektronische
Kommunikationsunterstützung via Email Einzug in Unternehmen gehalten und entfaltet
Veränderungspotenziale (vgl. Götzenbrucker 2005: 2). Mit Verweis auf die Bedeutung
von Geschwindigkeit in einer globalisierten Welt, sprechen Kuhn/Thielmann (2005: 3f)
vom
Erfordernis
des
,,Echtzeitunternehmens",
in
welchem
Daten
"ohne
Zeitverzögerung in Echtzeit in den wohl organisierten, betrieblichen Datenpool
integriert" (Kuhn/Thielmann 2005: 3) werden. Umstrukturierungen von Daimler Chrysler
hin zum Echtzeitunternehmen zeigten, dass es nicht ausreicht, elektronisch vermittelte
Kommunikation als reinen Bestandteil des Kerngeschäftsprozesses zu nutzen, ,,sie
muß vollständig darin eingebettet werden" (Unger 2005: 81). Open Source-Projekte
stellen als hauptsächlich elektronisch vermittelte Produktionsweise (vgl. Brand/Schmid
2006: 127) ein Modell dar, welches diese Anforderungen erfüllt. Doch wie gelingt das?
Die Selbstbeschreibung der Szene bringt KDE-Gründer Matthias Ettrich (2004: 179)
wie folgt auf den Punkt:
"Wenn alle nur machen, was sie wollen, und keine kontrollierende und leitende
Instanz existiert, warum gibt es dann nicht endlose Diskussionen und ein
heilloses Durcheinander? [...] Derzeit wissen wir, dass es funktioniert, ahnen
aber lediglich, warum."
Umso erstaunlicher ist es, dass trotz der offenen Fragen das empirische Material rar
ausfällt. Sozialwissenschaftliche Diskussionen zu diesem Thema blieben bisher
überwiegend theoretischer Natur (vgl. ebd.: 1, Steglitz 2008: 175, Götzenbrucker 2005:
1, Brand/Holtgrewe 2007: 25). Dabei präsentieren sich Open Source-Communities als
quasi gläserne Organisationen. Interne Kommunikations- und Arbeitsabläufe stehen
jedermann im Netz frei zur Verfügung. Ein Grund für die mangelnde empirische
Ausbeute könnte darin liegen, dass Programmierkenntnisse, Umgang mit Datenbanken
und Verfahren der Netzwerkanalyse in den Sozialwissenschaften eher die Ausnahme
darstellen (vgl. Krempel 2008: 225). Das Computerzeitalter hat neue Fragen
aufgeworfen, aber es gibt dem Forscher auch die Mittel an die Hand, genau diese
Fragen zu lösen. Gerade im Bereich der sozialen Netzwerkanalyse steht inzwischen
leistungsfähige Software zur Verfügung, die den früheren Nachteil der Methode
beheben, auf mehr Datenmaterial als die Umfrageforschung angewiesen zu sein (vgl.
ebd.: 215). Wie aufschlussreich die sozialwissenschaftlichen, aber auch ökonomischen
Einsichten einer netzwerkanalytisch aufgearbeiteten Kommunikationsstruktur sein
können, demonstrieren Collingsworth/Menezes (2009: 209) in einer aktuellen
Untersuchung
des
Emailverkehrs
des
2001
in
Konkurs getretenen
US-
3
Energiekonzerns Enron. Die Unternehmenskrise zeichnete sich schon im Emailnetz
ab, so das Argument. Es fanden sich u.a. Zusammenhänge zwischen Aktienkurs und
Emailaktivität (vgl. ebd.: 218).
"our hypothesis is that we can use the anomalies in the network to identify
social tension in the organization and consequently help mitigate its
consequences." (ebd.: 209)
Ziel dieser Diplomarbeit ist es, einen empirischen Beitrag zu leisten, indem
Netzwerkstrukturen eines Open Source-Projektes hinsichtlich ihrer Übertragbarkeit auf
traditionelle Unternehmensstrukturen ausgewertet werden. Als Untersuchungs-
gegenstand empfiehlt sich das Open Source Projekt KDE (K Desktop Environment)
3
,
denn es war bereits Thema sozial-wissenschaftlicher Abhandlungen und bietet ein
gewisses empirisches und theoretisches Fundament (vgl. Brand 2002, 2003,
Brand/Schmid 2006, Brand/Holtgrewe 2007, Ettrich 2004, Brucherseifer 2004). Das
Projekt stellt seit 1996 eine graphische Desktopumgebung her, die das Betriebssystem
Linux
4
auch für PC-Anwender nutzbar machen soll (vgl. Brucherseifer 2004: 67).
Derzeit zählt die Community ca. 1200 aktive Mitwirkenden (vgl. Bantle 2009). Seit 1997
existiert auch ein formaler Dachverband in Form eines gemeinnützigen Vereins KDE
e.V. (vgl. KDE-Vereinssatzung 2006).
1.2 Aufbau der Arbeit
Vor der eigentlichen Untersuchung werden die zu verwendenden Datensätze sowie
Netzwerkkennzahlen und Messkonzepte vorgestellt. Der empirische Teil gliedert sich in
drei Kapitel. Kapitel 4 beschäftigt sich mit Reputation innerhalb der Community, Kapitel
5 und 6 mit der Emailkommunikation in KDE. Dabei fasst Kapitel 5 das statische Netz
ins Auge, Kapitel 6 wirft einen Blick auf Netzwerkdynamiken im Zeitverlauf. Am Ende
eines jeden empirischen Kapitels stellt eine Ergebnisdiskussion die Bedeutung
gefundener Strukturmuster vor einen sozialwissenschaftstheoretischen Hintergrund.
Insgesamt hält die Diplomarbeit ihren Fokus explorativ auf der Makroebene.
3
www.kde.org
4
www.linux.org / www.linuxworld.com
4
2 Datenerhebung und Analysesoftware
2.1 Datenerhebung
Alle Datensätze wurden zwischen 2006 und 2009 im Rahmen mehrerer von Dr. Lothar
Krempel und Sam Zeini geleiteter Seminare zur sozialen Netzwerkanalyse an der
Universität Duisburg-Essen erhoben (e-Anhang A).
KDE-Mailinglisten-Netze:
Die Daten sind von Sam Zeini aus der KDE-Developer-Core Mailing-Liste
(www.kde.org/mailinglists) erstellt worden. Bei dieser Mailingliste handelt es sich um
die Haupt-Entwicklerplattform von KDE. Der Zeitraum der Kommunikationsdaten
umfasst die kompletten Jahre 2003 bis 2006. Mehrfach vorhandene Namen mit
ähnlicher Schreibweise oder unterschiedlichen E-Mail Adressen wurden unter der
Anwendung des Levenshtein Algorithmus (www.levenshtein.de) zweifacher Iteration,
einmal mit einer Distanz von 2 und einmal einer Distanz von 5, ermittelt und
verschmolzen.
Die Daten liegen als 1-Mode und als 2-Mode-Netze
5
vor. Im 2-Mode-Netz sind Akteure
durch gerichtete Kanten mit Threads
6
verbunden. Der Kantenwert steht dabei für die
Anzahl der Beiträge, die ein Akteur in einem Thread geschrieben hat. Im 1-Mode-Netz
bedeutet eine gerichtete Kante zwischen zwei Akteuren deren Teilnahme an
mindestens einem gemeinsamen Thread. Ein Pfeil eines Akteurs A nach B bedeutet,
dass Akteur A auf B geantwortet hat. Das 1-Mode-Netz existiert mit Zeitstempeln für
Tag, Monat und Jahr, 2-Mode-Netze mit Zeitstempel für Monat und Jahr. Die Netze
unterscheiden sich etwas in ihrer Knotenzahl. Ein Grund dafür ist, dass die 2-Mode-
Netze wegen eines festgestellten technischen Fehlers der Urerhebung 2009 noch
einmal nachträglich erhoben werden mussten. So haben alle 2-mode-Netze 820
Knoten. 1-Mode-Netze hatten ursprünglich 828 Knoten. Für das Monats-Netz wurde
jedoch ein Name (Celeste Paul) per Hand korrigiert, der als Dublette auftrat. Für die
Untersuchungen der Tages und Jahresnetze war diese Korrektur hinsichtlich der
Untersuchungsfragen nicht erforderlich. 1-Mode Netze existieren für Tage und Jahre
mit 828 Knoten, für Monate mit 827 Knoten.
5
In einem 1-Mode-Netzwerk gibt es nur ein Knotenattribut, z.B. jeweils Personen, Themen usw.
Im 2-Mode-Netz sind Knoten verschiedener Attribute vereint (vgl. Breiger 1974).
6
Ein Thread ist ein fortlaufender Strang aus Diskussionsbeiträgen zu einem Thema.
5
SVN Log-Netze:
Diese Daten wurden ebenfalls von Sam Zeini aus den SVN
7
Logs der KDE-
Repositories KDEBase und KDELibs
8
für die 3.5er Release
9
des KDE Projektes
generiert. Die SVN-Nicknames konnten vollständig aufgelöst werden. Es existieren 1-
Mode- und 2-Mode-Datensätze mit Tages- Monats- und Jahres-Zeitstempel.
Credits-Projektgruppen-Datensatz:
Die Daten der Projektgruppenerhebung umfassen eine Erhebung des Autors von KDE-
Mitgliedern, deren Tätigkeitsfelder, Projekt- und Projektfamilienmitgliedschaften,
Vereinszugehörigkeit und amtstätigkeiten sowie einen Vermerk über interviewte
Mitglieder auf der KDE-Webseite www.behindkde.org. Die Daten wurden in Excel
sortiert und dienen als Basis zur Erzeugung diverser Pajek-Netfiles. Auf der Seite
http://docs.kde.org/stable/ findet man die dokumentierten KDE Projektfamilien, denen
jeweils Unterprojekte zugeordnet sind (z.B. KMail der Familie KDEpim). In der
Dokumentation der Projekte sind unter Credits die Namen der Programmierer,
Dokumentatoren, Contributoren und Copyrights aufgelistet. Die meisten dieser KDE-
Familien
und
viele
Projekte
besitzen
zudem
eigene
Webseiten
(z.B.
http://pim.kde.org/). Dort sind wiederum mehrere Namen bestimmten Gruppen oder
Aufgaben zugeteilt, die in den Datensatz einflossen. In den KDE e.V.
Jahreshauptversammlungsprotokollen
(http://ev.kde.org/reports/)
und
einer
Vereinsbroschüre (http://akademy2008.kde.org/conference/slides/kde-ev.pdf) sind für
die
jeweiligen
Zeiträume
Vereinsfunktionäre
dokumentiert.
Die
Seite
http://behindkde.org/people/ enthält Interviews mit ausgewählten KDE-Mitgliedern.
Weiterhin finden sich auf den KDE-Internetseiten die Mitglieder verschiedener Working
Groups und KDE-Repräsentanten von Ländern und Kontinenten. Die Datenerhebung
fand zwischen 01. und 13. Dezember 2007 stattt.
7
Bei SVN handelt es sich um ein Verwaltungssystem, mit dem Open Source-Projekte ihre
Dateien verwalten, http://subversion.tigris.org.
8
KDEbase und KDElibs bezeichnen zu Projektfamilien zusammengefasste KDE-Projekte,
http://www.kde.de/infos/kde_familie.php
9
Bei einem Release handelt sich um eine offizielle Version einer Software.
6
2.2 Verwendete Analysesoftware
Die Analyse der Netzwerkdaten basiert vor allem auf dem Programmpaket Pajek 1.24
10
(http://vlado.fmf.uni-lj.si/pub/networks/pajek/),
ergänzt
durch
UCINET
6
(www.analytictech .com/downloaduc6.htm). Als Generator für Pajek-Netfiles aus der
Exceltabelle der Credits-Projektgruppen-Daten diente das Tool ,,Ecxel2Pajek"
(http://vlado.fmf.uni-lj.si/pub/networks/pajek/howto/excel2pajek.htm). Für Korrelations-
berechnungen wurde auf SPSS 15.0 zurückgegriffen.
10
Für einige Aufbereitungen bietet Pajek keine Funktionen. Dann wurden die Files außerhalb
von Pajek mit Excel bearbeitet. Beispielsweise kann man mit Pajek keine Netze verschiedener
Zeiträume zu einem einzelnen Gesamtnetz zusammenfügen. Die Funktion Union of vertices
stellt Teilnetze lediglich separat nebeneinander in dieselbe Datei. Wo eine Netzvereinigung
nötig war, wurden alle Netze im ersten Schritt mit dieser Pajek-Funktion zusammengeführt.
Anschließend wurde über Excel für dieses Gemeinschaftsnetz eine Partition erstellt, in der jeder
Akteursname seine eigene Partitionsnummer erhielt. Mehrfachnamen standen dann alle in
derselben Partition. Nach Shrinken aller Partitionen in Pajek, fusionierten alle gleich lautenden
Namen und deren Kanten zu jeweils einem gemeinsamen Knoten und das Netz des
gewünschten Zeitraums war erstellt.
7
3 Verwendete Netzwerkanalytische Maßzahlen und Verfahren
Die Folgenden Ausführungen behandeln knapp netzwerkanalytische Konzepte und
Maßzahlen, soweit sie in der Diplomarbeit Verwendung finden. Auf nicht angewandte
Maße und Konzepte wird nicht eingegangen.
Zentralität:
Für die Wichtigkeit von Akteuren kennt die Netzwerkanalyse Zentralitätsmaße. Die hier
verwendeten Zentralitätsmaße sind Degree- und Betweenness-Zentralität (vgl.
Krempel 2005: 75f). Degree-Zentralität zählt alle Verbindungen (Kanten), die ein Akteur
auf sich vereint. Ein Akteur (Knoten) mit einem hohen Wert ist wichtig, weil er viele
direkte Beziehungen besitzt. Indirekte Beziehungen fließen in die Betweenness-
Zentralität als ein Maß für die Vermittlerposition von Akteuren ein. Sie errechnet sich
daraus, wie häufig ein Knoten auf den kürzesten Pfaden zwischen anderen Knoten
passiert werden muss. Ein Akteur ist dann umso wichtiger, je stärker er indirekt
zwischen anderen Akteuren liegt. Je höher der Wert, desto größer ist ggf. die
Informationsmacht. In gerichteten Netzwerken, also solchen, bei denen die Richtung
einer Kante eine Rolle spielt, kann man zwischen eingehenden und ausgehenden
Beziehungen unterscheiden (Indegree und Outdegree).
Dichte:
Die Dichte eines Netzwerkes beschreibt das Verhältnis zwischen der Anzahl der
vorhandenen zu den möglichen Kanten und steht für die Verbundenheit eines Netzes
(vgl. ebd.: 74f). Das Maß eignet sich für den Vergleich von Netzwerken mit gleichen
Knotenzahlen. Bei verschieden großen Netzwerken ist ein Vergleich problematisch. Da
es für viele Akteure weit schwieriger wird, zu allen anderen Kontakt zu halten, sind
kleine Netzwerke oft viel dichter.
Komponenten, k-Cores und Cliquen:
Ein Netzwerk, welches sich in unverbundene Subnetzwerke aufteilt, besteht aus
Komponenten (vgl. ebd.: 75f). Es gibt mehrere Subgruppenkonzepte, die sich
hauptsächlich durch das Kriterium ihrer Verbundenheit unterscheiden (vgl. Trappmann
et al. 2005: 71-96). Das am strengsten definierte ist das der Clique (vgl. ebd.: 71).
Innerhalb einer Clique sind alle Akteure direkt miteinander verbunden und bestehen
8
aus mindestens drei Knoten. Durch Cliquen werden also besonders dichte Gruppen
identifiziert. Weniger streng können Knoten auch zu k-Cores zusammengefasst
werden. Ein k-Core ist ein Subgraph, in dem jeder Akteur mit mindestens k anderen
Akteure des Cores verbunden ist (vgl. Scott 1991: 113-115).
Blockmodelle:
In der sozialen Netzwerkanalyse geht es bisweilen darum, das Verständnis von Netzen
durch Reduktion ihrer Komplexität zu verbessern (vgl. Krempel 2005: 91-102). Ein
Blockmodell ist eine solche reduzierte Abbildung (vgl. Heidler 2006: 6). Jene Akteure,
die ähnliche Beziehungen zu ähnlichen Akteuren haben, werden zu Positionen
zusammengefasst und die Beziehungen der Positionen untereinander in einer Matrix
dargestellt.
Für die Zusammenfassung von Akteuren zu Positionen gibt es verschiedene
Ähnlichkeitskonzepte (vgl. Trappmann et al. 2005: 97). Dahinter steht die Idee, dass
sich Akteure mit ähnlichen Beziehungen auch ähnlich verhalten. Demnach legen nicht
Attribute wie Geschlecht, Alter oder Beruf das Verhalten von Akteuren fest, sondern die
Relation im sozialen Netzwerk (vgl. Heidler 2006: 25). Das hier angewandte Konzept
ist das der strukturellen Ähnlichkeit. Zwei Akteure sind dann strukturell Ähnlich, wenn
sie eine hohe Übereinstimmung an gleichen Verbindungen zu denselben Akteuren
aufweisen (vgl. Trappmann et al. 2005: 102f, 109).
Wurden Akteure zu Positionen zusammengefasst und diese Positionen in eine Matrix
eingetragen, beschreibt die Matrix nicht mehr die Verbindungen der Akteure, sondern
der Positionen. Eine ungerichtete Verbindung von Position 1 zu Position 2 in einer
Blockmodell-Matrix wird das dahingehend interpretiert, dass alle Akteure der Position 1
zu allen Akteuren der Position 2 Beziehungen unterhalten und umgekehrt. Die
Verbindung von Position 1 mit sich selbst bedeutet dann, ein Akteur innerhalb von
Position 1 ist mit allen anderen Akteuren aus Position 1 verbunden. Das ist jedoch ein
Idealfall. In der Realität haben meist mehr oder weniger Akteure einer Position zu mehr
oder weniger Akteuren einer anderen oder derselben Position Kontakte, selten aber zu
allen. Wie entscheidet man, ab welchem Ausmaß an Kontakten zwischen zwei
Positionen eine Verbindung gilt? Eine mögliche Entscheidungshilfe ist das Alpha-
Dichtekriterium (vgl. ebd.: 144). Man schaut sich dazu die Dichten innerhalb der
Blöcke (Zellen der Dichtematrix) an. Erreicht oder übersteigt die Dichte innerhalb eines
Blocks das Alpha-Dichtekriterium, setzt man in die Matrixzelle eine 1 für ,,Verbindung",
9
ansonsten eine 0 für ,,keine Verbindung". Doch welchen Wert legt man für Alpha fest?
Die in dieser Arbeit verwendete Regel ist die, für Alpha die Gesamtdichte des
Netzwerks heranzuziehen (vgl. ebd.). Ist die Dichte in einem Block größer oder gleich
der Gesamtdichte des Netzwerks, wird eine 1, ansonsten eine 0 gesetzt.
Zur Erstellung eines Blockmodells hält UCINET den CONCOR-Algorithmus
(Convergence of iterated correlation) bereit (vgl. Heidler 2006: 61-64, Jansen 2003:
226). Er errechnet Zeilen- und Spalten-Korrelationen einer Beziehungsmatrix und
erstellt daraus eine Korrelationsmatrix. Anschließend korreliert er Zeilen und Spalten
der Korrelationsmatrix. Dies führt er bis zu einem vorher festgelegten Abbruchkriterium
durch (Splittzahl in der Voreinstellung). Das Verfahren wird durchaus kritisiert. Die
mathematische Legitimation für die Korrelation der Korrelation fehle (vgl. ebd.: 63,
Jansen 2003: 227), es führe nicht immer zu Partitionen struktureller Äquivalenz (vgl.
Heidler 2006: 64) und die zu erwartende Anzahl der Cluster lässt sich nicht optimal
voreinstellen (vgl. ebd.: 63). Will man mit UCINET eine CONCOR-Analyse
durchführen, kann man nicht die Anzahl der Blöcke einstellen, die man gern hätte,
sondern nur die Splittiefe. Je tiefer die Splittung, desto strenger werden die Akteure in
verschiedene Ähnlichkeits-Cluster sortiert. Dafür sind die Ergebnisse recht robust (vgl.
Jansen 2003: 227). Hat man das Netzwerk einer CONCOR-Analyse unterzogen, wirft
UCINET eine Dichtematrix aus, anhand der man das Blockmodell entsprechend des
gewählten Dichtekriteriums ableiten kann.
Um mit Pajek eine Blockmodellanalyse durchzuführen, bestimmt man vorher die
Anzahl der Partitionen. Pajek versucht nun, für diese Vorgabe die Bestmögliche
Verteilung der Knoten auf die Partitionen zu finden (vgl. Heidler 2006: 48f). Bei einer
Voreinstellung von drei Partitionen, teilt Pajek die Akteure so gut wie möglich in drei
Gruppen ähnlicher Akteure, auch wenn das Netz optimal eigentlich 4 Partitionen
hergäbe. Ziel ist es, den Determinationskoeffizienten zu maximieren. Pajek versucht,
die quadrierten Abweichungen der Blockwerte vom jeweiligen Blockmittelwert dabei
weitmöglich gering zu halten. Dem Verfahren liegen vier Idealtypen von Blöcken
zugrunde: (1) Keine Position hat zu irgendwem einen Kontakt, (2) alle Positionen
haben zu allen anderen und sich selbst Kontakt, (3) alle Blöcke haben außer zu sich
selbst zu allen anderen Positionen Kontakt, (4) Alle Positionen haben ausschließlich zu
sich selbst Kontakt. Pajek vergleicht nun das Netz auf Inkonsistenzen gegenüber den
Idealtypen. Ein Nachteil des Verfahrens ist, dass die ausgeworfenen Lösungen für
große Netze nicht immer konsistent sind, dass mehrfache Durchläufe also durchaus zu
10
unterschiedlichen Ergebnissen führen können. So sperrt sich das Programm auch
gegen Blockmodellanalysen von Netzwerken mit mehr als 255 Knoten.
Spring Embedder:
Blockmodelle führen zu Informationsverlust. Eine Möglichkeit, Ähnlichkeiten in
komplexen Netzwerken ohne Informationsverlust zu finden, bieten Spring Embedder.
Das sind Algorithmen, welche Knoten visuell nach Beziehungsähnlichkeiten anordnen
(vgl. Krempel 2005: 103f). Knoten, die durch Kanten verbunden sind, werden näher
beieinander, unverbundene weiter entfernt angeordnet. Pajek verfügt über zwei Spring
Embedder Algorithmen: Kamada-Kawai und Fruchtermann-Rheingold. Kamada-Kawai
berechnet Kanten wie mechanische Federn bei abstoßenden und anziehenden Kräften
und optimiert die euklidsche Distanz den Pfaddistanzen schrittweise (vgl. ebd.: 112f,
Pfeffer 2008: 231). Der Algorithmus ist wegen seines hohen Rechenaufwands nur für
Netze bis 1000 Knoten geeignet. Der Fruchtermann-Rheingold-Algorithmus stellt eine
mathematische Verbesserung vor allem für die Rechengeschwindigkeit dar. Knoten
werden von ihren Nachbarn angezogen, aber von allen Knoten auch abgestoßen. Mit
Fruchtermann-Rheingold können sehr große Netze vernünftig geordnet werden.
Teilweise kommt es jedoch zu Überlappungen von Knoten und Kanten, also zu einem
Informationsverlust.
11
4 Die Bedeutung von Reputation in Open Source Projekten
4.1 Bisherige Forschungsergebnisse zur Reputation in Open Source-Projekten
Die Motivationen von Teilnehmern an Open Source-Projekten ist ein gut erforschtes
Feld. Umfragen haben vornehmlich intrinsische
11
Motive für die Teilnahme an Open
Source-Projekten herausgestellt. Unter denen rangiert der Spaß an erster Stelle (vgl.
Brand/Holtgrewe 2007: 29f, Heinrich et al. 2006: 61-64, Luthiger 2004: 103-105, Brand
2002: 17-23). Als sehr bedeutsames extrinsisches Motiv erweist sich das Streben nach
Reputation innerhalb der Community. Indirekt sind damit auch monetäre Ziele
verbunden, denn wer sich
,,beispielsweise in einem Credits File eines Open-Source-Projekts Erwähnung
findet, empfiehlt sich quasi selbst als guter Entwickler für eine feste Anstellung."
(Heinrich et al. 2006: 61).
Reputation scheint darüber hinaus als innerer Koordinationsmechanismus zu
fungieren. Brand/Schmidt (2005: 8) sehen für KDE eine Reputationshierarchie
gegeben, in der teilnehmende Akteure durch Leistung aufsteigen:
,,Machtbeziehungen entstehen in Netzwerken durch das Verschenken [...] die
Rückgabe wird auf einen unbestimmten, zukünftigen Zeitpunkt verlegt,
weswegen der Schenkende durch wiederholte Gabe den Beschenkten von ihm
abhängig machen kann." Schenken erzeugt ,,symbolisches Kapital, da über
Schenken Reputation aufgebaut wird und zu einem Statusunterschied führt. Die
Macht entsteht also in einem Open Source Projekt durch Geschenke bzw. über
erstellte Leistungen."
Im Zusammenhang mit der Bedeutsamkeit einer kleinen Minderheit mit großem Anteil
am Kommunikationsaufkommen und der Produktion sei daraus auf eine
11
,,Intrinsisch [...] bezeichnet [...] eine Motivation, die von innen heraus durch ein starkes
persönl. Interesse an Erkenntnisgewinn, Wissenserweiterung, an bestimmten Lehrstoffen,
Lehrvorgängen, Aufgabenbewältigungen u. Problemlösungen [...] zu Lernerfolgen führt. Extrins.
ist dagegen eine Motivation, die erst durch äußere, nicht ,in der Sache' liegende Anreize und
Bedingungen wie Belohnungen, Strafen, Zwänge, Identifikation mit einem Vorbild [...]
hervorgebracht u. angetrieben wird." (Hillmann 1994: 391f)
12
Reputationshierarchie zu schließen (vgl. ebd.). KDE-Gründer Matthias Ettrich (2004:
181) erklärt es ähnlich:
,,einige übernehmen automatisch eine Führungsrolle in einem gewissen
Bereich, getrieben vom Charakter und gestützt auf durch Arbeit und Wissen
erworbenen Respekt der Mitmenschen."
Brand/Holtgrewe (2004: 25) bestätigen diese Selbstbeschreibung für KDE:
,,Zusammengefaßt ist der Einstieg in das Open Source-Projekt ein gestufter
Eintritt. Erst muß sich bei den Entwicklern die Schreibberechtigung für die
Dateiablage verdient werden. Nachdem man die erste relativ einfache Hürde
genommen hat, kommt der schwierige Aufstieg in den inneren Kreis des
Projekts. Bei diesem Aufstieg muß durch ständige Mitarbeit Reputation
erworben werden, um im inneren Kreis anerkannt zu sein. Dabei ist die
Reputation das Selektionskriterium, nach dem die Projektbeteiligten ihren
sozialen Status in dem Großprojekt festlegen."
Schon der Urvater des pragmatischen Open Source-Ansatzes, Eric S. Raymond
(2000), sah im Aufbau einer funktionierenden Reputationsökonomie den wesentlichen
Grund, wieso das Linuxmodell Linus Torvalds überhaupt funktionieren konnte:
"We may view Linus's method as a way to create an efficient market in `egoboo'
to connect the selfishness of individual hackers as firmly as possible to difficult
ends that can only be achieved by sustained cooperation."
So fragt Raymond (ebd.) angesichts der ausgiebigen, aber eigentlich ungeliebten
Programm-Dokumentierung innerhalb von Open Source ironisch:
"It is a hallowed given that programmers hate documenting; how is it, then, that
Linux hackers generate so much documentation?"
13
4.2 Tätigkeitsbezogener Reputationserwerb
Wenn Credits in Dokumentationen Reputation anzeigen, dann sollten sich in einem aus
den Credits erhobenen Netzwerk Reputationstendenzen ablesen lassen. Als Indikator
für Reputation werden hier Ämter (Board, Working Groups, Representatives), die
Vereinsmitgliedschaft in KDE e.V.
12
und das Auftauchen auf der Interview-Webseite
www.behindkde.org für ausgewählte Mitglieder angenommen. Akteure, die einen
dieser Punkte erfüllen, erhalten im Netzwerk eine Kante zu einem Prestige-Knoten.
Dieser Knoten wird in ein Netzwerk aus Akteuren und deren Haupttätigkeitsfeldern
gesetzt:
Abbildung 4.1: Zugehörigkeit von Akteuren zu Tätigkeitsfeldern und Prestigeindikatoren,
Anordnung mit Spring Embedder. (Pajekfile: 401.paj)
.
Starke Nähe bedeutet hier, dass zwei Tätigkeitsfelder in Relation gesehen viele
Akteure gemeinsam haben, sich also diese mit sonst keinen oder annähernd keinen
anderen Tätigkeitsfeldern teilen. Programming- und Documentation-Knoten besitzen
die meisten gemeinsamen Akteure (139 Akteure gegenüber 125 gemeinsamen
Akteuren von Programming und Contribution) und die meiste Ähnlichkeit hinsichtlich
ihrer Akteure. Von 412 Programmierern im Projektnetz haben 139 (34%) auch
Dokumentationen geschrieben. Dazu kommen reine Dokumentations-Tätigkeiten,
12
Vereinsmitgliedschaften werden selektiv nach Empfehlung vergeben (vgl. KDE-
Vereinssatzung 2006).
14
welche den Programmierern Dokumentationsarbeit abnehmen. Das Projektnetz
umfasst 217 dokumentierte Einzelprojekte (Anhang CI). 241 Personen waren daran als
Dokumentatoren beteiligt. Man kann durchaus einen beachtlichen Personal- und
Arbeitsaufwand für die ungeliebte Dokumentationspflege vermuten. Die Masse sagt
freilich nichts über die Qualität aus. Gerade die wird öfters kritisiert (vgl. Oppliger 2003,
Glaser 2004, Aschoff 2007). Vor dem Hintergrund einer Reputationsökonomie wäre
das erklärlich, ginge es den Beteiligten doch mehr um die Credits als um den
Anwendernutzen an sich.
Tätigkeit
Akteure nur einer
Tätigkeit
davon Reputationsträger
%
Programmieren
Dokumentatoren
Contributor
Übersetzer
193
79
355
164
31
8
3
21
16%
10%
6%
2%
Tabelle 4.1: Anteil der Reputationsträger an Akteuren, welche jeweils in nur einem einzigen
Tätigkeitsfeld Credits erzeugt haben.
Programmieren ist das Tätigkeitsfeld, welches ausschließlich ausgeübt, am häufigsten
mit Prestige verbunden war. Obwohl es sich beim Übersetzen und Dokumentieren
gleichermaßen um Schreibtätigkeiten handelt, die keine Programmierkenntnisse
erfordern, gelangten Übersetzer weit seltener zu Prestige. Vermutlich, weil
Dokumentatoren die eigentlichen Prestigeträger, die Programmierer, entlasten und
dafür belohnt werden. So räumt Ex-SuSE
13
-Vorstand Dirk Hohndel (2004) ein:
,,Es ist leicht, Leute zu finden, die genialen Code schreiben. Es ist schwierig,
Leute zu finden, die bereit sind, diesen genialen Code auch für den Anfänger
lesbar zu dokumentieren."
Eine Reihe von Prestigeträgern in Abbildung 4.1 tauchten überhaupt nicht in den
Credits auf, es muss also noch Wege außerhalb der Creditverdienste geben, um
Reputation zu erwerben.
In Abbildung 4.2 erhielten zwei Akteure desselben Tätigkeitsfeldes eine Kante, wenn
sie an mindestens einem gemeinsamen Projekt teilnahmen. Übersetzer weisen die
stärkste Vernetzung auf. Im Gegensatz zu anderen Tätigkeiten, gibt es bei ihnen kaum
Einzelkomponenten oder isolierte Akteure. Ein Übersetzer kann im Prinzip jedes
13
SuSE (früher SUSE Linux und SuSE, heute openSUSE) ist ein Gemeinschaftsprojekt zur
Verbreitung des Open Source Betriebssystems Linux; www.opensuse.org.
15
Projekt übersetzen, ob er damit vertraut ist oder nicht. Für einen Programmierer ist
dagegen eine gewisse Vertrautheit zum konkreten Quelltext notwendig. Das
beschränkt seine Verknüpfung zu verschiedenen Projekten. Daher überrascht die
stärkere Vernetzung der Übersetzer erst einmal wenig. Doch warum sind
Dokumentatoren nicht ähnlich engmaschig vernetzt, wo sie doch ebenso wenig
projektabhängiges Spezialwissen benötigen? Die Vermutung, dies läge daran, dass
Dokumentationen zum Teil von Programmierern geschrieben werden und damit
indirekt eher projektgebunden sind, wird durch die Vernetzung jener Dokumentatoren
ausgeräumt, welche keiner Programmiertätigkeit nachgehen (Abb. 4.3). Auch deren
Vernetzung ergibt viele Komponenten und Isolierte.
Im Projektnetz
Im Familiennetz
Programmierer
Contributors
Dokumentatoren
Übersetzer
Abbildung 4.2: Vernetzung der Akteure über gemeinsame Teilnahme an Projekten. (Pajekfile:
402.paj)
16
Abbildung 4.3: Vernetzung von Dokumentatoren, die keine Programmier-Credits aufwiesen.
(Pajekfile: 403.net)
Vom Standpunkt einer Reputationsökonomie ließe sich das erklären. Übersetzungen
generieren weniger Reputation und die Übersetzer wären bestrebt, dieses Defizit durch
breitere Aktivität auszugleichen. Hinzu kommt, Übersetzungstätigkeiten überschneiden
sich weniger mit anderen Tätigkeiten (Tab. 4.2). Den Übersetzern stünden somit
seltener Reputationsquellen zur Verfügung als den Dokumentatoren und sie könnten
danach streben, auch dieses Manko wiederum durch eine breitere Aktivität
auszugleichen
.
Gesamt Contribution Programmierern Dokumentieren Übersetzen
Contributor
511
355
126
64
32
Developer
412
126
192
140
23
Documentator
241
64
140
79
24
Translator
212
32
23
24
164
Tabelle 4.2: Überschneidungsmatrix der Tätigkeitsfelder.
4.3 Projektbezogener Reputationserwerb
Gibt es bestimmte Projekte, die prestigeträchtiger sind als andere? In Abbildung 4.4
wurden Akteure mit Projektfamilien
14
verbunden. Aus dem Netz werden alle
Prestigeträger ohne Projekte gelöscht, da nur die Frage nach dem Verhältnis der
Projekte zum Prestige steht, nicht des Prestiges zu den Projekten.
14
Projektfamilien
sind
von
KDE
thematisch
zusammengefasste
Projektgruppen:
http://www.kde.de/infos/kde_familie.php
17
Abbildung 4.4: Akteure und deren Zugehörigkeit zu KDE-Projektfamilien sowie zu
Prestigeindikatoren. (Pajekfile: 404.net)
Offenbar gibt es Projektfamilien mit mehr, andere mit weniger Affinität zu
Prestigeträgern. KDE Edutainment (kdeedu) bietet Lernprogramme und kleine Spiele
an.
15
Es handelt sich vor allem um kleine, wenig arbeitsteilige Programme mit einer
vergleichsweise untergeordneten Rolle für das Gesamtprojekt. KDevelop hingegen
gehört zu den größten und arbeitsteiligen Unterprojekten von KDE. KDevelop
unterstützt
KDE
Nutzer
bei
der
Entwicklung
eigener
Anwendungen
(www.kdevelop.org). Beide Projekte haben somit eine gewisse Brückenfunktion für
Neueinsteiger, was die vielen Akteure erklären mag, die sich ausschließlich in einem
dieser Projekte aufhalten. KDevelop erleichtert Endanwendern den Zugang zum
Entwicklerstatus und KDE Edutainment bietet eine Anlaufstelle für kleine autarke
Erstlings-Programme. KDEBase hingegen ist als Kern der Bibliotheken technisch
entscheidend und anspruchsvoll. Entsprechend nahe liegen die Prestigeträger
positioniert, was die Selbstbeschreibung der Community als Meritokratie stützt (Ettrich
2004: 181).
15
KDE-Komponentenbeschreibung unter: http://docs.kde.org/stable/en/kdebaseruntime/
userguide/kde-edutainment.html
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Erscheinungsjahr
- 2009
- ISBN (eBook)
- 9783836645607
- Dateigröße
- 1.3 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Universität Duisburg-Essen – Gesellschaftswissenschaften, Sozialwissenschaften
- Erscheinungsdatum
- 2014 (April)
- Note
- 1,2
- Schlagworte
- netzwerkanalyse open source soziologie internet
- Produktsicherheit
- Diplom.de
