On "Reserving" Package Names

378 views
Skip to first unread message

Isaac Schlueter

unread,
Dec 14, 2012, 7:10:23 PM12/14/12
to nodejs, np...@googlegroups.com
TL;DR - Package squatting is not allowed. If you sit on a package
name and don't publish code, it'll be deleted without warning.

----

npm package names have always been a "first come, first served"
system. I think this is generally good. It incentivizes early
adopters, which is important, because they're the most valuable users.

It also is a powerful motivator to *actually write code*.
Traditionally, the pattern has been that if you think of a great name,
well, you'd better ship something, then! We never had to have an
explicit rule about publishing empty packages, for the same reason
that you don't have to have an explicit rule about leaving garbage on
the floor in someone's house. It's just not something you'd do.

It is hard to really comprehend *just how many* possible package names
there are. The math isn't that hard, but the actual numbers are
mind-boggling. Even just limiting to 4 characters, there's
36*38*38*38 potential names. That's about 100x the number of npm
packages that have ever been published. And yes, it includes stuff
like 0-_-, but still. You don't have to limit it to 4 characters. At
8 characters, there's 4118960973312 potential names. If you got TJ
Holowaychunk and Raynos and Substack and architectd and Dominic Tarr
together and managed to get them to publish a package with a unique
8-character name every MILLISECOND, it'd take OVER 130 YEARS to ever
use them all up! Absurdity aside, there are millions and millions of
common words and clever spellings. We'll never run out. There is no
scarcity.

(To the alpha-nerds in the audience: this is not a challenge. Please
don't DOS the registry. ;)

The official policy for handing name disputes mostly focuses on
abandoned modules, confusing name collisions, and other cases where
two parties both actually have published (or want to publish) working
code. There's never been a need to make the "no seat saving"
explicit, because it just didn't happen much. Disputes between two
authors have generally always been handled pretty easily. The
occasional "no code here" module was always a mistake or an oversight,
and promptly cleaned up.

Lately, probably owing to the increase in our community's size, or the
increase in npm's popularity, or some combination of factors, I've
been seeing a lot more cases where someone asks to use a module,
pointing out that the author isn't using it, and they're told, "No,
that's something I'll be publishing at some time in the future." When
I've stepped in and made a ruling, pointing out that **npm is for node
modules that exist, not for node modules that don't exist**, the
squatters have in some cases reacted with surprise and frustration.
It's gotten un-amicable.

If you think I'm talking about you, you're probably right. But I
wouldn't bother to write this if it had been an isolated incident, so
you're not alone. I don't want to single anyone out, and it's
happened enough times that clearly there's some widespread confusion
about what's ok and what isn't. You're not a bad person. You didn't
know.

To be fair, yes, this was never a part of any "official" policy in an
explicit way. So, as of
https://github.com/isaacs/npm/commit/993abe412db791f9460932371b39642817523aab
(and this email) it's explicit. (The great thing about npm being a
dictatorship is that it doesn't ultimately matter what any policy
says. My interest is for the node community to write code, so
anything that stands in the way of that gets cut down, policy be
damned.)

It is very easy to rename a module. It's a matter of changing *a
single field* in a JSON doc. If it takes a few months to build
something, and someone publishes something in with the same name in
the meantime, that means a few things are likely:

1. You took took long. Go faster. Which probably means:
1a. You tried to write something that was too big. Build smaller.
2. The name you chose is too vague and doesn't tell much about your
problem domain. Which probably means:
2a. Your problem domain is ill defined. (Is it an MVC framework?
CMS platform? Stop right there.)

If that happens, just pick a new name! There are literally zillions
to choose from. It doesn't matter how long you've slaved over the
code to make your module, with the hope of using that name. They got
it over the finish line first. That's how "first come first served"
works.

This is the warning. If you're reading this, and you have something
that you're "intending" to publish "soon", hurry up! If your module
is just a placeholder, it'll be removed the first time someone calls
attention to it.

It pains me to have to do administration of any sort. Really. You
have no idea how lazy I am when it comes to petty things like this,
and I don't enjoy being a hardass. But npm is not for owning words.
It's for sharing code. Hack or get out of the way.

Chris O'Hara

unread,
Dec 14, 2012, 9:05:26 PM12/14/12
to nod...@googlegroups.com, np...@googlegroups.com, i...@izs.me
It's worth adding that you should reach out to the author first if you find such a package in npm. There's a good chance that they're not "squatting" the name intentionally - they probably just started a project excitedly and didn't push as fast as they'd hoped.

I had a "dynamo" and "task" in npm without little or no code. I was contacted by jed who had a dynamo client ready to go and tkellen who wanted task for a gruntjs related project. - in both cases I gave up the names.

No drama, no need call anyone a squatter, no need to get Isaac involved, good times.

Isaac Schlueter

unread,
Dec 15, 2012, 1:32:53 AM12/15/12
to Chris O'Hara, nodejs, np...@googlegroups.com
There's no need for drama, you're right. But you make an important
point: the correct answer is "Oh, sorry about that, sure, it's all
yours."

The problem is that sometimes the response is "No, I'm planning on
releasing something there some day, so you can't have it." The
relevant difference is that planned modules don't exist.

Outsider (JeongHoon Byun)

unread,
Dec 15, 2012, 9:42:57 PM12/15/12
to nod...@googlegroups.com
+1
i think it's necessary policy for module quality not just module count.
and it's reasonable to me.

node comunity has became pretty big.
so commiters can't communicate with each module authors.
doing so waste time too much and positive result will be very low.


2012년 12월 15일 토요일에 Isaac Schlueter님이 작성:
--
Sent from my iPad

Diogo Resende

unread,
Dec 16, 2012, 9:57:18 AM12/16/12
to nod...@googlegroups.com
+1

-- 
Diogo Resende

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Austin William Wright

unread,
Dec 18, 2012, 5:33:22 AM12/18/12
to nod...@googlegroups.com, np...@googlegroups.com, i...@izs.me
On Friday, December 14, 2012 5:10:23 PM UTC-7, Isaac Schlueter wrote:
TL;DR - Package squatting is not allowed.  If you sit on a package
name and don't publish code, it'll be deleted without warning.
...

It is hard to really comprehend *just how many* possible package names 
there are.  ... We'll never run out.  There is no scarcity.

So is there a problem with people registering names, or not? On one hand you implicitly admit to there being scarcity (otherwise there would be no desire to kick people off who are squatting names), on the other you claim there is none.

Yes, there is scarcity, and it's caused by npm's single distribution channel and global namespace. While it may be true that you can't "run out" of package names in general, don't confuse this with running out of desirable package names for a particular, individual repository. (It also leads to other consequences, like artificially high barriers to forking.)

Floby

unread,
Dec 19, 2012, 4:35:10 AM12/19/12
to nod...@googlegroups.com, np...@googlegroups.com, i...@izs.me
Well, the NPM repository is in fact Isaac's repository. And Isaac says that he doesn't want empty packages in his repository.
I don't see how it can be more complex than that. If one wants to publish dozens of empty modules, one can publish them on his own repository.

Austin William Wright

unread,
Dec 19, 2012, 5:09:45 AM12/19/12
to nod...@googlegroups.com, np...@googlegroups.com, i...@izs.me


On Wednesday, December 19, 2012 2:35:10 AM UTC-7, Floby wrote:
Well, the NPM repository is in fact Isaac's repository. And Isaac says that he doesn't want empty packages in his repository.
I don't see how it can be more complex than that. If one wants to publish dozens of empty modules, one can publish them on his own repository.
 
Well I'm not arguing against the policy! Due to the intrinsic nature of npm (e.g. we don't see GitHub enforce such a policy), it's a measure to decrease scarcity of names for package maintainers, and it seems to accomplishes that.

That said I think it's a bit unfair to say "publish it in your own package repository" since npm has a special privileged status in the Node.js Git tree, which is above and beyond mere popularity.

Eric Mill

unread,
Dec 19, 2012, 10:25:16 AM12/19/12
to nod...@googlegroups.com, np...@googlegroups.com, i...@izs.me
Well I'm not arguing against the policy! Due to the intrinsic nature of npm (e.g. we don't see GitHub enforce such a policy), it's a measure to decrease scarcity of names for package maintainers, and it seems to accomplishes that.

That's a fair point. The purposes of Github are obviously very different than npm, though. Code on Github is expected to be messy, complete, and experimental, and this should get in no one's way. npm lends your code authority, so the expectations are a bit higher.
 
That said I think it's a bit unfair to say "publish it in your own package repository" since npm has a special privileged status in the Node.js Git tree, which is above and beyond mere popularity.

Also a fair point. npm's rules are more or less the node.js' community's rules. They're run by the same benevolent dictator, so, hey - not a problem. 

Though it is possible to compete with "the establishment" - what is now rubygems.org started out as gemcutter.org, an unofficial competitor to the official Ruby gem host on rubyforge. It was so much better that eventually they made gemcutter the official one and renamed it. It seemed to me that gemcutter succeeded on practicality, by reducing the friction of publishing/fetching gems - nothing they did made the system more or less democratic, that I'm aware of.

-- Eric
Reply all
Reply to author
Forward
0 new messages