InnerSourceのコントリビューターになるメリット

最も自明な動機は、初期のコントリビューターをオープンソースに引き込むことです。

あなたが長い間回避してきた迷惑なバグを覚えていますか？ これらの回避策のメンテナンスに費やす時間とエネルギーは？ アップストリームチームが将来その問題を修正するのを待たずに、先に自分で問題を修正できるとしたらどうでしょうか？ この「自分の手で問題を解決する」状況が初めてのコントリビューターは、自分のコードベースの回避策の数を減らすために、日々の作業に依存するプロジェクトの問題を修正することから始めることがよくあります。

独自の回避策を維持するのではなく、修正を作成してコントリビューションするかどうかを決めるときには、そのコントリビューションが独自の変更の品質にもたらすメリットについて考えてください。 単独で作業する代わりに、アップストリームプロジェクトで作業する人は、あなたのソリューションをレビューするだけでなく改善することもできます。 サポートと指導を受けることで、開発作業が大幅にスピードアップします。

他の人と多くの時間を過ごすことは、時間が経つにつれて、チームがどのように機能するか、どのように組織化されるか、どのようなツールを用いてプロジェクトを構築しているかを学ぶことを意味します。 新しいライブラリやビルドシステムについて読むだけではなく、それを自分のプロジェクトに導入する前に実践的な経験を積むことができるので、多くの場合、あなた自身のプロジェクトもその経験から恩恵を受けることになるでしょう。 複数のコアプロジェクトに取り組むことは、課題に対するベストプラクティスとソリューションを引き出す、より大きなエコシステムに晒されることを意味します。

他のチームで時間を過ごすことができることのプラス面の副次的効果は、あなたの評判と影響力が自分のチームの境界を超えて広がることです。 つまり、他の人から学び自分自身が成長することに加えて、プロジェクトに影響を与えることができます。 あなたは、自分自身のコントリビューションやプロジェクトのツールとセットアップに関する経験や知識を共有によって直接影響を与えます。 この共有は、アップストリームプロジェクトが開発サイクルを改善し加速するのに役立つかもしれません。

これらの客観的な基準のすべて以外にも、測定するのが非常に難しい要素がありますが、それらはInnerSourceとオープンソースプロジェクトの両方で同様に報告されています：人々はプロジェクトでの作業が個人的に充実していて楽しいから参加しています。 おそらくは、取り組むタスクを本当に自己選択できる立場にあるという側面が重要な枠割を果たしています。 この自己選択は、通常、ホストプロジェクトがコントリビューターのモチベーションを維持するための取り組みで非常に歓迎され支援することにつながります。

アップストリームでついに修正された厄介なバグを覚えていますか？ あなたのチームが、アップストリームプロジェクトにその修正を加えるために、余分な労力を費やす必要があるのはなぜでしょうか？

ひとつは、メンテナンスのコストと時間が、今はアップストリームプロジェクトにあることを意味します。 新しいリリースごとに、あなたの修正や要件が動作し続けるか、あなたのチームに代わって彼らが確認します。

チームメンバーが依存しているプロジェクトのアクティブなコントリビューターとしてとして働くことは、彼らがそのプロジェクトの方向性とスケジュールについて発言権を持つことを意味し、あなたのチームにとって有益となる可能性があります。

InnerSourceを利用することで、チームは「独立して自分で構築する」(自分自身の新しいバグをいくつも含む)と「既存の実装に依存することで時間とお金を節約する」(限られた方法でしか影響を与えられない長期的な依存関係を作る代償として)との中間パスを確立することができます。 そうすることで、再実装と再利用とのバランスをとることが容易になります。

会社のドメインの特定機能でありながら、会社全体では複数の実装が維持されていることを覚えていますか？ １ダースものバギーな実装を回避して、共有アセットにマージする方法があるとしたらどうでしょうか？ この共有アセットの開発プロセスが、中心的な依存関係がテーブルにもたらす通常のエネルギーなしに実行された場合はどうなるでしょうか？ 多くのオープンソースプロジェクトは膨大な数のプレイヤーによって利用されており、その中には設計や開発に参加しているプレイヤーもいます。 企業レベルでInnerSourceプロジェクトのチーム間のコラボレーションを促進することは、組織の端から中央のイノベーションを推進できることを意味します。

一般的に、 バスファクター が1人か2人のプロジェクトが組織にリスクをもたらすことはよく理解されていますが、そのプロジェクトがビジネスの目的の中心であることが明らかになった場合はなおさらです。 InnerSourceはこうしたプロジェクトの透明性を高めるだけでなく、メンタリングに重点を置きコントリビューターの基盤を拡大することで状況を改善するツールも提供しています。

チーム間のコラボレーションは、個人貢献の評価を難しくしますが、組織内での学習と知識の共有も可能にします。 その結果、個人の影響力が向上します。 ベストプラクティスやポジティブなイノベーションは、組織全体に容易に広がるようになるでしょう。 副次的な効果として、職場環境の改善が組織全体に広がりやすくなり、従業員の定着に役立ちます。

技術面で、より多様な背景を持つより多くの視点を持つことは、コードの変更がより精査され、全体的な品質とセキュリティの向上につながることを意味します。

最後に、プロジェクトのユーザーと顧客が開発に参加できるようにすることに重点を置くことで、これらのプロジェクトを簡単に始めることができるようにするための非常に明確なインセンティブが提供されます：標準的なツールをベースに、理解しやすく、再利用しやすく、結果的にモジュール化され、交換可能なものになっています。

この記事で見てきたように、個人や企業がオープンソースに積極的になる理由の多くは、InnerSourceプロジェクトにも当てはまります。 私たちはまた、InnerSourceプロジェクトで人々を協力させるのは利他的な理由だけではないことも見てきました。多くの場合、このようなコラボレーションが多くの意味を持つ場合、ビジネス上の理由を簡単に特定できます。