HackerTube.dev

The economics of open source by C J Silverio | JSConf EU 2019

JSConf · 92.5K views · 2019-06-03 · 37:43

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

HN recommends it as the best account of what is wrong with npm's governance and why alternative or decentralized registries are hard.

Recommended by 2 HN people across 2 months · HN mentions 2019–2020

Topics

Software practice, open source & careersWeb development
Search by tags
npmopen source sustainabilityjavascriptpackage managementdecentralized registry

What people said

drej · 2019-11 · Recommendation

For those wondering what's wrong with npm, I can recommend this C J Silverio talk [VIDEO] Sadly, as others have noted, this Pika thing does not quite address these issues.

Read the original HN comment ↗
pier25 · 2019-06 · Recommendation

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: [VIDEO]

Read the original HN comment ↗
drewbug01 · 2020-04 · Reference

> 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

Read the original HN comment ↗

Sources

Video by JSConf, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources