Tipps für ein beliebtes Open-Source-Projekt
(skerritt.blog)<p>„Netzwerkeffekt: Je mehr Menschen danach suchen, desto mehr Nutzer gibt es, desto mehr beteiligen sie sich, desto besser werden die Funktionen und desto bekannter wird es.“<br />
Wie schafft man es also, beliebt zu werden?<br />
<br />
#1. Eine gut gestaltete README <br />
- Gleich am Anfang kurz und prägnant erklären <br />
→ Was macht es?<br />
→ Löst es mein Problem?<br />
→ Löst es mein Problem besser als die Konkurrenz?<br />
→ Wie installiere ich es?<br />
→ Welche grundlegenden Befehle muss ich kennen?<br />
→ Wohin gehe ich, wenn ich Hilfe brauche?<br />
<br />
1.1 Einen Header erstellen, der das Projekt zusammenfasst <br />
→ Logo: Ein GIF-Logo kann man zum Beispiel mit Canva erstellen <br />
→ Slogan: Das Projekt in einer Zeile beschreiben. In die GitHub-Beschreibung übernehmen<br />
⇨ Sollte sofort ins Auge fallen<br />
⇨ Warum Nutzer das brauchen <br />
⇨ Warum es besser ist als andere <br />
⇨ Leicht verständlich <br />
⇨ Beispiel: hugo : The world’s fastest framework for building websites<br />
→ Badges: Kleine Bilder/Links, die das Projekt beschreiben <br />
⇨ Zuletzt aktive Änderungen, Download-Zahlen, wie viele Leute im Chat sind, unterstützte Versionen, Lizenz usw. <br />
→ Schnelle Installation: Den einfachen und schnellen Installationsbefehl sofort sichtbar machen<br />
⇨ Wer schon weiß, worum es geht, kann es direkt ausprobieren <br />
⇨ Dinge wie „mit Docker/PIP in einer Zeile installierbar“ möglichst weit oben zeigen <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Quick Links (nicht zwingend)<br />
⇨ Website, Forum, Dokumentation, Installationsanleitung, Contribution Guide, Twitter usw.<br />
<br />
1.2 „What is This?“ – das Projekt kurz erklären <br />
→ Kurze Beschreibung + GIF, das das Projekt in Aktion zeigt + die wichtigsten Funktionen, die Leute sehen wollen <br />
→ Beispiel: Starship: zwei Spalten, links die Kernfunktionen, rechts ein GIF der Nutzung <br />
→ Man muss nicht alle Funktionen zeigen. Nur das auflisten, was Nutzer sehen wollen, und leicht verständlich erklären <br />
<br />
1.3 „X vs Y“ – mit Konkurrenzprodukten vergleichen <br />
→ Es muss klar werden, warum man dieses Projekt statt der Konkurrenz wählen sollte <br />
→ Die Vorteile sollten leicht erkennbar sein<br />
→ Ähnlich wie im Lean Startup, wo man zuerst „Early Adopters“ statt „durchschnittlicher Nutzer“ finden sollte <br />
⇨ Wenn es bessere Funktionen gibt, sind das Menschen, die nicht zögern, auf ein neues Tool umzusteigen <br />
→ Nur wenn es gar keine Konkurrenz gibt oder aktuelle Lösungen im Vergleich zu deiner Lösung extrem kompliziert sind, sollte man auf „durchschnittliche Nutzer“ zielen <br />
→ Am einfachsten ist eine Vergleichstabelle mit Kernfunktionen<br />
⇨ Lieber Zahlen als Worte verwenden <br />
⇨ Es ist auch gut, die Funktionsweise per GIF zu vergleichen <br />
<br />
1.4 Hervorragende Dokumentation erstellen <br />
→ Man muss nicht die gesamte Dokumentation in die README packen. Das erschwert Aktualisierung und Suche und macht die README unübersichtlich <br />
→ Die Installation wurde oben schon erklärt, zusätzlich zeigen sollte man <br />
⇨ wie man es ausführt<br />
⇨ wo die Dokumentation zu finden ist<br />
⇨ wie man Support bekommt <br />
→ Die Nutzung kann man auch gut per GIF zeigen <br />
<br />
1.5 Erklären, wie man beiträgt, und Mitwirkende würdigen und willkommen heißen <br />
→ Wie man zum Projekt beiträgt<br />
→ Frühere Mitwirkende würdigen <br />
→ Bots wie all-contributors verwenden <br />
<br />
#2. Etwas bauen, das Menschen wollen <br />
→ Eine gute README weckt Interesse, und ein Projekt, das das „Problem löst“, bringt die Leute zum Reden <br />
<br />
2.1 Erst das Problem, dann das Produkt<br />
→ Nicht etwas bauen, nur um ein Produkt zu machen, sondern um ein Problem zu lösen <br />
→ „Fortschritt kommt nicht nur durch große Sprünge, sondern auch durch Hunderte kleiner Schritte.“<br />
<br />
2.2 Mit dem Problem leben <br />
→ Wenn es kein Problem gibt, kann man es nicht effektiv lösen <br />
→ Statt zufällig Ideen zu generieren, ist es viel einfacher, Probleme im eigenen Leben zu beobachten <br />
→ Wenn man merkt, dass es ein Problem gibt, weiß man zwei Dinge: Das Problem ist real, und andere haben es wahrscheinlich auch.<br />
<br />
2.3 Probleme in der Community finden <br />
→ Wenn man in Communities hineinschaut, sieht man oft, welche Probleme Menschen offen ansprechen <br />
→ Je mehr Menschen es gibt und je mehr man zuhört, desto mehr Ideen entstehen, als wenn man nur selbst nachdenkt <br />
→ Ein MVP (Minimum Viable Product) bauen, das ein Problem der Community löst <br />
→ Es mit der Community teilen, die Wirkung messen, lernen, es besser zu machen, und dann neu bauen oder ergänzen und verbessern <br />
<br />
#3. Es nach draußen tragen <br />
→ Selbst wenn es gut gemacht ist: Wenn man es nicht veröffentlicht, sieht es niemand <br />
→ Wenn man vorher schon mit einer Community gearbeitet hat, kennen sie es zum Glück bereits und werden es nutzen <br />
→ Einen GitHub Star von 0 auf 1 zu bringen ist schwer, von 10 auf 100 dagegen leicht <br />
<br />
3.1 In der Community teilen <br />
→ Build, Measure, Learn-Schleife <br />
→ Beim ersten echten Release sollte die Community unbedingt davon erfahren. Sie wird es mit Freunden teilen<br />
<br />
3.2 News Aggregators <br />
→ Passende Subreddits <br />
→ HackerNews (Anmerkung des Übersetzers im Original: GeekNews auch!)<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Eine thematisch passende Liste finden und einen PR schicken </p>
2 Kommentare