Back in December 2000, Tim O’Reilly, the founder of O’Reilly Media, coined the term “inner source” in his response to Matt Feinstein on Open Source and OpenGL. Back then, his definition of inner source was “to use open source development techniques within the corporation, or with a cluster of key customers - even if they aren't ready to take the step all the way to releasing their software as a public open source project.”

In twenty years, things haven’t changed much. The definition of inner source is still pretty much the same, but now organizations are heading down the inner source road for much more strategic reasons than just not being ready to go open source. Actually; inner source is seen as a means to significantly enhance the software development process of a large development environment by enabling distributed teams to develop software inside the corporate firewall in a much more efficient way than otherwise possible with conventional methodologies.

At the core, leveraging the best practices of highly efficient, globally distributed open source projects will naturally yield the typical benefits that open source projects already enjoy. But inside the corporate walls, this also enables teams that are not used to working together (e.g. multiple agile teams spread across several countries) to contribute code to a common codebase, turning a potential distributed agile nightmare into an efficient elegant reality.

Furthermore, when you encourage a diverse group of people to contribute to a common codebase, something excellent happens: Innovation. As Bill Joy, the co-founder of Sun Microsystems once said: “Innovation happens elsewhere.” You’re going to get a lot more innovation by encouraging out-of-the-box thinking, and the best people to think out of the box are the ones that are located outside your own box. Getting teams from different locations, contexts, even cultures to contribute to your software development effort will produce new ideas, faster and more consistently than one single team would come up with.

In the inner source approach developers can participate as much or as little as they can, based on the amount of time they can allocate and what they need or want to see in the project. This model of contributing based on need and availability enables an extremely efficient usage of time without requiring complex time management processes. And, the resulting increased speed of development drives much faster time to market and production of your internally developed code and – counterintuitively – with fewer bugs and defects.

Of course, you can only benefit from all of this if you put in place the right models for your development teams to work together. Your project governance, typical open source meritocratic structure, separation between contributors and committers, code reviews, community leadership and tools, and technologies to provide frictionless development. Using internal and external crowdfunding or gig-economy mechanisms to encourage initial contributions are additional methods to get you going efficiently.

Large, successful organizations such as PayPal and Capital One have strong inner source activities and are sharing their best practices as part of industry working groups to help other businesses be successful. So, when is your organization going to start its own inner source program?