インナーソース

オープンソースソフトウェア開発の文化とベストプラクティスの企業内における利用

インナーソース (InnerSource) は、オープンソースソフトウェア開発におけるベストプラクティスを活用し、非オープンソースやプロプライエタリソフトウェアを開発する組織内にオープンソースの手法を取り入れることである[1]。この用語は、2000年にティム・オライリーによって提唱され、コラムに掲載された[2][3]

モチベーション

編集

オープンソースを利用すると、高品質のソフトウェアを提供できることが一般に認められている[4]。さらに、オープンソースでのオープンコラボレーションにより、競合他社間でもコラボレーションが可能になる(例:ARMIntelは、メリットベースの決定でLinuxカーネルに取り組んでいる)。

その結果、ソフトウェア開発組織は、その成果(ソフトウェアコンポーネントとツール)だけでなく、オープンソースの世界で実行および確立された開発手法からも利益を得たいと考えている[5]

活用されたオープンソースのプラクティス

編集

Apache Software FoundationLinux FoundationEclipse Foundationなどの財団で確立されたいくつかのプラクティスに加えて、インナーソースおよびオープンソースプロジェクトには、オープンコラボレーション、オープンコミュニケーション、および適切な品質保証が必要である。

オープンコラボレーション

編集

すべての必要な開発成果物(コード、ドキュメント、課題管理システムなど)は、インナーソースを利用する組織のすべての従業員がアクセスできる必要がある。中央ソフトウェアリポジトリは、オープンコラボレーションを実装するための不可欠なツールである。

オープンコラボレーションの原則(平等主義実力主義、自己組織化)に基づいて、インナーソースプロジェクトを支援する意欲のあるすべてコントリビューターは通常歓迎される。インナーソースプロジェクトへのコントリビューションは、通常、プロジェクトにもたらす価値に基づいて実力主義的に判断される。決定が公に議論されるので、実力主義はオープンなコミュニケーションによっても可能になる。インナーソースを採用したために組織が必ずしも完全に自己組織化されるわけではないが、インナーソースを使用することにより、個人、組織単位、およびプロジェクトコミュニティに高度な自己組織化が可能になる。

オープンなコミュニケーション

編集

インナーソースのプロジェクトとプログラムは、すべての従業員がすべてのコミュニケーションにオープンにアクセスできるようにするために、オープンなコミュニケーションに依存している。オープンなコミュニケーションとは、(組織内で)公開され、書かれ、アーカイブされ、完全なコミュニケーションである。この性質の結果として、コミュニケーションは非同期になる。目標は、インナーソースプロジェクトに利害関係または関心を持つ個人または当事者がコミュニケーションに参加できるようにすることである。オープンなコミュニケーションの議論がアーカイブされると、ソフトウェアの詳細なドキュメントが受動的に収集され、歴史的な議論や決定に戻って再訪することができる。

インテグレーションとコントリビューションの分離による品質保証

編集

専用のコードレビューとコントリビューターとコミッター(インテグレーター、書き込みアクセス権を持つ開発者)の分離により、オープンソースプロジェクトの品質が保証される。したがって、インナーソースプロジェクトの品質も保証される。

利点

編集

オープンソースソフトウェアの品質属性に加えて、次の利点が報告されている[6][7]

より効率的かつ効果的な開発
  • 市場投入までの時間の短縮
  • 開発コストの削減
組織単位の境界を越える
  • 組織単位間のコストとリスクの共有
  • 組織単位の境界を越えたコラボレーション
  • プログラム全体の情報交換
より進んだコードの再利用
  • コンポーネント提供者で不足している能力の使用
  • 再利用者と提供者間の独立性
  • コンポーネント提供者の解放
より良いソフトウェアプロダクト
開発者のより柔軟な利用
  • 簡素化された開発者の配置
  • 独立した開発者のコラボレーション
強化された知識管理
  • コミュニティベースの学習
  • 知識の開放性と可用性
従業員のモチベーションの向上

インナーソースの普及

編集

とりわけ、以下の企業がインナーソースを採用していることで知られている。

インナーソースを採用するための重要な要素

編集

インナーソースは、ソフトウェアを開発する大規模な組織にとって有望なアプローチになる可能性がある。ただし、すべての設定で適切であるとは限らない。次の9つの要素は、3つのカテゴリにグループ化されており、インナーソースが適切である可能性がある範囲を評価するために参照できる[14]

製品要因

編集
  • コミュニティを引き付けるシード製品
  • さまざまなコントリビューションにおけるの複数の利害関係者
  • 寄稿者とユーザーを引き付けるためのモジュール性

プロセスとツールの要因

編集

組織とコミュニティの要因

編集
  • 内部実力主義の出現を支援するための調整とリーダーシップ
  • 組織を開放するための透明性
  • 経営支援と人を巻き込む動機

参考文献

編集
  1. ^ Capraro, Maximilian; Riehle, Dirk (2017-02-06). “InnerSource Definition, Benefits, and Challenges” (英語). ACM Computing Surveys 49 (4): 1–36. doi:10.1145/2856821. ISSN 0360-0300. https://opus4.kobv.de/opus4-fau/files/7544/capraro-riehle_inner-source-survey.pdf. 
  2. ^ Ven van 't ende (2016年5月9日). “InnerSource: An Open Source Approach to Community Culture”. 2022年7月22日閲覧。 “Tim O’Reilly, the founder of O’Reilly Media, coined the term “inner-sourcing” in 2000, describing it as: “the use of open source development techniques within the corporation.””
  3. ^ O'Reilly (2000年12月1日). “Open Source and OpenGL”. oreilly.com. O'Reilly and Associates. 2015年2月15日時点のオリジナルよりアーカイブ。2017年2月22日閲覧。 “[W]e've also worked with companies on what we call “inner sourcing” — that is, helping them to use open source development techniques within the corporation.”
  4. ^ Kevin Crowston, Kangning Wei, James Howison, Andrea Wiggins (2012), ACM, ed., “Free/Libre open-source software development: What we know and what we do not know” (ドイツ語), ACM Computing Surveys 44 (2): 1–35, doi:10.1145/2089125.2089127 
  5. ^ Stol, Klaas-Jan; Fitzgerald, Brian (2014). “Inner source—adopting open source development practices within organizations: a tutorial”. IEEE Software. doi:10.1109/MS.2014.77. https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf?sequence=2. 
  6. ^ Capraro, Maximilian; Riehle, Dirk (2016-12-01). “Inner Source Definition, Benefits, and Challenges”. ACM Comput. Surv. 49 (4): 67:1–67:36. doi:10.1145/2856821. ISSN 0360-0300. https://opus4.kobv.de/opus4-fau/frontdoor/index/index/docId/7544. 
  7. ^ Stol, Klaas-Jan; Fitzgerald, Brian (2015-07-01). “Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial”. IEEE Software 32 (4): 60–67. doi:10.1109/MS.2014.77. ISSN 0740-7459. https://ulir.ul.ie/bitstream/10344/4443/2/Stol_2014_inner.pdf. 
  8. ^ Microsoft Internal Solorigate Investigation Update. https://msrc-blog.microsoft.com/2020/12/31/microsoft-internal-solorigate-investigation-update/ 
  9. ^ Oram, Andy (2015). Getting Started with InnerSource. O’Reilly Media, Inc.. ISBN 978-1-491-93758-7. http://www.oreilly.com/programming/free/getting-started-with-innersource.csp 
  10. ^ Smith, Jared (2016). Using open source methods for internal software projects. O’Reilly Media, Inc.. https://www.oreilly.com/ideas/using-open-source-methods-for-internal-software-projects 
  11. ^ Archived at Ghostarchive and the Wayback Machine: Commit San Francisco 2020: Shucking Corporate Oysters-Kickstarting an Innersource Culture @ T-Mobile.
  12. ^ Watch: Creating an Inner Source Hub at Siemens” (英語). JFrog (2020年7月28日). 2020年12月9日閲覧。
  13. ^ How Wal-Mart enables ‘innersource’ with Github” (英語). CIO (2016年7月27日). 2021年7月10日閲覧。
  14. ^ Stol, K. J.; Avgeriou, P.; Babar, M. A.; Lucas, Y.; Fitzgerald, B. (2014). “Key factors for adopting inner source”. ACM Transactions on Software Engineering and Methodology 23 (2): 1. doi:10.1145/2533685.