How do you get your first users for an open-source project?

Building is a closed loop. It is you and the compiler and a test that either passes or it does not. When something is wrong, you can usually see it, and if you can see it you can usually fix it. The work answers to you and to nobody else, and there is a real comfort in that. Most of us got into this because that loop is honest.

Users are a different runtime entirely. They are other people, and other people do not compile on command. They skim the README, misread the one line that mattered, open the tab, and forget it for three weeks. You can spend six focused months on something clean and correct and watch it land in total silence, and silence is the one error message that tells you nothing.

So here is the uncomfortable part, said plainly: getting users is harder than building because building is the part you control and users are the part you do not. The reflex, when it hurts, is to go build more. Add a feature. Refactor the thing nobody has run yet. It feels like progress and it is mostly hiding. The work that actually earns users is talking to people, one at a time, which is slower and quieter and has no green checkmark at the end.

Almost never from a cold audience. Not from a single post flung at strangers who have never heard of you. Your first users come from warm places, and warm has a specific meaning here: a warm person is someone who already has the problem you just solved, before you ever say a word to them.

There are three wells to draw from, roughly in order of warmth. The first is people already living in the problem: the folks complaining about it in adjacent issue threads, in a Discord, on a forum where they have clearly been suffering. The second is your own network, the people who know you and will extend a little trust to your work because it has your name on it. The third, and the one people forget, is your early stargazers: the developers who starred your repo. A star is a small yes. It means "I want to remember this," which is a quieter and more useful signal than a like.

Prior interest beats cold reach every single time. The trouble is that a star count only tells you the aggregate, how many, and a number is not something you can talk to. The named people behind it are. You can still see who starred your repo as the owner (GitHub changed who can view a repo's full stargazer list in 2026, but your own list stays yours), and a free stargazer checker shows you the count at a glance. The count is the headline. The people are the story.

Narrower than feels comfortable. A tool that solves one problem perfectly spreads faster than a platform that solves ten problems adequately, because the first one is describable and the second one is not. Say your project is acme/rocketdb. "A database" is not going to move anybody. "The thing that makes a slow query fast without an index rewrite" might.

Use the sentence test. If you cannot say what your project does and who it is for in one sentence, without reaching for the word "and," it is probably too broad to catch on yet. Users do not adopt scope. dev-priya does not wake up wanting "a framework." She wakes up with a specific slow thing, and she adopts whatever fixes that specific slow thing today.

Narrow is also what makes a project shareable, which is how the first users find the second users. People pass along tools they can describe in half a breath. Something broad just sits open in a tab with good intentions. If you want more of this, there is a whole guide on how to promote your GitHub project that leans on the same idea: you cannot spread what you cannot say.

The instinct is the blast. One post, one announcement, fired at everybody at once, because it is fast and it feels like marketing. The blast is easy, and it is almost all noise, and the people it reaches have no reason to care yet.

The thing that actually works is slower and feels almost too small to count: reach people one at a time, with something specific to them. If dev-priya described your exact problem in an issue on some adjacent project last month, reply there, to that. If someone starred acme/rocketdb, that is a person who already raised their hand, and a short note referencing the specific thing they cared about is worth a hundred generic ones. This is owner-first by definition: you are reaching people who came to you, not strangers you found somewhere.

Many of your stargazers left a public email, and there is a guide on how to contact your GitHub stargazers the right way. The rule underneath all of it is simple: specificity is the whole difference between a message someone answers and a message someone deletes. Say the one true thing about why you are writing to this person, and then stop.

Getting a user is the loud half. Keeping one is the quiet half, and it is the half that decides whether you have a project or a graveyard. The biggest lever is speed of response. A first user is spending attention on an unknown thing, and the fastest way to lose them is to go silent. A maintainer who stops responding is, to the people relying on the project, a process that has stopped responding: still technically running, no longer answering.

Thank the people who file issues, actually thank them, because an issue is a gift. Someone hit a wall and chose to tell you instead of quietly leaving, which is the rarest and most generous thing a user does. And fix the small annoyances, the papercuts: the two-line README confusion, the surprising default. Nobody churns dramatically. They just accumulate tiny frictions until the tab closes.

Last, keep track of who your early users are, by name, not as a headline number. Star counts are aggregate; the relationship lives in the named people. Many of them left a public email, and something like WarmStars can turn your own stargazers into named people from public data, so your earliest supporters stay a list you can actually talk to. If you want the longer version, turn your GitHub stars into customers goes deeper. The number goes up once. The people, if you treat them well, stay.