feat: add Migrating from InnerSource to Open Source

.github/workflows/all-patterns-listed.yml

@@ -0,0 +1,46 @@
+# Check if all patterns are listed in README.md
+name: All Patterns Listed
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  all-patterns-listed:
+    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) - *When an InnerSource project succeeds internally and meets criteria for external release, organizations often lack a structured approach for the transition. Establish a process that addresses legal, security, governance, and community readiness to transition the project to open source while maintaining its internal value.*
 
 <!--
 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,141 @@
+## Title
+
+Migrating from InnerSource to Open Source
+
+## Patlet
+
+When an InnerSource project succeeds internally and meets criteria for external release, organizations often lack a structured approach for the transition. 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 for this evolution. While InnerSource provides a foundation of collaborative development practices, internal governance, and community management skills, the transition to external open source introduces new challenges. Without proper planning, projects risk legal issues, security vulnerabilities, governance conflicts, and community challenges that could harm both the project's success and the organization's reputation in the broader open source ecosystem.
+
+## 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, demonstrating proven collaborative development practices.
+- The organization has established InnerSource practices and governance, providing a foundation for external community management.
+- There is strategic value in releasing the project publicly while maintaining its internal utility.
+- Legal and compliance frameworks are in place for open source releases.
+- The project team has experience with InnerSource collaborative development practices and internal community management.
+- External market demand or strategic positioning justifies open sourcing, leveraging the project's InnerSource success.
+
+## 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
+   - Assess business value and strategic alignment for external release.
+   - Ensure InnerSource templates align with open source standards to reduce transition friction.
+
+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.
+   - Maintain contributor history and credits during the transition to avoid losing valuable contribution records.
+
+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.
+   - Add contributor acknowledgment sections to READMEs to appropriately credit all contributors during the transition.
+
+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
+   - Implement systems to measure and demonstrate business value produced by open source developers.
+   - Identify and automate repetitive processes in project setup and maintenance.
+
+## Resulting Context
+
+After successful migration:
+
+- The project gains external contributors and broader adoption, building on its InnerSource foundation.
+- Internal teams leverage their InnerSource community management experience to manage external contributors effectively.
+- The organization builds a reputation within the open source ecosystem, demonstrating a successful evolution from InnerSource to open source.
+- Legal and compliance frameworks are established for future open source releases.
+- The project may require ongoing resource allocation for community management, but it benefits from established InnerSource practices.
+- Internal development processes adapt to external community needs while maintaining InnerSource principles.
+- New opportunities for collaboration and innovation emerge through external partnerships, extending the collaborative culture developed through InnerSource.
+- Open sourcing projects often leads to increased internal usage and adoption, contrary to initial expectations.
+- Aligning InnerSource and open source templates reduces friction for future transitions.
+
+## Rationale
+
+Migrating from InnerSource to open source is a natural evolution for successful internal projects, but requires careful planning to avoid pitfalls. A structured approach addresses legal, security, and governance issues proactively. By building on established InnerSource practices, organizations can leverage their collaborative development skills, community management experience, and internal governance structures to adapt to external community challenges.
+
+This migration leverages the foundation of InnerSource success—proven collaboration patterns, established contribution workflows, and internal community management—to create sustainable open source projects. The gradual approach enables organizations to apply their InnerSource learnings while minimizing risks to both the project and the organization's reputation in the broader open source ecosystem.
+
+## References
+
+- [Open Source Guides: How to Contribute to Open Source (by GitHub)](https://opensource.guide/how-to-contribute/)
+- [Google's Open Source Documentation](https://opensource.google/documentation/reference)
+- [The Open Source Way](https://www.theopensourceway.org/)
+- [Apache Software Foundation: How to Open Source](https://www.apache.org/dev/apply-license.html)
+- [Microsoft Open Source Program: Releasing Projects](https://opensource.microsoft.com/program/#program-releasing)
+
+## 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