ステップ・バイ・ステップで説明しよう
さあ、どうしたものか。あなたは、プログラムをオープンソースにする利点と欠点を熟慮した上で、オープンソース・プロジェクトを始めるという結論に達した。しかし、どうしたらいいかさっぱり分からない。
もちろん、GitHubアカウントの作り方はお分かりだろうが、そういった手順は、オープンソース化に必要な作業のごく簡単な部分にすぎない。難しいのは、どうやったら人々が利用したいと思うようになるのか、貢献したいと思うようになるのか、ということだ。
この記事では、人々の関心を得られるプログラムを作成・リリースするためのいくつかの原則を挙げよう。
まずは基本
オープンソース・プログラムを選ぶ理由は様々だろう。例えば、アドバイスをくれるコミュニティーに参加したいからというものかもしれない。またはKnownのように、「社内開発者チームの力を引き出す、オープンソース・ディストリビューション」を求めているのかもしれない。
それとも、あなたは単にそれが正しい行動だと考えているだけかもしれない。イギリス政府がそう信じているように。
色々な理由があるだろうが、あなたがその理由の主体になることは決してない。オープンソースを成功させるためには、プランニングの大部分は必然的にソフトウェア利用者に関する事柄になる。筆者が2005年に書いたように、「多くの貢献（バグ修正や拡張など）を望む」なら、「良いドキュメンテーションを作成し、情報量が多いプログラミング言語を使用し…モジュラー・フレームワークを採用」する必要がある。
もちろん、あなた自身も人々が関心を持つようなソフトウェアを書かなければならない。
あなたが毎日の生活で依存しているテクノロジーについて考えてみよう。OS、Webアプリケーションのフレームワーク、データベースなどが一例だ。これらは特定の産業（例えば航空）向けのニッチなテクノロジーよりも、むしろ外野からの興味や貢献をはるかに得やすいものだ。テクノロジーが広く採用されるほど、コントリビューターや利用者は集まりやすくなる。
まとめると、オープンソース・プロジェクトには次のことが必要だ。
1. 適切な市場タイミング（市場のリアルなニーズを解決する）
2. 開発者とそれ以外のメンバーからなる一体感を持つチーム
3. 参加しやすい仕組み（詳しくは後述する）
4. 新規のコントリビューターが作業する部分を見つけやすくするためのモジュラー・コード。さもないとエベレストのような山積みのコードを読ませることになってしまう。
5. 広く適用可能なコード（あるいは、よりニッチなコードでそれを使う小集団に働きかける方法）
6. しっかりした初期ソースコード（ゴミのようなコードをGitHubに登録すると、ゴミのようなコードが返ってくるだけだ）
7. 寛容なライセンス。筆者は個人的にはApache式のライセンスが好きだ。開発者参加の敷居が非常に低いからだ。しかし、（LinuxやMySQLのような）成功を収めたプロジェクトはGPLライセンスを採用し、絶大な効果を上げているのも事実だ。
上記の項目を見れば分かるように、上手く参加者を集められないことが、時としてプロジェクトにとって最大の困難となりうる。それは大抵の場合、コードではなく人の問題である。
「オープンであること」はライセンスよりも重要
この分野で筆者が特に気に入った発言がある。テキサス州オースティン出身のユーザーエクスペリエンス＆インタラクション・デザイナーのヴィットリーオ・ミリアーノ（@vitor_jo）のものだ。ミリアーノが指摘するには、あなたのプロジェクトに関わったことがない人物はみな「素人」だ。その能力レベルに関わらず、あなたの書いたコードについてはほとんど知識がない、という意味で「素人」ということだ。
よって、ミリアーノの論によれば、あなたがやるべきとこは、敷居を下げ、プロジェクトに関わってもらいやすくすることだ。。彼はオープンソース・プロジェクトにおけるプログラマー以外の参加者の取り込みに焦点を置いている。そして、オープンソースでプロジェクト・リードが効果的に、あらゆる人材（技術者かどうかは関係ない）を取り込むために必要なものをいくつか挙げている。
1. プロジェクトの価値を理解してもらう方法
2. プロジェクトに付加できる価値を理解してもらう方法
3. プロジェクトに貢献することで得られる価値を理解してもらう方法
4. 貢献の手順（最初から最後まで）を理解してもらう方法
5. 彼らが普段作業しているワークフローに適した貢献の枠組み
世のプロジェクト・リードたちは、以上のうち5つ目に集中しがちで、1から4つ目をおろそかにしてしまう。貢献しようと思っている人にとって、貢献する「意義」に価値を見出せなければ、その「方法」が良くてもあまり意味がない。
そういうわけで、プロジェクトの価値を「難しい用語を使わずに説明すること」が極めて重要だとミリアーノは述べる。「誰がいつ読んでも有用な説明文を書くことで、アクセス性と一体感をアピールできる」というわけだ。さらに別の利点としては、そうすることでドキュメンテーションとコード内容が分かりやすいことを明示できることも重要だ、と彼は断言する。
2番目の項目では、プログラマーにしろそうでない人材にしろ、あなたが参加者に求めていることを正確に読み取れるようにしておく必要がある。そして、どの参加者がどの部分に貢献したかわかるようにしておかなければならない。MongoDBソリューション・アーキテクトのヘンリク・インゴが筆者にこう言った。「優秀な人物は素晴らしいコードをもたらしてくれるかもしれませんが、プロジェクト・メンバーがそれをきちんと理解できないことがあります」。そのような事態は、グループ内でコードを解明し、理解できれば酷い問題にはならない。
もっとも、いつもそれが可能とは言えないのだが。
あなたは本当にオープンソース・プロジェクトをリードしたいのか？
一体感をアピールするものの、それとはかけ離れたオープンソース・プロジェクトが多すぎる。他人にコードをいじられたくないというのなら、オープンソースの振りをするのはやめるべきだ。
そう、これは時として新入りをうんざりさせてしまう。Hacker Newsで、ある開発者がこんなことを書いている。
小規模プロジェクトには大量の、言ってしまえば、役立たずたちが集まってくる。付きっきりで手とり足とりしないと何も完成させられないようなド素人だ。それが彼らのためになっているのは理解できるが、どう考えても私にとって得ではない。コードを理解できないままコンピューター・サイエンスの修士号をなんとか修めたような奴らの世話に時間を費やしていたら、好きなことをする暇がなくなってしまう。だから、そういうのは無視している。
これは精神の健康のためには適切な対処と言えるが、プロジェクトが広くシェアされているのなら、あまり良いことではない。
あなたが本当にプログラマー以外からのデザイン、ドキュメンテーション、その他の貢献に少しも興味を持てないのなら、そのことを明確に述べよう。繰り返すが、その場合はオープンソース・プロジェクトにするべきではない。
当然、排他的に感じても実際はそうでないこともある。ActiveStateのVPを務めるバーナード・ゴールデンは、インスタント・メッセージで筆者にこう話した。「これから開発に加わりたい人々は、既存の排他的な開発者グループに委縮してしまいます。実際はそのようなグループではない場合も多いのです」
それでも、参加の意義を明瞭に説明することに力を注いで開発者を集めれば、貢献の方法は自然と定まるものだ。
トップ画像提供：Shutterstock
Matt Asay
[原文]
※本記事はReadWrite Japanからの転載です。転載元はこちら
