LaunchRepoShort answer
- Start with the repository itself: a README that answers what, why and how to start, a licence, up to 20 GitHub topics and a social preview image.
- Then go where your users already talk: the forum, chat or subreddit of your language or framework, and Show HN once people can run it without signing up.
- Ask the maintainers of one or two fitting awesome lists, following each list’s own contribution rules.
- Add a website or hosted version to a few directories and launch platforms, and keep shipping releases. Steady activity keeps new visitors coming.
The distribution map for open source
Open source has four layers of discovery. Each one builds on the one before it: a community post sends people to your repository, so the repository has to convince them first.
- 1 · The repositoryWhat every visitor sees first.
- README
- Licence
- Topics
- Social preview
- Releases
- 2 · GitHub discoveryHow people find you inside GitHub.
- Topic pages
- GitHub search
- Explore
- Stars and lists
- 3 · CommunitiesWhere your users already talk.
- Show HN
- Ecosystem forums and chats
- Subreddits
- Q&A answers
- 4 · Curated and listedPlaces that keep pointing to you.
- Awesome lists
- Package registries
- Directories
- Newsletters
Build your four-week plan
Answer eight questions and paste your topics. The builder checks the topics against GitHub’s rules and puts every channel in a week, marked as ready or with what to fix first. Everything runs in your browser; nothing is sent or stored.
Make the repository findable
Every channel on this page ends on your repository page. GitHub’s own documentation names what a README should answer; the table turns that into concrete first-screen content.
| Part | What the visitor needs | What works |
|---|---|---|
| What it does | Decide in seconds whether it fits their problem | One sentence under the title, in the words your users would search for |
| Why it is useful | A reason to choose it over the obvious alternative | One concrete difference, or a short comparison |
| How to start | A first success within minutes | One install command and one minimal example that runs as pasted |
| Show it working | Proof before they install | A screenshot, GIF or terminal recording near the top |
| Where to get help | Trust that they will not be left alone | Link Issues, Discussions or a chat; say what goes where |
| Who maintains it | Confidence that it is alive | Maintainers, recent release, contribution guide |
Topics: up to 20 doors into GitHub search
- Mix the four kinds GitHub suggests: purpose (cli, static-site-generator), subject (accessibility), community (hacktoberfest) and language (rust).
- Use the topics people really browse. Open github.com/topics/ and check that a topic already has repositories in it.
- GitHub also proposes topics for public repositories. Accept the ones that fit and reject the rest.
Social preview
Without an image, a shared link shows basic repository facts and your avatar. A clear 1280 × 640 image with the project name and one line of purpose makes every share recognizable. Check the size and format in the free image size checker before you upload. Check your launch images against platform size specs →
| Rule | Official wording | What it means for you |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Treat the README as your landing page: the top screen decides whether people stay. |
| README size | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | Long READMEs get cut. Move deep reference material into docs and link it. |
| Topic kinds | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Pick topics across purpose, subject, community and language, not ten variants of one word. |
| Topic format | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | The checker in the plan builder applies exactly these three rules. |
| 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). | Prepare a 1280 × 640 PNG or JPG under 1 MB. |
| Community profile | 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. | Open Insights → Community Standards in your repository and add what is missing. |
Awesome lists: two different routes
Awesome lists are curated collections on GitHub, one per topic. The rules that are often quoted, such as 30 days and four reviews, apply to one specific case. Know which route you are on.
Route A: your project goes into a topic list
This is the usual case for a library, tool or app. Find one or two active lists for your topic, read that list’s contributing file, and propose one line in its format. Lists differ in what they accept, so their own guide is the rule. Your README, licence and recent activity are what convince the maintainer.
Route B: your curated list goes into the awesome meta-list
Only if you maintain a list yourself. Then the strict meta-list template applies: at least 30 days old, review 4 other open pull requests, run awesome-lint, a Creative Commons licence, the awesome and awesome-list topics and a title in the form “Add Name of List”.
| Rule | Official wording | What it means for you |
|---|---|---|
| Adding to a list | If you have something awesome to contribute to an awesome list, this is how you do it. | Each list explains its own route. Read that list’s contribution guide, not a general one. |
| List age | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Only for lists that want into the awesome meta-list: wait 30 days after the first real commit. |
| Reviews | Just commenting “looks good” or simply marking the pull request as approved does not count! | Meta-list submitters must review at least 4 other open pull requests, with real feedback. |
| AI | Fully AI-generated pull requests are not accepted. | Write the pull request yourself. A fully generated one is closed. |
| Licence | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | A list needs a Creative Commons licence, CC0 recommended. Code licences do not count. |
| Quality | Only has awesome items. Awesome lists are curations of the best, not everything. | Lists include the best, not everything. Your README and activity are what get you in. |
We quote the rules as of the checked date; maintainers update them. LaunchRepo does not open pull requests or contact list maintainers for you.
Communities that welcome projects
Open source has an advantage here: many developer communities are happy to see a working project, as long as it solves a real problem and you stay to answer questions.
| Channel | Best fit | First step |
|---|---|---|
| Show HN (Hacker News) | Tools people can run right away | Post once, stay in the thread, answer every question |
| Your ecosystem’s forum or chat | Libraries and plugins for one language or framework | Read the showcase rules, then post a use case, not a slogan |
| A fitting subreddit | Projects with a clear audience on Reddit | Check each subreddit’s self-promotion rule first |
| Q&A answers | Projects that solve a recurring question | Answer the question fully; mention the project where it truly helps |
| Weekly newsletters of your ecosystem | Releases with a story | Send a short note with the release link to the editors |
| Meetups and conference talks | Projects with a lesson to teach | Start at a local meetup of your language |
In our public dataset of all 15,859 Show HN posts that linked a code repository between September 2025 and August 2026, the median post got 2 points and 9.5% reached 10 points or more. One post is a start, not the plan.
How to launch on Show HN →Promote your SaaS on Reddit without breaking the rules →
| Rule | Official wording | What it means for you |
|---|---|---|
| What fits | Show HN is for something you've made that other people can play with. | Something people can run, not an announcement or a landing page. |
| Substance | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Post a project you put real work into and can talk about. |
| Barriers | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | A public repository with one install command is the ideal Show HN. |
| Votes | Please don't ask friends to upvote or comment. That's not ok on HN. | Share the link with no request to vote. Let the work speak. |
| Targeting | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Choose a few communities where the project solves a real problem. |
| Reputation | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Help in other projects first. People notice and look at yours. |
Directories and launch platforms
Once there is a website, documentation site or hosted version, a few directories become a steady extra source of visitors and links. Three that suit open source well:
- AlternativeTo: when your project is a free alternative to well-known software.
- SourceForge: hosts open source projects with downloads through its Create a Project route, separate from its business software listings.
- Product Hunt: for projects with a polished interface and a launch day you can attend.
Pick platforms by audience fit and check each one’s current rules; a listing is a door, not a guarantee of users. Get your developer tool listed where developers actually look. →
What to leave out
- Bought or swapped stars
- GitHub’s policies forbid rank abuse, and research shows bought stars help only briefly. The details, with our own measurement: Earning GitHub stars through real usefulness →
- Asking friends to upvote
- Hacker News says it plainly: that is not ok. Votes from a group of friends also tell you nothing about real interest.
- The same post everywhere
- Copy-pasted announcements in many communities on one day read as spam. Pick a few places and write for each one.
- A launch before the README
- Attention is short. Fix the first screen of the repository before any post goes out.
Where LaunchRepo fits
LaunchRepo takes care of the directory and launch platform layer: your coding agent prepares and submits your project website to a large catalog of directories, with a tracker that tells a live listing from a pending one.
Community posts, awesome list requests and conversations stay with you, because they work best in your own voice. LaunchRepo frees the hours the forms would take, so you can spend them there.
Sources
All rules were read on October 1, 2026 and are quoted word for word in English. Text copies are kept with our evidence.
| Source | Last updated | Checked |
|---|---|---|
| GitHub Docs: About the repository README file | no date given | |
| GitHub Docs: Classifying your repository with topics | no date given | |
| GitHub Docs: Customizing your repository's social media preview | no date given | |
| GitHub Docs: About community profiles for public repositories | no date given | |
| GitHub Docs: Accessing a project's community profile | no date given | |
| GitHub Docs: Saving repositories with stars | no date given | |
| sindresorhus/awesome: pull request template | no date given | |
| sindresorhus/awesome: contribution guidelines | no date given | |
| Hacker News: Show HN Guidelines | no date given | |
| Open Source Guides: Finding Users for Your Project | no date given | |
| GitHub Acceptable Use Policies | no date given | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Frequently asked questions
- How do I promote an open source project?
- Start with the repository: a README that answers what, why and how to start, a licence, topics and a preview image. Then share it in your ecosystem’s community and on Show HN once people can try it without signing up, ask one or two fitting awesome lists, and keep releasing.
- How do I get my project into an awesome list?
- Open the list, read its contributing file and propose one entry in its format. The strict rules (30 days, four reviews, awesome-lint) apply only when you submit your own curated list to the awesome meta-list.
- How many GitHub topics should I add?
- GitHub allows up to 20. Use the ones that describe purpose, subject, community and language, written in lowercase letters, numbers and hyphens, each 50 characters or less.
- Is Show HN a good place for open source?
- Yes, if people can run the project right away and you can stay to answer questions. Show HN asks for something people can try, without sign-up barriers, and no requests to friends for votes.
- Should I buy GitHub stars to look established?
- No. GitHub’s Acceptable Use Policies forbid rank abuse such as automated starring, and a large study found that bought stars help only briefly and hurt in the long run.
- Does LaunchRepo post to communities for me?
- No. LaunchRepo gives your agent the playbooks for directory and launch platform submissions for your project’s website. Community posts and awesome list requests stay personal.
Let your agent handle the directories
One purchase, your coding agent, every product you build: your coding agent uses LaunchRepo to submit your project website to directories and launch platforms while you talk to your users.
See pricing