nixpkgs has a due-process problem · Domen Kožar

Skip to content

Building tools for better developer environments at cachix.org, secretspec.dev, and devenv.sh.

GitHub ↗<br>Twitter ↗<br>Email ↗

Nixpkgs has a due-process problem.

A project has a due-process problem when people have real power but the rules<br>around it are vague. Nixpkgs committers can merge and close pull requests.<br>Reviewers can block them. Teams can remove commit access and decide policy. Yet<br>the project does not always say what standard applies, who decides, or how a<br>mistake can be corrected.

This is not an argument against strict review. Security, licensing,<br>attribution, maintainer time, and contributor conduct all matter. The glibc<br>work I recently submitted changes the dynamic loader and rebuilds the world. It<br>should be reviewed unusually carefully. I have also made bad merges.

The test of governance is not whether it gives me what I want. It is whether<br>I would accept the same rules if the people and positions were reversed.

Losing the commit bit

I contributed to Nix and NixOS for more than a decade, served as a release<br>manager, and helped give Nixpkgs commit access to hundreds of contributors. On<br>June 8, 2025, the commit-bit delegation<br>removed my access<br>for a &ldquo;consistent pattern of bad judgement.&rdquo; It gave two reasons: I had merged<br>some of my own pull requests soon after opening them, and I had merged an<br>rbtools update that failed to build on every platform.

Both concerns were real. The package was already broken at runtime and I was<br>trying to revive an old leaf package, but I should have checked that the update<br>built. Other contributors later<br>fixed its missing dependencies.

I also should not have merged my pull requests so quickly. A warning thread<br>identified<br>three earlier rapid self-merges<br>and<br>a 37-second self-merged revert.<br>I explained the urgency of the change that prompted the warning, then followed<br>the requested workflow. Another contributor noted that this had been my first<br>formal warning and that<br>I had not self-merged again.

The question is not whether I made mistakes. It is how those mistakes led to an<br>indefinite loss of access, with no defined review or restoration process.

A month earlier, the organization had changed the process. On May 11 it added<br>to the delegation<br>the person who had challenged my merging practice.<br>On May 14 it replaced unanimous agreement on committer-list changes with a rule<br>allowing<br>one delegator to remove a committer.<br>Less than a month later, the new delegator announced my removal.

This sequence does not prove that the rule targeted me or that one person made<br>the decision. The announcement says the team discussed it. What the public<br>record does show is that one-person removal was formally possible, there was no<br>published warning threshold, and<br>the delegation did not contact me first.<br>There was no documented appeal.

The process has since improved. In December 2025, the Nixpkgs core team<br>took over the delegation and published<br>guidelines saying it<br>would try to discuss concerns, give a warning, reach consensus, and identify the<br>participants in a non-unanimous removal.

But these are guidelines the team aspires to follow. The formal rule still<br>says that<br>one member may remove a committer.<br>There is no binding threshold beyond one member, no recusal rule, no response<br>period, and no appeal.

I repeatedly asked the NixOS Steering Committee to review my removal and<br>received no reply. On September 10, 2025, in an email titled &ldquo;your commit bit,&rdquo;<br>the person who announced it apologized and said they believed it had been a<br>mistake and that my access should be restored. Readers cannot independently<br>verify this private exchange. I include it because it exposed the practical<br>gap: even when a member of the delegation later considered the removal<br>mistaken, there was no defined review or restoration process. As of this<br>writing, I still do not have Nixpkgs commit access.

A security-sensitive project must be able to suspend access quickly. But an<br>emergency suspension and an indefinite removal are different operations. The<br>second should require a written allegation, notice, a chance to respond,<br>recusal for conflicts, agreement by several disinterested people, reasons, and<br>an appeal.

Who decided?

Nix is not a direct democracy. It has an elected<br>Steering Committee<br>responsible for technical and community leadership and for ensuring that clear<br>decision and escalation processes exist. The committee has delegated Nixpkgs<br>governance to the<br>Nixpkgs core team, whose<br>mandate includes building bottom-up consensus and resolving disagreements.<br>The Steering Committee&rsquo;s mandate says that delegation does not end its<br>responsibility when a delegated team fails to reach a decision.

The relevant policy had already gone through that structure. After discussion<br>within the core team and with the community team, the core team<br>proposed an automation and AI policy,<br>kept it open for public feedback, and merged it...