GitHub and the crime against software
Mounting frustration with GitHub’s outages, UI bloat, and AI‑driven feature priorities is prompting developers to question its reliability and long‑term direction under Microsoft. Commenters weigh the trade‑offs between staying on a dominant, deeply integrated platform versus moving to alternatives like GitLab, Codeberg, Forgejo, or fully self‑hosted setups—while noting that issues, wikis, CI/CD, and “GitHub stars” create significant lock‑in beyond the raw git repositories. Many see self‑hosting and more modular toolchains as attractive in principle, but acknowledge the operational overhead, security concerns, and powerful network effects that keep most projects on GitHub for now.
Alternatives and mirroring strategies
- Many suggest mirroring repos to multiple forges (GitHub, GitLab, Codeberg, etc.) via multiple
pushurlentries, which some learned about for the first time. - Others propose decentralized or emerging options: Forgejo-based hosts, Gitea, sr.ht, tangled.org, radicle.dev, Nostr-based git, or even a bare-repo VPS/Mac mini on a VPN tailnet.
Issues, PRs, and project metadata lock-in
- Several argue the real lock-in is not git hosting but the surrounding ecosystem: issues, PRs, wikis, discussions, CI/CD, and historical context.
- Moving code is easy; migrating workflows, integrations, and metadata is described as hard and often proprietary.
- Some advocate splitting tools (e.g., YouTrack/Jira, Gerrit, separate wikis, chat) for flexibility, while others see this as a search and complexity nightmare and prefer everything in one place.
Self‑hosting tradeoffs
- Self-hosting Forgejo/Gitea on cheap servers or NAS devices is reported as straightforward and low-maintenance by some.
- Others describe GitLab self-hosted as heavy (large images, high resource usage) and a security/ops burden.
- A few foresee a “return to self-hosting,” but note most people don’t want to pay for or run their own forge.
Centralization, network effects, and stars
- Strong network effects are cited as the main reason GitHub remains dominant, even with credible alternatives.
- GitHub stars are seen as a powerful “currency” for project legitimacy, with claims they can be bought and thus distort adoption.
- This star economy is framed as a key source of lock-in; importing stars elsewhere doesn’t solve ongoing accumulation.
Reliability, performance, and AI focus
- Commenters highlight frequent GitHub outages and point to changelog data: many “Copilot/agent” entries and none labeled “performance/reliability.”
- The UI is criticized as bloated and JavaScript-heavy, with one breakdown listing hundreds of JS files loaded even for simple pages, including Copilot-related bundles.
- Others report GitHub largely “just works” for them, with rare impactful outages.
Debate over root causes and article tone
- One camp blames Microsoft/GitHub’s prioritization of AI features over stability and a decade of technical debt.
- Another attributes recent pain to a sudden explosion of automated activity from AI coding tools, arguing no team could have scaled fast enough.
- Some find the original article overly negative or ideological; others defend criticism as legitimate given enterprise usage and SLAs.