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}}
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..302eac5b5
--- /dev/null
+++ b/patterns/1-initial/innersource-before-open-source.md
@@ -0,0 +1,75 @@
+# 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 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. 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
+
+- Teams develop the skills necessary to manage open source projects effectively.  
+- Contributor documentation and governance structures are established and tested.  
+- 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
+
+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
+
+TBD
+
+## Status
+
+- Initial
+
+## Author(s)
+
+- Sebastian Spier
+- Fernando Correa
+
+## Alias
+
+- InnerSource as a Stepping Stone to Open Source
+- InnerSource before Open Source
+- InnerSource Incubation before Open Source