You most probably have heard of open source, a philosophy or mantra of source code that is made available and distributed freely for others to consume or modify and further re-distribute. According to Wikipedia:
The term “open source”, as used to describe software, was first proposed by a group of people in the free software movement who were critical of the political agenda and moral philosophy implied in the term “free software” and sought to reframe the discourse to reflect a more commercially minded position. Moreover, the ambiguity of the term “free software” was seen as discouraging business adoption. The group included Christine Peterson, Todd Anderson, Larry Augustin, Jon Hall, Sam Ockman, Michael Tiemann and Eric S. Raymond. Peterson suggested “open source” at a meeting held at Palo Alto, California, in reaction to Netscape‘s announcement in January 1998 of a source code release for Navigator. Linus Torvalds gave his support the following day, and Phil Hughes backed the term in Linux Journal. Richard Stallman, the founder of the free software movement, initially seemed to adopt the term, but later changed his mind. Netscape released its source code under the Netscape Public License and later under the Mozilla Public License.Wikipedia
A lot of popular software and platforms are part of this category. Even at large companies like Apple or Amazon, your engineers are most likely using open-source libraries within your apps. Leveraging open-source provides you with the opportunity to build a thriving community to drive support, provide unique solutions and capabilities, faster and better, and at scale. Seems pretty straightforward, but what is inner source?
What is InnerSource
InnerSource Commons concisely defines InnerSource as:
The use of open source principles and practices for software development within the confines of an organisation.InnerSource Commons
Working in an enterprise company like Amazon or Apple, you may not always have the ability to (or want to) publish your code to the world, but that doesn’t mean you can’t take advantage of many of the benefits that power open source software. This is what InnerSource is, bringing the best practices within your firewall. Thing of it as inviting contributions to your code beyond your team, breaking down silos and enabling other organizations and teams within your company to contribute back.
Whereas many companies wouldn’t be comfortable open-sourcing proprietary technology, keeping it within the confines of your organization, but being able to scale feature development and bug fixes beyond the expertise of inner circle is a powerful mechanism. Not only do you gain in new expertise perspectives, but you reduce the risk of knowledge being concentrated to a few, especially in cases of attribution, but encourage anti-tribalism and innovation.
The working group breaks down best practices into a form of repeatable and proven solutions, called patterns.
The purpose of patterns is to provide concise bite-sized solutions in the form of title, problem statement, context, forces, and solutions. Recipe-driven, these patterns help bridge the abstract theory into practical steps to solve your scaling problems.
Is InnerSource Right for Me
Much like agile, patterns are a framework, that comes down to customization for your environment, and the execution. I have no doubt that the best way to scale is to liberate your code. Open Source has proven itself over time and can stand as great testament to how Inner Source may work.
Answering for myself, I empathize with the premise of this framework based on the problems identified in the patterns. Despite the size of my company, we can’t scale at the pace we want, and other teams using our product have vested interest in certain features. Rather than be the bottleneck, open up your framework to them.
Whether it is right for you or not depends. The same reason many companies don’t want to go open-source, there are valid reasons for that as well. But opening up your code base to internal customers offers the same security and trust comfort whilst expanding your contributing capacity. You just have to ensure you have the right gatekeepers to ensure quality code, quality documentation and minimize regression problems.