オープンソースのプロジェクトを成功させるために避けるべき12のこと

by opensource.com

情報に誰でもアクセスできるようにし、レシピを自由に改造・改変・再配布可能にすることでソフトウェアの発展をより容易にするオープンソースソフトウェアを開発するプロジェクトが世界中に存在しますが、オープンソースのプロジェクトを成功させる上で「根本的にオープンソースのソフトウェアをどう考えるべきなのか？」ということから「どのようなライセンスを使えばいいのか？」ということまで、OpenSolarisの失敗を例にとってエンジニアのBryan Cantrill氏がまとめています。

Corporate Open Source Anti-patterns
http://www.slideshare.net/bcantrill/corporate-open-source-antipatterns

スライドは以下から見ることが可能です。


2005年にサン・マイクロシステムズがオープンソースプロジェクトのOpenSolarisを設立し、システム情報取得機能DTraceのソースコードを始めとするさまざまなソフトウェアのソースコードを公開しだしました。OSとしてのOpenSolarisはこれまで独占されていたソフトウェアの情報をオープンな状態にするための大きな役割を果たしましたが、2010年にサン・マイクロシステムズがオラクルに吸収合併されてしまうと、OpenSolarisコミュニティに興味がなく、オープンソースに対しても関心を持っていなかったオラクルによって、OpenSolarisの歩む道が大きく狭まります。

2010年8月13日、「OpenSolaris is officially now dead.(OpenSolarisは公式に終わった)」という表現が含まれた文書を元にした情報が出回り、混乱が生じます。そしてオラクルはオープンソース化自体は維持するものの、いわゆるナイトリーコードの公開を取りやめることを明らかにしました。オープンだったシステムをクローズするオラクルの姿勢によって、コミュニティのメンバーはOpenSolarisからフォーク(分岐)する形で「OpenIndiana」を開設。オラクルの支援を受けずに現在に至るまで活動を続けています。

OpenIndianaはラテン語で「啓発、教化」を意味する「illuminare」とオペレーティングシステムの略である「OS」に由来する同業組合「illumos Foundation」傘下で運営されており、OpenSolaris build 27で実装が公開されたZFSやDTraceなどもCommon Development and Distribution License(CDDL)のもと開発が続けられました。そして設立から数年後にはOmniOSやSmartOSといったオープンかつ無料のOSを配布するなど、緩やかでありながら着実にコミュニティーは運営されています。

SolarisやOpenSolaris、そしてillumosは、オープンソースの力とクローズだったものをオープンにする挑戦についての、多くの教訓が含まれています。OpenSolarisに関して生み出された失敗は、悪意から生み出されたのではなく、あくまで善意から生み出されたものであり、「エラー」ではなく「アンチパターン」です。

ソフトウェアの開発元がオープンソースにするケースは多々ありますが、ではOpenSolarisから学ぶ「やるべきではないこと」は何なのか、エンジニアのBryan Cantrill氏がブラジルで開催されたFISLで講演した時のスライドに12のポイントがまとめられています。

◆01：真逆の考え方

by Dan Hatton

これは何かを作る上での自然な考え方なのですが、オープンソースソフトウェアについて「どれくらい利益が出るのか」ということを考えがちです。しかし、オープンソースにおいて利益は二の次、三の次であり、考えるべきなのは「どれくらいコストがかかるのか」ということなのです。基本的に、ソフトウェアは製造にコストがかかりません。例外的にコストが発生するのは、誰かがお金を払って商品化やサポートを求めた時だけです。

◆02：希望的観測

by Ngo Quang Minh

あなたのソフトウェアを使う人はあなたに対してお金を支払いません。大切なのは「あなたにお金を払うかどうか」ではなく「あなたのソフトウェアを使うかどうか」なのです。このことをしっかり理解すれば、オープンソースの二番目・三番目の利点に焦点をあてることが可能なはず。つまり、ソフトウェアにとって多くの人が利用するということは改良のために重要であり、金銭を得なくともたくさんの人にソフトウェアを使ってもらうことで多くのメリットがあるのです。

◆03：ソースがない

by nyuhuhuu

2011年12月にヒューレット・パッカードはwebOSをオープンソース化することを発表しましたが、ソースコードは公開されないまま、webOSは結局2013年2月に韓国のLG Electronicsに売却されました。企業がソースコードを公開しないで「オープンソース」を発表するということはしばしば起こりますが、これはばかげた間違いです。得るものは何もなく、信用を失うだけなので、このようなことは行わないように。

◆04：フォークされることを恐れる

by Mike Bailey-Gates

ソフトウェアが複雑で大がかりなものであるほど、フォークによって開発の労力が浪費されるのでは、という恐れが生まれます。しかし、フォークには「ソフトウェアをフォークするのが簡単であるほどコミュニティーをフォークするのが難しい」というパラドックスが存在し、複雑なソフトウェアであるほど実験者が反対者に成り下がり、フォークする人たち同士で終わりなき言い争いをしていたり、決別して終わってしまうのです。

オープンソースはフォークされることで活気が生まれるので、むしろ企業はフォークされることを推進するべきと言えます。

◆05：合意形成の過熱

by Tintin44

フォークされることを恐れるのはオープンソースのアンチパターンの中でも有害な行いの1つ。フォークするのが技術的に難しい時、コミュニティはソフトウェアに対して「賛同」を強いられます。もちろん人々は本当に賛同したわけではないので、グループの意思を決めるために合意が形成されるのですが、多数決が行わられれば「法律」と「負け組」が生まれてしまい、コミュニティーに不和が生じます。

企業がフォークされることを恐れなければ、コミュニティの合意形成が過熱することはなく、適切に活気づくというわけです。

◆06：偽の民主主義

by Mike Hiatt

コミュニティの民主主義をマヒさせたり無くしたりするよりも悪いのは、偽の民主主義を作り上げることです。オープンソースと民主主義は密接な関係にありますが、企業は「コミュニティーに民主主義を与えなければならない」と考えるべきではありません。民主主義は上から行われるものではないのです。

◆07：リーダーシップを避ける

by Kevin Bond

よいオープンソースプロジェクトにはよいリーダーシップがあるもの。合意形成は大切ですが、合意が作られない時、リーダーシップが必要になります。

企業はプロジェクトにおいてリーダーシップを発揮することを恐れるべきではありません。よいリーダーシップとは優しい終身の独裁者(Benevolent Dictator For Life／BDFL)のB、つまりBenevolent(慈悲深さ)を意味します。そのためには、技術的なリーダーである従業員に可視性を与えることが必要。当たり前のことですが、「企業が改革するのではなく、人々が改革する」のです。

◆08：所有を避ける

by Crazy Cake Lady

オープンソースのソフトウェアを財団化することは一見よいことのように見えますが、実際のところ複雑で、税金の免除を受けるためには独立取締役や資本が必要になります。また、財団化するということは企業が技術的にソフトウェアから離れることを意味し、技術的にもそれ以外の意味でもデメリットが多いのが現実。アメリカで「ソフトウェアを財団化する」ということは法的にリーダーシップを放棄することなので、ソフトウェアの所有権はしっかりと持っていましょう。

◆09：競争狂になる

by Louis

自分の企業がオープンソース化する前に他の企業がオープンソースにしてしまう、と考えてしまうかもしれませんが、自分が「あの企業はクソ」と思っているように相手も自分の企業のことを「あの企業はクソ」と思っているので、基本的に技術が盗まれてしまうことはありません。

また、既存の製品などを発祥が異なることを理由に利用・購入しない社会をNIH(ここで発明したものではない)症候群であると言いますが、フリーソフトウェア・コミュニティではNIHの傾向が強いので、ライバルが盗んだ技術を適用してもうまくいかずに倒産してしまうでしょう。

◆10：共同ライセンスを避ける

競争狂的な自分の性質に立ち向かうには、あえてGPLバージョン2ライセンスやAGPLライセンスといったコピーレフトのライセンスを使うという方法もあります。しかし、全ての者が著作物を利用・再配布・改変できなければならないというコピーレフトの考え方は面白い試みではありますが、大抵の場合はライセンスが役に立ちません。

実際のところ、GPLバージョン2やAGPLの利用率はApacheやBSD・MITの利用率の増加に伴い減少していっています。

GitHubで最も注目されているプロジェクト上位50個を見ても、GPLやAGPLを使っているものは非常に少なく、MITやBSD、Apacheライセンスを使っているものがほとんどを占めています。コピーレフトのライセンスを使いたい場合は、MPLのようなコピーレフト性が弱いものを使用するのがお勧め。

◆11：利益のためにデュアルライセンスを使う

by Louis

「フリーかつオープンソフトウェアのバージョンを無料で配布し、商用ライセンス版を法人に提供することで利益を得る」という方法でデュアルライセンスを利用する企業を見かけることがあります。しかし、これはコピーレフトライセンスに対する不確かな恐怖心を周囲に広げるだけです。デュアルライセンスは商業利用に厳しい制限のあるライセンスを寄贈する時のみに使うべき。

◆12：厳しい条件でのライセンス譲渡

by JD Hancock

オラクルのようなオープンソースに親和性がない企業もあるので、要求の多いライセンスの譲渡には注意する必要があります。コピーライトの譲渡はすでに確立したプロジェクトの場合は意味があるものとなりますが、それでも社会契約と同じように扱わなければなりません。また、コピーライトの譲渡がコミュニティーにひずみを生み出さないように注意しましょう。

なお、スライドを使った講演の様子は以下のムービーから見ることが可能となっています。

Corporate Open Source Anti-Patterns: Doing It Wrong - YouTube


オープンソースは消費者的にも発明する側的にも非常に重要なもの。上記の点は必ず守らなければならないものではなく、状況次第で変更してもOKだとのことです。