LinuxCon ChinaでMicrosoftのエンジニアが説くオープンソースプロジェクト成功のポイントとは？

北京で開催されたLinuxCon＋ContainerCon＋CloudOpen China 2018（略称、LC3）には、中国のインターネット企業が多数参加し、自社のユースケースや開発をリードするオープンソースプロジェクトなどの訴求を行っていた。今回の記事では、その中でも少し毛色の変わったセッションを紹介したい。これはMicrosoftのStephen Walli氏が行った「Evolution of Open Source Software Foundation」と題されたもので、オープンソースソフトウェアが自然発生的に生まれてから、ガバナンスを非営利団体に委ねるまでの遷移とそれに従って発生する様々な状況を解説したものだ。

ここで重要なのは、Walli氏は「自然発生するオープンソースソフトウェアは、企業からのコントリビューションなしでは立ち行かなくなっていること」をまず指摘している点だろう。GoogleやMicrosoft、Facebook、Lyftなど企業の内部で開発されたソフトウェアがオープンソースとして公開されるという昨今の状況と、それを支える企業のエンジニアの存在を肯定的に認識した上で、「では企業がリードするオープンソースプロジェクトとはどうあるべきか？」を解説した。

講演を行うStephen Walli氏

まずWalli氏は、オープンソースソフトウェアが生まれてから拡大していく段階を示した。小さなアイデアと少人数のコミッターから始まり、コントリビューターが増え、コミュティが形成され、徐々に書籍やトレーニングなどのエコシステムが作られるという典型的なオープンソースプロジェクトの遷移を示したものだ。

一般的なオープンソースソフトウェアのプロジェクト

しかし次のスライドでは、単にソフトウェアとそれを開発する仕組みの進化だけではなく、コミュニティに関してもその進化を解き明かすことになる。ここでは、ソフトウェアのライセンスを決めるところからFAQの作成、オンラインフォーラムや公式メールアドレスの開設、コミュニティがコミュニケーションを行うためのツール、さらにCode of Conductの作成、コントリビューションを行う際の方法、ガバナンスの行い方、Meetupなどのイベントの開催など、およそコミュニティにおいて必要と思われるポイントがカバーされている。

ソフトウェアのパートでは、実行可能なイメージの公開からバグトラッキングシステム、ビルドやテストの自動化の必要性が明記されている。特にソフトウェアが成熟するに従って、ビルドやテストの自動化が複数のレベルで進化するという部分には、実際にオープンソースソフトウェアを観察してきたエンジニアとしての知見を感じられた。

ソフトウェアとコミュニティの遷移

そして、「いかにユーザーを増やすのか？」「いかにそのソフトウェアを使うデベロッパーを増やすのか？」「どうやってコントリビューションを簡単にするのか？」というオープンソースソフトウェアにおいては非常に大きな命題について、解説を始めた。

特にここからは、「企業に属するデベロッパーをどうやって引きつけるのか？」に主眼をおいて説明が行われた。このスライドの真ん中の赤い矢印、つまり途中から参加するデベロッパーとそれによって拡がるユーザーを意識したものだが、実際にはこの後に「このスライドは理想的な姿でしかなく現実は異なる」ということが示される。

企業に属するデベロッパーと同時に知財についても留意が必要

上記のスライドの緑の矢印は、企業に属するデベロッパーが参加すると同時に、そのソフトウェアの知的財産についても同時に検討を行わないと、企業に属するデベロッパーにとってはリスクが高まってしまうということを意味している。つまり「デベロッパーが書いたコードは誰のものか？」「ライセンスは何を使うのか？」などを明確にしておかないと、不具合が起こるということを示唆している。

オープンソースプロジェクトの実際

そして上記のスライドでは、実際に企業のデベロッパーが参加するオープンソースソフトウェアにおいて、かなり初期の段階からパートナーや競合他社までがプロジェクトに参加して、ソフトウェア開発が進められるようになっていることを解説している。これはMicrosoftやRed Hatのように、オペレーティングシステムという市場では競合になるベンダーのエンジニア同士が、一緒になってLinuxのカーネルを開発していることなどを見みれば、かなりリアリティを持って理解できるのではないだろうか。そしてそのような状況になった際には「ユーザーとパートナーの期待を、コミュニティの中でコントロールすること」が重要であることが強調された。

これは、今やホビーからオープンソースソフトウェアが始まることはほとんどなく、企業のストラテジーとしてソフトウェアを開発し、それをオープンソースソフトウェアとして公開することでソフトウェアの品質向上、企業イメージの向上などを目指している現実を、上手く表していると言えよう。

ただし、Walli氏はオープンソースプロジェクトが成功するためには、「Foundationという非営利団体で管理されることは必ずしも正解ではない」ともコメントした。WebサーバーであるApacheは確かにApache Software Foundationが結成され、そこでホストされることで開発のスピードが加速し、より多くのユーザーを惹きつけたことを事実として説明したが、コードの量だけが目安になるべきではない点も強調した。

Apache Software Foundation結成後、コードの量は飛躍的に増加した

そこで示されたのが、最も変化が速いオープンソースソフトウェアに関するグラフだ。

OSSのコミット数（X軸）とアクティビティ（Y軸）の相関図

このグラフ、元はCNCFの以下の記事に含まれていたものだが、Linux Kernelがコミットの数と同様にPull Request（PR）及びIssue数、そしてコントリビューターの数が多く、Kubernetesも同じ傾向にあることがわかる。しかし右下に存在するCloud Foundryのように、コミット数は多いが、ある程度成熟することでPRとバグの数も減り、安定してくるということが分かる。

The 30 Highest Velocity Open Source Projects

このようにプロジェクトそのものはその成熟度によってコミット数、PR数が増え、コントリビューターの数も増加するが、一定期間が経過して充分に成熟することで徐々にアクティビティは落ち着いてくるということだろう。つまりアクティビティの高さは、オープンソースプロジェクトの良し悪しの尺度ではない、ということがWalli氏の要点だ。

非営利団体はOSSに必須なのか

Walli氏はApache Software FoundationやLinux Foundationを例に挙げ、その良さを説明したが、その他の失敗例としてSymbian Foundationや自身が関わったOuterCurve Foundationを挙げた。Symbian Foundationは、携帯電話向けのプラットフォームとしてSymbianを買収したNokiaが推進した非営利団体、OuterCurve FoundationはMicrosoftが設立したもので、ソースコードリポジトリのCodePlexを使って企業の持つ知的財産を管理するための非営利団体だ。どちらも結成早々から運用がうまく行かずに、最終的には何の結果も産み出さずに終了している。

終了したOuterCurve Foundation

CodePlexはMicrosoft自家製のソースコードリポジトリで、Microsoft社内では終わったプロジェクトとして扱われており、奇しくも2018年6月に発表されたGitHubの買収によって、正式に葬り去られることとなる。

このセッションでは「どうやったらオープンソースプロジェクトは成功するのか？」という命題に明確な解答は与えられなかったが、企業デベロッパーがオープンソースプロジェクトに関わる際に重要となるいくつかのポイントは示されていたように思える。

実はこのセッションの後に、Walli氏に質問しようとした際に起きたエピソードがより印象的だったので、それを記して終わりたい。

それは筆者の前にWalli氏に質問した中国人デベロッパーが「中国でオープンソースソフトウェアの開発を行っているが、コントリビューターが増えない。このプロジェクトをもっと成功させるには何をすれば良いと思うか？」というものだったのだ。この質問にWalli氏は真摯に回答していた。その内容は「海外のカンファレンスでセッションを持つこと」「可能な限り英語で情報を公開すること」といった極々基本的なものだったが、とにかく自身が関わるプロジェクトを盛り上げたいエンジニアとしての思いがこのような質問になったのだと思う。

日本でも自社が開発したソフトウェアを公開するという流れがあるが、単にオープンソースソフトウェアとして公開しても簡単にコミュニティが形成されるわけでもなく、GitHubで公開はしてみたものの、結局社員だけが関わっているというプロジェクトも多いだろう。少なくともこの質問をしたエンジニアは、オープンソースに詳しい海外のプレゼンテーターにその質問を英語でぶつけて回答を得るという努力はしたのだ。その努力には敬意を評したいし、日本でもオープンソースプロジェクトのコミュニティ形成の難しさを味わっているエンジニアにとって、彼の行動は参考になるのではないだろうか。

ちなみにそのエンジニアはAlibabaのデベロッパーで、Apache Software FoundationでインキュベーションされているDubboというRPCのフレームワークのPMCでもあるHuxing Zhang氏だ。

Dubbo Project

Huxing Zhang氏のLinkedInを参照すると、日本のDeNAで働いた経験もあるらしい。Zhang氏のプロジェクトが、今後、盛り上がることを期待したい。