Proprietary software is normally developed by trusted teams with controlled access to source code for applications. A set of applications is supported by a dedicated team on the payroll.

Open source software differs in acceptance of contributions from anyone. Project mediation is conducted by trusted maintainers. Mostly everyone is donating their time as a volunteer.

InnerSource applies the mentality of open source to building proprietary software. It sounds simple, but the cultural shift is significant. Let’s consider how other teams in an organzation could routinely contribute to applications without project ownership.

What happens when any dev team is allowed to contribute to any company project?

Trust

Restrictions usually exist to prevent non-team members from participating on software projects. What happens when any dev team is allowed to contribute to any company project? Should they contribute in the same fashion as team members? Could they even get started? It depends.

Trust is likely built into development pipelines, and those contributing to the project operate within guidelines for trusted team members. A development workflow without implied trust among all developers requires checks and approvals by select members of the owning team.

Process

InnerSource establishes processes that allow other teams, employed by the same company, to participate in a project without full-time ownership. Outside contributors, like any new team member, need a project on-ramp. Those projects need guardrails to allow experimentation by those without detailed project knowledge.

Contributors need to:

• Quickly setup an environment.
• Run the necessary automated test.
• Deploy to a sandbox environment.
• Contribute back their improvements.

InnerSource establishes processes that allow other teams, employed by the same company, to participate in a project without full-time ownership.

Just think how other teams across an organization might interact with a source repository. They could be unable to contribute like the owning team members. Their available options might be outside the usual workflow or have consequences.

If pushing to the repository is possible, they might:

• Push a branch not knowing team conventions.
• Send a PR that leverages the automated pipeline.
• Deploy the application and consume resources.

If forking the repository is possible, they might:

• Have no method of testing or deploying their fork.
• Trigger a pipeline to run somewhere unintended.
• Merge into main of their fork without any approvals.

These scenarios impact how pipelines must be developed and protected. A trusted path must be paved and maintained for these contributors. Otherwise, they will forge paths of their own. Many variations will become difficult to support, so project owners driving the process is preferable.

Teams must allocate time for interacting with outside contributors.

Mediation

Contributions from other teams is an exciting thought, but supporting those contributions takes effort from the owning team. These contributors are working outside the owning team’s priorities, so there is potential to distract commited resources from delivery goals. Teams must allocate time for interacting with outside contributors. Doing so should be balanced with reducing the owning team’s delivery commitments.

What is there to mediate?

• Managing expectations on if/when a contribution might be accepted.
• Onboarding outside contributors to the project.
• Reviewing and interacting with pull request from outside contributors.

InnerSource includes a product management component. Outside contributions are only welcome when they fit within the product vision. Nobody wants the greater team developing features that go nowhere, so substantial effort still needs a green light.

That might sound like unnecessary work, but remember these teams are part of the same organization and greater team. Organizational priorities are every team’s priority. If contributions are offered to achieve shared goals, then collaboration is necessary from the owning team. As you can tell by now, InnerSource includes a product management component. Outside contributions are only welcome when they fit within the product vision. Nobody wants the greater team developing features that go nowhere, so substantial effort still needs a green light. Of course, 20% time may still produce unexpected contributions. Those experiments are encouraged where extensive support is not expected.

Documentation

InnerSource turns every source repository into a consumable product. Limiting time on support requires self-service onboarding via good documentation. An organization wide initiative can set standards for every source repository to offload these decisions and the discovery burden. Each team will still be responsible for documenting the specifics of their application. This is just good practice, but doing this publicly is different.

Architecture

The application design will become an organizational artifact. Shortcuts and tech debt will be surfaced for all to see. Decisions will need to be justified. We’ve explored architectural decisions further in the article series on ADRs.

Product Roadmap

Knowing if a feature is planned or near release factors into contributions from other teams. No developer wants to duplicate effort. Surfacing the roadmap informs outside teams on whether they should contribute to acheive their own goals. It’s also an opportunity to solicit contributions!

Summary

InnerSource embraces open source techniques, but it differs in distinct ways: