Scrolls
6 min read
On this page

Inner Source Patterns

Inner source works when it is structured. Without clear patterns, cross-team contributions devolve into confusion: who reviews the PR? What standards apply? How long should the owning team take to respond? The InnerSource Commons foundation has documented dozens of patterns from real organizations. The most important ones address three problems: who decides, how to contribute, and how to discover code.

The Trusted Committer

The trusted committer is the most important role in inner source. This is the person on the owning team who is responsible for reviewing and merging contributions from other teams. They are the bridge between the contributor and the codebase.

Responsibilities

Trusted committer responsibilities:
- Review cross-team pull requests
- Ensure contributions meet code standards
- Mentor contributors on codebase conventions
- Protect code quality without discouraging contribution
- Respond to contributions within an agreed timeframe
- Maintain the contributing guide

The trusted committer is not a gatekeeper. Their job is to help contributors succeed, not to find reasons to reject contributions. This mindset shift is critical. In traditional code review, the reviewer protects quality. In inner source, the trusted committer protects quality while also enabling contribution.

What Makes a Good Trusted Committer

Technical skills:
- Deep knowledge of the codebase
- Understanding of architectural decisions and their rationale
- Ability to spot issues that automated tools miss

Social skills:
- Patience with contributors unfamiliar with the codebase
- Clear, constructive feedback
- Willingness to explain "why" not just "what"
- Ability to say no without discouraging future contributions

The trusted committer role should be explicit and recognized. It takes time away from feature work, and the person filling it should receive credit in performance reviews. If the role is invisible, nobody will want to do it.

Rotating the Role

Some teams rotate the trusted committer role on a schedule (weekly or monthly). This prevents burnout and spreads knowledge about the contribution process across the team. It also ensures that the inner source program does not depend on a single person.

The Contribution Guide

Every inner source project needs a CONTRIBUTING.md file, just like an open source project. This document tells contributors from other teams everything they need to know to make a successful contribution.

What to Include

Contributing guide structure:
1. Getting started
   - How to set up the development environment
   - How to run tests
   - How to build the project

2. Contribution process
   - How to find issues to work on
   - How to create a branch
   - PR naming conventions
   - What to include in a PR description
   - Expected review timeline

3. Code standards
   - Style guide (or link to linter config)
   - Testing requirements (coverage, test types)
   - Documentation requirements
   - Commit message format

4. Architecture overview
   - High-level structure of the codebase
   - Key design decisions and their rationale
   - Areas that are stable vs. areas under active change

5. Contact
   - Who is the trusted committer
   - Where to ask questions (Slack channel, mailing list)
   - How to escalate if a PR is not reviewed

The Key Difference from Open Source

Internal contributing guides can assume more context than external ones. Contributors are employees who have access to the internal wiki, the company Slack, and the same development environment. The guide does not need to explain how to install Git. It does need to explain the team's specific conventions and the architectural context that a new contributor would not know.

Example

# Contributing to auth-service

## Quick Start
1. Clone the repo: git clone git@github.internal:platform/auth-service.git
2. Install dependencies: make setup
3. Run tests: make test
4. Run locally: make run

## Making a Contribution
- Check the "good first issue" label for starter tasks
- Create a branch from main: feature/your-change
- Write tests for your change
- Run the linter: make lint
- Submit a PR with a description of what and why
- Tag @platform-tc for review

## Review SLA
We aim to provide initial review within 2 business days.
If you have not heard back in 3 days, ping us in #platform-eng.

## Code Standards
- Go 1.22+, follow project .golangci.yml
- All public functions need doc comments
- Table-driven tests preferred
- No new dependencies without discussing first

## Trusted Committer (Q1 2026)
Sarah Chen (@schen) - primary
Marcus Webb (@mwebb) - backup

Discoverable Code

Inner source fails if people cannot find the code that already exists. Discoverability is the precondition for contribution.

Internal Code Catalogs

A code catalog is an internal registry of all inner source projects. It lists each project with a description, the owning team, the trusted committer, and the maturity level.

Code catalog entry:
  Project:     auth-service
  Team:        Platform Engineering
  Language:    Go
  Status:      Active, accepting contributions
  TC:          Sarah Chen
  Description: Central authentication and authorization service
  Tags:        auth, OAuth, SAML, SSO
  Docs:        wiki.internal/auth-service
  Repo:        github.internal/platform/auth-service

Some companies build custom catalog tools. Others use existing tools like Backstage (Spotify's open source developer portal) or Sourcegraph for code search.

Code search is the simplest form of discoverability. Tools like Sourcegraph, GitHub code search, or OpenGrok let developers search across all internal repositories. When a developer wonders "does anyone already have a rate limiter?", they can search and find the answer in seconds.

Documentation

Discoverable code is documented code. If a project has no README, no contributing guide, and no architecture docs, it is effectively invisible even if it shows up in search results. Nobody will contribute to code they cannot understand.

InnerSource Commons Patterns

The InnerSource Commons foundation has documented patterns that solve recurring problems in inner source adoption. Three of the most important are the 30-day warranty, standard base documentation, and the review committee.

The 30-Day Warranty

The 30-day warranty pattern addresses a common fear: "If I accept a contribution from another team, I am stuck maintaining their code forever."

The 30-day warranty:
- Contributor makes a change and it is merged
- For 30 days after merge, the contributor is responsible for:
  - Fixing bugs in their change
  - Responding to questions about their change
  - Making adjustments requested by the owning team
- After 30 days, maintenance transfers to the owning team

This pattern reduces risk for the owning team. They know that if the contribution causes problems, the contributor will fix them. It also ensures that contributors think carefully about their changes, knowing they will be on the hook for quality.

Standard Base Documentation

The standard base documentation pattern ensures every inner source project has a minimum set of documents. This is the inner source equivalent of the open source convention that every project needs a README, LICENSE, and CONTRIBUTING file.

Standard base documentation:
- README.md: What the project does, how to use it
- CONTRIBUTING.md: How to contribute
- ARCHITECTURE.md: High-level design and key decisions
- OWNERS.md or CODEOWNERS: Who maintains what
- CHANGELOG.md: What changed and when

The key insight is that standardizing these documents across the organization makes it easier for contributors to move between projects. Once you have read one CONTRIBUTING.md, you know how to read them all.

Review Committee

The review committee pattern addresses governance. When inner source spans many teams and projects, someone needs to coordinate: which projects participate, what the standards are, how disputes are resolved.

Review committee responsibilities:
- Set organization-wide inner source standards
- Resolve disputes between contributors and owning teams
- Track inner source metrics (contributions, adoption, satisfaction)
- Recognize and reward inner source participation
- Recommend projects for inner source adoption
- Provide training for trusted committers

The review committee is not an approval body. It does not approve individual contributions. It sets the rules of the game and ensures the program stays healthy.

Starting Small

The most common mistake in inner source adoption is starting too big. Companies that announce "all code is now inner source" and expect immediate transformation are disappointed. The pattern that works is starting small.

One Team, One Project

Pick one team that is enthusiastic about inner source. Pick one project that other teams frequently need changes in. Set up the contributing guide, designate a trusted committer, and invite one other team to make a contribution.

Starting small checklist:
1. Identify a willing team with a high-demand project
2. Write a CONTRIBUTING.md
3. Designate a trusted committer
4. Set a review SLA (e.g., 2 business days)
5. Identify one other team that needs a change
6. Guide them through the first contribution
7. Celebrate the first merged cross-team PR
8. Document what worked and what did not
9. Invite a second project
10. Repeat

Measuring Progress

Inner source metrics:
- Number of cross-team PRs submitted
- Number of cross-team PRs merged
- Time to first review
- Time to merge
- Number of projects with CONTRIBUTING.md
- Number of active trusted committers
- Contributor satisfaction (survey)

Track these over time. The numbers should trend up gradually. If cross-team PRs are submitted but not reviewed, the trusted committer process needs work. If PRs are reviewed but not merged, the contribution standards may be unclear.

Common Pitfalls

  • No trusted committer. Without a designated person to review cross-team PRs, contributions sit unreviewed and contributors give up.
  • No contributing guide. Contributors from other teams waste time guessing at conventions, leading to rejected PRs and frustration.
  • Review SLA too slow. If cross-team PRs take weeks to review while internal PRs are reviewed in hours, contributors learn that inner source is not worth the effort.
  • No discoverability. If developers cannot find existing inner source projects, they will build their own instead of contributing.
  • Treating the first contribution as the norm. The first cross-team contribution is always hard. It gets easier with practice. Do not judge the program by the friction of the first attempt.
  • Forgetting the warranty. If the owning team feels stuck maintaining code they did not write, they will stop accepting contributions. The 30-day warranty pattern prevents this.

Key Takeaways

  • The trusted committer is the most critical role in inner source, serving as the bridge between external contributors and the codebase.
  • Every inner source project needs a CONTRIBUTING.md that explains setup, standards, process, and contacts, just like an open source project.
  • Discoverability through code catalogs, internal search, and documentation is the precondition for inner source adoption.
  • InnerSource Commons patterns like the 30-day warranty, standard base documentation, and review committee solve recurring organizational problems.
  • Starting with one team and one project, then expanding gradually based on results, is more effective than a top-down mandate.
  • Measuring cross-team PR volume, review time, and merge rate provides concrete evidence of inner source health.