Nginx has moved to GitHub

Original Article ↗ Hacker News Discussion ↗

Nginx’s move from a Mercurial-plus-mailing-list workflow to active development on GitHub is seen as both a modernization step and another sign of GitHub’s growing centrality in open‑source infrastructure. Commenters weigh the practical benefits of GitHub’s tooling and code search against concerns about vendor lock‑in, Microsoft’s data practices, and the fragility of concentrating so many critical projects on one proprietary platform. The change also revives debates over email‑based contribution workflows, the decline of Mercurial, and the current health and fragmentation of the Nginx ecosystem.

Migration process & mailing lists

  • Questions on how nginx will handle the interim period where patches are still sent via mailing list but development moves to GitHub.
  • Several comments explain the traditional email‑driven workflow: contributors send patches to a list, maintainers apply them locally with tools like git am, review by email, and then push to the canonical repo.
  • Some expect a temporary “double‑duty” period: maintainers accept both email patches and GitHub contributions until a cutoff date.
  • Opinions differ on email workflows: some find them archaic and painful; others note they’re still common and well‑supported by tooling.

State of nginx and its forks

  • Thread asks about nginx’s health after the original core team split and multiple forks emerged.
  • Consensus: mainline nginx is still widely used and “fine,” with forks like freenginx, Angie, TEngine noted but seen as niche or domain‑specific.
  • Many large deployments already build nginx from source, so switching upstreams is considered feasible if needed.
  • Some point out nginx’s role as a common Kubernetes ingress controller, though others note alternatives such as Traefik and Envoy.

GitHub code search & login requirement

  • Multiple comments discuss the annoyance of “sign in to search code” on GitHub.
  • Some praise GitHub’s code search as technically strong and worth the friction.
  • Experiences with login persistence differ: some rarely reauthenticate; others report frequent logouts and 2FA prompts, which they find disruptive.
  • Explanations offered:
    • Business/tracking motive and “enshittification.”
    • Abuse and resource constraints from anonymous scraping and DDoS, based on reported internal knowledge.
  • Several workarounds mentioned: cloning with --depth 1, using third‑party search (grep.app, Sourcegraph), or browser‑VSCode frontends.

Centralization on GitHub & ecosystem concerns

  • Worry that too much of the open source ecosystem (including nginx) is concentrated on GitHub, raising resilience and monopoly concerns.
  • Counterpoint: Git itself provides local copies, and GitHub adds valuable extras (issues, CI, actions, hosted runners like macOS) that are hard or costly to self‑host.
  • Some argue projects should favor self‑hosted or open alternatives (Gitea, GitLab, Codeberg, Sourcehut), but others stress the practical benefit of “going where the community is.”

Version control choices: Git vs Mercurial

  • Several lament nginx dropping Mercurial, which some view as conceptually simpler and nicer than Git.
  • Others note that Git has effectively become the default expectation, with email‑centric or Mercurial‑based workflows seen as niche or inconvenient.
  • A few mention newer tools that try to hide Git’s complexity while remaining compatible.

Side tangents

  • Heated but informative pfSense vs OPNsense debate: technical capabilities, build openness, and perceived behavior of respective companies.
  • One commenter mentions avoiding nginx due to Russian provenance and personal ethical choices, noting alternatives now exist.