What is the difference between our open source and inner source strategies and teams?

Short answer

InnerSource applies open source collaboration practices inside the organization, on proprietary code. Open Source makes code publicly accessible to the world. The key difference is visibility: internal vs. global. Both strategies are complementary and can be governed by the OSPO.

Detailed explanation

Side-by-side definitions

InnerSource: open source in private mode

InnerSource is a software development strategy that applies open source best practices (transparency, cross-team contribution, peer review) to internal development — without making the code public.

In practice, this means:

• Any developer in the organization can view, report bugs (issues), and propose improvements (pull requests) to projects owned by other teams.
• Code is open by default internally, rather than siloed by team or department.
• Projects have designated maintainers, internal contribution documentation (CONTRIBUTING.md), and a transparent code review process.

Why adopt InnerSource?

InnerSource addresses concrete enterprise problems:

• Breaking silos — teams stop rebuilding the same components in parallel without knowing it.
• Code reuse — a component built by Team A can be discovered and reused by Team B without reinventing the wheel.
• Quality — open internal code review improves quality and spreads best practices across the organization.
• Collaboration culture — prepares teams to eventually contribute to external open source projects.
• Reducing “Not Invented Here” syndrome — developers are encouraged to contribute to existing projects rather than create new ones.

The strategic continuum

The two approaches are not in competition — they form a maturity continuum:

Proprietary code        InnerSource           Open Source
    (siloed)      →   (open internally)  →  (open to the world)
  per-team              entire org            community

An organization can practice InnerSource to accelerate internal collaboration, and later decide to open specific projects to the community — following OSPO validation (see Can we open source our own internal projects?).

Who leads what?

Some larger organizations create a dedicated ISPO (InnerSource Program Office), particularly where both practices require separate resources. In our organization, the OSPO coordinates both strategies.

Practical day-to-day differences

InnerSource as a stepping stone to open source

For organizations new to open source culture, InnerSource is often recommended as a first step: it lets teams adopt collaborative practices (open code review, documentation, contribution processes) in a safe environment, before considering public releases.

Common pitfalls

• Thinking InnerSource just means making internal repos visible — without designated maintainers, a review process, and contribution documentation, an “open” internal repo remains a siloed project.
• Confusing the two approaches in communications — developers must clearly know whether a project is internal or public, to avoid accidentally sharing sensitive information.
• Neglecting InnerSource governance — even internally, clear contribution rules prevent conflicts and regressions.

See also

• Why does our organization have an open source strategy?
• What is the role of the OSPO?
• Good governance handbook
• Can we open source our own internal projects?
• InnerSource Commons — Learning Path
• GitHub — Introduction to InnerSource