オープンソースの新しいモデル：プルリクエストは閉じ、リミックスは開く

さて、ソフトウェアエンジニアの世代がいくつか過ぎたので、このエッセイの歴史を紐解くことにします。そして、誰もが「大聖堂」を知っていると仮定せざるを得ません。皆さんはGitHubを日常的に使っているので、「バザール」は知っています。 大聖堂とバザール - Wikipedia Wikimedia Foundation, Inc. Wikimediaプロジェクトの貢献者 GitHubは、バザールのアイデア、つまり分散型でオープンな自己組織化されたオープンソースプロジェクトを取り入れ、プルリクエストを通じて誰でもソースコードを検査したり貢献したりできるワークフローを提供しました。 新しいソフトウェア開発モデルが必要だと考えてきました。私たちは、少数のプライベートで排他的なグループがソースコードを構築し、計画的で、まれで、洗練されたリリースを行う「大聖堂」には戻りません。 しかし、今やAIが登場したことで、何か別のものが必要であることは明らかです。AIが登場する前から、GitHubのバザールモデルは、消費者の権利意識を生み出し、誰もがメンテナーに何かをマージするようにせがむようになり、そのひび割れを見せ始めていました。それは非常に奇妙な社会構造の期待を生み出しました。コードをリリースした人は、それを維持する義務があり、その仕事に対して何も報酬を得ないというものです。 しかし今やAIが登場し、その堰は完全に決壊しました。コードによって生成されたプルリクエストを読むことに何の意味があるのでしょうか？私が読みたいのは、中心的なアイデアです。もしそれが良いアイデアであれば、それを上流に組み込むかもしれませんが、私がそうするという期待はありません。ご存知のように、オープンソースソフトウェアは、ライセンスが「現状有姿」であると述べているため、定義上オープンソースであり、その「現状有姿」は、あなたがソフトウェアをリミックスすることを許可しています。 しかし、問題は、ソフトウェアをリミックスすることが非常に難しいと認識されてきたことですが、そうではありませんでした。それは単なる知識のギャップの問題であり、エージェントが登場した今、もはや存在しません。Nixは何年も前から存在しています。数日前に私が投稿したNixオーバーレイに関する記事を見ていないなら、読むべきです。 世界はまだ、Nixオーバーレイで文字通りすべてを修正できることに気づいていません。 私たちの業界では多くのことが不確実ですが、私が13年間確信していることは一つあります。それは、Nixはひどいプログラミング言語だということです。初めて学んだとき、それは泥沼にはまっているような感覚でした。学習の壁。 Geoffrey Huntley Geoffrey Huntley そこで、他のオープンソースメンテナーを助けるかもしれないと思うことを提案します。これは、私がリリースするソフトウェアに対する私の考え方です。 リミックスモデル 構造：分散型で composable。アイデアは、単一のリポジトリと単一のメンテナーに収束するのではなく、独立したオーバーレイを通じて広まります。 ワークフロー：ソースと意図を現状有姿ライセンスの下で公開します。他者は、望ましい変更を一度表現する小さなNixオーバーレイを記述し、その派生（derivation）をdevenvシェル、Dockerイメージ、NixOSシステムとテスト、CI、エージェントサンドボックス全体で再利用することでリミックスします。フォークしたり、分岐した成果物を維持したりすることなく。 コア原則：パッチではなくアイデア。価値のある単位は、動作やアーキテクチャの変更です。メンテナーは、それを組み込むか、再実装するか、無視するかを決定します。元の作者は、変更をレビュー、統合、または維持する継続的な義務を持ちません。 社会的契約：ライセンスはすでに、誰かの将来の時間を主張することなくリミックスを許可しています。クレジットと可視性は依然として存在し得ます。継続的なメンテナンス義務はありません。上流への統合は依然としてオプションであり、意図的です。 発見：有用な適応は、野生のオーバーレイの広がりとして現れます。メンテナーは、選択すればその広がりからサンプリングできます。他のすべての人々は、エージェントを介して自分のオーバーレイを更新するだけで、アイデアを取得して組み合わせることができます。 例：プロジェクトの消費者が、そのプロジェクトでGitが強制プッシュする機能を無効にしたいとします。上流プロジェクトにプルリクエストを出す代わりに、消費者はGitに強制プッシュを拒否させるオーバーレイを作成します。これは一度定義され、開発者環境、コンテナイメージ、システムテストで一貫して表示されます。上流プロジェクトに対するプルリクエストなしで。 実際には、今後、GitHubでリリースするコードについては、プルリクエストを無効にし、ディスカッションをオープンに保ち、私のソフトウェアをリミックスする方法に関するガイダンスを公開・維持します。0:00 / 0:59 1× 無限にカスタマイズ可能で、消費しやすいソフトウェア。これが標準的な実践になることを願っています。オープンソースをリリースし、大規模なプロジェクトを実行する際の認知的な負担を取り除けば、より多くの人々がソフトウェアをリリースするようになるでしょう。そして、もし彼らが正しい方法で行えば、世界にはさらに多くのソフトウェアが登場するでしょう。GitHubのネットワークグラフは、エコシステム内のリミックスを探索するための素晴らしい方法を提供します。エージェントを使って人々のやっていることを要約したり、エージェントループでリミックスのアイデアを探求し、メインプロジェクトにフィードバックしたりすることもできます。 GitHub - ghuntley/nix-demo at ghuntley.com NixオーバーレイでGitを一度パッチし、devenv、NixOS VMテスト、Dockerイメージで使用する - ghuntley/nix-demo GitHub このアイデアの実演 ps. socials 🗞️ オープンソースの新しいモデル：プルリクエストは閉じ、リミックスは開く。https://t.co/kJAllc39mc pic.twitter.com/DILnyNns42— geoff (@GeoffreyHuntley) 2026年10月14日 Josh Wulfと私は4エピソードにわたってループエンジニアリングについて話しました。モデルはとっくに制約ではなくなりました。残っているのはビジョン、検証、エージェンシーです。スキルパックを削除し、システム全体をテスト下に置き、かつて難しかったすべてを見直してください。Justin Cormack、かつてMirageOSに携わっていた彼は、パブで私に電話して、なぜユニカーネルが復活しているのかについて話しました。それらを難しくしていた摩擦はなくなりました。オペレーティングシステムは設計上の負債であり、セキュリティを気にするなら真剣に検討すべきです。Ralphが昨年公開されたとき、私はそれを保留しました。人々が