Hacker News new | comments | show | ask | jobs | submit login

I'm left thinking of how Go does it, whereby repositories are downloaded via git or whatever version control software's URL. Making it impossible for the admins of "NPM" to take down a package. Add in IPFS and you've got one heck of a "package manager" I guess Go's approach is not really a "package manager" but nobody can truly stop you from downloading from a git repository, and if they do, you can go to the forks etc.

The same can happen with GitHub repositories, though, that is how the vast majority of Go packages get published.

It's almost as if privately controlled, centralized archives are a bad idea.

1. However, it would deal with GP's problem - that is, that somebody else could upload a package with the same name as one of the ones removed and cause ... surprises the next time someone runs npm install.

Github repos are namespaced to their owners, at least, radically reducing the potential for this kind of thing.

2. /s/github/whatever . As long as there's a public URL from which something can be cloned, the idea still works, as long as that URL doesn't someday point to something completely different. Again, not impossible, but less likely than with NPM.

3. There are, like it or not, real advantages to centralised archives - discoverability, optimisation of dependency resolution, etc. 'Privately controlled' is an elastic idea - it seems to me that there's a difference between a non-profit foundation, say, and a for-profit company like NPM or GH, but both are 'privately controlled'. The question is whether these advantages outweigh the disadvantages. In my opinion, they do.

About your third point, discoverability and optimization of dependency resolution can be solved by a proxy, in a decentralized system, like the one used in Go.

IPFS with public keys per developer and signing of packages would solve that.

Except Go isn't GitHub specific, I could use BitBucket, Gitlab, or any service I setup myself. Even locally, just like git itself I suppose. Go supports other tools like Mercurial as well as others.

Hasn't hurt Java devs any. Although we have plenty of mirrors and no concept of unpublishing.

The vendor experiment provides a nice solution to that problem. Check in the vendor directory into your own repository and you always have the required source code available, even after the original author removes his repository on github.

It's just as bad. Commits can be re-written and/or deleted. I've always been surprised that anyone thought release management based on SCM commits was a good idea. It's not.

Without IPFS, pretty sure authorities can order to take down the repository and all of the forks.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact