GGI: InnerSource

Table of contents

インナーソース

インナーソースは、組織の開発チーム内で成功したオープンソースの実践に基づいたアプローチを提供するため、現在、企業内で人気が高まっています。ただし、インナーソースを実行するには、それらの実践をコピーして貼り付けるだけでは不十分です。企業独自の文化や社内組織に合わせて調整する必要があります。インナーソースとは何か、そうでないものとは何か、関連する課題は何かを詳しく見てみましょう。

インナーソースとは？

この用語は、2000 年に Tim O’Reilly によって初めて使用され、インナーソーシングとは「[…] 企業内でのオープンソース開発手法の使用」であると述べています。

このトピックに関する参考資料である InnerSource Commons (EN) によると、インナーソースとは「組織の範囲内でソフトウェア開発にオープンソースの原則とプラクティスを使用する」ことです。

なぜインナーソース？

InnerSource Commons (EN) によると、「主にクローズドソースソフトウェアを構築している企業にとって、インナーソースはサイロを解体し、社内のコラボレーションを促進および拡大し、新しいエンジニアのオンボーディングを加速し、オープンソースの世界にソフトウェアを貢献する機会を特定するのに役立つ優れたツールになります」。

興味深いことに、インナーソースの利点は、エンジニアリングだけでなく、企業内のさまざまな機能に影響を与える可能性があります。その結果、一部の企業は次のような分野で具体的な利点を見出しています。

  • 法務機能: すぐに使用できる法的フレームワーク (インナーソースライセンス) の使用により、部門横断的なコラボレーションの確立を加速します。
  • 人事: 労力と専門知識を集約する責任を負う経験豊富な中心チームを通じて、不足しているスキルを管理します。

インナーソース論争

インナーソースには、批判者からよく聞かれる誤解がつきまといます。真のオープンソースではありませんが、このようなアプローチを社内で展開する組織にとって大きな潜在的なメリットがあります。以下に、こうした誤解の一部を示します。

  • [誤解] インナーソースはオープンソース (主にアウトバウンド) を犠牲にして行われます。
    • ソフトウェアプロジェクトは会社のファイアウォールの内側にとどまります。
    • オープンソースへの外部からの貢献が少なくなります。
  • [誤解] オープンソースの精神を乗っ取るのではなく、それにアプローチします。
  • [誤解] インナーソースプロジェクトがオープンソースプロジェクトになったことはありません。
  • [誤解] インナーソースを行う動機は、オープンソースに似ていることです。しかし、実際には、開発者がそれを重視する場合、直接的なオープンソース貢献が常に優先される必要があります。

以下に、これまでの誤解のほとんどを打ち破るインナーソースの実践に関するいくつかの事実を示します。

  • [事実] インナーソースは、主にクローズドな企業をオープンソースに迎え入れる方法です。
  • [事実] オープンソースへの貢献の大部分はボランティアによって行われていますが、この「認識されているメリット」のリストを使用して、エンジニアにオープンソースへの参加を宣伝することができます。
  • [事実] 場合によっては (またはほとんどの場合？)、企業は秩序立った管理された開発プラクティスに従っていません。これ (GGI) は、企業がこれを管理できるようにするための方法の 1 つです。
  • [事実] クローズドライセンスからオープンライセンスへの変換には、依然として多くの作業が必要です。
  • [事実] インナーソースプロジェクトがオープンソース化されているケースは確かにあります。
    • Twitter Bootstrap
    • Google 提供の Kubernetes
    • dotCloud (Docker Inc. の以前の名称) 提供の Docker
    • React Native
  • [事実] インナーソースのプラクティスは非常に似ているため、オープンソースのプラクティスに慣れるソフトウェアエンジニアが増えることで、オープンソースは恩恵を受けます。

誰がやっているのか？

多くの企業がインナーソースイニシアチブまたは ISPO (InnerSource Program Office) を立ち上げています。中には長い間立ち上げている企業もあれば、最近立ち上げた企業もあります。以下は主にヨーロッパの企業に焦点を当てた、非独占的なリストです。

InnerSource Commons、必須の参考資料

オープンソースの原則に従って活動する、活発で活気のあるインナーソース実践者のコミュニティは、InnerSource Commons (EN) にあります。このコミュニティでは、パターン (EN)、学習パス (EN)、小さな電子書籍など、このテーマについて理解を深めるのに役立つリソースが多数提供されています。

インナーソースガバナンスの違い

インナーソースは、オープンソースでは解決できない特定の課題をもたらします。しかし、プライベートソフトウェアを作成する組織のほとんどは、すでにそれらの課題に対処しています。

  • インナーソースプロジェクト専用の企業固有のライセンス (複数の法人を持つ大企業向け)。
  • オープンソースのパブリックな性質により、価格移転の課題から解放されます。インナーソースのプライベートな性質により、異なる管轄区域で事業を展開する企業は利益移転の責任にさらされます。
  • 貢献の動機は非常に異なります。
    • インナーソースは組織に限定されているため、貢献できる可能性のある人のプールは小さくなります。
    • 自分の専門スキルを示すことは貢献の原動力の一つです。インナーソースでは、この影響は組織の境界内にのみ制限されます。
    • 社会の改善に貢献することは、インナーソースでは制限されている貢献のまた別の原動力です。
    • したがって、モチベーションにはより強い努力が必要であり、報酬や割り当てに大きく依存します。
    • インナーソースでは、コードの可視性が制限されているため、詐欺師症候群などの完璧主義の恐怖に対処するのは簡単です。
  • 人材のアウトソーシングはより頻繁に行われ、それがガバナンスにさまざまな形で影響を及ぼします。
  • インナーソースは社内で開発されているため、企業の妥当性を評価するのは簡単です。
  • 検索可能性が問題になる傾向があります。企業にとって、情報のインデックス作成はそれほど優先事項ではありません。DuckDuckGo、Google、Bing などのパブリックな検索エンジンは、インナーソースが活用できない優れた機能を提供します。
  • インナーソースは社内で運営されているため、輸出管理の点でやや優位です。
  • ソースコードとして流出する知的財産の境界制御が必要です。

インナーソースは、より多くの企業がその原則を採用し、経験を共有するにつれて進化し続けています。このハンドブックの今後のバージョンでは、インナーソースの実践者に関連する GGI のアクティビティの厳選リストを提供します。