Open source before GitHub ran on self-hosted Trac, Subversion, and SourceForge, with reputation and friction as natural dependency filters.
Key Takeaways
Pre-GitHub dependency selection required understanding provenance: a package meant a project with a website, maintainer, mailing list, and release process.
GitHub’s most underappreciated contribution was archival: abandoned projects stayed findable; personal servers expired and took their software with them.
The distributed VCS (Git) won, then the world centralized on one hosted service anyway – a structural irony the author calls out directly.
npm plus GitHub removed nearly all friction from publishing and consuming code, accelerating the micro-dependency explosion and stretching the package graph beyond auditable size.
GitHub’s role in trusted publishing (signing npm releases, etc.) means eroding trust in GitHub damages the whole supply chain, not just source hosting.
Hacker News Comment Review
Commenters split on whether GitHub’s archival centralization was net positive: one camp sees it as a public library that preserved the commons; another argues it atrophied decentralized archival habits and created single-point-of-failure risk.
SourceForge nostalgia surfaces alongside CodePlex and code.google.com as reminders that dominant forges die – Google’s abandonment of code.google.com cited as a cautionary precedent for GitHub dependence.
Trac is remembered fondly but as a setup burden; Django still runs a 20-year-old Trac instance, which itself illustrates the author’s friction-as-forcing-function argument.
Notable Comments
@simonw: confirms Trac’s setup friction firsthand; notes Django has run on Trac for 20+ years as living evidence of pre-GitHub infrastructure longevity.
@Lammy: argues centralized archival is harmful – “everything had to be seeded by someone” would have kept collective archival skills sharp.
@pistoriusp: flags code.google.com as the clearest dropped ball in forge history, sharpening the case against platform dependency.
