さて、こういうOSSの状況にどう対処したらよいのかというのは難しい。
全部自身で実装する。 私自身は言語バンドルライブラリ以外は極力避けたい派で、自作プロダクトではこれを指向しているけれども、大規模なサービスやプロダクトでは現実的でないことも多いだろう（GoやNode.jsなどモダンな言語ではバンドルは最小限方向だし）。
サービス内容とOSSコンポーネントの役割を理解し、いざというときの代替を探しておく。 まぁこれは業務だったら当然考えてるよね（よね？）というところだけど。部品に限らず、スタートアップの速度重視からスケール対応重視のフェーズになっていったときにもう言語スタックから全部別ので作り直したほうがよいのでは、というケースもあるだろう。
OSSが継続できるようメンバーにジョインする。 死んだらforkで済ませればいいというのはまぁそうなんだろうけど、中の人になっておいたほうが様子はわかるし、活動していればOSSの中身自体の理解も進む。昔は必死にひどい英語モドキでやりとりするしかなくて「お前が何を言っているかわからない」という返答に枕を濡らしていたけれども、今はGoogle翻訳もDeepLもあって最高（あと、そもそも若手皆さん英語できるね……）。いずれにせよ、「全部実装」よりは軽いのではないか。
OSSを支援する。 ジョインはちょっと重いなーというときには、あとはなんとかOSSが死なないように支援する。対処できることはOSSが死ぬケースのうちのごく一部にはなるけどね。理由が金銭的困窮であればGitHub Sponsors、あるいは商業ライセンス購入（デュアルライセンスが用意されていればやりやすい）などが考えられるか。個人的には開発者会議の会場スポンサーは援助としてありがたかった。