企業におけるオープンソース開発の効果を高める

オープンソース開発は、多くの企業が慣れ親しんできた従来のやり方とは違ったアプローチを必要としますが、明確な計画を持って取り組みさえすれば、より容易になります。幸いなことに、すでに多くの企業や個人が、重要なオープンソース プロジェクトへの貢献に成功する道筋を作り上げています。彼らは試行の末に、オープンソース コミュニティでリーダーシップを確立する方法を見出しているのです。

この実用的ガイドは、企業内の開発プロセスを改善し、あなたの会社が最も重要視するオープンソース プロジェクトに貢献する準備を整えることを手助けします。Linuxカーネルに貢献することは、オープンソース開発者にとって最も厳しい挑戦の1つです。本ガイドではLinuxカーネルを事例として取り上げますが、その指針はほとんどすべてのオープンソース プロジェクトに適用できます。

内容

1. 効果のあるオープンソース開発とは？
2. 開発の改善に果たすオープンソース プログラムの役割
3. 共通的領域の改善
4. 推奨される取り組み トップ10
5. 強化の進捗状況を追跡して調べる評価尺度
6. 結論

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

開発者の貢献は、企業が実行するオープンソース プログラムのビジネス目標－その目標は、企業のオープンソース戦略によって支えられる－を達成する主要な活動のひとつです。オープンソース プロジェクトの方向性に影響を与える方法はたくさんあります。たとえば、多くの異なった環境でのテスト、コードに関連したドキュメントの追加、プロジェクトやそれに関連した財団への財政的援助、プロジェクトの運営会議への参加、他のオープンソース プロジェクトにおける当該コードの利用などです。しかし、企業がオープンソース プロジェクトに一番大きな影響力を発揮できるのは、コード貢献の質、量、および一貫性を通じたものです。したがって、企業の開発チームが高品質の効果的なオープンソース コードを開発できるような手段とプロセスを提供することが、企業の最善の利益となります。

影響力の大きなオープンソース コードは、企業が貢献しているオープンソース プロジェクトの技術的方向に影響を与えます。また、企業の保守費用を抑えながら、当該企業の製品を強化します。

目指すところは、オープンソース貢献を通じ、オープンソース貢献とともに企業の開発チームの有効性を向上させることです。本ガイドの推奨するオープンソース開発ベストプラクティス（ある結果を得るのに最も効率のよい手法、プロセスなど）のいくつかを実装すれば、次のようなことが可能となります。

• 製品部門の作業量を削減する
• 企業内のソース コードや独自ソース ツリーを保守するための費用を最小限にする
• コードの質を高める
• 開発サイクルを短縮する
• 製品の基盤となるコードを安定化させる
• 重要なオープンソース コミュニティにおける企業評価を高める

企業のオープンソース プログラムの成果物は、社内のインフラやサービスとして使われているか、商用の提供物として外部に出荷されているかにかかわらず、企業の製品に対して明確な直接的効果と間接的効果の両方をもたらします。これらの効果は、その大きさを測定もできれば、さらに大きくすることもできます。また、目に見える結果として経営幹部に報告し、オープンソース プログラムの価値を示し、また、ROI（投資に対応した利益）を生み出すこともできます。

直接的な効果

企業のオープンソース プログラムは、コードを貢献することが、企業のオープンソースコード開発に直接的な効果を与えます。すべての企業は、ビジネス目標と企業構造に最も適した方法で、そのオープンソース プログラムを構成し、技術的貢献を行います（本ガイド集の「オープンソース プログラムの作成」の中の「プログラム構造」のセクションを参照）。しかし、コードを貢献することは、オープンソース プロジェクトに影響を与え、オープンソース コミュニティで当該企業の評価を上げる最善の方法なのです。

Samsungにおいて、オープンソース プログラムは専任の技術チームを擁しており、R&D部門やプロダクト部門のオープンソース開発要請に応えています。同プログラムは、Samsungの社内で開発されたコードをいろいろなオープンソース プロジェクトに提供することにも手を貸しており、また、Samsung製品に関連した数多くのドライバーをアップストリーム向けに実装しています。プロダクト部門にもオープンソース プロジェクトに貢献する開発者がいますが、プロダクト開発に縛られているために、自由な行動が制約されています。そのため、オープンソース グループは、「カーネルに機能Xを実装する必要がある。」というような要請を受け、同グループの技術チームはプロダクト用のコードを提供し、さらに、Linuxカーネルにも提出します。

ポリシーとプロセスにのみ特化したオープンソース プログラム オフィスは、コードの貢献のための専任の技術チームを通常持ちません。その代わり、いろんな部門の技術者が一定の時間を捻出して、オープンソース コンポーネントに対して行った変更をアップストリームに提出します。

技術チームがどのような組織に属していようと、目指すところはそれらのコンポーネントに関する技術的な借金を最小限にすることです。もしもアップストリームへの貢献がなければ、製品部門はアップストリームと同期していないコードベースを保守し続けることでしょう。製品の強化のためではなく、更新部分を同期されていない企業独自のソースツリーにバックポートするために時間を取られるのです。

多くの場合、製品部門で働くオープンソース開発者は、アップストリームの活動やそこでの責任（コミッターとして、あるいは、メンテナーとして）と、製品を実現するための役割との釣り合いをとるのに苦労します。

各社のオープンソース プログラム オフィスは、ビジネスのニーズに合わせた組織構造を採用しています。たとえば、Facebookでは、オープンソース プログラム オフィスにツール専任のチームを持ち、同社のオープンソース資産の管理をやりやすくするための社内ツール群の構築に責任を持っています。そこには、Facebookが共有するプロジェクト（その多くがGitHub上で管理）もあれば、Linuxのように同社が貢献している外部プロジェクトもあります（Facebookのオープンソース プログラムに関するケーススタディを参照）。

間接的な効果

企業のオープンソース プログラムの効果は、さまざまなオープンソース プロジェクトに貢献するコードだけではありません。企業のパブリック リレーションやマーケティングから始まって、法務サポート、開発者トレーニングなどに至るまで、オープンソース プログラムは、さまざまな切り口で開発に効果を及ぼしています。ここでは、オープンソース プログラムが間接的に開発の改善に寄与する、コード貢献以外の4つの切り口を示します。

1. 外部で行われる技術討議。間接的な貢献を行うことができる領域の1つは、技術的な討議への参加を通じたものです。オープンソース開発者は、メーリングリストやIRCチャット上で積極的に活動することによってこれを行い、それにより、討議に参加し、プロジェクトの最新情報を常に受け取ることができます。しっかりとしたガバナンスの仕組みを持つ大きなプロジェクトでは、テクニカル ステアリング コミッティ（技術運営委委員会）に委員として参加することも可能です。
2. 社内で行われる技術討議。企業の決定が、関連するプロジェクト コミュニティの方向性と確実に適合するように、オープンソース開発者は社内のポリシーやアーキテクチャーの討議に参加することができます。オープンソース開発者は、たとえば、オープンソース コードに依存する製品の長期計画に関連した戦略討議に立ち会うべきです。
3. コンプライアンスの支援。プログラム マネージャーは、コンプライアンスの課題解決に援助を提供し、会社が受け取ったオープンソース コンプライアンスに関する問い合わせに対してコンプライアンス チームを支援することもできます。
4. バグの修正。最後に、当該企業が参加しているさまざまなオープンソース プロジェクトのコードを安定化させるために協力できます。バグを発見して修正し、バグ修正をテストし、アップストリームに提出することもできます。これにより、当該企業を含むすべてのプロジェクト ユーザーが使用するコード全体の価値が高まります。

企業のオープンソース プログラムが、オープンソース プロジェクトで開発者の生産性と有効性を高められる3つの領域があります。それは、文化、プロセス、そしてツールです。それぞれのカテゴリーには、オープンソース モデルに適合させるべき要素がいくつかあります。

専任オープンソース チームが企業の現場で取り組むべき課題

文化

文化的な課題は、従来型のソフトウェア開発手法とオープンソース開発の要件との間にギャップがあるという事実から生じます。オープンソースの専門家を雇い入れ、オープンソース開発モデルに不慣れなメンバーを教育してもらうことによって、このギャップに橋を渡すことができます。

プロセス

オープンソース開発は、ダイナミックで、とても早く動きますが、コンプライアンスについて特別な要件があります。このような開発スタイルに合うように内部プロセスを順応させていない企業は、簡単に取り残されてしまいます。開発者は、素早くアップストリームにコード貢献することが可能となっている必要があり、社内のコード ポリシーはこのような活動を容認するように変更される必要があります。

最初に、法務的な問題を避けるために、適切なオープンソース コンプライアンスに責任を持つチームを作ることは必須です（Linux Foundationの電子書籍、Open Source Compliance in the Enterpriseを参照）。

また、企業はオープンソースの活用と貢献のために、わかりやすい社内承認モデルを作る必要があります。ここ数年の間に、Samsungは、ソースコードの受け取り方法、レビュー方法、および貢献の承認方法について、複雑でやっかいなポリシーをわかりやすいものに変えました。それは関連するすべての組織、すなわち、法務部門、技術部門、およびオープンソース チームの間でバランスをとったたものです。現時点の合意では、専任のオープンソース チームの活動を後押ししており、同チームがたくさんのオープンソース プロジェクトに貢献することに対して一括承認を与えています。しかし、他のチームでは貢献するコードの性質に依存して異なったレベルの承認を必要としています。たとえば、バグ修正、既存機能の強化のためのコード、新機能を提供するコード、あるいは新規プロジェクトの立ち上げなどです。

ツール

活動の当初から、使用するツールをオープンソース開発モデルと共存できるものにした方がよいでしょう。オープンソース プログラム オフィスのニーズを満たし、しかも企業のITガイドラインに合った構成を作ってください。

たとえばSamsungでは、同社の技術者に、オープンソース開発に参加するのに必要なあらゆるツールが正しく動作するLinuxデバイスを支給しています。この環境により、開発者は通常の作業方法を大きく変更することなくオープンソース プロジェクトのチームに参加できます。また、同社は在宅作業を後押ししており、実際にごく少数のオープンソース開発者だけがシリコンバレーのオフィスで働いています。他のスタッフは全世界の遠隔地に拠点を持っています。

少し歴史を振り返ってみましょう。2000年12月、オープンソースの歴史に画期的な出来事がありました。IBMがLinuxの研究・開発に10億ドルを投入することを公約したのです。IBMは、Linuxとオープンソースに賭け金を投じた企業界の真のパイオニアでした。当時、そのような企業はほとんどなく、そのような規模の投資はありえない状況でした。オープンソース ソフトウェアや、同社が参加していたさまざまなプロジェクト コミュニティで活動するために、IBMは多くのことを学ばなければなりませんでした。

それは、大企業のオープンソース参入のスタート点でした。それ以後、数十の、さらに後には数百の企業がIBMに追随しました。今でも、数千の企業がオープンソースに参入しています。オープンソースがソフトウェア開発の新たな標準になりつつあるからです。問題は、どうすれば企業の学習曲線を最小限とし、「正しく理解する」プロセスをスピードアップできるかというところなのです。

答えは簡単です。けれども、その答を特定の企業文化に適用させる場合は難しい側面も存在します。オープンソース ソフトウェアにおける17年以上にわたる企業の経験を学び、容易に適用できる側面から探っていきましょう。ここで学んだことを特定の企業環境に適用するという難しい側面にも対応できるようになるでしょう。

一言だけ注意：これらの取り組みを実装することに加えて、従来型のソフトウェア開発の手法から、もっとオープンで協業にふさわしい考え方へと組織文化の転換を推進する必要があります。企業内が、オープンソースに関連した活動に好意的であることが必要です。組織のオープンソースのリーダーとして、予算の獲得、ROIの説明、アップストリームの関心獲得など、いくつもの課題に直面します。これらには、組織の上層にまで及ぶ考え方の転換と膨大な教育を要します。

1) プロジェクトのコミュニティから鍵となる開発者やメンテナーを雇い入れる

社内でオープンソースの専門家を育成するのにはかなりの時間を要します。企業が手早くスキルと外部の認知を獲得するのに、鍵となる開発者を雇い入れるのは不可欠なステップです。

2~3人の開発者で始めれば、Linuxカーネルのような大きなプロジェクトに注目されるような影響を及ぼし、さらなる開発者を惹きつけ、また、十分な資源を与えて若手開発者への教育を行うような方向へと進んで行くのに十分です（本ガイド集の「オープンソース開発者を募集する」を参照）。

目標は、コミュニティの仲間から影響力を十分認められている開発者を見つけることです。そのような影響力には一般に3つの柱があります。それは、当該領域の専門性、オープンソースの方法論、そして開発への取り組みです。

また、企業としての関心と個人の関心を一致させることが必要です。上級のオープンソース開発者に、本人の関心が企業の関心と合致していないプロジェクトに参加してもらっても動機づけは困難です。たとえば、Linuxのメモリー管理の専門家は、企業として優先度が高かったとしても、ファイルシステムの開発に携わることには関心ないかもしれません。長期的な関係維持のためには、関心をマッチングさせることは不可欠です。

2) アップストリーム貢献に時間を割く

オープンソース開発者を雇用する核心的原則は、企業のオープンソース開発とアップストリーム活動に対して支援することです。専門的な領域において製品部門を支援すべきであるという期待もあるでしょう。しかし、できるだけ多く製品開発のために働いてもらうことにより、オープンソース開発者の時間を乗っ取るべく開発部門が影響力を行使するというのはかなりよくある事例です。このようなことが起きると、多くのオープンソース開発者は、雇用した側に何が起きたのか理解もできないうちに、アップストリーム プロジェクトで活動することを許す新しい仕事を探してドアの外に向かうでしょう。

したがって、アップストリームの活動と製品開発の仕事を分割する方策を案出し、維持することが重要です。言い換えれば、オープンソース開発者には、特にメンテナーとして活躍するような開発者には、アップストリーム活動に対する願望を満たし、そこで責任を果たすためのたす時間を保証しなければなりません。若手の開発者やオープンソースを製品のコンポーネントとして利用する社内の開発者の場合でも、アップストリーム コミュニティとの交流は、言語・コミュニケーション・技術のスキルを向上させます。そのようなアップストリーム活動の時間を保証しないと、オープンソース開発チームのメンバーであっても、容易に製品部門に吸収されてしまい、結果として、製品開発を優先させてアップストリームに対する関心が干上がってしまいます。

オープンソース開発チームは、また、製品部門のためのアップストリーム パートナーになるべきです。製品部門は、特に家電業界の環境においては、圧力釜の中で生活しているように感じるようです。いつも要員不足であり、並行したアップストリーム開発に必要な資源が欠けており、また、厳しい開発スケジュールの下で機能提供を行うという定常的な圧力にさらされています。そのような環境で、目先の時間節約に走ると、アップストリーム活動のメリットが容易に見過ごされます。そのような時間節約は、不幸にして、長い目で見ればより大きなコストとなるような技術的負債をもたらします。オープンソース チームは、重要なコードをアップストリームに提供し、この技術的負債を減らすことにフォーカスしたパートナーであることによって手助けとなります。

オープンソース チームの外にいる開発者は、オープンソース コミュニティから学び、そこに貢献するよう奨励してください。オープンソース チームは、アップストリームのコード貢献に関してできる限りの支援を行います。しかし、チームの資源には限りがあり、コードをどこにアップストリームできるかを十分に見極めるのに必要とされる製品の深い理解があるとは言えません。オープンソース チーム以外の部門からのオープンソース コミュニティへの好適な関与は、より多くの重要なコードのアップストリーム化を可能とし、コミュニティとのやりとりを円滑にします。

3) 指導プログラムを作る

企業の製品に有効な特定の領域でオープンソース人材を育成してください。企業の外から何人かを雇い入れるのは簡単かもしれませんが、そのアプローチには制約もあるでしょう。

代わりとなるアプローチは、既存の開発者に特定技術領域とオープンソース方法論を学んでもらい、オープンソース貢献者になってもらうことです。このような開発者は、指導者とペアを組むことでさらにスキルを高めることができます。

指導プログラムを作り、それにより、経験を積んだ上級のオープンソース開発者が、若手で経験の少ない開発者を教育します。通常、指導プログラムは3~6か月をかけ、指導者は被指導者の作業を監督し、仕事を割り当て、確実に適切な成果を上げていきます。指導者は被指導者の作るすべてのコードについてレビューを行い、アップストリーム プロジェクトにコードを提出する前にフィードバックを提示します。

目指すものは、アップストリーム プロジェクトにコードを貢献する開発者の数を増やすこと、および、コードの品質を高め、アップストリーム プロジェクトに受け容れられるコードの率を上げることにより、個人としての実力を向上させることです。一般的には、4~5人以下の被指導者に対して指導者を1人割り当て、指導者と彼らが同じ領域で作業できるようにすれば、コード レビューが効率的に行われます。

4) オープンソースのキャリア パスを正式なものとする

オープンソース開発者として雇用した人々が、非オープンソース開発者との対比で、どのように昇進して行くかについて見通しを持てるように、人事システムにオープンソース開発者用のキャリアパスを作ってください。それに加えて、成果基準ボーナスには、オープンソース開発の仕事に関連した目標を設定できるよう調整すべきです。プロプライエタリ ソフトウェアや非オープンソース ソフトウェアの開発者の評価尺度は、オープンソース開発者のものとは異なっていることが多いでしょう。

一部の企業では、オープンソース開発者と非オープンソース開発者の間には明確な区別があります。しかし多くの企業では、組織としての構造やオープンソース戦略に依存して、境界は流動的です。実際には、最近の開発者はすべてオープンソースと関わって作業せざるを得ません。クローズドソースのみを扱う開発者はいないのです。どちらかといえば、コードは企業内に留まる時もあれば、公開される時（外部の企業・組織に提供、あるいは新規プロジェクトとして公開）もあるのです。企業の人事システムのキャリア パスやインセンティブは、オープンソースに対応した企業独特の組織構造やアプローチを反映させるべきです。

最後に、企業としてのポリシーがどうであれ、オープンソース開発者には、在宅勤務を許可してください。近年、在宅勤務に関しては逆の傾向があり、多くの企業が禁止したり、厳しい制限をつけたりしています。オープンソースの世界では、在宅勤務のポリシーは、ほとんど必須の状況です。というのは、オープンソースの専門家は世界中のあらゆる場所を拠点としており、このポリシーを適用するのが雇用の条件となるからです。

フレキシブルな勤務ポリシーには、企業運用上の利点もあります。スタンフォード大学が刊行した調査報告によると、リモートワークを選択できる従業員は転職率が下がり、また、「要員の減少率は50%も下がった」とのことです。また、ソフトウェア サービスのトップ プロバイダーであるPGIの調査によると、在宅勤務により作業員のモラルは80%向上し、欠勤率は68%下がったとあります。

5) トレーニングを提供する

どんな企業であろうと、当該領域で専門性の高い上級開発者をすべて雇用するのは不可能です。この見方はLinuxカーネルにも、また、その他のいかなるオープンソース プロジェクトにもあてはまります。したがって、当該技術分野において企業の開発者の能力を伸ばす方法を持っていなければなりません。技術的なトレーニングに加えて、オープンソース開発モデルやオープンソースの法務コンプライアンスの基礎概念を教育するトレーニングも必要です。

トレーニング コースの事例：

• Linuxカーネルのさまざまな領域をカバーする技術トレーニング。メンテナーや上級開発者が社内でカーネル専門知識を育成するために説明。このような専門知識は、専門的なカーネル開発者の雇用が難しい状況下で、企業が前に進むために必須。
• オープンソース開発の方法論のコース。オープンソースを初めて経験するスタッフに、オープンソースやLinuxカーネルの開発がどのように行われているか、およびどうすればうまく関わることができるかを教育。
• オープンソース コンプライアンスのコース。スタッフに対してコンプライアンスとオープンソース ライセンスの基礎を教育。企業のポリシーとプロセスを伝達するためにも使われるべき。Linux Foundationは開発者向けに自由に使用できるオンラインのオープンソース コンプライアンスのトレーニング コースを公開。

6) オープンソース イベントに参加する

開発者が、ローカルなコミュニティの会合、ハッカソン、サミットなども含めて、オープンソースのカンファレンスやイベントに出席し、参加するのを後押ししてください。そのような参加を通して、仲間との個人レベルの繋がりが生まれ、付き合い関係を築くことができ、顔を合わせた交流を行い、さらに、プロジェクトの方向を決める技術討議への参加ができるようになります。

開発者が他の人々から関心を持たれるような成果を上げたなら、その内容を発表する準備に手を貸してください。最後に、プロジェクト コミュニティ内での企業の知名度を上げるために、大小のイベントのスポンサーとなることができます。これらのイベントは、人材を見つけるための機会ともなります。

7) 柔軟なITインフラを用意する

オープンソース開発者が、オープンソースやLinuxカーネルのコミュニティと問題なくコミュニケーションをとり、一緒に活動することができる柔軟なITインフラを用意してください。加えて、この目的に沿って社内のチームとカーネル コミュニティや他のオープンソース プロジェクト コミュニティとの間のギャップの橋渡しをできるよう、外部で使用されるツールに適した社内ITインフラを整えてください。

インフラのかなりの部分は企業のオープンソース文化と一緒に自然に進化していきます。けれども、オープンソースソフトウェアを実装したインフラを整備する必要性に気付いて、その計画を作ることが重要です。

オープンソース開発で利用されるITサービスには、おもに3つの分野があります。すなわち、情報の共用（Wiki、共同編集プラットフォーム、パブリックWeb）、コミュニケーションと問題解決（メーリングリスト、フォーラム、リアルタイム チャット）、および、コード開発と頒布（コード リポジトリ、バグトラッキング）です。オープンソース開発を支援するのに、これらのツールの一部またはすべてが社内で利用できる必要がありますが、企業の既存のITポリシーとは矛盾が出て来る可能性もあります。そのようなことが起きると、矛盾を解消し、オープンソース開発者が馴れ親しんだツールを使えるようにすることが不可欠です。

これらのオープンソース プラクティスは、ITポリシーを制約するような多数の標準に束縛されないことを要求します。

8) 開発者のコード貢献を追跡して調べる

開発者の貢献と効果を追跡して調べるために社内の仕組みを作ってください。貢献には、アップストリーム開発、製品部門への支援、知識の伝達(指導やトレーニング)、知名度向上(執筆物や講演)、新規プロジェクトの立ち上げ、さらには、社内の他の部門やグループとの協業プロジェクトの構築などがあります。

ソースコード貢献を追跡して調べるのに便利なツールキットがいくつかあります。たとえば、Linux Foundationはgitdmと呼ばれるツールを使い、Linux Foundationが毎年発行する「Linuxカーネル レポート」で紹介するデータを生成しています。このツールは、個々の開発者とチーム全体の両方の成果を追跡して調べるのに使えます。各開発者について、提出したパッチの数、パッチの受け容れ率（受け容れられたパッチ数 / 提出パッチ数）、およびパッチのタイプ（新規機能、既存機能の拡張、バグフィックス、ドキュメントなど）を追跡して調べることができます。

GrimoireLabのようなツールも、追跡して調べたい評価尺度をチャートにしたり、可視化するのに使えます。次のセクションでは、追跡して調べるべき具体的データの評価尺度について触れています。

9) 大きな効果のあるフォーカス域を特定する

1つ以上のビジネス部門や1つ以上の製品に利益を与える領域に貢献し、フォーカスを合わせてください。これによって、複数のビジネス部門にわたって価値を提供し、ROIを示すことができます。また、より多くの予算や支援を得るチャンスが増えます。

企業の戦略や製品に直接的に利益をもたらすアップストリーム プロジェクトに貢献をフォーカスしてください。オープンソース開発にはおもわず夢中になるような興味深いプロジェクトがたくさんあります。オープンソース グループがコスト センターとして認識される大企業の現場においては、製品開発を後押しするオープンソース プロジェクトに同グループの力をフォーカスすべきです。

Samsungにおいては、できるだけたくさんの製品で共通して活用されたオープンソース プロジェクトの活動を分析し、その製品ポートフォリオを毎年レビューしています。この一覧表は、いくつかの要因をベースに優先度付けが行われ、優先度の高いプロジェクトに活動をフォーカスします。このように優先度の高い活動を推進する方法は、重要なもの、正当性のあるもの、および資金投入できるものからの逸脱を避ける良い方法です。

10) 企業内の協業を育てる

製品の中で同一のオープンソース プロジェクトを活用するいろいろなビジネス部門と協業してください。このような協業には次のような形態がありますが、その中のひとつ、ないしは、複数の形態がとられる可能性があります。

• 開発者にトレーニングを提供
• 特定の話題、あるいは、問題についてワークショップを開催
• 新しい機能を開発
• 問題やバグの分析と解決を実施
• 資源のないグループに代わって、出来上がったコードをアップストリームに提出
• 以前にフォークしたツリーから、メインラインの版に移行するのを支援
• その他

このような協業の目差すものは、オープンソースによって可能となるものを通じて、製品部門がニーズを理解し、製品目標を達成するのを後押しすることです。

このような協業の実施のためには、企業はさまざまな部門に渡る情報と優先度の共有がなされていなければなりません。例として、あなたがオープンソースチームに所属していて、ドライバーの開発を支援するように要請されたが、ハードウェアのマニュアルや命令セットへのアクセスが不可能だったとしましょう。これは暗闇の中でダーツをやるようなものです。オープンソース チームと他のあらゆる人々との間の社内協業の成功のためには、情報共有が必須な要素です。

これらのオープンソース ベストプラクティスを実施し始めると、望ましい開発行動をさらに推進するために、適切なオープンソース評価尺度が必要になります。しかし、製品開発組織でよく使用されてきた従来型の評価尺度は、オープンソース開発の環境では応用できません。

たとえば、修正件数とコード行数を追跡して調べるのは、オープンソース開発の効果のよい評価尺度になりえます。しかし、アップストリームにおいて企業が必要とする機能を実装するために、複数の活動を行っていることがあります。企業の開発者がコミュニティの支持を取り付けるためのロビー活動を行うなどするからです。このケースでは、オープンソース チームのメンバーがコードをアップストリームに提供し、企業のダウンストリームにおける保守費用を削減するために果たした技術的リーダーシップと比較すると、修正件数やコード行数は到底重要とは言えません。追跡して調べる評価尺度は両方の活動を評価するものであるべきです。

一定期間内のコミット数とコード行数

追跡して調べるべき最も基本的な評価尺度は、特定期間内、たとえば、週ごと、月ごと、あるいは、1年ごとに提出されたコミット数とコード行数です。

このデータに基づき、どこからコード貢献が出てきているかを判断して、さまざまな社内開発チームの貢献を比較し、社内資源を適切に割り当てることが可能となります。

これを用いて、さまざまな社内チームの累積貢献量、貢献全体に対する割合、アップストリームにコードをコミットするのに要した総時間数を比較するチャートを作ることができます（次のチャートを参照）。

これらの評価尺度は、企業の実績を、たとえばカーネル コミュニティに関わっている他社と比較するのに使うことができます（下図を参照）。このような競合分析は、当該プロジェクトに取り組む開発コミュニティ全体について、よりよい情報を得るのを助けます。

これらの評価尺度は、企業の強味と弱みがどこにあるのかについて優れた考察を提供し、また、企業の開発戦略全体について情報を得る助けとなります。たとえば、競合企業との貢献量を追跡して調べることにより、競合他社の製品と当該企業の製品の市場における位置づけ確認するのを助ける価値ある情報を提供します。

LinuxカーネルはSamsungにとって戦略的重要性があり、多くのプロジェクトを手掛ける中で、開発活動を同プロジェクトにフォーカスすることを選択しています。Samsungは、現在Linuxカーネルの修正件数に関して、定常的にトップ5貢献企業に入っています。また、同社の製品開発に不可欠だと考えられる他のオープンソース プロジェクトについても、同様にレベルが上がっています。

トップ貢献企業になること自体が目標ではありませんが、企業の開発活動が参加しているコミュニティに受け容れられていることの指標であることは間違いありません。俗に言うように、オープンソースの影響力ある企業として食卓に座るか、さもなければ、メニューに載るかです。

効果的なオープンソース開発は与えられるものではありません。働いて勝ち取らなければなりません。このリーダーシップは、定常的で継続的な参加と貢献を通じて勝ち取られます。

オープンソースにおけるパイオニア企業が提示したオープンソースのベストプラクティスのいくつかを踏襲することによって、企業が必要とするオープンソースのノウハウ獲得に向けて敏速な進歩を遂げることができます。そうすれば、そのノウハウをテコにして、コード保守の費用を低減しつつ、製品やサービスを強化できます。

楽しくハッキングしましょう。

これらのリソースは、TODO (Talk Openly, Develop Openly) グループとの協力により作成されました。TODOグループは、The Linux Foundation傘下のプロフェッショナル オープンソース プログラム ネットワーキング グループです。 このような包括的なガイドを作成するために時間を割き、豊富な知識を提供してくれたオープンソース プログラム マネージャーのみなさんに感謝します。TODOグループの参加企業は、Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath (Yahoo + AOL)、Red Hat、Salesforce、Samsung、およびVMwareです。
詳細については、todogroup.orgを参照してください。

この資料は、Creative Commons Attribution ShareAlike 4.0 International License (CC BY-SA 4.0：クリエイティブ・コモンズ 表示 – 継承 4.0 国際ライセンス) の下でライセンスされています。