Join us on Tuesday, October 8th, at 8am GMT / 9am CEST / 12:30pm IST / 6pm AEDT when Vincent Caldeira, Red Hat, Clemens Jütte, Humanitec, and Luiz Fernando Almeida de Oliveira, Red Hat, will discuss Promoting InnerSource Practices with an Internal Developer Platform.

InnerSourceの原則

会社、チーム、プロジェクト、そして個人はそれぞれ異ります。 ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。 しかし、InnerSourceの成功例の根底には4つの原則があります。 これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。

これらの原則は次の通りです:

  • オープン性

  • 透明性

  • 優先的なメンターシップ

  • 自発的なコードコントリビューション

それでは、それぞれの原則について詳細を見ていきましょう。

オープン性

オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。 プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになっていなければなりません。 組織の中の誰もが、目的としていたプロジェクトを見つけ、ホストチームのメンバからの過度な直接指導がなくても成長できるようになっていなければなりません。 ホストチームの連絡先情報は、そのプロジェクトにとって理にかなう程度の多くのチャネルに広められていなければなりません。 InnerSourceのコントリビューションを彼らのプロジェクトに受け入れるというホストチームの意図は、注目度を高めるために関連する組織のチャネルを通して共有されるべきです。 特に、小さめの環境では、あなたのチームが行っているInnerSourceの作業について定期的に"ブロードキャスト"したいかも知れません。 しかし、より大きい環境では、このようなブロードキャストは、多量のノイズとなる可能性があるため、簡単に使えるツールでプロジェクトを発見可能とする方が適切かも知れません。 忘れないでください。目標は、あなたの会社で機能する適切なチャネルを意識して使用することです。

上に記したことは、網羅的なリストではありません。 プロジェクトのオープン性は、通常、InnerSourceの観点でプロジェクトがどれくらい成功しているかに直接関係しています。 オープンであればあるぼど、将来の貢献者に対する障壁が少なくなります。 オープンでなければないほど、誰かが貢献することが困難になります。

透明性

ゲストチームがプロジェクトに有意義な貢献を行うには、ホストチームは 透明 でなければなりません。 これは、ゲストチームが以下のことを理解できるようにしておくことを意味します。

  • プロジェクト/リポジトリとその方向性

  • 未解決の機能要件

  • 機能要件の進捗

  • ホストチームの意思決事項

可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。 このコミュニケーションは、コアチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。

優先的なメンターシップ

Trusted Committer によるホストチームからゲストチームへの メンターシップ は、InnerSourceの重要な点になります。 ゲストチームの コントリビューター は、ホストチームのプロジェクト/リポジトリについて十分理解し、成功裏に変更できるようにレベルアップされます。 この過程で、彼らはプロジェクト/ソフトウェアの一般的な利用者かつアンバサダーとして、ホストチームのソフトウェアシステムをより良く理解するようになります。 この個人のコントリビューターは、経験を重ねることで、Trusted Committerとしてプロジェクトでより広範な役割を果たすことができます。

コントリビューターのためのメンターシップが、ホストチームで優先されることは重要です。 ホストチームは、ゲストチームのコントリビューターを指導するにあたり、ホストチームが都合が良いときでなく、 コントリビューターが必要とする時に 時間を作るように努めなければなりません。 ホストチームのエンジニアが、自分自身のコーディングだけより、他の人のコーディングを手伝うことに時間を費やすということは、文化の変化となるかもしれません。 このメンターシップは、個人のコントリビューターとホストの両者に価値があるもので、うまく行う価値があります。 長期的に相互に有益であることがわかります。 コードの改善をすることにより、コントリビューターは、そうでなければ存在しなかったかも知れない組織内の関係を構築したり改善したりします。 オープンソースは、このポイントを容易に認識しており、プロジェクトでTrusted Committerの地位を得ることは名誉なことだと考えています。

自発的なコードコントリビューション

最初の 自発的 という言葉は、ゲストチームとホストのチームの両方からInnerSourceに参加することが、彼らの自由意志に基づいて行われることを意味します。 ゲストチームは自発的にコードをホストチームに寄付し、ホストチームは自発的にそれを受け入れます。 このオプトインの性質は、それぞれのチームの関与が他チームの目的への付加価値となることを確信している必要があることを意味しています。 ホストチームは、彼らのミッションと全く一致しないコントリビューションを受け入れることは決してありません。 ゲストチームは、彼らのミッションや優先事項を全く進めないコントリビューションを提出することは決してありません。

コード という言葉は、ゲストとホストのコラボレーションがコードにまで及んでいることを強調しています。 ゲストが、イシューのオープンや要件の更新、ドキュメントの修正などへ関与することは良いことですが、ここまでに議論してきた効果を全て得るためには、コードを提供するに至るまでのコラボレーションが必要です。

Contributors