Why GitHub won

GitHub’s rise is attributed to a mix of timing, Git’s growing dominance, and a developer‑focused user experience that contrasted sharply with older platforms like SourceForge and Google Code. Commenters describe how SourceForge’s ad‑driven “enshittification,” awkward workflows, and later malware bundling pushed projects toward GitHub, while Google Code explicitly aimed only to break SourceForge’s monopoly rather than “win” the market. The thread also revisits why Git beat other version control systems, the role of network effects, and current concerns about GitHub’s monoculture and Microsoft ownership despite the technical ease of migrating elsewhere.

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.