オープンソースは報われない仕事。でもやるんだよ。
Microsoftの中の人で、OSSとWeb技術を推進するScott Hanselmanが書いたブログ記事 "Open Source is a thankless job. We do it anyway." を勝手に翻訳。
オープンソースは難しい。
セキュリティは難しい
OpenSSLの最近の "Heartbleed" バグに関する記事がたくさん出回っている。技術的な分析をすべて読んだら丸一日つぶれてしまうだろうが、 その中にこれはと思う見出しがあった。『OpenSSLはオープンソースの大きな問題を示している。資金不足、人員不足』だ。インターネットを織りなす基本の部分は、ほとんどの場合たった一人によるもので、あとはたくさんのボランティアだ。
〝魅惑的で気が遠くなるような事実とは、ネットワークインフラストラクチャにはこのように重大な部品が存在していて、インターネットの大部分で実際に動いているのだけれど、基本的にはフルタイムで作業しているのはたった一人しかいないということだ。〟
さらに、あるソフトウェアが動作している間は、私たちは貢献者たちの努力と成功を褒め称えたりはしない。その代わり、たった一行（重要な行の一つではあったが）が期待に応えなくなるのを待っている。このいまいましい無料の、おおむね動作する、世界規模で接続されたネットワークを動かしているソフトウェアめ。使えねーな。
オープンソースとは、おおむね報われない仕事だ。Microsoft .NETコミュニティの場合、時々むなしくなったりもする。ボランティアが全然見つからないことがあるのだ。多くの人々が、デフォルトのものやVisual Studioに同梱されているものを使う。RailsとかNodeの場合は、企業の支援もあるが、プロジェクトはコミュニティが駆動しているという認識がある。現実は中間なのだが、Microsoftのスタック上に構築されたオープンソースプロジェクトでは、ボランティアが「我々は、出荷されたものをただ使うのみだ」なんて言うことがある。
マイクロソフトの過去の行動に対しては「怒り」が存在するけれども、前にも言ったように彼らは「長い」道のりを越えてきた。私はこれからもMicrosoftでオープンソースを推進していく。もう押すのは終わり！これ以上押せない！と思うまでは。内部では地殻変動が進んでいる。ミスはあったが正しい方向に進んでいる。誰もが学びの途中だ。
注目されるのは難しい
Jeremy Millerのチームは"FubuMVC"という.NETのオープンソースフレームワークのアクティブな開発を最近停止した。彼の最終的なブログ記事には、NETオープンソースの存続可能性に関する問題が書かれていた。
〝実にリアルな疑問、つまり.NETのOSSとは見込みがある計画なのかという疑問を置いておくとしても（答えはおおむね否だ、いくらScott Hanselmanが声を枯らしてそんなことはないと言おうともね）、FubuMVCは失敗した。なぜなら我々は――多分ほとんどは私のせいなのだ、なぜならこれまでのところ最も目立っていたのは私だからだ――自分自身を売り込み、ブログ記事やドキュメントやカンファレンスでの発表を通じてコミュニティを構築する努力が足りなかったからだ。〟
これはまさに真実をついている。多くのオープンソースプロジェクトにとっては、広い意味での可視性が存続可能性の元となっているのだ。Jeremyのふりかえりは素晴らしいのでぜひ読んでみてほしい。
大規模なフレームワークが既に存在しているところに、代替手段となるような大規模フレームワークのプロジェクトを立ち上げるのは難しいことだと思う。多くの人にとってはデフォルトを使用する方が簡単だからだ。FubuMVC、OpenRasta、ServiceStack、Nancyなどのようなフレームワークはすべて「新たにデフォルトを考え直した」ものだ。それらは（いい意味で）独断を行った大規模フレームワークなのであり、現状に甘んじないものたちだ。しかし、大規模フレームワークが支持者を育てるのは、HumanizerやJSON.NET のような小さなライブラリよりもはるかに難しいことだ。
それでも、こういったプロジェクトがなければ我々はみんなデフォルトを使用したままだっただろうし、コミュニティとして新しいアイデアを探求したり限界ギリギリを攻めたりすることはなかっただろう。F#のFAKEビルドシステムや、Chocolateyや、Boxstarterみたいには。
MicrosoftはOSSプロジェクトを今よりよい方法でサポートできる。単にライセンスやお金だけではなく、可視性においても。Microsoftの全カンファレンスで、オープンソースにトラックを提供するよう提案したい。オープンソースコミュニティのメンバーがしゃべる枠を作るのだ。DotNetConfが手始めだが、拡大していけるはずだ。
組織化は難しい
OWINが良い例だ。小さいけれどとても重要なプロジェクトで、.NET界に影響を与えている。しかし組織化に苦労している。それをうまくやることは将来のために重要になってきている。コミュニティの中に小さいけれども影響力を持っているグループがあり、彼らは妥協点を見つけて技術的な問題にまつわるコンセンサスを構築しようとする努力を数か月間続けてきている。
ASP.NET Web APIとSignalRはどちらもOWIN (Open Web Interface in .NET) というオープンソースプロジェクトの上に構築されている。OWINはサーバ、フレームワーク、およびミドルウェアの密結合を分離することが目的だ。
GitHub上に開かれたままのissueがある。その問題は曖昧だがOWINに関して重要な点をついているように思われる。OWINの仕様にはIAppBuilderというインタフェースは含まれていないが、Microsoftのサンプルコードのほとんどにおいて、IAppBuilderはデフォルトで使用されている。根底を支えるOWINフレームワークは中立を保つことができるのか？このissueは長く、何度か横道に脱線している。複雑な問題であり、完全に理解しているのはおそらく20人ぐらいだろう。
Scott KoonはOWINのガバナンスドキュメントに関して頑張っていたが、建設的な動きを目にすることはなかった。彼は不満をTwitterで漏らした。当然のことではある。よく使われる「怠惰なコンセンサス」の技では、人々が沈黙しているか72時間以内に返信しなかった時は、事実上同意したものと見なし、プロジェクトの方向性を変更することができる。積極的な関与こそが重要なのだ。
オープンソースの華はプルリクエストとコーディングだけれども、コードを作る前に合意を形成する必要がある。このプロセスの中で最も論争を生む部分は所有権だ。所有権とはコントロールのことだ。方向をコントロールすること。所有権の問題を通じて落としどころを見つけて作業するための鍵は、全員の異なる目標を徹底的に理解して共通のビジョンを見つけることだ。共通のビジョンによって、コミュニティが結集し前進できる。
このソーセージ製造工程は退屈な汚れ仕事だが、必要なのだ。OSSにおいてはコードが占めるよりも多くの部分をこれらの議論が占めている。押しと引きは同程度が必要だ。
関わることは難しい
私は毎週、何十通もの電子メールを受け取る。それらはすべて「オープンソースに関わるにはどうすればいいのでしょうか？」と尋ねるものだ。どうやら誰もが、私の回答は「コードを書け」とか「プルリクエストを送れ」とか、場合によっては「ドキュメント書きを手伝え」だろうと予想しているようなのだ。
実際には、やれることはそれがすべてではない。みんながやるべきことは、読むこと。吸収すること。理解すること。歓迎し、受け入れ、親切にすること。思慮深い分析を提供し、質問をすること。誇張や炎上を招くような言葉を避けること。issueにコメントする際はコード例を示すこと。人の手助けをすること。
ブログ記事はコミュニティを動かすエンジンなのである。オープンソースのコミットも、ドキュメント書きも、プロモーションも、サンプルも、講演も、コード片も、確かに重要なことだ。しかし、オープンソースに関わるということは、「プロジェクトをフォークして、あなたの世界観を反映する巨大なプルリクエストを送信する」ことを必ずしも意味しない。地味な作業が重要なことも時にはある。ガバナンスドキュメントを書いたり、電話会議をまとめたり、GitHubの巨大なissueのスレッドで質問をする前に徹底的に読んだりすることが。
なぜこんなことをするのか？モテるためでも金のためでもない。我々が構築者だからだ。誰でもぜひ参加してほしい。やるべきことはたくさんある。
