- オープンソースのルネッサンスは進行中
- フリーからSaaSまでのオープンソースの歴史
- オープンソースの好循環
- Business Success Centersを支える三本の柱
- 事業モデルの選択
- クラウドと競争の壕 (moat)
- 市場開拓——オープンソースはファネルのトップ
- 成功と失敗はどのような姿をとるか
- OSS 3.0 – オープンソースはすべてのソフトウェア会社の構成要素の一つです。
編集後記——オープンソース・ソフトウェア(OSS)の進展により、オペレーションシステムやウェブブラウザ、デーアベースなど、最も重要で広く利用されているテクノロジーがいくつも作り出されてきました。OSSなしでは、私たちの世界は全く機能しないでしょう。少なくとも、今ほどうまくは機能していないはずです。
オープンソースが驚くべき技術的なイノベーションをもたらしてきた一方、ビジネス面でのイノベーション(直近で最も注目すべきものとしてSaaS)は、OSSの進展の成功にとって、同じぐらい不可欠な存在であり続けています。そして、オープンソースは、定義上、誰でもフリーで利用でき、修正でき、配信できるソフトウェアであるため、オープンソース事業には、他の種類のソフトウェア企業とは違うモデルや市場開拓が必要になってきています。
Peter Levineは開発者、起業家、投資家として、30年以上、オープンソースを扱って仕事をしてきました。彼は最近、“Open Source: From Community to Commercialization” という講演を行いました(発表の全体をここからダウンロードできます)。彼はその中で、自分の体験に加えて、オープンソースの専門家との何十件ものインタビューを引き合いに出しました。下記に挙げるのは、その発表を書き起こしたものです。その中でPeterは、OSSの増加を追跡し、オープンソース・プロジェクトの事業を成功に導くための、実用的なエンド・トゥ・エンドの枠組みを提示しています。
—
オープンソースはマイナーな活動として始まりましたが、その後、ソフトウェア開発の中心になっていきました。 オープンソースの初期の頃からの逸話で、私のお気に入りの一つは、電子メールの受信をユーザーに知らせるLinux/Unix command [~}$ BIFFに関するものです(当時、オープンソースは単なる「フリーソフトウェア」で、呼び名すらありませんでした)。このコマンドの名称は、バークレーのヒッピーが飼っていた犬に因んでいます。その犬は、郵便配達員が来ると、いつも外に出て行って吠えていました。私はこの話が好きです。初期の頃のオープンソースは、重要なコマンドが開発者の飼い犬に因んで名付けられるほど、マイナーなものだったことがうかがえるからです。
私は、MITのProject AthenaやOpen Software Foundationの開発者として、また、オープンソース企業であるXenSource社のCEOとして、何十年もオープンソースに携わってきました。そして、ここ10年間は、オープンソースを扱ういくつもの会社の取締役会の一員です。私は、開発者から取締役会の一員まで、それぞれの立場でオープンソースの進化とオープンソース・プロジェクトを土台にした大企業の成長を目の当たりにしてきました。
オープンソース事業を立ち上げるのに、これほど適した時代はこれまでなかったと心の底から信じています。ビジネス面でのイノベーションは、オープンソースの進展にとって不可欠です。そこでわたしは以下で、オープンソース製品を市場に出すための枠組みを提示したいと思います。
オープンソースのルネッサンスは進行中
過去10年間は、オープンソースにとってはルネッサンスでした。上掲のグラフは過去30年間を表したものです。 その期間の間に、約200社がオープンソースを中核テクノロジーとして創業しました。これらの企業は、あわせて100億ドル以上の資金を調達しており、過去10年間では、さらに大きな取引に向けたトレンドがみられます。実際に、これらの企業の4分の3と、資金調達の80%は、2005年より後に実現しました。私たちはこのルネッサンスのまさにスタート地点に立っていると思います。
これらの投資はさらに大きなIPOやM&A取引に結びつきます。
2008年にOracleがMySQLを10億ドルで買ったことは注目に値する興味深い出来事です。私は当時、10億ドルという額は、それまでのオープンソースでは最高額だと確信していました。10億ドルは、オープンソースを商品と考えていたソフトウェア産業によって、途方もないイグジットと見なされましたし、何年もこれを超えるものはありませんでした。
けれども、ここ数年に起こったことに注目してみましょう。Cloudera社やMongoDB社、Mulesoft社、Elastic社、GitHub社は、何十億ドルものIPOやM&A取引に参加しました。 そして、もちろん、RedHat社があります。同社は、1999年に36億ドルで上場し、今年、IBM社に340億ドルで売却されました。今後、最高額が再び更新されることを楽しみにしています。
オープンソースはそれだけでなく、ソフトウェアのさらなる領域へと拡大しています。従来は、OSSはほとんどが企業インフラを中心に開発されていました。例えば、LinuxやMySQLなどのデータベースやオペレーティングシステムなどです。現在のルネッサンスで、積極的なOSS開発は、Fintechや電子商取引、教育、サイバーセキュリティなど、ほぼすべての業界で行われています。
このルネッサンスの背景には何があるのでしょうか。それを理解するために、昔懐かしい思い出と、オープンソースの歴史を辿らせてください。
フリーからSaaSまでのオープンソースの歴史
オープンソース0.0 – 「フリーソフトウェア時代」
オープンソースは1970年代半ばに始まり、プログラマーである私は、この時代を0.0と呼びます。「フリーソフトウェアの時代」です。研究者と趣味に熱中する人々がソフトウェアを開発しました。そしてそれは、次のような精神に貫かれたものでした——ソフトウェアをフリーで提供しよう。ARPANET(高等研究計画局ネットワーク)がインターネットにとって代わられるに伴い、ネットワークによって共同作業とコードの交換が著しく容易になりました。
MITやOpen Software Foundationに勤務し、仕事をしていた当時、私の給料がどこから払われているのかが全くわかりませんでした。事業モデルの概念は全くなく、「フリーソフトウェア」開発の背後にある資金は、もしあれば、大学または企業の研究助成金という形をとっていました。
オープンソース1.0 – サポートとサービスの時代
1991年にLinuxが登場し、オープンソースは企業にとって重要になり、中核となるソフトウェア・テクノロジーをよりよく、より速く開発する方法であることを証明しました。 基本的なオープンソース・テクノロジーが増えれば増えるほど、オープンソース・コミュニティおよびオープンソース企業は商業化を試みるようになりました。
1998年にOpen Software Initiativeが「オープンソース」という用語を作り、その頃に、RedHatやMySQL、その他の多くがフリーソフトウェアに乗せて、有料のサポートやサービスを提供したことで、初めての現実的な事業モデルが登場しました。私たちが、このような組織の開発を支援する現実的な経済モデルを目にしたのはこれが初めてでした。
当時について他に注目すべきこととしては、オープンソース・ソフトウェア企業の価値がプロプリエタリ・ソフトウェア企業と比較して見劣りしていたということがあります。RedHat社とMicrosoft社との対比、MySQL社とOracle社との対比、XenSource社とVMWare社との対比で見ると、クローズソースのソフトウェア企業の価値は、オープンソースのそれを、はるかに上回っていました。業界はOSSを、プロプライエタリ・ソフトウェア企業が持つ潜在的な経済価値に匹敵するような価値はとても実現できない商品とみなしていました。
オープンソース2.0 – SaaSとオープンコアの時代
2000年代半ば頃には、そのような評価が変化し始めました。クラウドコンピューティングが小さな突破口を空け、企業はオープンソースSaaSを運営することができるようになりました。ひとたびクラウドでオープンソース・サービスを提供することができれば、 ユーザーは、その内部でオープンソース・ソフトウェアとプロプライエタリ・ソフトウェアのどちらが使用されているのかわかりませんし、またわかっていても、それを気にしません。これにより、オープンソースはプロプライエタリと同じぐらい評価されるようになり、オープンソースには実際に具体的な経済的、戦略的な価値があることが指し示されました。
またこれに加えて、一連の買収により、オープンソースは、大手ハイテク企業の構成要素の鍵にもなりました。そこにはSun社やその後のOracle社によるMySQLの買収は言うまでもなく、Citrix社による、私自身のスタートアップであるXenSource社の買収などが含まれます。2001年に、Microsoft社のSteve Ballmer CEOはLinuxを「癌」と呼びました。今では、Microsoft社でさえ、テクノロジーのスタックでオープンソースを使い、オープンソース・プロジェクトへの貢献に大きく投資しています。その結果、次のオープンスースのスタートアップは、大学の研究所または開発者のガレージから生まれるのと同程度に、主要なハイテク企業から分社化する可能性があります。
オープンソースの好循環
オープンソースの歴史を見ると、その拡大が、テクノロジーと事業革新の好循環によるものであることは明白です。技術的な観点から見た場合、オープンソースは、ソフトウェアの作成の最高の方法です。なぜなら、オープンソースは、製品フィードバックや革新の速度を上げ、ソフトウェアの信頼性を高め、サポートを拡大し、採用を促し、技術的な人材を蓄えるからです。オープンソースはテクノロジー駆動型モデルであり、これらの性質は「フリーソフトウェア」時代からありました。
しかしながら、オープンソースの可能性が完全に発揮されるのは、テクノロジーの革新が商業的革新と一緒に起こる場合のみです。有料のサポートやOpen Care、SaaSモデルなどの事業モデルがなくては、オープンソースのルネッサンスはありませんでした。
経済的な利益が好循環または弾み車を生みます。事業革新があればあるほど、開発者コミュニティは大きくなり、それによってテクノロジーの革新に拍車がかかり、オープンソースの経済的報酬が増加します。この講演の終わりには、私がオープンソース3.0の未来をどのように考えているかをお話し、 現在、テクノロジーと事業の両方の側面で起こっている興味深い革新のいくつかを指摘します。
けれども、まずはオープンソース事業の構築方法について話しましょう。
Business Success Centersを支える三本の柱
オープンソース事業の成功の理由は三本の柱にあります。最初、これらの要因は、ひとつの要因が別の要因を引き起こすといったように、段階的に展開されます。成熟した企業では、持続可能な事業に向け、それらの要因を柱として維持し、均衡を保つ必要が出てきます。
- プロジェクト・コミュニティ・フィット。オープンソース・プロジェクトが、オープンソース・コードベースに活発に貢献している開発者のコミュニティを形成します。これは、GitHubのスター、コミット、プルリクエスト、貢献者の増加などの指標で測定できます。
- プロダクト・マーケット・フィット。皆さんのオープンソース・ソフトウェアが、ユーザーに採用されます。これはダウンロードと利用状況を指標として測定できます。
- バリュー・マーケット・フィット。顧客が支払いたいと思う価値命題を見つけます。ここでの成功は、収益を指標として測定されます。
会社が存続している間に、三本柱のすべてが、どこかの時点で実現されている必要があります。実現のタイミングは、それぞれに測定可能な対象があるかどうかでわかります。
プロジェクトコミュニティフィット
第一の柱は、プロジェクトコミュニティフィットで、望ましい結果が得られるコミュニティの規模と、開発者のプロジェクトの牽引力に関わるものです。OSSコミュニティの規模はそれぞれに異なりますが、熱烈なファンや増大する人気は、OSSプロジェクトが開発者グループの強い関心を引くことができているかを示す、重要な指標です。こうした指標には、GitHubのスター、協力者の人数、プルリクエストの数などが含まれます。
オープンソース・プロジェクトは、大手企業や大学の中など、多くの場所で始めることができます。しかし、プロジェクトが始まる場所はあまり重要ではありません。むしろ、厳しい仕事を進めるプロジェクト・リーダーがいるかどうかの方が重要です。そのプロジェクト・リーダーは、通常は、商業法人のCEOになります。
プロジェクトコミュニティフィットに到達するには、触れ合いの多い信頼関係と、開発者コミュニティの継続的な承認が必要です。優れたプロジェクト・リーダーは、メンバーの包摂と、リーダーとして主張を行うことの間の、絶妙な均衡状態を達成する必要があります。すべての人間の声を聞き、貢献が認められている状況で、プロジェクトの方向性を明確に決定します。この均衡状態が達成されると、プロジェクトは健全な成長を続け、より多くの人がプロジェクトに貢献し、プロジェクトを共有します。
投資家として私たちは、OSSのプロジェクト・リーダーに融資する方向にかなり偏っています。なぜなら、彼らはコードベースを知り尽くしており、開発者コミュニティを支えるプロジェクトの精神とビジョンを支える存在だからです。
プロダクトマーケットフィット(PMF)
ひとたびプロジェクト・リーダーと活発な協力者グループを獲得すれば、次の局面は、PMFを把握し、評価することです。この過程では、プロジェクト・リーダーは次のことを明確にしなくてはいけません。オープンソース・ソフトウェアが役立って解決する問題はどのようなものか。誰のために問題を解決するのか。市場における代替案はどのようなものか。自社のユーザーと彼らの利用事例を把握しなければ、プロジェクトは多方向に引っ張れられ、失速します。
上記の質問に答えが出た時、皆さんは、広告の関与なしでサービスが採用されているのを目の当たりにするでしょう。これは、ダウンロード数によって測定されます。PMFは、後の営業活動における継続的な信頼関係の前触れです。うまくいけば、OSSユーザーは、付加価値のついた製品やサービスについて、ファネルの最初期段階の見込み客になります(付加価値のついた製品やサービスについては、市場開拓のセクションでもっと詳しく説明します)。
PMFに取り組むのと並行して、何が自社の商用製品の特徴となっているのか、どのようにして人がお金を使いたいと思う価値を提供するのか、という点について考えることが大切です。私が注意を促しておきたい一般的な落とし穴は、OSS製品が時として、あまりに優れすぎているということです。PMFは、バリューマーケットフィット (value-market fit) が不要なほどに、すばらしく優れているかもしれません。つまり、収益を左右するほどの拡大は自然に起こらないということです。結果として、皆さんと皆さんのコミュニティは、オーガニックなサービスの採用を促す一方で、将来的に何を商業化できるのかを慎重に検討すべきです。
バリューマーケットフィット
最終段階は、往々にして最も困難ですが、バリューマーケットフィットを模索し、収益を生むことです。PMFが個人のユーザーに生じる一方で、バリューマーケットフィットは、一般的には、部門別の企業の買い手が中心となります。 バリューマーケットフィットの秘訣は、皆さんが資金化できるものではなく、顧客が何を気にかけているか、何にお金を使いたがっているかに重きを置くことです。
バリューマーケットフィットは、製品が何をするかではなく、むしろ、製品がどのようにして採用されるか、またそれがもたらす価値の種類に左右されます。OSSが提供する価値は、その機能性だけではなく、業務運営上の利点と大規模な特性です。ですから、商用提供を検討する際に、次のようないくつかの疑問を考慮すべきです。自社製品は事業の主要な問題を解決しているか? あるいは、業務運営上の明確な利点を提供しているか? 複製は難しいか? あるいは、代替品は見つけにくいか? チームや組織に必要な、いまだ実現されていない大規模な能力を、OSSは備えているか?
これは完全な一覧ではありませんが、オープンソース・ソフトウェアの会社は以下のような特性に焦点を当て、バリューマーケットフィットを見出してきました。
- RAS(信頼性、利用可能性、セキュリティ)
- ツール、アドオン
- 性能
- 監査
- サービス
事業モデルの選択
皆さんが選択する事業モデルは、結局のところ、皆さんが顧客にどのような価値を提供するか、また、最善な提供方法はどのようなものかによって決まります。このような事業モデルは排他的なものではなく、複数のモデルの要素を持つ異種混交式事業を構築することも可能であると念頭に置いておくことが重要です。
Support and Serviceは、オープンソース1.0時代のモデルです。RedHat社は、この分野での市場を独占し、成長を達成しました。この道を行くのであれば、RedHat社と競争することになる可能性が高いです(5年前に私がブログの投稿で“Why There Will Never Be Another Red Hat: The Economics of Open Source”を書いた理由はこれです)。
Open CoreモデルはOSSの上に価値を付加したプロプライエタリ・コードの層を重ねたもので、自社運用型ソフトウェアの優れたモデルです。オープンソースの採用を損なうことなくプロプライエタリを維持することのできる非常に重要なコンポーネント(セキュリティや統合など)があるのであれば、Open Coreはよいモデルになるでしょう。注意すべき点として、Open Coreでは、どの特性がどのコードに属するかを決定するときにコミュニティの疎外が問題になる可能性があります。私は自社でそれを目にし、コミュニティの適切な較正は非常に重要だと知りました。ここでの究極的な落とし穴は、皆さんのコミュ二ティがプロプライエタリ側の皆さんの行動を好ましくないと判断し、プロジェクトを分岐させたり、同じコードベースを軸として新たなプロジェクトを開始したりすることです。
SaaSモデルでは、完璧にホストとなってソフトウェアを提供します。皆さんの価値や競争上の優位性がソフトウェアの秀逸な運用にあれば、SaaSはよい選択です。しかしながら、SaaSはクラウド・ホスティングを基本とするので、パブリッククラウドが皆さんのオープンソース・コードを選択して競争相手となるという潜在的なリスクがあります。
クラウドと競争の壕 (moat)
ひとたびオープンソース事業がある程度の成熟を達成すれば、パブリッククラウドの脅威とライセンスの話題が持ち上がる可能性が高くなります。ライセンスは非常に議論される話題で、重要であることには違いありませんが、会社が創業当初にライセンスに関する議論に時間をかけ過ぎているのを目にします。
私はまた、私たちがパブリッククラウドのベンダーからの脅威に、過剰反応してきたと思います。これらのベンダーはオープンソース・プロジェクトをホストしているかもしれませんが、これまでのところ、私が認識している限り、クラウドプロバイダーによって完全に追放されたオープンソースの企業は一つとしてありません。
オープンソースの企業が答えるべき、さらに重要な質問はこれです——コードが競争の壕ではないとしたら、壕 (moat) は何なのでしょうか?
その答えは、そもそもオープンソースがこれほど強力になった理由は何かというところまで遡ります。それは、コミュニティと開発に対する考え方です。独立したオープンソースの企業には競争上の優位性が3つあります。
- 企業顧客はベンダーの固定化を好まない。
- 彼らはコードを書いた人から製品を買いたがる。
- 大企業にはあなたの会社とは違い、専門家はいない。
以上の3つを組み合わせることで、本物の競争力のある価値が付加されます。それが、独立したオープンソースの企業が、大手のクラウドに完全に追放されるのを見たことがない理由だと思います。
さて、私たちは三本柱をすでに話題にしています。それを軸にしてどのように組織を構築するかを見ていきましょう。
オープンソースの企業が答えるべき、さらに重要な質問はこれです——コードが競争の壕ではないとしたら、壕は何なのでしょうか?コミュニティです。
市場開拓——オープンソースはファネルのトップ
皆さんのオープンソース・コミュニティは、開発者が動かすファネルの最上位の活動です。事業の構築にとって、そのファネルの最上位であるオープンソースを、価値に駆動された強力な商業製品に結びつけることが重要です。ファネルのアイデアは新しいものではありませんが、オープンソースの企業にとっては、それは異なる役割を果たします。私はこのセクションで、オープンソースの努力が、いかにしてファネルの異なる段階の営業努力に統合され、練り込まれるか、また、いかにそれぞれの段階と他の段階とを調和させて機能させるかを扱います。
オープンソースの市場開拓のファネルは、四つの段階と、鍵となる組織上の機能に分けることができます。
- 開発者コミュニティのマネジメントが、オープンソース製品への認知と関心を高める駆動力となります。
- 効果的なプロダクトマネジメントがユーザー基盤をフリーのオープンソース製品に導きます。
- 見込み客の獲得とビジネスデベロップメントによって、それらのユーザーベースを評価し、事業における潜在価値と営業機会を特定します。
- ユーザー発(ボトムアップ)と営業発(トップダウン)の動きによって、企業に向けた有料の製品およびサービスが提供・拡大されます。
これらのそれぞれの段階とその機能をさらに詳しく見てみましょう。
第一段階:認知と感心 – 開発者コミュニティのマネジメント
ファネルの段階が進むと、開発者による口コミの促進は、成功するためには絶対的な不可欠要素となります。こうした口コミは、ユーザーの登録数とダウンロード数によって測定されます。創業当初は、創業者自らが最初のエヴァンジェリストのように振る舞うことがよくあります。会社が拡大するにつけ、技術的な専門家でありつつ強力なコミュニケーションスキルを兼ね備えた開発者エヴァンジェリストの熱心なチームを持つことが重要になります。技術的なスキルとコミュニケーションスキルを兼ね備えた人は稀ですが、そのような人は出会えばすぐにわかります。もしそのような開発者に出会えたならば、彼らを雇用し、開発者コミュニティに関わる会議やソーシャルメディアに登場してもらい、皆さんのプロジェクトの重要性や価値を説明してもらいましょう。
営業と開発者エヴァンジェリストのメッセージを調整する必要がある一方で、コミュニティマネージャーが「販売」をするのは望ましくありません。彼らに期待することは関心を創出し、人々に製品情報を伝えることであって、彼らが販売に重きを置くと、コミュニティ内の信頼が損なわれます。
事業を開始するにあたり、オープンソース・プロジェクトと同じ名前とブランドをそのまま残すのかどうかについて決断を迫られるでしょう。企業はどちらでも成功します。それぞれにメリットとデメリットがあります。Databricks社とSparkのように、別々の名称はブランドの希釈化を防ぎ、ライセンスの柔軟性を高めます。一方、同じ名称であれば、OSSプロジェクトの勢いをさらに強めることがよくあります。ただし、オープンソース・コミュニティが利益のために搾取されていると感じたら、彼らを疎外するリスクがあるかもしれません。
結局のところ、オープンソース・ソフトウェアとプロプライエタリ・ソフトウェアの両方の一般的な指標はユーザー登録数とダウンロード数です。ですから、決め手となるのは、何を測っているかではなく、いかに精度を高めるかです。私たちは、XenSource社で、一時、不正確な数字を出していました。私たちが測定したダウンロード数には、開始されたけれども完了していない多数のダウンロードが含まれていたからです。ユーザーの登録数とユーザーの関心を測定する方法を磨くことで、ダウンロード数がファネルの次の段階に結びつかない無意味な指標になるのを回避できるでしょう。
第二段階:検討 – プロダクトマネジメント
次は検討です。ひとたび開発者コミュニティの信頼を得たら、次の目標は、開発者およびユーザーの愛着、採用、価値を最大化することです。このオープンソースのファネルの第二段階は、一般的に、プロダクトマネジメントを通じて行われます。
効果的なプロダクトマネジメントにより、この段階を支えるいくつもの機能が実行されます。クローズドソースおよびオープンソースのロードマップの管理、開発者およびユーザーに対する決定の伝達、利用パターンに関するより多くの洞察を収集し営業機会を予測するための、製品への分析の組み込みなどです。
プロプライエタリ・ソフトウェアとは違い、オープンソース事業は、一般的にマネジメントのロードマップが二つあります。OSSのCEOや創業者は、往々にして、これらのロードマップを管理したり、一方のロードマップが他方のロードマップに与える影響を管理したりすることに、ほとんどの時間を費やします。 これらがいかに互いに絡み合い、関係し、それぞれにおいてどのような特性が利用できるかを示して、1枚のページに配置されているのを見るのが私は好きです。
最も成功している企業や創業者は、何が有料で何がフリー化を区別したり、説明したりするのに役立つような、枠組みや指針を持っています。例えば、PlanetScale社は、ベンダーロックインを生むようなオープンソース製品を維持することに取り組んできました。オープンソース・コミュ二ティおよび企業顧客に好かれ続けるための価値を生むものです。顧客とコミュニティがフリーソフトウェアと有料ソフトウェアが提供する価値の違いを理解できるように、特性の比較表があると役に立ちます。
コミュニティの信頼を維持するためには、研究と開発に関する透明性と、コミュニティのフィードバックの製品ロードマップへの組み込みが特に重要です。成功している多くのオープンソース企業は、当該のオープンソース・プロジェクトの、活発で、往々にして主要な貢献者です。例えば、Databricks社はSparkに対して、他社比で10倍の貢献をしています。
製品自体について言えば、分析を組み込むべきです。自社のユーザーを把握し、OSSユーザーが買い手になる割合を予測する助けとなります。ユーザーが製品を手にすれば、製品利用分析がVMF (バリューマーケットフィット) からPMFを区別する助けとなり、フリーユーザーから有料ユーザーへと変わりそうな人数を特定して、営業機会を予測するのに役立ちます。例えば、ユーザー100人あたり5人の割合で有料ユーザーに変わるとすれば、財務モデルを作成するために5%の見積もりを使うことができます。
これは複雑な過程となるでしょうから、フリーと有料の最適な線引きを認識するために、製品パッケージを検証する必要があります。多くのオープンソースの創業者にとって、この製品実験は、終わることのない旅のようなものであり、彼らの市場開拓の成功には、こまめに製品へのフィードバックが得られる循環が不可欠です。
第三段階:評価と意図 – 見込み客の獲得とビジネスデベロップメント
ファネルの次の段階(評価と意図)は、見込み客の獲得とセールスデベロップメントを通じて、上記の理論を実証し、洗練させるものです。目標は、自社のユーザーから企業の買い手につながる道を見つけることです。ここでの成功は、営業対象の見込み客(SQL)によって測定されます。
これはアウトバウンドマーケティングから始まります。アウトバウンドマーケティングでは、ファネルのトップの開発者のエヴァンジェリズムが明らかにした、よく知られたパターンを基盤として、特定の市場区分に焦点を当てた宣伝活動を優先すべきです。オープンソースのユーザーに注意を払うことで、製品を利用する役割や部門を知り、彼らが何に関心を抱いているかを知ることになります。そうすれば、アウトバウンドマーケティングの標的を、自社製品に価値を見出しているエンジニアリングマネージャー、開発者、ITに絞ることができます。
次は営業開発努力です。営業開発担当者(SDR: Sales Development Reps)は、過度に売り込むようなアプローチよりは、顧客の成功を考えたアプローチをとり、常にユーザーの必要性や製品利用目的に興味を持つべきです。
キャンペーン活動が見込み客を獲得するようになるにつれて、彼らを営業対象とするためのフィルターが主に二つあります。1) どの組織の開発者あるいはユーザーなのか? 2) 彼らがダウンロードしたり、プロジェクトに携わったりしているのは、さらに大きな企業の目標と関連する何かのためなのか?
第四段階:購入と拡大 – インサイドセールスとフィールドセールス
営業対象となる見込み客を得たら、取り組むべき営業の動きが二つありえます。一つ目にありうるのが、ユーザー発下意上達の動きです。企業内のユーザーが広告を経由せずに製品を採用し、支払います。一般的には、この製品は個人向けとなります。二つ目は、営業発の動きです。これは、より伝統的な上意下達の動きを用い、取引を部門レベルに着地させるか、企業全体に利用を拡大するというものです。
成功と失敗はどのような姿をとるか
オーガニックな成長と企業営業との調整は、オープンソース事業によくみられるいくつかの失敗のパターンを招く可能性があります。これについては、私の同僚であるMartin CasadoがGrowth, Sales, and a New Era of B2Bの話の中で指摘しました。まず一つ目は、オープンソース・ユーザーが買い手にならないことです。この場合、PMFにはすばらしい手応えがありますが、バリューマーケットフィットは皆無です。
二つ目の失敗のパターンは、OSSプロジェクトの成長が企業営業に立ち遅れているというものです。ここでは、PMFはそれほどすばらしくはない場合があります。三つ目は、営業的な申し出によって、開発者コミュニティの信頼が損なわれる場合です。傾向としては、プロプライエタリは充実しすぎており、オープンソースには不足があります。結果として、オープンソース・プロジェクトは衰退します。
ファネルのトップはその後の全ての決め手となる鍵を提供します。従って、形式的なマーケティング営業の前に、まずは自社の開発者コミュニティ、オープンソース・プロジェクト、およびユーザーに投資しましょう。そして、次に挙げる三つの中心的な質問を常に視野に入れておくようにしましょう。ユーザーは誰か? 買い手は誰か? オープンソースと商用の提供はそれぞれのユーザーに対してどのようにして価値をもたらしているか?
もし成功していれば、上掲のようなグラフを目にするかもしれません。y軸は顧客ひとりあたりの収益で、x軸は時間です。このグラフは、元GitHubの取締役会の一員として、私が実際に直に見たもので、収益に集計されている、トップダウンおよびボトムアップの販売数を示しています。ここから学ぶべき教訓は、収益がレイヤーケーキのようになっていたらよい兆候だということです。オレンジ色の線は個人からのボトムアップによる収益で、典型的には一つの収益線をなします。次の収益線は、部門の買い手への販売数でしょう。これはトップダウンで、通常はインサイドセールスを用いています。レイヤーケーキの次の部分は、フィールドセールスあるいは直販で、企業全体にアカウントを販売または拡大しています。これらの収益線のそれぞれを最適化するためには、受け身の姿勢で営業に取り組んではいけません。それぞれの特定の機能に責任を持ち、目的をもってその活動を突き動かす人物を配置してください。
最後に、皆さんは、製品によっては、ユーザー発のセールスのみを行うこともあれば、インサイドセールスのみを行うこともあるかもしれません。それでも大丈夫です。これは実際のところ、製品の複雑さや製品を利用する場所と方法によります。私の経験からして、ほとんどのオープンソース企業はトップダウンとボトムアップの両方を何らかの形で組み合わせており、往々にして、ボトムアップで始め、その上に収益が拡大する機能を構築するというやり方をとります。
OSS 3.0 – オープンソースはすべてのソフトウェア会社の構成要素の一つです。
ソフトウェアが世界に浸透してきたように、オープンソースはソフトウェアに浸透しています。
現在では、Facebook社からGoogle社まで、ほぼすべてのテクノロジー企業がオープンソース・ソフトウェアを活用しています。これらの企業はまた、ますますオープンソース・プロジェクトの構築を行うようになっていました。例えば、Airbnb社は30件以上のオープンソース・プロジェクトを持っていますし、Google社にいたっては2000件以上です!
将来的に好循環が続くでしょう。テクノロジー、AI、オープンソース・データ、ブロックチェーンは、新しく登場した革新の一部の例です。大手のプロプライエタリ事業がオープンソース・プロジェクトを支援する場合のように、次世代の事業モデルには、広告収益型OSSが含まれるかもしれません。またデータ中心型収益や、ブロックチェーンを資金化するクリプト・トークンなどの事業モデルもそこに含まれるかもしれません。
オープンソース3.0がオープンソース事業についての私たちの考え方や定義の仕方を拡大すると私は信じています。RedHat、Elastic、Databricks、Clouderaはもはや、オープンソースを代表する存在ではなくなるでしょう。それらの事業は、少なくとも部分的には、Facebook、Airbnb、Googleなどのように、スタックの要としてオープンソースを持っているその他の事業にとって代わられるでしょう。オープンソースをこのように見た場合、進行中のルネッサンスはまだ黎明期にあるのかもしれません。オープンソース・ソフトウェアの市場と可能性は、これまで認識されてきたよりもはるかに大きなものです。
コミュニティ貢献者—— このガイドは、紛れもなくオープンソースの産物でした。オープンソース・コミュニティ全体の叡智を活用しています。私たちが特に感謝したいのは、次の方々です——Ali Ghodsi(Databricks社CEO)、Maxime Beauchemin(Superset社プロジェクト・リーダー)、Jiten Vaidya(PlanetScale社CEO)、Sugu Sougoumarane(PlanetScale社CTO)、Marco Palladino(Kong社CTO)、Paul St John(GitHub社SVP、国際営業)、Jono Bacon(コミュニティ・マネージャー)、Kevin Wang(FOSSA社CEO)Stuart West(Automattic社SVP、業務運営)、Zeeshan Yoonas(Netlify社CRO)、Heather Meeker(OSSライセンス弁護士)。
著者紹介 (本記事投稿時の情報)
Peter Levine は Andreessen Horowitz のジェネラルパートナーです。彼は以前 Citrix の Data Center & Cloud Division の上級副社長でありジェネラルマネージャーとして、売上、プロダクトマネジメント、ビジネスデベロップメント、戦略の方針について責任を負っていました。Peter は 2007 年に、XenSource が $500M で買収されたことにより Citrix に入社しました。XenSource で彼は CEO として、600 人の従業員を率い、Microsoft や Symantec、HP、NEC、Dell といった顧客と XenServer の製品ファミリに関する戦略的な契約を確立しました。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: Open Source: From Community to Commercialization (2019)