What is InnerSource?
WHAT IS INNERSOURCE?
The term InnerSource was first coined by Tim O’Reilly in 2000 to describe the use of open source development techniques within an organization to develop proprietary code. It promotes the principles of openness and transparency inside a company’s firewall.
When InnerSource is implemented at scale, you can view all your organization’s code, use what is useful, and contribute any changes that you need for your context. Trusted committers then decide whether to incorporate those changes into the original codebase. It replicates how the open source community works, except the resulting source code stays within the confines of the company. A brilliant way to get used to open source culture in a safe environment.
Although InnerSource can be used as a step on the path to open source, organizations that implement InnerSource report that the practice also breaks down organizational silos, reduces bottle necks, helps knowledge sharing, and accelerates innovation. Indeed, because the latest generation of developers have grown up in a world of open source, and the related levels of agency and autonomy, adopting InnerSource helps create a working environment that makes it easier to find and retain today’s most talented developers.
InnerSource Origins
Although first coined back in the early noughties, the idea of InnerSource really started to gain momentum in 2015, when long term open source advocate Danese Cooper began to advocate for the use of InnerSource.
This coincided with increasing interest in open source in corporate enterprises. Danese Cooper had been hired to head up PayPal’s open source programs, but she quickly realized that PayPal needed to learn a lot about open collaboration before they could successfully participate in the open source ecosystem. In 2015 she gave a keynote at the annual OSCON conference and announced that PayPal was to focus on building InnerSource skills as part of their journey towards open source development. In that talk, she also announced the formation of the InnerSource Commons, a community of practice for individuals with the goal of creating and sharing knowledge about InnerSource.
Since then, InnerSource has been adopted by tens of thousands of developers, across all industries from big tech to banking, manufacturing, and retail, in all corners of the globe.
The Core Concept: Effective Cross-silo Software Development
Code re-use has become a key priority
for many organisations.
In traditional siloed organisations, reusable code may exist but teams simply can’t find it, can’t trust it, or have no incentive to contribute back. InnerSource systematically addresses each of these barriers.
By adopting open source practices internally, code is discoverable across the organization and any engineer can propose changes to any codebase. The host team acts as “Trusted Committers,” reviewing and merging contributions rather than writing every line of code themselves. InnerSource thereby provides the principles and practices that enable effective collaboration in software development across organizational boundaries
Can't find it
Code hidden in team repos
Shared, discoverable repositories with standardised docs
Can't trust it
Unknown quality, no review process
The fact that InnerSource code has been written to be seen and re-used coupled with a peer review culture produces higher quality code and builds trust and confidence
Can't contribute back
Organisational boundaries prevent PRs
InnerSource practices (e.g. Trusted Committer role) formalize cross-team contributions
How is this different from Open Source?
The mechanics are very similar,
but the scope is different.
-
Open Source: Code is available to the public.
-
InnerSource: Code remains visible and editable only to employees within your organization. It protects your IP while unlocking your workforce's potential.
Why Organizations Adopt InnerSource
-
Faster Time to Market: Teams are no longer blocked by dependencies on other departments.
-
Knowledge Sharing: Documentation and transparent decision-making become the norm, preventing knowledge from being trapped in individual minds.
-
Higher Quality Code: With more eyes on the code and a standardised review process, bugs are caught earlier.
-
Developer Happiness: Engineers feel empowered to solve their own problems and connect with peers outside their immediate unit.
Getting Started with InnerSource
Check out the book
for more ideas about how to get started in your organization.
