インナーソース

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

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

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

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

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

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

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

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

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

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

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

HP Red Hat フィリップス ルーセント ノキア IBM DTE ロバートボッシュ グーグル マイクロソフト SAP トレンドマイクロ PayPal キャピタルワン アムドックス スカイスキャナー Comcast T-MobileArchived at Ghostarchive and the Wayback Machine: シーメンス ウォルマート 三菱電機 東芝

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

製品要因

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

プロセスとツールの要因

「バザールスタイル」の開発をサポートするプラクティス 「バザールスタイル」の品質保証をサポートするプラクティス コラボレーションを促進するためのツールの標準化

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

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

参考文献