A dispute over maintainer access in fsnotify, a widely used Go library for cross-platform filesystem notifications, briefly raised takeover concerns this week after contributors were removed from the project’s GitHub organization and recent releases came under scrutiny.

So far, there’s no evidence that any fsnotify release was compromised. The concern is messier and more familiar: when a popular project has unclear maintainer roles, release access, and review norms, downstream users can’t easily tell whether they’re watching routine open source conflict or the early signs of a takeover.

fsnotify provides cross-platform filesystem notifications for Windows, Linux, macOS, BSD, and illumos. GitHub shows fsnotify with 10.7k stars, 969 forks, and 321k dependent projects. At that scale, uncertainty around who can merge and release code becomes a downstream problem almost immediately. The concern came from its role in the stack: low-level file watching code underneath developer tools, CLIs, dev servers, and infrastructure workflows.

Removed maintainer sounded the alarm after losing access#

The concern began after Yasuhiro Matsumoto, a Go developer known online as mattn, posted on X that he had been removed from the fsnotify GitHub organization. In the now-deleted Japanese-language post, he wrote (AI-supplied translation):

Previously, fsnotify became difficult to maintain, so the project looked for maintainers.

→ I joined as a maintainer because I had relevant expertise.
→ Around that time, another person also joined.
→ When I tried to start contributing, I was scolded for “doing things on your own.”

Some time passed after that.

That person seems to have gotten carried away and removed even the original author of fsnotify from the org, which is honestly scary.

The post was later deleted, but claims from it became a central point of discussion in a heated GitHub issue, where users asked project maintainer Martin Tournoij (@arp242) to explain why other maintainers had been removed.

Grafana Staff Developer Advocate Oshi Yamaguchi, who started the thread, noted that fsnotify is widely used by major open source projects and that downstream users needed more context to evaluate the change.

What made the situation look risky from the outside was the combination of signals: a popular dependency, recent releases, changed maintainer access, a deleted public post, and uncertainty about who had authority to review or publish changes. This is why people started asking supply chain questions.

In April, a user asked whether fsnotify could cut a new release after automated scanners started flagging the project as unmaintained.

“Automatic code scanners consider this project as unmaintained if no new release is available within the last 12 months,” the issue said. “This project crossed that threshold on April 4th 2026.”

The issue shows how security tooling can inadvertently create pressure on a mature infrastructure library that is usually maintained in bursts.

Matsumoto published v1.10.0 soon after, followed by v1.10.1 on May 4, 2026. The latest release fixed inotify behavior where sibling watches that shared a path prefix could be removed or renamed incorrectly.

Maintainer removed access over rushed merges and sponsorship changes#

In the GitHub thread, Tournoij contends that the removed accounts had commit rights for historical reasons, not because they were active maintainers. He said the recent changes were merged too quickly, lacked sufficient discussion, and required cleanup.

“This isn't a case of ‘one maintainer removes other maintainers’ because they were never ‘maintaining’ anything in any meaningful sense until they self-appointed them as such with no discussion and started committing stuff of dubious quality,” he said.

The project had previously handed out commit rights broadly, including to people who had made earlier fixes, and this access no longer matched actual project stewardship.

“In any other project they never would have had commit rights,” he wrote.

Tournoij also pushed back on speculation that the access change represented a hostile takeover or supply chain event.

“This narrative of ‘oh noes, arp242 maliciously hijacked a project’ is just incorrect,” he commented, pointing readers to the commit history. “Seriously? Ya'll need to enhance your calm – the commit log isn't a secret.”

Tournoij said the access removals were a trust and quality-control decision. The recent work had moved too quickly, had not been sufficiently reviewed across fsnotify’s supported platforms, and risked reintroducing the kind of inconsistency he had spent years cleaning up.

He also said the funding change was a major reason he removed access, arguing that Matsumoto committed the sponsorship update directly to main early in the work and without discussion:

Now, all of that would be up to there, but updating the sponsors file as one of the first actions by committing directly to main with no discussion what-so-ever is just taking the piss. Additional context here is that mattn withdrew funds from thanks.dev a few times over the years before having done any work here (other than the aforementioned bugfix).

Matsumoto later acknowledged that part of his deleted X post was wrong, including his claim that access had also been revoked from original maintainers, and apologized.

He also said the FUNDING.yml update was a mistake in hindsight, but said his recent maintenance activity was in response to the project’s lack of a release for more than a year.

“I did not step forward to take anything over; I stepped forward to help a user who had raised an alert that there had been no release for a year,” he said.

Matsumoto pointed to recent bug fixes across Windows, kqueue, and inotify, plus test stabilization, release work, and follow-up on stalled issues. He argued that the work amounted to real maintenance, and said his remaining concern was that fsnotify now lacked another maintainer who could cross-check changes.

Translation added another layer of ambiguity. In the GitHub thread, one commenter noted that Japanese often omits subjects, while machine translation into English may insert one to make the sentence grammatical. Part of the deleted post was translated as “we recruited a maintainer,” though the commenter said Matsumoto “didn't actually say ‘we.’” Matsumoto later said he is not a native English speaker and uses machine translation for source-code comments.

Kubernetes users weighed forks and alternatives#

The concern also surfaced downstream. A Kubernetes issue titled “fsnotify/fsnotify - Healthy or not?” said the project should be watched carefully and, if necessary, Kubernetes should evaluate forks or consider forking it. The issue included notes describing fsnotify as a widely used dependency and pointed to gofsnotify/fsnotify, a separate implementation Matsumoto said he created after losing access to the original org, as something to monitor.

The chaotic way this incident unraveled shows the practical cost of governance ambiguity. Even without evidence of malicious code, a sudden change in who controls a dependency can send downstream users into verification mode.

"Dependencies like fsnotify are 'low' enough in the stack to be 'forgotten' about," Docker principal software engineer Sebastiaan van Stijn, a maintainer of Moby, containerd, and runc, commented on the thread. "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 early stages of a real supply chain compromise and the early stages of a maintainer dispute can look similar from the outside. Both can involve unexpected releases, unclear authority, changes in access, and contradictory public claims.

In xz-utils, the concern was malicious code introduced through a long-running social engineering effort. Maintainers are still shell-shocked from that incident, and users now treat unusual maintainer activity in critical dependencies with more suspicion than they might have a few years ago.

The underlying security issue with fsnotify is that users had limited visibility into how maintainer authority was assigned, removed, or reviewed.

For widely used open source packages, maintainer access stops being an internal matter when users can’t tell who actually controls the release pipeline. The fsnotify incident shows how little ambiguity it takes to set off that review. One access-control dispute in a low-level dependency sent users checking release history, watching forks, and asking whether routine updates were still safe. Clearer project roles and release authority will not prevent every dispute, but they would make access-control changes easier to verify before speculation fills the gap.