knqyf263's blog

自分のためのメモとして残しておくためのブログ。

OSSをベースにしたサービス提供の難しさ

背景

弊社（Aqua Security）ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。

speakerdeck.com

フルタイムOSS開発者をやってみての感想なども昔書いています。

knqyf263.hatenablog.com

今回はOSSをベースにしたサービス提供の難しさについて最近感じていることをまとめておきたいと思います。 こういうビジネスをしているのは弊社だけではないので同じような話はきっと既にどこかで語られていると思うのですが、愚者は経験に学ぶということで実際に自分で体験してみての感想です。 巨大企業がサイドプロジェクトとしてOSSを開発しているとか、企業内で使うツールチェーンの改善をしているという話とは違い、OSSでより直接的にビジネスをやる場合の話です。

最近会社では連日この辺りの議論しており自分でも観点を手元でまとめていたのですが、ちょうどOSSビジネスについてのブログが公開されていたので自分も公開しておきます。

note.com

弊社のビジネスモデルは上記ブログで挙げられている以下に該当します。クラウド以外でも提供しているのでOSSを組み込んだサービスという感じです。

では、大きな利益を得るためにはどうすればよいのだろうか？

一部の企業は、製品をオープンソースとして提供しつつ、それをクラウドでサービスとして提供することで売り上げを上げている。オープンソースで>直接稼ぐのではなく、オープンソースを使って稼いでいるわけだ。

難しさ

まずどういった点に難しさを感じているかをざっくばらんに書いておきます。 タイトルにもある通り基本的には難しさを書いているだけで、特に解を持ち合わせているわけではないことを初めに断っておきます。

利益相反になりがち

OSS開発を頑張りすぎると、有償版を使う理由がなくなっていきます。 つまり上のブログでもサポート契約のところで述べられていますが、ソフトウェアの品質を上げすぎると利益が減ることになります。 自分は Trivy というOSSを開発しているのですがお客さんから「Trivyで十分」と言われてしまうことが既に何度も起きてしまっています。 もちろん有償版にしかない機能も多数あるのですが、お客さんがお金を払ってでも使いたい機能というのが有償版に存在しない限りOSSから移行してもらうのは難しいです。 弊社のサービスはOSSと全く関係ない機能も多数提供しているため会社のビジネスとしては問題ないのですが、あくまでOSSをきっかけに有償版に繋げるのが難しいという話をしています。

またTrivyの場合は特殊な事情を含んでおり、元々 個人で開発 していたものが企業に買収されたため、買収時に既にある程度のクオリティに達してしまっていたという点と、元々OSSで世界をセキュアにすることを目標に始めたため無邪気にOSSを便利にしすぎたという点があります。 会社が利益を上げられなければOSS開発も続けられないため、ここは正直自分のミスだったなと反省しています。

と書いていて自分でもOSSフルタイム開発者がレイオフの対象になってしまうのは経営の観点で見ると仕方ないような気がしています。

全力で楽しいことをやらせてもらっているので、ある程度のリスクを取ることになるのは仕方ないと割り切っています。

追記：Red Hatではそんなことないよ、と教えていただいたのでどうやってそういう文化を獲得したのか興味がありますね。

競合OSSの存在

じゃあ機能を足さなければ良いのかというとそう単純な話ではないです。 上の発表スライドにも書いたようにOSSを通じて会社の知名度や信頼性を向上させる必要があります。 ということは単にOSSをやっているだけでは意味がなくて、ある程度使われるものを作る必要があります。 機能がスカスカなOSSを作っても誰にも使ってもらえないですし、競合のOSSが存在する場合はユーザがそちらに流れてしまいます。 つまり競合に対して優位性を保てる程度の機能追加をしつつ、有償版の利益を損なわないギリギリのラインを見極める必要があります。

以前 世界一になった という話を無邪気に書いたわけですが、もっときちんとそのラインについて考えるべきでした。

2年前のグラフがこれで

現在がこれです。

明らかにやり過ぎで、とにかく良いものを作りたいと思考停止になっていました。 これでも会社の指示には従っていたのですが、もっと自発的に色々と案を出すべきでした。 インフルエンサーとかを見ていて人さえ集めてしまえばなんとでもなるだろう（実際にはインフルエンサーもそんなことないのだろうと思います）みたいな安易な考えをしていたのも良くなかったです。

コミュニティからのPull Request

企業がOSSを公開する利点の一つとしてコミュニティの協力があります。 自社でリソースを割かなくてもコミュニティの有志により新機能が開発されていくことが多々あります。 これは会社にとって有益な一方で、上に述べたようにOSSに追加したくない機能もあり、そういう機能追加のPull Requestが来ることもあります。

もちろん会社主導のOSSなので断れば良いわけですが、そこの理由説明が難しい場合があります。 「この機能は受け入れたのにこの機能は何で受け入れないんだ？！」と一貫性のなさを指摘されてウッとなったことが何度もあります。

競合サービスによる利用

OSSなので他社が組み込んで有償サービスを提供しても問題ないわけですが、そっちの方が売れたりするとさすがにモヤッとします。 弊社はイスラエルの企業でイスラエルには多数のサイバーセキュリティスタートアップが存在します。 そしてその企業の多くでTrivyが使われています。 これはドキュメントなどで明言している場合もあれば、ローカルコミュニティの口コミで知っている場合もあるのですが、とにかく多くの企業に利用されています。 その中には弊社の時価総額を上回っているスタートアップもあり、社内で問題となっています。

最近だとMicrosoftやRed Hat, DatadogやElasticからのPRが増えていて、エンドユーザよりは弊社OSSを組み込んでサービスとして提供している会社からの貢献が大きいです。 もちろんありがたいのですが、一方でこれらは彼らのサービスをよりよくするためのものであり、気軽に受け入れることで競合を強くしてしまうという懸念もあります。 そういった機能追加がどの程度弊社の利益に寄与するかを考える必要があります。

レベニューシェアにならない

とあるCLIツールがセキュリティ機能を統合したのですが、この際に他社の商用製品を使っていました。 弊社のOSSの方が性能良いのになぜ他社の、しかも商用版をわざわざ使ったのだろうと不思議だったのですが、これはその商用版の契約が取れた場合に収益を還元する契約になっていたためでした。 ビジネスに疎かった自分としては盲点で、もっと純粋にOSSとしての完成度で競っているつもりでいました。 しかし実際にはもっと大人の世界があり、その中のロジックで選定されていました。 OSSだと確かに無料で導入出来る一方で1円も利益にはならないわけで、収益を分配できるビジネスモデルがあるならそっちを選ぶというのは納得です。 ただ良いOSSを作っていればよいわけではないのだなと個人的にはかなり大きな学びでした。

ちなみにその商用製品はやはり品質がイマイチで、その後に一時的にTrivyに切り替えていたりしました。 しかしレベニューシェアのビジネスモデルの旨味は大きく結局元の鞘に収まりました。 弊社も前からそういうモデルを構築しておけば良かったのですが、やや手遅れという感じでこの辺もきちんと考えてやらないとチャンスを逃します。

利用統計が取れない

OSSを使ってくれていたのに商用版に切り替えるタイミングで他社が選ばれてしまうということがあります。 事前にOSSを使ってくれていることを知っていれば営業などもやりやすいのですが、勝手にそういうデータを取得するOSSは嫌われがちです。 そのため基本はどこが使ってくれているか知らないのですが、弊社OSSを使っていることを偶然知ったおかげで契約に繋がったケースもあります。 ですがそういった事例はあくまで偶発的で、もっと能動的にデータが取れないと継続するのは難しいです。

やっておくべきこと

上述した難しさを踏まえ、前からやっておけばよかったなと思うことや今からでもやっておくべきだなと考えていることを書いておきます。 ただし絶賛模索中でして、これやれば万事解決！！みたいなのは全く無いです。 これをすれば少しでも良くなると思っているという話です。

お金を払いたい機能を見極める

どの機能ならお金を払ってくれるかという見極めは重要です。 上にも書いたようにOSSがスカスカだと意味がないので必要最低限の機能は備えつつ、かゆいところに手が届かない設計にする必要があります。 これはOSSに限らず最近のクラウド系サービスは無料機能と有料機能で分かれているので（無料なら直近90日の履歴だけ見られます、とか）自分が語るようなものでもない気がしますが一応触れておきます。

境界線を決める

これはOSSベースのサービスにおいては重要だと思います。 例えば大規模運用のための機能は有償版のみ、のような境界線を事前にきちんと定義しておく必要があります。 そうしないと上で説明したようにPRを受け入れる、受け入れない、の説明が難しくなります。 実装が簡単だったのでシュッとOSSに追加した機能が、実は有償版にとって重要だったみたいなことも起こります。

事前に明確に境界線を定義しておけばそういった間違いも起こりにくくコミュニティへの説明もしやすいです。

ライセンスについて考える

競合に使わせたくないということであればライセンスで商用サービスを制限することも候補に上がると思います。

www.itmedia.co.jp

こういったライセンスにすると厳密にはOSSではなくなってしまうわけですが、OSS原理主義者以外はそこまで気にしてないと思っています。 それよりも企業が存続できてOSS開発を継続できることのほうがエンドユーザにとっては重要なはずです。 また、ある程度経ってからライセンスを変更するのは難しいので最初からOSS戦略に組み込んでおくと良いと思います。

利用統計の取得方法について考える

勝手にデータを取得したりすると嫌がられるわけですが、オプトインの形で許諾を得れば問題ないよという企業やユーザも少なくないはずです。 OSSを使っていることを積極的に外部発信はしないが聞かれたら普通に答える企業は多いので、不快感なく利用統計が取れれば大きなアドバンテージになります。 そういったデータを使って営業するのはネガティブな印象もありますが、OSSでは機能が不足して困っているのに有償版の存在を知らなかったユーザも見かけているので、まず知ってもらうことは大事かなと思います。

OSSから有償版へのスムーズな移行を考える

これもTrivyの場合は個人で開発したOSSがあとから企業に組み込まれた背景が影響しているのですが、せっかくOSSを使ってくれていてもそこから有償版に切り替えるのが現状あまり容易ではありません。 ここの体験は非常に重要なので最初から設計に組み込んでおくべきです。

この辺がスムーズになっていれば他社サービスにまずOSSを組み込んでもらって有償版に繋がったら利益分配のような形も提案しやすいですし捗ると思います。

まとめ

難しさを書きましたが、事前にしっかり準備することで回避できることも多いと思います。 絶対的な答えを持ち合わせていなくて恐縮ですが、賢者は歴史に学ぶということで少しでも誰かのためになることを祈ります。

難しいということを共有しましたが、あまりネガティブな話をしているつもりはなくて挑戦的で楽しいなと思っています。 何も考えずに（もちろん会社としては色々と考えているので自分個人の話です）進めるとうまくいかないので戦略が必要という当たり前の話でした。

ビジネスは難しい。