The Unclear Definition of Inner Source

Usually, academics love definitions. A concise statement of the meaning of a term, concept, idea, variable, etc. But after almost 25 years, we still have no clear definition what inner source is. Just as in agile, we will face the same struggles — in academia and practice.

You might argue that inner source has a definition: According to Wikipedia,

Inner source is the use of open-source software development best practices and the establishment of an open source-like culture within organizations.

I should know because I initially wrote the Wikipedia article. Of course, the definition is not originally from me. Tim O’Reilly came up with this term in 2000. Different scientific publications followed over the years and for now we settled with this or a quite similar definition. However, they all have in common: It remains unclear what the best practices in open source are or how an open source culture feels like.

Let’s assume we are a company kicking of an inner source initiative. So we have a look at how different open-source projects handle new code contributions:

• TikiWiki describes their code review process as the “software made the wiki way”: Every everyone registered has write access to the main repository.
• TeX, the famous typesetting system, writes: „The files in this directory are master files maintained personally by Donald E. Knuth. Nobody else is authorized to make any changes whatever to them!“
• OpenStack, a platform for cloud computing, has an elaborated review voting system with [-2, -1, 0, +1, +2], while -2 and +2 are for core developers only; change to be merged requires two times +2
• For the Linux kernel, Linus Torvalds (a more or less benevolent dictator for life) or one of his lieutenants decide which code contributions make into the code base and which do not.

Those are all best practices (please remind me to write another blog post about why best practice is a terrible term) for those projects because the projects are successful and the practices work very well for them. The same applies for the culture. But what is now the best practice for handling new contributions that we can implement as inner source in our company now?

Of course, there is no one size fits all. However, this makes it impossible to draw a clear picture of inner source and draw conclusions on what practices companies should use internally — then as inner source best practices: You will always find a practice in open source — no matter how strange. But if everything goes, we cannot verify the promised benefits from inner source because it depends all on the process implementation which does not generalize.

In academia, we additionally have the problem of sampling: How do we know that a company is doing inner source and not something else? Just because they claim they are doing inner source? Do you mean like every company is doing agile software development nowadays — maybe even with a half-a-year sprint?

In the Wikipedia article, I tried to distill the core principles of open source: Open collaboration, open communication, and quality assurance through separation of contribution from integration.

But I am not happy with them at all, they are interwoven, linked, and not clearly separated: For example, code review can be considered as part of the open communication. Or open collaboration, that is egalitarian (everyone can join, no principled or artificial barriers to participation exist), meritocratic (decisions and status are merit-based rather than imposed) and self-organizing (processes adapt to people rather than people adapt to pre-defined processes), is simply not possible in the confines of a company: Someone is accountable, someone is the boss, someone is authorized to issue directives.

I fear we will see the same dynamics as in agile software development: In this area of uncertainty, different inner source frameworks will arise, with them a certification system that money can buy, and the choice of processes is religious and not grounded empirically.