Faux InnerSource

An internally open repository can still preserve every old boundary.

InnerSource often begins when a Host Team cannot deliver a feature in time and a Guest Team can. That is a legitimate starting point. Faux InnerSource mistakes that beginning for the operating model. It borrows hands while keeping context, decisions and practical stewardship closed. Every contribution starts again from zero.

The useful distinction is not between an organisation with controls and one without them. Host Teams remain accountable. Product responsibility exists on both sides. For a product change, the Guest and Host product counterparts need a handshake on the intended outcome, priority, existing capability and destination direction. Architecture, security and release decisions may need specialist judgement. Regulated software does not become less regulated because the contributor sits elsewhere.

The test is what the contribution leaves behind.

If a Guest Team supplies implementation and the project returns unchanged to the same small group of decision-makers, the organisation has borrowed capacity. If the contribution process leaves the project easier to discover, build, test, understand and deliver, with knowledge the next Contributor can reuse and wider stewardship where it helps, the organisation has built capability.

Done well, InnerSource lets comparable future contributions reuse more context and evidence. Faux InnerSource preserves the bottleneck and gives it a contribution process.

What faux InnerSource looks like

Faux InnerSource turns a legitimate starting condition into a permanent boundary. Host incapacity becomes the only permitted entry condition. The Guest Team supplies labour without making future contribution easier.

Here is the recognisable pattern. Contribution is permitted only after the Host Team cannot deliver. A small correction and a cross-service change pass through much the same front door, documents, meetings and approvals. The Guest Team owns design, implementation, testing, deployment and post-release support; the Host Team retains the material decisions. Consequential work may be ruled out before contribution can begin. The next Guest Team starts the same passage with the same people and reconstructed context.

That is an exception process for borrowing implementation capacity, not an engineering system learning to collaborate.

The problem is not Host Team accountability. Trust, evidence and improvements to the project cannot change the route. Discovery begins with permission rather than a draft change. Governance capacity is rationed independently of demand and consequence. Review returns to the same scarce people. The project remains no easier for the next capable engineer to change.

None of those controls proves the model is false on its own. A high-risk change may need every one of them. The tell is that the process cannot become lighter through evidence, familiarity or improvement to the project. It can accept code from outside the Host Team, but it does not develop an internally open engineering system.

The bottleneck moves from the Host Team's backlog to its design decisions, review attention and release authority. Those decisions may be necessary, but their capacity has not grown with the supply of proposed work.

Expensive passages change behaviour. Contributors may batch more into each submission because each review cycle is costly. Maintainers then receive larger, less familiar changes, which take longer to understand. Other teams may avoid the shared component or reproduce capability inside boundaries they control.

These are possible effects, not proof of bad intent. The answer is a proportionate route that consumes less scarce context.

InnerSource has a standard vocabulary

InnerSource Commons describes a Host Team, which owns the project, and a Guest Team, whose Contributor proposes a change through a pull request, called a merge request in GitLab. Product has a role on both sides. The Guest counterpart brings the priority, intended outcome and success measure. The Host counterpart brings knowledge of existing capability and destination direction. For new features and material capability changes, they agree a contribution path before substantial work begins. Routine fixes and local refactors need no Product handshake. Trusted Committers guide contributors, review work and protect the health of the project.

The corresponding principles are Openness, Transparency, Prioritized Mentorship and Voluntary Code Contribution. None gives a Contributor the right to merge. None removes the Host Team's enduring responsibility.

Once a team chooses to host an InnerSource project, direction and contribution rules should be visible and mentorship treated as project work. The Host Team may decline a contribution before work begins. Once it agrees a contribution path, it owes timely review against its published standards. Agreement creates a credible route to a decision, never a guarantee of merge.

InnerSource also supports different governance levels. A Host Team may welcome Guest Contributions while retaining control and strategy. Other projects may grant shared write access or develop shared ownership. These are legitimate choices, not a ladder every Contributor must climb. Retained authority alone is not evidence of faux InnerSource.

The next contribution tests the system

An effective Host Team becomes good at being understood.

Its direction, ownership and contribution standards are visible. A capable engineer can build it, run meaningful tests and trace a changed line to a running system. Interfaces make sense beyond their authors. Deployment and observability evidence do not depend on private knowledge.

These are not courtesies for Guest Teams. They are properties of healthy software.

If another engineer cannot build the project, the build has exposed a constraint. If only an incumbent can interpret the tests, the tests have exposed a constraint. If a meeting is required to discover the owner, ownership has exposed a constraint. InnerSource makes these conditions visible because an unfamiliar but capable engineer attempts a real change.

That obligation to mentor creates useful pressure. Maintainers must explain decisions well enough that a comparable future contribution can reuse the context. Repeated questions should improve documentation, automation or interfaces. Good review transfers context instead of merely checking compliance.

The Guest Team changes too. Its engineers work within another team's constraints, learn the operational consequences of their decisions and contribute evidence that remains after they leave. They become participants in a shared engineering system, not customers passing requirements across a boundary.

Controls are not the dividing line

Design constraints, scheduled review, controlled release and temporary post-release accountability can all belong to legitimate InnerSource.

A Guest contribution should follow the Host Team's normal path, standards and quality bar as closely as practical. Additional control should follow the change, not the Contributor's place in the organisation.

A shared library may need little beyond owner review and automated compatibility evidence. A service that handles identity, money or regulated behaviour may require security review, segregation of duties and a controlled production decision. A change that crosses repositories or team boundaries may need more integration evidence than a contained one.

Those boundaries can increase coordination, atomicity, operational and support risk. They should inform the assessment. They should not determine the control path by themselves.

The Guest Team may need to validate the outcome and correct defects attributable to its contribution until the agreed outcome and stability evidence are met. The Host Team remains the service owner throughout.

The better question is whether the control responds to the consequence of the change and the evidence available. A returning Contributor with demonstrated project knowledge, reliable automated tests and a reversible change should not consume the same explanatory effort as a first contribution to an opaque, high-risk service.

DORA's guidance on change approval favours peer review and automation for individual changes, with additional scrutiny for high-risk work. It also recommends examining the change process end to end and identifying bottlenecks. The aim is not the fewest controls. It is the shortest trustworthy path from proposal to evidence.

The merge request can hold the discovery

Approval processes often assume a clean sequence: define the requirement, approve the design, then permit development. Real engineering is less obedient.

An implementation reveals an awkward dependency. A test exposes an assumption hidden in an interface. A small experiment shows that a proposed abstraction is unnecessary. Coding is one of the ways engineers discover the shape of the problem.

A draft merge request lets design, experiment and review develop beside the implementation. It creates no entitlement to merge. The Host Team can reject the approach, ask for a different boundary or decline the contribution. The Contributor accepts that exploratory code may never merge. Acceptance governs shared software and its production path, not whether an engineer may learn enough to make a good proposal.

A routine contribution does not become safer because its reasoning is copied into a second system.

The merge request can hold the problem, the proposed decision, the implementation, discussion, accountable approval, automated evidence and links to deployment and observation. In GitLab, a draft merge request makes the provisional state explicit. The evidence stays attached to the revision it describes.

A separate RFC or architecture decision record is warranted when the decision must outlive this implementation, establishes a shared dependency, spans several repositories, commits material cost or changes a lasting security, privacy or operational obligation. It should be linked from the change, not reproduced for another audience.

The first Guest Team may need a meeting and a separate explanation because the project does not expose its decisions well. The next should find more of that context beside the code.

Stewardship can expand

A Trusted Committer is not required. In an exception-only model, every contribution returns to the same scarce approvers. Familiarity does not expand the organisation's ability to decide.

In a capability-building model, demonstrated stewardship can lead to the Trusted Committer role. Scope remains explicit. The Host Team retains accountability. Authority grows because a Contributor has shown judgement, project knowledge and care for its operation.

Not every Contributor will want that role, and some Host Teams should retain all write authority. Repeated contribution should still create reusable knowledge when authority does not move.

Measure whether the system learns

InnerSource should be judged across contributions, not by the publication of a policy or the opening of a repository.

Measure time to the first accepted change and the share spent waiting. Track review batch size, change-failure rate and the proportion of Contributors who return. Compare work of similar consequence and complexity. Separate the advantage of a returning Contributor's memory from the onboarding cost for a new capable Contributor. Count improvement as system learning only when it can be traced to retained documentation, automation, evidence or distributed stewardship. Record how many projects can be built and tested from their published instructions. Where the governance model permits it, track how many Contributors earn scoped stewardship.

Reserved review capacity and additional gates may be sensible scaffolding while a Host Team improves brittle builds, implicit contracts or operational evidence. Scaffolding should have an expected effect. If comparable work keeps consuming the same reconstructed context, the operating model is not yet building capability.

In The Code Belongs to Everyone, I argued that the ability to propose a change should be the invitation. An open door is necessary. The Host Team becoming easier to contribute to is the result.

InnerSource may begin because one team needs another team's capacity. Its lasting value is the engineering organisation they leave behind.