In the open source contribution pattern, teams are given responsibility for developing specific architectural components but are not expected to be the only contributing developers. When this pattern works well, a team will act as a benevolent dictator over their components, reviewing submitted changes to a component for quality and conceptual integrity. This pattern allows for limited centralized control across the architecture. Use this pattern when there are experts available from multiple development teams or when there is a common dependency on specific components.
For this pattern to be successful, teams must know they are responsible for specific components and have a firm understanding of where their components fit within the larger context. Provide only the owning team with write access to enforce architectural responsibility for the component. All other teams should have the ability to submit changes for review. Create style guides, design for testability, and impose constraints on technologies and build platforms, to make it easier for developers to contribute.
Category | Allocation |
Elements |
Team—a group who may submit or review component changes. Repository—version control repository containing software components. |
Relations |
Owns—indicates a team responsible for reviewing changes and maintaining conceptual integrity over a repository. The owner is sometimes called the repository’s benevolent dictator. May contribute to—indicates a team who may submit changes to a repository. |
Rules for Use | Repositories typically have only one owner but this is not a strict rule. Teams to contribute to many repositories. |
Strengths | Promotes reusability, maintainability, and development speed |
Weaknesses | This pattern is strongly tied with the component partitioning strategy. In many cases the learning curve for contributions is so steep this pattern becomes impractical. May require the owning teams to adopt other open management practices to be successful. |
The open source contribution pattern pairs well with any architecture patterns that also promotes reusability. Giving teams the ability to contribute changes can create opportunities for reuse that might not exist otherwise.
3.137.170.241