kaffeeringe.de

Open Source: Wie man mit ätzenden Leuten umgeht

Ätzend

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:

  1. Höflichkeit
  2. Respekt
  3. Vertrauen
  4. 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

Kommentare

Thilo Pfennig

Die beiden arbeiten aber an Subversion, was gar kein Userprojekt ist. In Projekten wie GNOME oder KDE, die auf Enduser ausgerichtet sind passiert dagegen oft, dass sich die Ausrichtung wegorientiert vom User. Dann führen wieder Firmen wie Novell oder Sun irreteure Userstudien durch. Ich denke eine Community kann gesund sein, wenn sie die verschiedenen Ebenen ausreichend berücksichtigt. D.h. bei den Nur-Programmieern ist die Gefahr groß, daß die irgendwann nur noch in ihrer eigenen Blase leben. Für die können Leute von aussen, die nicht einfahc nur Patches beitragen als Störer wirken. Man könnte ja auch Subversion selbst als gescheiterters Konzept betrachten. „CVS done right“ – Subversion wollte immer nur das bessere CVS sein und hat dabei gegenüber neueren Systemen klare Nachteile. vielleicht hat sich die Gemeinde da auch zu früh abgeschottet gegenüber anderen Ideen. Wenn ich an einer Idee arbeite, die suboptimal ist, kann ich Leute, die das in Zweifel ziehen als Störer betrachten oder auch manchmal über deren Ideen nachdenken, Wir haben im Web so viele Communities, die voneinander unabhängig agieren (z.B. bei den CMS) – alle braten in ihrem eigenen Saft und grenzen sich gegenüber anderen Projekten und neuen Ideen ab. Ob es wirklich bessere ist so viele PHP-CMS zu haben, die alle ähnliche Schwierigkeiten haben? Ähnliches gilt natürlich auch für Versionskontroll-Systeme. Ich habe bei einigen Projekten viele Leute kennengelernt, die sich wunderbar in der Community zurechtfinden, aber jeglichen Fortschritt was die User angeht unterbinden. Daher denke ich, das ebenso Projektleiter und hochintegrierte Programmierer zu einem Problem werden können. Es gibt daher keine Faustregel.

Steffen

Die Welt lebt von konkurrierenden Ideen. Der wichtigste Faktor von Innovation ist die Kreativität im wörtlichen Sinne: Sie muss kreieren. Und wenn man etwas schöpfen will, muss man irgendwann einfach die Theorie abbrechen und zur Praxis schreiten.

Voltaire hat gesagt: „Das Perfekte ist der Feind des Guten“ – Wer also überhaupt mal zu einer Lösung kommen will, sollte sich an einem Punkt mit dem zufrieden geben, was er hat.

Dazu kommt, dass jede Lösung nur in ihrer Zeit die Beste ist. CVS war damals eine Lösung für viele Probleme. Subversion hat die Probleme von CVS gelöst. Natürlich wäre es besser gewesen, dass sich die Subversion-Leute an CVS beteiligt und das weiterentwickelt hätten. Es ist aber oft einfacher bei Null anzufangen und dann einen Import zu schreiben.

Das Problem entsteht halt dann, wenn ein Projekt älter wird: Soll man es dann wegschmeißen und etwas Neues beginnen? Oder das Alte so umbauen, dass es den neuen Ansprüchen genügt? Da wird es immer verschiedene Meinungen zu geben.

Ich bin ja nun mit Zikula bei einem sehr alten Projekt beteiligt – die Wurzeln reichen bis weit in die 90er-Jahre zurück. Inzwischen hat sich die Welt weitergedreht und neue Ideen sind aufgetaucht: Von Angeboten bei denen sich die Hoster um das CMS kümmern (wordpress.com) bis hin zu Frameworks wie Ruby On Rails.

Sollten sich die Rails Leute jetzt an Zikula beteiligen? Oder sollten wir unseren Code hinschmeißen und an Rails arbeiten?

Wir haben einen anderen Weg gewählt: Wir haben unseren Code komplett neu geschrieben, und viele Lösungen verbessert und für Zikula einen Import für Postnuke implementiert. Außerdem versuchen wir den Trend zum „Rapid Development“ zu überspringen und gleich zum „Sustainable Development“ zu gelangen. Statt einfach nur schnell Software zu bauen, wollen wir es ermöglichen, schnell wartbare Software zu bauen.

Beim Mentor Summit des Google Summer of Code wurde natürlich auch darüber diskutiert, wie die verschiedenen CMSe Zikula, Drupal, Joomla usw. zusammenarbeiten könnten. Das ist aber viel zu Aufwendig zu koordinieren und zu viele Leute müssten zu viele Kompromisse eingehen. OpenSource-Entwicklung hat als Ziel nun einmal nicht Effizienz, sondern persönliche Befriedigung.

kreisliga-alemao

Das schlimmer ist, dass ich gerade das Gefühl bekomme, auch so ein freundlicher Störenfried zu sein. Zumindest werde ich aber nach Lesen dieses Artikels versuchen, weniger zu fragen und dafür nach Möglichkeit mal etwas beizutragen.

kaffeeringe.de

Nein! Sicher nicht. Hast Du Dir das Video mal angeschaut? Bei dem Menschen ging es darum, dass sich der Hauptteil der Kommunkation auf der Entwickler-Mailing-Liste nur noch auf diesen einen, freundlichen Menschen bezog! Bei Zikula jedenfalls bist Du nicht so 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Möchtest Du benachrichtigt werden, wenn Dir hier jemand antwortet?