My research about KDE

[anbrand]

Hello KDE-Nove-Hrady-Planning-People,
I have read that you are planing a KDE-meeting at Nove Hrady. I do not know
if you remember me but I did ask you questions and let some of you fill out
surveys at last years linuxtag. After a lot of time I have nearly finished
my research. My research consists of a case study, the analysis of the
survey (linuxtag) and the analysis of interviews from tink. The findings of
the case study are attached to this mail. The findings of the quantitative
studies could be found at
http://www.uni-frankfurt.de/fb03/arbeitslehre/brand_veroeffentlichungen.htm
(the working papers at
http://www.uni-frankfurt.de/fb03/arbeitslehre/Auswertung%20Selbstinterviews%
20OS-community%20V0,5.pdf and
http://www.uni-frankfurt.de/fb03/arbeitslehre/Auswertung%20quan%20Interviews
%20OS-community%20V0,5.pdf). These working papers (the quantitative studies)
are in a pre-beta Phase and I have seen that the pdf-format has omitted
something at diagrams in this papers. But nevertheless I think, the findings
are interesting for you. If you have questions or remarks about some
findings feel free to mail me.
I am also in contact with the planing group of linuxtag 2003 for a speech
about these findings.

I want to reflect/give back my research to your community. So my question
is, if I could give a speech or workshop at your KDE-meeting at Nove Hrady
(Probably the same as on the Linuxtag).

Sorry,
I forgot: the texts about my research are in german. I have and had no time
to translate them in english. I asked my girl-friend to translate the
quantitative studies but this will take some time (also they are in a
pre-beta phase so translation is not worth the effort). I hope you will
understand this problem.
But I could hold the speech in english, so that everyone could understand
it.

Best wishes
Andreas Brand

Besides: It seems that there are some people who are interested in the
research. F.e. Stephan Binner contacted me and asked for findings.


***************************************************************************
  Dipl. Soz. Andreas Brand
  Project electronic labourmarkets (PELM)
    / Projekt elektronische Arbeitsmärkte
  Johann W. v. Goethe Universität
    / Johann W. v. Goethe University
  Institut für Polytechnik und Arbeitslehre
    / Institute for polytechnic and laboursciences
  Robert-Mayer Str. 1 / FLAT: Zimmer 105 / Room 105
  Postadresse / for letters:
  Postfach
  D-60054 Frankfurt / Main
  Tel.:  +49-(0)69-798-28923; Fax: ~798-28233
  Email: A.Brand at em.uni-frankfurt.de
  Url:   http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html
***************************************************************************

-------------- next part --------------
Andreas Brand: Die Struktur, Eintritt, Leistungserstellung, Motivation und Kontrolle in einem Open Source-Projekt 
Paper für einen Vortrag auf dem Linuxtag, 10.-13. Juli


Kontakt:

Dipl. Soz. Andreas Brand
Project electronic labourmarkets (PELM) / Projekt elektronische Arbeitsmärkte
Johann W. v. Goethe Universität / Johann W. v. Goethe University
Institut für Polytechnik und Arbeitslehre / Institute for polytechnic and laboursciences
Email: A.Brand at 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 Nürnberg/Erlangen. Die Gruppe ist recht homogen, da der größte Teil der Personen männlich und zwischen 20 und 30 Jahren alt ist. Ein großer Teil der Projektbeteiligten sind Studenten, ein anderer großer Teil sind Erwerbstätige. Gemeinsam ist der überwältigenden Mehrheit, daß sie entweder eine IT-Studium oder IT-Ausbildung absolviert oder absolviert hat. Schüler, Lehrlinge, Arbeitslose und Erwerbstätige aus anderen Bereichen bilden dagegen eine Minderheit. Z.T. gibt es auch mitarbeitende wissenschaftlich Tätige und Projektbeteiligte, die sich selbständig 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ätigkeitsbereiche 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ätigkeiten, wie z.B. Homepagepflege, Graphik-/Sounderstellung, nur ca. 5 %.
Die wichtigsten Werkzeuge stellen die Mailinglisten für die Kommunikation und das Dateiablagesystem für 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änderung 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änderungen. Nach mehrmaligem Zusenden erhalten die Neulinge die Schreibberechtigung für 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 Möglichkeit 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ät/ 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 Löschen von Quellcode. 

Leistungserstellung, Arbeitsverteilung und Arbeitszusammenführung
Es gibt eine operative und eine strategische Entscheidungsebene, wobei sich die operative um die konkrete Softwareerstellung und die strategische um rechtliche Probleme und visionäre 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ängliche Skizzen bzw. andere formale Hilfsmittel sofort programmiert oder sich vorher im Kopf beim Sport ein möglicher Lösungsweg ausgedacht. Nur eine Minderheit entwirft vorher ein formales Modell, das später programmiert wird. Damit fällt 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ür das Projekt aufgewendet. Es wird vor allem während der Freizeit gearbeitet, wenn man von den Personen absieht, die für 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önnen 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 für 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ällt. Allgemein ist die Zustimmung zu einer Mitsprachemöglichkeit im Subprojekt hoch. Doch gibt es eine Tendenz, daß Projektleiter und Personen aus dem inneren Kreis eine eher höhere Mitsprachemöglichkeit 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 zusammengeführt. Es gibt eine offizielle Veröffentlichung, den Release, der nach einem koordinierenden Releaseplan herausgegeben wird. Zuständig für die Kontrolle dieses Plans und für die Übernahme von stabilen Programmen ist der Releasekoordinator, der diesen speziellen, koordinierenden Posten für den inneren Kreis übernimmt. 

Motivation/Gratifikation
Es sind monetäre und nicht-monetäre Motivationsgründe zu unterscheiden. Die monetären Gründe existieren, da Personen für die Arbeit an dem Open Source-Projekt angestellt wurden (vergleichbar Sponsoring des Projekts). Andererseits bekommen die Projektbeteiligten Werbegeschenke und Geräte auf dem neuesten technologischen Stand ausgeliehen, was dem Sponsoring von Einzelpersonen gleichkommt. Einige gaben an, kurzzeitig monetäre Gratifikationen für bestimmte Arbeiten von projektnahen Firmen bekommen zu haben. Manche bekommen für Arbeiten um das Projekt, wie Vorträge und Zeitschriftenartikel Geld.

Die nicht-monetären Motivationsgründe ü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 lösen oder der Spaß am Programmieren. Diese Motivationsgründe 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ählen soziale Anerkennung (Reputation) und gegenseitige Hilfe. Diese Motivationsgründe werden auch von einer Mehrheit für wichtig erachtet. Konflikte können dabei einerseits die Motivation im Projekt durch Beleidigungen senken, aber andererseits durch das wecken von Ehrgeiz erhöhen. Die zukünftigen Arbeitsplatzmöglichkeiten stellen auch einen Motivationsgrund dar. 

Die persönlichen Treffen stellen eine wichtige Motivationsquelle dar. Die Personen, die schon länger 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äumlicher Nähe. 

Mit der Motivation hängen auch die Hobbies zusammen, da das Projekt als zeitaufwendiges Hobby angesehen wird. Es gibt eine Fraktion die generell technikfasziniert ist. Es können zwei Lager ausgemacht werden: das erste verwendet das Programmieren zum Abschalten und das zweite , bei dem die Personen keinen Computer mehr sehen können. Sonst fällt nur auf, daß die Hobbys stark gestreut sind. Das Lesen von Comics, Science-Fiction- oder Fantasybücher ist und sportliche Hobbys sind verbreitet. 


Kontrolle
Die Kontrolle der Arbeit im Open Source-Projekt läuft über die Kontrolle der Qualität des Quellcodes. Dies erfolgt auf der operativen Ebene. Die Qualität wird durch Selbstkontrolle durch gleichzeitige Nutzung der Software, stichprobenartigen Kontrollen durch Projektkoordinatoren und den Einbezug der Endnutzer über ein Fehlerberichtsystem erhöht. Es besteht dabei ein Konflikt zwischen der selbstbestimmten Arbeitsweise und der Endnutzerorientierung der Community, was sich in kleineren Streitigkeiten entlädt. 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ür die Einheit des Großprojekts bzw. für das einheitliche Auftreten zuständig.

Es kristallisieren sich drei Kanäle für Störquellen heraus. Erstens gibt es Konflikte bei der Kommunikation, d.h. auf den Mailinglisten, aber auch beim Chatsystem. Hier sind die meisten Störungen zu finden. Störungen von Projektbeteiligten werden verbal geahndet, projekt-externe Störungen 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 Störungen bei der Leistungserstellung im Dateiablagesystem selten vor. Dies wird durch Zurückspielen des vorherigen Quellcodes und u.U. Sperrung des Zugangs sanktioniert.

Es gibt bei den kommunikativen Konflikten mehrere Themenbereiche, die öfters auftreten. Der erste Bereich, der am häufigsten Auftritt, ist über Konflikte bei der zukünftigen Entwicklung des Großprojekts und der Subprojekte. Im zweiten Bereich, der seltener auftritt, kommen folgende Konfliktgründe vor: Nichtbeachtung von Beiträgen, Ablehnung von eingereichtem Quellcode (z.B.: patches), Löschen oder Verändern von Quellcode, Qualität von programmiertem Code/Übersetzung/Dokumentation und Art der Kommunikation. Ganz selten bis nie treten die Konfliktarten Aufgabenverteilung, (verkannte) Anerkennung für geschriebenen Quellcode, Selbstüberschätzung der eigenen Leistung und Anspruchshaltung auf. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/novehrady/attachments/20030522/cb631443/KurzesAbstractVortragLinuxtag2003-0001.htm