The Zig project has formally declared its departure from GitHub and moved its canonical repository to Codeberg, a decision framed by its leadership as a protest against declining engineering standards, unreliable CI, and what they describe as an accelerating, corporate push toward AI-first productization. The public split — announced by Zig’s maintainers and amplified by industry coverage — crystallizes long‑running tensions between large corporate forges and the open‑source communities that depend on them, and it raises urgent questions about CI reliability, governance of AI tooling, and where projects should host their code and community.
Background
Zig’s move was made public on November 26, 2025 when the Zig project posted a migration notice stating the canonical origin for ziglang/zig is now hosted on Codeberg and that the GitHub mirror has been set to read‑only. The post framed the change as a response to systemic problems at GitHub following its acquisition by Microsoft, calling out performance regressions, increased fragility in developer workflows, and an ecosystem that “used to be snappy” but has become “sluggish and often entirely broken.” At roughly the same time, industry outlets summarized the announcement and supplied additional reporting around a high‑profile CI problem involving a script named safe_sleep.sh, which maintainers say contributed materially to long‑running runner outages. Those reports picked up both Zig’s public post and commentary from third parties who examined the issue. This story sits inside a broader pattern: major Microsoft announcements about deep AI integration across Windows, GitHub, and developer tooling have provoked vocal developer backlash across forums and specialist communities. Those public conversations—about Copilot’s expanding footprint, marketing tone, and how platform owners handle AI—help explain why a migration off GitHub resonates for many maintainers and contributors. Community discussion of these issues has been detailed and sustained on several developer forums.
What Zig said — the migration plan and reasons
Immediate change and practical steps
Zig’s announcement was explicit and pragmatic. The maintainers set the GitHub repository to read‑only and declared the Codeberg repository the canonical origin. They described a migration strategy that leaves existing GitHub issues and pull requests intact (treating them as “copy‑on‑write”) while starting fresh issue numbering on Codeberg to avoid confusion. The project urged sponsors to move from GitHub Sponsors to Every.org to reduce dependency on a single proprietary platform for donations.
Core grievances
The public rationale Zig’s lead developer set out centers on four tightly related complaints:
- CI reliability: Zig’s leadership singled out GitHub Actions as being “neglected” and prone to unpredictable scheduling and resource contention, causing blocked CI pipelines and unchecked master‑branch commits. The announcement framed the choice to move as a cost‑effective alternative to buying more self‑hosted runner capacity to paper over platform instability.
- Platform priorities: The maintainers argued that GitHub’s strategic emphasis on AI tooling and product features (including Copilot and AI‑powered UX elements) has shifted engineering focus away from core reliability and developer tools. That pattern, they say, undermines trust in the platform’s basic operational excellence.
- Sponsorship and monetization: GitHub Sponsors was called out as a previously valuable but now declining product after key personnel left; Zig signalled intent to migrate donation flows to avoid single‑vendor lock‑in.
- Philosophical objections to LLMs: Zig’s policy of “no LLM / no AI” in certain contexts was cited as a further reason to avoid a platform that increasingly surface‑promotes AI features to contributors and issue reporters.
Taken together, the message is: for a resource‑constrained, volunteer‑backed foundation, avoiding reliance on a platform perceived to prioritize AI features over engineering integrity is an act of stewardship.
The safe_sleep.sh saga: what’s claimed and what’s verified
The reported bug and impact
Multiple reports, summarized in press coverage, point to a specific operational bug in GitHub Actions runner tooling. The fault — as described in public discussion — involved a replacement of the POSIX sleep behavior with a wrapper script, “safe_sleep.sh,” introduced years earlier and alleged to spin at full CPU in many circumstances instead of sleeping, thereby starving runner resources. That behavior reportedly manifested under high load on CI machines, causing processes to run for hundreds of hours and effectively taking down runner services until manual intervention occurred. Zig contributors reported seeing multiple processes eating CPU and rendering runners inoperative for extended periods.
Timeline claims and verification status
Press accounts assert the problematic behavior was raised publicly in April 2025, that a fix was merged around August 20, 2025, and that related issue threads remained open as late as December 1, 2025. Those reports are credible in tone and consistent across outlets; Zig’s migration post also cites chronic CI problems as a deciding factor. However, the specific GitHub issue and the exact commit history referenced by some coverage were not readily findable via casual public search at the time of writing. That gap may reflect differences in indexing, private issue closures, or the way GitHub surfaced fixes. Because direct inspection of the original issue thread and the exact commit diffs was not consistently available in public search results, readers should treat the most granular claims about commit dates and individual usernames as
reported by maintainers and the press but not independently reproduced here. The core, high‑impact claim — that a sleep wrapper caused full‑CPU spins on runners and that this materially affected Zig’s CI — is attested by Zig’s own migration announcement and contemporaneous press coverage.
Expert reaction
Independent developers and machine‑learning practitioners amplified the critique. In industry discussion, the bug was described as straightforward and glaring in its CPU‑intensive failure mode — which, depending on how the wrapper was implemented, could spin waiting for a one‑second tick if the process missed the narrow scheduling window that lets it return. Observers called the chain of events — slow review, bot‑closed patches, and late merges — emblematic of systemic operational slippage. Journalists and community members framed this as symptomatic rather than isolated. Again, those reactions were widely reported in the same coverage that summarized Zig’s move.
Community ripple effects: Dillo and others
Zig is not alone in publicly moving away from GitHub. Rodrigo Arias Mallo, the maintainer of the lightweight Dillo browser, posted his own rationale for leaving GitHub, citing platform performance, moderation tooling shortfalls, concerns about heavy JavaScript and client‑side dependency, and what he described as an over‑focus on LLMs and generative AI that damages the open web. Dillo’s move highlights how technical and philosophical objections can coincide: maintainers want a hosting environment that is fast, minimally invasive, and aligned with the project’s values. At the same time, Codeberg — the non‑profit German forge Zig selected — has been growing. Codeberg’s public reports note membership moving past 1,000 and repository counts in the hundreds of thousands, which concreteizes a pattern of smaller projects and maintainers looking to federated or non‑profit forges for stability and governance aligned with open‑source values. The platform recently reported candidate membership numbers rising from several hundred to more than 1,200 across 2025. Those numbers are consistent with the narrative that smaller, mission‑driven forges are seeing a revival amid concerns about larger vendors’ strategies.
Why this matters: engineering, governance, and the economics of forges
CI is infrastructure — not a marketing feature
Continuous integration, runners, and build pipelines are foundational infrastructure for modern development. Interruptions in CI affect not just code throughput but contributor experience, code review cadence, and release safety. When community projects report that CI backlogs prevent master commits from being tested, the problem is not superficial; it threatens security, introduces technical debt, and reduces the velocity of the project’s entire contributor base.
Zig’s calculation — that paying for additional runner hardware to compensate for upstream platform instability is a poor use of donor funds — is a rational economic trade‑off for a volunteer‑run foundation. The alternative (move to a platform whose running costs and reliability match the project’s risk profile) is, in that light, an act of budgetary stewardship.
AI strategy vs. engineering discipline
The broader context in which Zig’s migration occurred is Microsoft’s and GitHub’s public pivot to AI‑heavy tooling: Copilot has evolved from an autocomplete to a suite of agentic features that can open PRs, attempt multi‑file edits, and automate developer tasks. Microsoft’s own investor communications report very rapid adoption of Copilot: Satya Nadella said GitHub had “over 1.3 million paid GitHub Copilot subscribers” on the Q2 2024 call, and later reported “over 15 million GitHub Copilot users” in Q3 2025 — numbers that underscore how Copilot is both a product growth engine and a strategic priority inside Microsoft’s developer tooling portfolio. Those figures help explain the commercial incentives for GitHub to invest heavily in Copilot and agent features. But adoption is not the same thing as maturity. Community critiques have focused on governance, provenance, and the risk that AI suggestions — if not carefully audited — can insert buggy or insecure code into projects at scale. Developer fora are filled with pragmatic recommendations: treat AI suggestions as drafts, require CI and security scans on AI‑generated code, and maintain strict review and provenance controls. These debates are visible across multiple community observations and threads.
The risk of vendor lock‑in and platform concentration
Large platform providers deliver convenience and scale, but they also concentrate control. Evolving feature priorities at a platform level (for example, shifting engineering attention toward LLM products) have outsized effects on thousands of downstream projects. Sponsors, CI hosting, issue triage features, and moderation tools can all be subject to vendor roadmaps. When projects depend on those features for fundraising or contributor onboarding, the vendor’s product strategy becomes a governance vector for the project.
Zig’s move makes a policy argument: that decentralization and non‑profit forges protect project autonomy and reduce exposure to product decisions that may conflict with project values.
Strengths and weaknesses of the choices being made
Strengths of Zig’s approach
- Principled stewardship: By aligning platform choice with operational and ethical priorities (CI reliability, anti‑AI policies for certain contexts, donation stability), Zig is signalling coherence between values and infrastructure.
- Cost discipline: Avoiding expensive runner capacity purchases to compensate for platform deficiencies preserves donor funds for core development and associated community programs.
- Ecosystem diversification: Moving to Codeberg both reduces single‑vendor dependence and helps grow the ecosystem of federated forges, which benefits the broader open‑source commons.
Risks and trade‑offs
- Discoverability and contributor friction: GitHub is the de‑facto social graph for many developers. Moving to a smaller forge introduces friction for contributors unfamiliar with Forgejo/Codeberg workflows, potentially reducing volunteer contributions over time.
- Tooling gaps and service parity: Not every alternative forge offers the same set of integrations (e.g., macOS runners, certain marketplace integrations, or enterprise SSO flows). Projects may need to invest effort into CI configurations, mirrors, and contributor documentation.
- Sponsorship economics: GitHub Sponsors provided a low‑friction donation path that materially helped many maintainers. Recreating an equally frictionless model off GitHub is challenging and may reduce recurring revenue unless projects can successfully migrate donors.
- Operational overhead: Smaller forges may require more hands‑on participation from maintainers to manage mirrors, CI runners, and cross‑forge automation.
What GitHub (and large forges) should consider
- Prioritize engineering hygiene: An explicit program to reduce regression velocity and keep CI primitives rock‑solid would go a long way to restoring developer trust.
- Govern AI features with transparency: Publish provenance metadata for Copilot suggestions, model versions used, and provide enterprise‑grade audit trails for auto‑applied changes.
- Offer migration safety nets: Build better export/migration tools and sponsor continuity features (donation migration tooling, mirrors) to ease movement for projects that choose to leave.
- Improve CI observability and control: Expose clearer scheduling guarantees, job prioritization controls, and better isolation for self‑hosted runners to reduce “vibe scheduling” complaints and provide manual intervention paths.
These steps are practical and respond to the core technical and trust deficits voiced by community members.
Practical advice for maintainers and orgs evaluating a move
- Audit your CI surface: quantify how many workflows are GitHub‑only, what runner types you need, and compute the cost to self‑host or replicate alternatives.
- Test migrations on low‑risk repos first: try mirror workflows, update contributor guides, and measure PR velocity changes before committing to a full migration.
- Protect donation flows: map out current donor channels and have a clear plan (e.g., Every.org, OpenCollective, direct bank options) before sunsetting Sponsors‑based perks.
- Harden review gates: regardless of hosting, require dependency checks, security scanning, and explicit human sign‑off for AI‑suggested PRs.
Final analysis — what this episode reveals about today’s open‑source ecology
Zig’s departure from GitHub is both symbolic and substantive. Symbolically, it is a high‑visibility rebuke of a major platform’s priorities at a time when corporations are rapidly evolving AI capabilities at scale. Substantively, it stresses the reality that core engineering primitives — CI, code hosting, and sponsorship mechanisms — are foundational to project health, and when those primitives falter, maintainers will make hard, pragmatic choices to preserve project continuity.
This episode also exposes a tension that will define developer platform policy in the next several years: how to reconcile rapid product innovation (particularly in AI) with the careful engineering discipline and governance developers expect from infrastructure providers. Projects like Zig opting for Codeberg will not by themselves topple the major forges, but they nudge the ecosystem toward pluralism. That pluralism — a healthy mosaic of corporate, non‑profit, and federated forges — is the most durable long‑term hedge against single‑vendor systemic risk.
Readers should note that while the high‑level facts here (Zig’s migration, Codeberg’s membership growth, Dillo’s migration rationale, and Microsoft’s Copilot usage claims) are verified through public project posts and earnings transcripts, some narrow operational claims about specific GitHub issue threads and exact commit timings reported in the press were not independently reproduced in every primary source during reporting and should therefore be treated with measured caution. The practical takeaway is clear: open‑source projects will increasingly balance engineering reliability, platform governance, and philosophical fit when choosing where to live. The Zig migration is a leading indicator of that recalibration, not the final word.
Source: theregister.com
Zig quits GitHub, gripes about Microsoft's AI obsession