[ox-de] keimform.de: Community Anti-Patterns
- From: Stefan Meretz <stefan meretz.de>
- Date: Fri, 21 Jan 2011 18:08:55 +0100
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: projekt oekonux.de