Before GitHub: Open Source Memory, Trust, and What Comes Next
Open source has changed shape at least three times in one generation.
First, projects lived on personal servers, university machines, SourceForge pages, mailing lists, and self-run trackers. Then GitHub became the default center of gravity: code, issues, pull requests, release assets, and social identity all in one place. Now that center is starting to look less stable, and many teams are asking the same question at the same time:
If we decentralize again, how do we keep the memory of what was built?
That question sits behind Armin Ronacher’s recent essay, Before GitHub, and it is more important than the latest hosting migration headline. The harder problem is not where we push commits tomorrow. The harder problem is whether important software history remains searchable, verifiable, and recoverable ten years from now.
Open source before the platform era
A lot of developers entered open source during the GitHub era, so it is easy to assume this has always been normal. It has not.
Before GitHub, publishing code often meant running your own infrastructure stack: version control server, ticket tracker, documentation, release files, and sometimes mailing lists. Teams carried their own operational burden. In exchange, they had more autonomy.
That older world had obvious drawbacks:
- Setup and maintenance were expensive for small teams.
- Discovery was fragmented.
- Collaboration flows were inconsistent from project to project.
- Project survival depended heavily on individual maintainers keeping servers alive.
But it also had a hidden strength: choosing a dependency usually forced more deliberate judgment. You were not just adding a package name; you were evaluating a project’s reputation, release habits, and long-term credibility.
What GitHub got right
It is fashionable to critique GitHub right now, but that can erase why it became dominant in the first place.
GitHub dramatically lowered the cost of participation. It normalized contribution for people who never touched mailing-list workflows. It made discovery far easier than the old web of disconnected project homes. It standardized collaboration around pull requests and visible history. For a long stretch, it was a very good default.
The under-discussed contribution was archival side effects.
By concentrating so much open source activity in one place, GitHub unintentionally became a public memory layer. Even dormant projects often remained findable. Old issues and design debates stayed linked. Fork networks preserved context that would have vanished in a fully fragmented ecosystem.
That centralization created risk, but it also created continuity.
Frictionless publishing changed dependency behavior
The combination of GitHub plus modern package registries changed more than tooling. It changed norms.
When creating and consuming packages became nearly frictionless, dependency graphs exploded. Tiny utilities became independently published artifacts. Reuse accelerated, but so did transitive complexity and supply-chain ambiguity.
In earlier eras, friction acted as a forcing function. Vendoring was common because external distribution could be unreliable. Teams paid a higher up-front cost but often had clearer ownership boundaries.
In the platform era, the cost shifted:
- Integrating dependencies became easier.
- Auditing dependency trees became harder.
- Trust moved from personal/project reputation toward platform and ecosystem signals.
That trust shift matters. If the platform layer becomes unstable, the impact ripples across code hosting, package publishing, CI assumptions, and day-to-day maintainer workflows.
The current signal: confidence is cracking
Recent stories on Hacker News reflect this directly. One of the loudest examples is Mitchell Hashimoto’s announcement that Ghostty is leaving GitHub. The post is emotionally direct, but the technical point is straightforward: a distributed VCS is not enough when issue tracking, review, automation, and project operations depend on centralized services that feel unreliable.
This is why the “Git is distributed” reply misses the operational reality. Git objects are portable. Collaboration context is not automatically portable.
A repository mirror is easy. A full project memory mirror is hard.
Decentralization is healthy and costly at the same time
Moving away from a single default forge can be good for ecosystem resilience. It reduces single-vendor dependence and encourages alternatives to compete on governance, reliability, and maintainer experience.
But there is no free lunch.
Dispersion increases the chance of loss in exactly the layers that future maintainers need most:
- Security advisories tied to specific releases
- PR discussion context for architectural decisions
- Historical issue threads documenting known tradeoffs
- Old binary assets and release artifacts
- Cross-project links that explain provenance
Code can survive while meaning disappears.
That is a real risk because software maintenance is mostly context retrieval. Teams spend less time writing new lines than understanding why older lines exist.
Why software memory now needs first-class infrastructure
If we accept that open source homes will diversify again, archival strategy cannot remain accidental.
We need institutions and tooling designed for continuity, not engagement metrics. Software Heritage already demonstrates the direction: archive broadly, keep identifiers stable, and make retrieval practical over long time horizons.
The missing piece is cultural, not just technical. Projects should treat preservation as part of release engineering, not as an afterthought.
A practical preservation baseline for serious projects could look like this:
- Mirror source and tags to at least one independent remote.
- Archive every release artifact with durable checksums.
- Export issue/PR metadata snapshots on a scheduled cadence.
- Keep machine-readable changelogs that survive platform migration.
- Document provenance for external dependencies and critical build steps.
- Register projects with long-lived archival services where possible.
None of this is glamorous. All of it reduces future incident cost.
The next chapter: keep memory, reduce dependence
The lesson from the pre-GitHub era is not “go back.”
The lesson is to separate two concerns that were fused by convenience:
- Productive collaboration surfaces (forges, review UIs, automation workflows)
- Long-term memory systems (archives, immutable release records, durable metadata)
One company can offer the first. The second should not depend on one company remaining stable forever.
GitHub may recover strongly. Alternative forges may gain meaningful share. Both can be true. The strategic move for maintainers is the same either way: design project operations so migration is survivable and history is preservable.
Open source does not just need better tools for writing code. It needs better tools for remembering what code meant.