Ladybirdの開発方式変更
(ladybird.org)- Ladybirdは、最初のalpha releaseと実ユーザー向けブラウザーの公開準備に合わせて、公開pull request の受け入れを停止し、コード変更はプロジェクトのメンテナーのみが取り込むことにする
- AIツール によって、本気の貢献に見える作業をより速く安く作れるようになり、大きなパッチが善意や相当な努力を示すという従来の信頼モデルが弱まった
- ブラウザーは、インターネット全体からの信頼できない入力をユーザーのマシン上で実行するため、うまく偽装された 脆弱性 が1つあるだけでも攻撃者には十分である
- 現在開いている公開PRはすべて閉じられ、issues・comments・email・forks を通じた別個のパッチ提出手続きや シャドー貢献システム も作らない
- Ladybirdはオープンソースのままであり、外部参加はコード提出の代わりに、明確なバグ報告、縮小再現、Webサイトテスト、標準・設計の議論、セキュリティ報告、技術的フィードバックへと向かう
開発手順変更の要点
- Ladybirdは今後、公開pull requestを受け付けず、コードベースの変更はプロジェクトのメンテナーだけが取り込む方式へ移行する
- 最初のalpha releaseを準備する段階で、より厳格な開発手順、より明確なセキュリティモデル、そしてブラウザーに入るコードに責任を持つより小さな集団が必要になった
- 過去には、大きなパッチは相当な努力と善意を示す合理的な代理シグナルだったが、AIツールによってその前提はもはや成り立たなくなった
- ブラウザーはインターネットの信頼できない入力をユーザーのマシン上で実行し、巧妙に偽装された脆弱性が1つあるだけで攻撃者に十分な条件となる
- オープンソースでは、メンテナーの信頼を得てそれを悪用しようとする、忍耐強く資金や資源のあるキャンペーンがすでに存在しており、本気の貢献に見える作業をより速く安く作れるようになったことが違いである
- Ladybirdに入るすべての変更は、アーキテクチャに適合し、将来のリファクタリングに耐え、ブラウザーの他の部分と正しく相互作用し、メンテナーが理解できるものでなければならない
- コードが手書きかどうかは本質ではなく、ブラウザーに入ったあと誰が責任を負うのかが本質である
移行措置と今後も可能な参加
- 現在開いているすべての公開pull requestは閉じられ、既存のキューを維持すると実質的に公開貢献経路が開いたままになるため、今この移行を行う
- 今後、pull requestはプロジェクトのメンテナーに対してのみ提供される
- issues、comments、email、forks を通じた別個のパッチ提出手続きを作らず、fork や patch dump を upstream Ladybird の review queue として扱わない
- 外部コードはライセンス条件に従って存在しうる
- Ladybirdはオープンソースのままであり、ソースコードはオープンソースライセンスに基づいて引き続き公開される
- 外部参加は、明確な bug reports、reductions、website testing、standards discussion、design discussion、security reports、technical feedback を通じてプロジェクトの進行に役立つ
- 実ユーザーにブラウザーを公開しようとする準備段階では、開発手順もその責任に見合ったものでなければならない
2件のコメント
Hacker Newsの意見
最近、Godot のような大規模なオープンソースプロジェクトのPRをよく見ているが、コードも説明もすべてAIが作ったPRがかなり増えている。
プロジェクトのポリシーで禁止されているので、たいてい投稿者は軽く注意されるのだが、多くの人はそれを受け入れる一方で、一部はメンテナに感謝しないと腹を立てる。
AIに完全に乗っている人たちでさえ、コードの塊を作り出すこと自体には本質的な価値がない、という点をまだ内面化できていないように見える。
自分が費やした労力は大幅に減っているのに、大きなPRを出したときにはAI以前と同じ反応や感謝を期待している。
そういう文脈では、この業界にもともと多すぎた 態度の悪い人たち が、AI以後に行動を変えるとは思えない。
ちなみに、私の職場の非技術職の社員が、私の管理する社内リポジトリにAI生成PRを出し始めたのだが、品質は素晴らしく、レビューのフィードバックもよく受け入れて素早く反映している。技術職でないことが問題なのではなく、態度の問題 だ。
それは貢献の仕方だけでなく、普段の話し方にも表れている。「自分がXを作った」、自分の「キュレーション」が結果に非常に大きな影響を与えたというこだわり、LLMの貢献を口にしづらがること、「自分は作ることに集中し、他人は細部に時間を無駄にしている」という態度、潜在的な欠陥と向き合うのを拒む姿勢などがある。
自分の作った成果物が欠陥だらけで雑なものかもしれないと常に疑っているシニア開発者たちとは、驚くほど対照的だ。インポスター症候群が反転した ような感じだ。
こうしたPRを出す人たちの側に100%問題がある。プロジェクトのルールを破ることにためらいがなく、しかも傲慢ですらある履歴があるなら、その人のプロフィールを見る潜在的雇用主や将来の協業相手にとって、巨大な 危険信号 になるべきだ。
なぜ自分の評判をわざわざ傷つけるのか理解できない。悪い行動の記録を残すくらいなら、プロフィールに何の活動もないほうがずっとましだ。
たとえば「プロジェクトの境界を守ることでも、コード品質を保証することでもない。これは、AIの効率を本当にマスターしたあなたのような未来志向のクリエイターを脅威と感じる伝統主義者たちが作った 門番装置 だ」といった具合かもしれない。
「相当なパッチは相当な努力を意味しており、その努力は善意の合理的な代理指標だった。今やその前提はもはや成り立たない。」
この一文が記事の核心であり、ほとんどのプロジェクトに当てはまると思う。
それでも、ある人が長期的に十分コミットしてメンテナになれるかどうかを判断する仕組みは必要だ。ソースへの貢献は、もはやそのシグナルとして信頼しにくくなっており、今後どんなシグナルを使うようになるのかはわからない。かなり難しい問題になるだろう。
ただし、もしAIが本当にプログラマの生産性を大幅に高めるなら、成功したオープンソースプロジェクトに大規模なメンテナチームは不要になるかもしれない。
一方では、バザール で育ったなら 伽藍 に移るのが「オープンソースの死」のように感じられるかもしれない。実際には、より古い作業様式に戻るだけなのかもしれないのに。
その一方で、外部コード貢献を受け付けなければセキュリティ態勢は明らかに良くなるが、誰を僧団に招くべきかを見極めるのはもっと難しくなるだろう。
GitHubが台頭する前のオープンソースプロジェクトは、強い塀に囲まれた庭に近かった。部屋に入るとじっと見られる小さなクラブのようなものだった。GitHubは接触を商品化し、貢献前に必要だった労力や関心の障壁を下げた。
いまやその時代は終わり、何かに貢献する前に、まず信頼を築かなければならない。
これはオープンソースの死ではなく、誰もが自由に歩き回り容易に相互作用できた 地球村の死 だ。小さく、社会的で、信頼ベースの共同体の復活であり、この流れがインターネット全体に広がってほしい。
今の人たちは、その比喩やRaymondの本を知っているのだろうか。Microsoftが主要なオープンソース供給者であり、地球上のオープンソースプログラミングの大半を可能にするプラットフォームを担っている世界なのだ。90年代後半から来たタイムトラベラーに説明してみてほしい。
また、兄弟コメントが示唆していたように、Linuxカーネルのような典型的な「バザール」ですら、今ではGitHubの無制限な無法地帯モデルと比べればかなり 伽藍 的に見える。
だからLadybirdの決定を問題だとは思わない。むしろ、ソフトウェア開発の人間的側面を強め、AIフリーライダーにブレーキをかける決定だと思う。
理想的ではないが、評判を築くこと にはもともと時間がかかるものだ。
こういうのを見ると、AIなんて最初から存在しなければよかったのにと思ってしまう
オープンソースプロジェクトが新しいメンテナーを見つけてメンタリングする能力を失っているのは、本当にがっかりだ
「どのような手段でもパッチを提出する手続きは存在しない」と「外部参加は依然として重要だ: 明確なバグ報告」というのは
つまりバグを見つけて直すことはできるが、具体的にどう直したかは言ってはいけないということか
その代わりにチームがもう一度それを突き止めなければならない。すでに他の誰かが繰り返しやってのけたことをまたやるなんて、チームもさぞ楽しいだろう
ユーザーであり開発者でもある立場として、自分の生活を改善できるソフトウェアにこんな障壁を置くプロジェクトに、なぜ時間を使うべきなのか分からない。自分の修正が実際に受け入れられる可能性のある Firefox や Chromium を使うほうが、はるかに簡単に見える
昔、新しい Chromium バージョンが自分の製品でクラッシュしたとき、V8 に修正案を提案できて、それが次の Chromium リリースに反映され、製品が再び動くようになった経験はとても有用だった(https://github.com/v8/v8/commit/4f8a70adca01c)
こういう経路がなければ、Chromium 開発者が時間不足で原因を把握できず、修正もしなかったかもしれない
「プルリクエストは、もはや提出者について以前ほど多くを教えてくれない」と言うが、プルリクエストを出した人については、そもそも誰も知る必要がないはずだ
Firefox や Chromium に入るコードは、提出者の「努力」や「善意」ではなく、レビューで確認された コードの正確性 を基準に決められるべきだと思う
コード修正のレビューは、自分で考え出すより明らかに簡単だ。そうでない状況なら、最初から自分でコードを書けば終わりだ
プロジェクト側としては、望まない PR はいつでも無視したり閉じたりできる。だが、外部貢献をレビューしたり、自分たちの再実装の入力として使う 選択肢 自体を塞ぐのは賢明には見えない
その精緻な分析を共有することが、貢献を最大化する方法だ。コードはせいぜい任意のボーナスに近い
君のバグ修正に価値はあるかもしれないが、その価値がレビューして受け入れるコストを上回るとは限らない
「コード修正レビューは自分で考え出すより明らかに簡単だ」というのは、十分に複雑なプロジェクトでは完全に間違っている。修正は1行でも、その結果は遠くまで影響しうる
ユーザーであり開発者でもある立場として、そんなルールのプロジェクトに時間を使いたくないなら、使わなければいい。君もプロジェクトに借りがあるわけではないし、プロジェクトも君に借りがあるわけではない。それだけ単純な話だ
Firefox や Chromium ははるかに大きなチームで運営されているし、Linux カーネルは言うまでもない。彼らには君の貢献を受け入れる余力があるのかもしれない
自分の経験と元記事の事例だけでなく、似たような文章を共有した数多くのメンテナーの経験もそうだ
この問題について専門性の根拠となる、何年にもわたってメンテナンスし、貢献レビューをしてきたオープンソースプロジェクトのリンクを共有してもらえるか?
メンテナーが解決アプローチを理解できるよう、自然言語による説明 で書けばいい
彼らの優先順位やニーズは違う。この件では評価したうえで、有用ではないと判断されたということだ。コストが利益を上回ったという意味だ
少なくとも一つの重要な点では、Chromium/Gecko/WebKit は今や Ladybird よりも「開かれた」ブラウザエンジンに見えるのが興味深い
Servo は AI を使わない限り外部貢献を受け付けるので、中間くらいと言える
資金が潤沢でないチームが人件費を節約するために貢献を閉じなければならない、というのは理解できる。だが、Google/Mozilla/Apple が開放性を可能にするために投入している経済的資源について、人々は十分に評価していないようにも感じる
個人的なバイアスと経験を明かすと、今は引退しているが、以前は Google で Chrome を作っていた。多くの同僚が外部貢献者を育てるのを見たし、自分も非公式に、あるいはインターンシップのようなプログラムを通じて一部それをやっていた
独占の構築に永遠に感謝すべきだとは思わない
なぜその決定をするのかは理解できる。プルリクエストの大半がAIで書かれたコードなら、メンテナーもClaude Codeに直接プロンプトを入れられる。
オープンソースかどうかに関係なく、ソフトウェア工学というゲーム全体が完全に変わったのだと思う。コードの塊は、2年前と同じ意味を持ったり示唆したりはしない。
数年前なら、私がコンパイルされてテストを通る複雑なPRを送れば、それだけ時間と認知的投資をしたという意味だった。コードベースや機能、あるいはバグを理解していなければ、そうした投資をしていない可能性が高かった。
今ではその理解を得るコストはおおむね以前と同じだが、AIがコンパイルされてテストを通るコードを生成するコストを大幅に下げた。
善意である可能性が高いコミュニティ参加者は、安いもの、つまりClaude Codeのトークンを喜んで提供するが、それがあまりに安くなったため、高価なもの、つまり人間の理解を提供した良い指標にはならなくなった。
私はOpenCodeでサイドプロジェクトに取り組んでいて、かなり多くの時間をかけてプロンプトを書き、適切なファイルをセットアップし、作ろうとしている製品やロードマップを説明している。
変更後に自動チェックを数多く回せる密な検証ループを整え、生成された機能が壊しうる境界ケースも手動で数多くテストしたうえで反復する。種類の違う仕事ではあるが、手でコーディングするときより速く前進できる。中核となる構成要素は検証ループだ。
ここ数か月の経験では、AIでコーディングすることも技術であり、試しながら新しい手法を学んで上達していく。つまり、うまくやれば価値のある結果を作れるということでもある。
だから最初の文には異論があるが、2つ目の文には完全に同意する。私たちが失ったのは、深く考えた結果と考えなしに生成した結果を簡単に見分ける能力だ。ここでは安価な検証に集中することが大いに役立つはずだ。
すべてのプロジェクトがこの方向に向かう気がする。一緒に計画を磨くほうがより筋が通っている。
AIが最初に登場したとき、いつか職を失うのではないかと怖かった。私は運が良かったが、実際に多くの人が失い、それはとてもつらいことだった。
自動化によって誰かが何かを失うときは、経済論理とは無関係に人間の側に立ちたいし、少なくとも最も大きな影響を受ける人たちに対して社会が引き続き公正であってほしいと思う。
今はコミュニティが影響を受けるのを見ている。PRを殺せば、コード貢献だけでなく、アイデアやコードに対するより多くの目といった不可視の貢献も大きく揺らぐ。それはずっと悪く感じられる。
私は葛藤し、混乱し、怖れている。それでもClaudeやDeepSeek、各種技術、複雑なハーネスやMCPなどを使っている。だが今はすべてが移行期のように見える。いったい何への移行なのかは分からない。
多くの問いは、人生に意味を与えなければ答えられない。人間の手触り？ もう手遅れなのか？ それに、ある曲が好きだったのにSunoだった。知ってからいいねを取り消した。自分があまりにも頻繁に愚かに感じられる。
まとまりのない脱線で申し訳ない。Ladybirdが好きで、ノートPCにもステッカーを貼っている。うまくいってほしい。
竜巻のど真ん中にいるような感覚だ。それでも画面を消して机に座り、落ち着いて第一原理を思い出しながらゆっくり考えるのが助けになる。
Obamaの言葉を借りれば、「現実は最後には追いついてくる」。
いろいろ言われてはいるが、iOSが毎年10年分の機能や修正を出しているわけではない。文字どおり誰もそんなことはできておらず、むしろ既存機能が壊れているという不満が出ている。だから私たちが10倍の生産性に到達したという話は事実ではありえず、この事実はいずれ私たちに追いついてくる。
人間らしく考えなければならない。多くの人が感情的に投資している点も覚えておくべきだ。ジュニアたちは、自分を拒んだ市場で輝く機会になってほしいと願っている。CEOたちはAIに賭けており、引き返したくない。シニアたちは、自分が無用になったわけではないというシグナルを送りたがっている。AI企業は言説を汚染するだろう。だがこの煙は結局晴れるはずだ。
たいていは望まれない意見、敵対的買収の試み、価値の抽出、ありがちなドラマ、そして単にコードを書くことに上乗せされる全般的な運用負荷に行き着いていた。
いつもそうだったわけではないが、GitHub流の自由なオープンソース開発モデルと、あらゆる摩擦の除去が、明らかに新たなデフォルトを作った。
そのモデルは元々持続不可能だったが、消耗の速度が十分低かったので、疲れた人をより多くの人間で置き換えながら持ちこたえられた。
AIが消耗の速度を置き換えの速度より高くしてしまった。だから、より多くのプロジェクトがこの立場、あるいは近い立場を取る可能性が高い。
私はクリエイターでありプログラマーでもあるが、あるコミュニティで起きていることを見るのは嫌なのに、開発にはエージェントを使っている。GoogleやStack Overflowが最初に現れたとき避けがたかったように、LLMにもはっきりした前後を分ける瞬間があるように思える。
これといって有用なことを付け加えるのは難しいが、こうした葛藤を感じているのは自分だけではない、ということは言いたい。新しいものはたいていそうだ。ある領域では莫大な利益をもたらす一方で、別の場所では人間性を剥ぎ取るように見え、ある人たちはハッタリやゴミを作るが、別の人たちは新しい能力を得てより良いものを作る。残念ながら、普遍的な真理はないようだ。
この記事を読んで、何とも言えない後味の悪さが残った。というのも、筆者はしばしば1,000行を超える非自明なPRを作り、ときには1日に複数作成し、レビューなしで当日マージする傾向があるからだ。
LLMの観点を抜きにしてもそうだ。そのうち何パーセントが支援を受けたものかは分からないが、たとえ0%だったとしても、自分が安心できる開発速度ではない。
「コードを手で打ったかどうかは本質ではない。重要なのは、そのコードがブラウザに入ったあと、誰が責任を負うのかだ。Ladybirdは実際のユーザーのためのブラウザになりつつある。変更を導入する人は、その変更がプロジェクトに属すると判断し、その結果に責任を負う人でなければならない。」
会社で何年も使ってきたオープンソースのプラットフォームがあり、有料のEnterprise版を使っている。そのプラットフォームにかなり奇妙なセキュリティ欠陥が入り、調べてみるとAIがプロジェクトを支配していたことが分かった。
明示されているかどうかに関係なく、コミットログを見るだけでも量と頻度から明らかだ。非常に失望した。
[1] https://github.com/awesomekling
LLMがLadybirdのこの決定を導いた理由の1つかもしれないが、唯一あり得る理由ではない。たとえばSQLiteは、ほぼ最初からずっとこの方式で開発されてきた。
人それぞれやり方があるのだと思う。
MITライセンスで、メンテナはバグ報告に常に感謝しているが、プロジェクトのすべてのコードはたった3人が書いている。
自分たちの時間とプロジェクトを守るための、完全に合理的な動きだ
Lobste.rsの意見
最近のclangでのコントリビューションレビューはあまりにも悲惨だ。終わりのないゴミPRが押し寄せてきて、人々は露骨な痕跡を以前よりうまく隠すようになったが、それでもたいていは見抜けるし、それをふるい分けるのに時間がかかる
AIの使用を認めてどう使ったか書いてくる人がいても、その説明が本当なのか、それとも使用を矮小化して質の悪いPRを通そうとしているのかを結局確認し直さなければならない
これまで本当にたくさんこういうPRを見てきたが、バイブコーディングPRで実際によかったものは一つも見たことがないと思う。中には「まあまあ」なものもあって、作者自身が作業に着手している場合もあるが、大半は消え、残りもclangの内部知識がなくても基本的なコーディング概念から完全に間違っているのが明白だ
さらにひどいのは、fuzzer→bug→LLM→PRのパイプラインを自動化したスクリプトで、実際のバグを深刻に誤解し、壊れたやり方で「修正」し、質の悪いテストを付けたり、元の失敗ケースすら入れなかったりする
結局、新しいコントリビューターに時間をかけて力量を育てたいという気持ちまで薄れてしまう。見たことのない名前がクラッシュ修正PRを出してきたとき、それが時間の無駄なのか、本当に貢献者になりうる人なのかをまず疑ってしまう
ただプロジェクトにゴミを投げ込むだけの人は、貢献や学習に関心がなく、たいていは履歴書に「clangに貢献」のような項目を入れたいだけに見える
その後も来続けて「なぜ一覧が更新されないんだ？ なぜまだ自分が載っていないんだ？」と聞いてきて、Webサイトが更新されたあとは消えた
ただ、私も若いころは同じように愚かだった。有名なオープンソースの人物のWebサイトをミラーできると聞いてミラーを作り、一覧に入れてくれとメールしたこともあるし、1337 hax0rになるつもりでnmap開発メーリングリストを購読したものの、パッチを送ったことは一度もなかった
問題設定は誰にとっても明確だ。何十年もの間、オープンソースプロジェクトはコード貢献を通じて誰を信頼すべきかを学んできたし、人々は仕事をし、変更に責任を持ち、関わり続け、その信頼は仕事そのものから生まれていた
ただ、この解決策は Zig プロジェクトが選んだ LLM貢献禁止 よりも厳しい、しかも悪い版に見える
AIツールが経済性を急速に変えつつある今、PR は以前ほど提出者について多くを語ってくれない。大きなパッチは以前なら大きな努力を意味し、善意の代理指標でもあったが、今ではその前提は成り立たない
懸念しているのは、オープンソースは難しいビジネスであり、その価値ある利点を最大限活用すべきなのに、貢献者は実質的に無料で莫大な価値をもたらし（contributor poker）、採用経路としても非常に重要だということだ。なのにそれを全部拒否するのは狂った選択に見える
LLM がその穴を埋められると主張することもできるが、第一に信頼されていない貢献者の PR でのみ LLM 使用を禁止することもできたはずだし、第二に最高の LLM でもコストがかかり、トークン価格は上がっており、コードはどうせレビューしなければならず、結局のところコードベースの一部に責任を持つ信頼された中核貢献者にはなれない
PR から流入するコードをなくせば、時間がたつにつれて少数の貢献者がコード全体を所有するようになり、プロジェクトが ライセンス rugpull をしやすくなる。著作権所有がうまく分散されていれば、こうしたことはもっと難しい
全体として良くない。オープンソースを不必要にさらに問題の多い事業モデルにし、中核貢献者の採用をより難しくし、コード所有を少数に集中させている。災厄の明白なレシピに見えるので、単なるミスなのか、それとも Ladybird のスポンサーの一部が何か妙なゲームをしているのかと疑いたくなる
本当のところ、この変化の背景が気になる。毎月のステータスレポートの冒頭でさまざまな新規貢献者数を誇っていたプロジェクトが、ここまで急に方針転換したのはかなり急激だ。今出されている説明は、少なくとも不完全に見える
Zig と Ladybird はどちらも、私たちが望まなかった未来の中で前に進む方法を探している。何年もの間、私は何もわかっていなかったし、正直こんな未来が来るとは思っていなかった。今では何が「正しいこと」なのかまったく明確ではない
Zig に尋ねたいのは、LLM PR と人間が直接作った PR を区別できないという点だ。低労力のゴミはふるい落とせても、「AI禁止」をやるには一種のチューリングテストを通す必要があり、私と Claude Pro ライセンスがあれば十分通過できる
「AI禁止」が実際にやることは、誰かが LLM コードを送りつけて手作業だと主張し、それがばれたときにその人とその評判を攻撃できるようにすることだ。そんなことに時間を使いたいのか？ 手書きコーディングを装って LLM を使う人を暴く Karl Jobst のような存在が生まれるだけだ
LLM PR を止められるわけではなく、ゲームを「捕まえられるものなら捕まえてみろ」に変えるだけだ。Ladybird で Andreas が rugpull に近い決定をするのを見たとき、最初は背筋が寒くなり、次には度胸はあると思った。LLM 補助と信頼は本当に大きな問題なので、Zig と Ladybird の両方が既成概念の外で考える姿を見たい
実際には Designator であり、私の読みでは辞任するか無能力状態にならない限り、その地位は生涯保証される。Designator は多数決で決めるが 2 人しかいないなら 2 人とも同意しなければならず、この人たちは Directors を指名・解任し、定款変更にも同意が必要になる
つまり彼はこの非営利組織に対して、実質的に牽制のない拒否権を持っていることになる。Andreas も同様だが、Andreas は作業のかなりの部分を作った人物であり、プロジェクトに関与していて億万長者でもない。Wanstrath は億万長者で、資産のごく一部を寄付すると決めただけで運営には関わっていないのに、同じ権限を持つ
私が見落としている妥当な法的理由がない限り、オープンソースプロジェクトにとって良いガバナンス構造には聞こえない
最近貢献を閉じたプロジェクトが長期的にどうなるのか心配だ。いずれ信頼された中核人材の一部が去る時点が来るだろうが、実績ある長期貢献者がいなければ明確な後継者がいないかもしれない
基本ルートは バーンアウトと放置されたプロジェクト につながりかねないので、それを乗り越える方法を見つけてほしい
これをどんな種類の リーダーシップ とも見なさない。正しい方向への一歩でもないし、私たちが共に生きる方法についてのアイデアでもない
圧力が現実のものだというのはわかるが、対応が活気や希望に満ちたものではなく、冷笑的で敗北主義的に感じられて残念だ
「今回の変更の一環として、現在開いているすべての公開 pull request を閉じる」という部分は衝撃的だ
数年前、あるプロジェクトが PR をレビューするリソースがないと判断して私の PR を閉じたことがあるが、かなりつらかったし、その PR に作業を費やした貢献者にとって公平ではない
提示された理由は理解できるが、この決定は心配だ。必ずしも悪いというわけではなく、一時的なもので、後で別の折衷案を見つけるなら問題ないかもしれないが、それでも懸念はある
これが最初の警告サインというわけでもない。LLM支援のRust書き直しにも同じような印象を受けた。Bunとは違って比較的慎重で、レビュー可能なサイズのコンポーネントと明確な入出力を持ち、既存コンポーネントと並列実行して不一致を見つける方式ではあった。それでも、ブラウザエンジンで見たい進め方ではない
Ladybirdにはうまくいってほしい。新しいブラウザエンジンが寡占構造に挑戦してほしいからだ。ただ、Ladybirdが道を踏み外した場合を考えると、ここ数年停滞していたServoが順調に前進しているのも救いだ
Rust実装にAIゴミコードを使い、DHHを支持する側、つまり白人至上主義や反LGBT寄りに見え、かなり攻撃的にも見える。このプロジェクトが遠くまで行くとは思えない
外部から貢献者になれる入口がないなら、多くを取りこぼすことになると思う。単に通りすがりにPRを投げる以上の、より真剣なコミットメントが必要だとしてもだ
そうすれば、開発者を追加しようとするときにコードベースを知っている人材プールが広がるし、コアチームが優先していないニーズを外部組織が解決できるかもしれない。これは採用にも役立ち、作業負担の軽減にもつながる
この記事にvibecodingタグを付けるのは適切ではないように思う。バイブコーディングの被害者を、その行為を宣伝している人たちと同じタグで括るのは根本的におかしい