InnerSource - a better way to develop?

InnerSource is what has been defining my work for the last couple of years as I lead the InnerSource Initiative at Microsoft. It has been irritating me now for a while that InnerSource in general is often misunderstood as a different type of source. It is typically compared to open source and described as internal open source. This is however a misnomer in my opinion. To really grasp what InnerSource is, we have to look differentiated at it. For one, InnerSource is NOT a different type of source, it is the same company internal source that you cannot share with the world. Once you decide to use InnerSource methods, it is still your responsibility to maintain, update, develop the project to drive company goals and your customer satisfaction. InnerSource does not change the code or internal contracts. InnerSource at its core is rather more a collaborative behavior applied to how the repo content is developed within the confines of the company. InnerSource is somewhat similar to open source in respect to some of the behaviors, however, motivation, legal impact, risk are fundamentally different and thus require a differentiated thinking between open source and InnerSource.

Ideally you want to look at all your company internal code as InnerSource candidates and all the code you can share with the world as open source candidates. Why all of it? You essentially want to maximize the potential for collaboration in both worlds. By including all of the code (obviously except where legal or business reasons speak against it) you also make it easier for developers as you introduce a single concept: Sharing code / documentation where possible. By all practical means, code that cannot be shared will be hidden (private repos for example), and so the boundaries are very obvious and clear. No new ways to distinguish, no different ways to find code. Secondly, I used the word candidates. Candidates means you could technically choose to actively pursue collaboration, but I am sure you realize, not all candidates are equally great candidates. The important thing is to set all the repos up and work in them as if you would collaborate. You will discover that this helps to set expectations, drives team discipline, eases onboarding of new team members and will make the teamwork so much better as well. Third, distinguish between open source and InnerSource. Think about open source candidates as things that will be helpful for others outside your company walls to solve their business or technical problems and a way to learn languages, technologies and interact with others in communities. Think of good InnerSource candidates as things you can't share with the world but that can help your internal partners / internal customers to solve their technology / business challenges. I want to emphasize, the focus for InnerSource is relative narrow compared to open source: Help solving internal business/technology challenges and drive efficiency. Using this understanding in my opinion will help you to narrow down the behaviors you should primarily consider for driving successful InnerSource. (I am not saying there are no company internal communities with InnerSource, we do see some of this in Microsoft, what I am saying is that communities are much rarer in InnerSource settings, typically much smaller and more transactional in nature and thus play a different role than they do in open source projects. As a consequence, for most cases I would as much focus on community building as I would advise to do in the open source space, but rather look at the potential InnerSource collaborators as my customers and ensure their success.)

Now, back to the question, why would you choose collaboration as a general path? Collaboration is interaction between two or more parties that try to achieve their individual goals. To get there, they (hopefully) realize that partnering will enable them to achieve these goals easier/faster/better. This means in collaboration you deal with individuals, and dealing with people is messy - just ask any repo open source maintainer... Even worse, you may not have organizational control over them! So, why would you seek to work this way? It seems so much more efficient to shrink the project scope to just your team, right? Yes, it is easier to deal with fewer contributors that all interact within the same envelope and thus have a tightly aligned common understanding. No doubt, it is worse at the same time. When shrinking the circle of influencers to just your team (or a few others), you have also the limited the diversity of inputs available to you and you have limited the resources available to solve your problem. Your results and products will reflect this and thus will be less complete, less attractive/competitive and likely less commercial successful in the long run. In contrast, with InnerSource (or open source) you harness the power of collaboration, diverse thinking and experience. IF you implement great engineering practices and prioritize InnerSource behaviors, you will likely not only see better quality products, but you also likely see an efficiency, innovation and satisfaction boost within your organization or project. There is no sugar coating here though. Collaboration is work, it is work that needs to be planned for, invested in and executed on. This means mentoring, discussing (respectful), open communication, reviewing etc., but the benefits can be enormous as we have seen in projects inside Microsoft.

One great example about how InnerSource collaboration can work and help to achieve the above-mentioned benefits is described in the Microsoft DevOps Dojo case study that was just published by the InnerSource Commons. The case study highlights that InnerSource is NOT centrally about tools but focusses on the cultural aspects, clear processes, acknowledgement of achievements. This, combined with strong community leadership, has enabled the DevOps Dojo team to drive success with InnerSource in a setting with world wide distributed collaborators. The case study further shows that InnerSource is not limited to code but can equally successful be applied to documentation and guidance development scenarios. Finally, this case study showcases a scenario where a community is essential as many individuals use and contribute to the same set of documents. My gratitude goes to Kan Tang, the DevOps Dojo community leaders and the complete Microsoft DevOps Dojo community for this outstanding work as well as Clare Dillon and Daniel Izquierdo from the InnerSource Commons Foundation to create this case study. You can checkout this wonderful example of the possibilities of internal collaboration here and towards the end of the year a publication in paper format is planned as well.

Thanks for listening/reading, I hope this is helpful.

Arno Mihm, PM InnerSource, Microsoft