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 bei­den ar­bei­ten aber an Subversion, was gar kein Userprojekt ist. In Projekten wie GNOME oder KDE, die auf Enduser aus­ge­rich­tet sind pas­siert da­ge­gen oft, dass si­ch die Ausrichtung we­gori­en­tiert vom User. Dann füh­ren wie­der Firmen wie Novell oder Sun ir­re­teu­re Userstudien durch. Ich den­ke ei­ne Community kann ge­sund sein, wenn sie die ver­schie­de­nen Ebenen aus­rei­chend be­rück­sich­tigt. D.h. bei den Nur-Programmieern ist die Gefahr groß, daß die ir­gend­wann nur no­ch in ih­rer ei­ge­nen Blase le­ben. Für die kön­nen Leute von aus­sen, die nicht ein­fahc nur Patches bei­tra­gen als Störer wir­ken. Man könn­te ja auch Subversion selbst als ge­schei­terters Konzept be­trach­ten. „CVS do­ne right“ – Subversion woll­te im­mer nur das bes­se­re CVS sein und hat da­bei ge­gen­über neue­ren Systemen kla­re Nachteile. viel­leicht hat si­ch die Gemeinde da auch zu früh ab­ge­schot­tet ge­gen­über an­de­ren Ideen. Wenn ich an ei­ner Idee ar­bei­te, die sub­op­ti­mal ist, kann ich Leute, die das in Zweifel zie­hen als Störer be­trach­ten oder auch manch­mal über de­ren Ideen nach­den­ken, Wir ha­ben im Web so vie­le Communities, die von­ein­an­der un­ab­hän­gig agie­ren (z.B. bei den CMS) – al­le bra­ten in ih­rem ei­ge­nen Saft und gren­zen si­ch ge­gen­über an­de­ren Projekten und neu­en Ideen ab. Ob es wirk­li­ch bes­se­re ist so vie­le PHP-CMS zu ha­ben, die al­le ähn­li­che Schwierigkeiten ha­ben? Ähnliches gilt na­tür­li­ch auch für Versionskontroll-Systeme. Ich ha­be bei ei­ni­gen Projekten vie­le Leute ken­nen­ge­lernt, die si­ch wun­der­bar in der Community zu­recht­fin­den, aber jeg­li­chen Fortschritt was die User an­geht un­ter­bin­den. Daher den­ke ich, das eben­so Projektleiter und hoch­in­te­grier­te Programmierer zu ei­nem Problem wer­den kön­nen. Es gibt da­her kei­ne Faustregel.

Steffen

Die Welt lebt von kon­kur­rie­ren­den Ideen. Der wich­tigs­te Faktor von Innovation ist die Kreativität im wört­li­chen Sinne: Sie muss kre­ieren. Und wenn man et­was schöp­fen will, muss man ir­gend­wann ein­fach die Theorie ab­bre­chen und zur Praxis schrei­ten.

Voltaire hat ge­sagt: „Das Perfekte ist der Feind des Guten“ – Wer al­so über­haupt mal zu ei­ner Lösung kom­men will, soll­te si­ch an ei­nem Punkt mit dem zu­frie­den ge­ben, was er hat.

Dazu kommt, dass je­de Lösung nur in ih­rer Zeit die Beste ist. CVS war da­mals ei­ne Lösung für vie­le Probleme. Subversion hat die Probleme von CVS ge­löst. Natürlich wä­re es bes­ser ge­we­sen, dass si­ch die Subversion-Leute an CVS be­tei­ligt und das wei­ter­ent­wi­ckelt hät­ten. Es ist aber oft ein­fa­cher bei Null an­zu­fan­gen und dann ei­nen Import zu schrei­ben.

Das Problem ent­steht halt dann, wenn ein Projekt äl­ter wird: Soll man es dann weg­schmei­ßen und et­was Neues be­gin­nen? Oder das Alte so um­bau­en, dass es den neu­en Ansprüchen ge­nügt? Da wird es im­mer ver­schie­de­ne Meinungen zu ge­ben.

Ich bin ja nun mit Zikula bei ei­nem sehr al­ten Projekt be­tei­ligt – die Wurzeln rei­chen bis weit in die 90er-Jahre zu­rück. Inzwischen hat si­ch die Welt wei­ter­ge­dreht und neue Ideen sind auf­ge­taucht: Von Angeboten bei de­nen si­ch die Hoster um das CMS küm­mern (wordpress.com) bis hin zu Frameworks wie Ruby On Rails.

Sollten si­ch die Rails Leute jetzt an Zikula be­tei­li­gen? Oder soll­ten wir un­se­ren Code hin­schmei­ßen und an Rails ar­bei­ten?

Wir ha­ben ei­nen an­de­ren Weg ge­wählt: Wir ha­ben un­se­ren Code kom­plett neu ge­schrie­ben, und vie­le Lösungen ver­bes­sert und für Zikula ei­nen Import für Postnuke im­ple­men­tiert. Außerdem ver­su­chen wir den Trend zum „Rapid Development“ zu über­sprin­gen und gleich zum „Sustainable Development“ zu ge­lan­gen. Statt ein­fach nur schnell Software zu bau­en, wol­len wir es er­mög­li­chen, schnell wart­ba­re Software zu bau­en.

Beim Mentor Summit des Google Summer of Code wur­de na­tür­li­ch auch dar­über dis­ku­tiert, wie die ver­schie­de­nen CMSe Zikula, Drupal, Joomla usw. zu­sam­men­ar­bei­ten könn­ten. Das ist aber viel zu Aufwendig zu ko­or­di­nie­ren und zu vie­le Leute müss­ten zu vie­le Kompromisse ein­ge­hen. OpenSource-Entwicklung hat als Ziel nun ein­mal nicht Effizienz, son­dern per­sön­li­che Befriedigung.

kreisliga-alemao

Das schlim­mer ist, dass ich ge­ra­de das Gefühl be­kom­me, auch so ein freund­li­cher Störenfried zu sein. Zumindest wer­de ich aber nach Lesen die­ses Artikels ver­su­chen, we­ni­ger zu fra­gen und da­für nach Möglichkeit mal et­was bei­zu­tra­gen.

kaffeeringe.de

Nein! Sicher nicht. Hast Du Dir das Video mal an­ge­schaut? Bei dem Menschen ging es dar­um, dass si­ch der Hauptteil der Kommunkation auf der Entwickler-Mailing-Liste nur no­ch auf die­sen ei­nen, freund­li­chen Menschen be­zog! Bei Zikula je­den­falls 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?