# fsnotify Maintainer Dispute and Supply-Chain Concerns

In early May 2026, Yasuhiro Matsumoto ([[mattn]]) posted on X that he had been removed from the [[fsnotify]] GitHub organization. [[fsnotify]] is a Go library for cross-platform filesystem notifications with 321k dependent projects — low in the stack under most Go CLIs, dev servers, and infrastructure tools. From the outside, the combination of signals — a popular dependency, recent releases, sudden maintainer removals, a deleted public post, and unclear release authority — read enough like the early stages of a supply-chain attack that Grafana opened a public issue, Kubernetes opened a "Healthy or not?" issue and floated forks, and Socket wrote it up.

There is no evidence any fsnotify release was compromised. The interesting part of the story is that *governance ambiguity itself triggered a supply-chain response* — which is the right reaction in the post-xz-utils world, and which makes "who controls the release pipeline" the operational variable, not the code.

## What actually happened

The project's original maintainer, Martin Tournoij ([[arp242]]), had over years handed out commit rights broadly — to people who had landed earlier fixes, historically. That access "no longer matched actual project stewardship." When mattn stepped in to resume maintenance (the project had not cut a release in over a year, and automated scanners had begun flagging it as unmaintained — see [[unmaintained-scanner-pressure]]), arp242 felt the work was being merged too quickly across fsnotify's many platforms (Windows, Linux, macOS, BSD, illumos), without sufficient review, in ways that reintroduced inconsistencies he had spent years cleaning up.

The decisive event was a `FUNDING.yml` change. mattn committed an update to the project's sponsorship file directly to `main` early in his work, with no discussion. arp242's read: the new contributor was redirecting project funding before having built any review history. mattn later agreed the commit was a mistake.

arp242 then removed commit access for accounts he considered inactive historical maintainers. In a since-deleted Japanese-language X post, mattn — using machine translation — wrote a description that, in English, read as if arp242 had also removed the project's original author. Japanese omits subjects in ways English doesn't; the translator inserted a "we" that mattn didn't write. mattn later corrected the post, said the original-author claim was wrong, and apologized.

Versions 1.10.0 and 1.10.1 had already shipped from mattn's recent work (the 1.10.1 fix addressed an inotify case where sibling watches sharing a path prefix could be removed or renamed incorrectly). After the dispute, mattn created a separate `gofsnotify/fsnotify` implementation, which Kubernetes filed under "things to monitor."

## Why this looked like a supply-chain incident

The piece of this worth keeping is the outside-observer view. Downstream users *can't easily distinguish* a real takeover from an internal dispute, because the visible signals are the same:

- An unexpected release.
- A change in who has commit access.
- Conflicting public statements.
- Deletion of an original public post.
- A new fork or rival implementation appearing.

This is the [[maintainer-governance-ambiguity]] failure mode: the project's actual decision-making is private (and routine) but the access events are public (and read as escalation). [[xz-utils-incident|xz-utils]] is the reference incident — a real social-engineering takeover that, for almost a year, was indistinguishable from "a new maintainer is doing more work than the old one."

Sebastiaan van Stijn (Docker / Moby / containerd / runc maintainer) said the quiet part on the Kubernetes thread: *"Dependencies like fsnotify are 'low' enough in the stack to be 'forgotten' about. Supply-chain attacks are a reality, and dependabot makes it very easy for projects to 'just update a dependency' without giving it much thought."* The combination of low-stack-depth dependency, automated updaters, and ambiguous maintainer authority is the actual risk surface.

## Pressure from automated scanners

A secondary thread in the story: an April 2026 issue (fsnotify#735) pointed out that automated code scanners flag projects with no release in 12 months as unmaintained. fsnotify crossed that threshold on 2026-04-04. The scanner output created downstream pressure for someone to ship a release — which is part of what motivated mattn to step in. This is a structural problem in current security tooling: mature infrastructure libraries are often *correctly* maintained in bursts, but binary "stale = bad" heuristics generate noise that pressures projects into releasing churn or into "anyone willing" stepping forward. See [[unmaintained-scanner-pressure]].

## What it would take to make this kind of event verifiable

The article doesn't prescribe; the structural point is implicit. For widely-used projects, maintainer access stops being an internal matter the moment downstream users can't tell whether release-pipeline control just changed hands hostilely. Concrete defenses worth keeping in mind for any project at fsnotify's depth in the stack:

- **Document maintainer roles** — who can merge, who can release, who is "historical commit-bit" vs "active maintainer." A `MAINTAINERS.md` with current/inactive sections is enough.
- **Make access changes auditable in-repo** — when commit rights are added or removed, leave a record in a way downstream tooling can read (CODEOWNERS history, a `MAINTAINERS.md` PR, a project-decisions file).
- **Separate release authority from commit access** — release tags signed by a known key, release workflows scoped to specific maintainers. Commit rights should not automatically grant release rights.
- **Don't run sponsorship/funding changes as silent direct-to-main commits** — these are not a code change; they are an authority statement. PRs with discussion exist for a reason.

None of these would have prevented the dispute. They would have shortened the period during which downstream users couldn't tell takeover from drama.

## Cross-references

- [[supply-chain-security]] — broader concept
- [[maintainer-governance-ambiguity]] — the underlying failure mode
- [[unmaintained-scanner-pressure]] — automated-scanner heuristics as a forcing function on mature projects
- [[xz-utils-incident]] — the canonical case where governance ambiguity hid a real attack
- [[fsnotify]] — the project itself
- [[mattn]], [[arp242]] — the two people at the center
- [[socket-blog]] — source publisher