The economics of open source by C J Silverio | JSConf EU 2019
Why Hacker News recommends it
HN recommends it as the best account of what is wrong with npm's governance and why alternative or decentralized registries are hard.
What it is
C J Silverio, former npm CTO, explains how the JavaScript package commons ended up in the hands of a for-profit company with no accountability. She discusses the cost of running a registry and what the community should do next.
Recommended by 2 HN commenters across 2 different months, 2019 to 2020.
What Hacker News said
Recommends pier25 · 2019-06 · on “Pika CDN – A CDN for Modern JavaScript”
This is a great recent talk about this problem by the former NPM CTO in which she tells her story about NPM and proposes a new decentralized package manager: [this video]
Recommends drej · 2019-11 · on “Pika – A JavaScript package registry for the modern web”
For those wondering what's wrong with npm, I can recommend this C J Silverio talk [this video] Sadly, as others have noted, this Pika thing does not quite address these issues.
Cites kostarelo · 2019-06 · on “Entropic – A Federated Package Manager for JavaScript”
I am trying to understand why we make NPM such a big deal (and suddenly have all these projects born to solve the NPM problem) when people have solve the issue of a package repository already. C j Silverio's point (JSConf's talk [1]) was that is NPM's scale that makes it hard. Refs: 1: [this video]
Cites TimothyBJacobs · 2019-09 · on “NPM CEO Bryan Bogensberger Resigned”
There has been. CJ Silverio gave a talk on that topic at JSConf this year: [this video] See also Entropic as a possible alternative to NPM: [LINK]
Cites drewbug01 · 2020-04 · on “GitHub has completed its acquisition of NPM”
> This massively depends on the architecture of the package manager though. Composer (PHPs primary package manager) only serves the metadata See also, CocoaPods. But we're really talking about two things here as if they're the same, and I think it's because the language we use for them isn't clear: package managers (like CocoaPods and Composer) and full-blown package registries (like RubyGems and NPM). I mean, the difference between them is slight; and there's overlap. They both resolve package dependencies and sort out problems, for example. But they're such very, very different things! It's not really fair to compare these two approaches and say things about Composer like "this allows them