TL;DR
To grow an open source project, make it easy to understand in one minute, easy to try in five, and easy to contribute to in an afternoon. Then go to the places where your users already talk, reply fast, and share credit.
- Most projects stall because people cannot tell what the project does or how to start, not because the code is weak.
- A clear README, a short quickstart, and labeled beginner issues do more than any launch post.
- A launch on Hacker News can bring a burst of stars, but replies, docs, and trust keep people around.
- Plan for the maintainers too. Burnout ends more projects than bad code does.
Developers are building at a pace the world has never seen. GitHub's Octoverse 2025 report says a new developer joined GitHub every second on average, and about 230 new repositories were created every minute. It also says 63% of all repositories on GitHub are public or open source.
So your project is not just competing with other good ideas. It is competing with a flood of them, every minute of every day.
This guide walks through what actually helps an open source project grow, in plain steps you can start today. Every number links to where it came from.
What does it mean to grow an open source project?
Growing an open source project means more people use it, more people help build it, and a few of them stay long enough to share the load. Stars are a nice sign, but they are not the goal.
The Open Source Guides, written by GitHub, describe this as a funnel. People start as users, some become contributors, and a few become maintainers. Your job is to remove friction at every step so each person finds an easy first win.
| Stage | What it looks like | What moves people forward |
|---|---|---|
| Visitor | Lands on your repo and decides in seconds | A clear one line pitch and a good README |
| User | Installs and tries it | A working quickstart and examples |
| Contributor | Files an issue or sends a fix | Labeled beginner tasks and fast replies |
| Maintainer | Reviews, releases, helps others | Trust, credit, and shared ownership |
Keep that table in mind. Every step below fits into one of those rows.
How to grow an open source project: 12 steps
1. Say what it does in one sentence
Before anything else, you need a sentence a stranger can repeat. Who is it for, and what problem does it fix?
Open Source Guides suggest asking yourself what makes the project different and why you built it, then writing from the point of view of a user, not the builder. Try finishing this line: "My project helps X do Y without Z." If you cannot finish it, nobody else will be able to either.
Put that sentence at the top of your README, in your GitHub description, on your website, and in every post you write.
2. Make the README do the selling
Your README is your landing page. Treat it that way.
The numbers explain why. In GitHub's 2017 Open Source Survey, 93% of respondents said they had run into incomplete or outdated documentation. The same survey found that 60% of contributors say they rarely or never help with docs. That is a big gap, and it is your chance to stand out.
A README that works has:
- The one-sentence pitch at the top.
- A short code sample or screenshot showing the result.
- Install steps that take under a minute.
- A link to full docs.
- The license.
- A line on how to get help and how to contribute.
Open Source Guides has a simple walkthrough for writing a README if you want a starting point.
3. Add a license, a contributing file, and a code of conduct
These three files tell people it is safe to use your work and safe to join in. The same survey coverage notes that licenses are the most valued type of documentation for both users and contributors.
Without a license, many companies will not touch your code. Without a contributing guide, newcomers guess, and guessing is scary. Without a code of conduct, you have no clear way to handle bad behavior when it shows up.
4. Give the project one home
People need one link to remember. A GitHub repo works at the start. A small website works better as you grow.
Open Source Guides quotes Adrian Holovaty, co-creator of Django, saying the website was one of the best things the team did early on. You do not need anything fancy. GitHub Pages is free and fine. What matters is that the site has your pitch, the quickstart, examples, and docs in one place.
5. Make the first five minutes work
A visitor who cannot get a working result in five minutes usually leaves and does not come back.
Test your own quickstart on a clean machine. Better still, ask a friend who has never seen the project to try it while you watch silently. Fix every spot where they pause.
Then add:
- A starter template or example repo people can clone.
- Copy and paste code that runs without edits.
- The exact text of the most common errors, with fixes.
Studio1 has written about why poor onboarding and thin docs sink developer products. The same lessons apply to open source.
6. Label good first issues
Most people who want to help do not know where to start. Show them.
Use the "good first issue" and "help wanted" labels on tasks a newcomer can finish. GitHub's own docs say it uses an algorithm to find approachable issues and show them in places across the site, and that adding the label can raise the chance yours get shown. The CNCF issue label guide adds a good test: a new person should be able to claim the task and send an acceptable pull request without having to ask for help.
Write each beginner issue so it stands on its own. Say why it matters, which files to look at, and what done looks like.
Also, keep a few easy bugs unfixed on purpose. Open Source Guides suggest using small, non-urgent bugs as a way to bring in new contributors instead of fixing them yourself.
7. Reply fast, especially to first timers
This one costs nothing and matters a lot.
Open Source Guides point to a Mozilla study showing that contributors who got a code review within 48 hours came back far more often. They also warn that if you leave an issue sitting for a month, people usually forget your project.
The numbers on why this matters are not pretty. One analysis by the team at Multitudes found that around 70% of contributors are one-time contributors. A friendly, quick reply is how you turn a few of them into regulars.
You do not need a full review in two days. A short note like "Thanks, I will look this week" counts. Track it, too. The Linux Foundation's Insights tool lists median time to first review as a health signal for exactly this reason.
8. Launch where developers already hang out
You do not have to launch loudly, but you do have to tell people. Open Source Guides say plainly that you have to spread the word instead of hoping others find you.
Researchers looked at how the 100 most starred GitHub projects promote themselves. The paper, How Do Developers Promote Open Source Projects?, found that Twitter (now X), user meetups, and blogs were the most common channels. It also showed that a successful Hacker News post gave projects a clear jump in stars.
More recent work agrees. A 2025 study of 1,814 AI repositories shared on Hacker News saw a significant rise in forks, stars, and contributors afterward. Another paper tracked 138 repository launches and found an average gain of 121 stars in the first day, 189 in two days, and 289 in a week. It also found the "Show HN" tag gave no statistical edge once other factors were counted, while the time of posting did matter.
Treat those as averages from AI and developer tool launches, not a promise. Your result depends on the idea and the post.
How to launch without being annoying:
- Pick two or three places where your exact users hang out, not ten.
- Say who it is for and what you want feedback on.
- Show the working result first, then the story.
- Stay in the thread and answer every comment.
- If nobody notices, try a new angle in a month. Open Source Guides note that many launches take months or years to catch on.
9. Write content people actually search for
Most developers do not find projects by luck. They search for a problem, or they ask an assistant.
In the 2025 Stack Overflow Developer Survey, 50.6% of professional developers said they use AI tools every day. So your pages need to work for Google and for AI answers.
Write the pages your users would search for:
- How-to guides for each main task ("How to add auth to a Next.js app with X").
- Comparisons that are honest about where another tool fits better.
- Migration guides for people leaving a competitor.
- Error fixes with the exact error message in the title.
Put the answer in the first two sentences. Keep every section understandable on its own, so a search engine or assistant can lift it out. Studio1 goes deeper into Developer Docs as Your Best AEO Asset and How to Get Your Tool Recommended by ChatGPT, Perplexity, and Google.
10. Help other people before you ask for anything
The fastest way to be known is to be useful somewhere else.
Open Source Guides suggest answering questions in forums where your users ask for help, and mentioning your project only when it truly fits. They also suggest contributing to projects near yours. The guide shares a story from the maintainer of urllib3, who said the library became so popular largely because requests bundled it.
Practical ways to do this:
- Answer questions on Stack Overflow, Reddit, and Discord with real fixes.
- Send a pull request to a related project.
- Thank people who write about your project, and share their posts.
- Speak at a local meetup. It is a gentle way to start, and the people in the room are real users.
11. Share ownership and give credit
People stay where they feel their work counts.
Open Source Guides list several easy moves: keep a CONTRIBUTORS or AUTHORS file, thank people by name in release notes or a newsletter, give regular contributors commit access, and move the repo to a GitHub organization with at least one backup admin. They also note that most projects have only one or two maintainers doing most of the work, so the earlier you invite help, the better.
Public credit is cheap, and it works. Projects like Rust do it with a weekly newsletter that names contributors.
12. Protect the people who keep it running
A growing project means more issues, more questions, and more pressure. If you do not plan for that, you burn out.
Tidelift's 2024 survey of maintainers found that 60% describe themselves as unpaid hobbyists, and 60% have quit or thought about quitting. Tidelift's own breakdown also says 78% of unpaid maintainers spend ten hours or less a week on their projects.
That means your project probably runs on a few hours of someone's spare time. Build for that:
- Move all help into public channels, such as issues or discussions, so answers help everyone, and you are not stuck in private messages.
- Set office hours. The Kubernetes kops team does this every other week to help newcomers.
- Write down what you will and will not accept, and say no kindly.
- Add a second maintainer before you need one.
- Look into funding early. Tidelift reports that income most often comes from donations such as GitHub Sponsors (25%) or from employers who include open source work in a salary (24%).
How do you know your open source project is growing?
Stars are easy to see, but they do not tell you whether anyone is using or helping. Watch a few numbers that do.
| What to track | Why it matters |
|---|---|
| Installs or downloads per month | Shows real use, not just interest |
| New issues from people you do not know | A sign the project is being tried |
| First time contributors per month | Shows whether your doors are open |
| Contributors who come back | Shows whether they felt welcome |
| Median time to first reply | The number you control most |
| Visits to your docs from search | Shows your content is being found |
Check them once a month and write the numbers down. Small, steady gains beat one big spike.
Can programmatic SEO help an open source project?
Yes, if you have real facts behind every page. Programmatic SEO (pSEO) means building many pages from one template and a set of true details. For open source, the natural pages are the ones you already have material for.
| Page type | Example question it answers | What you need |
|---|---|---|
| Error page | What does "ECONNRESET" mean in our client and how do I fix it? | Exact message, cause, working fix |
| Integration page | How do I use our library with Express? | Tested steps and code |
| Migration page | How do I move from Library X to ours? | Side by side code, before and after |
| Comparison page | Ours vs Library X for caching | Honest numbers and trade offs |
| Release page | What changed in version 3? | Dated notes and upgrade steps |
One rule keeps this safe. Do not publish a page until it has facts that only apply to that page. If a page would read the same with one word swapped, search engines and AI tools will skip it. Google also says there is no special markup needed to appear in its AI features. Pages just need to be indexed and useful.
What mistakes slow down open source growth?
- Launching with a weak README. The visitor leaves before you can explain.
- Hiding the best help in private chats. Nobody else can learn from it.
- Ignoring first pull requests. Many first-timers never return after a silent reply.
- Doing every easy fix yourself. You lose the chance to invite someone new.
- Posting in ten places and following up in none. Two good threads beat ten ignored ones.
- Chasing stars over use. Stars fade. Installs and contributors build a project.
- Skipping docs updates. Old docs do quiet damage to trust.
A simple 30 day plan
| Week | Focus | Done when |
|---|---|---|
| 1 | One sentence pitch, README rewrite, license, contributing file | A stranger can explain your project back to you |
| 2 | Quickstart test with a new user, starter template, error fixes in docs | Someone gets a working result in under five minutes |
| 3 | Ten labeled beginner issues, public channel for help, reply rules | A new contributor can pick a task without asking |
| 4 | Launch in two chosen communities, publish one how-to and one comparison | You answered every comment within a day |
Then repeat the cycle. Growth comes from small habits you keep up.
Frequently asked questions
How long does it take to grow an open source project?
Often months or years. Open Source Guides say some of today's most popular projects took years to reach high activity. Plan for steady effort, and expect early progress to be small.
How do I get my first contributors?
Label beginner issues, write a clear contributing guide, and reply within a couple of days. Contributors rarely arrive on their own. Invite them in public and thank them by name.
Do GitHub stars matter?
They help people trust you at a glance, but they do not measure use. Watch installs, new issues from strangers, and returning contributors for a truer picture.
Where should I promote my open source project?
Go where your exact users already ask for help. For developer tools, that often means Hacker News, Reddit, relevant forums, and local meetups. Join the conversation first, then share your work where it fits.
How fast should I respond to issues and pull requests?
Aim for a first reply within 48 hours. A Mozilla study cited by Open Source Guides found that contributors reviewed within that window came back far more often. A short acknowledgement is enough when you cannot review right away.
How do I make my open source project show up in Google and AI answers?
Write pages that answer one question each, with the answer in the first two sentences. Keep docs fresh, readable in plain HTML, and easy to link to. Then earn mentions in the communities where developers talk.
How do open source maintainers get paid?
Tidelift's 2024 report says income most often comes from donations such as GitHub Sponsors, from employers that include open source work in a salary, and from Tidelift itself. Direct company payments, foundations, and government funding were each a small share.
