見出し画像

「Enterprise版にしかない」で諦めない。OSSをforkして必要な機能を足す選択肢が、コーディングエージェントで現実的になった

suwa-sh / 諏訪真一

「この機能はEnterprise版にしかない」「OSSプラグインを探したけど、どれも痒いところに手が届かない」。OSSミドルウェアを採用しようとすると、よく当たる壁です。これまでは、ここで予算交渉に切り替えるか、機能要件を諦めるかの二択になりがちでした。最近、第三の選択肢が現実的になってきたと感じています。OSSをforkして、足りない機能を自分で書き足す道です。コーディングエージェントが普及したことで、そのコストが昔とは別物になりました。

OSSミドルウェアを選ぶと、必ずぶつかる壁

APIゲートウェイのKongを例に取ります。OSS版を選ぶプロジェクトは多いのですが、認証まわりで壁にぶつかります。

  • OpenID Connectの公式プラグインはEnterprise版限定

  • セッション管理プラグインとOIDCを連携させる仕組みもEnterprise版限定

  • コミュニティ製のOSSプラグインは複数あるが、要件を完全には満たさない

似た状況は、Kong以外のOSSでも何度も経験しました。「コアは無料、運用に効く機能は有料」というのは、OSSビジネスとしては当然の戦略です。利用側としては、その線引きの内側で諦めるか、Enterpriseライセンスを買うか、自前実装するかの判断を迫られます。

「惜しい」OSSをforkして完成させる

第三の道が、OSSプラグインのforkです。コミュニティ製プラグインのソースを読むと、「ここまで動く、でもここから先は誰も書いていない」という境界線が見えます。その境界の少し先を自分のリポジトリで書き足す。Enterprise版を再実装するのではなく、コミュニティが途中まで進めた実装を、自分のユースケースに合わせて完成させる感覚です。

実際にKongのOIDCプラグインで試した結果が、公開しているこちらです。

  • リポジトリ:

なお、本家OSSにPull Requestを送る選択肢も検討しました。今回見送ってforkを選んだのは、次の理由からです。

  • カスタマイズの方向性が、本家のスコープと完全には一致しなかった（自分のユースケースに寄った仕様）

  • 本家のレビュー・マージ・リリースのライフサイクルを、こちらのプロジェクト都合で動かせない

  • forkして自分のリポジトリで管理するほうが、改修と利用のスピードが揃う

PRで本家に取り込んでもらえれば理想ですが、適用ライフサイクルが状況に合わないなら、自分のforkで完結させる判断もあります。本家に還元できそうな汎用的な改善が育ったら、そのときPRに切り出す。順序を逆にしてもよいわけです。


コーディングエージェントが、forkのコスト構造を変えた

forkして機能追加する選択肢は昔からありました。ただ、現実にはハードルが高かったのです。

  • マイナーな言語で書かれている（Kongのプラグインはlua）

  • 既存実装の構造を読み解くのに時間がかかる

  • 改修後のテストとビルド環境を整える手間が大きい

  • メンテナンスを自分が引き継ぐ覚悟が要る

このうち最初の3つは、コーディングエージェントが急速に下げてくれました。luaの構文を逐一覚えなくても、エージェントに既存コードを読ませて差分を書いてもらえます。テストの雛形もエージェントが用意してくれます。「知らない言語で書かれた他人のコードに手を入れる」という、これまで一番重かった作業が、軽くなりました。

「メンテナンスを引き継ぐ覚悟」だけは、本質的に変わりません。fork元のアップデートを追うか、自分のリポジトリで止めるかの判断は残ります。ただ、その判断を含めても、機能を諦める・予算交渉するに比べて選択肢として釣り合うようになってきています。

判断の軸

OSSミドルウェアで「Enterprise版にしかない」「どのOSSも要件を満たさない」に当たったとき、forkを検討する判断軸は次のあたりです。

  • コミュニティ製OSSの中に、機能の方向性が合っている「惜しい」実装があるか

  • 足りない部分の規模感はどれくらいか（数百行で済むか、ゼロから書くレベルか）

  • ライセンスがfork・改変・再配布を許しているか（MIT / Apache 2.0 / GPLなど）

  • 自分のチームで最低限のメンテナンスを続けられるか

ライセンスは特に大事です。fork前に必ず確認します。KongのOSSコアと多くのコミュニティプラグインはApache 2.0なので、改変も再配布も問題ありませんでした。

諦める前に、forkを試算してみる

「Enterprise版にしかない」と判断した瞬間、機能要件を削るか予算を増やすかに思考が引きずられがちです。一度立ち止まって、forkで越えられる壁ではないかを試算してみる価値はあります。コーディングエージェントを使えば、最低限の調査は半日で終わります。「OSS実装を読んで、足りない部分の見積もりを出す」という作業を、エージェントに依頼してみる。それだけでも、選択肢の幅は変わってきます。

OSSの世界は「使う」と「作る」の境界が曖昧です。境界の越え方が一つ増えたという意味で、コーディングエージェントの恩恵をもっとも受けているのは、この領域かもしれません。


いいなと思ったら応援しよう！

suwa-sh / 諏訪真一 いつも応援していただいている皆さん支えられています。