Dirk Riehle's Industry and Research Publications

Getting Started With Inner Source

I received several requests recently for my inner source charter document to provide it in DOC format, after I thought this work had fallen dormant (or perhaps the PDF version was sufficient). So I wanted to add my thoughts on how to take first steps in inner source, in particular in the selection of a pilot project.

While you can take a big bang approach to inner source, trying to roll it out in one step as broadly as possible, a more incremental process is likely to be more successful. After surveying prior inner source projects (who may not even have known that a name for them exists) to determine early allies, a first question is usually what could serve as a good pilot project. My answer to this is that in general you should start small but relevant, and increase complexity from there.

Companies loathe to experiment with anything that makes money (unless they have to), but if you choose a pilot project that makes no money, people may feel your (hopefully) success has little relevance. So to demonstrate relevance, you may have to focus on utility for different engineering groups rather than revenue.

An example type of software that fulfills this criteria are widely used internal tools, for example, configuration tools or product editors, sometimes used in the context of a single product line, sometimes used more broadly. If an engineering group provided such a tool to the company, over time, users mostly likely will have customized it to their needs (assuming they received the source code).

Then, we are facing a situation where inner source eminently makes sense. The users want their changes to be merged back into the authoritative version to avoid having to reapply their changes every time a new version is released. The original engineering group is interested in improving and growing their tool.

At the same time, the tool is relevant to the organization and hence a good showcase of the power and relevance of inner source. Hence my recommendation to see whether you can find such tool internally and turn that project into your first inner source (pilot) project.

Up next: Escalating levels of complexity in inner source projects.

Newsletter subscription


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes collaborative qualitative data analysis fun and easy.
EDITIVE makes document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use