OSS型の貢献

特定コンポーネントに責任のあるチーム以外の開発者が開発に貢献する。

パターンがうまく機能すると、「優しい独裁者と多数の貢献者」という構図になる。

アーキテクチャを横断した集中管理が可能になる。

複数のチームから専門家の協力が得られる場合、特定コンポーネントに共通の依存関係がある場合にこのパターンが向く。

パターンがうまく機能するための条件としては、

チームがそれぞれ特定コンポーネントに責務を持つことを理解していること。

そのコンポーネントがより大きなアーキテクチャのどこに当てはまるのか理解していること。

コンポーネントに責任を持つチームのみが書き込みアクセス権を持つこと。

アーキテクチャ上のコンポーネントの責務を強制するため

他のチームはレビューのために変更を提出する権限だけを持つこと。

貢献者が開発しやすいようスタイルガイドを作成し、テスト容易な構造を保つこと。

要素

チーム。コンポーネントの変更を提出またはレビューできるグループ。

リポジトリ。ソフトウェアコンポーネントを含むバージョン管理リポジトリ。

関係

「チームAはコンポーネントBを所有する」リポジトリ全体にわたり、変更・レビューの整合性の維持にチームが責任を負っていることを示す。

「チームCはコンポーネントDに貢献する可能性がある」変更を提出できるチームを示す。

規約

リポジトリは通常1つのチームに所有されるが、これは厳密でなくて良い。チームは沢山のリポジトリに貢献できる。

強み

再利用性、保守性、開発スピードを上げる。

弱み

コンポーネントの分割方法と密接な関係がある。分割方法がまずいと機能しないかもしれない。

多くの場合、貢献が可能になるまでの学習曲線は急勾配になる。