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

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

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

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

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

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

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

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

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