LaunchRepoKurze Antwort
- Fang beim Repository selbst an: ein README, das Was, Warum und den Einstieg beantwortet, eine Lizenz, bis zu 20 GitHub-Topics und ein Social-Preview-Bild.
- Geh dann dorthin, wo deine Nutzer schon reden: ins Forum, in den Chat oder das Subreddit deiner Sprache oder deines Frameworks, und zu Show HN, sobald man das Projekt ohne Anmeldung ausführen kann.
- Frag bei den Maintainern von ein oder zwei passenden Awesome-Listen an und halte dich an die Beitragsregeln der jeweiligen Liste.
- Trag eine Website oder gehostete Version in einige Verzeichnisse und Launch-Plattformen ein und veröffentliche weiter Releases. Stetige Aktivität bringt immer neue Besucher.
Die Distributionskarte für Open Source
Open Source wird auf vier Ebenen entdeckt. Jede baut auf der vorherigen auf: Ein Community-Beitrag schickt Leute auf dein Repository, also muss das Repository sie zuerst überzeugen.
- 1 · Das RepositoryWas jeder Besucher zuerst sieht.
- README
- Lizenz
- Topics
- Social Preview
- Releases
- 2 · Entdeckung auf GitHubWie man dich innerhalb von GitHub findet.
- Topic-Seiten
- GitHub-Suche
- Explore
- Sterne und Listen
- 3 · CommunitysWo deine Nutzer schon reden.
- Show HN
- Foren und Chats des Ökosystems
- Subreddits
- Antworten auf Fragen
- 4 · Kuratiert und gelistetOrte, die dauerhaft auf dich verweisen.
- Awesome-Listen
- Paket-Registries
- Verzeichnisse
- Newsletter
Erstelle deinen Vier-Wochen-Plan
Beantworte acht Fragen und füge deine Topics ein. Der Planer prüft die Topics gegen GitHubs Regeln und ordnet jeden Kanal einer Woche zu, markiert als bereit oder mit dem, was du zuerst beheben solltest. Alles läuft in deinem Browser; nichts wird gesendet oder gespeichert.
Mach das Repository auffindbar
Jeder Kanal auf dieser Seite endet auf deiner Repository-Seite. GitHubs eigene Dokumentation nennt, was ein README beantworten sollte; die Tabelle macht daraus konkreten Inhalt für den ersten Bildschirm.
| Teil | Was der Besucher braucht | Was funktioniert |
|---|---|---|
| Was es tut | In Sekunden entscheiden, ob es zum eigenen Problem passt | Ein Satz unter dem Titel, in den Worten, nach denen deine Nutzer suchen würden |
| Warum es nützlich ist | Ein Grund, es der naheliegenden Alternative vorzuziehen | Ein konkreter Unterschied oder ein kurzer Vergleich |
| Wie man anfängt | Ein erster Erfolg innerhalb von Minuten | Ein Installationsbefehl und ein minimales Beispiel, das beim Einfügen läuft |
| Zeig es in Aktion | Ein Beweis vor der Installation | Ein Screenshot, GIF oder Terminal-Mitschnitt weit oben |
| Wo es Hilfe gibt | Vertrauen, dass man nicht allein gelassen wird | Verlinke Issues, Discussions oder einen Chat; sag, was wohin gehört |
| Wer es pflegt | Sicherheit, dass das Projekt lebt | Maintainer, aktuelles Release, Beitragsleitfaden |
Topics: bis zu 20 Türen in die GitHub-Suche
- Misch die vier Arten, die GitHub vorschlägt: Zweck (cli, static-site-generator), Thema (accessibility), Community (hacktoberfest) und Sprache (rust).
- Nutze Topics, die Leute wirklich durchstöbern. Öffne github.com/topics/ und prüfe, ob ein Topic schon Repositorys enthält.
- GitHub schlägt für öffentliche Repositorys auch selbst Topics vor. Übernimm die passenden und lehne den Rest ab.
Social Preview
Ohne Bild zeigt ein geteilter Link nur einfache Repository-Daten und deinen Avatar. Ein klares Bild in 1280 × 640 mit Projektnamen und einer Zeile zum Zweck macht jedes Teilen wiedererkennbar. Prüf Größe und Format vor dem Hochladen im kostenlosen Bildgrößen-Checker. Prüfe deine Launch-Bilder gegen die Größenvorgaben der Plattformen →
| Regel | Offizieller Wortlaut | Was das für dich heißt |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Behandle das README als deine Landingpage: Der erste Bildschirm entscheidet, ob Leute bleiben. |
| README-Größe | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | Lange READMEs werden abgeschnitten. Verschieb ausführliches Referenzmaterial in die Doku und verlinke es. |
| Topic-Arten | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Wähl Topics über Zweck, Thema, Community und Sprache hinweg, nicht zehn Varianten eines Wortes. |
| Topic-Format | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | Der Checker im Planer wendet genau diese drei Regeln an. |
| Social Preview | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | Bereite ein PNG oder JPG in 1280 × 640 mit weniger als 1 MB vor. |
| Community-Profil | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | Öffne Insights → Community Standards in deinem Repository und ergänze, was fehlt. |
Awesome-Listen: zwei verschiedene Wege
Awesome-Listen sind kuratierte Sammlungen auf GitHub, eine pro Thema. Die oft zitierten Regeln wie 30 Tage und vier Reviews gelten für einen ganz bestimmten Fall. Wisse, auf welchem Weg du bist.
Weg A: Dein Projekt kommt in eine Themenliste
Das ist der übliche Fall für eine Bibliothek, ein Tool oder eine App. Such ein oder zwei aktive Listen zu deinem Thema, lies die Beitragsdatei dieser Liste und schlag eine Zeile in ihrem Format vor. Listen unterscheiden sich darin, was sie aufnehmen, deshalb gilt ihr eigener Leitfaden. Dein README, deine Lizenz und deine jüngste Aktivität überzeugen den Maintainer.
Weg B: Deine kuratierte Liste kommt in die awesome-Metaliste
Nur wenn du selbst eine Liste pflegst. Dann gilt die strenge Vorlage der Metaliste: mindestens 30 Tage alt, 4 andere offene Pull Requests reviewen, awesome-lint ausführen, eine Lizenz von Creative Commons, die Topics awesome und awesome-list und ein Titel in der Form „Add Name of List“.
| Regel | Offizieller Wortlaut | Was das für dich heißt |
|---|---|---|
| In eine Liste kommen | If you have something awesome to contribute to an awesome list, this is how you do it. | Jede Liste erklärt ihren eigenen Weg. Lies den Beitragsleitfaden dieser Liste, keinen allgemeinen. |
| Alter der Liste | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Nur für Listen, die in die awesome-Metaliste wollen: 30 Tage nach dem ersten echten Commit warten. |
| Reviews | Just commenting “looks good” or simply marking the pull request as approved does not count! | Wer bei der Metaliste einreicht, muss mindestens 4 andere offene Pull Requests mit echtem Feedback reviewen. |
| KI | Fully AI-generated pull requests are not accepted. | Schreib den Pull Request selbst. Ein komplett generierter wird geschlossen. |
| Lizenz | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Eine Liste braucht eine Lizenz von Creative Commons, empfohlen ist CC0. Code-Lizenzen zählen nicht. |
| Qualität | Only has awesome items. Awesome lists are curations of the best, not everything. | Listen nehmen das Beste auf, nicht alles. Dein README und deine Aktivität bringen dich hinein. |
Wir zitieren die Regeln zum geprüften Datum; Maintainer passen sie an. LaunchRepo öffnet keine Pull Requests und kontaktiert keine Listen-Maintainer für dich.
Communitys, die Projekte willkommen heißen
Open Source hat hier einen Vorteil: Viele Entwickler-Communitys freuen sich über ein funktionierendes Projekt, solange es ein echtes Problem löst und du bleibst, um Fragen zu beantworten.
| Kanal | Passt am besten zu | Erster Schritt |
|---|---|---|
| Show HN (Hacker News) | Tools, die man sofort ausführen kann | Einmal posten, im Thread bleiben, jede Frage beantworten |
| Forum oder Chat deines Ökosystems | Bibliotheken und Plugins für eine Sprache oder ein Framework | Showcase-Regeln lesen, dann einen Anwendungsfall posten, keinen Slogan |
| Ein passendes Subreddit | Projekte mit klarem Publikum auf Reddit | Zuerst die Eigenwerbungsregel jedes Subreddits prüfen |
| Antworten auf Fragen | Projekte, die eine wiederkehrende Frage lösen | Die Frage vollständig beantworten; das Projekt nennen, wo es wirklich hilft |
| Wöchentliche Newsletter deines Ökosystems | Releases mit einer Geschichte | Der Redaktion eine kurze Notiz mit dem Release-Link schicken |
| Meetups und Konferenzvorträge | Projekte, aus denen man etwas lernen kann | Bei einem lokalen Meetup deiner Sprache anfangen |
In unserem öffentlichen Datensatz aller 15.859 Beiträge auf Show HN, die zwischen September 2025 und August 2026 auf ein Code-Repository verlinkten, bekam der Median-Beitrag 2 Punkte, und 9,5 % erreichten 10 Punkte oder mehr. Ein Beitrag ist ein Anfang, nicht der Plan.
So launchst du dein Projekt auf Show HN →Dein SaaS auf Reddit bewerben, ohne Regeln zu brechen →
| Regel | Offizieller Wortlaut | Was das für dich heißt |
|---|---|---|
| Was passt | Show HN is for something you've made that other people can play with. | Etwas, das man ausführen kann, keine Ankündigung und keine Landingpage. |
| Substanz | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Poste ein Projekt, in das du echte Arbeit gesteckt hast und über das du reden kannst. |
| Hürden | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Ein öffentliches Repository mit einem Installationsbefehl ist der ideale Show HN. |
| Stimmen | Please don't ask friends to upvote or comment. That's not ok on HN. | Teile den Link ohne Bitte um Stimmen. Lass die Arbeit für sich sprechen. |
| Zielgruppe | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Wähl einige Communitys, in denen das Projekt ein echtes Problem löst. |
| Ruf | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Hilf zuerst in anderen Projekten. Die Leute merken das und schauen sich deins an. |
Verzeichnisse und Launch-Plattformen
Sobald es eine Website, eine Doku-Seite oder eine gehostete Version gibt, werden einige Verzeichnisse zu einer stetigen zusätzlichen Quelle für Besucher und Links. Drei, die gut zu Open Source passen:
- AlternativeTo: wenn dein Projekt eine kostenlose Alternative zu bekannter Software ist.
- SourceForge: hostet Open-Source-Projekte mit Downloads über den Weg „Create a Project“, getrennt von den Einträgen für Business-Software.
- Product Hunt: für Projekte mit ausgefeilter Oberfläche und einem Launch-Tag, an dem du dabei sein kannst.
Wähle Plattformen nach passendem Publikum und prüfe jeweils die aktuellen Regeln; ein Eintrag ist eine Tür, keine Garantie für Nutzer. Lass dein Developer-Tool dort eintragen, wo Entwickler wirklich suchen. →
Was du weglassen solltest
- Gekaufte oder getauschte Sterne
- GitHubs Richtlinien verbieten Ranking-Missbrauch, und Forschung zeigt, dass gekaufte Sterne nur kurz helfen. Die Details, mit unserer eigenen Messung: GitHub-Sterne durch echten Nutzen verdienen →
- Freunde um Upvotes bitten
- Hacker News sagt es klar: Das ist nicht okay. Stimmen aus dem Freundeskreis sagen dir außerdem nichts über echtes Interesse.
- Überall derselbe Beitrag
- Kopierte Ankündigungen in vielen Communitys am selben Tag wirken wie Spam. Wähl wenige Orte und schreib für jeden einzeln.
- Ein Launch vor dem README
- Aufmerksamkeit ist kurz. Bring den ersten Bildschirm des Repositorys in Ordnung, bevor irgendein Beitrag rausgeht.
Wo LaunchRepo hineinpasst
LaunchRepo übernimmt die Ebene der Verzeichnisse und Launch-Plattformen: Dein Coding-Agent bereitet deine Projekt-Website vor und reicht sie bei einem großen Katalog von Verzeichnissen ein, mit einem Tracker, der einen Live-Eintrag von einem ausstehenden unterscheidet.
Community-Beiträge, Anfragen an Awesome-Listen und Gespräche bleiben bei dir, weil sie in deiner eigenen Stimme am besten funktionieren. LaunchRepo spart dir die Stunden, die die Formulare kosten würden, damit du sie dort verbringen kannst.
Quellen
Alle Regeln wurden am 1. Oktober 2026 gelesen und werden wörtlich auf Englisch zitiert. Textkopien liegen bei unseren Belegen.
| Quelle | Zuletzt aktualisiert | Geprüft |
|---|---|---|
| GitHub Docs: About the repository README file | kein Datum angegeben | |
| GitHub Docs: Classifying your repository with topics | kein Datum angegeben | |
| GitHub Docs: Customizing your repository's social media preview | kein Datum angegeben | |
| GitHub Docs: About community profiles for public repositories | kein Datum angegeben | |
| GitHub Docs: Accessing a project's community profile | kein Datum angegeben | |
| GitHub Docs: Saving repositories with stars | kein Datum angegeben | |
| sindresorhus/awesome: pull request template | kein Datum angegeben | |
| sindresorhus/awesome: contribution guidelines | kein Datum angegeben | |
| Hacker News: Show HN Guidelines | kein Datum angegeben | |
| Open Source Guides: Finding Users for Your Project | kein Datum angegeben | |
| GitHub Acceptable Use Policies | kein Datum angegeben | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Häufige Fragen
- Wie mache ich ein Open-Source-Projekt bekannt?
- Fang beim Repository an: ein README, das Was, Warum und den Einstieg beantwortet, eine Lizenz, Topics und ein Vorschaubild. Teile es dann in der Community deines Ökosystems und auf Show HN, sobald man es ohne Anmeldung ausprobieren kann, frag bei ein oder zwei passenden Awesome-Listen an und veröffentliche weiter Releases.
- Wie kommt mein Projekt in eine Awesome-Liste?
- Öffne die Liste, lies ihre Beitragsdatei und schlag einen Eintrag in ihrem Format vor. Die strengen Regeln (30 Tage, vier Reviews, awesome-lint) gelten nur, wenn du deine eigene kuratierte Liste bei der awesome-Metaliste einreichst.
- Wie viele GitHub-Topics sollte ich setzen?
- GitHub erlaubt bis zu 20. Nutze die, die Zweck, Thema, Community und Sprache beschreiben, geschrieben in Kleinbuchstaben, Ziffern und Bindestrichen, jeweils höchstens 50 Zeichen lang.
- Ist Show HN ein guter Ort für Open Source?
- Ja, wenn man das Projekt sofort ausführen kann und du bleibst, um Fragen zu beantworten. Show HN verlangt etwas, das man ausprobieren kann, ohne Anmeldehürden und ohne Bitten an Freunde um Stimmen.
- Sollte ich GitHub-Sterne kaufen, um etabliert zu wirken?
- Nein. GitHubs Acceptable Use Policies verbieten Ranking-Missbrauch wie automatisiertes Vergeben von Sternen, und eine große Studie fand heraus, dass gekaufte Sterne nur kurz helfen und langfristig schaden.
- Postet LaunchRepo für mich in Communitys?
- Nein. LaunchRepo gibt deinem Agenten die Playbooks für Einreichungen bei Verzeichnissen und Launch-Plattformen für die Website deines Projekts. Community-Beiträge und Anfragen an Awesome-Listen bleiben persönlich.
Lass deinen Agenten die Verzeichnisse erledigen
Ein Kauf, dein Coding-Agent, jedes Produkt, das du baust: dein Coding-Agent reicht mit LaunchRepo deine Projekt-Website bei Verzeichnissen und Launch-Plattformen ein, während du mit deinen Nutzern sprichst.
Preise ansehen