feat: add Migrating from InnerSource to Open Source

.github/workflows/overview-complete.yml

@@ -0,0 +1,46 @@
+# Check if all patterns are listed in README.md
+name: Overview Complete
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  overviewComplete:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v5
+
+      - name: Check if all patterns are listed in README.md
+        run: |
+          README="README.md"
+
+          # Ensure README.md exists
+          if [[ ! -f "$README" ]]; then
+              echo "Error: $README not found!"
+              exit 1
+          fi
+
+          missing=0
+
+          for file in patterns/*/*.md; do
+              if grep -qF "$file" "$README"; then
+                  echo "✔ Found: $file"
+              else
+                  echo "✘ Missing: $file"
+                  echo "✘ Pattern file not listed in README.md: $file" >> $GITHUB_STEP_SUMMARY
+                  missing=$((missing + 1))
+              fi
+          done
+
+          if [[ $missing -gt 0 ]]; then
+              echo "Some patterns are missing from $README."
+              exit 1
+          else
+              echo "All patterns are listed in $README."
+              exit 0
+          fi

README.md

@@ -98,6 +98,7 @@ Our mission
 * [Require InnerSource before Open Source](/patterns/1-initial/innersource-before-open-source.md) - *Maintaining and managing open source projects can be challenging for organizations, due to a lack of internal infrastructure and people with the knowledge of the required collaboration practices. By requiring projects to be InnerSource before becoming open source, teams have time to establish the necessary internal support, governance, and collaboration skills needed for successful community engagement.*
 * [AI Code Generation Context](patterns/1-initial/ai-code-generation-context.md) - *AI tools generate code that diverges from project standards and architectural patterns. Provide an AI Code Generation Context within the repositories to guide AI tools in producing contributions that align with existing project conventions, reducing review friction and maintaining code consistency.*
 * [InnerSource as a Career Booster](patterns/1-initial/innersource-as-career-booster.md) - *Many employees wonder how contributing to InnerSource projects benefits their careers beyond their immediate team objectives. By engaging in InnerSource, individuals expand their skills, grow their network, increase visibility across the organization, and unlock new career opportunities.*
+* [Migrating from InnerSource to Open Source](patterns/1-initial/migrating-from-innersource-to-open-source.md) - *TBD*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

patterns/1-initial/innersource-before-open-source.md

@@ -23,15 +23,22 @@ This pattern applies in organizations that:
 - Want to release internal software as open source.  
 - Lack structured internal collaboration processes.  
 - Have teams unfamiliar with maintaining open source projects.  
-- Need to establish internal governance and contribution models before engaging the broader open source community.  
+- Need to establish internal governance and contribution models before engaging the broader open source community.
+- Operate in regulated industries (healthcare, financial services) where compliance requirements are stringent.
+- Have concerns about intellectual property, security, or competitive advantage when releasing code publicly.
+- Want to validate project value and adoption internally before external exposure.  
 
 ## Forces
 
 - **Collaboration Readiness**: Teams may not be used to handling external contributions or asynchronous collaboration.  
 - **Documentation Gaps**: A lack of contributor guidelines, API documentation, and onboarding materials can hinder adoption.  
 - **Governance & Ownership**: Without clear ownership and decision-making processes, project direction can become unclear.  
 - **Support Burden**: Open source projects require active maintainers to review pull requests, address issues, and engage the community.  
-- **Security & Compliance**: Code may require review to meet licensing and security requirements before being released publicly.  
+- **Security & Compliance**: Code may require review to meet licensing and security requirements before being released publicly.
+- **Regulatory Compliance**: Increasing government regulations may require additional considerations when moving from InnerSource to Open Source.
+- **Intellectual Property Risk**: Corporate information embedded in comments or code may create legal exposure when released publicly.
+- **Bidirectional Movement**: Projects may need to move from Open Source back to InnerSource if they become unmaintained or face sustainability challenges.
+- **Market Awareness**: Limited understanding of InnerSource practices in the broader market may affect external adoption.  
 
 ## Solution
 
@@ -43,7 +50,11 @@ Before making a project open source, require it to go through an InnerSource pha
 4. Maintainers get to practice the soft skills required to support a community of people outside of their own team.
 5. Internal adoption and success metrics are measured to determine if the project is ready for external release. Some possible metrics are detailed in the [Repository Activity Score](../2-structured/repository-activity-score.md).
 6. Feedback loops are created to refine processes before engaging a broader open source audience.
-7. Decision about whether or not the project should be released as open source (based on the success metrics defined earlier). The incubation phase as an InnerSource project can be seen a quality gate. So naturally not all projects will pass that gate.
+7. **Legal and compliance review**: Conduct thorough checks for copyright, patents, and corporate information that may be embedded in comments or code before external release.
+8. **Security assessment**: Perform security reviews to ensure open sourcing won't create vulnerabilities or expose sensitive information.
+9. **OSP/OSPO vetting**: Have an Open Source Program Office (OSPO) or equivalent team review the project for engineering quality, legal compliance, and strategic alignment.
+10. **Approval process**: Establish a formal approval workflow where projects are added to an approved list that legal departments can reference for ongoing compliance.
+11. Decision about whether or not the project should be released as open source (based on the success metrics defined earlier). The incubation phase as an InnerSource project can be seen a quality gate. So naturally not all projects will pass that gate.
 
 ## Resulting Context
 
@@ -78,6 +89,7 @@ We are currently reviewing our InnerSource stage flow, where a project will be a
 
 - Sebastian Spier
 - Fernando Correa
+- Jeff Bailey
 
 ## Alias
 

patterns/1-initial/migrating-from-innersource-to-open-source.md

@@ -0,0 +1,125 @@
+## Title
+
+Migrating from InnerSource to Open Source
+
+## Patlet
+
+When an InnerSource project succeeds internally and meets criteria for external release, establish a process that addresses legal, security, governance, and community readiness to transition the project to open source while maintaining its internal value.
+
+## Problem
+
+Organizations with successful InnerSource projects may want to transition to open source but lack structured processes. Without proper planning, projects risk legal issues, security vulnerabilities, governance conflicts, and community challenges that could harm success and reputation.
+
+## Story
+
+A tech company developed a popular internal tool using InnerSource, achieving strong adoption and good documentation. When they open sourced it, they found corporate information in comments, unclear licenses, and no community processes. The rushed release caused legal issues, security risks, and overwhelmed maintainers struggling with external contributions.
+
+## Context
+
+This pattern applies when:
+
+- An InnerSource project has achieved internal success and adoption.
+- The organization has established InnerSource practices and governance.
+- There is strategic value in releasing the project publicly.
+- Legal and compliance frameworks are in place for open source releases.
+- The project team has experience with collaborative development practices.
+- External market demand or strategic positioning justifies open sourcing.
+
+## Forces
+
+- **Legal Complexity**: Existing code may contain proprietary information, unclear licensing, or patent concerns that must be resolved before public release
+- **Security Exposure**: Internal security practices may not be suitable for public code, requiring a comprehensive security review
+- **Governance Transition**: Internal governance structures may conflict with open source community expectations and meritocracy principles
+- **Community Readiness**: Internal teams may lack experience managing external contributors and community dynamics
+- **Resource Allocation**: Open source projects require ongoing maintenance and community support that may conflict with internal priorities
+- **Brand and Reputation**: Public release represents the organization to external communities and may impact brand perception
+- **Competitive Advantage**: Releasing code publicly may reduce competitive advantages while potentially increasing market influence
+- **Regulatory Compliance**: Industry-specific regulations may impose additional requirements for public code releases
+
+## Solutions
+
+Establish a comprehensive migration process that includes:
+
+1. **Pre-Migration Assessment**: Evaluate the project's readiness using established criteria, including adoption metrics, documentation quality, and community management capabilities
+
+2. **Legal and Compliance Review**:
+   - Conduct a thorough code review to identify and remove proprietary information.
+   - Establish clear licensing terms and intellectual property ownership.
+   - Perform patent and copyright clearance.
+   - Create legal documentation for external contributors.
+
+3. **Security Hardening**:
+   - Remove internal credentials, API keys, and sensitive configuration.
+   - Implement security best practices suitable for public code.
+   - Establish vulnerability disclosure processes.
+   - Create security documentation and guidelines.
+
+4. **Governance Structure Design**:
+   - Define decision-making processes that balance internal needs with community input to ensure effective outcomes.
+   - Establish maintainer roles and responsibilities.
+   - Create contribution guidelines and code of conduct.
+   - Design community management processes
+
+5. **Community Preparation**:
+   - Train maintainers on open source community management
+   - Establish communication channels and documentation standards.
+   - Create onboarding processes for external contributors.
+   - Develop community engagement strategies.
+
+6. **Infrastructure Setup**:
+   - Migrate to public repositories with appropriate access controls.
+   - Set up CI/CD pipelines suitable for public development.
+   - Establish issue tracking and project management tools.
+   - Create public documentation and websites.
+
+7. **Gradual Release Strategy**:
+   - Start with limited external access or beta releases.
+   - Gradually expand community participation.
+   - Monitor adoption and community health metrics.
+   - Adjust processes based on community feedback.
+
+8. **Ongoing Support Framework**:
+   - Establish maintenance and support processes.
+   - Create escalation procedures for critical issues.
+   - Define success metrics and review cycles.
+   - Plan for long-term sustainability
+
+## Resulting Context
+
+After successful migration:
+
+- The project gains external contributors and broader adoption.
+- Internal teams develop open source community management skills.
+- The organization builds a reputation within the open-source ecosystem.
+- Legal and compliance frameworks are established for future open source releases.
+- The project may require ongoing resource allocation for community management.
+- Internal development processes may need to adapt to the needs of the external community.
+- New opportunities for collaboration and innovation emerge through external partnerships.
+
+## Rationale
+
+Migrating from InnerSource to open source is a natural evolution for internal projects, but requires careful planning to avoid pitfalls. A structured approach addresses legal, security, and governance issues proactively. By building on InnerSource practices, organizations can leverage collaborative skills and adapt to external community challenges.
+
+This migration strikes a balance between organizational needs and open-source community expectations, resulting in sustainable projects that benefit both. The gradual approach enables learning and adaptation while minimizing risks to the project and the organization.
+
+## Known Instances
+
+- **Nike** - Nike has migrated multiple open source projects from InnerSource to Open Source.
+
+## Status
+
+- Initial
+
+## Author
+
+- Jeff Bailey
+
+## Related Patterns
+
+- [InnerSource before Open Source](../1-initial/innersource-before-open-source.md)
+
+## Alias
+
+- InnerSource to Open Source Transition
+- Open Sourcing InnerSource Projects
+- Public Release of InnerSource Projects