From 6407bbb6e5e394299bc474356667c661bd7ff020 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 23 Feb 2025 21:16:11 +0100 Subject: [PATCH 1/9] [Pattern Draft] Require InnerSource before Open Source --- .../innersource-before-open-source.md | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 patterns/1-initial/innersource-before-open-source.md diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md new file mode 100644 index 000000000..f90bc0325 --- /dev/null +++ b/patterns/1-initial/innersource-before-open-source.md @@ -0,0 +1,73 @@ +# Title + +Require InnerSource before Open Source + +## Patlet + +Organizations often struggle with maintaining and managing open source projects due to a lack of internal collaboration practices and infrastructure. By requiring projects to be InnerSource before becoming open source, teams can establish the necessary internal support, governance, and collaboration skills needed for successful community engagement. + +## Problem + +When a project is released as open source without first building a strong internal contributor base, it may face challenges such as insufficient documentation, unclear governance, and difficulty managing external contributions. Without prior experience in collaborative development, maintainers may struggle to handle the influx of external contributors, resulting in an unsuccessful or unsustainable open source project. + +## Story + +A large tech company once open-sourced a widely used internal tool, expecting external developers to contribute immediately. However, due to a lack of contributor guidelines, onboarding processes, and structured governance, external adoption was low, and internal maintainers were overwhelmed with unstructured contributions and support requests. + +After seeing this, the company implemented an InnerSource-first policy, ensuring internal teams could practice open collaboration before releasing future projects as open source. + +## Context + +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. + +## 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. + +## Solution + +Before making a project open source, require it to go through an InnerSource phase where: + +1. The project is made available internally for contributions from other teams. +2. Clear documentation, contribution guidelines, and governance structures are established. +3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. +4. Internal adoption and success metrics are measured to determine if the project is ready for external release. +5. Feedback loops are created to refine processes before engaging a broader open source audience. + +## Resulting Context + +- Teams develop the skills necessary to manage open source projects effectively. +- Contributor documentation and governance structures are established and tested. +- Internal adoption increases, providing validation of the project's value before external release. +- The transition to open source is smoother, with better preparedness for external collaboration. + +## Rationale + +By requiring InnerSource before Open Source, organizations ensure that projects are equipped with the right practices and infrastructure to thrive in an open community. This approach mitigates risks, improves sustainability, and maximizes the chances of long-term success. + +## Known Instances + +- Several large enterprises, including major tech companies, require internal projects to undergo an InnerSource phase before being open-sourced. +- Open source foundations often encourage organizations to refine their collaboration processes internally before publicly launching a project. + +## Status + +- Initial + +## Author(s) + +- Sebastian Spier + +## Alias + +- InnerSource as a Stepping Stone to Open Source +- InnerSource before Open Source From 78e740cbf108887a76fa8a132d3a15fa74e433aa Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 23 Feb 2025 21:23:24 +0100 Subject: [PATCH 2/9] Cleanup --- patterns/1-initial/innersource-before-open-source.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index f90bc0325..8b547e762 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -1,4 +1,4 @@ -# Title +# Title Require InnerSource before Open Source @@ -56,8 +56,7 @@ By requiring InnerSource before Open Source, organizations ensure that projects ## Known Instances -- Several large enterprises, including major tech companies, require internal projects to undergo an InnerSource phase before being open-sourced. -- Open source foundations often encourage organizations to refine their collaboration processes internally before publicly launching a project. +TBD ## Status @@ -71,3 +70,4 @@ By requiring InnerSource before Open Source, organizations ensure that projects - InnerSource as a Stepping Stone to Open Source - InnerSource before Open Source +- InnerSource Incubation before Open Source \ No newline at end of file From 56bd23b0b783ab7310d7463dc7a25601ffca3573 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 23 Feb 2025 21:24:28 +0100 Subject: [PATCH 3/9] Fix linter issues --- patterns/1-initial/innersource-before-open-source.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index 8b547e762..7c8b010fa 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -56,7 +56,7 @@ By requiring InnerSource before Open Source, organizations ensure that projects ## Known Instances -TBD +TBD ## Status @@ -70,4 +70,4 @@ TBD - InnerSource as a Stepping Stone to Open Source - InnerSource before Open Source -- InnerSource Incubation before Open Source \ No newline at end of file +- InnerSource Incubation before Open Source From a070b940faadfc186fe705e8805c1a59a6686373 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 23 Feb 2025 21:27:02 +0100 Subject: [PATCH 4/9] If a new pattern in a PR does not contain any links, the GHA to check links should not fail --- .github/workflows/link-checker-prs.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/link-checker-prs.yml b/.github/workflows/link-checker-prs.yml index 985aa8ca1..3186937f9 100644 --- a/.github/workflows/link-checker-prs.yml +++ b/.github/workflows/link-checker-prs.yml @@ -41,6 +41,7 @@ jobs: with: args: --verbose --no-progress --cache --max-cache-age 1d $MARKDOWN_FILES fail: true + failIfEmpty: false jobSummary: true env: GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} From ff5699b89228f5217d21aba45262663fdb7b8426 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 27 Feb 2025 23:52:37 +0100 Subject: [PATCH 5/9] Adding some links to other patterns. Minor fix to Resulting Context. --- patterns/1-initial/innersource-before-open-source.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index 7c8b010fa..5bca3a974 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -37,8 +37,8 @@ This pattern applies in organizations that: Before making a project open source, require it to go through an InnerSource phase where: -1. The project is made available internally for contributions from other teams. -2. Clear documentation, contribution guidelines, and governance structures are established. +1. The project is made available internally for contributions from other teams e.g. via an [InnerSource Portal](../2-structured/innersource-portal.md). +2. Clear documentation, contribution guidelines, and governance structures are established. See also [Standard Base Documentation](../2-structured/base-documentation.md). 3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. 4. Internal adoption and success metrics are measured to determine if the project is ready for external release. 5. Feedback loops are created to refine processes before engaging a broader open source audience. @@ -47,7 +47,7 @@ Before making a project open source, require it to go through an InnerSource pha - Teams develop the skills necessary to manage open source projects effectively. - Contributor documentation and governance structures are established and tested. -- Internal adoption increases, providing validation of the project's value before external release. +- Further internal teams start using the project (adoption), providing validation of the project's value before external release. - The transition to open source is smoother, with better preparedness for external collaboration. ## Rationale From 7a03c91ffb6f402700cea24fdee62e78f0810ad3 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Mar 2025 09:41:14 +0100 Subject: [PATCH 6/9] Adding link to governance levels --- patterns/1-initial/innersource-before-open-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index 5bca3a974..ecba5c95a 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -38,7 +38,7 @@ This pattern applies in organizations that: Before making a project open source, require it to go through an InnerSource phase where: 1. The project is made available internally for contributions from other teams e.g. via an [InnerSource Portal](../2-structured/innersource-portal.md). -2. Clear documentation, contribution guidelines, and governance structures are established. See also [Standard Base Documentation](../2-structured/base-documentation.md). +2. Clear [documentation](../2-structured/base-documentation.md) (including contribution guidelines), and [governance structures](../2-structured/governance-levels.md) are established. 3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. 4. Internal adoption and success metrics are measured to determine if the project is ready for external release. 5. Feedback loops are created to refine processes before engaging a broader open source audience. From b92c0ffdb2d758aa47688ec65ef637e0e039c485 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Mar 2025 09:41:36 +0100 Subject: [PATCH 7/9] Adding Fernado as a co-author --- patterns/1-initial/innersource-before-open-source.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index ecba5c95a..8fe8965e6 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -65,6 +65,7 @@ TBD ## Author(s) - Sebastian Spier +- Fernando Correa ## Alias From 6b912912090b29358e78ba3396652ea6b2b8fc7a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Fri, 4 Apr 2025 09:24:28 +0200 Subject: [PATCH 8/9] Add link to repository-activity-score.md --- patterns/1-initial/innersource-before-open-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index 8fe8965e6..d7785cb4c 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -40,7 +40,7 @@ Before making a project open source, require it to go through an InnerSource pha 1. The project is made available internally for contributions from other teams e.g. via an [InnerSource Portal](../2-structured/innersource-portal.md). 2. Clear [documentation](../2-structured/base-documentation.md) (including contribution guidelines), and [governance structures](../2-structured/governance-levels.md) are established. 3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. -4. Internal adoption and success metrics are measured to determine if the project is ready for external release. +4. 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). 5. Feedback loops are created to refine processes before engaging a broader open source audience. ## Resulting Context From 1431086993213d996e3a24af2bf842c6f330f420 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Tue, 8 Apr 2025 22:26:50 +0200 Subject: [PATCH 9/9] Adding another skill acquired during the solution --- patterns/1-initial/innersource-before-open-source.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/innersource-before-open-source.md b/patterns/1-initial/innersource-before-open-source.md index d7785cb4c..302eac5b5 100644 --- a/patterns/1-initial/innersource-before-open-source.md +++ b/patterns/1-initial/innersource-before-open-source.md @@ -39,9 +39,10 @@ Before making a project open source, require it to go through an InnerSource pha 1. The project is made available internally for contributions from other teams e.g. via an [InnerSource Portal](../2-structured/innersource-portal.md). 2. Clear [documentation](../2-structured/base-documentation.md) (including contribution guidelines), and [governance structures](../2-structured/governance-levels.md) are established. -3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. -4. 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). -5. Feedback loops are created to refine processes before engaging a broader open source audience. +3. Maintainers gain experience managing contributions, reviewing pull requests, and addressing issues. +4. Maintainers get to git 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. ## Resulting Context