Andreas Brand: Die Struktur, Eintritt, = Leistungserstellung, Motivation und Kontrolle in einem Open Source-Projekt
Paper f=FCr einen Vortrag auf dem Linuxtag, 10.-13. = Juli
|
Kontakt: Dipl.
Soz. Andreas Brand Project
electronic labourmarkets (PELM) / Projekt elektronische =
Arbeitsm=E4rkte Johann
W. v. Goethe Universit=E4t / Johann W. v. Goethe =
University Institut
f=FCr Polytechnik und Arbeitslehre / Institute for polytechnic and
laboursciences Email: =
A.Brand@em.uni-frankfurt.de Url:=A0=A0
=
http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html<=
/span> |
Struktur: =
Innere =
Struktur von
KDE:
Bei diesem Open Source-Gro=DFprojekt handelt es = sich um eine weltweit verteilte Gruppe von ca. 800-1000 Menschen (ca. 800 = cvs-accounts ohne den Gro=DFteil der =DCbersetzer), 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 N=FCrnberg/Erlangen. Die Gruppe ist recht homogen, da der gr=F6=DFte = Teil der Personen m=E4nnlich und zwischen 20 und 30 Jahren alt ist. Ein gro=DFer = Teil der Projektbeteiligten sind Studenten, ein anderer gro=DFer Teil sind = Erwerbst=E4tige. Gemeinsam ist der =FCberw=E4ltigenden Mehrheit, da=DF sie entweder eine = IT-Studium oder IT-Ausbildung absolviert oder absolviert hat. Sch=FCler, Lehrlinge, Arbeitslose und Erwerbst=E4tige aus anderen Bereichen bilden dagegen = eine Minderheit. Z.T. gibt es auch mitarbeitende wissenschaftlich T=E4tige = und Projektbeteiligte, die sich selbst=E4ndig 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=E4tigkeitsbereiche in = der Open Source-Community, wovon die Softwareentwickler und die Dokumentierer/ =DCbersetzer, die wichtigsten sind. Die Softwareentwickler stellen zwei = Drittel, die Dokumentierer/ =DCbersetzer ca. ein Drittel und andere = T=E4tigkeiten, wie z.B. Homepagepflege, Graphik-/Sounderstellung, nur ca. 5 %.
Die wichtigsten Werkzeuge stellen die Mailinglisten = f=FCr die Kommunikation und das Dateiablagesystem f=FCr die Produktion dar. Das = Open Source-Projekt besteht einerseits aus wenigen wichtigen und zentralen Unterprojekten, andererseits aus vielen kleinen = Ein-Personen-Subprojekten.
=C4u=DFere =
Struktur bzw.
Einbettung von KDE:
Die Umwelt des Gro=DFprojekts besteht einerseits = aus anderen Open Source-Projekten, Unternehmen und Endanwendern. Es gibt Konflikte = zwischen der Umwelt des Gro=DFprojekts und dem Gro=DFprojekt 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=DFprojekt untermauert. Weit mehr normative Konflikte um die = Anwendung der Lizenz des Gro=DFprojekts gibt es zwischen dem Gro=DFprojekt und = Unternehmen, wobei sich die Konfliktthemen um die =DCbernahme, Ver=E4nderung 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 =FCber 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=E4nderungen. Nach mehrmaligem Zusenden erhalten die = Neulinge die Schreibberechtigung f=FCr das Dateiablagesystem. Dies erfolgt relativ = schnell, im Rahmen von 0,5 bis 1 Jahr.
Der Eintritt ist dabei als ein = Selbstselektionsproze=DF zu sehen, wobei die Selbstmotivation eine gro=DFe Rolle spielt. Nach dem = Eintritt besteht die M=F6glichkeit 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=E4t/ Erfahrung, kontinuierliche Leistung, freundlichem/kooperativen Umgang = und Sichtbarkeit. Freiwillige Austritte erfolgen durch die Hinwendung zu anderen Aufgaben, = wie Familie oder Erwerbsarbeit, Zwangsaustritte durch das =DCbertreten von = wichtigen Normen, wie z.B. das unabgesprochene L=F6schen 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=E4re 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=DF, wobei derjenige =FCber seine Arbeit entscheidet, der = die Arbeit macht.
Dabei wird konkret entweder ohne anf=E4ngliche = Skizzen bzw. andere formale Hilfsmittel sofort programmiert oder sich vorher im Kopf = beim Sport ein m=F6glicher L=F6sungsweg ausgedacht. Nur eine Minderheit = entwirft vorher ein formales Modell, das sp=E4ter programmiert wird. Damit f=E4llt 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 f=FCr das = Projekt aufgewendet. Es wird vor allem w=E4hrend der Freizeit gearbeitet, wenn = man von den Personen absieht, die f=FCr 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 k=F6nnen Subprojekte mit =FCber 10-20 Personen = auftreten. Die Personen aus dem inneren Kreis gaben an, bei Projekten mit mehr = Personen als der durchschnittlich mitzuarbeiten. Au=DFerdem sind die Personen aus dem = inneren Kreis an mehr Subprojekten beteiligt als die anderen = Projektbeteiligten.
Die Arbeitsaufteilung erfolgt =FCber die = freiwillige =DCbernahme von Arbeiten, wobei ein Projektkoordinator mit Mitarbeitern sein Projekt =FCberwacht. 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 f=FCr die Fehlerlosigkeit seines Projekts verantwortlich. Vom Projektkoordinator wird z.T. die weitere Bearbeitung seines Projekts = erwartet. Entscheidungen =FCber die =DCbernahme von Quellcode oder die weitere = Entwicklung des Projekts werden im Konsens gef=E4llt. Allgemein ist die Zustimmung = zu einer Mitsprachem=F6glichkeit im Subprojekt hoch. Doch gibt es eine Tendenz, da=DF Projektleiter und = Personen aus dem inneren Kreis eine eher h=F6here Mitsprachem=F6glichkeit angeben = als die Personen, die nur Beteiligt sind.
Der Projektkoordinator hat dabei keine besonderen Machtbefugnisse. Nur Projektbeteiligte aus dem inneren Kreis genie=DFen = wegen ihrer hohen Reputation besonderen Einflu=DF und Vertrauen. Bei = Konflikten wird von diesen eine Schlichtung erwartet.
Die gemeinsame Arbeit wird in einem Release = zusammengef=FChrt. Es gibt eine offizielle Ver=F6ffentlichung, den Release, der nach einem koordinierenden Releaseplan herausgegeben wird. Zust=E4ndig f=FCr die = Kontrolle dieses Plans und f=FCr die =DCbernahme von stabilen Programmen ist der Releasekoordinator, der diesen speziellen, koordinierenden Posten f=FCr = den inneren Kreis =FCbernimmt.
Es sind monet=E4re und nicht-monet=E4re = Motivationsgr=FCnde zu unterscheiden. Die monet=E4ren Gr=FCnde existieren, da Personen f=FCr = die Arbeit an dem Open Source-Projekt angestellt wurden (vergleichbar Sponsoring des Projekts). Andererseits bekommen die Projektbeteiligten Werbegeschenke = und Ger=E4te auf dem neuesten technologischen Stand ausgeliehen, was dem = Sponsoring von Einzelpersonen gleichkommt. Einige gaben an, kurzzeitig monet=E4re Gratifikationen f=FCr bestimmte Arbeiten von projektnahen Firmen = bekommen zu haben. Manche bekommen f=FCr Arbeiten um das Projekt, wie Vortr=E4ge und Zeitschriftenartikel Geld.
Die nicht-monet=E4ren Motivationsgr=FCnde = =FCberwiegen aber in diesem Projekt. Die Motivation der Projektbeteiligten setzt sich aus = einer Mischung intrinsischer und extrinsischer Elemente zusammen. Intrinsische Motivationen sind eigene Probleme zu l=F6sen oder der Spa=DF am = Programmieren. Diese Motivationsgr=FCnde wurden von einer gro=DFen Mehrheit als wichtig bezeichnet. Die extrinsische Motivation ist u.a. auf die Community und = ihrer kooperativen Kultur bezogen. Dazu z=E4hlen soziale Anerkennung = (Reputation) und gegenseitige Hilfe. Diese Motivationsgr=FCnde werden auch von einer = Mehrheit f=FCr wichtig erachtet. Konflikte k=F6nnen dabei einerseits die Motivation im = Projekt durch Beleidigungen senken, aber andererseits durch das wecken von = Ehrgeiz erh=F6hen. Die zuk=FCnftigen Arbeitsplatzm=F6glichkeiten stellen auch = einen Motivationsgrund dar.
Die pers=F6nlichen Treffen stellen eine wichtige Motivationsquelle dar. Die Personen, die schon l=E4nger 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=DFen Releases, oder wegen r=E4umlicher N=E4he.
Mit der Motivation h=E4ngen auch die Hobbies = zusammen, da das Projekt als zeitaufwendiges Hobby angesehen wird. Es gibt eine Fraktion die = generell technikfasziniert ist. Es k=F6nnen zwei Lager ausgemacht werden: das = erste verwendet das Programmieren zum Abschalten und das zweite , bei dem die Personen = keinen Computer mehr sehen k=F6nnen. Sonst f=E4llt nur auf, da=DF die Hobbys = stark gestreut sind. Das Lesen von Comics, Science-Fiction- oder Fantasyb=FCcher ist = und sportliche Hobbys sind verbreitet.
Die Kontrolle der Arbeit im Open Source-Projekt = l=E4uft =FCber die Kontrolle der Qualit=E4t des Quellcodes. Dies erfolgt auf der = operativen Ebene. Die Qualit=E4t wird durch Selbstkontrolle durch gleichzeitige = Nutzung der Software, stichprobenartigen Kontrollen durch Projektkoordinatoren und = den Einbezug der Endnutzer =FCber ein Fehlerberichtsystem erh=F6ht. Es = besteht dabei ein Konflikt zwischen der selbstbestimmten Arbeitsweise und der Endnutzerorientierung der Community, was sich in kleineren = Streitigkeiten entl=E4dt. 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 f=FCr die Einheit des = Gro=DFprojekts bzw. f=FCr das einheitliche Auftreten zust=E4ndig.
Es kristallisieren sich drei Kan=E4le f=FCr = St=F6rquellen heraus. Erstens gibt es Konflikte bei der Kommunikation, d.h. auf den = Mailinglisten, aber auch beim Chatsystem. Hier sind die meisten St=F6rungen zu finden. = St=F6rungen von Projektbeteiligten werden verbal geahndet, projekt-externe = St=F6rungen werden =FCblicherweise 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 St=F6rungen bei der Leistungserstellung im = Dateiablagesystem selten vor. Dies wird durch Zur=FCckspielen des vorherigen Quellcodes = und u.U. Sperrung des Zugangs sanktioniert.
Es gibt bei den kommunikativen Konflikten mehrere Themenbereiche, die =F6fters auftreten. Der erste Bereich, der am = h=E4ufigsten Auftritt, ist =FCber Konflikte bei der zuk=FCnftigen Entwicklung des = Gro=DFprojekts und der Subprojekte. Im zweiten Bereich, der seltener auftritt, kommen = folgende Konfliktgr=FCnde vor: Nichtbeachtung von Beitr=E4gen, Ablehnung von = eingereichtem Quellcode (z.B.: patches), L=F6schen oder Ver=E4ndern von Quellcode, = Qualit=E4t von programmiertem Code/=DCbersetzung/Dokumentation und Art der = Kommunikation. Ganz selten bis nie treten die Konfliktarten Aufgabenverteilung, (verkannte) Anerkennung f=FCr geschriebenen Quellcode, Selbst=FCbersch=E4tzung der = eigenen Leistung und Anspruchshaltung auf.