オープンソースのプロジェクトで採用されているCoC (Code of Conduct, 行動規範)を巡る議論が、一つの転換点を迎えているかもしれない。2025年9月、Rubyのエコシステムを支えるRubyGemsのガバナンスを巡る騒動が勃発し、コミュニティに大きな波紋を広げている最中であるが、これと直接的には関係がないもののこの混乱をきっかけにRuby on Railsの作者であるDavid Heinemeier Hansson(DHH)とオープンソースの元伝道師であるEric S. Raymond(ESR)という二人の有名人が、現代的なCoC、特に「Contributor Covenant」に対して痛烈な批判をX上で展開するという出来事があった。
DHHは、Contributor Covenantのような詳細かつ厳格なCoCを「トロイの木馬」と断じ、プロジェクトから排除すべきだと主張し、一方のESRはさらに踏み込み、CoCはコミュニティを掻き乱す「厄介者のための道具」に過ぎず、プロジェクトから完全に削除することが最善であると主張している。この二人は界隈で物議を醸すタイプの人物と見られることが多いが、この件に関しては自分の考え方もかなり近いところにある。
そもそもコラボレーションを促進し、コミュニティを健全に保つためのツールと見なされていたCoCが、何故これほどまでに激しい論争の的となったのか。本稿では、オープンソースのプロジェクトがCoCと出会った黎明期から、その普及と変質、そして現代における弊害までを歴史的に紐解き、なぜ過剰なCoCが多くのオープンソースプロジェクトにとって不要であるのかを論じる。結論として、CoCの原点に立ち返り、個々のプロジェクトの規模や文化に合わせた、身の丈に合った規範こそが、持続可能な開発コミュニティの礎となることを示す。
English version: https://shujisado.org/2025/09/30/why-heavy-codes-of-conduct-are-unnecessary-for-most-open-source-projects/
オープンソースプロジェクトがCoCの効力に出会った時
CoCは、ある日突然、思想的な目的のために外部から持ち込まれたものではない。それは、オープンソース・コミュニティが内包する現実的な問題、すなわち、技術的な対立がいつの間にか個人的な攻撃に発展し、プロジェクト全体の生産性が著しく損なわれるという課題への、実践的な解決策として生まれたのである。
Debianの停滞とUbuntuの躍進：CoC黎明期の原体験
CoCの有効性が初めて大規模に実証された事例は、2000年代初頭のDebianプロジェクトの状況に遡る。当時のDebianは、開発者の自律性を最大限に尊重する文化を持ち、中央集権的な強い意思決定機関が存在しなかった。その結果、各パッケージのメンテナーや各機能の担当者が自身の技術的信念を貫くあまり、プロジェクト全体のリリースが停滞するという事態が頻発していた。
この構造的な問題が最も顕著に現れたのが、2005年6月にリリースされたDebian 3.1、コードネーム「sarge」を巡る長い騒動である。その前のバージョンである「woody」がリリースされたのは2002年7月であり、sargeのリリースには実に3年近い歳月が費やされたわけだが、この長期にわたる遅延はDebianコミュニティ内の絶え間ないフレームウォーによる疲弊と、意思決定プロセスの麻痺を象徴していた。
このDebianの停滞と混乱に対する直接的な回答として登場したのが、2004年にMark Shuttleworthが立ち上げたUbuntuだった。Ubuntuは、「六ヶ月ごとのリリースサイクル」という技術的な約束事に加え、コミュニティの健全な運営を担保するためのCoCを最初期から導入した。このCoCの起草にはDebianプロジェクトにも深く関与していたBenjamin Mako Hillが中心的な役割を果たしているが、彼自身の言葉によれば、UbuntuのCoCは他のプロジェクト(当然、Debianであろう)で経験した「刺々しいやり取り」への反省から意図的に明文化されたものであった。つまり、UbuntuのCoCは、技術的な生産性を最大化するために、健全なプロジェクトの協働を維持するという現実に即した目的から生まれたのである。この結果として「Ubuntuの方が動きやすい」という空気が醸成され、多くの開発者がDebianからUbuntuへと活動の場を移すことになった。
カンファレンスからプロジェクトへ：規範の一般化
Ubuntuが示したCoCの有効性は幾つかのプロジェクトへ波及していたが、2010年代に入ると、その議論の舞台はオンラインの開発のメーリングリストから、オフラインの技術カンファレンスへと波及し、そこから一気に拡大していく。ここでCoCの目的は、全体の「協働の生産性向上」から「参加者の安全確保」を含むものへと大きく舵を切ることになったと言えるだろう。
この転換の引き金となったのは、2011年から2015年にかけて活動した非営利団体「Ada Initiative」である。Ada Initiativeは、技術カンファレンスにおけるハラスメントが深刻な問題であると指摘し、具体的な対策としてアンチハラスメント・ポリシーのテンプレートを公開し、その導入を強力に推進した。それまで一部のコミュニティを除いてほとんど存在しなかったカンファレンスの行動規範は、Ada Initiativeの活動によって業界の標準的な慣行として急速に広まっていった。
そして2013年、Pythonの年次カンファレンスであるPyConで発生した「Donglegate」事件が、CoCの必要性を決定的に可視化させることになった。これは参加者であった女性が、近くの席にいた男性たちの「ドングル」という発言を性的な冗談と受け止め不快に感じ、彼らの写真をTwitterに投稿したことが発端であった。この一件は、冗談を言った男性の一人と告発した女性自身の両方が職を失うという結末を迎えたのだが、コミュニティ内の対立が当事者のキャリアに深刻な実害を及ぼしうること、そして非公式な規範だけではこのような事態を収拾できないことを白日の下に晒した。事件後、PyConは「公の場での名指しの批判は、強力なコミュニティを構築する上で逆効果になり得る」との文言をポリシーに追加し、CoCとその運用手順の重要性が広く認識されるようになった。
Contributor Covenantによる標準化と主流化
Ubuntuが示した「協働の生産性向上のためのCoC」とAda Initiativeが推進した「安全のためのCoC」という二つの潮流が合流し、一つの完成形として登場したのが2014年にCoraline Ada Ehmkeによって作成された「Contributor Covenant」であるのだろう。Contributor Covenantは、特定のプロジェクトやイベントに限定されない汎用的なCoCのテンプレートとして設計され、その内容は、年齢、性自認、民族、経験レベルなど、保護されるべき属性を明示的に列挙し、「歓迎されインクルーシブな言葉遣い」を推奨する一方で「個人攻撃や政治的攻撃」「公的または私的なハラスメント」などを許容されない行動として具体的に定義している。さらに、違反が報告された場合の調査や是正措置に関する詳細な執行ガイドラインまで含んでおり、単なる理念の表明に留まらない法的文書に近い枠組みとなっている。
この網羅性と導入の容易さからContributor Covenantは瞬く間に普及し、多くのIT企業や主要なオープンソース・プロジェクトを含む数万ものプロジェクトで採用されるに至っている。2018年、Linus Torvalds自身が過去の攻撃的な言動を謝罪するとともに、Linuxカーネルが従来のCode of Conflictを廃止してContributor Covenantを採用したことで、この重量級の標準化されたCoCがオープンソース界隈にて象徴的転換点を経て現在に至っている。
CoCの歴史を振り返ると、その目的が段階的に変化してきたことが分かるだろう。当初はDebianの機能不全を解決するための「協働の生産性向上のツール」であった。次に、カンファレンスでの事件を契機に参加者を守るための「安全確保の仕組み」を含むものへと進化した。そして最終的に、Contributor Covenantによって、コミュニティのあるべき姿を定義し、それを強制するための法的な拘束力も強まった「倫理規範の標準フレームワーク」へと変貌を遂げた。ESRやDHHが批判の矛先を向けているのは、2004年当時の現実に即したツールではなく、2014年以降に主流となったこの倫理的・法的な性格を強く帯びたCoCなのである。
厳格なCoCの弊害と反発の動き
善意から生まれたはずの厳格なCoCであるが、その普及とともにオープンソースのガバナンスに新たな、そしてより深刻な問題をもたらし始めた。CoCが、時にコミュニティを守る盾ではなく、内部の権力闘争を助長し、貢献者を疲弊させる武器へと姿を変えることも分かってきたのである。特に詳細な条文と厳格な執行プロセスを持つCoCは、理論上は公平なコミュニティ運営を保証するように見える。しかし、現実には、前述のLinuxカーネルでのContributor Covenantの導入は賛否を呼び、多くのプロジェクトで政治的な対立を招いたわけでもあり、重厚なCoCにおける複雑さがガバナンスの構造的欠陥を露呈させたり、悪意ある第三者によって悪用されたりする脆弱性を生み出している。
Rustモデレーションチーム総辞職事件
中でも最も象徴的な事例は、2021年11月に起きたプログラミング言語Rustのモデレーションチームが全員辞任するという衝撃的な事件であろうか。彼らが発表した声明では、辞任の理由は「コアチームが自分たち以外の誰に対しても説明責任を負わない立場に身を置いているため」とされ、その結果として「コミュニティが期待する水準でRustのCoCを執行することができなくなった」というものであったのである。
問題の核心はガバナンスの構造にあった。Rustプロジェクトでは、CoCの執行を担当するモデレーションチームのメンバーがプロジェクトの最高意思決定機関であるコアチームによって任命されていた。つまり、CoCを執行する組織が、CoCによって裁かれる可能性のある組織に従属していたのである。この構造では、コアチームのメンバーが関与する違反疑惑に対して、独立かつ公平な調査や裁定を下すことは事実上不可能である。この事件は、どれほど立派なCoCを掲げたとしても、それをプロジェクトの最高権力者に対しても公平に適用できる独立したガバナンス構造がなければ、CoCが空文化し、摩擦だけが残るという厳然たる事実を示しており、CoCが権力に対するチェック機能として失敗した典型例と言えるだろう。
RubyGems事件からの示唆
Rustの事例がCoCの「無力さ」を示したとすれば、今回の論争のきっかけでもある現在進行中であるRubyGemsの事例は、CoCを含むガバナンスの言説がいかにして「権力掌握の道具」として悪用されうるかを示している可能性があるだろう。
この事件では、Rubyコミュニティのインフラを運営する非営利団体Ruby Centralが、主要なスポンサーからの圧力を受け、長年に渡り無償で貢献してきたメンテナーらの同意なしにRubyGemsとBundlerのGitHub Organizationの管理権を掌握したと追求されている。Ruby Centralが公式に掲げた理由は「サプライチェーンセキュリティの保護とガバナンスの強化」という誰もが反対しにくい正当なものであり、これは一定の説得力を持つものであるが、追放されたメンテナーらはこの動きの実態を「スポンサー企業の意向を背景とした中央集権化とコミュニティの乗っ取りであった」と主張し、「敵対的買収」と呼んでいる。この事案に対して自分のような外部の者がどちらか一方が悪いと決定的な論調で書くほどの材料は今のところは揃っていないと判断しているが、仮にメンテナーらの証言側に立てば、CoCの執行やセキュリティ確保といったガバナンス強化の名目がコミュニティを保護するのではなく、むしろコミュニティから権限を奪い、企業や一部の権力者の利益のために利用され得るというより悪質な失敗のパターンが存在することを露呈させているだろう。
RustとRubyGemsの事例が示すのは、CoCガバナンスのパラドックスであるのだろう。すなわち、指導部の暴走を抑えるほどに強力なCoCは指導部(あるいは外部勢力)によって乗っ取られ、コミュニティを支配するための道具としても使われるほどに強力でもあるということだ。コミュニティを守るために設計された仕組みそのものが、コミュニティの権利を奪うための手段となり得るのである。厳格かつ強力なCoCは必然的に複雑な執行機関を必要とする。この執行機関はプロジェクト内に新たな権力の中枢を生み出し、その権力は政治的力学や乗っ取りのリスクに晒される。結果として、CoCを複雑化させることが、意図せずしてプロジェクトの政治的な「攻撃対象領域」を拡大させてしまうのである。RubyGems事件はCoC自体ではなくガバナンスだが、規範や統治の重さがコミュニティの分断や企業政治と結び付く危険性を示唆しているとも言えるだろう。
ESRの功利主義とRuby CoCの寛容性
このようなCoCの機能不全の状況に対し、ESRとDHHは現代のCoCパラダイムに対する根本的な批判を展開したのである。両者のアプローチは異なるものの複雑で官僚的なCoCがオープンソースの本質を損なうという点で共通している。
ESRの主張(https://x.com/esrtweet/status/1971768345188844003) は明快であるが、やや過激である。彼の助言は三点であり、(1) CoCを持つことを拒否せよ。もし既にあるなら削除せよ。(2) 官僚的な理由でどうしても必要なら次の一文で置き換えよ。「あなたの貢献が正当化できる範囲を超えて一緒に働くのが面倒になった場合、あなたは追放される」。(3) これ以上具体的にしようとする試みは機能しない。それは厄介者が操作するための制御面を提供するだけだ、ということである。この主張は純粋な能力主義と結果主義に基づいている。唯一の評価尺度は、貢献者がもたらす技術的な価値と彼らが引き起こす社会的な摩擦との差引勘定である。つまり、これはプロジェクトのリーダーに対して最終的な判断を下すという絶対的な信頼を委ねるモデルと言える。
DHHの批判(https://x.com/dhh/status/1971454220726566998) は一見はESRの主張と同様に強い意見に見えるが、よりバランスが取れた主張である。彼はContributor Covenantを「トロイの木馬」と呼び、その代替として「MatzがRubyのために導入した美しい代替案」を賞賛しているのである。DHHが「美しい」と評するRubyの公式CoCは非常にシンプルであり、以下の四つの基本原則から構成されている。
- 反対意見に対して寛容であること。
- 個人の攻撃や中傷的な発言をしないこと。
- 他者の言動を解釈する際は、常に善意を前提とすること。
- ハラスメントと合理的に見なされる行為は容認されないこと。
このRubyのCoCが効果的である理由は、その記述内容もさることながら、むしろ「何が書かれていないか」にあるだろう。ここには保護されるべき属性の長いリスト、段階的な執行プロセスの詳細な規定、法的な専門用語等といった類のものは一切ない。つまり、Ruby CoCは法律の条文ではなく、原則の表明なのである。このRuby CoCのアプローチは、参加者が善意を持った大人であることを信頼し、明確な不正行為(ハラスメントや個人攻撃)にのみ介入するというコミュニティに対する高い信頼に基づいている。
Contributor Covenantのような厳格なCoCは、政治的な目的で「武器化」されたり、法廷闘争のように扱われたりする可能性がある。例えば「政治的攻撃」のような曖昧な用語は大きな解釈の余地を生み、そこが脆弱性を生むことになる。また、公式な委員会、調査プロセス、詳細な記録保持を前提とした執行はコミュニティへ望まぬ負担をかけるだろう。これに対し、Ruby CoCは、何が違反にあたるかの判断はコミュニティの合意に大きく依存し、官僚的なプロセスなしで既存のプロジェクトリーダーシップに依存することになる。
Rubyの日本国外のコミュニティではMINASWAN(Matz is nice and so we are nice.：Matzは優しい、だから私たちも優しくあろう)という精神が掲げられることがあるが、これは開発者とコミュニティの相互の幸福のために加者同士が思いやりと尊厳を持って接することを求めているのだろう。細かい条項や政治的理念をわざわざ明文化しなくとも、運用が容易でありながら、他者を尊重する文化の形成には参加者が共有できる理念を掲げるだけで十分に機能するのである。
さいごに
本稿で詳述してきたように、DebianとUbuntuの歴史が示す通り、大規模な共同作業において、基本的な行動規範が必要であることは当然だとは思う。しかし、その後のCoCの進化は、本来の目的を見失い、オープンソースコミュニティに新たな問題をもたらした側面もあるだろう。
Contributor CovenantのようなCoCの普及はある意味で歴史の必然だったのかもしれないが、振り子が一方の極端からもう一方の極端へと振れすぎたのではないだろうか？Contributor Covenantに代表されるような、汎用的で重量級のフレームワークの広範な採用は、官僚的な運用コストの増大、Rustの事例に見られるようなガバナンスの危機、そして企業や特定利益集団による乗っ取りへの脆弱性といった深刻な病理を生み出したとも言えるだろう。これらのフレームワークは、参加者に対する低い信頼を前提として設計されており、オープンソースの生命線である、時には辛辣でさえある活発な技術的議論を萎縮させる危険性をはらんでいる。
今求められているのは、全サイズ共通のフリーサイズなテンプレートを思考停止で導入することではなく、個々のプロジェクトの規模、文化、目的に合わせた「身の丈サイズ」のアプローチである。Linuxカーネルのような世界中の開発者と大企業が参加する巨大プロジェクトの真似をしても仕方がなく、おそらく、多くのプロジェクトにとって理想的なCoCのモデルとしてはRuby CoCが挙げられるだろう。短くて分かりやすく、原則に基づいており、ハラスメントや個人攻撃といった明白な不正行為の禁止に焦点を当てつつ、技術的な意見の対立についてはコミュニティの自浄作用を信頼する。このバランスこそが、多くのプロジェクトにとって最適解である。前時代的と思われるかもしれないが、結局はこれが最もロバストな規範なのである。
オープンソース・プロジェクトはCoCに関する自律性を取り戻すべきだ。CoCは、ソフトウェアを構築するというコミュニティの中核機能を守るためのシンプルな「盾」であるべきであり、コミュニティ自身に向けられかねない複雑な「武器」であってはならない。大多数のオープンソース・プロジェクトにとって、ほんの数行で収まる程度のCoCは、単に十分であるだけでなく、むしろ優れている。何故なら長くなればなるほど、そのコミュニティにとってそれが必要なことが起きた過去があるからである。
Shuji Sado 