The economics of open source by C J Silverio | JSConf EU 2019
JSConf2 HN recommenders · recommended in 2 months, 2019–2020
talk · intermediate · 2019–2020 on HN
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.
HN recommends it as the best account of what is wrong with npm's governance and why alternative or decentralized registries are hard.
Up next
1 mo on HNTypeScript types can run DOOM
Michigan TypeScript
1 HN recommend · 2025–2025
3 mo on HNC++Now 2018: Matt Godbolt “What Else Has My Compiler Done For Me Lately?”
CppNow
3 HN recommender · 2018–2020
6 mo on HNCppCon 2017: Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid”
CppCon
7 HN recommender · 2018–2022
11 mo on HN"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
12 HN recommender · 2014–2024
3 mo on HNWhat is in a Lucene index? Adrien Grand, Software Engineer, Elasticsearch
LuceneSolrRevolution
3 HN recommender · 2019–2020
11 mo on HN🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
11 HN recommender · 2018–2024
11 mo on HNBret Victor The Future of Programming
Joey Reid
12 HN recommender · 2017–2026
10 mo on HN"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
10 HN recommender · 2016–2022
10 mo on HNTim Ewald - Clojure: Programming with Hand Tools
ClojureTV
9 HN recommender · 2014–2024
9 mo on HNUsing Python to Code by Voice
Next Day Video
12 HN recommender · 2013–2025
9 mo on HNTransforming Code into Beautiful, Idiomatic Python
Next Day Video
9 HN recommender · 2014–2022
9 mo on HNAgile is Dead • Pragmatic Dave Thomas • GOTO 2015
GOTO Conferences
11 HN recommender · 2016–2026
5 comments from Hacker News
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.
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
> 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 to serve the whole community with a team of 2-4 people": they're just not directly comparable. Those 2-4 people + the entire GitHub staff is what supports the whole community. Now - don't get me wrong: I think it's fine that GitHub does this! I'm not saying that CocoaPods and Composer are making the wrong choice here at all. In fact, I'm proud to work for a company that provides this service to everyone. But it hand-waves away a lot of stuff as just an "architecture" decision, when in reality it's a decision not to do the hardest part - which is hosting, because it requires gobs of money and dedicated staff and people on-call 24/7. Framing it as just a different "architecture" implies that registries like NPM are making the wrong choices by hosting their own downloads, which I think is no
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
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