Community Anti-Patterns

Dave Neary, langjähriges Mitglied der GNOME-Foundation und Maintainer von maemo.org, hat auf der 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), 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 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 als »Trivialitätsgesetz« 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!«), »The Art of Community« von Jono Bacon und speziell für Freie Software »Producing Open Source Software« von Karl Fogel (deutsch: »Produktion von Open-Source-Software«).

5 Kommentare

Entdecke mehr von keimform.de

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen