Launch Playbook for Open-Source Maintainers: Users First, Then Contributors
An open-source maintainer launches by making the repository work as the product page, tagging a release, and announcing it where people who have the problem will try it. Users come first, since contributors usually start as users. Prepare for the inflow before you post: a short README, a contributing file and a rule for saying no, because your scarce resource is attention.
Why is the repository your landing page?
A visitor who clicks a link to your project lands on the repository, not on a marketing site. They decide in a minute whether it solves their problem, so the top of the README does the selling. Write it for someone who has never heard of the project, and order it by what they ask: what is this, does it work for my case, how do I run it, what does it look like when it runs.
- One sentence that names the problem, not the technology. “Checks Markdown links in a docs folder and fails the build on a dead one” beats “a modern link checker.”
- An install and run command that works on a clean machine. Test it on one.
- An output sample: a screenshot, a few lines of terminal output or a minimal example.
- A license in the repository, so people know whether they may use it. Choosing one is a decision to make before launch, not after the first fork.
- A status line that says how stable it is, so nobody builds on an experiment by mistake.
The README template and the open-source launch checklist turn this into a copyable structure.
Should you look for users or contributors first?
Users. The Open Source Guides make the point that people become involved as users and later become contributors because the project solves a problem for them. They also say plainly that nothing requires you to promote a project at all, and that there are good reasons to work in open source with no interest in popularity. Decide which camp you are in. If you want it used, you have to go and tell people.
Read the guide’s chapter on finding users (read on 13 November 2026) alongside this page; it covers messaging and where a project’s audience gathers. The short version for a launch is to write down the three kinds of person who would benefit, and go where each one already reads.
How do you protect your time before attention arrives?
A launch sends strangers to your issue tracker, and every message is a small claim on your evenings. Decide your rules while you are calm, then publish them where people will see them.
- A contributing file that says how to report a bug, what a good report contains and what kinds of change you will not accept.
- Issue templates that ask for the version, the steps and the expected result, so you spend fewer messages on the basics.
- A stated response time, honest and modest: “I read issues on weekends” is better than a promise you cannot keep.
- Two or three labelled starter issues, small and well described, so a willing newcomer has somewhere to begin.
- A calm way to say no. Write one paragraph for “this is out of scope” and reuse it.
What does a two-week window around a release look like?
| Days | Action | Why then |
|---|---|---|
| 1 to 3 | Fix the README and test the install on a clean machine | A broken first command loses more visitors than any missing feature |
| 4 | Tag a release and publish the package where your language looks for it | People install from the registry or the release page, not from main |
| 5 | Publish on the free launch board with the repository as the link | A stable public address for the project, live as soon as the emailed link is confirmed |
| 6 to 7 | Post a Show HN if people can try it right away, then stay for the thread | Its guidelines ask for work others can try, and for you to be around to discuss it |
| 8 to 14 | Answer issues, merge small fixes, note repeated questions | Fast, friendly early replies decide who comes back |
For more places that accept a repository, see where to launch an open-source project and the open-source launch playbook.
What should maintainers avoid?
- Asking for stars. A star is not a user. Ask for a bug report, which is worth more.
- Buying or trading attention. Fake stars and favour swaps break the rules of most places and damage trust in a project that depends on it.
- A funding ask in the first post. Ask once the project has users who might care.
- Over-promising a roadmap. Say what exists today. A short “not yet” list is more believable than a long future.
If you are still deciding what to build, the developer tool ideas other people have posted are a source of real problems that maintainers could take on.
Frequently asked questions
Do I need a website to launch an open-source project?
Not at first. The repository acts as the landing page, so a clear README with one sentence, an install command, an output sample and a license is the priority. A separate site helps later, when you want search traffic or documentation that outgrows a single file.
Should I ask people for GitHub stars?
It is better to ask for something specific, such as a bug report or whether the install worked. Stars measure interest, not use. Fake or traded stars break the rules of many places and hurt trust, so a small honest audience that files real issues is worth more.
Where should I announce an open-source project for free?
Post where people with the problem already read: your language’s package registry, a free launch board that takes a repository link, and Show HN if people can try it right away. Hacker News’s guidelines ask you to be around to discuss, so pick a time when you can.
How do I stop a launch from overwhelming me?
Prepare before you post. Add a contributing file, issue templates, a stated response time and a standard reply for out-of-scope requests. Then batch your replies into fixed windows. A launch brings a rush of messages for a few days, and clear rules turn it into a manageable queue.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.