We are proud and happy to announce that we are an official supporter and sponsor of the InnerSource Commons! Engaging successfully in Inner Source is one of the premier activities to become a better and more efficient tech organization. The InnerSource Commons is the world's largest community of Inner Source practitioners, and it offers a wealth of resources to support you on that path.

There are a lot of reasons to support the InnerSource Commons. Go to their website and check out all the good stuff there: Learning path, patterns, educational videos, community calls, recordings of past events, and a great community to support you on your Inner Source path. And because we believe in this community and the good work, they do for everyone, we have joined the ranks of supporters. But why is that so important? Let’s take a closer look at Inner Source.

Inner Source vs. Open Source

A lot of companies struggle with the successful implementation of the principles of Inner Source. Full disclosure: At Mercedes-Benz, we do, too. We do have a few really good, well-working Inner Source projects. But not as many as we would like. So why is it that Inner Source altogether is staying behind its expectations? Let’s examine some of the key factors.

First of all, when compared to Open Source, it is worth noting that Open Source projects are created for sharing from the start. This is not usually the case with most projects in Inner Source which are usually tailored to very specific needs, and thus may not be suitable or even interesting for a broader group. Thus, it can’t be expected that there will be as many successful Inner Source projects (however exactly you define success here) as Open Source.

Another aspect is that Inner Source done right requires additional effort applied to the project that you want to publish on your Inner Source platform of choice:

• You likely need to adapt code to make it fit for sharing (e.g., remove certain references or dependencies)

• There could be liability concerns (whether they are justified or not)

• You might want to crank up your documentation a notch

• You should make your project known in the Inner Source community, e.g., by advertising and installing community management

• There might be some legal or governance overhead which is not required for closed-source projects.

These efforts are quite similar to the ones required to make a project fit for Open Source (unless, as mentioned above, it is already created with sharing in mind from the beginning). But a lot of times it is perceived that Inner Source projects don’t receive enough contributions from outside the core project team to make this additional effort worthwhile. Paired with the notorious lack of free time of most developers – with this, I mean more or less freely available working time not tied to your main work topics – there is a low perceived additional value for oneself. Thus, a lot of teams of potentially successful Inner Source projects don’t even bother to take the first step to make it available for others to see.

One problem: Visibility of Inner Source projects

Furthermore, often an Open Source solution can be found faster for a problem at hand – which in our case, even follows our own FOSS Manifesto’s principle Prefer FOSS to look into Open Source first. This is also sometimes connected to the fact that Inner Source search tools aren’t as available or effective as for Open Source. (As a side note, let me recommend SAP’s Inner Source Portal here which we also have implemented internally.) Having said that, even though it is perfectly fine to look in Open Source first, this is still something that doesn’t foster Inner Source.

It is worth noting that only an estimated 2% of Open Source projects are considered successful* (with probably 0.5% taking the by far largest share). There is no reason to assume that this should be any different in Inner Source, yet this is sometimes expected.

Lastly, many times Inner Source afficionados mention the lack of middle management support as a hindering factor. It is easy to blame this group, but of course they too have their agenda and goals to fulfill, so it is on us to make it transparent to them why Inner Source will benefit them as well.

Criteria for Inner Source

So now, let’s look at two positive criteria for a promising Inner Source project (with "promising" here meaning: with a lot of potential participation from people outside of the core project team):

1. It needs to solve a common and widespread developer pain or demand. “Duh”, you might say. Yes, I agree – this one is obvious, but still worth mentioning explicitly. So much stuff gets innersourced and people are disappointed if no one cares, but when you look at it, it is a very specialized topic – which may be absolutely crucial for the people who need it, but only mildly interesting for the rest. Remember: You want the already busy developers from neighboring and other teams to take an interest and ideally even contribute in their valuable time. Think about where you would contribute: Only if it serves your needs and it will scratch your own itch, right?
2. It needs to be specific to your company. I.e., it either contains stuff that it is uninteresting for the general public, or it is somewhat confidential, or you would have to spend a lot of time removing company-specific stuff. For if this is not the case: Why not Open Source it?

With these two prerequisites fulfilled, you’re almost good to go! But note that it is also quite important to have at least one or better two dedicated maintainers who take care of the project, answer pull request and so forth, as well as a good amount of community management. In this, Inner Source does again not differ much from Open Source, but this is still often overlooked. I’ve seen projects getting published on the Inner Source platform, but they go there to die because no one takes care of it. The original publishers abandoned it and their idea from the start was that “it’s good stuff, so someone will pick it up” – not so. I hope I was able to spark your interest. Of course, there is much more to say and do around Inner Source – so: May the Inner Source be with you!

---

*The estimated 2% are just that – an estimation. I have no robust source for this. Please also note that roughly 68% of all statistics are completely made up anyway.