Launch an Open-Source Project for Free: Licence, Health Files and First Contributors
Launch an open-source project by choosing a licence before you publish, because code with no licence gives other people no right to use it. Then add the files GitHub’s community checklist looks for, a README, LICENSE, CONTRIBUTING and a code of conduct, set repository topics, label a few beginner-friendly issues, and announce in the places where users of that kind of software already talk. Promotion is optional; maintenance time is not.
Which licence do you choose before anyone sees the code?
Publishing code is not the same as licensing it. The Choose a License site explains that a repository with no licence leaves the default copyright rules in place, so other people may not copy, change or share your work, apart from what the host’s own terms allow, such as viewing and forking on GitHub. Those limits are too thin for the use and collaboration an open project is after. If you want people to build on it, say so in a licence file.
You do not need to become a lawyer to pick one. Decide what you want strangers to be allowed to do, and use the site’s guided chooser rather than copying a licence from a project that looks similar. As a rule of thumb, a permissive licence makes adoption easiest for companies, while a copyleft licence asks derived works to stay open. If you plan to sell a hosted version or a paid edition later, settle that now, because relicensing code that other people have contributed to is hard.
Which files does GitHub expect from a healthy project?
GitHub’s documentation describes a community profile checklist that looks for recommended community health files in a supported location, naming the README, the code of conduct, the licence and the contributing guide as examples. Each answers a question a visitor has before they invest time.
| File | Question it answers | Test |
|---|---|---|
| README | What is this and does it solve my problem? | A stranger can say what it does after thirty seconds |
| LICENSE | May I use it, and on what terms? | The file is at the root and named on the page |
| CONTRIBUTING | How do I send a change that you will accept? | It names the test command and the branch to target |
| Code of conduct | What happens if someone is unkind? | It gives a contact that is not only you |
| Issue templates | What do you need in a bug report? | The template asks for a version and steps |
Write CONTRIBUTING as if for yourself in a year: the exact commands to run the tests, a sentence on how decisions get made, and what a good first pull request looks like. The README template for a launch covers the top-of-page half.
How does a stranger find a repository nobody has starred?
Through GitHub itself, more than through any launch board. Topics appear on the main page of a repository and link to a page of other repositories with the same topic. GitHub’s docs say admins can add any topics they like, that useful ones describe the purpose, subject area, community or language, and that GitHub also suggests topics by analysing public content. Pick a few specific ones that match how a person would search for the problem.
Beginner-friendly issues do the other half of the work. GitHub’s guide to labels says that applying the good first issue label to issues in a public repository helps people find ways to contribute, and that the label can increase the chance your issues are surfaced. Keep three or four open and written clearly enough that someone new could take one without a call.
How do you announce something nobody owes attention to?
The Open Source Guides are refreshingly honest about this. Their page on finding users says there is no rule that you must promote an open project when you launch, and that many reasons for working in the open have nothing to do with popularity. If you do want users, it advises explaining what the project does and why it matters, giving it one home URL, and going where its audience already is, online and in person.
That produces a simple order of play. Write one honest paragraph about the problem and what you tried. Post it where the people with that problem read, as a story, with the repository linked at the end. A Show HN post fits when others can run the project, as the Show HN playbook explains. Then launch it on this free board for a permanent public page; the outbound link is a normal followed link, and the draft can be fixed right up to the moment you press Publish. Builders who browse developer tool ideas may also be your first contributors.
What does the first month include?
- Days 1 to 3: licence, README, CONTRIBUTING and issue templates. Run the install steps on a clean machine.
- Days 4 to 7: add topics, write four good first issues, tag a first release so the project has a version to point to.
- Days 8 to 14: show it privately to three people who could be users. Fix what confuses them in the README, not in a reply.
- Days 15 to 17: announce. Block the same three days in your calendar for answering.
- Days 18 to 30: reply to every issue within a day, merge the first outside pull request quickly and say thank you in public, and write down what you decided not to build.
That last item is a protection for you. A short “non-goals” section in the README turns a stream of feature requests into a conversation you can have in one line. The open-source launch checklist gives the fuller list.
What tells you the launch worked?
Stars are easy to count and say little about use. Look instead at how long strangers wait for a first reply from you, how many issues come from people you do not know, how many of those include enough detail to act on, and whether the first outside pull request arrives and gets merged. A project with ten engaged users and one outside contributor is in better shape than one with a thousand stars and no questions.
Write down the dates of each announcement and the changes in issue and clone numbers around them. If the numbers are low, the next job is another careful post in a different community, not a rewrite. The open-source maintainers playbook looks at the same launch from the maintainer’s own time budget.
Frequently asked questions
Do I need a licence to publish open-source code?
Yes, if you want others to use it. The Choose a License site explains that without a licence, default copyright applies and others may not use, change or share your work beyond what the host’s terms permit. Add a LICENSE file before announcing, and pick it deliberately.
What files should an open-source repository have?
At minimum a README and a LICENSE. GitHub’s community profile checklist also looks for a code of conduct and contributing guidelines, and issue templates help you receive useful reports. These files answer a stranger’s first questions about what the project is, whether they may use it and how to help.
How do I get contributors to a new project?
Label a few well-written issues good first issue, write a CONTRIBUTING file with the exact test commands, reply fast and thank the first contributor in public. GitHub’s docs say the good first issue label can make issues more likely to be surfaced to people looking for a way in.
Do I have to promote my open-source project?
No. The Open Source Guides say there is no rule that you must promote a project when you launch, and many reasons to work in the open are unrelated to popularity. If you do want users, explain the problem, give the project one home URL, and go where its audience is.
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.