「インナーソース」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
ページ「Inner source」の翻訳により作成
(相違点なし)

2022年7月22日 (金) 07:17時点における版

インナーソースは、オープンソースソフトウェア開発のベストプラクティスを使用し、非オープンソースおよび/またはプロプライエタリソフトウェアを開発するための組織内でのオープンソース文化の確立をすることです。[1] 。この用語は、2000年にティムオライリーによって提唱され、コラムに掲載されました[2] [3]

モチベーション

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

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

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

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

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

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

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

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

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

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

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

利点

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

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

インナーソースの普及

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

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

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

製品要因

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

プロセスとツールの要因

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

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

参考文献

  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”. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。 “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. ^ a b 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.  引用エラー: 無効な <ref> タグ; name ":0"が異なる内容で複数回定義されています
  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. ^ 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.