Add missing patlets to 16 initial-stage patterns

rrrutledge · claude · rrrutledge · commit 53ea86769750 · 2026-05-05T06:36:41.000-05:00
- 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 &lt;noreply@anthropic.com&gt;
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
 
