Inner Source & Reuse¶

Status: 🟢 Active  |  Owner: Engineering Enablement  |  Last Reviewed: 2025-Q4

Introduction¶

At a certain scale, every engineering organisation faces the same challenge: valuable capabilities are being built over and over again by different teams who are each unaware of what others have already solved. Authentication flows, audit logging, event publishing, rate limiting, PDF generation, email templating — the list of capabilities that are genuinely cross-cutting and independently valuable is long, and the waste from rebuilding them in isolation is real.

Inner source is the practice of applying open source collaboration principles — open contribution, documented interfaces, explicit ownership, community review — to internal software development. It is the model by which this organisation builds and maintains shared libraries, platform capabilities, and golden path templates that any team can use and any team can improve.

This section governs how shared engineering assets are created, discovered, contributed to, owned, and evolved. It applies to every engineer in the organisation, because at this scale every engineer is both a consumer and a potential contributor to shared assets.

Core Principles¶

Every Shared Asset Has an Explicit Owner¶

Shared assets — libraries, services, APIs, golden paths, infrastructure modules — belong to teams, not to individuals, and not to the organisation as an abstraction. A team name is a durable identifier: individuals leave and roles change, but the team remains accountable. The developer portal makes this ownership legible and searchable at all times.

An asset without an active, named team owner is at risk of security drift, undiscovered bugs, breaking changes without communication, and eventual orphanage. Ownerless assets are treated as compliance violations.

Contribution Is the Mechanism, Not Requests¶

The inner source model exists to give consumer teams a third path between "build it yourself" and "raise a ticket and wait." When a shared library is missing a capability you need, the expected response is to contribute it — not to request it. The Custodian Team's job is to review and guide contributions, not to build on demand.

This requires that contribution is genuinely low-friction: clear CONTRIBUTING.md files, responsive review SLAs, and a culture in which submitting a PR to another team's repository is normal and welcomed.

Capability Ownership Must Be Transferable¶

The team that creates a shared asset is not necessarily the team that should own it forever. As organisations evolve, the team closest to a capability's primary users may change. Ownership transfer is a first-class process — with mandatory knowledge transfer, shadowing periods, and catalogue updates — so that continuity of ownership is maintained without requiring the original team to own something indefinitely.

Knowledge Lives in the Asset, Not in People¶

When a team contributes to a shared library or accepts a capability transfer, the institutional knowledge about why things work the way they do must be encoded in the repository — in ADRs, in DECISIONS.md, in architecture docs, in inline comments — not held in the heads of a handful of engineers. A shared asset whose operational knowledge is concentrated in two people is fragile. A shared asset that documents its own reasoning is robust.

Separation of Duties in Inner Source¶

Inner source involves multiple roles with distinct responsibilities. Clarity about who owns what prevents both bottlenecks (Custodian Team gatekeeping everything) and chaos (everyone merging whatever they want).

Contribution vs. Custodianship — The Key Distinction¶

A contributing team's responsibility ends when their contribution is merged. The Custodian Team owns the merged code from that point forward — including bugs, regressions introduced by later changes, and security patches. This clean handover is what makes contribution sustainable: engineers can contribute freely without accepting an open-ended maintenance commitment.

The corollary is that the Custodian Team cannot refuse to own what it merges. If a contribution is of insufficient quality to be owned confidently, it should not be merged — not merged with the expectation that the contributor will maintain it.

The Inner Source Workflow at a Glance¶

DISCOVER ──────────────────────────────────────────────────────────────────►
  Search the Component Registry and Developer Portal before building anything.
  If a shared asset covers your need: use it.
  If it partially covers your need: contribute.
  If nothing covers your need: propose a new shared asset via #innersource.

CONTRIBUTE ─────────────────────────────────────────────────────────────────►
  Open a discussion issue in the target repository.
  Wait for Custodian Team acknowledgement (≤2 business days).
  Implement with tests, docs, and a changelog entry.
  Open a PR — Custodian reviews within 5 business days.
  Contribution merged → Custodian Team owns it from here.

OWN ────────────────────────────────────────────────────────────────────────►
  Custodian Team maintains review SLA, releases, and security response.
  Engineering Enablement monitors custodian health quarterly.
  If ownership needs to transfer: follow the transfer process (minimum 2 weeks).
  Knowledge lives in the repo, not in people.

What You Will Find Here¶

Key Standards at a Glance¶

Last reviewed: 2025-Q4  |  Owner: Engineering Enablement