Suche
Die Community lieben lernen

4 Regeln, um eine erfolgreiche Open-Source-Community aufzubauen

Guillaume Laforge

© Shutterstock/VLADGRIN

Guillaume Laforge zufolge ändert sich im Softwarebereich nicht nur die Rolle, die Open-Source-Communities spielen, sondern auch, wie sie sich bilden. Im Artikel erklärt der Groovy-Pionier, wie man eine konstruktive Entwickler-Community leitet.

Vor kurzem habe ich, nachdem sich die Zahl der Groovy-Downloads in Folge des Wechsels zur Apache Software Foundation verdoppelt hatten, über einige Lektionen geschrieben, die ich durch den Umgang mit Programmierer-Communities gelernt habe. Ich wollte von einigen Erkenntnissen berichten, die wir im Rahmen des Aufbaus der Restlet-Development-Community in den letzten sechs Monaten gewinnen konnten.

Es ist nicht leicht eine Community aufzubauen, die zugleich dynamisch, wachstumsstark und immer hilfreich für ihre Mitglieder ist. Veränderung ist eine Konstante. Open-Source gilt mitterweile als normal und erfreut sich breiter Akzeptanz. Die größten Talente arbeiten für gewöhnlich an Open-Source-Projekten; die jüngsten Entwickler fühlen sich als Teil einer globalen Community wohl.

Auch die Kommunikationswerkzeuge haben sich im Laufe der Zeit geändert, und zwar so sehr, dass es heute völlig anders als vor beispielsweise fünf Jahren funktioniert, eine erfolgreiche Open-Source-Community zu etablieren.

Was also sind nun die wichtigsten Lehren, die man beim Aufbau einer erfolgreichen Open-Source-Community im Jahr 2016 beachten sollte?

1. Bring deine Persönlichkeit in die Community ein

Wenn ich einer Community beitrete, wird meine Persönlichkeit ein Teil von ihr. Das gilt für jeden von uns und der Umstand, dass wir alle verschieden sind, verleiht der Community eine einzigartige und interessante Atmosphäre. Das ist großartig.

Natürlich gibt es unterschiedliche Wege, eine Gruppe von Leuten zu organisieren und zu motivieren. Linus Torvalds ist zum Beispiel bekannt dafür, sehr direkt zu sein und – manchmal jedenfalls – Beiträge aus der Community sehr schnell und scharf zu kritisieren. Allerdings scheint dieser Kommunikationsstil für ihn zu funktionieren: Linux ist ein unfassbarer Erfolg, also gibt es offenbar Raum für diese Art der Kommunikation. Dennoch ist dies nicht unbedingt die Art und Weise zu kommunizieren, die ich den führenden Köpfen einer Community empfehlen oder bei ihnen gutheißen würde. Linus und Linux sind in vielerlei Hinsicht speziell; es wäre für die meisten Leute sehr schwer, diesen Stil zu imitieren und damit durchzukommen.

Meine eigene Philosophie ist, einfach nett zu sein. Der beste Weg, ein zukünftiges Wachstum zu garantieren, ist es, offen und einladend zu sein. Ich denke das Besondere an Communities sind die Persönlichkeiten der Leute. Die besten Communities sind international und generationenübergreifend. Außerdem werden die meisten teilnehmenden Entwickler nicht bezahlt, warum sich also wie ein Boss aufspielen? Ich jedenfalls versuche in allen Unterhaltungen mit Community-Mitgliedern freundlich zu sein, egal ob sie schon lange dabei oder frisch dazugestoßen sind. Ich glaube, dass die Leute automatisch freundlich sind, wenn man selbst auch freundlich ist. Haben die Mitglieder einer neugegründeten Community das verinnerlicht, geben sie dies auch an neue Mitglieder weiter – eine positive Feedback-Schleife.

Wie ich oft sage: Du bekommst die Community, die du verdienst: Bist du nicht freundlich, einladend und hilfreich, dann wird deine Community das auch nicht sein und Leute mit ebenso schlechten Manieren anlocken. Also sei freundlich!

2. Nutzt die Kommunikations-Tools, die die Entwickler nutzen wollen

Eines der Dinge, die eine Community braucht, ist eine solide Kommunikationsplattform. Es wäre vermutlich möglich, die Kommunikation durch ein zentrales Bug-Tracking-System oder über eine Support-Mail-Adresse laufen zu lassen. Dies würde den Organisatoren vermutlich sehr gelegen kommen.

In der Vergangenheit waren die beliebtesten Methoden Mailing-Listen, Foren und der IRC. Heute kann es dir passieren, dass du auf junge Entwickler triffst, die sich an Kommunikationsarten gewöhnt haben, die dir völlig unbekannt sind. Ich glaube, dass es sich lohnt, verschiedene Optionen der Kommunikation zu berücksichtigen, anstatt auf einer bestimmten zu bestehen.

Für Apache Groovy haben wir uns auf Mailing-Listen geeinigt. Die E-Mail-Archivierung erlaubt es Entwicklern auf Beiträge zu antworten wann sie wollen, egal in welcher Zeitzone sie sich befinden. Zusätzlich können User auch JIRA-Tickets erstellen und wir reagieren auch auf Kommentare auf Github. Wir überlegen sogar, einen Slack-Channel zu starten.

In meinen ersten sechs Monaten bei Restlet habe ich die Diskussionen zum Restlet Framework in eine neue Mailing-Liste bei Google Groups verlegt. Ich habe außerdem einen kostenlosen, wöchentlichen Newsletter über die API-Industrie verfasst. Wir verlassen uns auf Github als Issue-Tracker und für Diskussionen über Pull Requests. Viele Fragen werden auch über das Forum Stack Overflow gestellt und wir haben in den letzten Monaten durch die Verbesserung unserer internen Abläufe dafür gesorgt, möglichst schnell zu antworten.

Da alle Mitglieder der Community Informationen auf andere Weise aufnehmen, sollte man versuchen herauszufinden, was die beste Art der Informationsweitergabe ist.

Ein wichtiger Hinweis zum Schluss: Achtet darauf, nicht zu viele Kanäle gleichzeitig offen zu haben. Wenn die Arbeit eines Teams auf zu viele Kanäle verteilt wird, verringert dies die Supportqualität und die Möglichkeiten, der Community zu helfen. Wenn ihr also einen neuen Kanal öffnet, seid auch wirklich sicher, dass ihr ihn richtig betreuen könnt.

3. Erhöht die Anziehungskraft eurer Community, indem ihr alle Entwickler aufnehmt

Ob ihr es glaubt oder nicht, eure Community wird Verbindungen zu verschiedenen Ebenen der Entwicklung haben. Ihr mögt vielleicht denken, dass euer Projekt zum Beispiel ein Front-End-UI-Widget ist, aber die Verbindungen zum Back-End sind ebenfalls wichtig, genau wie die Frage, wie es im Mobile-Bereich genutzt wird. Manchmal wird die Community die Wichtigkeit dieser Themenbereiche eher erkennen, als ihr selbst.

Ein klares Beispiel dafür ist, dass ich glaubte, Apache Groovy sei eine Back-End-Sprache. Erst als es immer öfter auf mobilen Geräten verwendet wurde, ist mir aufgefallen, dass sie sehr viel mehr Potential hat. Dies passte nicht so richtig in das Bild, dass ich von den Stärken der Sprache hatte. Die Community hingegen fand sehr interessante Möglichkeiten, Groovy im mobilen Bereich anzuwenden und erweitert diese Ideen stetig. Ich finde das bemerkenswert und es zeigt, dass die Community sehr engagiert und tatkräftig ist. Es ist aufregend zu sehen, wie sich Apache Groovy in Richtungen entwickelt, die ich so nicht vorausgesehen habe.

Ähnlich verhält es sich mit der API-Entwicklung bzw. dem -Design. Beides wurde bislang vorrangig von Back-End-Entwicklern erledigt. Jetzt, nachdem ich einige Zeit mit der Restlet-Community zusammengearbeitet habe, habe ich gemerkt, dass sich auch andere Leute für API-Entwicklung interessieren. Sogar solche, die sich auf die Entwicklung im Mobile-Bereich spezialisiert haben. Das ist etwas, worauf man achten sollte.

4. Arbeitet mit anderen Open-Source-Communities zusammen: Verbindet Menschen, Ideen und Technologien

Ihr mögt vielleicht glauben, dass eure Technologie sich in eine gewisse Richtung entwickelt oder für einen ganz bestimmten Zweck gedacht ist. Manchmal werdet ihr allerdings überrascht sein, in welche Richtung die Mitglieder eurer Community das Projekt vorantreiben! Apache Groovy wird jeweils ganz unterschiedlich eingesetzt: Ob im Bereich Advanced Business Rules, für Scripting- und Task-Automatisierung oder als Test- und Build-Sprache. Über die Jahre hat sich rund um die Programmiersprache ein komplettes Ökosystem entwickelt, neue Frameworks und Libraries haben für ihren Durchbruch gesorgt. Eine Sache, die wir bei Projektbeginn nicht unbedingt erwartet hatten, war, wie wichtig der Mobile-Bereich werden würde: Wir hatten großes Interesse für Groovy auf Android-Geräten, also haben wir eine entsprechende Android-Unterstützung entwickelt.

Ein anderes Beispiel: Die Restlet-Community steht im aktiven Austausch mit der Open API Initiative (OAI) der Linux Foundation und arbeitet mit SmartBear und den Gründungsmitgliedern – 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft und PayPal – zusammen, um eine offene API-Definitionssprache zu definieren. Außerdem arbeitet Restlet mit anderen Open-Source- und Open-Specification-Gruppen rund um API Blueprint, RAML, WADL und vielen anderen Projekten zusammen.

Durch die Zusammenarbeit mit anderen Communities, die zum Teil sogar Konkurrenten sind, stärken wir das Ökosystem als Ganzes und schaffen auch Vorteile für unsere eigene Community.

Hoffentlich könnt ihr diese Grundsätze anwenden, um eure liebste Open-Source-Community zu unterstützen. Wenn ihr irgendwelche Fragen habt, könnt ihr mich jederzeit bei Restlet anschreiben. Vergesst nicht: Communities brauchen feste Strukturen, aber nicht zu viele. Sie können euch eine Menge erzählen – wenn ihr denn zuhört.

Aufmacherbild: Digital Community von Shutterstock / Urheberrecht: VLADGRIN

Verwandte Themen:

Geschrieben von
Guillaume Laforge

Guillaume is a PMC member on the Apache Groovy project and Restlet product lead and developer advocate. He co-authored the bestseller “Groovy in Action” with Dierk König.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: