/note/tech

過剰で厳格なCode of Conduct(行動規範)が多くのオープンソース・プロジェクトに不要な理由

要約:

■ 1. CoCの起源と初期の成功

  • Debianの停滞問題: 2000年代初頭、Debianは開発者の自律性を最大限尊重する文化を持ち、中央集権的な意思決定機関が存在しなかったため、プロジェクト全体のリリースが停滞していた
  • Debian 3.1(sarge)の遅延: 前バージョン(woody)が2002年7月リリースだったのに対し、sargeは2005年6月リリースで実に3年近い歳月を要し、フレームウォーによる疲弊と意思決定プロセスの麻痺を象徴していた
  • Ubuntuの登場: 2004年にMark Shuttleworthが立ち上げたUbuntuは、6ヶ月ごとのリリースサイクルに加え、コミュニティの健全な運営を担保するためのCoCを最初期から導入した
  • Benjamin Mako Hillの貢献: UbuntuのCoC起草に中心的役割を果たし、他のプロジェクト(Debian)で経験した「刺々しいやり取り」への反省から意図的に明文化された
  • 初期の効果: 技術的な生産性を最大化するために健全なプロジェクトの協働を維持するという現実に即した目的から生まれ、「Ubuntuの方が動きやすい」という空気が醸成された

■ 2. カンファレンスへの拡大と目的の変化

  • Ada Initiativeの活動: 2011年から2015年にかけて活動した非営利団体で、技術カンファレンスにおけるハラスメントが深刻な問題であると指摘し、アンチハラスメント・ポリシーのテンプレートを公開・推進した
  • 目的の転換: CoCの目的が「協働の生産性向上」から「参加者の安全確保」を含むものへと大きく舵を切った
  • Donglegate事件(2013年): PyCon参加者の女性が近くの席の男性の「ドングル」発言を性的冗談と受け止めTwitterに投稿し、冗談を言った男性の一人と告発した女性自身の両方が職を失うという結末を迎えた
  • 事件の教訓: コミュニティ内の対立が当事者のキャリアに深刻な実害を及ぼしうること、非公式な規範だけではこのような事態を収拾できないことを露呈した
  • PyConの対応: 「公の場での名指しの批判は、強力なコミュニティを構築する上で逆効果になり得る」との文言をポリシーに追加

■ 3. Contributor Covenantによる標準化

  • 2014年の登場: Coraline Ada Ehmkeによって作成され、特定のプロジェクトやイベントに限定されない汎用的なCoCのテンプレートとして設計された
  • 詳細な内容: 年齢、性自認、民族、経験レベルなど保護されるべき属性を明示的に列挙し、「歓迎されインクルーシブな言葉遣い」を推奨する一方で「個人攻撃や政治的攻撃」「公的または私的なハラスメント」を許容されない行動として定義
  • 執行ガイドライン: 違反が報告された場合の調査や是正措置に関する詳細な執行ガイドラインまで含み、単なる理念の表明に留まらない法的文書に近い枠組みとなった
  • 急速な普及: 網羅性と導入の容易さから瞬く間に普及し、数万ものプロジェクトで採用された
  • Linuxカーネルの採用(2018年): Linus Torvaldsが過去の攻撃的な言動を謝罪し、従来のCode of Conflictを廃止してContributor Covenantを採用したことで象徴的転換点を迎えた
  • 目的の変遷: 「協働の生産性向上のツール」→「安全確保の仕組み」→「倫理規範の標準フレームワーク」へと変貌を遂げた

■ 4. Rustモデレーションチーム総辞職事件(2021年11月)

  • 総辞職の理由: モデレーションチームが全員辞任し、「コアチームが自分たち以外の誰に対しても説明責任を負わない立場に身を置いているため」とされた
  • ガバナンス構造の欠陥: CoCの執行を担当するモデレーションチームのメンバーがプロジェクトの最高意思決定機関であるコアチームによって任命されていた
  • 従属関係の問題: CoCを執行する組織が、CoCによって裁かれる可能性のある組織に従属していたため、独立かつ公平な調査や裁定が事実上不可能だった
  • 教訓: どれほど立派なCoCを掲げても、プロジェクトの最高権力者に対しても公平に適用できる独立したガバナンス構造がなければ、CoCが空文化し摩擦だけが残る
  • CoCの無力さの証明: CoCが権力に対するチェック機能として失敗した典型例

■ 5. RubyGems事件(現在進行中)

  • 権力掌握の疑惑: Rubyコミュニティのインフラを運営する非営利団体Ruby Centralが、主要なスポンサーからの圧力を受け、長年無償で貢献してきたメンテナーの同意なしにRubyGemsとBundlerのGitHub Organizationの管理権を掌握したと追求されている
  • 公式の理由: 「サプライチェーンセキュリティの保護とガバナンスの強化」という正当な理由を掲げている
  • メンテナーの主張: 追放されたメンテナーは「スポンサー企業の意向を背景とした中央集権化とコミュニティの乗っ取り」と主張し、「敵対的買収」と呼んでいる
  • ガバナンスの武器化: CoCの執行やセキュリティ確保といったガバナンス強化の名目が、コミュニティを保護するのではなく、むしろコミュニティから権限を奪い企業や一部の権力者の利益のために利用され得る
  • CoCガバナンスのパラドックス: 指導部の暴走を抑えるほどに強力なCoCは、指導部(あるいは外部勢力)によって乗っ取られコミュニティを支配するための道具としても使われるほどに強力である

■ 6. Eric S. Raymond(ESR)の批判

  • 三つの助言:
    • (1) CoCを持つことを拒否せよ。既にあるなら削除せよ
    • (2) 官僚的な理由で必要なら「あなたの貢献が正当化できる範囲を超えて一緒に働くのが面倒になった場合、あなたは追放される」の一文で置き換えよ
    • (3) これ以上具体的にしようとする試みは機能しない。厄介者が操作するための制御面を提供するだけだ
  • 純粋な能力主義: 唯一の評価尺度は、貢献者がもたらす技術的な価値と彼らが引き起こす社会的な摩擦との差引勘定である
  • リーダーへの信頼: プロジェクトのリーダーに対して最終的な判断を下すという絶対的な信頼を委ねるモデル

■ 7. David Heinemeier Hansson(DHH)の批判とRuby CoCの評価

  • Contributor Covenantへの批判: 「トロイの木馬」と断じ、プロジェクトから排除すべきだと主張
  • Ruby CoCの賞賛: 「MatzがRubyのために導入した美しい代替案」を賞賛している
  • Ruby CoCの四つの基本原則:
    • 反対意見に対して寛容であること
    • 個人の攻撃や中傷的な発言をしないこと
    • 他者の言動を解釈する際は、常に善意を前提とすること
    • ハラスメントと合理的に見なされる行為は容認されないこと
  • シンプルさの効果: 保護されるべき属性のリスト、段階的な執行プロセスの詳細、法的な専門用語等が一切なく、法律の条文ではなく原則の表明である
  • 信頼に基づく: 参加者が善意を持った大人であることを信頼し、明確な不正行為(ハラスメントや個人攻撃)にのみ介入する

■ 8. Contributor Covenantの脆弱性

  • 武器化のリスク: 政治的な目的で武器化されたり、法廷闘争のように扱われたりする可能性がある
  • 曖昧な用語: 「政治的攻撃」のような曖昧な用語は大きな解釈の余地を生み、脆弱性を生む
  • 官僚的負担: 公式な委員会、調査プロセス、詳細な記録保持を前提とした執行はコミュニティへ望まぬ負担をかける
  • 技術的議論の萎縮: 参加者に対する低い信頼を前提として設計されており、時には辛辣でさえある活発な技術的議論を萎縮させる危険性をはらむ

■ 9. Ruby CoCの優位性

  • MINASWAN精神: 「Matz is nice and so we are nice.(Matzは優しい、だから私たちも優しくあろう)」という精神がコミュニティに浸透している
  • 運用の容易さ: 細かい条項や政治的理念を明文化しなくとも、運用が容易でありながら他者を尊重する文化の形成には参加者が共有できる理念を掲げるだけで十分
  • コミュニティへの信頼: 何が違反にあたるかの判断はコミュニティの合意に大きく依存し、官僚的なプロセスなしで既存のプロジェクトリーダーシップに依存する
  • バランスの良さ: 短くて分かりやすく、原則に基づいており、ハラスメントや個人攻撃といった明白な不正行為の禁止に焦点を当てつつ、技術的な意見の対立についてはコミュニティの自浄作用を信頼する

■ 10. 提言:身の丈に合ったCoCへ

  • フリーサイズの限界: 全サイズ共通のテンプレートを思考停止で導入することではなく、個々のプロジェクトの規模、文化、目的に合わせた「身の丈サイズ」のアプローチが必要
  • Linuxの真似は不要: Linuxカーネルのような世界中の開発者と大企業が参加する巨大プロジェクトの真似をしても仕方がない
  • 短いCoCの優位性: 大多数のオープンソース・プロジェクトにとって、ほんの数行で収まる程度のCoCは単に十分であるだけでなく、むしろ優れている
  • 長さと過去の関係: 長くなればなるほど、そのコミュニティにとってそれが必要なことが起きた過去があるからである
  • 盾であって武器ではない: CoCはソフトウェアを構築するというコミュニティの中核機能を守るためのシンプルな「盾」であるべきであり、コミュニティ自身に向けられかねない複雑な「武器」であってはならない