The Economics of Package Management
github.com
github.com
I agree with the author that there will one day be a reckoning with npm, inc - they'll shut down abruptly, or do something people are really unhappy with.
However, I'm afraid the package manager proposed at the end will have a lot of trouble gaining traction. It sounds like package maintainers will have to port their packages to the new package manager. Worse, developers won't be able to build, say, React until all 1000 of its indirect dependencies have been ported.
This will take a gargantuan effort to port over, all to avoid a vague future threat. I know it's "the right thing" to use this more decentralized system, but I can't see us getting to there from here with all the pain in between.
I think this is a more likely outcome:
1. npm, inc does a bad thing that makes people angry 2. A community-governed, charity-hosted registry appears. This registry includes everything in registry.npmjs.org, plus exclusive packages 3. users and authors switch to new community registry
In fact, we may already be poised for this coup. Did you know that 1/3 of all package installations go through registry.yarnpkg.com?
Entropic will mirror all packages you install from the legacy package manager.
Not sure what that exactly means, but it _sounds_ like it will proxy packages from npm in some manner.Couple notes regarding TFA:
- Author rightly points out to look at a company's incentive; what are their incentives to release a new package manager?
- "Javascript commons" is a bad term; node.js' API is based on CommonJS [1], and these two are too close; besides, "JavaScript" is trademarked