From dba2f4e9ffe94e1d9552e1a02868537e6732c434 Mon Sep 17 00:00:00 2001 From: Jeff Bailey <776901+jeffabailey@users.noreply.github.com> Date: Fri, 26 Sep 2025 07:54:59 -0700 Subject: [PATCH 01/20] feat: add Migrating from InnerSource to Open Source chore: add inputs from ISPO WG to Require InnerSource before Open Source --- .../innersource-before-open-source.md | 18 ++- ...grating-from-innersource-to-open-source.md | 125 ++++++++++++++++++ 2 files changed, 140 insertions(+), 3 deletions(-) create mode 100644 patterns/1-initial/migrating-from-innersource-to-open-source.md diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index 2066cce65..80c9f12c0 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -23,7 +23,10 @@ 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 @@ -31,7 +34,11 @@ This pattern applies in organizations that: - **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 diff --git a/patterns/1-initial/migrating-from-innersource-to-open-source.md b/patterns/1-initial/migrating-from-innersource-to-open-source.md new file mode 100644 index 000000000..36a85a445 --- /dev/null +++ b/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 From 14406cffd35d36abf1389f98260299a88f39a21b Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 09:22:08 +0200 Subject: [PATCH 02/20] Test a new action that checks if all patterns are listed in the main README --- .github/workflows/overview-complete.yml | 28 +++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 .github/workflows/overview-complete.yml diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml new file mode 100644 index 000000000..1d7c6e4aa --- /dev/null +++ b/.github/workflows/overview-complete.yml @@ -0,0 +1,28 @@ +# Are all patterns shown somewhere in the main overview (README)? +name: Overview Complete + +on: + push: + branches: + - main + pull_request: + branches: + - main + +jobs: + linkChecker: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v5 + with: + fetch-depth: 0 + + - name: Get changed files + id: changed-files + uses: tj-actions/changed-files@v47 + + - name: Filter markdown files only + run: | + md_files=`find ${{ steps.changed-files.outputs.all_changed_files }} -maxdepth 0 -name "*.md" | tr '\n' ' '` + echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV + From fd4dbe41f41ca2d489c027b16e50021f979df071 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 09:23:50 +0200 Subject: [PATCH 03/20] Test --- .github/workflows/overview-complete.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index 1d7c6e4aa..b8d42f730 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -10,7 +10,7 @@ on: - main jobs: - linkChecker: + overviewComplete: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 @@ -25,4 +25,5 @@ jobs: run: | md_files=`find ${{ steps.changed-files.outputs.all_changed_files }} -maxdepth 0 -name "*.md" | tr '\n' ' '` echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV + echo "$md_files" From 34becb5866f3764860de9f06a8bad400a9ef6d84 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 09:24:29 +0200 Subject: [PATCH 04/20] Linter fix --- patterns/1-initial/migrating-from-innersource-to-open-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/migrating-from-innersource-to-open-source.md b/patterns/1-initial/migrating-from-innersource-to-open-source.md index 36a85a445..20d748b72 100644 --- a/patterns/1-initial/migrating-from-innersource-to-open-source.md +++ b/patterns/1-initial/migrating-from-innersource-to-open-source.md @@ -42,7 +42,7 @@ 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**: +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. From bf7f1751146b72cade4a92eb3756ba4855c42cc3 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 11:40:29 +0200 Subject: [PATCH 05/20] Running check on all pattern files, rathern than on just the new ones --- .github/workflows/overview-complete.yml | 29 +++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index b8d42f730..c3a2245ed 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -27,3 +27,32 @@ jobs: echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV echo "$md_files" + - name: Check if all files exist in README + - 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 + echo $file + if grep -qF "$file" "$README"; then + echo "✔ Found: $file" + else + echo "✘ Missing: $file" + missing=$((missing + 1)) + fi + done + + if [[ $missing -gt 0 ]]; then + echo "Some files are missing from $README." + exit 1 + else + echo "All files are mentioned in $README." + exit 0 + fi From 9571676ac659838255c99a208737efbe179f4295 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:13:00 +0200 Subject: [PATCH 06/20] Get rid of workflow steps that are not needed --- .github/workflows/overview-complete.yml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index c3a2245ed..f5f53d089 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -14,18 +14,18 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - with: - fetch-depth: 0 + # with: + # fetch-depth: 0 - - name: Get changed files - id: changed-files - uses: tj-actions/changed-files@v47 + # - name: Get changed files + # id: changed-files + # uses: tj-actions/changed-files@v47 - - name: Filter markdown files only - run: | - md_files=`find ${{ steps.changed-files.outputs.all_changed_files }} -maxdepth 0 -name "*.md" | tr '\n' ' '` - echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV - echo "$md_files" + # - name: Filter markdown files only + # run: | + # md_files=`find ${{ steps.changed-files.outputs.all_changed_files }} -maxdepth 0 -name "*.md" | tr '\n' ' '` + # echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV + # echo "$md_files" - name: Check if all files exist in README - run: | @@ -33,8 +33,8 @@ jobs: # Ensure README.md exists if [[ ! -f "$README" ]]; then - echo "Error: $README not found!" - exit 1 + echo "Error: $README not found!" + exit 1 fi missing=0 From b9f45d9791606805000c084449380297a4fa49f7 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:16:06 +0200 Subject: [PATCH 07/20] Fix wrong GHA syntax --- .github/workflows/overview-complete.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index f5f53d089..e76b2c5d7 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -28,7 +28,7 @@ jobs: # echo "$md_files" - name: Check if all files exist in README - - run: | + run: | README="README.md" # Ensure README.md exists From 26f28312d719e55941733557efe3c34e7ee21303 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:36:40 +0200 Subject: [PATCH 08/20] Writing annotation to be picked up by GHA --- .github/workflows/overview-complete.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index e76b2c5d7..0a93b3d73 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -27,7 +27,7 @@ jobs: # echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV # echo "$md_files" - - name: Check if all files exist in README + - name: Check if all patterns are listed in README.md run: | README="README.md" @@ -40,11 +40,10 @@ jobs: missing=0 for file in patterns/*/*.md; do - echo $file if grep -qF "$file" "$README"; then echo "✔ Found: $file" else - echo "✘ Missing: $file" + echo "::error ✘ Missing: $file" missing=$((missing + 1)) fi done From 351415374416fd2d0c832d3a22cfa69a9da8fb97 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:38:47 +0200 Subject: [PATCH 09/20] Adding errors to step summary --- .github/workflows/overview-complete.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index 0a93b3d73..b93b4a2bb 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -43,7 +43,8 @@ jobs: if grep -qF "$file" "$README"; then echo "✔ Found: $file" else - echo "::error ✘ Missing: $file" + echo "✘ Missing: $file" + echo "✘ Missing: $file" >> $GITHUB_STEP_SUMMARY missing=$((missing + 1)) fi done From 22a3e127854d8e29b60328fec86ed566fbc65489 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:43:50 +0200 Subject: [PATCH 10/20] Cleanup --- .github/workflows/overview-complete.yml | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/.github/workflows/overview-complete.yml b/.github/workflows/overview-complete.yml index b93b4a2bb..b0f38a619 100644 --- a/.github/workflows/overview-complete.yml +++ b/.github/workflows/overview-complete.yml @@ -1,4 +1,4 @@ -# Are all patterns shown somewhere in the main overview (README)? +# Check if all patterns are listed in README.md name: Overview Complete on: @@ -14,18 +14,6 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - # with: - # fetch-depth: 0 - - # - name: Get changed files - # id: changed-files - # uses: tj-actions/changed-files@v47 - - # - name: Filter markdown files only - # run: | - # md_files=`find ${{ steps.changed-files.outputs.all_changed_files }} -maxdepth 0 -name "*.md" | tr '\n' ' '` - # echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV - # echo "$md_files" - name: Check if all patterns are listed in README.md run: | @@ -44,15 +32,15 @@ jobs: echo "✔ Found: $file" else echo "✘ Missing: $file" - echo "✘ Missing: $file" >> $GITHUB_STEP_SUMMARY + echo "✘ Pattern file not listed in README.md: $file" >> $GITHUB_STEP_SUMMARY missing=$((missing + 1)) fi done if [[ $missing -gt 0 ]]; then - echo "Some files are missing from $README." + echo "Some patterns are missing from $README." exit 1 else - echo "All files are mentioned in $README." + echo "All patterns are listed in $README." exit 0 fi From 9db4fddf887494467efcdf97bb7fa817b80e11cf Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 28 Sep 2025 12:45:39 +0200 Subject: [PATCH 11/20] List new pattern in README --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 8639923c4..820caf119 100644 --- a/README.md +++ b/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*