📖 Kommunikationsstrategien für Community-Building und -Management

Gute Kommunikation ist das A und O, wenn ihr Nutzer*innen erreichen und eine Entwickler*innen-Community rund um euer FOSS-Projekt aufbauen wollt. Personen, die die Software nutzen mömöchten, mümüssen verstehen, wie sie funktioniert. Und Personen, die zur Entwicklung beitragen wollen, mümüssen wissen, ob das gewügewünscht ist, wie das geht und was gebraucht wird.

Im Folgenden findet ihr eine Reihe von Kommunikationsstrategien, mit denen ihr anderen helft, eure FOSS-Projekte sicher und langfristig zu nutzen, zur Entwicklung beizutragen oder da weiterzumachen, wo ihr aufgehöaufgehört habt.

Von Anfang an: 

Gerade, wenn ihr vorhabt, eine Community rund um euer Projekt aufzubauen und miteinzubeziehen, kann es vorteilhaft sein, den Code noch wäwährend der Entwicklung zu veröveröffentlichen. Zum einen ist es nänämlich ganz im Sinne des Open-Source-Gedankens, dass Versuche und Lernprozesse offen und gemeinsam mit anderen geschehen. Zum anderen kann ein aktives Repository mehr Aufmerksamkeit füfür euer Projekt generieren, da es guten Einblick in eure Projektziele und Entwicklungsschritte gewägewährt. So stehen mehr Infos füfür potenzielle Mitwirkende bereit. Generell kann es sogar füfür Dritte attraktiver sein mitzumachen, wenn das Projekt noch in der Entwicklung ist und sich viel mehr MitgestaltungsmöMitgestaltungsmöglichkeiten bieten, als wenn nur noch Maintenance ansteht.

Oft wird die Sorge vor Kritik am Code und damit am Projekt als Grund genannt, mit der VeröVeröffentlichung bis zu einem bestimmten Meilenstein zu warten. Dabei sind Hinweise auf mömögliche Probleme oder Bugs vielfach konstruktiv und durchaus hilfreich: Wer weißweiß, wie lange diese Fehler sonst unentdeckt geblieben wäwären.

Der Code allein ist natünatürlich nur die halbe Miete, wenn du Nutzende und Mitstreiter*innen gewinnen mömöchtest. Rund um euer Projekt existieren noch eine ganze Menge weitere Infos, die füfür andere hilfreich sind, um zu verstehen, worum es euch geht, wie sie euer Projekt nutzen und wo sie euch vielleicht unterstüunterstützen kökönnen. Je nachdem, was euer Ziel ist, kökönnen die folgenden Tipps hilfreich sein, Nutzenden und potenziellen Mitentwickler*innen alle Informationen zur VerfüVerfügung zu stellen, die sie füfür Nutzung oder Einstieg brauchen:

Informationen füfür Nutzende:

• Stellt Informationen in einer Form bereit, die füfür die Nutzenden intuitiv ist, z. B. in Form eines Wikis. Die App StreetComplete hat etwa ein Wiki mithilfe der Open-Source-Software MediaWiki erstellt, die auch füfür Nicht-Entwickler*innen vertraut sowie leicht nutzbar ist. Zudem ist das Wiki im allgemeinen OpenStreetMap-Wiki verknüverknüpft und ist so leicht auffindbar. (ÜÜbrigens hat Tobias von StreetComplete in einem Interview, das ihr in der Knowledge Base findet, üüber die Arbeit mit der Community berichtet.)
• Wenn das Projekt noch nicht ausreichend sicher ist oder wichtige Funktionen fehlen, sind Informationen zum aktuellen Entwicklungsstand und mömöglicherweise auftretenden Problemen sehr hilfreich füfür potenzielle Nutzer*innen. ÜÜber einen Hinweis auf eurer Webseite oder im Appstore kökönnt ihr Endnutzer*innen erreichen und gleichzeitig um Feedback bei Problemen bitten, wie es etwa OpenAndroidInstaller tut.
• ÄÄnderungen, Neuerungen oder Fehlerbehebungen bei der VeröVeröffentlichung von neuen Softwareversionen lassen sich gut in Form von Release Notes im Repository oder auf der Projektwebseite kommunizieren und sind besonders füfür technisch versiertere Nutzer*innen hilfreich. Es gibt dafüdafür keine Standards, deswegen schaut euch am besten an, wie andere Projekte solche Infos bereitstellen. Eine gute Anlaufstelle ist da zum Beispiel die Webseite von gget.

Informationen füfür Entwickler*innen:

• Auf Veranstaltungen, üüber Social Media, in Artikeln oder BlogbeiträBlogbeiträgen üüber eure Projektfortschritte zu berichten, ist ein gägängiger Weg, um Aufmerksamkeit füfür euer Projekt zu gewinnen. Auch in einem früfrühen Entwicklungsstadium kann sich das schon lohnen –– auch wenn es vermeintlich wenig zu berichten gibt: andere Entwickler*innen kökönnen etwa wertvolles Feedback geben oder sogar Mithilfe anbieten. Wenn ihr auf Veranstaltungen unterwegs seid, kann es außaußerdem nünützlich sein, nicht nur im Vorfeld üüber eure KanäKanäle darüdarüber zu informieren, sondern auch danach, wie Polychat es etwa tut. So kökönnen im Nachgang Interessierte Aufzeichnungen eurer VorträVorträge finden und einen Eindruck gewinnen, wo man euch in Zukunft treffen kann. Unser Tipp: ÜÜberlegt euch nicht nur, wo ihr eure Zielgruppe am besten erreicht, sondern auch, welches Format zu euch passt. Manche sind füfür die großgroße BüBühne geboren, aber vielleicht füfühlt ihr euch ja bei einem informelleren Meetup mit kurzer Pitchrunde am Anfang wohler. Event-Tipps findet ihr u. a. hier in der Knowledge Base.
• Informationen üüber eure geplanten Entwicklungsschritte kökönnen Entwickler*innen helfen, euer Projekt auch dann zu verfolgen, wenn es noch in einer recht früfrühen Entwicklungsphase steckt, und mömögliche AnknüAnknüpfungspunkte füfür eine Mitarbeit zu identifizieren. Eine Checkliste lälässt sich etwa gut im Repository, aber auch auf der Projektwebseite unterbringen und kann neben der ÜÜbersicht zu den EntwicklungspläEntwicklungsplänen zeitgleich auch den Fortschritt dokumentieren. Solltet ihr irgendwann an einen Punkt kommen, an dem ihr das Projekt abgeben mömöchtet, kann so eine ÜÜbersicht außaußerdem eine gute Basis füfür ein ÜÜbergabedokument bieten. Ein gutes Beispiel dafüdafür bietet das Projekt PsyLink, das in der Checkliste nicht nur die reine Entwicklung der Software plant, sondern auch üüber die Themen Hardware, Dokumentation, Community und Marketing informiert.
• Contributing Guidelines geben Hinweise dazu, wie Entwickler*innen zu einem Projekt beitragen kökönnen. Bei OpenMLS seht ihr ganz gut, was sie alles beinhalten können:können: Informationen, welchen Stilrichtlinien BeiträBeiträge folgen sollten, wie BeiträBeiträge im Repository hinzugefühinzugefügt werden kökönnen und welchen Regeln der anschließanschließende Review-Prozess folgt. Laura von gget hat hier in der Knowledge Base außaußerdem Hinweise füfür Contributing Guidelines zusammengefasst.
• Neben Informationen, wie der technische Ablauf füfür BeiträBeiträge ist, kann ein Code of Conduct (CoC) dabei helfen, Erwartungen an die Art der Kommunikation und die Zusammenarbeit im Projekt zu erkläerklären. Gerade wenn ein Projekt noch in einer früfrühen Entwicklungsphase ist und größgrößere MäMängel kritisiert werden, kann ein CoC einen Kommunikationsstandard setzen. Auch hier gibt es natünatürlich vielfävielfältige MöMöglichkeiten, wie so ein CoC aussieht und was er alles beinhaltet. Das Team vom Projekt transcribee hat sich beispielsweise am verbreiteten Contributor Covenant orientiert und legt in seinem CoC eine Reihe von Verhaltensstandards sowie deren Durchsetzung fest.
• Direkte BeiträBeiträge zum Code sind oftmals nicht die einzige MöMöglichkeit, an einem Projekt mitzuarbeiten. Um die Arbeit aller Community-Mitglieder ööffentlich anzuerkennen, ist es daher sinnvoll, sie auch als Beitragende aufzufüaufzuführen. WäWährend das auf der Webseite einfach ist, kann es je nach Plattform im Repository schon schwieriger sein. Anbieter wie GitHub legen den Fokus stark auf den technischen Teil der Software-Entwicklung, sodass nur die Entwickler*innen als Beitragende aufgelistet werden. Projekte wie UrbanAnalyst zum Beispiel haben aber auch Beitragende, die etwa durch Issues an der Weiterentwicklung mitwirken. Deshalb nutzt das Projekt den Bot „„All Contributors“Contributors“ füfür GitHub, mit dem sich zusäzusätzliche Beitragende leicht zur ÜÜbersicht im Readme hinzufühinzufügen lassen.

Wo fange ich an? 

Nicht alle Kommunikationswege, die wir hier vorstellen, sind füfür alle Projekte gleich wichtig. ÜÜberlegt euch, was füfür euch und eure Zielgruppe sinnvoll sein kökönnte. Dabei kökönnen euch die folgenden Fragen helfen, ein klareres Bild zu zeichnen:

• Was füfür eine Community habe ich oder will ich? Geht es mir eher um Endnutzer*innen oder Menschen, die aktiv an der Entwicklung des Projekts mitwirken sollen?
• Was wüwünsche ich mir von der Community, bzw. was kann sie zum Projekt beitragen? Das kann von der regelmäßregelmäßigen Nutzung deiner Anwendung üüber Feedback hin zu Mitarbeit bei der Weiterentwicklung eine ganze Menge sein.
• Was braucht sie an Informationen, damit sie diesen Beitrag zum Projekt leisten kann?
• Wo kann ich sie am besten erreichen, sowohl digital –– zum Beispiel üüber meine Webseite oder das Repository –– oderals auch auf Veranstaltungen?

Und wenn‘wenn‘s nicht so läläuft wie geplant?

Dann ist gute Kommunikation umso wichtiger!

• Bei Bugs oder Sicherheitsproblemen solltet ihr transparent auf allen KanäKanälen kommunizieren, was diese sind und ggf. vorbeugende Schritte treffen, damit das Problem keine weiteren SchäSchäden anrichtet. Zum Beispiel, indem ihr die App durch einen Dummy im Store ersetzt.
• Es kann viele GrüGründe dafüdafür geben, dass sich das Projekt im Ganzen nicht so entwickelt wie gewügewünscht: weil etwa der Ansatz nicht funktioniert oder durch technische Neuerungen (bald) üüberholt ist. Der Code und die Erkenntnisse, die ihr bei der Entwicklung gewonnen habt, kökönnen trotzdem einen Mehrwert füfür andere darstellen. Vielleicht hat ja jemand eine äähnliche Idee und kann von der Vorarbeit oder euren Erfahrungen, was funktioniert und was nicht, profitieren. Die kökönnt ihr beispielsweise in der Dokumentation oder einem Whitepaper zusammenfassen, wie es das Projekt audilu getan hat.
• Zu guter Letzt: Gerade wenn ihr vielleicht am Projekt weiterarbeiten mömöchtet, aber schlichtweg die Zeit dafüdafür fehlt, kann gute Kommunikation und Dokumentation zum Stand des Projekts andere motivieren, Aufgaben zu üübernehmen und in das Projekt einzusteigen oder sogar ganz zu üübernehmen.