diff --git a/README.md b/README.md index c89470c8e..1e41e6862 100644 --- a/README.md +++ b/README.md @@ -58,6 +58,7 @@ Our mission * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.* * [Standard Release Process](patterns/2-structured/release-process.md) - *Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.* * [Group Support](patterns/2-structured/group-support.md) - *What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.* +* [Explicit Governance Levels](patterns/2-structured/governance-levels.md) - *Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.* ### Maturity Level 1: Initial @@ -71,7 +72,6 @@ Our mission * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.* * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.* * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.* -* [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.* * [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.* * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.* * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.* diff --git a/assets/img/flutter-pyramid.svg b/assets/img/flutter-pyramid.svg deleted file mode 100644 index a23d324d4..000000000 --- a/assets/img/flutter-pyramid.svg +++ /dev/null @@ -1,3 +0,0 @@ - - -
1. Readable Source
1. Readable Source
2. Guest
Contributions
2. Guest...
3. Maintainers in
Multiple Teams
3. Maintainers in...Viewer does not support full SVG 1.1 \ No newline at end of file diff --git a/assets/img/governance-levels/1.png b/assets/img/governance-levels/1.png new file mode 100644 index 000000000..acca4cccb Binary files /dev/null and b/assets/img/governance-levels/1.png differ diff --git a/assets/img/governance-levels/2.png b/assets/img/governance-levels/2.png new file mode 100644 index 000000000..55471d0c5 Binary files /dev/null and b/assets/img/governance-levels/2.png differ diff --git a/assets/img/governance-levels/3.png b/assets/img/governance-levels/3.png new file mode 100644 index 000000000..ed8da186c Binary files /dev/null and b/assets/img/governance-levels/3.png differ diff --git a/assets/img/governance-levels/4.png b/assets/img/governance-levels/4.png new file mode 100644 index 000000000..0ceb985c7 Binary files /dev/null and b/assets/img/governance-levels/4.png differ diff --git a/assets/img/governance-levels/flutter-pyramid.png b/assets/img/governance-levels/flutter-pyramid.png new file mode 100644 index 000000000..0eb8f1fa0 Binary files /dev/null and b/assets/img/governance-levels/flutter-pyramid.png differ diff --git a/book/en/toc.md b/book/en/toc.md index 0027209d1..064e0d0b0 100644 --- a/book/en/toc.md +++ b/book/en/toc.md @@ -27,6 +27,7 @@ Instead edit toc_template.md * [Cross-Team Project Valuation](../../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it. * [Dedicated Community Leader](../../patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative. * [Document your Guiding Principles](../../patterns/2-structured/document-your-guiding-principles.md) - The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely. +* [Explicit Governance Levels](../../patterns/2-structured/governance-levels.md) - Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike. * [Extensions for Sustainable Growth](../../patterns/2-structured/extensions-for-sustainable-growth.md) - An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead. * [Gig Marketplace](../../patterns/2-structured/gig-marketplace.md) - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions. * [Group Support](../../patterns/2-structured/group-support.md) - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals. diff --git a/book/scripts/Gemfile b/book/scripts/Gemfile index 1cd3261e2..b6ad7dc6a 100644 --- a/book/scripts/Gemfile +++ b/book/scripts/Gemfile @@ -4,4 +4,4 @@ source "https://rubygems.org" git_source(:github) {|repo_name| "https://github.com/#{repo_name}" } -gem 'commonmarker' +gem 'commonmarker', "0.18.2" diff --git a/pattern-categorization/innersource-program-mind-map.html b/pattern-categorization/innersource-program-mind-map.html index 982f418e6..26ecf063e 100644 --- a/pattern-categorization/innersource-program-mind-map.html +++ b/pattern-categorization/innersource-program-mind-map.html @@ -27,6 +27,6 @@ (getOptions || markmap.deriveOptions)(jsonOptions), root2 ); - })(() => window.markmap,null,{"content":"InnerSource Program","children":[{"content":"Begin","children":[{"content":"Program Setup","children":[{"content":"Management hesitates to invest in InnerSource","children":[{"content":"Start as an Experiment","children":[],"payload":{"tag":"h5","lines":"8,9"}}],"payload":{"tag":"h4","lines":"6,7"}},{"content":"Slow community growth hinders InnerSource","children":[{"content":"Dedicated Community Leader","children":[],"payload":{"tag":"h5","lines":"12,13"}}],"payload":{"tag":"h4","lines":"10,11"}},{"content":"InnerSource principles are not intuitive for everybody","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"16,17"}}],"payload":{"tag":"h4","lines":"14,15"}}],"payload":{"tag":"h3","lines":"4,5"}},{"content":"Project Setup","children":[{"content":"Hard to assess a project quickly","children":[{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"22,23"}}],"payload":{"tag":"h4","lines":"20,21"}},{"content":"Ad-hoc communication hinders project growth","children":[{"content":"Communication Tooling","children":[],"payload":{"tag":"h5","lines":"26,27"}}],"payload":{"tag":"h4","lines":"24,25"}},{"content":"Intransparent roadmap and direction of the project","children":[{"content":"Issue Tracker Use Cases","children":[],"payload":{"tag":"h5","lines":"30,31"}}],"payload":{"tag":"h4","lines":"28,29"}}],"payload":{"tag":"h3","lines":"18,19"}}],"payload":{"tag":"h2","lines":"2,3"}},{"content":"Adopt","children":[{"content":"Valuation Challenges","children":[{"content":"How to measure a project's business value","children":[{"content":"Cross-Team Project Valuation","children":[],"payload":{"tag":"h5","lines":"38,39"}}],"payload":{"tag":"h4","lines":"36,37"}},{"content":"Can we rely on the project for an extended period?","children":[{"content":"Standard Release Process","children":[],"payload":{"tag":"h5","lines":"42,43"}},{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"44,45"}}],"payload":{"tag":"h4","lines":"40,41"}}],"payload":{"tag":"h3","lines":"34,35"}},{"content":"Cultural Challenges","children":[{"content":"Unrecognized effort","children":[{"content":"Praise Participants","children":[],"payload":{"tag":"h5","lines":"50,51"}},{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"52,53"}}],"payload":{"tag":"h4","lines":"48,49"}}],"payload":{"tag":"h3","lines":"46,47"}},{"content":"Technical Challenges","children":[{"content":"Not meeting everyone's needs","children":[{"content":"Common Requirements","children":[],"payload":{"tag":"h5","lines":"58,59"}}],"payload":{"tag":"h4","lines":"56,57"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"62,63"}}],"payload":{"tag":"h4","lines":"60,61"}},{"content":"Project is difficult to contribute to and use","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"66,67"}}],"payload":{"tag":"h4","lines":"64,65"}}],"payload":{"tag":"h3","lines":"54,55"}},{"content":"Organizational Challenges","children":[{"content":"Discouragement of contributing resource","children":[{"content":"Contracted Contributor","children":[],"payload":{"tag":"h5","lines":"72,73"}}],"payload":{"tag":"h4","lines":"70,71"}},{"content":"Rejection of accepting contribution","children":[{"content":"30 Day Warranty","children":[],"payload":{"tag":"h5","lines":"76,77"}}],"payload":{"tag":"h4","lines":"74,75"}},{"content":"Radical change of management","children":[{"content":"Review Committee","children":[],"payload":{"tag":"h5","lines":"80,81"}}],"payload":{"tag":"h4","lines":"78,79"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"84,85"}}],"payload":{"tag":"h4","lines":"82,83"}},{"content":"Not enough maintainers to scale","children":[{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"88,89"}}],"payload":{"tag":"h4","lines":"86,87"}},{"content":"Difficult cross-team coordination","children":[{"content":"Transparent Cross-Team Decision Making using RFCs","children":[],"payload":{"tag":"h5","lines":"92,93"}}],"payload":{"tag":"h4","lines":"90,91"}},{"content":"Project without an owner/maintainer","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"96,97"}},{"content":"Group Support","children":[],"payload":{"tag":"h5","lines":"98,99"}}],"payload":{"tag":"h4","lines":"94,95"}}],"payload":{"tag":"h3","lines":"68,69"}},{"content":"Cross Legal Entities Challenges","children":[{"content":"Concern on legal liabilities or cross-company accounting","children":[{"content":"InnerSource License","children":[],"payload":{"tag":"h5","lines":"104,105"}}],"payload":{"tag":"h4","lines":"102,103"}}],"payload":{"tag":"h3","lines":"100,101"}}],"payload":{"tag":"h2","lines":"32,33"}},{"content":"Grow","children":[{"content":"Discovery Challenges","children":[{"content":"Can't find matching projects","children":[{"content":"Gig Marketplace","children":[],"payload":{"tag":"h5","lines":"112,113"}},{"content":"InnerSource Portal","children":[],"payload":{"tag":"h5","lines":"114,115"}}],"payload":{"tag":"h4","lines":"110,111"}},{"content":"Difficult to find active projects","children":[{"content":"Repository Activity Score","children":[],"payload":{"tag":"h5","lines":"118,119"}}],"payload":{"tag":"h4","lines":"116,117"}}],"payload":{"tag":"h3","lines":"108,109"}}],"payload":{"tag":"h2","lines":"106,107"}},{"content":"Scale","children":[{"content":"Self Education/Improvement Challenges","children":[{"content":"Not aware of InnerSource best practices","children":[{"content":"Maturity Model","children":[],"payload":{"tag":"h5","lines":"126,127"}}],"payload":{"tag":"h4","lines":"124,125"}},{"content":"Lack of open source knowledge","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"130,131"}}],"payload":{"tag":"h4","lines":"128,129"}}],"payload":{"tag":"h3","lines":"122,123"}},{"content":"Technical Challenges","children":[{"content":"Increasing maintenance overhead","children":[{"content":"Extensions for Sustainable Growth","children":[],"payload":{"tag":"h5","lines":"136,137"}}],"payload":{"tag":"h4","lines":"134,135"}}],"payload":{"tag":"h3","lines":"132,133"}}],"payload":{"tag":"h2","lines":"120,121"}}],"payload":{"tag":"h1","lines":"0,1"}},null) + })(() => window.markmap,null,{"content":"InnerSource Program","children":[{"content":"Begin","children":[{"content":"Program Setup","children":[{"content":"Management hesitates to invest in InnerSource","children":[{"content":"Start as an Experiment","children":[],"payload":{"tag":"h5","lines":"8,9"}}],"payload":{"tag":"h4","lines":"6,7"}},{"content":"Slow community growth hinders InnerSource","children":[{"content":"Dedicated Community Leader","children":[],"payload":{"tag":"h5","lines":"12,13"}}],"payload":{"tag":"h4","lines":"10,11"}},{"content":"InnerSource principles are not intuitive for everybody","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"16,17"}}],"payload":{"tag":"h4","lines":"14,15"}}],"payload":{"tag":"h3","lines":"4,5"}},{"content":"Project Setup","children":[{"content":"Hard to assess a project quickly","children":[{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"22,23"}}],"payload":{"tag":"h4","lines":"20,21"}},{"content":"Ad-hoc communication hinders project growth","children":[{"content":"Communication Tooling","children":[],"payload":{"tag":"h5","lines":"26,27"}}],"payload":{"tag":"h4","lines":"24,25"}},{"content":"Intransparent roadmap and direction of the project","children":[{"content":"Issue Tracker Use Cases","children":[],"payload":{"tag":"h5","lines":"30,31"}}],"payload":{"tag":"h4","lines":"28,29"}},{"content":"Language around project governance is ambiguous","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"34,35"}}],"payload":{"tag":"h4","lines":"32,33"}}],"payload":{"tag":"h3","lines":"18,19"}}],"payload":{"tag":"h2","lines":"2,3"}},{"content":"Adopt","children":[{"content":"Valuation Challenges","children":[{"content":"How to measure a project's business value","children":[{"content":"Cross-Team Project Valuation","children":[],"payload":{"tag":"h5","lines":"42,43"}}],"payload":{"tag":"h4","lines":"40,41"}},{"content":"Can we rely on the project for an extended period?","children":[{"content":"Standard Release Process","children":[],"payload":{"tag":"h5","lines":"46,47"}},{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"48,49"}}],"payload":{"tag":"h4","lines":"44,45"}}],"payload":{"tag":"h3","lines":"38,39"}},{"content":"Cultural Challenges","children":[{"content":"Unrecognized effort","children":[{"content":"Praise Participants","children":[],"payload":{"tag":"h5","lines":"54,55"}},{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"56,57"}}],"payload":{"tag":"h4","lines":"52,53"}}],"payload":{"tag":"h3","lines":"50,51"}},{"content":"Technical Challenges","children":[{"content":"Not meeting everyone's needs","children":[{"content":"Common Requirements","children":[],"payload":{"tag":"h5","lines":"62,63"}}],"payload":{"tag":"h4","lines":"60,61"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"66,67"}}],"payload":{"tag":"h4","lines":"64,65"}},{"content":"Project is difficult to contribute to and use","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"70,71"}}],"payload":{"tag":"h4","lines":"68,69"}}],"payload":{"tag":"h3","lines":"58,59"}},{"content":"Organizational Challenges","children":[{"content":"Discouragement of contributing resource","children":[{"content":"Contracted Contributor","children":[],"payload":{"tag":"h5","lines":"76,77"}}],"payload":{"tag":"h4","lines":"74,75"}},{"content":"Rejection of accepting contribution","children":[{"content":"30 Day Warranty","children":[],"payload":{"tag":"h5","lines":"80,81"}}],"payload":{"tag":"h4","lines":"78,79"}},{"content":"Radical change of management","children":[{"content":"Review Committee","children":[],"payload":{"tag":"h5","lines":"84,85"}}],"payload":{"tag":"h4","lines":"82,83"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"88,89"}}],"payload":{"tag":"h4","lines":"86,87"}},{"content":"Not enough maintainers to scale","children":[{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"92,93"}}],"payload":{"tag":"h4","lines":"90,91"}},{"content":"Difficult cross-team coordination","children":[{"content":"Transparent Cross-Team Decision Making using RFCs","children":[],"payload":{"tag":"h5","lines":"96,97"}}],"payload":{"tag":"h4","lines":"94,95"}},{"content":"Level of influence for contributing teams is unclear","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"100,101"}}],"payload":{"tag":"h4","lines":"98,99"}},{"content":"Project without an owner/maintainer","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"104,105"}},{"content":"Group Support","children":[],"payload":{"tag":"h5","lines":"106,107"}}],"payload":{"tag":"h4","lines":"102,103"}}],"payload":{"tag":"h3","lines":"72,73"}},{"content":"Cross Legal Entities Challenges","children":[{"content":"Concern on legal liabilities or cross-company accounting","children":[{"content":"InnerSource License","children":[],"payload":{"tag":"h5","lines":"112,113"}}],"payload":{"tag":"h4","lines":"110,111"}}],"payload":{"tag":"h3","lines":"108,109"}}],"payload":{"tag":"h2","lines":"36,37"}},{"content":"Grow","children":[{"content":"Discovery Challenges","children":[{"content":"Can't find matching projects","children":[{"content":"Gig Marketplace","children":[],"payload":{"tag":"h5","lines":"120,121"}},{"content":"InnerSource Portal","children":[],"payload":{"tag":"h5","lines":"122,123"}}],"payload":{"tag":"h4","lines":"118,119"}},{"content":"Difficult to find active projects","children":[{"content":"Repository Activity Score","children":[],"payload":{"tag":"h5","lines":"126,127"}}],"payload":{"tag":"h4","lines":"124,125"}}],"payload":{"tag":"h3","lines":"116,117"}}],"payload":{"tag":"h2","lines":"114,115"}},{"content":"Scale","children":[{"content":"Self Education/Improvement Challenges","children":[{"content":"Not aware of InnerSource best practices","children":[{"content":"Maturity Model","children":[],"payload":{"tag":"h5","lines":"134,135"}}],"payload":{"tag":"h4","lines":"132,133"}},{"content":"Lack of open source knowledge","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"138,139"}}],"payload":{"tag":"h4","lines":"136,137"}}],"payload":{"tag":"h3","lines":"130,131"}},{"content":"Technical Challenges","children":[{"content":"Increasing maintenance overhead","children":[{"content":"Extensions for Sustainable Growth","children":[],"payload":{"tag":"h5","lines":"144,145"}}],"payload":{"tag":"h4","lines":"142,143"}}],"payload":{"tag":"h3","lines":"140,141"}}],"payload":{"tag":"h2","lines":"128,129"}}],"payload":{"tag":"h1","lines":"0,1"}},null) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index 9bccd8332..6caf8f186 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -30,6 +30,10 @@ ##### [Issue Tracker Use Cases](https://patterns.innersourcecommons.org/p/issue-tracker) +#### Language around project governance is ambiguous + +##### [Explicit Governance Levels](https://patterns.innersourcecommons.org/p/governance-levels) + ## Adopt ### Valuation Challenges @@ -92,6 +96,10 @@ ##### [Transparent Cross-Team Decision Making using RFCs](https://patterns.innersourcecommons.org/p/transparent-cross-team-decision-making-using-rfcs) +#### Level of influence for contributing teams is unclear + +##### [Explicit Governance Levels](https://patterns.innersourcecommons.org/p/governance-levels) + #### Project without an owner/maintainer ##### [Core Team](https://patterns.innersourcecommons.org/p/core-team) diff --git a/pattern-categorization/innersource-program-mind-map.png b/pattern-categorization/innersource-program-mind-map.png index 389a7e07a..ddf9a119d 100644 Binary files a/pattern-categorization/innersource-program-mind-map.png and b/pattern-categorization/innersource-program-mind-map.png differ diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md deleted file mode 100644 index 75d19ee98..000000000 --- a/patterns/1-initial/governance-levels.md +++ /dev/null @@ -1,100 +0,0 @@ -## Title - -Transparent Governance Levels - -## Patlet - -Several teams are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. - -Estabilishing a more accurate common language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity. - -## Problem - -Several teams are using InnerSource practices. However the degree to which they welcome contributions and give equal collaboration rights to contributors differ. Despite these differences, all teams refer to their way of working as "InnerSource" without any additional qualifiers. - -The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications. - -## Stories - -### Example of Confusion - -For two projects InnerSource best practices have been adopted. Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. Project B is fully owned by one team with contributions from other teams. New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications. - -### Example of Delayed Decision - -Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made. - -### Examples from Open Source - -Like "InnerSource", Open Source is also a broad term. - -There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it. - -There are projects where the roadmap is created in-house, hidden from public view. Where commit rights come and go with the contract of the employees of one company (e.g. MongoDB, Elastic, Tensorflow). Users are welcome to submit patches, they will even be mentored through. All development happens in the open, but control and strategy is never shared. This would be the equivalent of stage "Contributions Welcome". - -There are projects that share write access, but do not share the power to decide who gets write access next. This applies to everyone who is only a committer at an Apache project. There are projects that are fully shared across multiple independent organizations (e.g. k8s, any Apache project) - those would be "Shared Ownership". - -The same levels make sense inside of organizations. - -## Context - -- InnerSource concepts are established within an organization with multiple projects and teams adopting InnerSource. -- Internal InnerSource practices are not prescribed in detail. -- Teams/projects have the autonomy to optimise for their local circumstances. - -## Forces - -- Projects adopt different InnerSource patterns and practices to optimise for their context. -- Users want clarity on the level of influence they can gain in an InnerSource project when deciding whether or how to use it. -- Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits. -- Writing a detailed description of a set of InnerSource practices requires significant effort. - -## Solution - -The solution is to create a universally understood language to describe the InnerSource operating models that are used in your organization. - -We define **InnerSource operating model** as a description of how much influence the core development team of a project ist willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project. - -The shared language for these InnerSource operating models can be established with these steps: - -1. Identify the common recurring InnerSource operating models that exist in your teams and projects. -2. Document each model in detail, and give each a distinctive name. -3. Promote the use of these names to describe projects until the name's meaning is understood across the whole organization. - -Examples of common InnerSource operating models (1) are: - -- **Bug Reports and Issues Welcome**: People outside the core development team may use the code. They can submit feature requests and bug reports for things they would like to see changed. -- **Contributions Welcome**: People outside the core development team may use the code. They can also make modifications and submit them to core team for inclusion. -- **Shared Ownership** (sometimes called **Distributed Ownership**): Members of different teams collaborate on the project as equal peers. Everyone has the ability to merge code. Everyone has an equal say on the project direction. Everyone has an equal say in who else to add to this group. - -Examples of promoting the model names (3) are: - -- Using the names within project documentation and contributing guides (see also [Standard Base Documentation](../2-structured/base-documentation.md)). -- Labelling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md). -- Presenting the names as a menu of adoption options for new InnerSource projects. -- Including the names and models in any internal InnerSource training or promotion. - -## Resulting Context - -- Cross team communication occurs efficiently without confusion using terms that are universally understood and centrally documented. -- Organization leaders understand the nuances within practising InnerSource and make better informed and more precise decisions that are easier to communicate. -- Increased standardisation of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption. -- Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating. - -## Known Instances - -* BBC - referenced in this talk: [Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC)](https://www.youtube.com/watch?v=O8TK7QG3FjM) -* Flutter Entertainment - -![InnerSource Pyramid used by Flutter Entertainment](../../assets/img/flutter-pyramid.svg) - -Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/) to describe 3 different InnerSource operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. - -## Status - -Structured - -## Authors - -- Isabel Drost-Fromm -- Rob Tuley diff --git a/patterns/2-structured/governance-levels.md b/patterns/2-structured/governance-levels.md new file mode 100644 index 000000000..b991ffb55 --- /dev/null +++ b/patterns/2-structured/governance-levels.md @@ -0,0 +1,171 @@ +## Title + +Explicit Governance Levels + +## Patlet + +Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. +Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike. + +## Problem + +Several teams are using InnerSource practices. +However the degree to which they welcome contributions and give equal collaboration rights to contributors differ. +Despite these differences, all teams refer to their way of working as "InnerSource" without any additional qualifiers. + +The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. +This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications. + +## Story + +### Example of Confusion + +For two projects, different InnerSource practices have been adopted. +Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. +Project B is fully owned by one team with contributions from other teams. + +New users of either project are regularly confused about the level of influence they can gain in the respective project. +This leads to long discussions, escalations and time lost on clarifications. + +### Example of Delayed Decision + +Project C is currently closed source and used only by team 1. +Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. +Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made. + +## Context + +- InnerSource concepts are established within an organization with multiple projects and teams adopting InnerSource. +- Internal InnerSource practices are not prescribed in detail. +- Teams/projects have the autonomy to optimize for their local circumstances. + +## Forces + +- Projects adopt different InnerSource patterns and practices to optimize for their context. +- Users want clarity on the level of influence they can gain in an InnerSource project when deciding whether or how to use it. +- Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits. +- Writing a detailed description of a set of InnerSource practices requires significant effort. + +## Solution + +Create centrally maintained documentation of the project governance levels that are used in your organization. +The governance levels describe how much influence the host team of a project is willing to share with contributing teams. +Or in other terms, the level of influence a contributing team can gain in the respective project. + +Note: Instead of "governance levels" we might also say "operating models", or "ownership models". +We stick to the term "governance levels" throughout this pattern. +Feel free to use whatever terms fits your organization best. + +To establish governance levels in your organization, we recommend these activities: + +1. Define your governance levels - **Goal**: Have a clear written description of the governance levels, that you can refer to as a reference. +2. Promote your governance levels - **Goal**: The governance levels are known and understood throughout your organization. + +We will go into more detail on each of these activities in the following sections. + +### Define your Governance Levels + +The goal of this activity is to have a clear written description of the governance levels, that you can refer to as a reference. + + - Document the governance levels that are commonly used in your organization. + - Document additional governance levels that you don't have yet, but that would benefit the cross-team collaboration in your organization. + - Give each of them a distinctive and descriptive name. + - Use specific projects as examples where helpful. + - Keep this documentation in a central place that you can easily reference that can be accessed by everybody. + +#### Commonly used Governance Levels + +The following governance levels are commonly used when practicing InnerSource. + +Each of these levels adds more influence/karma to the contributing team. +However each step also requires more transparency and shared communication resources between both teams. + +1. **Bug Reports and Issues Welcome**: + - People outside the host team may use the code. + - They can submit feature requests and bug reports for things they would like to see changed. + - aka **Readable Source**, **Shared Source** +2. **Contributions Welcome**: + - People outside the host team may use the code. + - They can make modifications and submit them to the host team for inclusion. + - aka **Guest Contributions** +3. **Shared Write Access**: + - People outside of the host team can get write access to the project. + - The host team may give outside contributors additional leverage in the strategic direction of the project. + - Related Pattern: [Trusted Committer](../2-structured/trusted-committer.md) +4. **Shared Ownership**: + - Members of different teams collaborate on the project as equal peers. + - Everyone has the ability to merge code. + - Everyone has an equal say on the project direction. + - Everyone has an equal say in who else to add to this group. + - aka **Distributed Ownership**, **Maintainers in Multiple Team** + - Related Pattern: [Group Support](../2-structured/group-support.md) + +
+
Bug Reports and Issues Welcome

Bug Reports and Issues Welcome

+
Contributions Welcome

Contributions Welcome

+
Shared Write Access

Shared Write Access

+
Shared Ownership

Shared Ownership

+
+ +### Promote your Governance Levels + +The goal of this activity is that the governance levels are known and understood throughout your organization, and that some of your higher profile InnerSource project start to adopt these governance levels explicitly. + +- Present your governance levels in existing knowledge sharing forums in your organization. Make sure to explain the why, not just the what! +- Whenever talking about your governance levels, make sure to stick to he exact names/titles of your governance levels. +- Use the names of your governance levels within project documentation and contributing guides (see also [Standard Base Documentation](../2-structured/base-documentation.md)). +- Label projects with the governance levels in an [InnerSource Portal](../2-structured/innersource-portal.md), so that contributors can see at a glance what type of InnerSource collaboration the host team supports for the given project. +- Create training material containing examples of projects in your organization. That makes it easier for people in your organization to related to these examples and understand what these governance levels mean and how they work. +- Present the governance levels as a menu of adoption options when launching new InnerSource projects. + +## Resulting Context + +- Cross team communication occurs efficiently without confusion, using terms that are universally understood and centrally documented. +- Organization leaders understand the nuances within practicing InnerSource and make better informed and more precise decisions that are easier to communicate. +- Increased standardization of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption. +- Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating. + +## Rationale + +Like "InnerSource", Open Source is also a broad term. + +There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it. We call this **shared source**, which would not qualify as open source software (OSS) yet. + +There are projects where the roadmap is created in-house, hidden from public view. Where commit rights come and go with the contract of the employees of one company (e.g. MongoDB, Elastic, Tensorflow). Users are welcome to submit patches, they will even be mentored through. All development happens in the open, but control and strategy is never shared. This would be the equivalent of stage "Contributions Welcome". We call this **single vendor OSS**. + +There are projects that share write access, but do not share the power to decide who gets write access next. This applies to everyone who is only a committer at an Apache project. + +There are projects that are fully shared across multiple independent organizations (e.g. k8s, any Apache project) - those would be "Shared Ownership". We call this **vendor neutral OS**. + +The same levels make sense inside of organizations. + +## Known Instances + +- BBC - referenced in this talk: [Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC)](https://www.youtube.com/watch?v=O8TK7QG3FjM) +- Flutter Entertainment +- Europace AG + +### Flutter Entertainment + +Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/pyramid/) to describe three different operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorization of each InnerSource project. + +![InnerSource Pyramid as used by Flutter Entertainment](../../assets/img/governance-levels/flutter-pyramid.png) + +## Status + +- Structured + +## Authors + +- Isabel Drost-Fromm +- Rob Tuley +- Tom Sadler +- Sebastian Spier + +## Alias + +- Governance Framework (for InnerSource) +- Defined Project Governance +- Project Ownership Models +- Explicitly Defined Governance +- InnerSource Operating Models (seems a bit too broad, as readers might expect this to include CI/CD setups, code review tooling, and the like)