Meltano、GitLab内製ツールから4.2百万ドル調達のopen-source DataOps基盤へ

まずGitLab内の困りごとから始まった

Meltanoは2018年、GitLabのdata and analytics team向けのopen-source toolとして生まれた。出典

当初から「データ統合を特定部署だけの専用品にしない」という問題意識があった。

ELTへのpivot

2020年、MeltanoはSingerとdbtを軸にopen-source ELTへ方向転換した。出典

ここで重要だったのは、巨大な一体型platformを最初から作るのではなく、既存の標準と周辺ツールを組み合わせる設計を選んだことだ。

独立という転機

2021年、MeltanoはGitLabから独立し、GV主導で420万ドルのseed fundingを調達した。出典

その後、プロジェクトはGitLabからGitHubへ移り、communityが日常的に参加する場所を変えた。出典

Founderが引き継ぐテーマ

現在の公式Aboutでは、Aaron PhetheanがMeltanoのFounderとして「make dependable data infrastructure the standard, not the exception」という方針を掲げている。出典

これは派手な機能競争より、壊れにくく透明なdata accessを標準化する方向だ。

今のMeltano

Meltano 2.0ではSinger、dbt、Airflow、Great Expectations、Supersetなどを組み合わせるDataOps infrastructureを提示した。出典

GitHub、SDK、Hubまで含む開発面の整備が、単なるETL CLIをplatformへ押し上げる道のりになっている。

データエンジニアはAPIごとのintegrationを個別実装し、認証・state・schema変更・再実行を運用し続ける痛みを抱える。

MeltanoはSingerのtap/targetと宣言的なproject設定を組み合わせ、接続と実行をコードレビュー可能な単位へ落とす。出典

500以上のconnectorとopen-source基盤を打ち出すことで、特定vendorへのロックインを避けたいチームに適合する。出典

特許ではなく、Singer仕様・SDK・Hub・connectorの組み合わせによるecosystem moat。

個々のconnectorは代替可能でも、設定・発見・実行の一体化は移行コストを生む。

中程度。

利用者が増えるほどconnectorと知見は増えるが、単一projectの価値は他ユーザーの参加なしでも成立するため、強い両面市場ではない。

複数SaaS・DBからwarehouseへデータを集めるdata engineer、analytics engineer、または小規模チーム。

GUIだけで完結したい非技術ユーザーには過剰。

Singerという既存標準を再利用し、connectorをSDKで増やせる構造にした点が大きい。出典

GitLabから独立した後もGitHubとMeltano Hubでcommunity discoveryを促進した。出典

open-sourceの自由度は初期設定・運用責任を利用者に戻す。

Meltano自身もconnector品質、state管理、managed cloudとself-hostの境界を継続的に改善する必要がある。

公開情報だけではARRや顧客構成は要確認。

open-source coreとcontent、GitHub、Hubを入口にし、運用負荷を下げたいチームへcloud/managed offeringを提案する。

無料の自己ホストと有料運用の間に明確な価値差を作れるかが継続課題。

主要チャネル: content, open_source_community, github, sales

標準仕様を先に押さえると、個別connectorの積み上げをecosystemへ変えられる。

独立後もopen-sourceの発見性と運用性を同時に整える必要がある。

日本ではSaaSと基幹系のデータ接続が部門ごとに分断されがち。

Meltano型を導入するなら、まず社内データ契約・個人情報のmasking・再実行方針をテンプレ化し、connector数より監査可能性を優先したい。