Inner Source

Inner source applies open-source development practices within an organization. InnerSource Commons describes collaboration across team boundaries around shared software. The originating community writes the name as one word, InnerSource. Internal visibility is part of the arrangement, together with a usable contribution and decision process; the software need not become public.

InnerSource Commons maintains learning materials and patterns for this work. Its About page describes a foundation incorporated in 2020, following the community’s founding in 2015. Membership changes over time; community size does not establish whether the practice fits a particular project.

The situation it exists for

The Commons’ introduction uses a familiar situation: team A consumes team B’s software and needs a feature that B cannot implement on A’s schedule. The teams have to decide how to meet the need while preserving the shared project’s responsibilities.

Waiting, negotiating priorities, using an alternative, or maintaining a separate implementation may each be reasonable. They have different costs. Bottcher reports one telecommunications study in which tasks waiting for another team took 10–12 times as long in elapsed time. That context-specific comparison is not a universal multiplier or an estimate of what contribution alone would save.

Inner source adds the option for team A to implement a change and propose it to the shared project. If it is accepted, the teams can avoid maintaining a separate copy. Continued maintenance, release, and support responsibility still need agreement; submitting code does not automatically transfer those obligations.

This addresses backlog coupling on the implementation side. The guest needs people, familiarity, and time to build; the host needs capacity for design decisions, review, security checks, release, and subsequent support. Both constraints may remain. A contribution route is useful when it offers a workable delivery option, even if it does not remove every dependency.

Why platforms end up here

The CNCF maturity model’s participatory adoption level includes users improving and extending capabilities. A platform can make this possible through interfaces and contribution rules that specialists outside the central team can use.

The model illustrates a team contributing an alternative backup approach whose reuse is initially limited. It can be offered as alpha and later qualify for core support. This is a possible path for a specialized need, not a guarantee of acceptance or promotion.

Agree what those stages mean: quality and compatibility checks, the responsible provider, support scope, and lifecycle terms. A contribution still needs review and release capacity, and an alpha offering must not silently inherit a production support promise.

DORA recommends extensibility and a defined contribution model so other teams can supply relevant expertise. That distributes implementation where the organization has capacity while preserving shared decisions about integration and operation.

Publishing the repository is the easy part

A readable repository gives potential contributors access to code, but it does not tell them how to make an acceptable change. Explain the project’s purpose, access rules, owners, and contribution process.

Make the route from discovery to acceptance usable for someone outside the owning team.

1. Discovery. Help contributors find the project and owner through a service catalog, repository directory, or another maintained entry point.
2. Build and test guidance. Document setup, supported versions, tests, and common failures. Some onboarding help can be a worthwhile investment; evaluate its cost across the expected contributions rather than treating any question as lost savings.
3. Contribution rules. State what changes are welcome, what is out of scope, how to discuss a proposal, and who decides whether it meets compatibility, security, and operating requirements.
4. Recorded coordination. Use issues, design records, and pull requests so work can proceed across schedules. InnerSource Commons also describes pairing and synchronous collaboration where useful. Record the resulting decisions so people who were absent can follow them.
5. Host capacity. Assign review and release responsibility, indicate expected response times, and make capacity limits visible before a guest commits substantial effort.

Contribution shifts some implementation work to the guest and creates coordination and review work for the host. Measure both teams’ effort and elapsed time. Review cost depends on scope, familiarity, tests, and risk; it is not inherently lower than implementation cost. Do not shorten review merely to make a queue appear healthy.

Discuss the approach before substantial implementation, explain that an invitation is not a promise to merge, and agree long-term responsibility before acceptance. Name who handles defects, dependencies, security fixes, releases, and retirement. These duties can be shared or assigned to the guest under the project’s contract.

The Commons’ principles emphasize open communication and documented decisions, while its learning materials allow practices to vary by context. Choose a process that contributors and maintainers can actually sustain, and revise it using their experience.

Deciding whether a contribution fits

Evaluate the proposed change against the shared project’s direction, compatibility, cost, and available authority. The number of interested teams is useful demand evidence, not a definition of inner source.

• A narrow requirement. One team may contribute a suitable enhancement or extension to a shared project. If the work is separate software with no plausible shared benefit, maintaining it in that team may be simpler. Discuss the expected reuse and maintenance cost rather than applying a one-team exclusion rule.
• An operational dependency. A one-off request to run a task differs from a contribution that automates recurring fulfillment. Self-service provisioning and pull requests can coexist: a PR may change the automation, configuration, documentation, or approved desired state through which the service operates. Define approval and execution expectations for that route.
• No review capacity. Agree a later schedule, provide capacity, reduce scope, or choose another delivery route before inviting work the host cannot evaluate.
• An incompatible change. Consider configuration, an extension point, a separate implementation, or rejection. Preserve the shared contract and give each accepted option an operating owner; a separate fork is one possible outcome, not an automatic requirement.

Contribution expands who can improve a platform. Operating responsibility changes only through an explicit agreement, including support and retirement conditions; core promotion is not a promise of indefinite operation. Platform Adoption: Onboarding, Support, and Feedback connects this delivery option to adoption and support. Developer advocacy and a community of practice can help participants find projects and learn the contribution process.

References

• InnerSource Commons — Introduction to InnerSource
• InnerSource Commons — InnerSource Principles
• InnerSource Commons — InnerSource and Agile
• InnerSource Commons — About
• CNCF — Platform Engineering Maturity Model
• DORA — Platform engineering
• Evan Bottcher — What I Talk About When I Talk About Platforms (2018)