'[kde-promo] My research about KDE'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-promo
Subject: [kde-promo] My research about KDE
From: "anbrand" <A.Brand () em ! uni-frankfurt ! de>
Date: 2003-05-22 8:46:17
[Download RAW message or body]

Hello KDE-Promo-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 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).

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@em.uni-frankfurt.de
  Url:   http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html
***************************************************************************

["Kurzes Abstract Vortrag Linuxtag 2003.txt" (text/plain)]

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@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. 

["Kurzes Abstract Vortrag Linuxtag 2003.htm" (text/html)]

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List
href="./Kurzes%20Abstract%20Vortrag%20Linuxtag%202003-Dateien/filelist.xml">
<title>Kurzes Abstract für einen Vortrag auf dem Linuxtag, 10</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>aa</o:Author>
  <o:Template>Normal</o:Template>
  <o:LastAuthor>aa</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:Created>2003-05-13T10:21:00Z</o:Created>
  <o:LastSaved>2003-05-13T10:21:00Z</o:LastSaved>
  <o:Pages>4</o:Pages>
  <o:Words>1811</o:Words>
  <o:Characters>10328</o:Characters>
  <o:Company>a</o:Company>
  <o:Lines>86</o:Lines>
  <o:Paragraphs>20</o:Paragraphs>
  <o:CharactersWithSpaces>12683</o:CharactersWithSpaces>
  <o:Version>9.2812</o:Version>
 </o:DocumentProperties>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:HyphenationZone>21</w:HyphenationZone>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Standard;
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-font-kerning:0pt;
	mso-bidi-font-weight:normal;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:-132;
	mso-list-type:simple;
	mso-list-template-ids:1180870688;}
@list l0:level1
	{mso-level-tab-stop:74.6pt;
	mso-level-number-position:left;
	margin-left:74.6pt;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:-131;
	mso-list-type:simple;
	mso-list-template-ids:-335228168;}
@list l1:level1
	{mso-level-tab-stop:60.45pt;
	mso-level-number-position:left;
	margin-left:60.45pt;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:-130;
	mso-list-type:simple;
	mso-list-template-ids:-1918068500;}
@list l2:level1
	{mso-level-tab-stop:46.3pt;
	mso-level-number-position:left;
	margin-left:46.3pt;
	text-indent:-18.0pt;}
@list l3
	{mso-list-id:-129;
	mso-list-type:simple;
	mso-list-template-ids:-432888390;}
@list l3:level1
	{mso-level-tab-stop:32.15pt;
	mso-level-number-position:left;
	margin-left:32.15pt;
	text-indent:-18.0pt;}
@list l4
	{mso-list-id:-128;
	mso-list-type:simple;
	mso-list-template-ids:117497042;}
@list l4:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:74.6pt;
	mso-level-number-position:left;
	margin-left:74.6pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l5
	{mso-list-id:-127;
	mso-list-type:simple;
	mso-list-template-ids:329563828;}
@list l5:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:60.45pt;
	mso-level-number-position:left;
	margin-left:60.45pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l6
	{mso-list-id:-126;
	mso-list-type:simple;
	mso-list-template-ids:-1617506268;}
@list l6:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:46.3pt;
	mso-level-number-position:left;
	margin-left:46.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l7
	{mso-list-id:-125;
	mso-list-type:simple;
	mso-list-template-ids:-856249978;}
@list l7:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:32.15pt;
	mso-level-number-position:left;
	margin-left:32.15pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l8
	{mso-list-id:-120;
	mso-list-type:simple;
	mso-list-template-ids:71624266;}
@list l8:level1
	{mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l9
	{mso-list-id:-119;
	mso-list-type:simple;
	mso-list-template-ids:-1717416318;}
@list l9:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=DE style='tab-interval:35.4pt'>

<div class=Section1>

<p class=MsoNormal>Andreas Brand: Die Struktur, Eintritt, Leistungserstellung, \
Motivation und Kontrolle in einem Open Source-Projekt </p>

Paper für einen Vortrag auf dem Linuxtag, 10.-13. Juli

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<table border=1 cellspacing=0 cellpadding=0 style='border-collapse:collapse;
 border:none;mso-border-alt:solid windowtext 1.0pt;mso-padding-alt:0cm 3.5pt 0cm \
3.5pt'>  <tr>
  <td width=614 style='width:460.6pt;border:solid windowtext 1.0pt;padding:
  0cm 3.5pt 0cm 3.5pt'>
  <p class=MsoNormal><span \
style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Kontakt:<o:p></o:p></span></p>  <p \
class=MsoNormal><span style='font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if \
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>  <p class=MsoNormal><span \
style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Dipl.  Soz. Andreas \
Brand<o:p></o:p></span></p>  <p class=MsoNormal><span \
style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Project  electronic labourmarkets \
(PELM) / Projekt elektronische Arbeitsmärkte<o:p></o:p></span></p>  <p \
class=MsoNormal><span style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Johann  W. \
v. Goethe Universität / Johann W. v. Goethe University<o:p></o:p></span></p>  <p \
class=MsoNormal><span style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Institut  \
für Polytechnik und Arbeitslehre / Institute for polytechnic and  \
laboursciences<o:p></o:p></span></p>  <p class=MsoNormal><span lang=FR \
style='font-size:10.0pt;mso-bidi-font-size:  12.0pt;mso-ansi-language:FR'>Email: \
A.Brand@em.uni-frankfurt.de<o:p></o:p></span></p>  <p class=MsoNormal><span lang=FR \
style='font-size:10.0pt;mso-bidi-font-size:  12.0pt;mso-ansi-language:FR'>Url:<span \
style="mso-spacerun: yes">    \
</span>http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html</span><span  \
lang=FR style='mso-ansi-language:FR'><o:p></o:p></span></p>  </td>
 </tr>
</table>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><b style='mso-bidi-font-weight:normal'><span
style='font-size:14.0pt;mso-bidi-font-size:12.0pt'>Struktur: \
<o:p></o:p></span></b></p>

<p class=MsoNormal><b style='mso-bidi-font-weight:normal'>Innere Struktur von
KDE:<o:p></o:p></b></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

Äußere Struktur bzw.
Einbettung von KDE:<o:p></o:p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><b style='mso-bidi-font-weight:normal'><span
style='font-size:14.0pt;mso-bidi-font-size:12.0pt'>Funktionsweise:<o:p></o:p></span></b></p>

<p class=MsoNormal><b \
style='mso-bidi-font-weight:normal'>Eintritt:<o:p></o:p></b></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1>Leistungserstellung, Arbeitsverteilung und Arbeitszusammenführung</h1>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1>Motivation/Gratifikation</h1>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1>Kontrolle</h1>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

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.

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

</div>

</body>

</html>

_______________________________________________
This message is from the kde-promo mailing list.

Visit http://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or \
temporarily stop your subscription.

[prev in list] [next in list] [prev in thread] [next in thread] 