本題に入る前に言っておきます。私は、このトピックは重大であるし、Chef Software（以後Chef Incと表記）の一部の人たちにとっては、ことさら重要な意味があると思っています。「Chefはオープンソースではない」という問題に向き合う時が来たのです。いつからそうなったか正確には分かりませんが、この数年間でChefはオープンソースモデルから確実にシフトしてきています。

「でも、コードはGitHubに公開されていますよ」

確かに、文字通りの意味では、コードは自由に閲覧および改変できるようになっていますが、それだけではオープンソースの理念を満たしているとは言えません。なぜなら、オープンソースとは協力してソフトウェアを構築するコミュニティだからです。

「でも、私もパッチを提供したことがありますよ」

皆さんのコントリビューションには感謝しますが、この問題は大局的に捉える必要があります。元々「コモンズ」の背景には、皆が少しずつ協力することで、より優れたソフトウェアをより持続的な方法で構築するという考え方がありました。しかしChefコミュニティおよびエコシステムではこの理念が実施されていません。現状はChef Incが一部の人たちと協力して膨大な時間と資金を費やす一方で、少数の企業とそれより更に少ない人たちがプロジェクトを通じてコントリビュートし、そのあとに純粋な利用者のロングテールがあるといった具合です。

「でも、どのコミュニティでも製作者より利用者の方が多いですよ」

確かにその通りですが、Chefの場合は両者の健全なバランスを大きく逸脱しています。Chefのエコシステムがコントリビュータの減少を招き、その結果、エコシステムの多くの部分はそこに残った人たちで運営されているのです。残念ながら、これは企業が支援するオープンソースプロジェクト全般に言えることです。というのも、そのようなプロジェクトは企業のやり方を容認することで利益を上げようとするからです。私が参加している他のコミュニティの中で、一貫して健全なエコシステムがそれなりに保たれているのは、ウェブ開発の分野だけのようです。現場の人たちは、この類いのコミュニティに参入して日が浅く、いまだにエンドユーザの視点を持っていると考えられますが、それも推測の域を出ません。

大企業はBtoBスタートアップからもオープンソースの世界からも評判がよくありません。断言しておきますが、私は大企業に注目すること自体が間違いだとは思いません。私はChef Incの社員全員に対して多大な敬意を抱いていますし、もし彼らが会社の将来を安泰にするためのベストな方法がこれだと考えているとしたら、私は100％彼らを支持するつもりです。しかしそれには代償が付き物で、残念ながらこの場合もそうだと言わざるを得ません。

「Chefがオープンソースでなければ、一体何なのですか？」

Chefは優れたエンタープライズ自動化ツールキットで、フリープロダクトも豊富に提供しています。そしてそれこそが、多くの人が求めていることでもあります。私はおそらく、私自身を含め、Chefを強力なオープンソースコミュニティにするために多大な力を注いでいる人たちの名前を全て挙げられますが、私たちだけではこのコミュニティの理念を保持するには不十分です。だからと言って、私はこれがChefやChef Incの破滅につながるとは考えていません。現に市場の反応はよく、フリープロダクトも人気があります。また、他にChefのような役割を担うプレイヤーがいないとは言え、GitHubにChefのコードが公開されていることも、ベンダロックインではないという暖かみを感じさせてくれます。

Chef Incが公開の場でChefを構築していくことが困難になればなるほど、この傾向が見られるようになります。ちなみに、 ChefRFC を知っている人はどれくらいいるでしょうか？プロセス自体は存在しているものの、その利用には一貫性がなく、プルリクエストに参加している一部の人たちを除いて、ほとんどやり取りも行われていません。Chefのフィーチャに関するロードマップはますます不可解になり、私的、もしくは公的ではあっても巧妙に隠された舞台裏でコミュニティ全体の決定がなされ、また、コミュニティのコントリビューションは急速に衰退しています。

ケーススタディ：Chefのサポート

私が取り上げた製作者と利用者の割合に関する問題を例に挙げて、Chefのプロダクトサポートの仕組みに注目してみましょう。Chef Incは有料のサポートパッケージを提供していますが、それを利用している人はほとんどいません。また、Chef Incには優良な入門トレーニング教材やレッスンがあるものの、これらは利用者に出発点を与えるきっかけに過ぎず、学習後の質問に対応する場はありません。

IRC

まずは私のお気に入りのツールであるIRCから話を始めましょう。私はChefのIRCチャンネルに関して、 毎晩更新する統計 を公開していますが、あえて言えば、私はこの手段を通じて利用者の大半にカスタマーサポートを提供しています。私の貢献度に最も近いChef Incの社員でさえ、私が確認できる限り、私の10分の1程度しかサポートを提供しておらず、このような状況は随所で見受けられます。私はこの状況を改善するようChef Incに働きかけていますが、私のメールに対する回答はまだありません。

StackOverflow

StackOverflowの”chef”タグは非常によく見かけます。テクニカルツールの問題解決に最も活用されている方法と言えるでしょう。とびぬけて回数の多い回答者はセス・ヴァーゴです。セスはChef Incの社員ですが、この作業は彼の職務の一部ではなく、全くの個人的な時間に行われています。セスの次に回答数が多いChef Incの社員と比べても10倍以上の差がついています。

メーリングリスト

ここではもう少しだけバランスがとれているようです。トップ5の回答者のうち3人までがChef Incの社員です。彼らの勤務時間のうちどのくらいの割合を割いてこれらのメールを書いているかは分かりません。しかしこの3人がカスタマーサポートの所属ではないことを考えると、大した割合ではないでしょう。トップ5による回答が全体の15％しかないので、これもむしろロングテールと言えるかもしれません。
世界的なChefのコミュニティは、全体としては一握りの人たちによってサポートが提供されているという明白なパターンがあるようです。

ケーススタディ：コントリビューション

Chefのコミット

Chef IncはChefへのパッチを受け入れていますが、このことによる効果はかなり低いと思われます。今年は現時点で社外からのパッチはラインカウントで4％にすぎません。2013年も大きな違いはなく、1年を通して社外からのコントリビューションはたったの7％でした。前にも述べましたが、Chef開発の大部分を担っているのは、そのために雇われた社員なのです。

Chefのプッシュ

コミットだけではありません。事実上、社員以外でChefへのコミットの直接権限を持っている人がいないということは注目に値するでしょう。2012年には社外からのリポジトリプッシュは3人からの9件のみでした。このうち7件が1人からのものです。Chef Incがプロジェクトに対するただ1つのゲートキーパーであるということは、オープンソースのコミュニティのあり方の完全な対局にあると言えます。

Chef Server のコントリビューション

ErlangベースのChef　Serverのライフスパンを通して、社外からのパッチで私が発見できたものはたった1つです。コンフィギュレーションの修正の1行だけでした。このことはRubyからErlangに移植するときのリスク要因だということは理解されていたと思いますが、その影響はすぐはっきりと表れました。完全に社内開発だったErchefのワークフローが、多くのプロプライエタリなツールに依存しているという事実からすれば仕方ないことかもしれません。

今後の対策

分からない、というのが正直なところです。私はChefのエコシステムを健全なものにするため、金銭的にも感情的にも相当投資してきました。Chefに投資することで家賃を払ってきたし、人生の長い期間をその投資に費やしてきました。残念ながら出口が見えません。Chef Incの人たちも何とかしたいとは思っているでしょう。この記事を読んで、もっとプライオリティが高い問題だということに気付いてくれるといいのですが。このような状況から回復できたコミュニティというのは、私が見てきた中では思いつきません。それどころか、フリーとうたっていながら商用ソフトウェアになってしまいました。Chef Incがコミュニティ参加への改善方法を見つけて、積極的に対話を続けることを希望します。私としては商用ソフトウェアに対してこれ以上タダ働きをする正当性が見つけられません。市場では既に良い結果を得ていますし、質の高いフリープロダクトには需要があります。

進むべき道

改善の余地があるとしても、あらゆる面での変化を起こさなくてはならないのは明らかです。コミュニティ全体の中から、変わろうという意志が出てこなければなりません。議論のスタートポイントになり得ることをいくつかリストしてみます。

1. 計画と設計をオープンにすること。Chef RFCがPythonのPEPのような仕組み、すなわち大規模な変更は正式なプロポーザルとして提出し、chef-devメーリングリストで議論するようになることを強く希望します。最近のJiraのシャットダウンのような政策的な決定も含めてです。
2. コミッターになるためのガイドラインを作成する。オープンソースの世界にはいくつもの前例があり、道筋があればより多くの社外のコミッターが戦力になるでしょう。
3. Cookbookの共有を改善すること。Cookbookの名前空間について、私は完全に無駄骨を折ってきました。多くの人にとってはこれがコミュニティ参加への大きな障壁となっているのです。
4. Chef エコシステム開発のサポートをChef Inc以外の企業に進めてもらう。
5. Software Freedom Conservancy(SFC)、または類似の団体に、Chefをプロジェクトとして移管することを検討する。

上に述べたようなことは特効薬とは言えませんが、まとまればある程度効果があると思います。より力強く、多様なChefのコミュニティが形成されれば、よりよいツールを生み出せるでしょう。オープンソースのモデルは、ソフトウェアの作成に適しており維持しやすいモデルです。ご賛同いただけたらうれしいです。

草稿をレビューしてくれたみんなに感謝します。