Before GitHub

Original Article ↗ Hacker News Discussion ↗

Open source developers reflect on how code hosting evolved from self‑hosted tools like Trac, Bugzilla, and SourceForge to today’s near‑monopoly of GitHub, and what has been gained and lost along the way. Many praise GitHub for lowering friction, standardizing workflows, and acting as a de facto archive, but worry about centralization, enshittification under corporate ownership, DMCA takedowns, and fragile access to issues and discussions. Alternatives such as GitLab, Forgejo/Codeberg, Fossil, and archival efforts like Software Heritage are cited as ways to regain decentralization and long‑term preservation, though federation, spam control, and CI funding remain hard problems.

Pre-GitHub Tools and Workflows

  • Many recall Trac, Bugzilla, Mantis, SourceForge, CodePlex, Launchpad, SVN, and even Visual SourceSafe.
  • Trac and Bugzilla are remembered as powerful but often painful to set up and configure; flexibility led to complexity.
  • SourceForge is remembered fondly before heavy ads/adware; it was crucial for cheap binary hosting.
  • Self‑hosted infra (SVN + Bugzilla, early Git + cgit) was common, even for medium projects like desktop environments.

What GitHub Changed

  • Lowered friction to start and share projects, shifting from “project-centric” (SourceForge) to “person-centric” repos.
  • Provided integrated issues, PRs, wikis, releases, and CI over time, not all at once.
  • Standardized workflows and URLs; easy issue creation and shared logins significantly reduced collaboration friction.

Centralization, Archival, and “Library of Alexandria” Risk

  • Some praise GitHub as an informal archive: abandoned projects remain discoverable.
  • Others see this as dangerous centralization: DMCA takedowns can erase all forks, and people lose local archival habits.
  • Concern that “if it’s not on GitHub, it doesn’t exist” marginalizes other hosting.
  • Several mention independent archival efforts (e.g., GitHub’s own archive program, Software Heritage).

GitHub’s Perceived Decline

  • Some say GitHub keeps improving and don’t see the “decline.”
  • Others cite worsening uptime, flaky Actions, AI-focused product changes, and Microsoft ownership/strategy as worrying.
  • Enshittification and “big-company acquisition decay” are recurring themes.

Self-Hosting and Alternative Forges

  • GitLab is viewed as powerful; its CI is praised by some and deemed overcomplicated by others.
  • Gitea/Forgejo and Codeberg are popular alternatives; performance and capacity are concerns for large migrations.
  • Self-hosting is seen as feasible for small teams, but resilience to traffic spikes and maintenance burden are issues.

Version Control Alternatives (Fossil, Mercurial, etc.)

  • Strong advocacy for Fossil’s all‑in‑one model (code, tickets, wiki, forum in a single SQLite file), especially for small teams and freelancing.
  • Critiques: opinionated workflow, poor fit for large organizations, and some awkward separations (docs vs wiki, tickets vs commits).
  • Nostalgia for Mercurial, Bazaar, darcs; sense that Git “won” largely via kernel adoption and ecosystem momentum, not technical inevitability.

Federation, Identity, and Spam

  • Decentralized forges are attractive for sovereignty, but federation is “the hard part.”
  • Repeated pain points: needing many logins to file issues, and rampant spam on open registration instances.
  • Suggestions range from ActivityPub/ForgeFed to simply using email/git send-email, which already federate well.

Need for a Long-Term Archive

  • Multiple comments emphasize a “boring, well-funded” public archive for code and its metadata (not just commits, but issues, PRs, discussions).
  • Existing initiatives are praised but seen as underfunded relative to the scale of open source.