[ox-de] keimform.de: Community Anti-Patterns

Community Anti-Patterns

http://www.keimform.de/2011/community-anti-patterns/

Von StefanMz

Dave Neary, langjähriges Mitglied der GNOME-Foundation 
<http://de.wikipedia.org/wiki/GNOME_Foundation> und Maintainer von 
maemo.org <http://maemo.org/>, hat auf der 
MeeGo<http://de.wikipedia.org/wiki/MeeGo>-Konferenz im November 2010 
einen interessanten Vortrag zur Frage gehalten, wie eine Community 
scheitern kann. Er wählte dafür den Begiff »Anti-Patterns« (nach 
Christopher Alexander 
<http://de.wikipedia.org/wiki/Christopher_Alexander>), also etwa »Muster 
destruktiven Verhaltens«. Viele (nicht alle) der aus der Software-
Entwicklung gewonnenen Beobachtungen lassen sich auf andere commons-
basierte Projekte übertragen.

Zu Beginn des Vortrags erklärt Dave den Begriff »Pattern« (»Muster«) mit 
einem Picasso-Zitat: »Good artists copy, great artists steal« (»Gute 
Künstler kopieren, großartige Künstler stehlen«). Wenn man ein Muster 
von etwas wirklich versteht, dann nimmt man es in sich auf (»stiehlt 
es«) und verwendet im eigenen, neuen Sinn weiter, anstatt das 
unverstandene Muster nur nachzuahmen (»zu kopieren«).

Der Witz ist nun: Nachahmung funktioniert in Communities nicht! Aus 
bloßer Nachahmung können stattdessen Anti-Patterns entstehen, die Dave 
Neary dann in 8 Punkten beschreibt — inklusive Vorschlägen (die sich 
v.a. an Maintainer <http://de.wikipedia.org/wiki/Maintainer> richten), 
damit umzugehen.

1. Cookie-Licker (Keks-Anlecker)

Im Bild leckt ein Kind, das den letzten Keks für später reservieren 
will, einen Keks an, damit ihn niemand anderes isst. In Communities wird 
dieses Verhalten auch »volunteerism« (volunteer=Freiwilliger) genannt: 
Leute melden sich freiwillig für eine Aufgabe, obwohl sie wissen oder 
ahnen, dass sie diese Aufgabe nicht erledigen können (aus Zeitmangel 
etc.). Das Problem ist dabei, dass oft die besten Beitragenden in einer 
Community sich — hoch anerkannt — freiwillig melden und dann nicht nur 
die Aufgabe nicht hinbekommen, sondern den ganzen Prozess blockieren, 
weil auch niemand anderes inzwischen die Aufgabe erledigen kann. Der 
ganze Community-Prozess wird von wenigen Voluteeristen abhängig. Eine 
Rückgabe der Aufgabe an die Community erscheint dann schwierig bis 
unmöglich, weil sie es ja eigentlich hinbekommen könnten und weil eine 
Rückgabe das Eingeständnis eines Fehlers oder einer Niederlage wäre — 
verbunden mit dem entsprechenden Gesichtsverlust.

Was tun? Eine Fehlerkultur etablieren: Fehler müssen möglich sein. Es 
ist ok und erwünscht, eine Aufgabe zurückzugeben, dann jedoch möglichst 
zügig, nachdem klar ist, dass es nichts wird. Dieser Prozess muss 
community-öffentlich (also nicht über private Mails) laufen, damit allen 
klar ist: Alle können Aufgaben zurückgeben. Umso schneller dies nach dem 
Erkennen, dass die Umsetzung nicht klappt, geschieht, desto besser für 
den gesamten Community-Prozess.

2. Help Vampire (Hilfe-Vampire)

Neue Community-Mitglieder können die Hilfsbereitschaft und Projekt-
Ressourcen »aussaugen«. Jede (notwendige, erwünschte und sinnvolle) 
Frage auf einer Mailingliste erfordert die Aufmerksamkeit aller und 
entzieht die Ressourcen denen, die immer wieder antworten.

Was tun? Zunächst eine gute Dokumentation für die immer wiederkehrenden 
Fragen schaffen. Versetze die Neuen in die Lage, sich selbst 
Informationen zu beschaffen und sich selbst zu helfen. Dann sollten die 
jeweils vor kurzem eingestiegenen Mitglieder, die den Einstiegsprozess 
gerade geschafft haben, ermutigt werden, die Fragen der gerade neu 
Hinzukommenden zu beantworten. Wichtig ist, dass die erfahrenen 
Mitglieder den Raum dafür lassen, die Einsteigerfragen durch die zu 
beantworten zu lassen, die die Hürde vor kurzem erst geschafft haben.

3. RTFM (»Lies das verdammte Handbuch«)

Das Gegenstück zum Beantworten jeder kleinen, neuen Frage eines »Hilfe-
Vampirs« ist der schlichte RTFM-Verweis: Lies erst die Doku, lies erst 
das Wiki, lies erst die Mailingslisten-Archive — und dann komm wieder. 
Das ist genauso schlecht, wie auf jede triviale Frage immer wieder 
einzugehen.

Was tun? Hier greift die gleiche Lösung wie beim »Hilfe-Vampir«.

4. Headless Chicken (Kopfloses Huhn)

In Communities ohne »leadership« (Führerschaft, im Englischen nicht 
negativ besetzt) zerren die unterschiedlichen Strömungen das Projekt in 
verschiedene Richtungen, und es kommt nicht von der Stelle. Dies führt 
häufig zu »bike shed« (Fahrradunterstand) Diskussionen: Endlose 
Kontroversen über nebensächliche Punkte, bei denen alle mitreden können, 
während die wichtigen Entscheidungen gar nicht getroffen oder 
durchgewunken werden, weil sie nicht wirklich beurteilt werden können 
(Fahrradunterstand im Vergleich zur nächsten Großinvestition). Dies 
wurde von C.N. Parkinson 
<http://de.wikipedia.org/wiki/Cyril_Northcote_Parkinson> als 
»Trivialitätsgesetz« 
<http://de.wikipedia.org/wiki/Parkinsonsches_Gesetz> formuliert.

Was tun? »Leadership« etablieren, das heißt Maintainer finden, die die 
Fähigkeit haben, die notwendigen Entscheidungen herbeizuführen. Oft gibt 
es »de-facto leader«, die eine entsprechende Reputation besitzen und 
deren Vorschlägen das Projekt folgt, die sich aber selbst nicht als 
solche ansehen wollen. Hier gilt es, die De-Facto-Situation in explizit 
erklärte Verhältnisse umzuwandeln. In und zu klaren Verhältnissen können 
sich die Projekt-Mitglieder auch klarer verhalten.

Zweite Option ist, eine Kultur des »Machens« zu etablieren, anstatt eine 
Kultur des bloßen Redens hinzunehmen. So könnten Opponenten bei 
Konflikten aufgefordert werden, nach einer Auszeit ihre Vorschläge 
ausformuliert vorzulegen. Oft ist es so, dass nach der Auszeit nur der 
initiale Vorschlag vorliegt, während es die Einwender beim Reden und 
Meckern belassen haben. Und sollten doch zwei Vorschläge vorliegen, dann 
ist eine Entscheidung auf ausformulierter Grundlage einfacher möglich.

5. Water Cooler (Wasserspender)

Dieses Phänomen ist aus Unternehmen bekannt: An allen möglichen Orten 
wird kreativ gearbeitet, nur nicht am Arbeitsplatz, z.B. beim Quatschen 
am Wasserspender, in der Teeküche etc. Übertragen auf Community-Projekte 
wird dieses Problem in der Zusammenarbeit mit Unternehmen zum Problem, 
wenn Unternehmensmitarbeiter sich nicht transparent in den 
Kommunikationsstrukturen des Projekts bewegen, sondern »mal eben« zum 
Kollegen oder zur Kollegin nebenan gehen, um das Problem zu besprechen. 
Das hat mit einer »Angst vor Community« zu tun in dem Sinne, dass nicht 
geglaubt wird, in der offenen Projektarbeit genauso viel Arbeit leisten 
zu können wie im Unternehmen (»auf der Mailingliste wird alles 
durchgekaut, dafür habe ich keine Zeit«).

Was tun? Niemand muss überall mitreden, was in der offenen 
Projektkommunikation abläuft. Insbesondere, wenn es darum geht, 
bestimmte Ideen als integrales Konzept durchzusetzen, kann man 
(befristet) die Glashaus-Methode anwenden. Dabei wird z.B. eine 
themenbezogene Mailingliste eingerichtet, auf der ernannte Personen ein 
bestimmtes Problem bearbeiten. Die Mailingliste ist wie üblich offen für 
Eintragungen, hat ein Archiv, ist also transparent. Aber Beiträge von 
Nichtmitgliedern der Arbeitsgruppe sind nicht möglich (z.B. per Listen-
Moderation). Auf diese Weise ist klar, wie Entscheidungen zustande 
kommen, was die Gründe waren etc. Das ist besser als sich still ins 
(virtuelle oder reale) Hinterzimmer zurück zu ziehen und dann plötzlich 
eine Lösung vorzulegen, die alle überrascht bzw. vor den Kopf stößt.

6. Blackhole (Schwarzes Loch)

Wenn ein sehr aktiver Entwickler dafür fest angestellt wird, genau das 
zu tun, was er bisher getan hat, dann sinkt die Aktivität im Projekt. 
Der Hintergrund ist, dass im Unternehmen die Vorgesetzen »Code-
Schreiben« als Aufgabe eines Entwicklers ansehen, nicht aber Review von 
Code von anderen Entwicklern, Kommunikation auf der Mailingliste, 
Beantworten von Fragen etc. Wenn nur noch Code geschrieben wird, keiner 
aber mehr weiss, wie der Stand ist, dann verschwinden solche 
Entwicklungen aus Sicht des Projekts in einem schwarzen Loch. Dann 
besteht die Gefahr paralleler Entwicklungen, Leute können frustiert 
werden, wenn das, woran sie arbeiten, plötzlich aus dem schwarzen Loch 
als fertige Lösung auftaucht. Frustrierte Entwickler verschwinden dann 
meist aus dem Projekt.

Was tun? Zunächst einmal sicherstellen, dass die komplette Bandbreite 
der bisherigen offenen Tätigkeiten Teil der Tätigkeitsbeschreibung im 
neuen Job wird. Es ist sinnvoll, dass auch die Manager Schulungen in 
»Community-Software-Entwicklung« bekommen, denn die Software-Entwicklung 
in Communities funktioniert nun mal anders als in Unternehmen, und 
Manager müssen das verstehen. Die Transparenz darüber, wer woran 
arbeitet, muss kontinuierlich gegeben sein. Öffentliche Roadmaps sind 
hier sinnvoll. Die angestellten Entwickler sollten klar benennen, welche 
Aufgaben sie bearbeiten, und welche Aufgaben offen für andere Entwickler 
sind.

7. Broken Window (zerbrochenes Fenster)

Das Phänomen spielt auf die inkonsequente Reaktion auf Regelverstöße im 
Projekt an: Wenn ringsum die Fenster zerbrochen sind, ist es ein Signal 
dafür, folgenlos auch selbst ein Fenster einzuwerfen. Übertragen auf die 
Community sind das zum Beispiel Off-Topic- oder Bike-Shed-Diskussionen, 
Wiki-Vandalismus, Verstöße gegen verabredete Namenskonventionen in Wikis 
oder im Code etc.

Was tun? Best Practices dokumentieren, aufschreiben, was im Projekt 
erwünscht ist; dann frühe, freundliche Erinnerungen, die Verabredungen 
einzuhalten, an solche Mitglieder, die dies nicht tun.

8. Community as emotional places (Gemeinschaften als Orte der Gefühle)

Communities können frustrierende Orte werden, Leute können verzweifeln; 
Communities können Orte werden, wo alle als wirkliches Kollektiv agieren 
und eine Vision verfolgen; Communities können Orte werden, wo es Spaß 
macht, zu teilen — was den Kern von Freier Software ausmacht. In den 
Abschlussworten von Dave Neary:

    »Lasst uns eine freundliche Umgebung schaffen, in der es Spaß macht, 
zu teilen, in der Leute sich sicher fühlen, großartige Arbeit leisten — 
und eine tolle Mobil-Plattform schaffen.«

In der Diskussion empfiehlt Dave Neary dann drei Bücher: allgemein zu 
Projektmanagement »Peopleware — Productive Projects and Teams« von Tom 
DeMarco und Timothy Lister (deutsch: »Wien wartet auf Dich!« 
<http://de.wikipedia.org/wiki/Peopleware>), »The Art of Community« 
<http://www.artofcommunityonline.org/> von Jono Bacon und speziell für 
Freie Software »Producing Open Source Software« 
<http://producingoss.com/> von Karl Fogel (deutsch: »Produktion von 
Open-Source-Software« <http://producingoss.com/de/>).

-- 
Start here: www.meretz.de
________________________________
Web-Site: http://www.oekonux.de/
Organisation: http://www.oekonux.de/projekt/
Kontakt: [email protected]