Open SourceArchived

RethinkDB

RethinkDB は、ライブクエリ更新を持つアプリケーションを作る開発者向けのオープンソースリアルタイムデータベースでした。

元のストーリーを見る

プロダクト概要

何だったか

RethinkDB は、realtime applications 向けに 分散ドキュメント保存 と ライブプッシュ更新 を提供しました。

誰のためか

application developersstartup engineering teamsオープンソースデータベース adopters

課題 / 価値

従来型データベースを繰り返し polling せずに、realtime application features を作りやすくすること。

中核ワークフロー

  • JSON documents を保存する
  • realtime application features を作る
  • distributed NoSQL workloads を動かす

プロダクト形態

オープンソースデータベースdeveloper tooldocumentation site

価格モデル

Open source。商業的な収益化の詳細は、公開閉鎖ソースでは完全には開示されていません。

何が起きたか

概要

RethinkDB の会社は 2016 年に閉鎖されましたが、オープンソースプロジェクト は継続しました。

結果

会社は持続可能な事業を作れませんでしたが、オープンソースプロジェクト は会社より長く残りました。

需要シグナル

RethinkDB の会社は、プロジェクトに本物の開発者関心があり、open source として継続したにもかかわらず、持続可能な事業を作れず閉鎖されました。教訓は技術価値の欠如ではなく、収益化と市場選択です。

集客上の問題

オープンソース開発者ツールは無料代替と曖昧な買い手と競います。創業者ポストモーテムでは、ユーザーはチームが最適化した軸よりも availability、自分たちの workload 上の speed、具体的な fit を重視したと述べられています。

タイムライン

  • Failory によると 2009 年に開始されました。
  • 2016 年 10 月 5 日、会社閉鎖が発表されました。
  • Project と Horizon は オープンソースライセンス の下で利用可能なままでした。
  • Project は コミュニティ と Linux Foundation の文脈で継続しました。

作る前に確認すること

なぜ重要か

developer tool は愛され、使われ、技術的に強くても、明確な買い手と支払い意思を欠くことがあります。

主な確認事項

開発者からの称賛とは別に有料需要を検証してください。スター数、利用量、技術的評価は、オープンソースツールの背後に会社が生き残れる証明にはなりません。

チェックリスト

  • ダウンロード や スター数 だけでなく、ユーザーセグメント ごとの有料転換を追う。
  • production users に budget と purchase criteria を聞く。
  • maintenance burden を広げる前に、support、hosting、enterprise package を試す。
  • 誰がこのツールに予算を持ち、なぜ今支払うのか。
  • 無料プロジェクトより強い有料 workflow は何か。
  • ユーザーは、チームが最適化している品質と同じ理由でツールを選んでいるか。

参考になる場合

  • オープンソース開発者ツール、データベース、フレームワーク、インフラプロジェクト を作っている。
  • コミュニティ 利用量 を会社規模の事業証拠として扱っている。

参考になりにくい場合

  • 転換と更新が証明された具体的な有料セグメントをすでに持っている。

開発前テスト

  • roadmap を広げる前に、production users へ具体的な有料 package を 1 つ売る。
  • business contexts で既にツールを使っているユーザーに pricing interviews を行う。

応用できる学び

  • 無料利用と コミュニティ praise とは別に、有料転換を測る。
  • 買い手がすでに予算を持つ user job に製品を固定する。
  • support、hosting、enterprise features、または狭い workflow のどれが収益化の wedge になるかを決める。

今作るなら

プラットフォームを広げる前に、1 つの有料ユーザーセグメントを選んでください。誰が、なぜ、どの workload に対して支払うのか、support や hosting が収益化製品になれるかを試してください。