Open Source Leadership Summit開催 OSS運営に関する多数のセッションが開かれる
VMwareによる「Managing an Open Source Project：The Non-code work」
次のセッションは、VMwareのJonas Rosland氏が登壇し、オープンソースソフトウェアにおけるコード以外の仕事の重要性に関する内容となった。
VMwareのJonas Rosland氏
これはオープンソースソフトウェア開発のプロジェクトにおいて、コードを書くことだけが重要なのではなく、それ以外の仕事も同時に重要であるということを、VMwareがリードするコンテナイメージのリポジトリーであるHarborとKubernetesを例に解説するというものだ。
ソースコードだけが全てではない
そしてコードにまつわるドキュメンテーション、SNSなどへの投稿による露出、コミュニティへの教育活動などが重要であると、Harborの例を元に解説した。またプロジェクトの外観にも相当するビジュアルコミュニケーションについても、その重要性を解説した。これは最近、多くのプロジェクトでプロジェクトのロゴだけではなく、アイコンやマスコットなどのデザインを重視する傾向にあることを併せて考えると納得出来る内容だった。元はといえば、GitHubがマスコットであるOctocatのモナリザをデザインして全てのコミュニケーションに利用していることに端を発していると言えるが、Kubernetesの舵を模したデザイン、Istioの帆船のモチーフ、そしてHarborの灯台を模したデザインまで、ビジュアル的に親近感を集めることがデベロッパーにとっても重要であることを示唆している。
またGo言語のマスコットであるGo Gopherについても言及し、マスコットのデザインもそのプロジェクトの成功に影響することを解説した。
Go Gopherをカスタマイズできるアプリの紹介
なおGo Gopherが誕生した経緯については以下を参照されたい。
Lyftによる「Envoy: An End User Driven Open Source Success Story」
最後に、LyftのMatte Klein氏によるユーザーで生まれたオープンソースソフトウェアに関するセッションを紹介する。
Envoyの生みの親であるLyftのMatt Klein氏
マイクロサービスを実現する軽量ProxyサーバーのEnvoyは、元々Lyftの内部のシステムとして開発されていた。それがCNCFにホスティングされることで、一気に利用が拡がった。特にサービスメッシュを実装するIstioでは、コンテナを格納するPodにサイドカーとしてEnvoyが実装され、アプリケーションの通信を担う役割を果たす。
Envoyの歴史。CNCFには2017年にホスティングされ2018年にはGraduationステージになった
Klein氏はまず、社内のシステムがオープンソースソフトウェアとして公開されることについてその背景を解説。
EnvoyがOSSになった背景
セッションの主な内容は、「コントリビュータとして参加する人にはそれぞれの目的があることを認識しよう」「オープンソースプロジェクトを運営するのは会社経営を始めるのと同じくらいに難しい」「テクニカルな部分以外が重要である」というものだった。最後のテクニカルな部分以外が重要というのは、VMwareのRosland氏のNon-Code Workが重要であるというのとほぼ同じ内容のメッセージである。また誰に対してもナイスに振る舞うこと、コード以外のWebサイトのデザインなども重要であることも、言葉を変えて同じことを語っていると言える。
Webやドキュメントも重要
そして透明性の重要さ、SNSの活用などを説明した後に、Envoyのビジネスモデルについて解説した。
Envoyのビジネスモデル
このスライドのタイトルに「ビジネスモデル（もしくはソレがないこと）」と書かれているように、EnvoyはLyftというユーザー企業で開発されたソフトウェアだ。同様の経緯で登場し、CNCFにホストされたものとしては、YouTubeで開発されたVitessなど挙げられるだろう。これらに共通する点は、「そのソフトウェアだけで利益を生むことを期待されていない」ということだ。これは、OSSのライセンス問題として名前の挙がるMongoDBやRedis、Elasticsearchなどの企業とは大きく異なる点だ。つまりEnvoyには上記の写真にあるように「No Premium Version」つまり機能を追加した有料版がないのは自明だ。そして純粋に技術的に良いことに集中できることが、このビジネスモデルの利点だろう。
参考：Open Source Leadership SummitでAWSとElasticのOSSタダ乗り問題が再燃。コミュニティは静観か？
OSSが上手くいかないことを防ぐ方法
ここでは特に持続させるために必要なのは、コントリビュータの拡大に尽きることを説明。またオープンソースプロジェクトに関わるエンジニアがバーンアウトしてしまうことについては、簡単な処置方法はなく、エンジニアの雇用側の期待との衝突は簡単に避けられるものではないという厳しい現実をあからさまにした。
Envoy成功のポイントはコミュティに尽きる
最後のスライドで「No “open core” / premium version」とあるのは、ここでもベースだけをオープンソースにするオープンコアモデルの限界を示唆していると言える。コンテナ界隈で最も成功しているKubernetesもオープンコアではなく、フルにオープンなモデルとしてパブリッククラウドプロバイダーからはそれぞれの実装ができているほどに、エコシステムが拡大しているのは明らかだ。オープンソースソフトウェア自体では利益があがらないこと、つまりビジネスモデルが完成しないこと自体がビジネスモデルであり、企業に属するエンジニアをいかにエンゲージするか？ これが成功の要点であるという話は、2018年に北京で開催されたLinuxConで取材したセッションでも解説されていた。
参考：LinuxCon ChinaでMicrosoftのエンジニアが説くオープンソースプロジェクト成功のポイントとは？
Open Source Leadership Summitの2日目は、「オープンでありながら、いかにビジネスとして存続するか？」ということが大きなトピックであることを、改めて実感させられるものとなった。
