オープンソースは業務上のスタンダードになった。しかしそうする事が必ずしも正しいわけではない
出てきた時は「ガンのようなもの」であり「反アメリカ的」だと散々に言われたオープンソースは、今日アップルパイと同じくらい「アメリカ的」（そして資本主義的）な物となった。皆が利用し、フェイスブックの様な大企業が開発プラクティスに取り入れている。今日びオープンソースの価値に疑問を抱くものはいないだろう。
しかし面白いことに、あなたのソフトをオープンソース化するべきかどうかは決して明らかではない。自分のコードをコミュニティと共有する前に、考慮しなければならないポイントを以下に紹介する。
よくある思い込み
オープンソースに馴染みがある人もそうでない人も、「コミュニティー」という言葉は聞いたことがあるだろう。コミュニティーを怒らせてはいけない、コードをオープンにすればコミュニティーは多くのソースをコミットしてくれる、コミュニティーとはハッカーたちのゆるい寄り集まりだ、等々よく耳にするだろうが、これらは云わばナンセンスだ。
ジョン・マーク・ウォーカーが数年前に主張したように、まず「オープンソース・コミュニティー」などというものはない。そうでなく、「オープンソース」とは「コミュニティー」の寄り集まりだ。その性質はコミュニティーごとに大きく異なる。
たしかにオープンソースで成功しているコミュニティーには一連の傾向はある。しかしそれらの傾向を踏まえても、プロプライエタリなプロジェクトでもマーケティングのタイミングが重要であるように、成功には運も必要だ。また単に、「ソースを公開したから人が集まってくる」という思い込みも禁物だ。
なぜか？なぜなら全てのオープンソース・プロジェクトは多くの小規模な献身的な開発者グループからコードの貢献をうけており、ほとんどのオープンソース・プロジェクトは創設時以上の開発者を集める事無く、一年以内に解散してしまっているからだ。
（ところで、「献身的」というのはこの活動でギャラが発生している開発者を言い表すのにいい言葉だ。たとえばAlfrescoのような商業的なプロジェクトにおいて、無償でフルタイムの活動ができるのは数えるほどしかいない）
GPLとApacheライセンスの支持者同士の争いを耳にしたことをない人はいないだろう（著者はGPL、Apacheどちらについても過去に述べている）。ライセンス論争については決着がついた。Apache側の勝利だ。GitHub世代が流行の指標であるとすれば、私の言っていることは正しいと思う。「ライセンスなんかない」というライセンシングが受け入れられたのだ。
オープンソースにしない理由
オープンソースはすべてに有効な万能薬ではない
ますます多くの開発者たちがライセンスの問題について飽き飽きしているなか、自分のコードをオープンにするためのコストは馬鹿にならない。
例えば、コードを公開するにあたり、まず自分が困った立場にならないように立ちまわる必要がある。ある時、プロプライエタリな大企業に務めていた、MongoDBのエンジニアと話すことがあり、その時彼がいったのは、プロプライエタリとオープンソースの一番の違いは品質だということだ。
彼の経験によれば、プロプライエタリなソフトウェアは納期に間に合わせるために書かれているという。コードの質がどうであれ、重要なのは納期に納品できることである。一方オープンソースの場合は、これでOKという状態になるまでリリースされない。商業的な理由でリリースの圧力がかかることがあってもだ。
こういった対比が完璧に当てはまらないにしても、基本的に言ってることは正しいはずだ。もし自分のコードが人目にさらされる事になれば、ライセンスによって公開されることが無いときよりも、その品質を確かなものにするはずだ。
これはオープンソースソフトのユーザーにとっては素晴らしいことだが、これは前述のライセンスおよびリリースの問題にとどまらない。マット・ハリソンが言うように、ソースをオープンにすると言うことは、自分のコードがモジュール化されており、ドキュメントが整っており、他の人が作業に入りやすいようにするため、より時間を取られるということでもある。
もしこれらの問題がクリアされたとして、逆にあなたはそのプロジェクトに参加しようと思うだろうか？ノア・カントロヴィッツは、Chef Incを名義だけのオープンソース・プロジェクトだと批難している。
Chef Incには莫大な資金と時間が費やされた。少数の企業と更に少ない個人からの貢献をうけ、多くのコンシューマーが残された
このような現実において、オープンソースである事が重要だろうか？私はそれでもYesと言いたい。しかしここでハッキリしておきたいことは、ビジネスモデルとしてハードルが高くなるということである。
オープンソースにするという事は多くの場合、容易に得られる収入が絶たれるということを意味する。DropboxがGoライブラリをオープンソースに出来たのは、彼らのビジネスモデルがそれを販売する事に依存していなかったからだ。しかし例えば顧客管理システムをオープンソース化するとすれば、そのビジネスモデルに与えるインパクトは多大なものになるだろう。
マーク・アンドレッセンの以下の皮肉は多くのリツイートを集めた。
“The best minds of my generation are thinking about how to make people buy support contracts for free software.” –Anonymous
— Marc Andreessen (@pmarca) Jun 16, 2014
マーク・アンドレッセン(Marc Andreessen)：「私たちの時代では、どのようにフリーソフトのサポート契約をとるかばかり考えていた（匿名）」
もし過去に同じようなことを試したことがあるのなら、この一文は面白くもあり悲しくあるだろう。
もしあなたがDropboxの様なモデルで上手くいっており、コミュニティーを惹きつけるためにソースをオープンにするとしても、現実は残酷なもので、ほとんどのプロジェクトにおいて、参加者がもつ時間はあくまで彼らのものだ。
ではオープンソースにする意味とは？
これまでを踏まえて、なぜソースをオープンにする意味があるのだろう。
OSやDBなどのインフラ系ソフトを書いたとすると、他に選択の余地はない。Clouderaの協業設立者、マイク・オルソンによれば、
エンタープライズなインフラには、もう引き返しの付かない流れがある。もしデータセンターを運営するとしたら、オープンソースなOS、DB、ミドルウェア等を必ず使うことになる。プロプラエタリなソフトで主流になり得たものは、ここ10年は出てきていない。
もし自分のプロジェクトが注目を集めたいのであれば、ソースはオープンにするに越したことはない。好き嫌いはともかく、「オープン」であるということは、開発者から理解を得る何よりの手段だ。
いくつかの成功しているプロジェクトにおいて、オープンソース・ライセンスは「安上りで導入が楽（例：AmazonのWebサービス）」とか、ティム・オライリーがいうように「安上りですぐできる」という事を達成するための簡単なショートカットになりつつある。
オープンソースには揉め事無くコードをシェアすることで技術者を集めるための元手のかからない広告になるなど、他のメリットもある。ある日、オープンソースの開発者コミュニティ―と話した時、ソースをオープンにすることで個人的な自由も得られるということがわかった。トニー・ヤルッソによれば：
@mjasay Convincing employer to let me put an OSS license on work product means I can use those scripts personally and at future jobs.
— Tony Yarusso (@TonyYarusso) Jul 4, 2014
マット・アサイ(Matt Asay)：「ソースをオープンにする理由、もしくはしない理由を教えてください」
トニー・ヤルッソ(Tony Yarusso)：「雇い主に今仕掛かってるプロダクトをオープンソースにさせる事を理解してもらうことで、それを個人的に使うことも出来、次の仕事をみつける助けにもなるからです」
また（自己満足かも知れないが）ポール・ラムゼイによると、
@mjasay “Someone else might find this useful, and then think I’m cool.” #amended
— Paul Ramsey (@pwramsey) Jul 4, 2014
マット・アサイ(Matt Asay)：「なぜソースをオープンにするのですか？ もしくはしないのですか？」
ポール・ラムゼイ(Paul Ramsey)：「自分が作ったものを誰かがいいねと思ってくれたら最高じゃないか」
こう言った個人的な理由のほかに、もし大手ベンダーをひっくり返してやろうと考えているのならば、オープンソースはそういったベンダー達を慌てさせるのに他とない手段となり得る。
ともあれ、オープンソースとは楽しいものだ。自分自身、オープンソース系の会社に15年ほど務めている。そこで目にするのはまずコードをシェアする仲間との共有意識とコラボレーションだ。そうだ、忘れてはいけない、口喧嘩もしょっちゅうある。でもこうすることでコミュニティーは良くなっていくのだ。
オープンソースでないということが完璧でないという訳ではない。しかしこれまでの個人的経験から言わせてもらえば、オープンであるということはあらゆるソフトウェアの基準であるべきだと思う。あなたにもそう思ってもらえるとうれしい。
トップ画像提供：Shutterstock
Matt Asay
[原文]
※本記事はReadWrite Japanからの転載です。転載元はこちら
