Why GitHub won

Original Article ↗ Hacker News Discussion ↗

Why GitHub Won vs. Other Forges

  • Many see GitHub’s success as a mix of timing and “taste”: launched as DVCSs were rising, focused narrowly on Git, and shipped a clean, developer-centric UX when others were clunky or ad-driven.
  • Pull requests, easy forking, and a pleasant web UI greatly lowered the barrier to contributing to open source, versus mailing-list patches and centralized commit rights.
  • Competitors (SourceForge, Google Code, Bitbucket, CollabNet) are described as enterprise- or distribution-focused, slow to adopt Git, or lacking polish and consistent UX.
  • Network effects reinforced the lead: once “all the cool projects” were on GitHub, people migrated even if they preferred Mercurial or other tools.

Git vs. Other Version Control Systems

  • Older developers recall CVS/SVN/Perforce/Visual SourceSafe as painful, especially for branching, merging, offline work, and server dependence.
  • Git’s local commits, cheap branching, and offline workflows were a huge leap, even if its CLI UX is considered confusing and “user-hostile.”
  • Several argue Mercurial or bzr had better UX and concepts, but lost out due to performance, weaker hosting ecosystems, and GitHub’s Git-only bet.
  • Some note that most teams now use Git in a de facto centralized way, with GitHub as “the server,” blurring DVCS vs. centralized distinctions.

SourceForge, Google Code, and Monoculture

  • SourceForge is remembered as initially crucial, then increasingly “enshittified”: ad-saturated pages, misleading download buttons, and eventually bundled adware/“grayware.”
  • A Google Code insider states its goal was to break SourceForge’s monoculture, not to “win” or make money; they shut it down once alternatives existed, keeping an archive.
  • Others criticize this posture as a cop-out and cite the shutdown as part of a broader pattern of Google abandoning products users rely on.

Concerns About GitHub Dominance and Lock-In

  • Some worry GitHub is now its own monoculture, but point out viable alternatives (GitLab, Bitbucket, self-hosted Gitea/Forgejo, SourceHut, etc.) and easy migration of raw Git history.
  • Lock-in is seen more in ecosystem features (issues, PRs, cross-repo references, GitHub Actions) than in Git itself.
  • There is discomfort with a proprietary, Microsoft-owned platform sitting at the center of open source, especially given Copilot’s training on GitHub code.