InnerSource? What’s that?

Have you ever had a task to write something commonly used in a company (like an authentication mechanism) for your greenfield project, but there was nobody to ask for hints how to connect to a corporate infrastructure? You checked with a couple of teams and discovered that the most experienced developers in the topic… are not there anymore. Luckily, you have found some pieces of documentation… but it turned out to be outdated. Finally, you have figured out which systems used similar mechanisms in production and you were able to identify developers who still maintain them. You would like to analyze their solution… but you do not have access to their repository. After a struggle to get access, you can finally dig deeper into the code… just to find out, that every team used a different approach and you have no clue which one is optimal and which you should use. You compare these solutions and do POCs… After a lengthy analysis, you finally understood how things work. You have even found a bug in one of the reviewed solutions… but still cannot do anything about that as this repository does not belong to your team… and the given access just got revoked.

I have seen that, I have been there… Many times, in many large companies. A few years ago, I have heard about the “InnerSource”, which is basically the use of open-source practices in the “inner”, non-open-source corporate codebase. From my point of view, this approach is a fantastic way to solve the abovementioned issues. Other obvious benefits are, just to name a few: better software quality, lower development costs (reuse of solutions), faster development, enhanced collaboration, easier knowledge sharing as well as increased transparency.

There ain’t no such thing as a free lunch, though. Implementing these practices in the established, corporate environment can be challenging, despite they give the company enormous benefits.

InnerSource in the nutshell

With the InnerSource mindset, projects inside the company shall be treated similarly to open-source code. These practices involve:

• Open collaboration, where every developer has the access to the corporate codebase, CI toolset, documentation, issue trackers, and so on. No need to ask for access or permission, these artifacts are transparent
• Projects shall have a list of maintainers. Every developer should be able to create a pull request to any repository, get the code review, discuss the change with maintainers, and eventually have the code merged (or declined, if needed).

Tools that help

Apart from that, there are several things that may even further encourage collaboration and ease of knowledge sharing. I think that the most crucial are:

• a quick way to search the entire codebase and documentation – devs should be able to “google” all repositories and get satisfactory results
• GitHub-like badges (build status, code coverage, security checks) for each repository that give more context about the health of the project and provide quick links to integrated CI tools
• a way to promote useful repositories (like stars) and top contributors
• an application portal, where you can see all apps developed in the company. It would be great to see stars for these apps, forks, and top contributors

Common challenges

Of course, InnerSource is not a silver bullet that will increase the productivity of developers (and not only!) without any challenges. From what I experienced and consulted with other folks, a few common challenges are:

• The management may not understand the benefit of having the InnerSource practices in the company. Without the support of the management, it is very difficult for any bottom initiatives like that to flourish. InnerSource has to get its funding, at least to have a proper promotion across the company in the initial stage
• Developers have no time to contribute to external repositories
• Some developers may not be willing to understand different codebases as it requires time and effort
• Some teams would rather like to keep their codebase private for various reasons:)

My story

Together with yet another colleague, I was promoting InnerSource in one of the companies I worked for. We were doing technical sessions, bootstrapping projects, and generally engaging developers to start using open-source practices inside the company. The idea of using open-source practices was very appealing to developers and lots of them have engaged in making their projects open. It was very satisfying to see PRs coming from different teams, or that a library or a bootstrap project got a wider adoption across the company once it became more visible. Nevertheless, we also faced challenges. When the company changed its direction and switched its priorities, we were not able to keep the momentum without a proper time allocation to promote the initiative. Also, without a dedicated application portal where developers can browse projects, it is much more difficult to make worthy apps visible.

InnerSource? What’s that?

Despite that InnerSource is used in many companies (check Inner source – Wikipedia), it took almost two decades for me to first hear about that. Strange, taking into consideration all the benefits the open-source practices can give to a proprietary code. Hopefully, you have heard of/used it earlier. Let’s also hope that more and more companies will adopt that – it will make our life much easier! I do not own my software company, but InnerSource would be one of the first things in the software development dept I would like to apply. I also think that smaller companies are “InnerSourced” by default, in contradiction to corporations with dozens of information silos.

If you like the idea, here you can grab a bunch of useful materials from Awesome InnerSource (great work, Przemek!). Do not forget to check out the Backstage or SAP app portal – maybe starting with the InnerSource in your company will be easier than you think.