fsnotify の maintainer 権限まわりで少し騒ぎになっている。
日本語圏では、mattn 氏が X で発信したこともあって、「arp242 氏が横暴に maintainer を外した」「有名 OSS を乗っ取った」「怖い」みたいな受け止め方がかなり広がっているように見える。
ただ、GitHub 上の issue や commit log、実際の contribution を見ると、この見方はかなり雑ではないかと思った。
少なくとも、公開情報を見る限り、arp242 氏が一方的に悪いという話には見えない。むしろ、実質的に長く fsnotify をメンテしていた arp242 氏が、過去の緩い権限付与によって残っていた commit 権限を整理した、という見方のほうが自然に見える。
■ fsnotify は「誰のプロジェクト」だったのか
まず前提として、fsnotify は Go のファイル監視ライブラリで、いろいろなプロジェクトに使われている。Kubernetes などでも間接的に関係するため、supply chain 的にも軽く扱えるものではない。
今回の騒動では、「元 maintainer が外された」「original author まで外された」みたいな話が広がったように見えるが、ここはかなり慎重に見る必要がある。
GitHub の Issue #757 で arp242 氏は、過去に repo が archived されていたこと、自分が Nathan に連絡して引き継ぎ、かなりの時間をかけて整理してきたことを説明している。
また、commit log を見ても、近年の実質的なメンテナンスは arp242 氏がかなり担っていたように見える。arp242 氏自身も以下のような contributor 数を出している。
178 Martin Tournoij <[email protected]> 160 Nathan Youngman <[email protected]> 112 Chris Howey <[email protected]> ... 15 mattn <[email protected]> ... 5 ICHINOSE Shogo <[email protected]>もちろん commit 数だけがすべてではない。だが、少なくとも「arp242 氏は急に現れてプロジェクトを乗っ取った人」ではない。むしろ、長い間かなり実質的に面倒を見ていた側だと見るべきだと思う。
■ 古い commit 権限と、現在の maintainer 権限は同じではない
この件で重要なのは、fsnotify には過去にかなり緩く commit 権限を与えていた時期があったらしい、という点だ。
Issue #126 では、当時の maintainer が「最初の PR 後に commit access を与える」ようなかなり liberal な方針について話している。
つまり、過去に commit bit を持っていたからといって、それが現在の production-critical な OSS における release 権限や main への直接 push 権限を持つべきだ、という話にはならない。
昔の小規模 OSS では、PR を投げてくれた人に commit 権限を渡すような文化はあった。善意ベースではある。しかし、今となってはそのまま残しておくのはかなり危うい。
特に fsnotify のように広く使われるライブラリでは、「昔 PR を出したことがある人」がそのまま release できる状態になっているほうが、むしろ supply chain 的には怖い。
だから、arp242 氏が権限を整理したこと自体は、それほど不自然ではない。むしろ、実質 maintainer としてはやるべき整理だった可能性がある。
■ FUNDING.yml の変更は軽く見てはいけない
今回、個人的に一番引っかかるのは、mattn 氏が .github/FUNDING.yml を変更して、自分を GitHub Sponsors に追加している点だ。
commit はこれ。
- github: arp242 + github: [arp242, mattn]これは単なるバグ修正ではない。資金導線の変更である。
OSS において funding の設定を変えることは、コードの typo 修正や CI 修正とは意味が違う。既存 maintainer との明示的な合意なしに、自分を sponsor 対象に追加するのは、かなり強い行動だと思う。
しかも、arp242 氏の説明によると、mattn 氏は thanks.dev から過去に funds を引き出していたが、fsnotify で実質的な作業をする前だった、という文脈もあるらしい。
この説明が事実なら、arp242 氏が不信感を持つのはかなり自然ではないか。
少なくとも、「mattn 氏が善意で助けようとしただけなのに、arp242 氏が急に怒って追い出した」という単純な話ではない。
■ mattn 氏の行動にも疑問がある
mattn 氏は日本の Go 界隈では非常に有名な人で、技術的な実績も大きい。それは否定しない。
ただ、今回の個別の行動が妥当だったかは別問題だ。
疑問点は複数ある。
- fsnotify の issue 上で十分に確認する前に、X で強い印象を与える形で発信したように見えること
- FUNDING.yml に自分を追加したこと
- メンテナ権限を外されたあと、似たような API の gofsnotify/fsnotify を立ち上げたこと
もちろん fork や別実装を作る自由はある。OSS なので、それ自体は問題ではない。
しかし、今回の流れでそれをやると、「元プロジェクトの信頼性に疑問があるから、こちらに移行しよう」という空気を作りやすい。実際、日本語圏ではそういう反応も見かける。
これはかなり危ういと思う。
■ AI rewrite 的な振る舞いは軽く見られすぎている
gofsnotify が実際にどういう意図で作られたのかは、外からは断定できない。
ただ、既存プロジェクトと似た API の代替実装を、権限トラブルの直後に短期間で立ち上げることには、少なくとも行儀の悪さがあると思う。
最近は、既存 OSS のコードを AI に rewrite させれば、ライセンス上の制約や由来の問題を回避できる、というような雑な発想も批判されている。AI を通したからといって、設計・API・挙動・テスト・不具合修正の蓄積までクリーンになるわけではない。
gofsnotify がライセンス逃れ目的だと言いたいわけではない。そこは断定できない。
ただ、元プロジェクトへの不信が広がっているタイミングで、似た API の代替実装を AI 利用込みで出し、それを周囲が「移行先」として扱うのは、かなり慎重であるべきだと思う。
少なくとも、「AI で作ったから問題ない」「別実装だから問題ない」「有名人が作ったから信用できる」といった雑な受け止め方は危うい。
■ 日本語圏の反応がかなり危うい
今回一番気になったのは、日本語圏での反応だ。
- mattn 氏が言っているから正しい
- 海外 maintainer が横暴
- arp242 氏は怖い
- じゃあ gofsnotify に移行しよう
みたいな流れが、かなり安易に見える。
有名人の発言は強い。特に日本語圏では、海外 OSS の issue をちゃんと読まずに、日本語の X の空気だけで判断する人も多い。
しかし OSS の maintainer 権限、release 権限、funding、supply chain は、感情で判断するものではない。
mattn 氏のこれまでの実績と、今回の行動の妥当性は分けて考えるべきだ。
同じように、arp242 氏の言い方がきついことと、権限整理の妥当性も分けて考えるべきだ。
■ arp242 氏にも落ち度はある
もちろん、arp242 氏が完璧だったとは思わない。
権限を外すなら、事前または直後に issue を立てて説明したほうがよかった。
たとえば、
- 過去の緩い commit access を整理する
- 実質 maintainer と release 権限を明確化する
- funding の変更には事前合意を必要とする
- main への直接 push を制限する
- 過去 contributor は collaborator ではなく contributor として扱う
といった governance note を出しておけば、ここまで燃えなかったかもしれない。
その意味で、arp242 氏の手続きは雑だったと思う。
ただし、それは「arp242 氏が悪意を持って乗っ取った」という話とはまったく違う。
説明不足だったことと、権限整理の理由がなかったことは別である。
■ まとめ
自分の見方はこうだ。
- arp242 氏は説明の出し方が悪かった
- しかし、fsnotify を実質的に長くメンテしてきたのは arp242 氏側に見える
- 過去の緩い commit 権限を整理すること自体は不自然ではない
- FUNDING.yml に自分を追加する行動はかなり重い
- mattn 氏の X での発信は、結果として arp242 氏への過剰な攻撃を招いたように見える
- その後に似た API の gofsnotify を短期間で出し、周囲が移行先として扱う流れもかなり危うい
だから、今回の件を「arp242 氏が横暴だった」で片付けるのはかなり無理があると思う。
むしろ、日本語圏の反応こそ反省したほうがいい。
OSS の信頼性は、有名人が怒っているかどうかではなく、実際の履歴、権限、資金導線、review、release policy、長期保守の実績で判断するべきだ。
少なくとも、fsnotify から gofsnotify に移行しよう、みたいな話を軽くする段階ではない。