Fix missing patlets (#906)

* 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 <noreply@anthropic.com>

* Adapting heading level in these patterns to h2 (##)

* Adding new Patlets to the overview in the README. Other minor fixes.

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Sebastian Spier <github@spier.hu>

Author: 3 people

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?

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
 

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