Der Großteil der Open-Source-Entwicklung findet in der Freizeit statt und obwohl oder vielleicht gerade deswegen, kommt es immer wieder zu Konflikte mit Menschen, die Unruhe in die Community bringen. Das müssen gar nicht immer böse oder dumme Menschen sein – manche können die Community auch mit Freundlichkeit und Interesse in den Wahnsinn treiben. Wie man mit solchen Leuten umgeht, erklären Ben Collins-Sussman und Brian Fitzpatrick in einem Vortrag.
In dem Google Tech-Talk „How Open Source Projects Survive Poisonous People“ erzählen Ben Collins-Sussman und Brian Fitzpatrick vom Subversion-Projekt eigentlich nichts Neues, denn es könnte auch im Knigge oder bei Aristoteles stehen: Open Source Communities sollten auf 4 Säulen fundieren:
- Höflichkeit
- Respekt
- Vertrauen
- Demut
Und so stellen sie auch am Ende Ihres fast einstündigen Vortrags fest, dass all ihre Tipps auch für jede andere Art von Gemeinschaft zutreffen.
„Don‘t Panic!“
Ihr Haupttipp ist: Bloß nicht aus der Ruhe bringen lassen! Die Träger einer Community wissen meist sehr genau, wo das Projekt steht und wo es hin soll. Wenn Störungen auftreten, sollte man die nicht zu ernst nehmen. Eventuell gibt es Punkte hinter all den Störungen, die man aufnehmen kann, aber bloß nicht auf die Störungen reagieren.
Die beiden Sprecher identifizieren verschiedene Typen von Störern:
- Da sind die Typen, die in eine Community kommen und alles besser wissen.
- Die unterteilen sich dann einmal in die, die nur reden und nichts tun wollen oder können.
- Und diejenigen, die alles an sich reißen wollen.
Ein guter Indikator für solche Leute sind lächerliche Usernamen, die auch noch im Forum andere sind als im Chat usw. Dazu kommt übermäßiger Gebrauch von Internet-Abkürzungen und Interpunktion (Bsp.: WTF!!!!!111einseinself!!)
„Submit a Patch“
Collins-Sussman und Fitzpatrick empfehlen: „Submit a Patch“, was zwar eine Einladung zum Mitmachen ist, bei diesen Leuten aber dazu führt, dass der Ball bei ihnen ist und sie dann meist doch nichts tun, und sich wieder zurückziehen.
Man sollte hier die Langzeit-Ausrichtung des Projektes im Hinterkopf behalten und nicht darauf hoffen, dass diese Person tatsächlich etwas einbringt.
Generell sollte man nicht zu viel Aufwand in die Einbindung von neuen Mitglieder treiben: natürlich muss ein Projekt offen für neue Leute sein, die müssen sich aber entweder relativ selbstständig und ohne großen Aufwand zurechtfinden, oder man wird langfristig ohnehin nicht glücklich zusammen.
Collins-Sussman und Fitzpatrick berichten zum Beispiel von einem kuriosen Fall: Ein neues Mitglied war total freundlich und aufgeschlossen, hat sich in alles eingelesen usw. Nach kurzer Zeit fing er dann an, weitergehende Fragen zu stellen. Immer freundlich. Irgendwann aber stellte Fitzpatrick aber fest, dass ein Großteil der Kommunikation auf der Mailing Liste entweder von dieser Person ausging oder sich auf deren Fragen bezog. Man hat ihm dann höflich per Telefon erklärt, dass das so nicht ginge. Da derjenige das aber nicht verstehen (wollte/konnte), hat er sich wieder verabschiedet.
Wie gesagt: Der Vortrag bringt nicht viele neue Erkenntnisse, fasst die üblichen Probleme aber gut zusammen und zeigt, wie man damit umgehen sollte. Ich finde es beruhigend, dass es anderen Projekten auch so geht und dass auch den Profis manchmal nichts anderes übrig bleibt, als Leute zu verabschieden.
Links
- „How Open Source Projects Survive Poisonous People“, Google Tech Talks
Schreibe einen Kommentar