/note/tech

Open question for the reason why other maintainers were removed from the org(fsnotify Issue #757)

要約:

■ 1. 概要

  • GitHubリポジトリfsnotifyのIssue #757における、メンテナー権限の剥奪をめぐる議論の整理
  • 発端はymotongpooによる「他のメンテナーがorgから外された理由の説明を求める」問題提起
  • 議論はarp242・mattn双方の主張の対立を軸に展開し、複数の匿名コメントによる事実確認を含む

■ 2. 登場人物

  • ymotongpoo: Google社員、Issue開設者、説明を求める立場
  • arp242 (Martin Tournoij): fsnotifyの実質メンテナー(178コミット)、権限整理を実施した当事者
  • mattn: 日本のGoエンジニア(15コミット)、権限を剥奪された当事者
  • umlx5h: 第三者として事実確認を行う

■ 3. 権限整理の経緯(arp242の主張)

  • 権限整理の背景:
    • 権限を持つ関係者の多くは「昔PRを出したら全員にcommit権限を渡す」という過去の慣行(Issue #126)に基づくものであり実質的なメンテナーではなかった
    • 外されたのはコミット数が19・8・5・1の貢献者たちであり、Kubernetesが依存するライブラリでコミット数の少ないユーザーがrelease権限を持つことの危険性が指摘された
  • PR品質の問題:
    • mattn・shogoのPRはレビューなしで数分以内にrubber-stamp approveされてマージされた
    • 変更の品質が低く(「AI slop」と表現)修正作業に前日の午前中をほぼすべて費やした
    • fsnotifyは全プラットフォームで一貫した動作が求められる難しいプロジェクトでありgo testを走らせるだけでは正しさを確認できない
  • FUNDING.ymlの問題:
    • mattnが5コミットのみの状態で自身をFUNDING.ymlに追加した
    • mattnはthanks.devから実質的な作業を行う前に過去複数回資金を引き出していた背景がある

■ 4. Twitterで拡散した誤情報への反論(arp242)

  • 「以前fsnotifyが維持不能になりメンテナーを募集した」という主張はrepositoryがarchiveされていた事実の誤認であり自分がNathanにメールして引き継いだ
  • 「original authorまで外した」という主張に対し、Nathanは自らorgを離れており「安心してfsnotifyから離れられる」というメールを受け取っている
  • コミットログは隠すものではなくgit logの出力(178コミット等)を公開した

■ 5. mattnの反論と説明

  • 誤認の謝罪:
    • howeyc/nathanyが今回外されたと誤認していた点を謝罪
  • 活動実績の説明:
    • Issue #735(「1年以上releaseがなくautomated dependency scannerに『unmaintained』と判定される」)を受け、半年間動きのなかったrepoを確認を待たずに整備した
    • 2026年4月21日〜5月4日の間に11本のPR(バグ修正・テスト安定化・toolchain更新など)をマージしv1.10.0とv1.10.1をリリースした
  • FUNDING.ymlについて:
    • メンテナーとしての認識の下でコミットした
    • 事前確認なしにmainに直接コミットしたのは判断ミスだったと認める
  • thanks.devについて:
    • 2023年頃にfsnotifyのメンテナーとして登録されていた
    • 現在はorgメンバーでなくなったためダッシュボードからfsnotifyが消えており詳細を確認できないが一定の金額を受け取っていた可能性は否定しない
    • 調査の上判明すれば公開すると述べる
  • PR #756の評価について:
    • 「AI slopのrollback」という評価は実際のdiffと一致しない
    • バグ修正(#736等)はmainに残っており#756で戻されたのはリネームや再構成が中心
    • Windowsのドキュメントについては、MicrosoftおよびJim Beveridgeの文書を根拠に記述したもの
  • gofsnotify/fsnotifyについて:
    • orgへのアクセスを失った後に作成した独立実装(forkではない)
    • 既存の代替として提示したものではない

■ 6. 主要な争点

  • 権限整理の正当性:
    • arp242: 過去の慣行による残存権限を整理したに過ぎない
    • mattn: 1年間inactive後に活発に貢献した実績があった
  • FUNDING.ymlの変更の適切性:
    • arp242: 実質作業前に資金を受け取っていた前歴があり不信感を持つのは自然
    • mattn: メンテナーとしての認識でコミットし事前確認しなかったのは判断ミスと認める
  • Twitterでの情報発信の適切性:
    • arp242: issueではなくTwitterで批判するのは不適切
    • mattn: 一方的な状況になっているのを見て書かざるを得なかった、誤りは謝罪
  • PR品質の評価:
    • arp242: AI生成を含む低品質で修正に相当な時間を要した
    • mattn: バグ修正の実績は具体的に示した、ドキュメントにも根拠がある

■ 7. 未解決事項

  • arp242からmattnのコメントへの直接返答がない
  • Issue自体はOpenのまま
  • thanks.devの具体的な金額の開示がなされていない
  • 権限整理の事前通知がなかった点についてarp242からの謝罪・説明がない
  • fsnotifyの今後のガバナンス(単独メンテナー問題)への具体的な回答もない

論評:

■ 1. arp242の評価

  • 正当性が高い点:
    • Issue #757での説明はcommit log公開・Nathanからの引き継ぎ経緯・thanks.devでの資金引き出し時系列など一次情報に基づく具体的かつ検証可能な根拠を伴っている
    • FUNDING.ymlの問題はmattn自身が「判断ミスだった」と認めており不信感は事後的に正当化された
    • Issue #126に基づく権限整理の説明はsupply chain securityの観点から筋が通っている
  • 批判が残る点:
    • 権限剥奪を無言で行ったことが致命的な落ち度である
    • mattnが2週間で11本のPRをマージし2回のreleaseを切るという活発な貢献をしていた人物をissueひとつ立てることなく突然外したことはコミュニティの信頼という観点で拙かった
    • 「説明しなかったのは余計な炎上を避けたかったから」という釈明は結果として逆効果であったことを自ら認めている
    • Twitterで火がついてから初めてissueで説明するという順序はgovernanceとして最悪のパターンである
    • PR #756において技術的なバグ修正PRのスコープに実質的な権限整理が紐付いていた点は変更の透明性という観点で擁護しにくい
    • 「AI slop」という表現は感情的すぎる
    • 品質問題と権限剥奪を直接結びつけるならPRのレビューで具体的に指摘するのが先であり後から「低品質だった」と説明するのは後付けの印象が拭えない
  • 総合評価:
    • 「何をしたか」は概ね正当化できるが「どうやったか」と「何を言ったか」に問題が集中している
    • 長年の貢献者としての正当性とコミュニティ運営者としての成熟度の間に大きな乖離がある

■ 2. mattnの評価

  • 正当性が高い点:
    • Issue #735(1年以上releaseがなくdependency scannerにunmaintainedと判定される)という具体的なユーザーの声を受けて動いた動機は利用者目線のものとして理解できる
    • 11本のPR・2回のreleaseという活動量はissueで丁寧に説明されており単純な批判と噛み合っていない部分がある
    • Xでの誤情報(howeyc/nathanyが外されたという誤認)を率直に謝罪し自分のポストを削除した
    • arp242へのdownvoteをしないよう呼びかけ議論を建設的に収めようとする意志を示した
  • 批判が残る点:
    • FUNDING.ymlの変更が最大の問題であり mattn自身が「判断ミスだった」と認めているがこれを「認めた」で済ませるのは軽すぎる
    • fsnotifyはKubernetesが依存するpublicなOSSであり既存のmaintainerであるarp242の明示的な合意を取らずに直接mainにpushしたことは手続きとして誤りである
    • 「メンテナーとして活動していた認識だったから」という説明は自分でその認識を設定して自分でその認識を根拠にした循環論法に近い
    • thanks.devの問題は深刻であり「作業をする前に資金を引き出していた可能性がある」ことを実質的に認めたがissue上でその後の開示はない
    • issueでの確認よりも先にXで動いたことが不必要な炎上を招いた
    • shogoが数分でrubber-stamp approveしてマージしたという事実があり レビュープロセスが形骸化していたことは否定できない
  • 総合評価:
    • 「何をしようとしたか」は理解できるが「どういう順序でやったか」と「資金面の透明性」に問題が残る
    • thanks.devの件はissueでの謝罪後も追跡調査・公開がなされていないとすれば誠実さの評価を大きく下げる要因になる

■ 3. 両者の比較

  • 技術的貢献の正当性:
    • arp242: 高い
    • mattn: 議論あり(短期・品質問題)
  • 権限整理の根拠:
    • arp242: 筋が通る
    • mattn: 該当なし
  • 手続きの適切さ:
    • arp242: 問題あり(無言で実行)
    • mattn: 問題あり(合意なしでFUNDING変更)
  • 情報発信の適切さ:
    • arp242: 遅すぎた
    • mattn: 不正確かつ順序が逆
  • 事後の説明:
    • arp242: 具体的・検証可能
    • mattn: 誠実だが資金面に不透明さが残る
  • コミュニティへの影響:
    • arp242: 単独メンテナー問題を放置
    • mattn: 誤情報拡散・不必要な炎上

■ 4. 構造的な問題

  • 両者の個別の行動を超えてこの件が示しているのはOSSガバナンスの設計不全である
  • arp242が「権限整理は当然だ」と言えてしまうほどfsnotifyには明文化されたガバナンスルールが存在しなかった
  • 誰がmaintainerでどういう条件でFUNDINGを変更できどういう手続きで権限を外すかが定義されていなければ今回のような衝突は構造的に起きうる
  • 両者の行動を裁くより「こういう事態を防ぐにはどんなガバナンスが必要か」を問う方がOSSコミュニティにとって生産的な問いである

MEMO: