それに、有料の依存関係は通常、サポートが一つのソースしかないから、会社が倒産したり、製品のサポートをやめたりすると、厳しい状況になるよね。ほとんどの会社が永遠に続くわけじゃないから、自分のプロジェクトがその会社のサポート能力に依存していると、影響を受けるかどうかを考えなきゃいけない。

私の意見だけど、有料の依存関係はだいたい悪いことが多い。なぜなら、その依存関係を提供している会社には、ユーザーを縛りつけるインセンティブがあるから。ベンダーロックインは、購入したコンポーネントだけでなく、メンテナンスを引き受けたくない組織のFOSSにもリスクがある。サードパーティのコンポーネントを組み込むチームがリスクを管理し、適切な代替案を見つけて、ソリューションをモジュール化する責任がある。

有料の依存関係が悪いなら、もしかしたらその価値に見合った金額を払ってないのかも。私のコードに依存関係があるなら、それをサポートするのが自分の仕事だと思っている人がいるといいな。サポートするために十分な人数が雇われているか、あるいはそのコードに自分の価値やアイデンティティが強く結びついている人がいて、誇りを持ってサポートしてくれる必要がある。放置される可能性のある会社は要らないし、「バグは私の問題じゃない。ソースがあるから、自分で直せば？」って言うフリーソフトウェアの作者も要らない。そんな選択肢なら、自分で書いた方がマシだね。

非エンジニアのチームから強制された悪い有料の依存関係を経験したことがある。コミュニティで広く使われている「オープンコア」タイプの依存関係には、いくつか良い経験があるよ。例えば、sidekiqとかね。そういうのは、突然消えちゃう可能性が低いから、他の人たちにフォークされてメンテナンスされるだろうし。お金を払うメリットは、オーナーや会社が安定している限り、無給のソロメンテイナーが燃え尽きてログインしなくなる心配をしなくていいことだね。

https://opensourcemaintenancefee.org/ は、プロジェクトを続けるためのインセンティブとして支払いを利用しているから、依存関係を更新できるんだ。 .NET Rocks! が彼らにインタビューしたよ。 https://www.dotnetrocks.com/details/1948

開発者はこう言って、AWS LambdaやVercelにデプロイするんだよね、ほんとに。

そのアイデアは、もしお金を払っているなら、依存関係は何らかのオープンスタンダードやインターフェースを実装する必要があるってことだと思う。少なくとも他の実装に移行できる選択肢があるから、ベンダーはこの要件でロックインできないんだよね。ちょっと高くつくかもしれないけど、移行する選択肢は常にあるから、脅しとして存在しているだけなんだ。

LLMは訓練された依存関係のコードを吐き出すだけじゃないの？それって、依存関係をフォークして自分のものとして扱うのと何が違うの？

今日は学んだこと。オーストラリアの「She'll buff out, mate」っていうミームを思い出した。

知ってる経験豊富な開発者は、ほとんどがこのアーティクルに同意すると思うよ。大体、みんな一度は間違った依存関係を使って痛い目にあったり、必要ないライブラリをアップグレードする時の面倒くささを経験してるからね。

純粋に雰囲気だけど、ニュージーランド人として言わせてもらうと、ナンバー8ワイヤーの精神はもう20年くらい前に死んでる気がする。

あなたの会社はセキュリティの脆弱性やライセンスについてどれくらい真剣に考えてるの？前は依存関係に対して結構緩い態度だったけど、そういうことを真剣に考える会社に入ったら、かなり変わったよ。

依存関係は二面性があるね。声を大にする人たちは「使い捨て」のソフトウェアに関わってることが多い。ソフトウェアの巨人たちは、組織の隅に追いやられたコードを維持するよりも、エンジニアの時間を使って書き直す方が安上がりなんだ。小さなブランドやウェブショップが高品質でメンテナンスしやすいコードを作る意味はあまりないけど、なぜ「エンタープライズパターン」が存在するのかを再考することをお勧めするよ。これらのアーキテクチャを使う主な理由は、5年後にドキュメントが古くなっても、そのコンポーネントに関する組織の記憶が残っていない状態で、元の開発者が別のチームや部署に移ったり、会社を辞めたりしても、コンポーネントがしっかりと隔離されていて、分析可能で作業が可能な状態を保つためなんだ。外部依存関係を導入することには、2つのビジネスリスクがある。依存関係のサポートが打ち切られる可能性があるから、自分でメンテナンスの負担を背負うか、依存関係を切り替えなきゃいけなくなるか、もしくは破壊的な変更が入る可能性があるから、メンテナンスされていないバージョンに留まるか、製品コードを更新しなきゃいけなくなる。どちらの状況も最終的には機能の流れに影響を与えるよ。トランクとリーフの妥協（依存関係のプッシュとプル）はモジュール化に内在していて、常に存在するけど、内部コンポーネントの場合はその妥協が内部的なもので、外部的なものではない。> 多くの人は新しいコードを書くのが好きで、ビジネスに悪影響を与えてもやっちゃう。でも、10回中9回は「悪い」依存関係を使う方が、社内で書くよりもずっと効果的だよ。もしあなたがSaaS企業なら、たぶんそうだね。短期的な成果がビジネスの成功を決定するから。でも、安全性やサポートの要件がある業界で働いているなら、長期的な視野がビジネスの成功を示すことになるよ。新しいコードを書くことは、成熟した組織ではほとんどボトルネックにならないからね。

問題を再整理する方が、SQLiteのテストスイートをゼロから再発明するよりもずっと安上がりだよ。確かにそうだけど、既存のDBに満足していないなら、ファイルシステム上のファイルレイアウトの方が必要だと思ってるのは間違いかもしれないね。

サードパーティの依存関係を使う理由は二つ考えられる。1) サードパーティのサービスプロバイダーへの依存。もしそのサービスプロバイダーが現行であれば、依存関係はメンテナンスされるはず。2) 書きたくないコードのショートカット。1)には異論はないけど、ビジネス上の理由があってライフサイクルが一致するべきだよね。でも、アプリケーションを動かすためにはメジャーバージョンの破壊的変更があることは覚悟しておくべき。2)については、避けられるコードの複雑さに依存するから、得られるメリットはあまり明確じゃない。依存関係を持つということは、他の誰かが自分の時間を使って更新やテストをしなければならないことを決めることになる。サードパーティの依存関係を持つことは、コードベースを維持する責任を負うこと、またはそれを怠るリスクを負うことでもある。

あなたのRDBMSの例は面白いね。ここにはたくさんのRDBMSがあって（ウィキペディアには100以上のリストがある）、ほとんどのものが解決できない問題も多いけど、解決できるものもある。彼らは自分たちの解決策の実用性を考慮して、実装に進んだんだ。

じゃあ、なんでこんなに多くのデータベースエンジンがあるの？それぞれのデータベースのインスタンスはNIHのインスタンスなの？もちろん、答えは、どんな複雑なコンピュータシステムでもトレードオフをしなきゃいけないってことだよね。制約が必要か、スケーラビリティが必要か、同時実行性やセキュリティが必要か？データが特定の形式で、特定の圧縮可能なストレージ形式から利益を得る場合もあるし、書き込み一回読み取り多回の最適化が必要だったり、いろいろあるよね。記事の主旨、つまり依存関係のコストについてだけど、依存関係が自分の依存関係を最小限に抑えようとしているなら、私はその依存関係を受け入れるのがずっと嬉しいんだ。つまり、森のような依存関係を抱えたくないってこと。私の見解では、多くの自動依存関係管理システムが、彼らが解決しようとしている混乱を生み出すのを助けていると思うし、慎重な手動の依存関係管理が負担を減らすのに役立つよ。

RDBMSでは解決できない問題にすぐにぶつかるよ。データセットの同時変更をサポートするように作られているから、すごく制約されてるんだ。もしそれが必要ないなら、かなり単純なインデックス実装でも、データが不変であると仮定すれば、RDBMSよりも桁違いにパフォーマンスが出るよ。

データベース、ゲームエンジン、ウェブサーバー、暗号プリミティブなどについては同じことは言えない。多くの場合、絶対に言えるよ。- 多くのアプリケーションは、ファイルとランタイムインデックスさえあれば、あまり多くのデータベースを必要としない。データベースサーバーを立ち上げたり、SQLiteを埋め込むのは、場合によってはオーバーキルだよ。- 私の意見では、ほとんどのゲームはカスタムのゲームエンジンを使った方がいいと思う、特に小さなチームが作ったものはね。確立されたエンジンを使う唯一の本当の利点は、置き換え可能なアーティストのための慣れ親しんだアセットパイプラインだけど、それには大きなオーバーヘッドがかかる。カスタムエンジン、または少なくともゲーム開発者が維持している大幅に修正されたものが標準だったことを思い出して。最近のトレンドは「Unity^WUnrealを使え」って感じだよ。- シンプルなウェブサーバーとFastCGIアプリケーションの間に複雑さの違いはないよ。- 暗号プリミティブのすべての使用がセキュリティの問題になるわけじゃない。もしデータの破損をチェックするためにハッシュを計算するなら、それを自分で実装することもできるし（既存の実装をコピーすることもできる）、巨大なライブラリを取り込む必要はないよ。既存のデータをオフラインで復号化するのが目的なら、暗号セキュリティはあまり気にしないし、正しく復号化された出力が得られればいいんだ。こういうケースは他にもたくさんあるよ。「難しい」テーマに対する学習された無力感は誰の役にも立たない。既存の解決策があなたの問題を「解決」しているからといって、それが最良または最も効率的な方法だとは限らない。

あなたがどのような責任を持つかについて現実的である限り。トレーニングやオンボーディングも含めてね。「人気」のライブラリや言語、パターンなどが人気である理由があるんだ。ひとつの「勝利」は、タレントを探すときのネットワーク効果だよ。彼らは少なくともジョギングを始めることができるから。

NIHって何？記事をざっと読んだけど、二回読んでもまだ理解できない。Googleによると、国立衛生研究所って出てくるけど。

これは驚くほど洞察に満ちてる、ありがとう。これを今後使う依存関係の手続きファイルにコピーするつもり。唯一の問題は、JavaScriptの世界に見られるような非常に深い依存関係ツリーだね。

4)と5)はすごく重要だけど、しばしば忘れられがち。自分の小さなプロジェクトでも、長期間の休暇から戻ると依存関係が完全に古くなって使えなくなってたり、リポジトリが完全に削除されてたりすることがあった。だから「フォーク」方式を採用したんだ。依存関係のソースをプライベートでフォークして、依存関係をビルドする。これを彼らの依存関係にも再帰的に行って（言語レベルのライブラリで止める）、ビルドチェーンに慣れるためにね。それから初めて、その依存関係をプロジェクトに追加する気になれる（そして彼らの公開されたアーティファクトを使う）。ちょっと手間だけど、この努力は前もってかける価値があると思うし、プロジェクトが長生きすればエコシステムが変わるときに未来の手間を省けるからね（追従したくない時もあるし）。時々、事前にビルドされたバイナリよりもソースライブラリの方が良いと感じることもある。ソースをフォークしてプロジェクトにリンクするだけで済むから、依存関係のビルドチェーンについて学ぶ必要がないし。

5については、フォークするのはちょっとやりすぎかも。フォークを最新の状態に保つのは大きなメンテナンスの負担になるからね。でも、依存関係をベンダリングする（gitやgit LFSに突っ込むとか、キャッシュプロキシを運営するの）は有効だよ。特に長寿命のソフトウェアプロジェクトにはね。NodeJSベースのものにはあまり当てはまらないかもしれないけど、依存関係が小さなファイルをたくさん使うから。でも、YarnやPNPMがあれば、依存関係をもっと便利なアーカイブファイルに保管してくれるよ。

4と5について。少なくとも一度も、全てのコードはネットワークケーブルを抜いた状態でもビルドできるべきだし、できればバイナリアーティファクトなしでね。でも、それが常に可能とは限らないけど。

4については、時々同意するけど、SQLite（や他の似たような依存関係）は、私が作っている製品よりも100%長生きすることを認識しているよ。だから、自分の製品がそれらよりも長生きすると言うのはちょっと傲慢だと思う。依存関係だからってLinuxカーネルを作るつもりはないよ。

開発者の質に関係なくてもいいんだよね。どんなツールチェーンや製品を使っても、他の誰かの依存関係を使ってるわけだし。場所によっては特にそうだけど、大抵の人は自分で行列の掛け算コードを実装してるわけじゃないし、実装してる人も、自分のビジネスに関係ないライブラリ#24を実装することはないよね。だから、この議論は白黒つけたがるけど、実際には人々が気にしてるのは、規制の義務があるかどうか、特定の実装に個人的な興味があるか、特定のライブラリに執着してるかってことだけ。誰もこれを完全に適用してるわけじゃないし、そうだったらまだビーチで砂を集めてるはずだよ。

TigerBeetleを例に出すのはあまり好きじゃないんだ。なぜなら、彼らは非常に新しいスタートアップだから。まだ1.0にも達してなくて、プロダクションリリースからちょうど1年ちょっとしか経ってない。彼らのアプローチが実際に成功したかどうかを判断するには早すぎるよ。

（私はTigerBeetleで働いています）+100、コンテキストが重要だよね。TigerBeetleもrust-analyzerも、物事の進め方に強い文化があるけど、_特定_の文化はかなり異なる。なぜなら、彼らは非常に異なる問題を解決しているから。とはいえ、あなたは依存関係の良い/悪いという議論に少しパターンマッチしているかもしれないし、TFAは別のレベルにあると思う。使われている依存関係の例に注目してみて：POSIX、ECMA-48、ウェブプラットフォーム。これらはライブラリじゃなくて、システムインターフェースだよ！ライブラリへの依存は大したことじゃない --- もしそれが問題になるなら、コードを再実装すればいいだけだ！でも、そのライブラリが行っている基盤となるものへの依存は、通常変更できないか、変更するのが非常にコストがかかる。自分のソフトウェアの範囲内で「Xをすることは可能か？」に「いいえ」と答えるのは強力だよ。兄弟コメントに言及すると、もし行列の掛け算コードを書くことがコアビジネスのチームがあれば、彼らはライブラリ#24を他の目的で使うことができるけど、しばしばソフトウェアデザインを適用すると、行列の掛け算を取り巻く製品は#24の問題を扱うべきじゃないって気づくかもしれない。#24の問題が全く扱われていないわけじゃなくて、むしろ全体のシステムをより良く分割して、重要な依存関係を区分けしようとしているんだ。

ここに著者がいるよ！TigerBeetleを指摘したのは、彼らが依存関係についての哲学を持っていて、かつそれを簡単に引用できる文書でオープンに話している数少ない会社の一つだから。成功したかどうかはわからないけど、「依存関係」という言葉を非常に広い意味で使いたかったんだ。ライブラリやサービスだけでなく、構築やデプロイに必要なものも含めてね。単に依存関係を使わないようにという呼びかけではなかったんだ。依存関係について考え、何に依存しているのかを明確にすることを呼びかけたんだ。TigerBeetleはそれを実践して、理由を示しているよ。

でも、平均的な開発者は、ほとんどの業務用CRUDシステムを書いているわけで、正直言って、最初からそんなに強くないんだよね。これはちょっと過激な意見だね。開発者は通常、自分が働くシステムを選ぶことはできないし、開発中にはリソースの制約がある。私たちは毎日トレードオフの決定をしていて、「安い」依存関係を取り込むことが、出荷される動作するソフトウェアと単なる「何もない」の違いを生むことが多いよ。あなたのこの意見は、かなり一般的で間違っているように見えるから、実際のソフトウェア開発にあまり関わっていないように感じるよ。

この考え方に対する俺の問題は、底辺の開発者についてだけ通用するってことだよね。技術の世界って、最低限のレベルに合わせてアドバイスを簡単にしがちだけど、正直言って、俺はそんな環境で働いたことない。開発者がクソみたいな依存関係の機能を複製しながら問題を解決できないなんてことはないと思うし。CRUDを馬鹿にするのが好きな人も多いけど、悪い抽象化はCRUD作業をしているチームにとっては本当に厄介な負担になることもあるよ。人気のあるものでも、基本的なことを繰り返すだけのチュートリアルをやっている限り、時間の無駄になることが多いしね。