Ihr Projekt zum Erfolg führen

Ihr gerade gestartetes Projekt wird schon verbreitet und Leute schauen vorbei? Fantastisch! Wie überzeugen Sie sie, da zu bleiben?

Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Beiträge erfährt, fangen Sie damit an, den frühen Mitwirkenden eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen.

Geben Sie Leuten das Gefühl, willkommen zu sein

Die Community Ihres Projekts kann nach @MikeMcQuaid als “Mitwirkendenrichter” (contributor funnel) aufgefasst werden:

Contributor funnel

Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle*r Benutzer*in) theoretisch den Weg nach unten finden könnte (aktive*r Mitstreiter*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute “leichte Beute” machen können, ermutigt sie dies zu weiteren Beiträgen.

Beginnen Sie mit der Dokumentation:

  • Helfen Sie beim Einstieg in ihr Projekt. Eine freundliche README und anschauliche Codebeispiele erleichtern Allen, die auf Ihr Projekt stoßen, den Einstieg.
  • Erklären Sie in klaren Worten, wie Leute beitragen sollen, bspw. in einer CONTRIBUTING-Datei, und indem Sie die Issues stets aktuell halten.
  • Good first issues: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie für Anfänger*innen geeignete Issues explizit kenntlich machen (Englisch). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen.

GitHubs Open-Source-Umfrage aus dem Jahr 2017 zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren.

  • Wenn Leute neu zu Ihrem Projekt hinzustoßen, danken Sie ihnen für ihr Interesse! Ansonsten braucht es nur eine negative Erfahrung, um jemanden nachhaltig abzuschrecken.
  • Antworten Sie schnell. Wenn Sie einen Monat lang nicht auf jemandes Issue reagieren, ist es wahrscheinlich, dass diese Person Ihr Projekt bereits vergessen hat.
  • Nehmen Sie unterschiedliche Arten von Beiträgen an. Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt viele Möglichkeiten, einen Beitrag zu leisten zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten.
  • Wenn es einen Beitrag gibt, mit dem Sie nicht einverstanden sind, bedanken Sie sich trotzdem, aber erklären warum die Idee nicht in den Projektrahmen passt. Verlinken Sie auf relevante Dokumentation, wenn vorhanden.

Die Mehrheit der Open-Source-Mitwirkenden sind “Gelegenheitsmitwirkende”: Personen, die nur gelegentlich an einem Projekt mitarbeiten. Möglicherweise haben sie nicht die Zeit, sich mit Ihrem Projekt vertraut zu machen. Daher ist es Ihre Aufgabe, es Leuten leicht zu machen, einen Beitrag zu leisten.

Andere zur Mitarbeit zu ermutigen, ist auch eine Investition in sich selbst: Wenn Sie Ihre größten Fans dazu befähigen, mit an etwas zu arbeiten, das sie begeistert, stehen Sie unter weniger Druck, alles selbst zu erledigen.

Dokumentieren Sie alles

Wenn Sie ein neues Projekt starten, mag es sich normal anfühlen, Ihre Arbeit privat zu halten. Aber Open-Source-Projekte gedeihen, wenn Sie Ihren Prozess öffentlich dokumentieren.

Wenn Sie Dinge aufschreiben, können mehr Leute an jedem Schritt des Weges teilnehmen. Vielleicht bekommen Sie Hilfe zu etwas, von dem Sie nicht einmal wussten, dass Sie es brauchen.

Dinge aufzuschreiben, ist mehr als nur technische Dokumentation. Wenn Sie den Drang verspüren, etwas aufzuschreiben oder Ihr Projekt privat zu diskutieren, fragen Sie sich, ob Sie es nicht doch öffentlich machen können.

Seien Sie transparent, was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben.

Wenn Sie feststellen, dass mehrere Benutzer*innen auf das gleiche Problem stoßen, dokumentieren Sie die Antworten in der README.

Ziehen Sie in Betracht, Besprechungsnotizen oder Schlussfolgerungen zu veröffentlichen. Die Rückmeldungen, die Sie aufgrund dieser Transparenz erhalten, könnten Sie überraschen.

Alles zu dokumentieren, gilt auch für Ihre Arbeit. Wenn Sie an einem umfangreichen Update Ihres Projekts arbeiten, erstellen Sie früh einen Pull Request und kennzeichnen Sie ihn als “Work in Progress” (WIP). So fühlen sich andere Personen frühzeitig in den Prozess eingebunden.

Antworten Sie schnell

Wenn Sie für Ihr Projekt werben, werden Sie sicherlich Rückmeldungen geben - vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder wo sie Hilfe für die Benutzung finden können.

Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnelle Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen.

Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft eine frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an Middleman:

Pull Request an Middleman

Eine Mozilla-Studie fand heraus, dass Mitwirkende, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen.

Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wie z.B. auf Stack Overflow, Twitter oder Reddit. Dort können Sie Benachrichtigungen einrichten, um über Erwähnungen Ihres Projektes informiert zu werden.

Geben Sie Ihrer Gemeinschaft einen Ort, an dem sie sich versammeln kann.

Es gibt zwei Gründe, Ihrer Gemeinschaft einen Ort der Begegnung zu geben.

Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jeder die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen.

Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten keinen öffentlichen Ort geben, um über Ihr Projekt zu sprechen, werden sie wahrscheinlich direkt mit Ihnen in Verbindung treten. Am Anfang mag es einfach erscheinen, hin und wieder mal auf private Nachrichten zu antworten, aber mit der Zeit, besonders wenn Ihr Projekt populär wird, werden Sie sich erschöpft fühlen und der Versuchung widerstehen, mit Leuten über Ihr Projekt privat zu kommunizieren, anstatt sie an einen bestimmten öffentlichen Kanal zu verweisen.

Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder gleich alles auf einmal!

Kubernetes’ Kops legt alle zwei Wochen Bürozeiten fest, um den Mitglieder*innen der Gemeinschaft zu helfen:

Die Kops-Betreuer*innen haben sich bereit erklärt, Zeit einzuplanen für die Arbeit mit Neuankömmlingen, die Unterstützung von Pull Requests, sowie für die Diskussion über neue Funktionen.

Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.

Wichtige Ausnahmen von öffentlicher Kommunikation sind: 1) Sicherheitsprobleme und 2) Verstöße gegen den Verhaltenskodex; Sie sollten immer eine Möglichkeit anbieten, solche Probleme privat zu melden. Wenn Sie Ihre persönliche E-Mail-Adresse dafür nicht verwenden möchten, richten Sie eine dedizierte Adresse ein.

Ihre Nutzergemeinschaft vergrößern

Eine Gemeinschaft kann sehr kraftvoll sein. Dies kann zu Segen und Fluch werden, je nach Art der Nutzung. Wenn die Projektgemeinschaft wächst, gibt es Möglichkeiten, ihr zu einer konstruktiven Kraft zu verhelfen, anstatt zu einer destruktiven.

Dulden Sie keine destruktiven Akteure

Jedes populäre Projekt wird unweigerlich Menschen anziehen, die Ihrer Gemeinschaft mehr schaden als helfen. Beispielsweise indem Sie können unnötige Debatten starten, über triviale Dinge streiten oder andere schikanieren.

Tun Sie Ihr Bestes, um eine Null-Toleranz-Politik gegenüber solchen Leuten zu verfolgen. Denn wenn obiges Verhalten unsanktioniert bleibt, werden andere Kontributor*innen sich genervt fühlen und evtl. sogar Ihr Projekt verlassen.

Regelmäßige Debatten über triviale Aspekte Ihres Projekts lenken alle davon ab, sich auf wichtige Aufgaben zu konzentrieren. Neue Leute, die zu Ihrem Projekt kommen, können diese Gespräche sehen und wollen nicht teilnehmen.

Wenn Sie ein destruktives Verhalten in Ihrem Projekt beobachten, sprechen Sie es öffentlich an. Erklären Sie freundlich aber bestimmt, warum so etwas nicht akzeptabel ist. Wenn das Problem weiterbesteht, müssen Sie die Verursacher*innen bitten, das Projekt zu verlassen, Ihr Verhaltenskodex kann eine konstruktive Anleitung für solche Gespräche sein.

Holen Sie Mitwirkende dort ab, wo sie sich stehen

Eine gute Dokumentation wird immer wichtiger, je mehr Ihre Community wächst. Mitwirkende, die nur gelegentlich Beiträge leisten und damit mit Ihrem Projekt nicht zwingend vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen.

Geben Sie in Ihrer CONTRIBUTING-Datei explizit an, wie sie anfangen sollen. Vielleicht möchten Sie sogar eine eigene Sektion für diesen Zweck einrichten: Django zum Beispiel, hat eine spezielle Startseite, die neue Mitwirkende willkommen heißt.

Djangos Startseite für neue Mitwirkende

Die Liste der Issues sollte durchsortiert sein, Bugs z.B. als solche markiert, sowie Issues auch für unterschiedliche potentielle Kontributor*innen: z.B. “first timers only”, “good first issue”, oder “documentation”. Solche “Labels” vereinfachen es Neuankömmlingen, sich in Ihrem Projekt zurechtzufinden und mit der Lösung eines Problems zu beginnen.

Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen zu empfangen und ihnen Schritt-für-Schritt zu helfen.

Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen, nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht.

Zum Beispiel: Rubinius beginnt den Kontributionsratgeber mit:

Zum Einstieg möchten wir Dir erstmal unseren Dank aussprechen, dass Du Rubinius nutzt. Dieses Projekt wurde mit viel Liebe aufgebaut und wir schätzen alle Benutzer*innen, die Fehler aufspüren, Geschwindigkeitsverbesserungen vornehmen und bei der Dokumentation helfen. Jeder Beitrag bedeutet uns etwas, also vielen Dank für Ihre Teilnahme! Wir bitten Sie jedoch, einige Richtlinien zu befolgen, damit wir Ihr Issue erfolgreich bearbeiten können.

We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.

Teilen Sie die Eigentümerschaft an Ihrem Projekt

Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch schenken, desto eher werden diese bei Ihrem Projekt bleiben.

Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmern*innen zu teilen:

  • Lassen Sie einfache (unkritische) Bugs unangetastet. Nutzen Sie diese stattdessen als Gelegenheit, neue Mitwirkende zu rekrutieren, oder helfen Sie einem hilfsbereiten Neuling, den Prozess eines Bug-Fixes zu durchlaufen. Es mag zunächst unnatürlich erscheinen, aber Ihre Investition wird sich im Laufe der Zeit auszahlen. @michaeljoseph hat zum Beispiel einen Mitwirkenden gebeten, einen Pull Request zu einem der folgenden Probleme in Cookiecutter zu stellen, anstatt es selbst zu beheben.

Cookiecutter-Issue

  • Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei Sinatra.

  • Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, senden Sie eine Rundmail oder schreiben ins Blog, dass Sie Kontributor*innen danken. Rusts This Week in Rust und Hoodies Shoutout-Grüße sind zwei gute Beispiele dafür.

  • Geben Sie allen Mitwirkenden Schreibzugriff. @felixge fand heraus, dass dies Leute zu mehr Feinschliff ihrer Beiträge anspornt, und gewann sogar neue Maintainer*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete.

  • Wenn Ihr Projekt auf GitHub liegt, verschieben Sie es von Ihrem Privat-Konto in das einer Organisation und fügen Sie zur Sicherheit mindestens eine*n weitere*n Administrator*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher.

Realistischerweise haben die meisten Projekte nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer*innengemeinschaft, desto einfacher wird es sein, Hilfe zu finden.

Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen.

Konflikte beilegen

In der Anfangsphase Ihres Projekts ist es einfach, wichtige Entscheidungen zu treffen: Wenn Sie etwas tun wollen, dann tun Sie es einfach.

Je beliebter Ihr Projekt wird, desto mehr Menschen werden sich für von Ihnen getroffene Entscheidungen interessieren. Selbst wenn Sie keine große Gemeinschaft von Mitwirkenden haben: Wenn Ihr Projekt viele Benutzer*innen hat, werden darunter Leute sein, die sich über Entscheidungen auslassen oder ihre eigenen Themen ansprechen.

Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist.

Setzen Sie die Messlatte für Freundlichkeit

Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an anderen oder an Ihnen auslassen.

Ihre Aufgabe als Maintainer*in ist es, solche Situationen vor einer Eskalation zu schützen. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, handeln Sie sofort, um die Diskussionen zivil und produktiv zu halten.

Andere Leute erwarten von Ihnen, ein gutes Beispiel abzugeben. Sie können immer noch Enttäuschung, Unzufriedenheit oder Besorgnis ausdrücken, aber tun Sie dies auf eine ruhige Art und Weise.

Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird Ihnen dafür danken!

Nutzen Sie die README als Verfassung

Ihre README-Datei ist mehr als nur eine Anleitung. Sie ist auch das Dokument, das Ihre Ziele, Ihre Produktvision und Ihre Roadmap aufzeigt. Wenn die Leute sich zu sehr darauf konzentrieren, über die Vorzüge einer bestimmten Funktion zu diskutieren, kann es helfen, Ihre README zu überprüfen und das überragende Ziel Ihres Projekts anzusprechen. Der Verweis auf Ihre README entpersönlicht eine Diskussion auch, sodass Sie wieder konstruktiver geführt werden kann.

Der Weg ist das Ziel

Einige Projekte eigene “Abstimmungsprozesse”, um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen anderer einzugehen.

Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jeder mit ab, z.B. weil es ein stille Mehrheit in Ihrer Gemeinschaft geben könnte, oder neue Benutzer*innen einfach nicht wussten, dass eine Abstimmung stattfindet.

Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Versuchen Sie daher - so gut es geht - die Konsensfindung statt den Konsens selbst zu betonen.

Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein. Wenn dann nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erlaubt auch, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion.

Auch wenn Sie als Projektbetreuer*in keine Konsensfindung betreiben möchten, ist es wichtig, dass die Leute ein offenes Ohr bei Ihnen finden. Anderen zuzuhören, und sich für die Lösung ihrer Probleme einzusetzen, hilft beim Entschärfen sensibler Situationen sehr. Lassen Sie Ihren Worten aber auch Taten folgen.

Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jeder sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen.

Halten Sie Diskussionen fokussiert auf Aktionen

Diskussionen sind wichtig, aber es gibt einen Unterschied zwischen produktiven und unproduktiven Gesprächen.

Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar wird, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion.

Die Fortsetzung solcher Diskussionen ist nicht nur schlecht für das jeweilige Thema, sondern auch für die Gesundheit Ihrer Gemeinschaft. Die Botschaft zu vermitteln, dass unproduktive Diskussionen erlaubt oder sogar gefördert werden, könnte Leute zukünftig davon abgehalten werden, Probleme anzusprechen oder zu lösen.

Bei jedem Diskussionsbeitrag ihrerseits, oder von anderen, sollten Sie sich fragen “Wie bringt uns dies einer Lösung näher?”

Falls die Diskussion abdriftet, fragen Sie die Teilnehmer*innen: “Welche Schritte sollten wir als nächstes gehen?”, um sie wieder zu fokussieren.

Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnahmen zu ergreifen gibt, oder schon welche ergriffen wurden, schließen Sie das Issue und erklären Sie, warum Sie es geschlossen haben.

Wählen Sie Auseinandersetzungen mit Bedacht

Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Teilnehmer*innen den Rest der Gemeinschaft repräsentieren.

Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Ist er oder sie ein*e einzelne*r Unruhestifter*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder*innen nicht.

Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue.

Identifizieren Sie einen Community-Tiebreaker

Mit einer positiven Herangehensweise und klarer Kommunikation sind selbst die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die als Schiedsrichter*in fungieren kann.

Ein*e solche*r Schiedsrichter*in kann die oder der Hauptverantwortliche für das Projekt sein, oder eine kleine Gruppe von Leuten, die über eine Entscheidung abstimmen. Idealerweise haben Sie einen Tiebreaker und den damit verbundenen Prozess in einer GOVERNANCE-Datei identifiziert, bevor Sie diese verwenden müssen.

Ihr*e Schiedsrichter*in sollte der letzte Ausweg sein, denn zunächst entzweiend wirkende Probleme sind eine Chance für Ihre Gemeinschaft, zu wachsen und zu lernen. Nutzen Sie diese Möglichkeiten, um in einem gemeinsamen Prozess zu einer Lösung zu kommen, wo immer dies möglich ist.

Das ❤️ von Open-Source sind Gemeinschaften

Gesunde, blühende Gemeinschaften sorgen für den Antrieb für Tausende von Stunden, die jede Woche in Open-Source gesteckt werden. Viele Mitwirkende verweisen auf andere Menschen als Grund dafür, an Open-Source zu arbeiten (oder eben nicht). Indem Sie lernen, diese Kraft konstruktiv zu nutzen, werden Sie jemandem da draußen helfen, ein unvergessliches Open-Source-Erlebnis zu haben.