（結論はなく、ダラダラ昔話を書いただけ。）
サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。
OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。
ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。
ところが実際のところ、OSSは他者が思うよりもずっと簡単にその命を終える。これまで自分が見てきた実例だけでも、
- 開発者が技術やソフト自体を使わなくなって放置
- 転職して忙しくなった
- 家庭の都合（結婚した、お子さんが生まれたとか）
- 病気や事故、あるいは逝去した
- 失業した
- 犯罪を犯した（殺人で刑務所行きとか、政治犯扱いになったとかも……）
- チーム内で意見が対立した
- ユーザーのエスカレーションする要求にうんざりした
- ネットからの批判にやる気を失った
- セキュリティ警察に萎えた
まぁいろいろあるね。モチベーションの失われたOSSプロジェクトに対し、「引き継ぐよ」と善意を装った者がマルウェアを仕掛けたりする例もある。善意ベースのパッケージシステムは、乗っ取られてマルウェアの巣になりやすい。
さて、こういうOSSの状況にどう対処したらよいのかというのは難しい。
全部自身で実装する。 私自身は言語バンドルライブラリ以外は極力避けたい派で、自作プロダクトではこれを指向しているけれども、大規模なサービスやプロダクトでは現実的でないことも多いだろう（GoやNode.jsなどモダンな言語ではバンドルは最小限方向だし）。
サービス内容とOSSコンポーネントの役割を理解し、いざというときの代替を探しておく。 まぁこれは業務だったら当然考えてるよね（よね？）というところだけど。部品に限らず、スタートアップの速度重視からスケール対応重視のフェーズになっていったときにもう言語スタックから全部別ので作り直したほうがよいのでは、というケースもあるだろう。
OSSが継続できるようメンバーにジョインする。 死んだらforkで済ませればいいというのはまぁそうなんだろうけど、中の人になっておいたほうが様子はわかるし、活動していればOSSの中身自体の理解も進む。昔は必死にひどい英語モドキでやりとりするしかなくて「お前が何を言っているかわからない」という返答に枕を濡らしていたけれども、今はGoogle翻訳もDeepLもあって最高（あと、そもそも若手皆さん英語できるね……）。いずれにせよ、「全部実装」よりは軽いのではないか。
OSSを支援する。 ジョインはちょっと重いなーというときには、あとはなんとかOSSが死なないように支援する。対処できることはOSSが死ぬケースのうちのごく一部にはなるけどね。理由が金銭的困窮であればGitHub Sponsors、あるいは商業ライセンス購入（デュアルライセンスが用意されていればやりやすい）などが考えられるか。個人的には開発者会議の会場スポンサーは援助としてありがたかった。
ということでオチはないけど、最近の開発風景を見ながら。
