The “Why” of Inner Source

By Jim Jagielski, Senior Distinguished Engineer with the Tech Fellows Program at Capital One

Most information and guides related to the topic of Inner Source focus on The How and The What of Inner Source. For example, explaining that Inner Source is “Taking the lessons learned in successful Open Source projects about software development and bringing them in-house” (the “what”) or “Make sure your GitHub repos are open to all developers” (the “how”). Now to be sure, this is useful information to have, but ignores, at least to me, the most important aspects of Inner Source: The Why.

The importance of understanding The Why of Inner Source is critical to helping fine-tune how Inner Source is implemented in one’s environment. There is a spectrum of Inner Source methodologies, each with their own particularly suited “sweet spots,” but choosing which implementation is difficult, if not nigh impossible, unless one understands the basic foundations behind Inner Source; and this requires insight into what Inner Source is based upon: Open Source.

Software Developers are Curious, Artists and Craftspeople

Open Source, both as its own independent entity as well as an “offshoot” of the Free Software Movement, is based on a number of fundamental guidelines related to software development, and, at its core, the individual software developer. Common to both Free Software and Open Source is the requirement that access to the source code of a project must be available. But why should that be? The reason is simple: it is an acknowledgement that software developers will inevitably want to, or need to, read and modify the code. It is stating a fundamental principle that software developers are curious creatures, with a deep desire to not only know how things work, but to create and change those works themselves.

Software developers are artists, craftspeople. Successful Open Source projects are based on this realization. Licenses define the culture of the code, so to speak, but projects define, and create, the culture of contributor interaction, knowing what works and what does not. The underlying philosophies of meritocracy, transparency and community, the core aspects of Open Source and The Apache Way, are there to enable collaboration. Collaboration isn’t an end-game; it’s a starting point. An environment that fully embraces meritocracy, transparency and communication is the ideal soil for collaboration to take root. And the more one “cuts back” on either (or all) of those 3 guiding principles, the more difficult collaboration becomes. At which point, you really aren’t doing “Inner Source” at all, because the Why of Inner Source is to HAVE collaboration.

Collaboration Brings out the Best in People and Results

It is from this collaboration that all the “Good Things” of Inner Source naturally and organically derive from. Code reuse doesn’t need to be forced upon teams; they will simply naturally reuse good code that they can, and have, collaborated upon. In fact, if one finds that code reuse of a particular project must be mandated, it’s solid proof that one has not done Inner Source correctly.

Collaboration is also where innovation itself comes from. The ability for a diverse community to work together brings out the best in people; it also provides a wide range of different points of view that serve as the catalyst of innovation. We see this, and naturally understand this, in the areas of science, mathematics and medicine. Software development is no different.

Open Source, and thereby by extension Inner Source, is based on the knowledge that individuals, working in collaboration, produce robust, reliable, secure and innovative software. That more so than any other software development paradigm, Inner Source creates projects and products that alleviate risk, are produced and implemented faster, and result in commercial success.

Why? Because It Works!

In essence, the answer to “Why Inner Source?” is because, quite simply, it works.

These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2017 Capital One.

Image Copyright Giorgio Fochesato.