あなたのPRはもういらない

18日前原文(dpc.pw)

概要

PRのマージ を断る理由と背景の説明
LLM（大規模言語モデル）活用 による開発スタイルの変化
貢献方法の転換 と価値あるサポートの提案
具体的な協力方法 の提示
フォーク推奨 による開発効率化の促進

コントリビューションの見直しとPRをマージしない理由

あなたの貢献 に感謝しつつ、現状のコラボレーション方法を再考したい意向
見知らぬコントリビューター のコードには悪意ある変更が混入しているリスクが常につきまとう
コードの書き方やスタイル に対する個人的なこだわりや主観的な側面の違い
レビューやCI、マージコンフリクト など、調整作業の手間とタイムゾーンの違いによる非効率
PRのやりとり が開発スピードを遅延させる要因
LLMの進化 により、コード実装自体の価値が相対的に低下
LLM生成コード は悪意のリスクが低く、スタイルも自動化しやすいため、自己完結型開発が容易
他者との調整不要 で、自分のペースで開発可能

ソフトウェア開発の本質的な変化

ソースコード は「ソース」ではなく「中間成果物」としての性格が強まる
自動生成が容易 になり、設計やレビューに価値がシフト
LLMの活用 で設計・レビュー・理解が主なボトルネックに
他人のPR は設計や理解、レビュー面であまり助けにならない
今後は自分でLLMを活用し実装 する方が効率的

価値ある貢献方法の提案

フィードバック提供
- 実装者は利用やリサーチの時間が限られるため、ユーザー視点の改善点や良い点の共有が有益
アイデアの議論
- 多様な経験や視点を持つ人との議論が設計や方向性決定に役立つ
バグ報告・調査
- 再現手順や発生箇所の特定、解決案の議論まで含めた良質なバグ報告は極めて価値が高い
変更のプロトタイプ提示
- 参考実装や生成プロンプトの共有は、実際にマージしなくても設計の参考資料として有用
コードレビューと指摘
- レビュー負荷の軽減や見落とし防止に貢献
フォークして独自開発
- 自分のニーズに合わせて自由に改変し、アップストリームと独立したペースで開発可能
- 設計の多様性や新たな学びにつながる可能性

今後の協力のあり方

コードの直接的なPR提出 は控え、上記のような多様な形でサポートを検討
フォーク・独自実装 も歓迎し、相互に学び合う開発コミュニティ形成を志向

Hackerたちの意見

これ、まあ…大丈夫そう？プロジェクトでバグに遭遇したら、自分で直しちゃうことが多いから、直さなきゃいけないし。バグをPRと一緒に書いてメンテナーに送るのは、普通の礼儀だと思うんだよね。もしマージされれば、アップデートの時にフォークしたりパッチ当てたりしなくて済むし、ウィンウィンだと思う。でも、メンテナーがPRを受け取りたくないなら、それも全然いいよね。自分でやった方が楽な時もあるし。

提出者がLLMを使ってPRを作ってるなら、著者がそのプロンプトを自分で実行するのも納得だよね。プロンプトを共有すればいいだけだし（実際にLLM用のプロンプトとしてフォーマットされてるかどうかは別として）、他の名前の機能リクエストとあまり変わらないし。

└

これには同意だな。もしかしたら、提案された仕様でPRを作るところから始めて、メンテナーがそれを実装するエージェントを使うべきかも。これは、仕事で始めたことに似てる。PRをレビューする最初の段階は、仕様に合意することなんだ。コードを書くことやレビューすることは、ほとんど trivial な部分だよ。

└

LLMを一回きりのプロンプトで使ってるなら、きっと新しいんだね。

└

そうだね。今は、望んだ結果を出すプロンプトの方が、PRの結果コードよりも役立つよ。実際、コードはバイナリの特性を持ち始めてる。

すべてのメンテナーは、他の人にどう貢献してほしいかを言えるべきだと思う。でも、インターネット全体からのパッチは、ほとんどの場合、手間がかかるだけであまり価値がないってのは常に真実だった気がする。人々がそれを受け入れる理由は、パッチ自体のためじゃなくて、新しい貢献者を得るためなんだよね。最終的には役に立つようになるし。

└

記事の著者はこの点を見落としてると思う。実際に人と一緒に働いて、みんながコードベースの似たようなメンタルモデルを持つと、人間同士のコミュニケーションはLLMよりずっと効果的だよ。ランダムな貢献には当てはまらないけどね。

└

でも、インターネット全体からのパッチは、ほとんどの場合、価値に見合う以上のトラブルを引き起こすのは常に真実だった気がする。ああ、15年前にオープンソースプロジェクト（ちょっとしたフリーミアムプロジェクト）に機能を追加したくて、プロのソフトウェア開発の経験もなければ、プルリクエストの理解もなかった。自分がやろうとしていることを説明して、プロジェクトにとって良い機能だと思うって言ってPRを送ったんだ。今思うと、彼らは盲目的にマージすべきじゃなかったけど、実際にマージされて、めちゃくちゃになった。あの日、貴重な教訓を学んだよ、ハハ。

これ、両方の立場を経験したことがある。ghidra-delinker-extensionのメンテナーとして、非トリビアルなPR（オブジェクトファイルフォーマットやISAアナライザーの追加みたいな）が来ると、嬉しいんだよね。それに、ツールチェインをインストールしたり、使い方を学んだり（MSVC…）、いろんなナンセンスやドキュメントのないことを理解したり（COFF…）、必要ならバイナリファイルツールキットの中でバイトパーフェクトなラウンドトリップパーサー/シリアライザーとテストを書いたり、ゴールデンGhidraデータベースを準備したり、ユニットテストを書いたり、リンク解除したものが再リンクされたときにちゃんと動くか確認したり、自分の基準やリンターをクリアして、クリーンなGit履歴を持つことになる。だいたい、彼らのブランチを取って、自分でその作業をする方が楽だし（適切なときにコミットに著作権を付与しながら）、マスターブランチにプッシュしてPRをクローズする方が、GitHubのコメントで遠くの誰かにやらせるよりも簡単だと思う。逆に、仕事ではMbed-TLSの中でPKCS#7証明書チェーンのサポートを実装して、上流にPRを提出してた。正確で、コメントもドキュメントもテストも完璧だったのに、開発者の一人が暗黙のうちに認めてくれた。今でもオープンのままで（もちろんマージコンフリクトはあるけど）、同じ機能のために5つくらいのオープンPRがある。これを見ると、無理に主張するつもりはないし、次のJiraタスクに進むよ。

└

「マスターブランチにプッシュしてPRを閉じる方が、地球の反対側にいる誰かをGitHubのコメントで操るよりマシだ」この気持ちは分かるけど、15年以上前にオープンソースに関わるようになったことには感謝してる。なぜなら、メンテナーたちが「操ってくれた」おかげで、後で自分一人では学びにくいプロジェクトのさまざまなプロセスをたくさん学べたから。

└

普段は、彼らのブランチを取って、自分でその作業を全部やる方が楽だと思う（適切なときにはコミットに著作権を付与して）、マスターブランチにプッシュしてPRを閉じる方が、GitHubのコメントで遠くの誰かを操るよりもずっと簡単だよ。オープンソースへの貢献で最もネガティブな経験はそういう感じだった。私のパッチがマスターに入るまで関わってくれた唯一のメンテナーとのやり取りは、今までのオープンソース貢献の中で最高の経験だった。開発者と関わることを「遠くの誰かをGitHubのコメントで操ること」と見なすのは悲しいね…。

フォークして戻ってくるのが好きなんだ。今、フォークしたプロジェクトを使ってて、ワークフローに合わせてちょっとずつ変更してる。あと1、2週間で、すべてがうまく動いてるって確信が持てたら、イシューを立てて、自分の変更を受け入れてくれるか聞いてみるつもり。主に、自分がフォークを永遠に維持しなくて済むようにお願いする感じ。

最近、似たようなことに気づいたんだ。「持ち帰りOSS」って呼んでるけど、自由にフォークして、自分好みにAIコーディングエージェントを使って修正して、上流の許可を待つのをやめようってこと。重要なバグやセキュリティ修正以外は、PRやイシューを提出する必要があまりない未来に向かっている気がする。OSSは原材料で、あなたのフォークがあなたの製品みたいな感じ。

└

みんながその考え方を持つと、すぐに「原材料」はほとんど残らなくなるよ。

└

これはすごく短絡的だし、自分の足を撃つために銃を磨いてるみたい。もし「持ち帰りOSS」で「PRや問題を提出する必要はあまりない」なら、どうして誰も「重大なバグやセキュリティ修正」のためにPRや問題を提出するんだろう？修正があって、それがうまくいってるなら、彼らはそれで満足だし。ついでに言うと、どうして誰も何かを共有しようとするの？面倒すぎるよ。人々は文句を言うか、全然気にしないかだと思う。数年後、LLMコーディングがみんなが慣れ親しんだ古くて退屈なものになって、共有しないことでいくつかの厳しい教訓を学んだら、もっと効果的なソフトウェアのコラボレーションの新しい形が生まれると思う。自分とLLMが自分とLLMと何千人、何百万の人々とLLMより優れているって考えるよりもね。

└

最近、サイバーセキュリティに特化したリリース日を守るために、そんなレガシープロジェクトに急に投げ込まれた。10年前にチェックインされた何百万行ものオープンソースコードが、SubversionからGitへの移行前にあって、そこから至る所でパッチが当てられて、CVEのdiffが適用できない状態。どの上流バージョンがフォークを最もよく説明するのかもわからない。最後には、プロジェクトマネージャーが「フレームトロワーを消してくれ」って頼んできた。クリーンなマニフェストをタグ付きバージョンとパッチの山にするために、全部引き剥がしてたから。「持ち帰りOSS」ってテイクアウトの食べ物みたいなもので、もし自分の仕事をしないでキッチンカウンターに何ヶ月も何年も放置したら、次にアパートに入る人は吐いちゃうよ。

└

これはずっとそうだったし、オープンソースの主な実用的な利点だね。コードを戻すのはコミュニティサービスの一環だけど、みんながいつも時間があるわけじゃない。問題は、時間が経つにつれて、他の人たちが自分のコミュニティサービスを戻してくれること。バグ修正や機能追加があって、それを利用したいと思うかもしれない。上流と自分のフォークが分岐すると、パッチを更新するのにどんどん手間がかかるようになる。だから、上流に従うつもりなら、パッチを戻すのが得だよ。

これには同意だな。ここ1ヶ月くらいで、LLMがなかったら何ヶ月もかかってたプロジェクトをゼロから実装したんだ。自分のペースで進められたし、どうやって作られているかも分かったから、基盤を築けたって感じ。似たようなサイズのPRを他のプロジェクトでレビューするのはすごく大変だった。特に同じ機能を実装してるやつとかね。小さいPRをちゃんとレビューして受け入れるのにすごく努力したのは、貢献者が頑張ってくれたから。逆に、低い努力のPRは全部拒否したよ。信頼できる他のメンテナーからのPRは、ちゃんとレビューしたとは言えないけど受け入れた。もし君のことを知らないし信頼もしてないなら、LLM生成のPRは送らないでほしいな。最初は仕様書とかバグ、失敗するテストから始めたいし、必要なら自分でコードを生成する方がいい。

なんか、これってLLMの深刻な負の側面に思える。セキュリティパッチがエコシステムをどう通るか考えるべきだよね。こういう変更は理解できるけど、LLMのPRがひどくて多すぎるからこそなんだよね。新しい脆弱性が発見されると、LLMがライブラリを使わないせいで、変更が必要なサイトの数が指数関数的に増える。しかも、ライブラリの貢献者は新しい脆弱性を考慮してコードを変更することを知らない可能性が高い。これって回復してるってより、無用になるまで溶けて分解されてる感じだね。

└

コードの変更は今は安くできるけど、検証するのはちょっと高くつくね。だから、まだ貢献できるよ。コードを提供する必要はなくて、問題を報告するだけでいい。聞こえは悪いけど、理論的には正しいコードをすぐに書き直すのは気が引けるけど、メンテナーの意見がまともなら、意見が強いコードベースはうまく機能するみたい。

└

新しい脆弱性が発見されると、LLMがライブラリを使わないため、変更が必要なサイトの数が指数関数的に増える。一方で、ライブラリにサプライチェーン攻撃があった場合、それがすぐに何千ものプロダクションサーバーに広がることはない。

これまで見た中でこの視点を一番うまく表現してると思うから、あなたの文章力に敬意を表します。この投稿をしばらく考えてたけど、フレーミングの何かが気になって仕方ない。一つの質問に戻ってくるんだ：これらのコミットにCo-authored-byのトレーラーを追加する予定はあるの？提案はこうだ：コードを送らずに、生成に使ったプロンプトを送ってくれってこと。表面的にはそれが軽いお願いに聞こえるけど、プロンプトは小さなもので、一文かもしれないし、全体のdiffに比べて簡単そうに見える。でも、それが手品のようなものなんだ。動作するパッチを生成したプロンプトは、ほとんどの場合一つじゃない。私のPRは、その全ての作業の圧縮された出力なんだ。だから「ただプロンプトを送って」ってのは、二つのことを同時にやってる。貢献者の作業を小さなアーティファクト（プロンプト一つ、そんなに難しくないでしょ）として再フレーミングして、結果を再実行する人に再割り当てしてる。もし私がパッチを生成した実際のもの、全てのトランスクリプトや拒否された試み、修正を送ったら、それはPRよりも小さな貢献じゃなくて、より完全なものになる。そしてそのコミットはあなたの名前の下に載ることになる。これはモデルラボがトレーニングデータについて主張したのと同じ形の議論だね。個々の貢献は「小さすぎて」クレジットを与える価値がないけど、集約されたものは価値があって、それをまとめた人に属する。そこが好きじゃないし、ここでも好きじゃない。もう一つ考えてることは、これらのツールを真剣に使ったことがない人にとって、自分の名前の下に大量のクリーンなコミットを持つエンジニアは非常に生産的な著者に見えるってこと。その見た目と実際に起こっていることとのギャップは最終的には埋まるだろうけど、その間はこういう風に設定することへの本当のインセンティブになってる。これがワークフローに対する反論ではないよ。レビューは高くつくし、信頼できないコードはリスクがあるのは分かる。ただ、Co-authored-byがこの取引の一部であるべきだという主張をしたいだけなんだ。

数ヶ月前に、オープンソース開発がコードを貢献するのではなく、お金を貢献する方向にシフトすると思うって記事を書いたんだ。メンテナーがAIに特定の機能リクエストを実装させるためのトークンを購入するためにね。人気はなかったけど、これは当たると思う：https://essays.johnloeber.com/p/31-open-source-software-in-t...

ハクソク