Two people were enough to govern one of the largest package repositories on the planet. Until they weren’t.
This week, the two remaining members of the Nixpkgs core team — known on GitHub as @alyssais and @emilazy — posted on the NixOS Discourse forums that the team was disbanding. No scandal, no single blowup. Just the slow math of open source: not enough hands, not enough trust, and a governance structure that made their work harder instead of easier. The announcement shot to the top of Hacker News within hours, and hundreds of developers piled in with the same tired question: is NixOS dying?
What Happened to the Nixpkgs Core Team
Quick context for anyone who doesn’t live in the Nix world: Nix is a package manager and operating system built around one radical idea — every build is reproducible, byte for byte, from a single description file. Nixpkgs is the giant repository of package descriptions behind it, roughly 100,000 packages at last count. It powers everything from personal desktops to serious CI pipelines that need to know exactly what’s in their software.
The Nixpkgs core team was never supposed to be a big, bureaucratic body. It was stood up in September 2025 to give the repository what the project constitution called “project direction, decision-making, and coordination” — a light-touch leadership layer that could settle disputes, keep momentum, and represent the repo to the NixOS Foundation.
In ten months, two people accomplished more than most teams do in five. They reformed the committer delegation process and onboarded 19 new committers. They extended the merge bot that keeps package updates flowing. They got GitHub to sponsor the NixOS organization’s Enterprise Cloud plan for free. They helped triage a serious GitHub security advisory and tracked the org-level risks that incident exposed. They even wrote the project’s first automation and AI policy — requiring human accountability for LLM-generated contributions, in the same spirit as LLVM, the Linux kernel, Mesa, and Fedora.
Then it fell apart. A founding member left in May. A call for new members brought exactly one applicant for two open seats. “Recruiting sufficiently to keep things healthy looks untenable,” they wrote, “and stepping down is necessary for our health.”
Read that again: necessary for our health. That is not a resignation letter. That is a medical note.
The Pattern Nobody Can Ignore
The team’s parting statement is blunt about why they left. The Steering Committee, they argue, “lacks a native instinct for the delegation envisioned by the constitution.” Decisions that had been formally delegated kept getting pulled back into committee hands. Communication was chronically poor — members often couldn’t tell whether SC members spoke for themselves or for the committee. Matters arrived with desired outcomes already attached. Coordination on things like GSoC, grants initiatives, and AI policy was slow and disjointed, and progress on moderation reform and GitHub org-owner reform crawled.
Sound familiar? It should. This is the second volunteer body in twelve months to collapse pointing at the same institution. In September 2025 — the same month the core team was created — five members of the NixOS Moderation Team resigned in protest over Steering Committee interference with their decisions, a story covered by LWN. Before that, founder Eelco Dolstra had stepped back from the project in 2024. Several longtime contributors published their own painful post-mortems along the way. At some point, a pattern stops being coincidence.
None of this is a villain story. The core team themselves said it: this is a systemic problem, not one committee member’s fault. Representatives have limited time, and a majoritarian body can only do so much. The failure is structural — and that’s exactly why it keeps repeating.
Why This Matters Beyond Nix
It’s tempting to file this under “Nix drama” and move on. Don’t. Nix is the gold standard for reproducible builds — the tool teams reach for when they need cryptographic certainty about what’s in their software. That makes Nixpkgs one of the most security-critical repositories in the world, not because it’s famous, but because so many builds, CI pipelines, and production systems quietly depend on it.
Think about what reproducibility actually buys you. When a dependency gets compromised upstream, a Nix-based build tells you exactly which revision of which package went into every artifact you shipped, because the whole thing is pinned to a hash. That’s why security teams love Nix even when developers grumble about the learning curve. Losing momentum on the governance side doesn’t undo that property. But it does threaten the ecosystem’s ability to respond fast when something goes wrong — and in security, response time is everything.
Here’s the uncomfortable part: the software your supply chain runs on is maintained by volunteers who are burning out in public. We saw the same story across the npm ecosystem this year — a Rust infostealer riding on a compromised package, a worm spreading through cached package data. Every time, the lesson is identical. The packages keep building tonight. The question is who’s left to tend them next year. If you’re responsible for any environment that consumes open source — and every IT department is — it’s worth knowing how to spot a compromised package before it lands in your build.
The Volunteer Economy Is Breaking
The numbers tell the story. One contributor in the Hacker News thread noted that monthly commits to Nixpkgs have roughly doubled in four years, from about 7,000 to 14,000 a month. The repository has grown from a hobby into critical infrastructure — but the people holding it together still work for free, in their spare time, often at real personal cost.
As one commenter put it: “Nix package manager: correctly resolves dependency hell for your entire OS. Nix governance: still hasn’t resolved dependency hell for humans.”
The counterargument matters too. Tomberek, a long-time contributor, pointed out that Nixpkgs ran for roughly twenty years without any formal core team. “This is not a critical emergency,” he wrote. “It’s a return to the status quo of late last year.” Both things can be true: the project will survive this, and it also can’t keep burning through the people willing to do the work. The growth of the past six years changed the stakes — the old normal isn’t coming back.
What I’d Tell the Steering Committee
I manage an ICT division in a Philippine government office, which means I’ve spent years learning the difference between delegating and just saying you did. Delegation isn’t handing a team a task and then overruling them the moment it gets uncomfortable. It’s agreeing on boundaries, then defending those boundaries against everyone — including yourself — when the pressure comes. Every IT organization I’ve been part of has had its own version of this story: a steering body that can’t let go, and a working group that burns out trying to push real work through the friction.
The Nixpkgs core team’s parting recommendation is disarmingly simple: “clear, lightweight processes for decision-making and dispute resolution,” and genuine delegation instead of nominal delegation. That’s not radical. That’s organizational hygiene. The fact that they had to say it twice, loudly, on the way out the door tells you most of what you need to know about where things stand.
There’s an AI angle here that deserves attention, too. The core team’s one automation policy — human accountability for LLM-generated contributions — was an early attempt to answer a question every open source project is now facing: how do you keep AI-assisted contributions flowing without losing trust in what lands in the tree? It’s the same tension I’ve poked at while building my first MCP server and watching AI agents get more involved in development workflows — and Nix’s functional, reproducible model is actually one of the friendlier places for that experiment.
And here’s the part that hits me personally. Open source is the foundation my whole career stands on — the same foundation that quietly runs most of the software in Philippine government offices, often without anyone realizing it. We consume this infrastructure daily and pay for almost none of its maintenance. The health of the people who build it is our problem too, not just theirs.
So what do we actually do? If you use Nix, think about what sponsorship looks like — the team’s one concrete win was convincing GitHub to pay for Enterprise Cloud. If you run any open source in production, budget for maintainership the way you budget for servers: through foundations, paid maintainers, or at minimum, respect for the humans who keep the lights on. The biggest companies in the world are already quietly betting their AI workloads on self-hosted open-source models — the software underneath that trend runs on the same volunteer economy. And if you lead a team, remember the chess lesson — the board wins when the pieces are trusted to move, not micromanaged into paralysis. In boxing, you roll with the punch and keep fighting. Open source has been doing that for decades. It just shouldn’t have to keep doing it alone.
The Open Question
The Nixpkgs core team is gone, and nothing breaks today. Packages still build. The 19 committers they onboarded stay active. The Steering Committee resumes as the final backstop, the way it was before the team ever existed.
But the deeper question hangs over every project that runs on volunteer labor: when the people doing the work say the structure is unhealthy, who listens? Because the next core team — in Nix or anywhere else — is only one burned-out contributor away from disbanding too.