InnerSourceとは何か
INNERSOURCEとは何か
InnerSourceという用語は、2000年にTim O’Reillyによって初めて造られ、組織内でオープンソース開発技術を使用してプロプライエタリコードを開発することを表しています。これは、企業のファイアウォール内でオープン性と透明性の原則を推進します。
InnerSourceが大規模に実装されると、組織のすべてのコードを閲覧し、有用なものを使用し、自分の状況に必要な変更を貢献することができます。その後、信頼されたコミッターがそれらの変更を元のコードベースに組み込むかどうかを決定します。これは、オープンソースコミュニティの仕組みを再現しますが、結果として得られるソースコードは企業の範囲内に留まります。安全な環境でオープンソース文化に慣れるための優れた方法です。
InnerSourceはオープンソースへの道のりの一歩として使用できますが、InnerSourceを実装している組織は、この実践が組織のサイロを打破し、ボトルネックを削減し、知識共有を促進し、イノベーションを加速させることも報告しています。実際、最新世代の開発者はオープンソースの世界で育ち、関連する主体性と自律性のレベルを持っているため、InnerSourceを採用することで、今日最も優秀な開発者を見つけ、維持しやすい労働環境を作ることができます。
InnerSourceの起源
2000年代初頭に初めて造られましたが、InnerSourceのアイデアが本格的に勢いを増し始めたのは2015年で、長年のオープンソース支持者であるDanese CooperがInnerSourceの使用を提唱し始めた時でした。
これは、企業におけるオープンソースへの関心の高まりと一致しました。Danese Cooperは、PayPalのオープンソースプログラムを統括するために雇われましたが、PayPalがオープンソースエコシステムに成功裏に参加する前に、オープンコラボレーションについて多くを学ぶ必要があることにすぐに気づきました。2015年、彼女は年次OSCON会議で基調講演を行い、PayPalがオープンソース開発への道のりの一環としてInnerSourceスキルの構築に注力することを発表しました。その講演で、彼女はInnerSourceに関する知識を作成し共有することを目的とした個人のための実践コミュニティであるInnerSource Commonsの設立も発表しました。
それ以来、InnerSourceは、ビッグテックから銀行、製造、小売まで、あらゆる業界の世界中の数万人の開発者によって採用されています。
核心概念：効果的なサイロ横断ソフトウェア開発
コードの再利用は、多くの組織にとって重要な
優先事項となっています。
従来のサイロ化された組織では、再利用可能なコードが存在する可能性がありますが、チームは単にそれを見つけることができない、信頼できない、または貢献するインセンティブがありません。InnerSourceは、これらの障壁のそれぞれに体系的に対処します。
オープンソースの実践を内部で採用することにより、コードは組織全体で発見可能になり、どのエンジニアもどのコードベースにも変更を提案できます。ホストチームは「信頼されたコミッター」として機能し、すべてのコード行を自分で書くのではなく、貢献をレビューしてマージします。これにより、InnerSourceは組織の境界を越えたソフトウェア開発における効果的なコラボレーションを可能にする原則と実践を提供します。
見つけられない
チームのリポジトリに隠されたコード
標準化されたドキュメントを備えた共有可能で発見可能なリポジトリ
信頼できない
品質が不明、レビュープロセスがない
InnerSourceコードが見られ、再利用されるために書かれているという事実と、ピアレビュー文化が組み合わさることで、より高品質なコードが生成され、信頼と自信が構築されます
貢献できない
組織の境界がPRを妨げる
InnerSourceの実践(例：信頼されたコミッターの役割)は、チーム間の貢献を正式化します
これはオープンソースとどう違うのか
仕組みは非常に似ていますが、
その範囲が異なります。
- オープンソース：コードは一般に公開されます。
- InnerSource：コードは組織内の従業員のみが閲覧および編集できる状態に留まります。知的財産を保護しながら、労働力の潜在能力を解き放ちます。
組織がInnerSourceを採用する理由
- 市場投入までの時間の短縮：チームは他の部門への依存によってブロックされることがなくなります。
- 知識共有：ドキュメントと透明な意思決定が標準となり、知識が個人の頭の中に閉じ込められることを防ぎます。
- より高品質なコード：より多くの目がコードに向けられ、標準化されたレビュープロセスにより、バグが早期に発見されます。
- 開発者の満足度：エンジニアは自分の問題を解決し、直属のユニット外の仲間とつながる力を得たと感じます。
