There's one thing you're responsible for that I don't see mentioned here : potentially wasting a name from the global namespace.
There are too many abandoned projects that took the easy to remember / cool names. At a smaller scale and as an exemple, nowadays if you want to implement a protocol and publish it on NPM there is 99% chances the name is taken and the implementation is poor. Too many people thrown away quick hacks only to leave them die. People willing to work and invest time in proper implementations may end up discouraged and give up trying to publish or even coding them.
Names are the scarcest resource of all. My point of view is that when you take a name you take with it the responsibility of not wasting the cognitive paths associated with it. This is not a small responsibility at all, in my humble opinion.
It probably doesn't apply to the example you gave. Just took the opportunity to voice my concern.
With golang that problem goes away :) but if you're stuck on Node, there's always several different implementations to linking libraries (although, a pain in the ass, but this isn't the fault of the open source author -- complain to Isaac for making an incredibly useless packaging system [nicest to play with though hence the popularity]).
Don't get me wrong, I love Node, but blaming an NPM problem shouldn't place blame on an open source author. None of these solutions works for you? Time to be an open source contributor :)
Golang's stance on this struck me when I saw it. "Of course". URLs have the answer embedded in their name from the beggining. There of course are pros and cons but it seems to me much saner to have URLs as package names and registries as mere search engines leveraging package metadata.
I think you're a bit rude to NPM though. It had many things right and finding defects in retrospect is always an easy task.
Regarding my involvement in open source, I have no clear picture of a solution to this problem at the moment so I will refrain, following the spirit of my previous point. I tend to publish only what I know will be firm ground for others to build upon.
> I think you're a bit rude to NPM though. It had many things right and finding defects in retrospect is always an easy task.
In retrospect, NPM was a bit rude to it's userbase. We've asked for support on custom, multiple, and private registries. PRs have even been made for them and Isaac explicitly shut them down only to later (much later) come out and talk about NPM Inc. NPM is a great tool, and the community for building upon it is absolutely fantastic and wonderful, but the leadership and advisory board behind it are pretty terrible for something as good as NPM.
May be I am a bit harsh, and I may be a bit biased coming from "the old crowd" in Node before it was the cool thing on the block (funny to think back on Rubyist snickering at me for mentioning node to them :))
At least NPM has git URLs which is nice, and may be NPM can do these things (I've abandoned it for much saner practices other than cloning a 50+gb registry, pointing to a registry that falls back to an official registry [big security no-no, at least allow checksums], etc).
Thank you for the perspective though, less whining and more typing (contributing to NPM). My anger is more so towards the leadership of NPM rather than the toolset itself and I didn't express that in my OC ^
If someone is using the original package, then replacing that package with a better one (with different functionality and/or a different API) could mess them up.
There are too many abandoned projects that took the easy to remember / cool names. At a smaller scale and as an exemple, nowadays if you want to implement a protocol and publish it on NPM there is 99% chances the name is taken and the implementation is poor. Too many people thrown away quick hacks only to leave them die. People willing to work and invest time in proper implementations may end up discouraged and give up trying to publish or even coding them.
Names are the scarcest resource of all. My point of view is that when you take a name you take with it the responsibility of not wasting the cognitive paths associated with it. This is not a small responsibility at all, in my humble opinion.
It probably doesn't apply to the example you gave. Just took the opportunity to voice my concern.