Innersourcing

Waiting in a ticket queue for another team to build what you need is a waste of everyone's time. Innersourcing lets the team with the need contribute the code directly.

Overview

Innersourcing lets stream-aligned teams contribute directly to platform codebases when they need a capability that doesn’t exist yet. The stream team submits the change; the platform team reviews and accepts it. It’s temporary collaboration, not a permanent dependency. The platform team still owns acceptance and long-term maintenance.

This solves dependency negotiation and orchestration tensions: stream-aligned teams blocked on platform teams for features. Rather than waiting in a ticket queue or pressuring the platform team to reprioritize, the stream team builds what they need, following the platform’s contribution guidelines. The platform team retains quality control and architectural coherence while unblocking delivery.

Getting Started with Innersourcing

1. Define the contribution boundary. Not every part of the codebase should accept external contributions. Identify which modules or services are innersource-eligible and document them explicitly. Areas with high architectural sensitivity or active redesign are usually off-limits.

2. Write a CONTRIBUTING.md guide. This lets people now how to contribute and what standards you have for accepting contributions. It should cover: how to set up a local dev environment, coding standards and conventions, how to structure a pull request, what tests are required, and who reviews contributions and when. If a contributor can’t go from zero to opening a PR by following the guide, it’s not done.

3. Assign trusted committers. These are people on the platform team responsible for reviewing and merging innersource contributions. They need enough context to evaluate changes quickly and enough availability to keep review turnaround fast. Slow reviews kill innersource adoption.

4. Establish a communication channel. Contributors need a place to ask questions before and during development. A shared Slack channel or discussion forum works. The goal is to catch misalignment early, before someone builds the wrong thing.

5. Start with a pilot. Pick one stream-aligned team with a real need and a platform repo with a clear contribution surface. Run the first contribution as a learning exercise. Expect the CONTRIBUTING guide to need revisions after the first few PRs.

6. Make it visible. Track innersource contributions so the organization can see the model working. This builds trust with leadership and encourages other teams to participate, both as contributors and as hosts.

Resources

• GitHub, “An introduction to innersource” (GitHub Resources)
• Four Team Types — innersourcing bridges stream-aligned and platform teams
• Three Team Interaction Modes — innersourcing is a form of temporary Collaboration mode