■ 1. PRという当たり前の揺らぎ
- PRの位置付け:
- OSSへの貢献はプルリクエスト（PR）を送るのが作法
- GitHubが広めたこの作法は20年近く当たり前だった
- AIによる揺らぎ:
- AIが数分で生成したPRを、人間のメンテナーが何時間もかけて読む構図が生じている
- 生成コストとレビューコストが釣り合わなくなっている
- ハントリー氏の宣言:
- AIコーディングエージェントを実践するオーストラリアのエンジニア、ジェフリー・ハントリー氏の主張
- 2026年10月14日に記事「オープンソースの新しいモデル：プルリクエストは受け付けない、リミックスは歓迎」を公開
- 今後GitHubで公開する自身のコードではPRの受付を無効にする
- 代わりに「どう改変すればよいか」の手引きを公開し保守する
■ 2. 伽藍とバザールからリミックスへ
- 伽藍とバザール:
- エリック・レイモンド氏の1997年の論考で、開発の進め方を2つのモデルにたとえたもの
- 伽藍は少人数の閉じたグループが計画的に作り込むモデル
- バザールは誰でも参加でき、自己組織的に改良が進む開かれたモデル
- GitHubはバザールの思想を「誰でもPRで貢献できる」ワークフローにした
- AI以前からのバザールの無理:
- 公開者には報酬なしで保守する義務があるという奇妙な社会的期待が生まれた
- 利用者はメンテナーに「マージしてくれ」と迫る消費者になった
- ダムの決壊:
- AIの登場で状況は完全に破綻した
- AI生成PRを読む理由はなく、読みたいのはその核心にあるアイデアだけ
- リミックスモデルの提案:
- 変更を上流リポジトリに送らず、利用者が自分の環境で自分用に手を加える
- 原則は「パッチよりアイデア（Ideas over patches）」
- 原作者には取り込む義務も保守する義務もない
- 伽藍への回帰でもバザールの継続でもない、その間にある第3の形
■ 3. 編集長の見解: 自分で保守するコスト
- 作者としての実感:
- 個人で公開するOSSツールに届くPRは年に数件で、AI生成PRの洪水はまだ他人事
- 届いたPRは一つずつ中身を見て、そのまま入れるか手直しして入れるかを決めている
- 利用者としての共感:
- 気に入らない点は自分でフォークして直し、自分で管理すればよいと以前から考えていた
- そのためハントリー氏の提案自体に違和感はない
- Chrome拡張機能の問題:
- ストア経由の拡張機能を自分用に直すと、ストアからの自動更新を受けられなくなる
- 開発者モードで自分用の版を読み込めるが、以後の面倒は自分で見ることになる
- 仕様変更が多く、作者が1回追随すれば済むことを改変した各自が行う羽目になる
- Androidアプリの問題:
- これまではAPKファイルをURLから開くだけで自作アプリを入れられた
- Googleは開発者認証を進め、2027年には全世界で未認証開発者のアプリの導入が制限される
- 制限後は24時間待たされる上級者向け手順か、PCからのADBでしか入れられない
- 一方で10月13日、AIで作った自分専用アプリを開発者登録なしでGoogle Play経由で入れられる仕組みが発表された
- 自分用アプリの導入は続けられるが、その入り口はストア側に寄っていく
- 導入後の保守:
- Googleの発表は、自分用アプリの更新が端末にどう届くかに触れていない
- 自分用に直す人が増えるほど、自分で保守し続ける人も増える
- そのコストを誰が払うのかを念頭に置いて提案を読むべき
■ 4. リミックスモデルの5つの要点
- 構造:
- 分散的で組み合わせ可能
- アイデアは単一のリポジトリやメンテナーに収束せず、独立したオーバーレイとして広がる
- オーバーレイは元のソフトウェアに重ねる差分
- ワークフロー:
- 作者はソースと意図を「現状のまま（as-is）」のライセンスで公開する
- 利用者は望む変更を小さなオーバーレイとして1回書く
- そのオーバーレイを開発環境、Dockerイメージ、テスト、CI、エージェントのサンドボックスで使い回す
- フォークして別物を保守する必要はない
- 原則:
- 「パッチよりアイデア」であり、価値の単位は振る舞いや設計の変更そのもの
- メンテナーはそれを取り込むか、作り直すか、無視するかを選べる
- レビュー、統合、保守の義務はない
- 社会契約:
- ライセンスはもともと、誰かの将来の時間への請求権を生まずに改変を許している
- クレジットや可視性は残るが、継続的な保守義務はない
- 上流への取り込みは任意で、意図的に行う
- 発見:
- 有用な改変は、世の中に散らばったオーバーレイの増殖として現れる
- メンテナーは望めばそこから取り込める
- 他の利用者も、エージェントに自分のオーバーレイを更新させて良いアイデアを取り込める
- 具体例: force pushの禁止:
- 上流にPRを送る代わりに、Gitにパッチを当てるオーバーレイを書く
- 定義は1カ所にあり、開発環境、コンテナイメージ、システムテストに一貫して現れる
- 上流への働きかけは不要
- 実装例はNix（宣言的に環境を構築するパッケージ管理ツール）で公開されている
- 知識の壁の消失:
- リミックスは難し過ぎると思われてきたが、実際には知識の壁があっただけ
- エージェントの登場でその壁はなくなった
■ 5. 背景: 既に扉を閉め始めたメンテナー
- 2026年の貢献制限の相次ぐ動き:
- 提案は空想ではなく、著名OSSプロジェクトが外部貢献を制限する流れの中にある
- curl:
- 作者ダニエル・ステンバーグ氏が2026年1月、6年続けたバグバウンティを2月1日で終了すると発表
- 2025年には報告の20％がAI生成で、有効な報告の割合は5％まで低下していた
- 押し寄せる投稿がセキュリティチームに高い負荷をかけていた
- tldraw:
- 創業者スティーブ・ルイズ氏は外部からのPRを全て自動クローズする方針を取った
- Ghostty:
- 作者ミッチェル・ハシモト氏はAI生成コードの外部寄与に制限を設けた
- Ghostty自体は多くのAI支援で書かれている
- AI生成のIssueをAIに読ませてPRを生成する連鎖で、低品質な寄与が増えたことが理由とされる
- GitHub:
- 2026年2月、リポジトリ設定に「プルリクエストを無効化する」選択肢を追加したと報じられている
- AI Slopageddon:
- RedMonkのアナリストがこの状況を「AI Slopageddon」と呼んだ
- スロップ＋アルマゲドン、すなわち低質な生成物の大災厄を意味する
- ハントリー氏の「ダムの決壊」もこの状況を指す
- 提案の位置付け:
- 閉めた扉の代わりに別の入り口を用意する試み
■ 6. 反論: PRはただの投稿箱ではない
- レビューによる品質担保:
- 第三者の目を通すことでバグや設計の問題が見つかる
- リミックスでは改変は各自の責任となり、誰も見ていないコードが増える
- 修正の集約:
- セキュリティ修正が上流に集まれば、全利用者が1回の更新で守られる
- 改変が散らばれば、同じ脆弱性が無数の環境に残る
- 誰がどこを直したかも追えなくなる
- 知識の共有:
- PRの議論は、変更が必要な理由という文脈の記録でもある
- ハントリー氏はDiscussionsを開けておくとしているが、コードと議論が分かれる
- Nixと知識の壁:
- 実装例のNixは学習コストが高いことで知られる
- ハントリー氏自身も別の記事で「Nixはひどいプログラミング言語だ」と書いている
- 「エージェントが壁をなくした」はエージェントを使いこなせる人には当てはまるが、全利用者には当てはまらない
- 提案段階の宣言:
- 1人の開発者の宣言であり、提案段階にとどまる
- 全リポジトリで実際にPRを無効化したかは執筆時点で確認できていない
■ 7. 読むときの注意点
- ハントリー氏の記事は本人の提案と宣言であり、採用事例や効果の測定はない
- curlやtldrawの事例:
- PRをやめたのではなく、外部貢献や報奨金を制限したもの
- リミックスモデルとは別の対応
- GitHubの「PR無効化」設定は報道に基づく記載であり、公式発表での確認が必要
- Nixのオーバーレイは実装手段の一つで、リミックスモデルの考え方自体はNixに依存しない
■ 8. まとめ: 送るから自分用に直すへ
- 提案の核心:
- OSSのライセンスはもともと改変を許しており、PRという作法がそれを忘れさせていた
- バザールの前提の崩壊:
- AIがPRを量産する時代に、人間が全部を読むモデルは続かない
- 各自が自分用に直す形:
- 変更を上流に送るのではなく、各自が自分用に直す
- 原作者の義務をなくし、利用者の自由を広げる
- 代償:
- 品質と修正の集約が失われる
- 誰も見ていない改変が増え、セキュリティ修正が散らばる
- OSSへの関わり方の再考:
- リミックスモデルが広まるかは分からない
- 「PRを送るのが貢献」という形は、人間が書き人間がレビューする時代に合わせたもの
- AIがコードを書く今、OSSへの関わり方を考え直す時期に来ている
- ハントリー氏の宣言はその問いを最も分かりやすい形で突きつけたもの