How to name an open-source project (npm, GitHub, and the trademark trap)

For a startup, “the name is available” mostly means the domain is free and the trademark search came back clean. For an open-source project, that’s maybe half the checklist. The name also has to be free on the package registry your users will install from, on the code host where the repo will live, and — if the project ships a command — in the space of binary names people already have in their PATH. Each of those is a global, first-come namespace, and each one can block you even when the domain is sitting there unregistered. There’s a trademark wrinkle too, and open source has been burned by it more than once: Mozilla’s browser famously shipped under two earlier names, Phoenix and then Firebird, before conflicts with an existing company and an existing database project pushed it to Firefox. Getting this right up front matters, because an OSS rename after the stars, contributors, and install commands pile up is uniquely expensive to undo.

Why is “available” a longer checklist for open source?

The package registry is the hardest gate. npm, PyPI, and crates.io are each a single flat namespace shared by every developer in their ecosystem, allocated first-come, first-served. If someone published a package under your name years ago — even a stub with no downloads — that name is gone, and no amount of domain availability changes it. npm has one escape hatch: scoped packages. @yourorg/name is yours as long as the yourorg scope is, even if the bare name is taken — though scoped names are slightly less discoverable. crates.io has no scopes at all and PyPI is flat too, so there the bare name is the whole game. Check the registries first, because they’re the least forgiving.

Then the code host. GitHub repos are namespaced under an owner, so the repo name itself rarely blocks you — but the org or username does. A project that lives at github.com/somename/somename reads as canonical in a way github.com/random-handle/somename doesn’t, and the org name, alongside the repo, is baked into every Go import path and git clone command. The same logic applies on GitLab.

Then the binary. If the project ships a CLI, the command name is its own namespace: whatever people type in a terminal shouldn’t collide with a common Unix tool or an existing package name in Homebrew or Debian. A collision here doesn’t just confuse users — it can keep package maintainers from ever shipping you under your own name.

Only then the usual suspects. Domain and social handles come last, and the workflow is the same as for any project — the full method is in how to name a startup: generate candidates, check the whole list at once, keep what survives — our guide to checking availability in bulk covers that loop, and for the domain itself, .dev and .app are the natural first stops for developer-facing projects.

Can an open-source project really get in trademark trouble?

Yes — free and hobby don’t exempt you. Trademark law cares about confusion in a market, not about whether money changes hands, so an unpaid side project can still draw a very real objection — up to a cease-and-desist — if its name collides with a mark or an established project in a related space. That pressure is what renamed Mozilla’s browser twice before Firefox stuck. The fix is cheap: a few minutes of searching before you commit, following the same steps as any founder — our trademark basics guide walks through it.

The reverse angle matters once the project succeeds. If the thing takes off, somebody ends up holding the trademark — you, your company, or a foundation — and that’s where project names and steward names often diverge. There’s a well-known pattern where a company keeps its brand for the commercial product and moves the community project to a separate name: Docker did this when the open-source engine’s upstream became the Moby project while Docker remained the product. And there’s the mirror-image pattern, where a project’s stewards relicense it and the community forks and renames: Terraform’s relicensing produced OpenTofu, and Redis’s produced Valkey, both continuing under foundation ownership with new names precisely because the old marks weren’t theirs to keep. You don’t need to plan for foundation governance on day one — but picking a name you could actually own the mark for keeps every one of those doors open.

What makes a name good for a developer audience?

Everything that makes a name brandable, plus a terminal test. The general rules — short, distinctive, easy to say and spell — are covered in what makes a name brandable, and they all apply. Open source adds a few accents. People will type this name into a terminal daily, so it should be short, lowercase-friendly, and typo-proof — the same name-is-an-interface logic behind our domain name ideas for developer tools. It should be greppable: unique enough that searching for it — in a codebase, on a search engine, in an issue tracker — finds your project rather than a thousand unrelated hits. That’s the quiet argument against naming a project after a common English word: it pollutes search results, and it’s the most likely thing to already be taken on every registry and to sit closest to someone’s existing trademark. A coined word sidesteps most of that in one move — the registries are empty, the searches are clean, and the mark is registrable.

How painful is renaming an open-source project later?

Uniquely painful, so plan as if you’ll never get to. GitHub at least redirects the old repo URL after a rename and keeps your stars — until someone claims the old name and silently breaks the redirect. npm has no rename at all: you publish a new package, deprecate the old one, and watch your install base split across two names while download counts start from zero. Go import paths embed the repo path, so a rename is a breaking change for every consumer. And no redirect fixes the tutorials, Stack Overflow answers, conference talks, and muscle memory that all point at the old name. Renames do happen, and sometimes they’re the right call — when and how to rename a project covers making that decision — but the cost curve is steeper for OSS than for a normal product, which is the best argument for spending an extra hour on the name now.

The fastest way to clear that stack is to start from candidates distinctive enough that the registries are likely empty too. Domain Yoga generates availability-checked, brandable name ideas from a plain description of what you’re building, so more of your shortlist survives first contact with npm.