Naming a side project is one decision. Naming an open source project is three, stacked on top of each other, and most naming guides only deal with the first kind. The name has to work as a GitHub repository, since that's where the code lives and where most people will first run into it. If the project ever ships a package, that same name also has to survive npm, or PyPI, or whatever registry fits the language, where the rules are stricter and the name is permanent the moment it's live. And it has to be the thing someone types into Google months later, after seeing it once in a tweet or hearing it mentioned at a conference, trying to find it again from a half-remembered string. That's three separate constraints, not one.
The real failure mode is not a bad name, it is a name clash
Most naming advice focuses on creativity, on finding something memorable or clever. The thing that actually kills a project's discoverability isn't a name that sounds boring, it's a name that already belongs to something else. In December 2011, a new JavaScript framework was announced under the name Amber.js. Four days later, it was renamed to Ember.js. The reason wasn't a trademark threat or a legal letter. Amber Smalltalk, an existing Smalltalk implementation written in JavaScript, already used a name close enough to cause real confusion in search results, issue trackers, and conversation. The Ember team talked directly with the Amber Smalltalk maintainers and changed course within days, before two unrelated projects ended up permanently splitting search traffic and community attention between them. That's the lesson worth taking from it: checking for a collision before you commit to a name costs about ten minutes. Discovering one after launch costs a rename, a redirect strategy, months of split search equity, and an awkward conversation with whoever maintains the project you collided with.
Check these four places before you commit to a name
None of these checks take long on their own. Skipping all four is how a project ends up needing the Ember.js treatment six months in.
GitHub search
Search the exact name, and close variants, directly in GitHub's own search bar, not just Google. GitHub ranks its own search results by signals like stars and recent activity, so an existing project with a similar name and even a modest star count can outrank you in GitHub's search for years, regardless of how good your project becomes.
npm registry
If there's any chance this project ships a package, check npmjs.com for the exact name today, even if publishing is months away. A name that's free on GitHub isn't automatically free, or even legal, on npm; the registry has its own hard rules around casing, punctuation, and uniqueness. Cross-reference against NameKit's npm package naming rules guide, since a name can clear every GitHub check and still fail the moment you run npm publish.
General web search
Search the name on its own, in quotes, and combined with your category, things like “yourname javascript” or “yourname cli.” You're checking for unrelated companies, products, or people who already sit on that exact search term, since that's exactly what you'll compete against every time someone searches for your project by name.
Domain and social handles
Even for a project with zero commercial intent, a matching domain and a consistent handle across GitHub, npm, and Twitter/X make the project easier to find and easier to trust. A contributor deciding whether a project is alive and maintained reads a consistent identity across platforms as a quiet signal that someone's actually behind it.
Three things your name has to do at once
Work as a GitHub repository name
NameKit already covers the exact mechanics of how to translate a project name into a good repository name, lowercase, hyphenated, descriptive, in detail. The catch is that a project name decided in isolation, before you've thought about how it reads as a URL, doesn't always translate cleanly. A name that sounds great out loud can turn into an awkward or ambiguous repository slug without some adjustment.
Survive becoming a package name
If this project will ever ship to npm, PyPI, or any other registry, the project name and the package name should match, or come close enough that nobody has to guess. A mismatch, the project is called one thing publicly while the package on the registry is called something else, creates permanent confusion for anyone trying to find, cite, or recommend the project to someone else.
Be searchable when someone only half remembers it
Someone who saw your project mentioned once, in a tweet, a conference talk, a Slack message someone forwarded, needs to be able to find it again from a fuzzy memory weeks later. A name that's a real, common English word combined with your category usually loses that search to a slightly invented one with zero competing results. “Parser” will never out-rank a made-up word, no matter how good the parser is.
Good and bad open source project names: real patterns
Abstract naming advice is easy to agree with and hard to apply at midnight while staring at a blank repository field. Here are six patterns that show up constantly in open source.
| Pattern | Outcome | Why |
|---|---|---|
| A generic English word with no qualifier (e.g. “Parser,” “Validator”) | Fails | Returns millions of unrelated results and is almost certainly already a package name on at least one registry. |
| A name that collides with an existing well-known project in an adjacent space | Fails | The Amber.js situation: confusion costs you contributors and search visibility even after a rename. |
| A pure acronym with no phonetic identity | Fails | Hard to say aloud, hard to remember, and gives zero clue what the project does. |
| A real word stretched into uniqueness through unconventional spelling (dropping a vowel, adding a letter) | Works | Stays pronounceable while becoming far easier to find in search, the pattern behind Redis, Vite, and Zod. |
| A compound of two short, real words describing function | Works | Self-explanatory to a new visitor while staying distinct enough to rank, similar in spirit to date-fns or fast-glob. |
| A short invented word with no prior meaning, checked against GitHub, npm, and general search before launch | Works | Works when the collision check actually happens first, fails badly when it doesn't. |
Notice what the “fails” rows have in common: they're either too generic to ever rank, too close to something that already exists, or too abstract to remember. The “works” rows all do the opposite, they're specific, pronounceable, and checked against the three places people will actually look before the name ever ships.
A pre-launch naming checklist
Five checks, none of them longer than a search query, run through all of them before the name goes anywhere near a git init.
- 01Searched the exact name on GitHub. Checked the top five results for confusing overlap with an existing project.
- 02Searched the name on npmjs.com. Or whatever registry fits your language, PyPI, crates.io, RubyGems.
- 03Searched the name in quotes on the open web. Checked for unrelated companies, products, or people already using it.
- 04Confirmed the name still works as a repo name. Converted to lowercase and hyphenated, it should read just as clearly.
- 05Confirmed you're comfortable with this being permanent. A forced migration later is expensive; changing your mind now is free.
Pick the name, then make it official everywhere
Check for collisions on GitHub, npm, and the open web before anything else, then confirm the name survives translation into a repo name and a package name without losing what made it good in the first place. If you're starting from a one-line description instead of a name, NameKit's GitHub Repository Name Generator turns that into ready-to-use, valid repo names you can run through the same checks above before committing to anything. And if this project started life as a side project that's now going public, our guide to naming a side project covers the broader version of this decision, this one is the open source specific version, for when a search engine starts looking for it too, not just your own hard drive.
Frequently asked questions
What is a name collision in open source naming?
When a new project's name is identical or confusingly similar to an existing project, package, or product. The Amber.js to Ember.js rename in 2011 happened specifically because of a collision with Amber Smalltalk, an unrelated existing project.
Should I check npm even if I am not publishing a package yet?
Yes. Many projects start as just a GitHub repository and later ship an npm package under the same name. Checking early avoids discovering the name is taken right when you're ready to publish.
Is it bad to rename an open source project after launch?
It's survivable but costly. Ember.js did it successfully within days of launch with minimal damage. Waiting months or years means rebuilding search rankings, contributor recognition, and every external link pointing to the old name.
Does the project name need to match the npm package name exactly?
Not strictly, but a close match avoids confusion. If they diverge, anyone searching for the project by its public name may not find the package, and vice versa.
Where should I check for name collisions first?
Start with GitHub search, since that's where most open source discovery happens, then check the relevant package registry (npm, PyPI, crates.io), then a general web search for the name on its own.