The InnerSource Movement: What Happens When You Apply Open Source Thinking Inside a Company

One of the most persistent problems in large engineering organisations is the silo. Not the kind you can see on an org chart — those are managed, at least nominally. The invisible kind: the team that built a useful internal library that nobody else knows exists, the component that gets rebuilt three times across three departments, the developer who can’t contribute a fix to a codebase they depend on because they don’t own it.

The open source world solved this problem decades ago. I wanted to bring that solution inside.

What InnerSource Actually Means

InnerSource is the application of open source methodology to software development inside a company’s firewall — with the organisation retaining full intellectual property ownership. The principles are the same: any engineer can view the code, learn from it, comment on it, and submit changes. The difference is that it happens on internal repositories rather than public ones.

I led the InnerSource movement, and the work had three dimensions. First, actively promoting the model and making the case for why cross-team code contribution was better for everyone than siloed ownership. Second, identifying which applications across the organisation were good candidates for innersourcing — typically those with wide internal usage but narrow ownership. Third, coaching teams through the transition: how to write contribution guidelines, how to review external pull requests, how to maintain quality while welcoming contribution from outside your immediate team.

What We Built

Over the course of the initiative, I enabled over 200 applications to be innersourced. To make the ecosystem discoverable — which is half the battle with any internal platform — I built and launched a dedicated InnerSource discovery portal, and we open-sourced the portal itself, contributing it back to the broader community.

The Global Developer Experience and InnerSource movement became a recognised pillar of engineering culture, eliminating bottlenecks, reducing redundant development, and accelerating delivery speed across teams that previously had no formal mechanism for collaboration.

What It Changed

The less obvious outcome was cultural. When engineers can contribute to codebases outside their team, the organisational walls become more permeable in the best possible way. Knowledge spreads. Patterns converge. Developers stop feeling like they’re maintaining an isolated corner of a vast codebase and start feeling like participants in something larger.

That shift — from ownership to stewardship, from silos to shared infrastructure — is, I think, one of the most valuable engineering culture changes a large organisation can make. InnerSource is one of the most practical mechanisms for getting there.

---

In your engineering organisation, how many times has the same internal problem been solved independently by different teams — and what would it take to make that stop?

Let’s keep learning — together.