From 53ea86769750deb480c8f5d368b943855bfd37b3 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Tue, 5 May 2026 06:22:51 -0500 Subject: [PATCH 1/3] Add missing patlets to 16 initial-stage patterns - Fix # Patlet heading level to ## Patlet in 3 files (balancing-openness-and-security, code-consumers, explicit-shared-ownership) - Write patlets for 14 patterns that had TBD placeholder content - All patlets derived from each pattern's existing Problem/Context/Solution sections Co-Authored-By: Claude Sonnet 4.6 --- patterns/1-initial/assisted_compliance.md | 2 +- patterns/1-initial/bad-weather-for-liftoff.md | 2 +- patterns/1-initial/balancing-openness-and-security.md | 2 +- patterns/1-initial/change-the-developers-mindset.md | 2 +- patterns/1-initial/code-consumers.md | 4 ++-- patterns/1-initial/cultural-change-through-hiring.md | 2 +- patterns/1-initial/defeat-hierarchical-constraints.md | 2 +- ...eloper-incentive-alignment-for-innersource-contribution.md | 2 +- patterns/1-initial/duplicated-projects.md | 2 +- patterns/1-initial/explicit-shared-ownership.md | 2 +- patterns/1-initial/junkyard-styled-innersourcing.md | 2 +- patterns/1-initial/organizational-mindset-change.md | 2 +- .../1-initial/overcome-acquisition-based-silos-developer.md | 2 +- .../1-initial/overcome-acquisition-based-silos-manager.md | 2 +- patterns/1-initial/reluctance-to-accept-contributions.md | 2 +- patterns/1-initial/share-your-code-to-get-more-done.md | 2 +- 16 files changed, 17 insertions(+), 17 deletions(-) diff --git a/patterns/1-initial/assisted_compliance.md b/patterns/1-initial/assisted_compliance.md index 9bfd0b58a..ca0c089ea 100644 --- a/patterns/1-initial/assisted_compliance.md +++ b/patterns/1-initial/assisted_compliance.md @@ -4,7 +4,7 @@ Assisted Compliance ## Patlet -TBD +Repo owners resist adding compliance documentation like CONTRIBUTING.md, blocking contributions and slowing InnerSource adoption. A compliance task force breaks the stalemate by writing the missing documentation as a pull request on behalf of the resistant team, framing it as helpful contribution rather than enforcement. ## Problem diff --git a/patterns/1-initial/bad-weather-for-liftoff.md b/patterns/1-initial/bad-weather-for-liftoff.md index 3397188a2..92a061708 100644 --- a/patterns/1-initial/bad-weather-for-liftoff.md +++ b/patterns/1-initial/bad-weather-for-liftoff.md @@ -4,7 +4,7 @@ Bad weather for liftoff ## Patlet -TBD +An InnerSource initiative fails to demonstrate improvement in quality or speed because the team lacks open source development experience and deadline pressure prevents adopting new ways of working. Starting InnerSource pilots with experienced practitioners and protecting time for new practices are prerequisites for success. ## Problem diff --git a/patterns/1-initial/balancing-openness-and-security.md b/patterns/1-initial/balancing-openness-and-security.md index ee11406dd..3e3cbabc0 100644 --- a/patterns/1-initial/balancing-openness-and-security.md +++ b/patterns/1-initial/balancing-openness-and-security.md @@ -2,7 +2,7 @@ Balancing Openness and Security -# Patlet +## Patlet While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks. diff --git a/patterns/1-initial/change-the-developers-mindset.md b/patterns/1-initial/change-the-developers-mindset.md index 654325cb5..c4fc9073f 100644 --- a/patterns/1-initial/change-the-developers-mindset.md +++ b/patterns/1-initial/change-the-developers-mindset.md @@ -4,7 +4,7 @@ Change the developers mindset ## Patlet -TBD +Developers resist adopting InnerSource collaboration practices because they are comfortable with existing hierarchical workflows and middle management does not actively support the change. Combining visible recognition of InnerSource contributions, formalized training, clearer processes, and explicit management objectives creates the conditions needed to shift developer behavior. ## Problem diff --git a/patterns/1-initial/code-consumers.md b/patterns/1-initial/code-consumers.md index eaee8ef11..2744b8c72 100644 --- a/patterns/1-initial/code-consumers.md +++ b/patterns/1-initial/code-consumers.md @@ -2,9 +2,9 @@ Code Consumers -# Patlet +## Patlet -TBD +When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers. # Problem diff --git a/patterns/1-initial/cultural-change-through-hiring.md b/patterns/1-initial/cultural-change-through-hiring.md index 9f96444f2..5472d426d 100644 --- a/patterns/1-initial/cultural-change-through-hiring.md +++ b/patterns/1-initial/cultural-change-through-hiring.md @@ -4,7 +4,7 @@ Culture Change through Hiring ## Patlet -TBD +An InnerSource program struggles to reach critical mass because most existing employees lack open source or InnerSource experience, and HR does not factor in collaborative development skills when recruiting or reviewing performance. By aligning Engineering and HR to actively seek and develop these skills, organizations accelerate cultural change and build a self-sustaining InnerSource community. ## Problem diff --git a/patterns/1-initial/defeat-hierarchical-constraints.md b/patterns/1-initial/defeat-hierarchical-constraints.md index b26ac86da..ffd54ec7d 100644 --- a/patterns/1-initial/defeat-hierarchical-constraints.md +++ b/patterns/1-initial/defeat-hierarchical-constraints.md @@ -4,7 +4,7 @@ Defeat Hierarchical Constraints ## Patlet -TBD +In strongly hierarchical organizations, developers want to contribute to InnerSource projects but are blocked by direct managers who prioritize their own team's goals and fear losing their team's time to cross-team work. Making InnerSource contributions a recognized part of individual performance goals and helping managers see concrete benefits for their own teams can empower developers to participate despite these constraints. ## Problem diff --git a/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md b/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md index 55a04ab7a..b0827dc4c 100644 --- a/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md +++ b/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md @@ -4,7 +4,7 @@ Developer Incentive Alignment for InnerSource Contribution ## Patlet -TBD +Developers are not motivated to contribute to InnerSource because organizational incentives reward individual code output over cross-team mentorship and collaboration, leading to siloed work. By embedding InnerSource contribution and mentorship expectations into job descriptions and promotion criteria at each career level, organizations align personal career advancement with InnerSource participation. ## Problem diff --git a/patterns/1-initial/duplicated-projects.md b/patterns/1-initial/duplicated-projects.md index d929d379a..d64c59f8b 100644 --- a/patterns/1-initial/duplicated-projects.md +++ b/patterns/1-initial/duplicated-projects.md @@ -4,7 +4,7 @@ Duplicated Projects ## Patlet -TBD +After opening codebases through InnerSource, teams discover they have independently built overlapping or identical products, but territorial management and differing technical approaches make consolidation difficult. Establishing a neutral governance process that gives all managers meaningful influence over the merged project makes it possible to consolidate duplicated efforts without losing key stakeholders. ## Problem diff --git a/patterns/1-initial/explicit-shared-ownership.md b/patterns/1-initial/explicit-shared-ownership.md index 87104cb76..038a48090 100644 --- a/patterns/1-initial/explicit-shared-ownership.md +++ b/patterns/1-initial/explicit-shared-ownership.md @@ -2,7 +2,7 @@ Explicit Shared Ownership -# Patlet +## Patlet A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership. diff --git a/patterns/1-initial/junkyard-styled-innersourcing.md b/patterns/1-initial/junkyard-styled-innersourcing.md index 6042dd90a..b9eed9a58 100644 --- a/patterns/1-initial/junkyard-styled-innersourcing.md +++ b/patterns/1-initial/junkyard-styled-innersourcing.md @@ -5,7 +5,7 @@ ## Patlet -TBD +Developers share code internally for the sake of sharing without regard for reusability or production readiness, resulting in a repository of low-quality components that others find but cannot safely use. Supporting all contributions while transparently communicating component maturity — and engaging contributors in quality improvements — keeps the shared repository growing without discouraging participation. ## Context diff --git a/patterns/1-initial/organizational-mindset-change.md b/patterns/1-initial/organizational-mindset-change.md index 85d7b88ff..499451439 100644 --- a/patterns/1-initial/organizational-mindset-change.md +++ b/patterns/1-initial/organizational-mindset-change.md @@ -4,7 +4,7 @@ Organizational Mindset Change ## Patlet -TBD +Upper management, middle management, and developers all need to shift their mindset to support InnerSource, but organizational change is slow and costly, and pressures from deadlines and competition make experimentation feel too risky. A phased approach that starts with a small visible experiment, demonstrates concrete value early, and uses that momentum to broaden adoption is the most effective path to lasting culture change. ## Problem diff --git a/patterns/1-initial/overcome-acquisition-based-silos-developer.md b/patterns/1-initial/overcome-acquisition-based-silos-developer.md index 84ec681c1..0e5414feb 100644 --- a/patterns/1-initial/overcome-acquisition-based-silos-developer.md +++ b/patterns/1-initial/overcome-acquisition-based-silos-developer.md @@ -4,7 +4,7 @@ Overcome Acquisition-based Silos (Developer Level) ## Patlet -TBD +After a company acquisition, development teams remain siloed due to distrust, unfamiliar tools and processes, and fear of losing identity or job security, preventing the efficient cross-team collaboration InnerSource requires. A neutral governance committee, clear rules for handling code redundancy, generous onboarding, and face-to-face engagement help acquired developers overcome these barriers and begin contributing through InnerSource. ## Problem diff --git a/patterns/1-initial/overcome-acquisition-based-silos-manager.md b/patterns/1-initial/overcome-acquisition-based-silos-manager.md index c947a83f3..fa7928ebf 100644 --- a/patterns/1-initial/overcome-acquisition-based-silos-manager.md +++ b/patterns/1-initial/overcome-acquisition-based-silos-manager.md @@ -4,7 +4,7 @@ Overcome Acquisition-based Silos (Management Level) ## Patlet -TBD +After a company acquisition, middle managers from the acquired company resist InnerSource collaboration out of fear of losing control over their team, their code domain, and their developer resources. A neutral governance committee, career advancement opportunities tied to InnerSource participation, and a realistic integration timeline with measurable milestones help managers feel secure enough to support cross-company collaboration. ## Problem diff --git a/patterns/1-initial/reluctance-to-accept-contributions.md b/patterns/1-initial/reluctance-to-accept-contributions.md index 2868bce14..c43221773 100644 --- a/patterns/1-initial/reluctance-to-accept-contributions.md +++ b/patterns/1-initial/reluctance-to-accept-contributions.md @@ -4,7 +4,7 @@ Reluctance to accept contributions ## Patlet -TBD +The team owning a shared InnerSource component is reluctant to accept contributions because doing so means taking on maintenance responsibility for unfamiliar code of uncertain quality. Establishing clear contribution guidelines, a time-limited post-merge support warranty from contributors, and a documented review workflow gives the host team confidence to accept contributions while setting clear expectations for contributors. ## Problem diff --git a/patterns/1-initial/share-your-code-to-get-more-done.md b/patterns/1-initial/share-your-code-to-get-more-done.md index d8cf0ad64..2fb9f99b7 100644 --- a/patterns/1-initial/share-your-code-to-get-more-done.md +++ b/patterns/1-initial/share-your-code-to-get-more-done.md @@ -4,7 +4,7 @@ Share Your Code to Get More Done ## Patlet -TBD +Development teams working in silos cannot deliver software fast enough but have no obvious path to increase throughput, unaware that opening their codebase to InnerSource contributions could unlock capacity from developers across the organization. By building an evidence-based project plan showing the value of contributions and actively recruiting potential contributors, teams expand their effective development capacity without adding permanent headcount. ## Problem From ad5936098eea43e996947d0872bea8221f7d04d7 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Tue, 5 May 2026 21:34:40 +0200 Subject: [PATCH 2/3] Adapting heading level in these patterns to h2 (##) --- .../balancing-openness-and-security.md | 40 +++++++++---------- patterns/1-initial/code-consumers.md | 18 ++++----- .../1-initial/explicit-shared-ownership.md | 14 +++---- 3 files changed, 36 insertions(+), 36 deletions(-) diff --git a/patterns/1-initial/balancing-openness-and-security.md b/patterns/1-initial/balancing-openness-and-security.md index 3e3cbabc0..9afa74e76 100644 --- a/patterns/1-initial/balancing-openness-and-security.md +++ b/patterns/1-initial/balancing-openness-and-security.md @@ -1,4 +1,4 @@ -# Title +## Title Balancing Openness and Security @@ -7,11 +7,11 @@ Balancing Openness and Security While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks. -# Problem +## Problem A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap), while good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege]. How to balance and address these seemingly contradicting requirements? -# Story +## Story Most organizations developing proprietary software will have source code that they do not want to leave the organization, as this may harm their business. Think what would happen when the major competitors would have access to their latest features and would know what they are working on next. @@ -19,7 +19,7 @@ Even when the source code management system is not compromised from the outside, Restricting access typically reduces the risk of these things from happening, but at the same time hampers collaboration and re-use. -# Context +## Context - The organization has an InnerSource Program Office (ISPO), or a similar group, steering the success of the InnerSource initiative in the organization. One of their goals is to stimulate maximum openness and transparency in the organization. - The organization has a Security Team constraining unnecessary data access to prevent the organization from data-leakage and malicious code injection. @@ -27,7 +27,7 @@ Restricting access typically reduces the risk of these things from happening, bu - "Closed Source" is the default in the organization when creating new repositories, i.e. only the team owning/maintaining the code has access to the given repo. - "Shared Source" within the organization isn’t common practice. Organizational teams aren’t familiar with what code or information should or shouldn’t be placed in shared repositories. -# Forces +## Forces - A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap) - Good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege]. @@ -35,13 +35,13 @@ Restricting access typically reduces the risk of these things from happening, bu - Engineering Teams focus more on service/product development or knowledge sharing than on measures for data protection. While it is easy for Engineering Teams to decide to close or open the repository, they are usually not willing to spend time on judging how to reach a balance between both. Or to refactor their code in order to be able to share more. - No one-fit-all guideline or rules to judge what data or process is to be secured or not. That much depends on data sensitivity and overall security policy/infrastructure. -# Solutions +## Solutions To reduce the misalignment and possible misunderstanding between the teams involved, it is key to bring everybody together so that they can express their goals and concerns, and develop shared language together. After that they can decide as a group how to drive the execution of the specific goals, and what to do to reduce the risks that were identified. -## Setup +### Setup Start by bringing (representatives from) Engineering, Security, Legal, and the ISPO together, to discuss the goals of the InnerSource initiative, as well as any security concerns. @@ -55,13 +55,13 @@ Some helpful practices are: - **SHARED** - inner source: accessible for all software developers in the organization - **CLOSED** - closed source: only accessible to named individuals in the organization -## Execution +### Execution How to allow for a greater amount of SHARED code in the organizations depends a lot on the specific business domain, related regulations, and concerns identified in the initial meetings of the InnerSource task force as mentioned above. Following are some practices that have proven to be helpful in reducing security concerns and allowing for a greater amount of SHARED code. -### Security Training and SCM Setup +#### Security Training and SCM Setup - Employee training about security awareness and individual responsibility - Enhanced security measures or policies on source code management (SCM) system to prevent malicious access to shared repositories and reduce the impact of the same: @@ -76,12 +76,12 @@ Following are some practices that have proven to be helpful in reducing security - downloading source code from new devices - downloading a great amount of source code in the monitoring period. -### Split out the 'secret sauce' into separate repos +#### Split out the 'secret sauce' into separate repos Separate highly specific, differentiating code (the 'secret sauce') from code that is considered commodity in the organization (e.g. infrastructure, platform, and UI components). By placing them in separate repositories, you increase your chances of offering the commodity code as SHARED repos, while the 'secret sauce' may stay CLOSED. -### Prevent sensitive information in shared repositories +#### Prevent sensitive information in shared repositories Build up agreed security requirement of InnerSource, such as: @@ -92,7 +92,7 @@ Build up agreed security requirement of InnerSource, such as: - Leverage secrets scanning tools to scan the target repositories (including code, test cases, and helper scripts) for confidential data such as accounts, passwords, access tokens, keys, and other sensitive data. - Keep repositories CLOSED, but expose metadata about the projects (i.e. through an [InnerSource Portal][innersource-portal]), and create some kind of access request workflow. This way you could still give people access to the code, but not open it to everyone by default. *(Note: The full model is described under **Extension: An Additional Sharing Level**)* -### Extension: An Additional Sharing Level +#### Extension: An Additional Sharing Level In some cases, introducing additional sharing levels might be appropriate. Use cases include: @@ -118,7 +118,7 @@ Repositories with RESTRICTED sharing level are included in the [central catalog] - RESTRICTED repos will likely get fewer contributions due to the additional step to access the code. Where possible, INTERNAL repos should be preferred. - It is possible to use a tool that automatically adds the `README.md` and some other metadata to an internal repository in GitHub, allowing the GitHub search feature to include this data in the search results. -# Sketch +## Sketch ``` Example Repository Sharing Levels @@ -137,7 +137,7 @@ Example Repository Sharing Levels └──────┘ ``` -# Resulting Context +## Resulting Context InnerSource adoption in an organization will often [start as an experiment][start-as-an-experiment], with a small number of SHARED repositories. @@ -149,32 +149,32 @@ With the increased confidence and lessons learned from this experiment, the task Most importantly, the changes implemented through this pattern lead to more code being shared between teams, and closed source will no longer be the obvious default. -# Known Instances +## Known Instances * Philips * Verizon -# Status +## Status - Initial -# Authors +## Authors - Bart Golsteijn - Jack Yang - Sebastian Spier -# Acknowledgements +## Acknowledgements - Conley Rogers -# Alias +## Alias - Secure Discoverability - Secure Code Sharing - Secure InnerSource -# Notes (internal) +## Notes (internal) *These notes are meant for internal use within the InnerSource Commons Patterns Working Group only.* diff --git a/patterns/1-initial/code-consumers.md b/patterns/1-initial/code-consumers.md index 2744b8c72..06432fbb0 100644 --- a/patterns/1-initial/code-consumers.md +++ b/patterns/1-initial/code-consumers.md @@ -1,4 +1,4 @@ -# Title +## Title Code Consumers @@ -6,7 +6,7 @@ Code Consumers When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers. -# Problem +## Problem There's several reasons why we might want to know who's using (consuming) our code. We can't do the following: @@ -16,18 +16,18 @@ There's several reasons why we might want to know who's using (consuming) our co * encourage others to use a project - by showing how many users there already are * survey users for feedback -# Context +## Context This is a general issue that affects potentially all InnerSource (and open source!) projects. The act of opening code allows people to use it without letting you know. -# Forces +## Forces * The harder it is to download/integrate the project, the less it will be adopted (forcing people to give information when they use it adds barriers) * Not all projects may want you to know what they're using (tightly closed source/top secret downstream project) * Putting in callback/call home routines into projects may introduce distrust in downstream projects and users -# Solutions +## Solutions The following are potential solutions that have been proposed to this problem: @@ -37,21 +37,21 @@ The following are potential solutions that have been proposed to this problem: * Audit code clones/artifact downloads * Incentivise/Offer users a mailing list/update stream to which they can subscribe -# Resulting Context +## Resulting Context TBD -# Known Instances +## Known Instances TBD -# Authors +## Authors * Georg Grütter (Robert Bosch GmbH) * Raimund Hook (EXFO Inc) * Katrina Novakovic (RedHat) -# Status +## Status * Initial * Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019 diff --git a/patterns/1-initial/explicit-shared-ownership.md b/patterns/1-initial/explicit-shared-ownership.md index 038a48090..43be8a8b7 100644 --- a/patterns/1-initial/explicit-shared-ownership.md +++ b/patterns/1-initial/explicit-shared-ownership.md @@ -1,4 +1,4 @@ -# Title +## Title Explicit Shared Ownership @@ -6,7 +6,7 @@ Explicit Shared Ownership A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership. -# Problem +## Problem An organization is already using InnerSource best practices in several teams. The architecture of the software offered has grown organically. @@ -14,7 +14,7 @@ While talking about code ownership and accountability, teams notice that there i Simply forking the component would lead to a lot of duplication and wasted effort. Therefore the involved teams are looking for a less intrusive solution to the issue. -# Context +## Context - Teams are working independently but are providing one common platform as a service. @@ -22,7 +22,7 @@ Simply forking the component would lead to a lot of duplication and wasted effor - One component is in widespread use but ownership is unclear. -# Forces +## Forces - Ownership of one component is unclear. @@ -31,13 +31,13 @@ Simply forking the component would lead to a lot of duplication and wasted effor - There may be people dependent on the module that are not yet known. There often is fear around maintenance efforts arising from unwanted attribution to the project. -# Solution +## Solution Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed: A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a proposed list of initial [Trusted Committers](../2-structured/trusted-committer.md). This suggestion is posted to the project's documentation (e.g. it's `README.md` file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone. -# Resulting Context +## Resulting Context There is an initial team of [Trusted Committers](../2-structured/trusted-committer.md) committed to the component. @@ -47,7 +47,7 @@ The entire decision process backing the result is transparent and can be influen There is a proven way to adjust the setup in the future. -# Status +## Status Initial (early draft) From f82fd9e3a7f6e1ad06b4206ca49af35d39faee28 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Tue, 5 May 2026 21:47:43 +0200 Subject: [PATCH 3/3] Adding new Patlets to the overview in the README. Other minor fixes. --- README.md | 28 +++++++++---------- .../reluctance-to-accept-contributions.md | 2 ++ 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 199e35b91..27e81e6df 100644 --- a/README.md +++ b/README.md @@ -69,9 +69,9 @@ Our mission * [Introducing Metrics in InnerSource](patterns/1-initial/introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.* * [Shared Code Repo Different from Build Repo](patterns/1-initial/shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.* * [InnerSource Portal - Hygiene](patterns/1-initial/innersource-portal-hygiene.md) - *Allow generation of an official badge for projects intending to be recognized as InnerSource project within your company.* -* [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.* +* [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *The team owning a shared InnerSource component is reluctant to accept contributions because doing so means taking on maintenance responsibility for unfamiliar code of uncertain quality. Establishing clear contribution guidelines, a time-limited post-merge support warranty from contributors, and a documented review workflow gives the host team confidence to accept contributions while setting clear expectations for contributors.* * [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.* +* [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Repo owners resist adding compliance documentation like CONTRIBUTING.md, blocking contributions and slowing InnerSource adoption. A compliance task force breaks the stalemate by writing the missing documentation as a pull request on behalf of the resistant team, framing it as helpful contribution rather than enforcement.* * [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.* * [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.* @@ -105,25 +105,25 @@ NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential f This is why we keep these patterns at the bottom of the list. --> -* [Overcome Acquisition Based Silos - Developers](patterns/1-initial/overcome-acquisition-based-silos-developer.md) -* [Overcome Acquisition Based Silos - Managers](patterns/1-initial/overcome-acquisition-based-silos-manager.md) +* [Overcome Acquisition Based Silos - Developers](patterns/1-initial/overcome-acquisition-based-silos-developer.md) - *After a company acquisition, development teams remain siloed due to distrust, unfamiliar tools and processes, and fear of losing identity or job security, preventing the efficient cross-team collaboration InnerSource requires. A neutral governance committee, clear rules for handling code redundancy, generous onboarding, and face-to-face engagement help acquired developers overcome these barriers and begin contributing through InnerSource.* +* [Overcome Acquisition Based Silos - Managers](patterns/1-initial/overcome-acquisition-based-silos-manager.md) - *After a company acquisition, middle managers from the acquired company resist InnerSource collaboration out of fear of losing control over their team, their code domain, and their developer resources. A neutral governance committee, career advancement opportunities tied to InnerSource participation, and a realistic integration timeline with measurable milestones help managers feel secure enough to support cross-company collaboration.* * [Discover Your InnerSource](patterns/1-initial/discover-your-innersource.md) -* [Junkyard Styled Inner Sourcing](patterns/1-initial/junkyard-styled-innersourcing.md) -* [Incentive Alignment](patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md) -* [Change the Developers Mindset](patterns/1-initial/change-the-developers-mindset.md) +* [Junkyard Styled Inner Sourcing](patterns/1-initial/junkyard-styled-innersourcing.md) - *Developers share code internally for the sake of sharing without regard for reusability or production readiness, resulting in a repository of low-quality components that others find but cannot safely use. Supporting all contributions while transparently communicating component maturity — and engaging contributors in quality improvements — keeps the shared repository growing without discouraging participation.* +* [Incentive Alignment](patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md) - *Developers are not motivated to contribute to InnerSource because organizational incentives reward individual code output over cross-team mentorship and collaboration, leading to siloed work. By embedding InnerSource contribution and mentorship expectations into job descriptions and promotion criteria at each career level, organizations align personal career advancement with InnerSource participation.* +* [Change the Developers Mindset](patterns/1-initial/change-the-developers-mindset.md) - *Developers resist adopting InnerSource collaboration practices because they are comfortable with existing hierarchical workflows and middle management does not actively support the change. Combining visible recognition of InnerSource contributions, formalized training, clearer processes, and explicit management objectives creates the conditions needed to shift developer behavior.* * [Change the Middle-Management Mindset](patterns/1-initial/change-the-middle-management-mindset.md) -* [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md) -* [Code Consumers](patterns/1-initial/code-consumers.md) +* [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md) - *Development teams working in silos cannot deliver software fast enough but have no obvious path to increase throughput, unaware that opening their codebase to InnerSource contributions could unlock capacity from developers across the organization. By building an evidence-based project plan showing the value of contributions and actively recruiting potential contributors, teams expand their effective development capacity without adding permanent headcount.* +* [Code Consumers](patterns/1-initial/code-consumers.md) - *When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers.* * [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md) -* [Culture Change through Hiring](patterns/1-initial/cultural-change-through-hiring.md) +* [Culture Change through Hiring](patterns/1-initial/cultural-change-through-hiring.md) - *An InnerSource program struggles to reach critical mass because most existing employees lack open source or InnerSource experience, and HR does not factor in collaborative development skills when recruiting or reviewing performance. By aligning Engineering and HR to actively seek and develop these skills, organizations accelerate cultural change and build a self-sustaining InnerSource community.* #### Donuts (needing a solution) -* [How to Defeat the Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md) -* [Organizational Mindset Change](patterns/1-initial/organizational-mindset-change.md) -* [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md) +* [Defeat Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md) - *In strongly hierarchical organizations, developers want to contribute to InnerSource projects but are blocked by direct managers who prioritize their own team's goals and fear losing their team's time to cross-team work. Making InnerSource contributions a recognized part of individual performance goals and helping managers see concrete benefits for their own teams can empower developers to participate despite these constraints.* +* [Organizational Mindset Change](patterns/1-initial/organizational-mindset-change.md) - *Upper management, middle management, and developers all need to shift their mindset to support InnerSource, but organizational change is slow and costly, and pressures from deadlines and competition make experimentation feel too risky. A phased approach that starts with a small visible experiment, demonstrates concrete value early, and uses that momentum to broaden adoption is the most effective path to lasting culture change.* +* [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md) - *An InnerSource initiative fails to demonstrate improvement in quality or speed because the team lacks open source development experience and deadline pressure prevents adopting new ways of working. Starting InnerSource pilots with experienced practitioners and protecting time for new practices are prerequisites for success.* * [Incentive mechanisms to foster voluntary contribution](patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md) -* [Duplicated Projects](patterns/1-initial/duplicated-projects.md) +* [Duplicated Projects](patterns/1-initial/duplicated-projects.md) - *After opening codebases through InnerSource, teams discover they have independently built overlapping or identical products, but territorial management and differing technical approaches make consolidation difficult. Establishing a neutral governance process that gives all managers meaningful influence over the merged project makes it possible to consolidate duplicated efforts without losing key stakeholders.* * [Sustainable InnerSource Program](patterns/1-initial/sustainable-innersource-program.md) ## What are InnerSource Patterns? diff --git a/patterns/1-initial/reluctance-to-accept-contributions.md b/patterns/1-initial/reluctance-to-accept-contributions.md index c43221773..c35dff0f3 100644 --- a/patterns/1-initial/reluctance-to-accept-contributions.md +++ b/patterns/1-initial/reluctance-to-accept-contributions.md @@ -70,6 +70,8 @@ Klaas-Jan Stol ## References +Old Patlet: Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined. + Pattern was first created in the gDoc: [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) (this section can be deleted once the conversion from gDoc to markdown is complete)