Publishing Open Source: The Naming Chaos Nobody Talks About
Shipping to PyPI or npm means your package name becomes your brand. I learned this the hard way with Seven Suite.
I shipped Seven Suite to npm and immediately regretted the naming inconsistency. The GitHub handle is seven-suite. The npm package is seven-suite. The docs URL is different. The GitHub org is yet another variation.
This matters more than you think.
When someone tries to import your package at 2 AM debugging production, they're going to guess. They'll try import from 'seven-suite', then seven_suite, then dig through docs. Every variation you support creates maintenance debt.
I see this constantly in the ecosystem. Developers publish a tool, slap it on PyPI or npm, then handle the branding later. By then, you've got forks, Stack Overflow posts, and GitHub issues using three different names.
My approach now: standardize before shipping. Pick one handle. Use it everywhere.
- GitHub org:
seven-dev - npm packages:
@seven-dev/suite,@seven-dev/cms,@seven-dev/shop - Docker images:
sevendev/suite:latest - Documentation domain:
docs.seven.dev
Consistency isn't boring—it's a feature. Users remember one thing. You spend less time fixing typos in documentation.
The second decision: when to open source. I used to ship immediately. Now I wait until the naming settles and the core is solid. Seven CMS spent six months private before I was confident in the public API. Seven Shop's first release was after real client use.
This isn't gatekeeping. It's respecting your users' time. An open source package with three renames and six breaking versions in six months damages trust more than waiting two months for v1.0.
What I've learned: shipping is 10% code, 90% decisions you made before touching the keyboard. The infrastructure, naming, versioning strategy, support model—these decide whether someone adopts your tool or finds an alternative.
If you're considering open sourcing something, spend a week on this alone. The code will thank you later.