Andreas Brand: Die Struktur, Eintritt, Leistungserstellung, Motivation und Kontrolle in einem Open Source-Projekt
Paper fr einen Vortrag auf dem Linuxtag, 10.-13. Juli
|
Kontakt: Dipl.
Soz. Andreas Brand Project
electronic labourmarkets (PELM) / Projekt elektronische Arbeitsm舐kte Johann
W. v. Goethe Universit舩 / Johann W. v. Goethe University Institut
fr Polytechnik und Arbeitslehre / Institute for polytechnic and
laboursciences Email: A.Brand@em.uni-frankfurt.de Url:
http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html |
Struktur:
Innere Struktur von
KDE:
Bei diesem Open Source-Groﾟprojekt handelt es sich um eine weltweit verteilte Gruppe von ca. 800-1000 Menschen (ca. 800 cvs-accounts ohne den Groﾟteil der ﾜbersetzer), die vor allem aus Europa, besonders Deutschland, kommen. Die meisten Projektbeteiligten kommen aus dem Kerneuropa, d.h. D, F, GB, Benelux, und einige aus USA/Kanada.
Es existieren aber auch regionale Cluster, wie z.B. in Nrnberg/Erlangen. Die Gruppe ist recht homogen, da der grte Teil der Personen m舅nlich und zwischen 20 und 30 Jahren alt ist. Ein groﾟer Teil der Projektbeteiligten sind Studenten, ein anderer groﾟer Teil sind Erwerbst舩ige. Gemeinsam ist der berw舁tigenden Mehrheit, daﾟ sie entweder eine IT-Studium oder IT-Ausbildung absolviert oder absolviert hat. Schler, Lehrlinge, Arbeitslose und Erwerbst舩ige aus anderen Bereichen bilden dagegen eine Minderheit. Z.T. gibt es auch mitarbeitende wissenschaftlich T舩ige und Projektbeteiligte, die sich selbst舅dig gemacht haben und Dienstleistungen um das Open Source-Projekt anbieten.
Alle arbeiten freiwillig, als Hobby, an der gemeinsamen Erstellung eines Desktops. Es gibt verschiedene T舩igkeitsbereiche in der Open Source-Community, wovon die Softwareentwickler und die Dokumentierer/ ﾜbersetzer, die wichtigsten sind. Die Softwareentwickler stellen zwei Drittel, die Dokumentierer/ ﾜbersetzer ca. ein Drittel und andere T舩igkeiten, wie z.B. Homepagepflege, Graphik-/Sounderstellung, nur ca. 5 %.
Die wichtigsten Werkzeuge stellen die Mailinglisten fr die Kommunikation und das Dateiablagesystem fr die Produktion dar. Das Open Source-Projekt besteht einerseits aus wenigen wichtigen und zentralen Unterprojekten, andererseits aus vielen kleinen Ein-Personen-Subprojekten.
ﾄuﾟere Struktur bzw.
Einbettung von KDE:
Die Umwelt des Groﾟprojekts besteht einerseits aus anderen Open Source-Projekten, Unternehmen und Endanwendern. Es gibt Konflikte zwischen der Umwelt des Groﾟprojekts und dem Groﾟprojekt selbst. Konflikte zwischen verschiedenen Open Source-Projekten sind selten, aber wenn sie auftreten, geht es um die normativen Grundlagen der allgemeinen Open Source-Community, wie dem konkreten Umgang mit den Lizenzen. Die guten Beziehungen zu anderen Open Source-Projekten werden durch die Nutzung von Werkzeugen dieser Projekte im Groﾟprojekt untermauert. Weit mehr normative Konflikte um die Anwendung der Lizenz des Groﾟprojekts gibt es zwischen dem Groﾟprojekt und Unternehmen, wobei sich die Konfliktthemen um die ﾜbernahme, Ver舅derung und Verkauf von Quellcode sowie um die Reputation durch copyright-Vermerke drehen.
Funktionsweise:
Eintritt:
Aufmerksam auf das Projekt wurden viele durch die Nutzung einer Linux-Distribution, Freunde und Computer-Zeitschriftenartikel. Am Anfang des Projekts wurde aber vor allem ber Mailinglisten und Usenet-Foren geworben. Das Projekt existiert seit 1996, die meisten sind aber erst 1999 bis 2002 eingetreten.
Der Eintritt in die Community erfolgt nach dem Signalisieren von Interesse an der Mitarbeit durch Zusenden von kleinen Quellcodever舅derungen. Nach mehrmaligem Zusenden erhalten die Neulinge die Schreibberechtigung fr das Dateiablagesystem. Dies erfolgt relativ schnell, im Rahmen von 0,5 bis 1 Jahr.
Der Eintritt ist dabei als ein Selbstselektionsprozeﾟ zu sehen, wobei die Selbstmotivation eine groﾟe Rolle spielt. Nach dem Eintritt besteht die Mlichkeit durch Reputation in den inneren Kreis aufzusteigen. Der innere Kreis ist eine schwer abgrenzbare Gruppe von Personen, die sich um das Projekt verdient gemacht und deswegen Reputation bzw. sozialen Status erlangt haben. Die Reputation besteht aus verschiedenen Elementen, wie Seniorit舩/ Erfahrung, kontinuierliche Leistung, freundlichem/kooperativen Umgang und Sichtbarkeit. Freiwillige Austritte erfolgen durch die Hinwendung zu anderen Aufgaben, wie Familie oder Erwerbsarbeit, Zwangsaustritte durch das ﾜbertreten von wichtigen Normen, wie z.B. das unabgesprochene Lchen von Quellcode.
Es gibt eine operative und eine strategische Entscheidungsebene, wobei sich die operative um die konkrete Softwareerstellung und die strategische um rechtliche Probleme und vision舐e Ziele dreht. Die strategische Ebene wird von den Personen aus dem inneren Kreis vertreten, die sich Reputation erworben haben.
Die Produkterstellung steht in dem Open Source-Projekt im Mittelpunkt. Die Softwareentwicklung erfolgt normalerweise in einem Versuch und Irrtums-Prozeﾟ, wobei derjenige ber seine Arbeit entscheidet, der die Arbeit macht.
Dabei wird konkret entweder ohne anf舅gliche Skizzen bzw. andere formale Hilfsmittel sofort programmiert oder sich vorher im Kopf beim Sport ein mlicher Lungsweg ausgedacht. Nur eine Minderheit entwirft vorher ein formales Modell, das sp舩er programmiert wird. Damit f舁lt die Leistungserstellung und die Arbeitsverteilung zusammen.
Die Arbeitszeit ist sehr heterogen und stark gespreizt, zwischen ein paar Minuten und 14 Stunden pro Tag, d.h. ca. 0,5 und ca. 90 Stunden pro Woche. Im Mittel wird zwischen 2-3 Stunden pro Tag fr das Projekt aufgewendet. Es wird vor allem w臧rend der Freizeit gearbeitet, wenn man von den Personen absieht, die fr die Arbeit an dem Projekt von projektnahen Unternehmen, wie Distributoren, angestellt wurden. Probleme bestehen deswegen vor allem mit dem Partner und der Familie wegen des zeitaufwendigen Hobbys.
Die meisten gaben an, bei 1 bis 4 Projekten mitzuarbeiten. Der Median lag dabei bei 2 Projekten. Die durchschnittliche Personenzahl sind 3-4 Personen pro Subprojekt. Bei der maximalen Zahl liegt der Durchschnitt eher bei 6-8 Personen. Vereinzelt knen Subprojekte mit ber 10-20 Personen auftreten. Die Personen aus dem inneren Kreis gaben an, bei Projekten mit mehr Personen als der durchschnittlich mitzuarbeiten. Auﾟerdem sind die Personen aus dem inneren Kreis an mehr Subprojekten beteiligt als die anderen Projektbeteiligten.
Die Arbeitsaufteilung erfolgt ber die freiwillige ﾜbernahme von Arbeiten, wobei ein Projektkoordinator mit Mitarbeitern sein Projekt berwacht. Bei der Arbeitsverteilung werden Absprachen zwischen den Subprojektmitarbeitern getroffen, wobei Vertrauen zur Einhaltung der Absprache eine wichtige Rolle bei dem Open Source-Projekt spielt. Der Projektkoordinator ist fr die Fehlerlosigkeit seines Projekts verantwortlich. Vom Projektkoordinator wird z.T. die weitere Bearbeitung seines Projekts erwartet. Entscheidungen ber die ﾜbernahme von Quellcode oder die weitere Entwicklung des Projekts werden im Konsens gef舁lt. Allgemein ist die Zustimmung zu einer Mitsprachemlichkeit im Subprojekt hoch. Doch gibt es eine Tendenz, daﾟ Projektleiter und Personen aus dem inneren Kreis eine eher here Mitsprachemlichkeit angeben als die Personen, die nur Beteiligt sind.
Der Projektkoordinator hat dabei keine besonderen Machtbefugnisse. Nur Projektbeteiligte aus dem inneren Kreis genieﾟen wegen ihrer hohen Reputation besonderen Einfluﾟ und Vertrauen. Bei Konflikten wird von diesen eine Schlichtung erwartet.
Die gemeinsame Arbeit wird in einem Release zusammengefhrt. Es gibt eine offizielle Verfentlichung, den Release, der nach einem koordinierenden Releaseplan herausgegeben wird. Zust舅dig fr die Kontrolle dieses Plans und fr die ﾜbernahme von stabilen Programmen ist der Releasekoordinator, der diesen speziellen, koordinierenden Posten fr den inneren Kreis bernimmt.
Es sind monet舐e und nicht-monet舐e Motivationsgrnde zu unterscheiden. Die monet舐en Grnde existieren, da Personen fr die Arbeit an dem Open Source-Projekt angestellt wurden (vergleichbar Sponsoring des Projekts). Andererseits bekommen die Projektbeteiligten Werbegeschenke und Ger舩e auf dem neuesten technologischen Stand ausgeliehen, was dem Sponsoring von Einzelpersonen gleichkommt. Einige gaben an, kurzzeitig monet舐e Gratifikationen fr bestimmte Arbeiten von projektnahen Firmen bekommen zu haben. Manche bekommen fr Arbeiten um das Projekt, wie Vortr臠e und Zeitschriftenartikel Geld.
Die nicht-monet舐en Motivationsgrnde berwiegen aber in diesem Projekt. Die Motivation der Projektbeteiligten setzt sich aus einer Mischung intrinsischer und extrinsischer Elemente zusammen. Intrinsische Motivationen sind eigene Probleme zu len oder der Spaﾟ am Programmieren. Diese Motivationsgrnde wurden von einer groﾟen Mehrheit als wichtig bezeichnet. Die extrinsische Motivation ist u.a. auf die Community und ihrer kooperativen Kultur bezogen. Dazu z臧len soziale Anerkennung (Reputation) und gegenseitige Hilfe. Diese Motivationsgrnde werden auch von einer Mehrheit fr wichtig erachtet. Konflikte knen dabei einerseits die Motivation im Projekt durch Beleidigungen senken, aber andererseits durch das wecken von Ehrgeiz erhen. Die zuknftigen Arbeitsplatzmlichkeiten stellen auch einen Motivationsgrund dar.
Die perslichen Treffen stellen eine wichtige Motivationsquelle dar. Die Personen, die schon l舅ger am Projekt beteiligt sind (innerer Kreis), haben schon andere Projektbeteiligte getroffen. Die Treffen erfolgen vor allem auf Linux-Konferenzen, seltener auf projektbezogenen Programmiertreffen, wie vor groﾟen Releases, oder wegen r舫mlicher N臧e.
Mit der Motivation h舅gen auch die Hobbies zusammen, da das Projekt als zeitaufwendiges Hobby angesehen wird. Es gibt eine Fraktion die generell technikfasziniert ist. Es knen zwei Lager ausgemacht werden: das erste verwendet das Programmieren zum Abschalten und das zweite , bei dem die Personen keinen Computer mehr sehen knen. Sonst f舁lt nur auf, daﾟ die Hobbys stark gestreut sind. Das Lesen von Comics, Science-Fiction- oder Fantasybcher ist und sportliche Hobbys sind verbreitet.
Die Kontrolle der Arbeit im Open Source-Projekt l舫ft ber die Kontrolle der Qualit舩 des Quellcodes. Dies erfolgt auf der operativen Ebene. Die Qualit舩 wird durch Selbstkontrolle durch gleichzeitige Nutzung der Software, stichprobenartigen Kontrollen durch Projektkoordinatoren und den Einbezug der Endnutzer ber ein Fehlerberichtsystem erht. Es besteht dabei ein Konflikt zwischen der selbstbestimmten Arbeitsweise und der Endnutzerorientierung der Community, was sich in kleineren Streitigkeiten entl臈t. Auf der strategischen Ebene kontrolliert der innere Kreis die Einhaltung von Normen bei der Produktion, Kommunikation und Nutzung der gemeinsamen Software. Dabei ist der innere Kreis fr die Einheit des Groﾟprojekts bzw. fr das einheitliche Auftreten zust舅dig.
Es kristallisieren sich drei Kan舁e fr Stquellen heraus. Erstens gibt es Konflikte bei der Kommunikation, d.h. auf den Mailinglisten, aber auch beim Chatsystem. Hier sind die meisten Stungen zu finden. Stungen von Projektbeteiligten werden verbal geahndet, projekt-externe Stungen werden blicherweise ignoriert. Zweitens gibt es bei der Nutzung von Quellcode hin und wieder Konflikte und Probleme mit Trittbrettfahrern, die sich um die GPL-Lizenz drehen. Dies wird normalerweise bei Firmen durch schlechte Publicity geahndet. Drittens kommen Stungen bei der Leistungserstellung im Dateiablagesystem selten vor. Dies wird durch Zurckspielen des vorherigen Quellcodes und u.U. Sperrung des Zugangs sanktioniert.
Es gibt bei den kommunikativen Konflikten mehrere Themenbereiche, die ters auftreten. Der erste Bereich, der am h舫figsten Auftritt, ist ber Konflikte bei der zuknftigen Entwicklung des Groﾟprojekts und der Subprojekte. Im zweiten Bereich, der seltener auftritt, kommen folgende Konfliktgrnde vor: Nichtbeachtung von Beitr臠en, Ablehnung von eingereichtem Quellcode (z.B.: patches), Lchen oder Ver舅dern von Quellcode, Qualit舩 von programmiertem Code/ﾜbersetzung/Dokumentation und Art der Kommunikation. Ganz selten bis nie treten die Konfliktarten Aufgabenverteilung, (verkannte) Anerkennung fr geschriebenen Quellcode, Selbstbersch舩zung der eigenen Leistung und Anspruchshaltung auf.