If I could make my own GitHub

Original Article ↗ Hacker News Discussion ↗

Frustration with GitHub’s pull request workflow, UI, and growing AI focus is driving developers to imagine or build alternative code forges. Commenters debate features like pre-commit CI, stacked reviews, richer approval states, offline-friendly issues and reviews, and tighter integration of code, tickets, and metadata directly into Git repositories. While some advocate self-hosted or existing tools like GitLab, Gitea, Gerrit, Radicle, Tangled, and SourceHut, others argue that any credible replacement must balance simplicity, strong UX, decentralization, and long‑term reliability.

DIY forges and LLM-assisted cloning

  • Several comments argue “doesn’t sound too hard”: with modern LLMs, cloning or reimplementing tools (even closed-source apps) is seen as feasible weekend projects.
  • Others note scope creep: what starts as a weekend project can turn into ongoing work, and “foundational” tools are hard to generalize beyond one’s own needs.

Existing alternatives and self‑hosting

  • Many point out existing self-hosted options: GitLab, Gitea, Forgejo/Codeberg, cgit, Sourcehut, Tangled, Radicle, Grasp, Fossil, Gerrit.
  • Critics argue most still mimic GitHub’s model and inherit its flaws, or suffer from poor UX, complexity, reliability issues, or missing features (e.g., private repos in some decentralized designs).
  • Some like Sourcehut’s minimal, email-centric approach; others want just barebones git hosting with most “bells and whistles” removed.

PR and review workflow problems

  • Strong dissatisfaction with GitHub-style PRs: noisy, UI hides discussion, comments prioritized over code, hard to track revisions, and stacked/iterative review is clumsy.
  • Gerrit’s change-id-based, multi-round review (with comments persisting across revisions) is praised, along with its richer approval states (e.g., -2…+2) and customizable labels.
  • There’s debate over whether approval should be strictly boolean vs multi-level (“partial approvals”, domain-specific signoffs, “approve with suggestions”).

CI, pre-commit hooks, and local vs remote

  • Some want enforced pre-commit/“pre-push” CI run remotely on the forge to catch issues before PR churn.
  • Others push back: conceptually post-push, bad for workflows that commit broken checkpoints, and can be slow; local test commands or tools like pre-commit are preferred.
  • Desire for CI definitions that run identically locally and in CI; frustration that GitHub Actions are hard to replicate offline.

Decentralization, control, and business model

  • Concern over centralizing on GitHub and corporate control (especially post-acquisition), censorship of issue discussions, and AI-driven priorities over reliability.
  • Acknowledgement that running SaaS is expensive, pushing platforms to optimize for large customers and vendor lock-in (e.g., keeping review/issue metadata off-git).

What a “better GitHub” might prioritize

  • Strong UX and reliability are seen as more critical than novel backends.
  • Features people want: stacked PRs, better integration of reviews/issues into git history, offline/“local-first” issues and reviews, simpler hosting modes, flexible review rules, easier private repos, and avoiding YAML-heavy CI.
  • Some note that git already supports partial clones, hooks, and notes, implying more could be built on existing capabilities.