Here’s a problem that almost every large software organisation knows intimately but rarely talks about directly: the same internal component gets built three times, by three different teams, in three different parts of the codebase. Nobody knows the other two exist. Each team maintains their version in isolation. The duplication compounds. The silos deepen.
I decided to do something about it — and the answer, it turned out, had already been solved in the open source world for decades.
What InnerSource Actually Is
InnerSource is the application of open source methodology to software development inside a company’s firewall, while the organisation retains full IP ownership. The principle is elegantly simple: anyone in the company can view any codebase, comment on it, learn from it, and submit changes — just as they would on a public open source project, but without any of the code leaving the building.
What this unlocks is significant. Reuse increases because developers can find and build on what already exists. Quality improves because more eyes review more code. Silos erode because contribution is no longer gated by team membership. And a culture of transparency starts to replace the default assumption that code, like information in most organisations, belongs exclusively to whoever created it.
Why I Spearheaded It
When I led the InnerSource movement at SAP Labs India, the problem it was solving was very real and very visible. We had a global organisation with multiple product lines, overlapping technical components, and engineering teams that had optimised for local velocity at the cost of collective efficiency. The bottlenecks were structural, not personal — and structural problems require structural solutions.
I drove the initiative across three dimensions simultaneously. First, evangelism: making the case to engineering leadership and teams for why this model was worth the transition cost, and what the compound benefits looked like over time. Second, identification: systematically scanning the application landscape to find high-usage, broadly-relevant components that were strong candidates for innersourcing. Third, enablement: coaching teams through what it actually means to run an innersourced project — how to write contribution guidelines, how to handle external pull requests, how to maintain quality without gatekeeping contribution.
Over the course of the initiative, I enabled over 200 applications to be innersourced across the organisation.
The Discovery Problem — and What We Built to Solve It
There’s a challenge that sits underneath InnerSource that doesn’t get enough attention: discoverability. If engineers can’t find the innersourced projects that are relevant to them, the benefits disappear. You end up with open codebases that nobody knows exist — which is functionally the same problem as having closed ones.
To solve this, I led the building of a dedicated InnerSource Discovery Portal — a searchable, browsable interface that surfaces all innersourced projects within the organisation, with metadata that helps engineers understand what each project does, its activity level, and how to contribute. Then we went a step further: we open-sourced the portal itself, making it available to any organisation facing the same discovery problem.
The portal lives here: github.com/SAP/project-portal-for-innersource
We presented it at the InnerSource Commons Summit in the Fall of 2020 — and the response confirmed that this wasn’t a problem unique to SAP. It was a problem the entire industry was sitting with. GitHub agreed: they featured the portal in two separate blog posts, in March 2021 and again in May 2022, as a practical model for solving the InnerSource discovery challenge at enterprise scale.
What It Changed
The obvious outcomes were engineering efficiency gains — reduced redundant development, faster delivery through component reuse, and fewer bottlenecks from single-team code ownership. But the less obvious outcome was cultural, and I think it was more lasting.
When engineers can contribute to codebases outside their immediate team, the organisational walls become more permeable in the best possible way. A developer in one product line finds a bug in a shared component used by another. In the old model, they file a ticket and wait. In the InnerSource model, they submit a fix. The barrier between “finding a problem” and “solving a problem” collapses — and over time, that changes how engineers think about their relationship to the broader codebase and to each other.
That shift — from isolated ownership to shared stewardship — is, in my view, one of the most valuable engineering culture changes a large organisation can make. The portal was a tool. The movement was the point.
In your engineering organisation, how much time is spent rebuilding what already exists somewhere else in the codebase — and what would it take to change that?
Let’s keep learning — together.
You can find the portal here: https://github.com/SAP/project-portal-for-innersource, and we presented the same at the InnerSource Commons Summit in the Fall of 2020, below is our session:
The portal has been featured in multiple github blogs such as:
harish.balasubramanian 
Share your thoughts