Key Factors for Adopting Inner Source

Author(s): K. Stol, P. Avgeriou, M. Ali Babar, Y. Lucas, B. Fitzgerald
Venue: Transactions on Software Engineering and Methodology
Date: March 2014

Type of Experiement: Case Study
Sample Size: 3
Class/Experience Level: Professional
Participant Selection: Code Metric
Data Collection Method: Observation, Code Metric


This case study was used to evaluate and analyze how to properly adopt the Inner Source framework, a framework where open-source development practices are used be an organization. This idea came about while studying the success of open-source projects which follow no clear development process. In researching Philips Healthcare, Neopost Technologies, and Rolls-Royce, companies using or planning on using Inner Source practices, this article outlines nine factors that should be accounted for and addressed for an organization looking to use Inner Source development practices.

In doing research on open-source development, whose techniques are not defined very well, there are several common practices seen. These include global use of necessary artifacts such as source code, a transparent development environment, reviews of the project by peers, use of unofficial means of communication as well as constant releases, motivated contributors, and frequent development, essentially at all times. Open-source projects also develop a sort of hierarchy amongst members, where contributors have more control over the project based on their standing.

The researchers attempted to take their findings and produce a framework from which an organization could successfully utilize Inner Source. Five steps were followed in order to create this framework. These were extracting data, coding data, turning the code into themes, creating a model for the higher-order themes, and evaluating how correct the research is. For the first part of the framework focusing on the product, there must be a seed product to be built upon. Next, there must be multiple stakeholders working on the product as well as be modular.

The study showed that it could be difficult to gather as well as maintain a large number of stakeholders on a project. Though it is necessary for development on the projects to be a ‘bazaar-style’ in which the code is in view of the public, this proved to manifest itself differently depending on the company. An example is Rolls-Royce in which redoing features or implementations were limited by the requirement for their products to be compatible. Further research could look into the phases that an Inner Source Project goes through, such as the bazaar phase and the cathedral phase.