InnerSource - Rethinking Your Sovereignty
The innovation landscape is fracturing. Geopolitical pressure is redrawing technology supply chains, and over-reliance on a handful of platform giants has stopped being a neutral strategic choice. InnerSource, the practice of running open-source workflows inside the enterprise, is how forward-leaning organisations are building the nervous system that connects autonomous teams and compounds institutional knowledge. The companies that master it will shape the technology landscape they operate in, rather than adapt to one shaped elsewhere.
The villain in the boardroom
For thirty years, enterprise technology strategy ran on a comfortable assumption: the platform under your code would still be there, on roughly the same terms, next year. That assumption is dead. Geopolitical pressure is redrawing supply chains at a pace few CIOs anticipated. A small number of platform giants now hold the pen on pricing, roadmap, and access, and the decisions are increasingly made in boardrooms several time zones from yours. The AI revolution amplifies the consequence in both directions. Organisations with strong institutional foundations are pulling away, those running on hidden dependencies and siloed knowledge are watching the ground move beneath them. Most still respond by writing a vendor management policy and calling it sovereignty. It isn’t.
“Most still respond by writing a vendor management policy and calling it sovereignty. It isn’t.”
The octopus, not the org chart
In The Octopus Organization, Phil Le-Brun and Jana Werner offer a metaphor worth borrowing whole. The traditional enterprise, what they call the Tinman, is rigid, centralised, and slow. The octopus is different. Two-thirds of its neurons sit in its arms, each one capable of sensing and acting on its own, coordinated by a central nervous system that keeps the whole creature pointed in the same direction. The most innovative enterprises are already evolving this way without using the word. Autonomous teams shipping fast across business units, geographies, and product lines. Independent arms, moving with intent. But arms without a shared nervous system cannot learn from each other. They lose institutional memory the moment an engineer changes teams. They solve the same problem twelve times, each time from a blank page.
InnerSource is that nervous system.
What InnerSource actually is
InnerSource takes the practices that made open source the dominant model of software development on the planet (transparent code, contribution guidelines, distributed review, public discoverability) and runs them inside the organisations walls. Code, documentation, and expertise are shared, discoverable, and collaboratively developed across business units, while staying inside enterprise governance, IP protection, and access control. Think of it as the collaborative velocity of open source under the security model of enterprise development. The relationship with open source matters strategically. Organisations with mature InnerSource programmes tend to contribute upstream to the tools they depend on, which strengthens shared foundations and builds the reputations that attract scarce engineering talent. The United Nations’ Open Source initiative signals that this model has reached institutional maturity. What started as a developer practice is now sovereign technology strategy at the highest levels.
The proof, with names
Bosch is the canonical case. What began in 2009 as a controlled experiment now spans 34.000 members, 150 business units, 50 countries, 12.000 repositories, and over a million code contributions. Community-developed solutions have hardened into internal standards, and InnerSource has become a recruiting argument, not just an engineering one. The pattern repeats broader. SAP reports 70% of its engineers actively want to contribute to internal InnerSource projects. Tencent has InnerSourced 80% of its codebase. Nationwide has converted direct cost savings into capacity for higher-value work. Microsoft has been doing this consistently for more than five years, citing sustained gains in both engineering satisfaction and product quality. The mechanism becomes to life and visible in Internal Developer Portals: self-service interfaces aggregating tools, documentation, APIs, and services into one place. Backstage, built initially by Spotify and now one of the top 5 active CNCF open-source projects, is InnerSource embodied. A small core team maintains a flexible platform, and 80% of contributions come from outside that team. American Airlines replicated the model with their “Runway” portal: 16 core engineers enabling 108 contributors across the company. Their own conclusion: “I don’t think Runway would’ve been successful without InnerSource.” Volvo Group scaled their Backstage instance from 100 to 1,000+ weekly active users in twelve months. Self-service provisioning collapsed setup time from days to minutes. A central API catalogue consolidated 3,600+ APIs that nobody had previously been able to find.
“How an organisation builds software determines whether it compounds knowledge over time, or quietly silos itself into irrelevance.”
Why now
Three forces are converging. External technology dependencies have become strategic exposures, and the answer isn’t to reject external platforms but to build the internal capability to navigate, adapt, and where necessary substitute. AI accelerates the cost of siloed knowledge faster than it accelerates almost anything else. An organisation that cannot find what it has already built is now losing ground monthly, not annually. And engineering talent remains scarce. Engineers who experience the autonomy and visibility of InnerSource rarely return to closed, siloed development. InnerSource is a delivery strategy and a talent strategy at the same time.
Growing the nervous system
There is no shortcut here. The octopus didn’t grow eight arms and then bolt on a nervous system; the intelligence emerged through use. Start with the teams who already share code informally and give that practice a backbone: documented contribution guidelines, discoverable repositories, lightweight cross-team review. Celebrate the early contributors by name. Measure reuse, not output. Then expand.
What separates the organisations that succeed from the ones that stagnate isn’t the tooling; it’s the governance and the cultural intent. Make it genuinely safe and rewarding to contribute across organisational boundaries. Reward reuse over reinvention. Treat ecosystem health as a first-class metric.
The organisations that build this don’t merely reduce dependency. They develop the capability and the culture to shape the technology landscape they operate in, rather than adapt to one shaped elsewhere.
The octopus does not wait to be fed. It reaches.
(this article also appeared in DPIR 12)