Skip to content
Published on

Bus Factor Is Not the Number of People Who Know the Code but the Number of People Who Can Decide

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

Introduction — the repository is unchanged but the leadership is gone

On 7 August 2026, a post announcing that the Nixpkgs core team has disbanded went up on NixOS Discourse. qyliss wrote it on behalf of @alyssais and @emilazy, and on the same day PR #277 in the NixOS/org repository was merged, deleting the @NixOS/nixpkgs-core team definition itself.

Nixpkgs is a repository holding more than 100,000 packages. When I counted directly with the GitHub API on 9 August 2026, merged PRs over the previous two weeks or so (since 24 July 2026) came to 4,468.

curl -s "https://api.github.com/search/issues?q=repo:NixOS/nixpkgs+is:pr+is:merged+merged:>=2026-07-24&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"
# 4468

And yet the team carrying the delegated technical leadership of this repository numbered two people. As those two stepped down, the announcement puts it this way: the matters that fell under our jurisdiction are now left without a direct owner.

This post is not an argument for or against using Nix. It is about where you should be measuring the risk of the projects you depend on.

Bus factor is a count of authority, not of knowledge

Bus factor is usually explained like this: how many key people have to be hit by a bus for the project to stop? And it is mostly interpreted as a knowledge problem. Documentation is thin; only one person understands a particular module.

What the Nixpkgs case shows is a different axis. Nixpkgs is not a project with concentrated knowledge. It has thousands of contributors and its committer count keeps growing. One of the things the core team did over ten months was exactly reforming the committer delegation process and onboarding 19 new committers.

Even so, two people leaving the team created a vacuum. Because what those two held was not code knowledge but decision-making authority. The constitutional delegation the announcement quotes is project direction, decision-making, coordination with the NixOS Foundation board, and the creation and management of teams, insofar as these relate to Nixpkgs.

There are plenty of people to write code. The people entitled to say "we are going in this direction" numbered two. These are entirely different counts, and we usually count only the first one.

What the announcement actually says

Before layering on interpretation, let me carry over the facts of the original precisely.

  • The team was active for ten months.
  • As accomplishments it lists reform of the committer delegation process and onboarding of 19 new committers, strengthening maintainer authority by extending the merge bot, resetting the relationship with GitHub and securing Enterprise Cloud sponsorship, supporting triage of the security advisory GHSA-67f2-674w-6g63, and establishing initial automation and AI policy.
  • The direct reason for stepping down is health. The original writes that it did not turn out to be a light role compatible with active technical contribution, and that two weeks ago they reached the conclusion that stepping down was necessary for their health.
  • On recruiting new members, they disclose that only one person actually applied and that responses to outreach were mixed.
  • Of the steering committee, they diagnose that it institutionally lacks the instinct for delegation that the constitution assumes, while also being neither engaged nor cohesive enough to handle individual decisions at that level itself. The result, they say, is unnecessary micromanagement of subordinate teams and chronically poor communication.
  • Finally, they state explicitly that this decision is not because of any single event but the culmination of a long-standing pattern.

That is the original. Nowhere is there any suggestion that Nixpkgs itself is stopping or that development is halting. The repository keeps turning as before.

What collapses when delegation is only a name

The most generalizable part of the announcement is its diagnosis of delegation.

When designing governance structures, this is a common shape. Put a representative body at the top, put per-area teams beneath it, and write in the constitution or the rules that "this area is delegated to that team." On paper it is complete.

The problem is that delegation is an act. It is not delegated by writing it in a document; it is delegated when the higher body actually takes its hands off. The failure patterns the announcement enumerates are exactly that point.

  • Unclear whether a steering committee member is stating a personal opinion or representing a collective position
  • Matters delivered with the desired conclusion already attached
  • The committee handling directly, without the relevant team, matters that fall entirely within a delegated area
  • Responses to raised concerns being insufficient and delayed

The last sentence is decisive: a general uncertainty about whether we are trusted to decide autonomously within the scope of our own authority.

This is how responsibility without authority comes about. The delegated team bears responsibility for outcomes but does not hold finality over decisions. That state burns people out quickly. If you have ever run an internal platform team or an architecture review group, the structure will not feel unfamiliar.

The list of ten months of accomplishments is also the list of functions now gone

Reading the accomplishments list in the announcement as a boast is reading only half of it. Read differently, it is the list of functions that now have no owner.

Committer onboarding, delegation of maintainer authority through the merge bot, reform of GitHub organization ownership, security advisory triage, automation and AI policy, and mediation of escalated disputes.

A good number of these are the kind of work that nobody feels a need for on ordinary days but that is needed immediately the moment it is needed. Security advisory triage especially so. If committer onboarding stops, it shows up as throughput a few months later; if dispute mediation stops, it shows up as thread length. Because nothing fails immediately, risk accumulates quietly.

The announcement itself acknowledges this point. It writes that in many cases the mere fact that the core team could be asked to mediate defused tension and led to conclusions everyone could agree on. That channel does not exist right now.

What this means from a user standpoint

So what should a team using Nixpkgs do? Laid out without exaggeration or minimization, it is this.

Nothing changes right now. Packages keep getting updated and channels keep shipping.

What has changed is the escalation path. Previously there was somewhere to ask about policy-level matters — for example, how to handle LLM-generated contributions, or who holds organization ownership. Now, in the announcement wording, the steering committee remains only as the final backstop, as always. A backstop is not a channel.

And according to the announcement, both people plan to reduce their involvement in Nixpkgs and have no intention of standing for the steering committee. That is, this vacuum persists until someone else takes that seat.

Practically, respond like this. If you have dependencies sensitive to policy change, re-examine channel pinning and the share of your own overlays; do not rely on upstream coordination alone for security advisories but confirm your own vulnerability scanning path; and calculate migration cost now and write it into a document. This does not mean move now. It means know what it would cost when you have to move.

How to actually measure the governance of a dependency

Star count is a popularity metric, not a risk metric. There are, however, things you can count. The commands below are in working form, and since the GitHub search API has a low per-minute request limit when used unauthenticated, attaching a token is advisable.

# merged PRs over the last 90 days — throughput
OWNER_REPO="NixOS/nixpkgs"
SINCE="2026-05-11"
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/search/issues?q=repo:${OWNER_REPO}+is:pr+is:merged+merged:>=${SINCE}&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"

# distribution of who actually merged the last 100 merged PRs — concentration of authority
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}/pulls?state=closed&per_page=100" \
  | python3 -c "
import sys, json, collections
prs = json.load(sys.stdin)
c = collections.Counter(p['merged_by']['login'] for p in prs if p.get('merged_by'))
for who, n in c.most_common(15):
    print(f'{n:4d}  {who}')
print('distinct mergers:', len(c))
"

The second command is the crucial one. If contributors are many but merging is concentrated in a few hands, those few are the bus factor. Conversely, if merging is spread wide, tolerance for individual departures is high.

What cannot be measured in numbers, check in documents. Is the decision-making body documented? Are the delegated areas specified? Is it written down where disputes are escalated? And is there a recent case where that path actually worked? The last item matters most and cannot be automated. You have to read the issue tracker and the forum yourself.

Burnout is an output of process, not of personality

Finally, let me carry over the passage from the announcement that struck me most personally.

The announcement acknowledges that there is a general distrust of governance in the community, and writes that this distrust encouraged an adversarial, zero-sum mode of conflict. It then continues: that mode may be effective against a leadership vacuum or unresponsive governance, but against a leadership team trying to engage in good faith it manufactures burnout.

The consequence, it diagnoses, is that the side that does not listen is rewarded, that the pool of experienced contributors with the time and will to participate in governance shrinks further, and that there is a risk of entrenching the historical phenomenon of decision-making by deadlock and attrition.

This diagnosis is not limited to open source. It applies just as directly to internal architecture review, code owner schemes, and platform teams. When a delegated team does not actually hold decision authority, and there is no formal path for resolving conflict, conflict gets resolved by the most exhausted person leaving first. And because conflict resolved that way leaves no record, the next one gets resolved the same way.

Lowering bus factor is not achieved by writing more documentation alone. Making clear who is allowed to finalize what, and then actually respecting that finality, is half of it.

References

The figure of 4,468 merged PRs is a value queried directly through the GitHub search API on 9 August 2026, and search API results vary depending on when they are run.

Discuss on Twitter • View on GitHub