オープンソースとは”なに”であり、”なぜ”それを行うのか
さて、あなたはオープンソースを始めようと考えているのですか？おめでとう！世界はあなたのコントリビュートに感謝します。オープンソースとはなんであってなぜ人々はそれを行うのかについて話しましょう。
「オープンソース」が意味するものは？
あるプロジェクトがオープンソースである時、それは誰でも自由に使って、学び、修正して、あなたのプロジェクトをいかなる目的であっても配布できるということを意味します。これらの行為を許可するということはオープンソースライセンスに定められています。
オープンソースは採用とコラボレーションの敷居を下げ、プロジェクトをすぐに広め、改善することを可能にするため強力です。また、クローズドソースと比べて、ユーザーに処理の内容を自分で制御できる可能性を提供することもオープンソースの特徴です。例えば、企業にとっては、クローズドソースのベンダーの製品に依存するのではなく、オープンソースソフトウェアに独自のカスタマイズを加えるようエンジニアを採用するという選択肢を提供します。
フリーソフトウェア という言葉も オープンソース と同じくプロジェクトを指します。ときにはこれらの言葉を合わせて「free and open source software」 (FOSS) や「free, libre, and open source software」 (FLOSS) と呼ばれているのを目にするかもしれません。 Free や libre は自由を指しているのであって、無料を指しているわけではありません。
なぜ人々は彼らの成果をオープンソースにするのか？
人々や組織がオープンソースプロジェクトを始めるには様々な理由があります。いくつか例を挙げてみましょう：
-
コラボレーション： オープンソースプロジェクトは世界の誰からも変更を受け付けます。例えば Exercism は、350を超えるコントリビューターがいるプログラミング練習プラットフォームです。
-
取り入れて再構成： オープンソースプロジェクトは誰しもがほとんどいかなる理由のためにも使えるものです。人々は他のものを作るためにでも使うことができます。例えば WordPress は、 b2 と呼ばれる既存のプロジェクトのフォークとして始まりました。
-
透明性： 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性はブルガリアやアメリカのような政府、銀行やヘルスケアのような規制産業、 Let’s Encrypt のようなセキュリティソフトウェアにとって重要です。
オープンソースはソフトウェアのためだけのものでもありません。データセットから本まであらゆるものをオープンソースにできるのです。他になにかオープンソースにできるものはないかアイデアを得るために GitHub Explore をチェックしてみましょう。
オープンソースは「無料で使える」事を意味している？
オープンソースの大きな魅力の一つがお金がかからないということです。しかし、「無料で使える」ことはオープンソースの全ての価値の副産物でしかありません。
オープンソースライセンスが要求しているように、誰でも使え、修正でき、どんな目的でも共有できるため、プロジェクト自身は無料で使える傾向にあります。もしそのプロジェクトが使うのにお金がかかるとしたら、誰でも合法的にそのコピーを作って無料のバージョンを代わりに作ることができます。
結果として、ほとんどのオープンソースプロジェクトは無料です。しかし、「無料で使える」ことはオープンソースの定義には含まれていません。オープンソースプロジェクトでも、デュアルライセンスや機能制限によって間接的に料金を取る方法はあります。これでもまだオープンソースの公式な定義に則っています。
自分自身のオープンソースプロジェクトを立ち上げるべき？
簡単な答えとしてはイエスです。なぜなら、成果がどうであれ、あなた自身のプロジェクトを立ち上げるのはオープンソースがどうやって成り立っているのかを学ぶ素晴らしい方法だからです。
もし今までプロジェクトをオープンソースにしたことがないのであれば、他の人から何を言われるか、誰も全く気づいてくれないんじゃないかと心配になっているかもしれません。もしあなたがそうだとしたら、あなたは一人ではありません！
オープンソース活動は他の執筆や絵画などのクリエイティブな活動を似ています。世界にあなたの作品を公開するのは怖いと感じるでしょうが、上達する唯一の方法は練習することなのです。たとえ、誰も見ている人が居ないとしても。
もしまだ納得していないのであれば、あなたのゴールがどういったものであるかを少し考えてみましょう。
ゴールを設定する
ゴールを設定することによって、何をやるべきか、なににノーというべきか、他の人の助けが必要な箇所を明確にすることができます。私はなぜこのプロジェクトをオープンソースにしたのか？ と自問してみましょう。
この質問に唯一の正解はありません。一つのプロジェクトに対して複数のゴールがあるかもしれないし、異なるプロジェクトで異なるゴールがあるかもしれません。
もしあなたのゴールがあなたの作品を見せびらかすことだけなのであれば、コントリビュートは望まないでしょうし、 README で表明すべきです。その一方で、コントリビューターを望むであれば、明確なドキュメントと新しく来た人が歓迎されていると感じるように時間を投資するでしょう。
あなたのプロジェクトが成長するにつれて、コミュニティがあなたに求めるものはコードを書くことだけではなくなるでしょう。イシューに返答したり、コードをレビューしたり、あなたのプロジェクトがオープンソースプロジェクトにとってとても重要なタスクなのであると説いて回るといったことです。
コーディング以外のタスクに費やす時間はあなたのプロジェクトのサイズと範囲に依存する一方で、メンテナーとしてそういった活動に取り組む準備をするか手伝ってくれる人を見つけるべきです。
もしあなたが企業でプロジェクトをオープンソースにすることに携わっているのであれば、 あなたのプロジェクトが盛り上がるのに必要な企業内部のリソースを持っているかどうか確かめましょう。立ち上げた後にプロジェクトをメンテナンスする担当の人は誰で、コミュニティとどのようにタスクを共有するのかを特定したいと思うでしょう。
プロジェクトの推進と運営、メンテナンスに予算と人員が必要なのであれば、その会話は早めに始めましょう。
他のプロジェクトにコントリビュートする
もしあなたのゴールが他の人とコラボレーションする方法を学んだり、オープンソースがどうやって機能しているのかを理解することなのであれば、既存のプロジェクトにコントリビュートすることも考えてみましょう。あなたが既に使っていて気に入っているプロジェクトから始めましょう。プロジェクトにコントリビュートするのは誤植を直したり、ドキュメントを更新したりといったシンプルなものでもよいのです。
コントリビューターとして活動し始める方法がわからないのであれば、オープンソースにコントリビュートする方法をチェックしてみて下さい。
あなた自身のオープンソースプロジェクトを立ち上げる
あなたの作品をオープンソースにするのに完璧なタイミングはありません。アイデアや作業中のもの、クローズドで何年も経ったものであってもオープンソースにできるのです。
一般的に言って、他の人があなたの作品をみて、フィードバックをくれることに対して苦痛がないのであれば、あなたのプロジェクトをオープンソースにするべきです。
あなたのプロジェクトをオープンソースにするのがどの段階であれ、全てのプロジェクトは下記のドキュメントを含んでいるべきです：
メンテナーとして、これらの要素は期待値をコミュニケーションし、コントリビュートをマネジメントし、すべての人（あなた自身も含む）の法的権利を守る助けになります。これらによってあなたが良い経験を積むことができる可能性を大幅に増やします。
もしあなたのプロジェクトが GitHub 上にあるのであれば、これらのファイルを推奨されているファイル名でルートディレクトリに置くことで、 GitHub がそれを認識し、見ている人に自動的に表示してくれます。
ライセンスを選ぶ
オープンソースライセンスは、他の人が恐れを感じることなくあなたのプロジェクトを使い、コピーし、修正し、コントリビュートする事を保証します。また、あなたを法的な面倒事からも守ってくれます。あなたがプロジェクトをオープンソースにするときは必ずライセンスを含めるようにしましょう。
法的な作業は楽しくはありません。既存のライセンスをあなたのリポジトリにコピーペーストできるというのは良い知らせでしょう。あなたの大事な作品を守るのに1分しかかかりません。
MIT や Apache 2.0 、 GPLv3 が最も有名なオープンソースライセンスですが、他の選択肢もあります。
GitHub 上に新しいプロジェクトを作るときは、ライセンスを選択する選択肢が表示されます。オープンソースライセンスを含めることで、あなたの GitHub プロジェクトはオープンソースになります。
オープンソースプロジェクトを管理する上での法的な面でまだ疑問や懸念があるのであれば、こちらを参照して下さい。
README を書く
README はあなたのプロジェクトをどうやって使うかを説明するだけにとどまりません。そこでは、なぜあなたのプロジェクトが重要なのか、そしてユーザーはあなたのプロジェクトで何ができるかということも説明するためのものです。
README には、下記の質問に答えるようにしましょう：
- このプロジェクトは何をするものなのか？
- なぜこのプロジェクトは便利なのか？
- どのようにして使い始められるのか？
- もし必要な場合、どうやったら助けを得られるか？
README では、コントリビュートをどのように扱うか、プロジェクトのゴールはなにか、ライセンスや帰属についての情報などといった他の疑問に答えるのに使うこともできる。もしコントリビュートを受け入れたくなかったり、あなたのプロジェクトは運用に乗せる準備が整っていなかったりする場合は、その情報も書きましょう。
時々、プロジェクトが未完了であったりコントリビュートを求めていないといった理由で README を書くのを避ける人が居ます。これらも README に書いておくと良いでしょう。
さらなるヒントとしては、完全な README を書くために @18F の “Making READMEs Readable” か @PurpleBooth の README template を読んでみると良いでしょう。
README ファイルをルートディレクトリに置くことで、 GitHub が自動的にリポジトリのホームページに表示してくれます。
コントリビュートのガイドラインを書く
CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参加するのかを伝えるためのものです。例えば、下記の様な情報を含めると良いでしょう：
- バグレポートの登録の仕方 (イシューやプルリクエストのテンプレートを使ってみましょう)
- 新しい機能の提案の仕方
- 環境のセットアップとテストの実行の仕方
技術的な詳細に加えて、 CONTRIBUTING ファイルはコントリビュートに対する期待値を伝える機会でもあります。例えば：
- あなたが求めているコントリビュートの種類
- プロジェクトのロードマップやビジョン
- コントリビューターがどのようにしてあなたにコンタクトすべきか（もしくはすべきでないか）
暖かく友好的なトーンを使って、（ドキュメントを書く、もしくはウェブサイトを作る、といったような）コントリビュートを具体的に提示することで、新しく来る人が歓迎されていて是非参加したいと思ってもらうのにとても役に立ちます。
例えば、 Active Admin はコントリビュートガイドを下記の内容から始めています：
まずはじめに、 Active Admin へのコントリビュートを考えてくれてありがとうございます。あなたのような人々が Active Admin を偉大なツールにしているのです。
あなたのプロジェクトの最初期では、 CONTRIBUTING ファイルはシンプルで大丈夫です。常にバグの報告の仕方かイシューの登録の仕方、コントリビュートをする際の技術的な要求（テストなど）を書くようにしましょう。
時間が経つにつれて、 CONTRIBUTING ファイルに頻繁に聞かれる質問を加えるでしょう。こういった情報を書くことによって、同じ質問を何度も繰り返ししてくる人が減っていくでしょう。
CONTRIBUTING ファイルを書くときに更に役に立つものとして、 @nayafia の contributing guide template や @mozilla の “How to Build a CONTRIBUTING.md” も参考になるでしょう。
README に CONTRIBUTING ファイルへのリンクをすることで、より多くの人の目に触れるようになります。 CONTRIBUTING ファイルをプロジェクトのリポジトリに置くことで、 GitHub でコントリビューターがイシューを登録したり、プルリクエストをオープンする際に、そのファイルへのリンクが自動的に表示されます。
行動規範を定める
最後に、行動規範はあなたのプロジェクトの参加者の行動に対する基本原則を設定する助けになります。これは特にあなたがコミュニティや会社のためのオープンソースを立ち上げる時に役に立ちます。行動規範は健康的で生産的なコミュニティの振る舞いを促進する助けになります。そして、あなたのメンテナーとしてのストレスを減らしてくれるでしょう。
更に情報が必要な場合は、行動規範ガイドを見てみましょう。
プロジェクトの参加者に どう 振る舞ってほしいかを伝えるのに加えて、行動規範では期待される行動が、誰に対して、いつ適用され、違反した場合には何をすべきなのかについても記載される傾向があります。
オープンソースライセンスによく似ていますが、行動規範にもスタンダードが出てきています。なので、あなた自身で書く必要はありません。 Contributor Covenant はカジュアルに使うことができる行動規範で、40,000を超えるオープンソースプロジェクトに使われており、そこには Kubernetes 、 Rails や Swift も含まれます。どの文書を使うにしても、必要なときにはあなたの指針に従わせる準備をしておくべきです。
あなたのリポジトリの CODE_OF_CONDUCT ファイルに文書を直接貼り付けましょう。そのファイルをプロジェクトのルートディレクトリに置いておくことで、簡単に見つけることができ、 README からリンクすることができます。
あなたのプロジェクトに名前とブランドを付けよう
ブランディングは華やかなロゴやキャッチーな名前以上のものです。それは、あなたのプロジェクトについてどう紹介し、あなたのメッセージが誰に届くのかということなのです。
適切な名前を選ぶ
覚えやすい名前を選びましょう。理想的には名前からそのプロジェクトが何をするのかがわかるようにしましょう。例：
既存のプロジェクトに基づいて開発しているのであれば、その名前を頭につけることであなたのプロジェクトが何をするものかを明らかにする助けになります（例えば、 node-fetch は Node.js に window.fetch を追加するものです）。
明快さを第一に考えましょう。ダジャレは面白いですが、ジョークは他の文化やあなたとは異なる経験を持った人には通じないこともあるということを覚えておきましょう。潜在的なユーザーには企業の従業員もいるかもしれません。彼らがあなたのプロジェクトについて職場で説明する時に居心地の悪い思いをさせたくはないでしょう。
名前の衝突を避ける
同じような名前のオープンソースプロジェクトを調べましょう。同じ言語やエコシステムを共有する場合は特にです。もし既存の有名なプロジェクトと名前が同じ部分があると、外から見た人を混乱させてしまうでしょう。
ウェブサイトや Twitter のハンドルや他であなたのプロジェクト名を使いたいのであれば、使いたい名前を使えるかどうか確かめましょう。理想的には、心の平穏のためにすぐにそれらの名前を予約しましょう。たとえ、今すぐに使うつもりがないとしても。
プロジェクトの名前が商標の侵害をしていないか確かめましょう。後になってある企業があなたのプロジェクトをやめるように言ってきたり、法的措置さえしてくるかもしれません。そんなリスクは見合いません。
商標を侵害していないかを調べるには WIPO Global Brand Database を確認しましょう。もし企業にいるのであれば、この点は法務部門が助けてくれることの一つでしょう。
最後に、あなたのプロジェクト名で Google 検索をしてみましょう。人々は簡単にあなたのプロジェクトを見つけることができるでしょうか？検索結果の中になにか望ましくないものが表示されていないでしょうか？
文書（やコード）の書き方はあなたのブランディングにも影響します！
あなたのプロジェクト全体を通して、多くの文書を書くでしょう： README 、チュートリアル、コミュニティドキュメント、イシューへの返答、もしかしたらニュースレターやメーリングリストもあるかもしれません。
公式のドキュメントであれ、カジュアルなメールであれ、あなたの文書のスタイルはプロジェクトのブランドの一部になります。見る人にどのようにして伝わるかや、あなたが伝えたいトーンかどうかを検討しましょう。
暖かく、排他的でない言葉遣い（一人の人を指すときであっても「彼ら」を使う、といったような）をすることで、あなたのプロジェクトで新しいコントリビューターが歓迎されていると感じてもらうことに繋がります。シンプルな言葉遣いをすることにこだわりましょう。あなたのプロジェクトを見る人の多くは英語のネイティブスピーカーではないかもしれません。
あなたがどう文書を書くかに加えて、あなたのコーディングスタイルもプロジェクトのブランドの一部になるかもしれません。 Angular と jQuery の2つは厳密なコーディングスタイルとガイドラインを持つプロジェクトの例です。
かならずしもプロジェクトを始める際にスタイルガイドを書く必要はありませんし、とにかく異なるコーディングスタイルを盛り込むのが楽しいと思うかもしれません。しかし、あなたの文書やコーディングスタイルが異なるタイプの人々を惹きつけることもあれば落胆させることもあるということを予期しておくべきです。プロジェクトの最初期はあなたが望む先例を作る良い機会です。
立ち上げ前のチェックリスト
あなたのプロジェクトをオープンソースにする準備が整いましたか？ここにあなたの助けとなるよう、チェックリストを用意しました。全てにチェックが付きましたか？そうであれば準備万端です！ “publish” をクリックして、自分を褒めてあげましょう。
ドキュメント
コード
人々
もし個人でやっているのであれば：
企業や組織でやっているのであれば：
やりました！
おめでとう！あなたの最初のプロジェクトをオープンソースにしました。成果はどうあれ、公の場で働くことはコミュニティへの贈り物です。あらゆるコミット、コメント、プルリクエストによって、あなた自身や他の人が学び、成長する機会を提供しているのです。
