オープンソース プロジェクトを立ち上げる

企業は、長期に渡ってオープンソース コミュニティに参加し、良い評価を確立したとき、企業独自のオープンソース プロジェクトを立ち上げることが可能になります。オープンソースへの参加がこの段階に達した時、企業はオープンな協業から得られる大きなメリットを実感できるのです。企業は、コミュニティで活用される可能性のあるプロプライエタリなプロジェクトをオープンソース化することができます。もうひとつのやり方は、新規のオープンソース プロジェクトをスクラッチから作り上げ、最初から外部開発者の協業のメリットを得るやり方です。

本ガイドの目的は、すでにオープンソースに関して十分に経験を積んだ企業の方々を対象に、企業独自のオープンソース プロジェクトを立ち上げるために知るべきことを学ぶ手助けとなることです。本ガイドでは、何をオープンソース化するかを決定することから始めて、予算や法的な考慮事項に至るまで、すべてのプロセスを案内します。オープンソース プロジェクトを作り上げることは、かつて経験したことのないことかもしれませんが、Google、IBM、Facebook、Twitter、Microsoftのような大企業は、後に続く人々のために道を開いてくれています。本ガイドの的確で有益なアドバイスを参考とし、自らの道を進んで下さい。

内容

  1. なぜオープンソース プロジェクトを作るのか
  2. いつオープンソース プロジェクトを作るか
  3. どこから始めるか
  4. プロジェクトの計画作り
  5. オープンソース プロジェクトの始動
  6. 結論
  7. オープンソース プロジェクト始動のチェックリスト

ガイド一覧 » GitHub上で貢献する »

このガイドの貢献者

Christine Abernathy Facebook オープンソース チーム 開発者アドボケイト

Ibrahim Haddad Samsung Research America R&D部門VP兼 オープンソース グループ長

Guy Martin Autodesk Open@ADSKディレクター

John Mertic The Linux Foundation プログラム管理 ディレクター

Jared Smith Capital One オープンソース コミュニティ マネージャー

セクション 1

なぜオープンソース プロジェクトを作るのか

企業にはオープンソース プロジェクトを立ち上げるたくさんの理由があります。すなわち、敏速な技術革新を狙い、早期市場参入を成し遂げ、新たなアイデアを収集し、相互運用性や業界標準を実装し、才能ある開発者を採用し、より優れたソフトウェアや製品を開発するために広汎な知見と貢献を集めることです。

このようなメリットはすべて、企業の外で作られ、運営されるオープンソース プロジェクトを利用したり、貢献したりすることによって実現されます。しかし、広い意味でのオープンソース戦略は、企業が自身でオープンソース プロジェクトを作り、立ち上げることも含む場合が多くあります。

プロジェクトを始めること、あるいは、既存プロジェクトをオープンソースとしてコミュニティに公開することは、「ギブ・アンド・テイク」への意識を高め、そのことがオープンソース コミュニティにおける企業の良好な評価をもたらし、企業がオープンソース開発者に魅力的に映り、また、企業の貢献するオープンソース プロジェクトに大きな影響力を持つことに繋がります。また、企業の持つコードベースを議論の開始点として公開することで、外部のパートナー、ベンダー、あるいは、ユーザーのエコシステムとの関係が強化され、さらなる利益を生み出すことになります。

企業のコードと開発手法を外部の利用と貢献に向けて公開することにより、企業は本当にオープン イノベーションを取り入れ、企業のビジネスに対する最大限の効果とみなされるまでオープンソースを活用したことになります。オープンソース ライセンスの下で公開されたコードは、誰でもそのコードに貢献したり、調査したり、変更したり、改善したりすることを許容します。このような開発の協業アプローチは、今やソフトウェア開発の実質的な標準となり、技術革新の推進力となっていると広く認識されています。

この状況は、企業の活動分野が、金融サービスであろうと、ヘルスケアの提供であろうと、トラック輸送の運用であろうと、店舗やオンラインでの小売りであろうと、通勤者や航空機搭乗者向けの移動手段の提供であろうと、道路や橋梁の建設であろうと、あるいは、その他何千にも及ぶ専門分野であろうと当てはまります。このような企業でも顧客に提供する価値の中核となるアプリケーションやテクノロジーは社内に保持することを望むでしょう。しかし、一方で、必要性はあるものの、企業にとって差別化要因とするほどの高い価値は認められないような無数のコードやソフトウェアも存在します。このようなテクノロジーを外部の貢献者に向けて公開することによって、当該コードの成長と強化の新たな可能性と機会が作りだされます。

「どんなにたくさんの優れた技術者を会社が雇用しようと、会社外にはもっと優れた技術者がいつも存在します。専門性があり、しかも喜んで私たちと一緒にコードの改善に取り組んでくれる外部の開発者の素晴らしいアドバイスと引き換えに、ソースを公開し、外部世界とコードを共有することには、私たちに大きな価値があることが分かりました。」

Jared Smith – Capital One オープンソース コミュニティ マネージャー

企業は、社内で必要な人材を供給できないような領域で何らかの計画を前に進めようとするときに、オープンソースに期待します。オープンソースに移行することにより、開発スピードを上げ、同じ目標を目指すソフトウェアの開発に向けて活動する人々と協調することができ、同時にコストを削減し、最終製品の価値を高めることができます。

オープンソース プロジェクトは、同じ業界の競合企業との間においてさえ、協調の自由をもたらします。また、開発中のコードに多くの人々の着眼を得て開発を加速させることができます。一緒に働くことにより、開発者は、オープンに情報を共有し、多くのフィードバックを受け、そして、拡張性、効率、品質において優れたコードを構築できます。

企業が新規にオープンソース プロジェクトを立ち上げる5つの理由

  1. オープン ソリューションの加速；標準規格に対するリファレンス実装を提供。戦略的機能に対する開発コストの共有。
  2. 市場をコモディティ化；非戦略的なソフトウェア コンポーネントの価格を低減。
  3. 製品のエコシステムを築き需要を喚起。
  4. 他社との間でパートナーの関係を形成；顧客を引き込む。共通のゴールに向けて関係性を強化。
  5. 顧客に自己サポートの能力を提供；企業の提示するコードを企業のサポートなしで利用してもらう。

出典: Ibrahim Haddad

セクション 2

いつオープンソース プロジェクトを作るか

コードを公開したり、新規オープンソース プロジェクトを作ったりすることの決定はその企業の置かれた状況に依存します。企業としては、まず第一にオープンソース ソフトウェアの利用や既存プロジェクトへの貢献を通じ、オープンソースに対して一定程度の習熟度に達しているべきです。このような活動によって、企業の製品を作り上げるのに、外部のプロジェクトや開発者をどのように活用できるのかを学ぶことができるからです。また、参加することによって、オープンソース コミュニティの習慣や文化に円滑に対応できるようになります。(本ガイド集の「オープンソース コードの利用」、および、「オープンソース コミュニティへの参加」を参照して下さい。) しかしながら、ひとたびオープンソースに対する円滑な対応が身につけば、企業独自のオープンソース プロジェクトを立ち上げるべき時は、単純明快に「早期」、「頻繁」の考え方にに従うのがよいでしょう。

早期にリリース、頻繁にリリース

開発の方法論

早期にリリース

  • 他のプロジェクト参加者が開発にフィードバックを提供し、貢献することが可能
  • コードにまだ柔軟性が残っている間に新しいアイデアを組み込むことが可能
  • 進行し過ぎない段階で、問題点が他の参加者によって提起されるうる

頻繁にリリース

  • 小さな修正の方が理解、デバッグ、改善、熟成への到達が容易
  • 開発、品質保証、技術革新の速いペースを維持
  • 進捗や開発の現況についてプロジェクト メンバーに対して高いレベルの可視性を維持

出典: Ibrahim Haddad

セクション 3

どこから始めるか

新しいプロジェクトを作るのは、おそらく、企業が自社だけでは解決できない困難な技術課題を認識した時でしょう。他の動機としては、企業の期待する活動を実施するプロジェクトを見つけ、参加することができないといった状況もあるでしょう。究極的には、設問に対する正しい答えはありません。企業が新しいプロジェクトを必要とし、既存の活動が見つからない時にプロジェクトを立ち上げるのがいいでしょう。

新たなオープンソース プロジェクトを検討する企業としては、「なぜ？」への独自の答えを見出すことから始めるのがよいでしょう。企業にとって何が重要なのかという問いをたくさん発することから始めてください。正しい理由に基づいてオープンソース プロジェクトを立ち上げることが大切です。

「企業にとって、新しいオープンソース プロジェクトで何を成し遂げたいかを常に考えることが非常に重要なことだと思います。コミュニティや開発者から見たプロジェクトの価値、および、プロジェクトの成果物として何を期待するかについて考えなければなりません。その後で、これを正しく行うために備えるべきすべての要素、たとえば、法務、ガバナンス(管理・統制)、インフラ、起点となるコミュニティなどを理解しなければなりません。それらは、オープンソース プロジェクトを作ろうとするときに私が一番強調する点です。」

John Mertic – The Linux Foundation プログラム管理ディレクター

起点となるのが、企業としては必ずしもその分野のオーソリティーになる必要のない副次的コーディング プロジェクトの位置づけながら、世界には当該企業の問題解決を手助けする技術者の大きなグループが存在するようなケースもあります。そのコードがミッション クリティカルな業務に供されるものでなければ、オープンソース化の候補となる可能性があります。しかしながら、そのコードは企業内で活発に利用され保守されているべきです。コードがビジネスで利用されているということにより、継続的なバグ修正、パッチ、さらには、新機能のフィードバックが可能となります。

「弊社が共有に供する多くのプロジェクトは、弊社の社内で利用しているものです。私たちは、弊社の日常業務で実際に利用しているものを共有することを目指しています。それは、Facebookのシステムの規模から考えて、実戦試験ずみであることを意味します。弊社がコミュニティに貢献しているものは、プロ級のソフトウェアです。もう一つのポイントとして、これらのツールは日常業務で使用されているので、弊社はこれらを劣化した状況や保守されない状況に置くことはあり得ません。弊社の技術者もこれらが良い状態であることを必要としているからです。」

Christine Abernathy – Facebook オープンソース チーム開発者アドボケイト

もう一つの考慮点は、そのプロジェクトがユニークなものなのか、あるいは、同様の問題に対応するために同様のコードを作ろうと既に活動している人々がいるかどうかです。オープンソース プロジェクトとすべく検討しているものは、プロジェクトとして提案し、管理して行くに値するほど当該企業にとって重要なものでしょうか？しかも、他のユーザーもそれを必要としているでしょうか？もしもそうであれば、おそらくそのアイデアには十分に意味があります。

企業は、ベンダー中立な非営利組織にその企業のコードを寄贈するのか、あるいは、企業独自のプロジェクトを所有・運営して何らかの制御を行い続けるかどうかを決定する必要が出て来ます。ここでも、答えはその企業が何を達成しようとしているかに依存します。

「オープンソース プロジェクトにするが適切なのは、検討中プロジェクトに企業としてそんなに重要じゃないけれども、何らかの制御を続けたいと思うような要素が認められる時です。また、オープンソース プロジェクトに他の開発者を巻き込むことによって、プロジェクトが浮上する可能性が広がると思ったときも、オープンソース プロジェクトを始めて下さい。つまり、何か追求したいものを考えてから、オープンソース プロジェクトを始めてください。」

John Mertic – The Linux Foundation プログラム管理ディレクター

オープンソース プロジェクトを立ち上げる前に問うべき質問

プロジェクトを財政的にサポートできますか？ 社内に経営幹部レベルで牽引してくれる人がいますか？

既存のオープンソース プロジェクトと一緒に活動することは可能ですか？

OSSモデルによってプロジェクトを立ち上げ、維持することはできますか？

何をもって成功とみなしますか？ どんな方法で評価しますか？

プロジェクトは、外部の企業の参加を引き寄せることが可能ですか (立ち上げの当初から)？

開発者のコミュニティを形成し、拡大していくのに十分な外部の関心はありますか？

出典: Ibrahim Haddad

セクション 4

プロジェクトの計画作り

計画を実行に移し始めると、オープンソース プロジェクトから成果を得るために、検討し、解決しなければならないことが無数に出てきます。プロジェクトのソースコードを公開、ないしは、寄贈するかどうかをいかに決定するかという問題から始めて、ひとつひとつ考えてみましょう。

どんなコードを公開または寄贈するかの決定

最初に、コードやプロジェクトに関する所有権を維持した状態で、コードの作成や公開を行おうと考えるのか、あるいは、他者に寄贈し、プロジェクトの保守と管理を任せたいと考えるのかを決定しなければなりません。もしもそのコードが既に存在している時には、関連した課題として、オープンソース プロジェクトに供するのは、既存プロジェクトのすべてのコードなのか、その一部のみとするのかを決定しなければなりません。

これらの決定を行うに当たり、そのコードに託した当初の目的を見定めために立ち戻って検討してください。

「私たちの技術者がプロジェクトをオープンソース化したいという決定をしたら、いくつかのことを考えます。まず、プロジェクトが社外の開発者にとって有用なものになるかどうかを確認します。そして、プロジェクトは斬新なものか？ ショーケースにできるようなものか？ また、プロジェクトの周りにコミュニティが形成され、プロジェクトを保守するがコミュニティをきちんとサポートできるかどうか？」

Christine Abernathy – Facebook オープンソース チーム開発者アドボケイト

たとえば、企業の業務の中核ではないアプリケーションの一部について、他の開発者から新鮮な見識を得たいと考えることがあるでしょう。あるいは、システム監視アプリケーションの中で、ログを検出する現実的なアルゴリズムを追加したいと考えるかもしれません。この際、全ソフトウェアをオープンソースとして公開するのでなく、アルゴリズムに関連したコードだけを公開するというやり方もあります。こうすれば、中核ビジネスを危うくすることなく、他の人々の貢献を受け、なおかつ、同様の手助けを必要としている人々を助けることもできます。

プロジェクトを立ち上げ、全体の制御権を維持すれば、プロジェクトを高い場所から見守り、必要な形に持って行くのに必要な影響力を持つことができます。それでも、貢献する開発者には彼らの活動の自由と自己制御を保証します。

企業が持っているコードを貢献するのは少し様子が異なります。それは、コードを放棄し、保守や管理に関する制御権を他者に引き渡すことを意味しています。企業にとってはもはや必要でないコードかもしれませんが、ユーザーの特定分野のニーズを満たしているので、他の人々には価値があるのです。企業としては単に時間をかけられないというようなコードでも、オープンソース コミュニティから歓迎され、前進の力を与えられ、長期的なプロジェクトとして成長する可能性があります。コードは企業にとって重要なものである可能性もありますが、より多くの参加者を引き寄せ、より大きなエコシステムへと成長するために、プロジェクトは中立的な受け皿を必要としています。

企業にとってもはや有用性がなくなった、あるいは、関心がなくなったというようなコードを貢献し、コミュニティが最新の環境に適合させることを期待してはいけません。私たちはそのようなことを勧めているのではありません。オープンソース コミュニティやプロジェクトを古いコードの捨て場として使い、弾みがつくかどうか試すようなことは決してしないでください。それがまったく重要なプロジェクトでないということになると、オープンソースの世界で信用を失い、その後、他のコードをオープンソース化しようとしても、開発者が関心を示さなくなります。過去にその企業が時間の浪費を強いたことは記憶に残るので、企業としてそのようなことを行ってはいけません。

「もしもあなたの会社が今年、3件のオープンソース プロジェクトを立ち上げ、それらのどれもが素晴らしいもので、良質なコミュニティを惹きつけたとすると、1年に10件のオープンソース プロジェクトを立ち上げるのよりも大きな値打ちがあります。オープンソース コミュニティは、量よりも質の方を高く評価し、どのプロジェクトに参加するのか自ら選択します。10件のプロジェクトが低質なものだったりすると、もはや牽引力を得ることはできないでしょう。よいものだけをオープンソース化するように考えるべきです。」

Guy Martin – Autodesk Open@ADSK ディレクター

ビジネス ケースを作る

オープンソース プロジェクトの立ち上げは、市場に製品を送りだすときと同じように、達成の見込みのある成果によって裏付けられた健全なビジネスケースを作った後で行うのがいいでしょう。そうすれば、経営幹部の了承も得られるでしょう。なぜなら、経営幹部としては、なぜプロジェクトが実施されるのか、ゴールは何か、予算はどの程度か、ロードマップはどうなるのか、どんな知財が開示されるのか、どのコードが関係しており、また、関係してないのかを理解する必要があるからです。

資源を割り当てる

また、プロジェクトに貢献する開発者の作業時間のような、資源提供のコミットメントを行うことができるかどうかも決定する必要があります。開発者の作業時間は、社内のコード開発の時に費やしていた時間と当初は同等になるでしょう。また、新しいコミュニティで他の人々がコードベースを素早く習得する手助けをするために、当該企業の開発者が、どれくらいの時間、どんな資材、どんな援助を提供する必要があるかを検討しなければなりません。また、競合他社を巻き込む可能性のあるオープンソース プロジェクトを作る際には、法務部門のチームの資源も必要とされます。さらに、マーケティング投資を行うことによって、プロジェクトの立ち上げ後、プロジェクトへのサポートと貢献者獲得が確かなものとなります。

また、プロジェクトの開設と維持に要するインフラのための予算も準備しなければなりません。例えば、GitHubのようなプロジェクトのホストとソース管理のためのWebサイトが必要とされ、そこに、コードが格納され、そこでバグ解決などの保守作業がなされ、必要なツールも用意されます。

コードの品質をテストする

オープンソース プロジェクトで使用されることを想定しているコードの完成度・成熟度は、計画の実行開始に向けた準備の指標ともなりえます。当然ながら、コードは良い状態にあることが望まれます。以前にも述べたように、ガラクタのようなコードは、オープンソース コミュニティにおける信用崩壊に繋がります。

同時に、注意しなければならないのは完璧なコードが要求されているわけではないという点です。もしもコードが完璧でなければならないと考えていると、プロジェクトを開始することができません。手元にある最善のものを提供し、他の人々が改良に向けて支援してくれるものと考えるのが良いでしょう。また、コミュニティに提供できるレベルの完成度を検証する際は、最初に提供するコードには、コード コメントに企業秘密や、企業のプロプライエタリ インターフェースへの参照、あるいは、不快な言葉その他の問題を含んでいないことを確かめるべきです。

有用性を確認する

そのプロジェクトが前に進むべく準備万端となるのは、IT課題に対して同様の答えを追求する他の人々にとってもそのプロジェクトが有用であることが明らかとなり、それを証明できた時です。そのような状況は、伝統的な市場分析によっても情報収集できます。そのプロジェクトは他の人々が探し求めるものであり、喜んで貢献したいと思うものであること、それゆえにプロジェクトが成功する可能性が高いことを確かめるのが良いでしょう。何らかの調査を行い、また、周りの人々に聞いて回ってください。また、オープンソース イベントに参加し、開発者や講演者と会話し、それらの人々の課題やプロジェクトについて聴いてください。

もしも他の人々が既に同じ問題を解決するために同様のプロジェクトを立ち上げていることが分かった時には、重複するよりも、その活動に参加することを検討してみるのが良いでしょう。同様のプロジェクトが存在しているなら、競合企業が推進していたとしても、チームになる方がより強力になります。なぜなら、オープンソース コミュニティでは、協調することが非常に重要な要因だからです。

オープンソース プロジェクト上で競合企業と一緒に活動することは、検討すべき重要なことがらです。企業が独自のオープンソース プロジェクトを立ち上げ、競合企業を巻き込むことができれば、協調、友好を築くことができ、より優れたコードの完成に繋がります。しかも、追随するのではなく、先導できるのです。

意見を求める

上記のすべての考慮点について、技術チームは、これらの決定や、プロジェクトの成功に必要なプロセスの方向付けを手助けするのに、経営幹部の方々の意見を求めることができます。企業内の開発者とITスタッフは、どこで、いつ協調すれば有効かを示すことができます。

「私たちがオープンソース プロジェクトを立ち上げるのは、私たちが探し求めていたものが見つからなかったときや、過去にうまく動いていたものが、私たちの環境の進化のために、動かなくなったということが分かったときです。それは性能的な理由であることもあります。また、単にコストが理由であったり、ベンダー ロックインが理由であったりします。私たちが、単純に、一連のインフラをより最新のテクノロジーに移行させたのに、過去に利用していたレガシー ベンダーのいくつかがクラウド環境やコンテナ環境で彼らのソフトウェアが間に合わない、あるいは、動作させる意志がないということもあります。」

Jared Smith – Capital One オープンソース コミュニティ マネージャー

セクション 5

オープンソース プロジェクトの始動

プロジェクトの計画作りができたら、次は、法務的な準備を始め、プロジェクトの設立に向けより公式のステップに踏み出すべき時となります。これには、コードを安全に利用できることを保証するためのコードのスキャンと改善の実施、プロジェクトに対する適切なライセンスの選択、円滑な運用のためのガバナンスのルール作りなどが含まれます。関連した話題として、インフラの開設、プロジェクトの開始に向けたコードの設置、そして、最後にコミュニティに対するプロジェクト始動の通知やドキュメントの提供もあります。

法務的レビュー

プロジェクトに起こりうる最悪の事態は、コードベースの法的潔白性に関してコミュニティに不信感を持たれることです。企業が公開するコードが、ライセンス、および、出所に関して明確であることを保証することが重要です。貢献として提供されるものがコミュニティ中の他の人々に受け入れ可能であることを確かなものとするのに、すべてにわたる法務的レビューが役立ちます。このレビューの重要な側面は、企業として当該コード全体を公開する権限を有していることを検証することです。法務的レビューには、商標の審査、登録も含まれるべきです。ただし、プロジェクトをファウンデーションの中で推進しようとしているなら、コードベースのオープンソース化の前にファウンデーションの商標戦略に合致しているかを確認する必要があります。

プロジェクトのライセンスを選択する必要もあります。ライセンスや知的財産に関わる要件があればそれらを文書化しておくことが重要です。IPポリシーを文書化しておくと、ライセンスや貢献の仕方に関わるすべての要件を明確にするのに役立ちます。また、コードについては、各ファイルにライセンス ヘッダー、あるいは、SPDXライセンス識別子を記述するようにしてください。各コミットにDCO(Developer Certificate of Origin) 、すなわち、「signed-off-by行」を要求し、コードの由来を証明しやすくすることも取り入れることが推奨される手法です。たとえば、GitHubでは、どんなリポジトリにおいてもこれを要求するようなツールを用意しており、 https://probot.github.io/apps/dcoで利用できます。

一般的に採用されるいくつかのオープンソース ライセンスと、それぞれのトレードオフについて精通しておくことが重要です。それらの中には、明示的な特許許諾の条項を持つもの、防御的な停止権限の条項を持つもの、ユーザーの権利を保護するもの、救済条項を提示するもの、簡易なものや業界で広く受け入れられているものがあります。また、当該コードが依存するソフトウェアや、それが組み込まれた、あるいは、統合されたコードベースで採用されたライセンスについても考慮の必要があります。

ソフトウェアのソースコードに加えて、プロジェクトの他の側面に関わるライセンス要件も検討しなければなりません。参加企業の特許許諾の取り決めを必要とする場合や、後でプロジェクトをリライセンスできるようにすることを見越す場合は、一般的なContributor License Agreements (CLAs)をいくつか参照してみるのがよいでしょう。しかし、すべてのCLAsが必ずしも似通っているわけでもないので、注意深く検討する必要があります。また、CLAsは、開発者が社内の承認を得るのに骨の折れるプロセスを要することもあり、参加の障害となる可能性もあります。

当該プロジェクトがソフトウェアではない成果物を作りだすこともあります。プロジェクトがドキュメントを作るのなら、それらのドキュメントに特別なライセンスを適用するのかどうかを議論する必要があります。たとえば、多くのオープンソース プロジェクトは、ソフトウェアに対してはオープンソース ライセンスを適用し、ドキュメントに対してはクリエィティブコモンズ ライセンスを適用します。加えて、プロジェクトの中には、他の人々がさまざまな方法で実装することを許すようなスペシフィケーションを作ろうとするものもあります。そのようなプロジェクトは、スペシフィケーション ライセンスを適用するという選択肢を検討すべきです。この実例はOpen Container Initiative (OCI)です。同プロジェクトは、スペシフィケーションに対しては、OWFa 1.0 – Patent Onlyスペシフィケーション ライセンスを適用し、作成したオープンソース ソフトウェアの実装に対しては、Apache License Version 2.0を適用しています。

ライセンス検討におけるもうひとつの共通的な考慮点は、コピーレフト ライセンスとパーミッシブ ライセンスの間でどんな寛容性と厳格性の選択をするかという点です。コピーレフトという用語は、互恵的な共有を要求し、提供されたソフトウェアに対応したソースコードをユーザーが受領する権利を保証しようとするライセンスを言及するのによく使われます。パーミッシブ ライセンスは、下流における義務なしに他の人々が貢献に参加することや、成果物を共有することを容易にするのに都合の良い傾向のあるライセンスです。このライセンスは、修正部分を開示することなしに、ソフトウェア開発者がオープンソース コードベースを元としたプロプライエタリ ソフトウェアを頒布することを必要とするソフトウェア セグメントに特に好都合です。

それぞれのライセンスには、有利な点と不利な点があります。しかし、プロジェクトの断片化の可能性には要注意です。これは、ソフトウェアに特有の課題であり、異なるベンダーのソリューション間で、相互運用性と可搬性が失われて行く問題です。この問題は、しばしば、適合性プログラムによって解決しており、同プログラムは、商用ソリューションがコミュニティの制定したテストや一連の要件をパスすることを条件として、プロジェクトの商標使用を許可しています。前もってこのことを考慮しておくと、法務的レビューに情報を与え、プロジェクトの計画作りに役立ちます。(オープンソースの法務的な課題、検討事項に関するさらなる情報として、本ガイド集の「オープンソースガイド推奨図書一覧」をお勧めします。)

要約すると、法務的レビューのステップでは、以下を実施します。

技術的レビュー

技術的レビューにおいては、ソースコードが他の社内コードや社内の開発技法に依存することなく機能すること、そして、オープンソースとして公開することのできない第三者コードが含まれていないことを確認します。

公開を計画しているコードが特許など他社知財を侵害していないことを確認してください。他企業の特許を侵害する可能性のあるコードを追跡して調べ回っているパテント トロールが数多く活動しています。これはネガティブな意味合いをもつ大きな問題ですが、プロジェクトの立ち上げ時から正しく対処しなければなりません。これを行うのに、多くの企業が、コードに問題がないことを確認する特別なスキャン ツールを使っています。また、ライセンス告知や著作権告知、さらには、ソースコードがどんなものなのか、どう利用されるのかを記述したドキュメントをプロジェクト情報として用意してください。

技術的レビューでは、すべてのライセンス告知と著作権告知を検証し、個人的なコード コメントを除去すべきです。実行すべきステップとしては、以下があります。

ガバナンス (管理・統制)

プロジェクト始動の前に、プロジェクトのガバナンスに関する技術的要件を定義しなければなりません。ガバナンスとは、プロジェクトの戦略、リリース、方向性、開発優先項目を決定するプロセスを指しています。すべての参加者がプロジェクトに起こる変化を知り、透明性を維持するために、決定の仕方は公開かつオープンでなければなりません。また、ガバナンスでは、問題をエスカレートするためのパスを持つべきかについても検討すべきです。

早期の段階で、プロジェクトのガバナンス組織(たとえば、理事会)に参加するためにどんな基準を満たさなければならないかを決定することが重要です。どのように機能追加やバグがトラックされるのか、どのようにコードが提出されるのか、誰がリリースのプロセスを管理するのかなどは、公式な決定を行うべきです。

プロジェクトの責任を任せられた人々には、プロジェクトを運営・管理するのに必要なツールが確実に使えるようにしなければなりません。オープンソース プログラム オフィスとプログラム マネージャーは、このような場面を想定して設けられます。

「これらの仕事を成し遂げることを課された人々には、それを推進できる十分な権限を与えられる必要があります。また、プロジェクトのビジネスの領分と技術の領分を入り混じらせないように気をつける必要があります。それらには明確なリーダーシップが必要です。そのようにして流れがとどこおらないようにします。また、筋違いな決定をしないようにします。技術側のより大きな成功のためにビジネス側に協力させます。」

John Mertic – The Linux Foundation プログラム管理ディレクター

技術的プロセス

プロジェクトの始動に先立ち、リリースの標準的なプロセスを作っておき、プロジェクトのメンテナーによる変更・強化の実装とともに行われるコードのリリースの定常スケジュールを決めておくと役に立ちます。スケジュールは、プロジェクトの開発コミュニティとビジネス側の人々のために、細部にわたり明確で可視的な情報とともに提示されるべきです。

どれくらいの頻度でリリースを行うかは、コミュニティがどれくらい待ち望んでいるかに依存します。プロジェクトが企業向けのもので、完成度の高いものを開発しようとしているのなら、リリースのスケジュールは、年間2回程度でしょう。また、プロジェクトが、より限定されたスコープと機敏さを特性として持ち、プロジェクトの一部を取り出して利用することを想定しているようなら、コードは毎月とか毎週のようなリリースも考えられるでしょう。スケジュールの考え方における鍵は、ユーザーに対しては必要なもの、待ち望むものを提供する一方で、速度の観点で、コミュニティ自らが予定表を作り、プロジェクトをサポートしていく自身の力量を十分に理解しなければならないという点です。

もしもコミュニティが、リリースが速過ぎる、あるいは、遅過ぎるというフィードバックを上げてくるようなら、プロジェクトのプロセスを見直し、調整を加える必要があります。ここにおいて重要なことは、一貫性、予測可能性、可視性です。

指導体制

プロジェクトの活動開始前に指導体制を作っておくことが重要です。それはプロジェクトが異なれば、異なったものになりえます。複数の大企業が参加する企業プロジェクトを立ち上げるのなら、監理役員会議とか管理グループのような、より形式にこだわったガバナンスが必要になるでしょう。他の構成では、オープンソース プロジェクトのすべての細部を技術的観点から指導する技術委員会だけで足ることもありえます。委員会は主に技術的なリーダー、また、企業の経営幹部に対して進捗とプロジェクトのニーズに関する情報更新を行う連絡員で構成されるでしょう。法務チームの要員は、技術メンバーや経営幹部が適切だと判断した時に参加します。

企業において最もアーキテクチャにたけた人物が、コードベースがどう動作するかを良く知る人々とともに、指導体制に参加するのがよいでしょう。委員会メンバーは、プロジェクトの進む方向に対するビジョンを持つとともに、開発者コミュニティからのサポートも受けます。これらはプロセスの計画作りの際に参加してもらいたい人々です。

「指導体制の人々は、そのコードを貢献した企業・組織に対する受託者責任があり、プロジェクトが企業の役員・株主、さらには、この知的財産を託してくれたすべての人々の意に即したものとなるようにしなければなりません。指導体制の人々はこの方向性で一致していなければなりません。同時にまた、降りかかってくる責任、危険、また、それに類する事柄が問題にとなる状況も想定していなければなりません。これを過小評価してはいけません。」

John Mertic – The Linux Foundation プログラム管理ディレクター

インフラ

プロジェクト始動の前に、プロジェクトのリポジトリを用意する必要があります。これは、コード リポジトリのインフラですが、貢献者はそこにアクセスすればいつでもプロジェクトを利用できます。多くのプロジェクトは良く知られたGitHubやGitLabのリポジトリを利用するか、あるいは、Gerritのようなツールを使って独自のリポジトリでプロジェクトをホストします。その他にも多くの選択肢はありますが、開発者がプロジェクトに参加し、関わることが容易となるように考えることがよいでしょう。プラットフォームを選択し、アカウントを開設してください。そして、コードを公開する場所を用意し、ワークフローを定めれば、魔法の始まりに準備万端です。

プロジェクトのインフラ計画の一部として、バグ、問題点、機能開発をトラックする仕組みを含めるべきです。貢献者が、解決を必要とする問題の発生を報告し、また、追加すると有益だとみなされる新規機能を要望するための場を提供することが重要です。それから、プロジェクトのGitHubリポジトリには、自動的なビルド システムと自動テスト システムのプロセスを含めることが必要となる可能性があります。それにより、コードの質を確保するためのコード スキャンとコード チェックを実施しつつ、常にシステムとして円滑に作業を進めることができるようになります。

Webサイト

次のステップは、企業から中立なプロジェクトのWebサイト、あるいは、Wikiページの開設です。Webページは、コミュニティに対してドキュメント、コードのダウンロード、さらにはもっといろいろな情報を見つける場を提供します。また、Webページは、プロジェクトの指導体制、スコープ、ユーザーと貢献者、予算、ガバナンス、その他について詳細な情報を提供することもできます。

コミュニケーション

コミュニティとして質問に答えるためのコミュニケーション チャネルを提供することは非常に重要です。開発ワークフロー全体 (たとえば、サポート要求、コードのチェックイン、エラーログ、その他の作業の通知を受信) に組み込むことが可能なツールが必要です。また、重要な問題の議論のためのフォーラムや、コミュニティのメンバーが同じプロジェクトに取り組む他の人々から迅速な回答を受け取る仕組みも必要です。これらすべてがコミュニケーションの重要な手法であり、プロジェクトをリアルタイムで前進させるのに役立ちます。

このようなプロジェクト ツールとして検討すべきものの一つはSlackです。Slackは、オンラインのチーム プロジェクト管理とコミュニケーションの機能を提供するプラットフォームです。ユーザーは、メッセージおよびファイルへのアクセスと共用、ワークフローの編成、情報の検索、さらに多くのことを行うことができます。しかし、Slackはプロプライエタリなツールであり、使い続けると課金が生じます。オープンソースの選択肢としては、IRC、Gitter.im、その他のものも存在します。たとえば、Hyperledgerプロジェクトでは、Rocket Chatと呼ばれるコミュニケーション システムを採用しており、完全にオープンソースでありながら、Slack同様の機能を提供しています。最新のフォーラム機能が必要なら、Discourseは、完全にオープンソースの素晴らしい選択肢であり、ホスティング サービスをオプションとして提供しています。

コミュニケーション システムを選択する際は、何らかの形のロックイン、課金、将来的な新システムへの移行の容易さに気を付けるべきでしょう。コミュニティの成長とともに、新たなコミュニケーション チャネルを採用できるようにしておく必要があります。newsgroupがたくさんのオープンソース プロジェクトで使われるコミュニケーション スタイルであったのはそんなに昔の話ではありません。

「当社のおよそ190件の異なったオープンソース プロジェクトは、ただひとつの中心的開発スポットであるGitHub上のAutodeskセクション中に配置しました。かつて、私たちはAutodeskのオープンソース プロジェクトとして少なくとも14セクションを運営していました。Twitterのコードをいくつか使うことによって、14セクションはひとつのビューにまとめられ、外部訪問者からも見てもらえるようにしました。企業の立場として、何を始めたのか、そして、人々が訪問してプロジェクトの内容を見たり、質問したりできる中心的スポットがあるということを外部の人々が確実に分かるようにすることが重要です。」

Guy Martin – Autodesk Open@ADSK ディレクター

始動と保守

いろいろな計画作り、準備、そして、多面的レビューと数々のステップの後、いよいよ、独自のオープンソース プロジェクトを始動させ、保守を開始する段となります。そこに至るまでには、広範囲にわたる計画作り、オープンに行われたコミュニケーション、上層・下層インフラの整備があったでしょう。さらには、ガバナンス、技術プロセス、および、両者の間の諸々の事柄のために作ったいくつものステップもあったはずです。

これらの必須の要素が整うと、当該プロジェクトを世界に公開し、貢献者からの入力を得る時となります。関心を持つ貢献者たちがプロジェクトを調べ、それが思慮に富み、簡明で、価値あるものであるとみなされると、彼らは、自ら利用できる何かがあるということで、堰を切ったようにわくわくして参加します。

始動に先立つ重要な仕事:

マーケティング活動を忘れないで

もちろん、プロジェクトの始動が活動の終わりを意味している訳ではありません。プロジェクトの前進を続けさせるためには、注意が必要な一連のビジネス上、および、マーケティング上の追加のステップがあります。それらの中には、プロジェクトの普及活動、上手くいく運営戦略の設定、現実的な予算の提供、および、プロジェクトのブランディングが含まれ、さらに、長期的成功を助けるような活動的なソーシャル メディア アカウントおよび使いやすいドメイン名を確保することも含まれます。

マーケティング レビューによってブランディングに向けたガイドラインを確立させます。これは、市場における一貫したメッセージを確かなものとするのに役立つため特に重要です。マーケティング レビューのステップには次があります。

プロジェクトの実働が始まると、プロジェクトを普及させ、そこにプロジェクトが存在しているので、人々が利用し、活動に参加できるということを知らしめる責任があります。人々がプロジェクトに引きつけられ、コードの貢献、フォーラムへの参加、バグ修正の提出、問題点の報告などの活動にいかに多くの人が加わってくれるかが成功を示すリトマス試験となるため、マーケティング活動に携わる者にとって、これは楽しみな挑戦となります。

「この活動にコミュニティは不可欠なので、しっかりとコミュニティの面倒を見ていくことが必要です。そのことは、小さなことですが、要望に対して敏速に行動することや、プロジェクトが確実に役に立つことで証明できます。誰かがプロジェクトを訪問したとき、彼らはプロジェクトの様子を見て、どうやっているかを知ることができるのです。」

Christine Abernathy – Facebook オープンソース チーム開発者アドボケイト

コミュニティの構築

プロジェクトの始動後、外部のコミュニティの活性度合いをよく見ていることが重要です。

コミュニティの構築は自動的に起きるものではありません。プロジェクトの初期の段階では、はずみをつけるために開発者イベントを主催したり、大きなコンファレンス中にミーティングを行うための資金援助をしたりすることが必要となるでしょう。

また、プロジェクトに対する期待を正しく管理し、義務を果たすことは、プロジェクトのガバナンスと透明性のために非常に重要なことです。

引き続き実施すべき活動には以下があります。

貢献者の多様なグループを構築することができれば、当初のコードを拡張することに対して自らの時間、資金、その他の資源を投資することに関心を持つほどの価値があると見定めた企業・組織と議論を行い、プロジェクトを次の段階に進めるかどうかを決定することができるようになります。他企業・組織からの入力と資源を得ることによって、プロジェクトは拡大し、また、成長し、貢献者の増加によってさらに多くのことができるようになります。

そのようなコミュニティの成長は、さらに多くの企業がよりたくさんの資金を貢献し、その企業の開発者を送り込んで開発活動に参加し、そして、当初のコードの拡張に彼らの開発力を注ぐことによって前に進める手助けを得る可能性を意味します。それは、プロジェクトの重要性、および、そのプロジェクトが他企業に何を意味するかによって、$10,000、あるいは、$250,000、さらには、それ以上の投資を意味します。プロジェクトが始まれば、他企業はプロジェクトがその企業の役に立てば、プロジェクト活動を前に進めるために、財政的な貢献を行うでしょう。

今日、このようなことは頻繁に起きています。今や、企業や組織が解決しようと試みる技術的な課題の大きさは、個別に解決できる課題の上限をはるかに超えているからです。企業や組織が他企業とともにベンダー中立なジョイント プロジェクトに参加することの戦略的価値にようやく気づき始めたのです。そのようなジョイント プロジェクトは、各企業が直面する技術課題を解決する解を得るという社会的な大義のために活動しています。

このアプローチをとる例を2つ挙げます。1つ目は、Hyperledgerのためのオープンソース プロジェクトです。同プロジェクトは、Linux Foundationが後援している共同開発活動であり、業界を跨るブロックチェーン技術の強化・発展を目指しています。2つ目は、Cloud Native Computing Foundation (CNCF) で、こちらは最新のプライベート クラウド、および、パブリック クラウドを構築するために利用されるオープンソース ソフトウェアです。多くの企業は、これらの大規模プロジェクトに開発者として貢献するだけではなく、多くの資金を提供し、これら技術の普及・強化を手助けしています。

セクション 6

結論

オープンソース プロジェクトを立ち上げ、飛躍させることは、少なくとも始めは、ちょっと神秘的で、恐ろしいところさえあります。しかし、企業がそのプロセスによって受け取る指数的価値を理解し、定量化すると、その最初のプロジェクトはオープンソース ソフトウェアをより戦略的に活用する企業活動の最初の一歩となるでしょう。それに続くオープンソース活動への挑戦が成功するために、他の企業がこの道のりをどのようにたどったかを学んでください。

セクション 7

オープンソース プロジェクト始動のチェックリスト

検討事項

ビジネス戦略、および、計画作り

法務的レビュー

技術的レビュー

ガバナンスとプロセス

ブランディングとマーケティング

始動と保守