Author Archives: Dirk Riehle

Inner Source Definition, Benefits, and Challenges

Abstract: Inner Source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. A steady stream of scientific literature and practitioner reports indicates the interest in this research area. However, the research area lacks a systematic assessment of known research work: No model exists that defines IS thoroughly. Various case studies provide insights into IS programs in the context of specific organizations but only few publications apply a broader perspective. To resolve this, we performed an extensive literature survey and analyzed 43 IS related publications plus additional background literature. Using qualitative data analysis methods, we developed a model of the elements that constitute IS. We present a classification framework for IS programs and projects and apply it to lay out a map of known IS endeavors. Further, we present qualitative models summarizing the benefits and challenges of IS adoption. The survey provides the first broad review of IS literature and systematic arrangement of IS research results.

Keywords: Inner source, inner source definition, inner source benefits, inner source challenges

Reference: Capraro, M., & Riehle, D. (2017, February). Inner Source Definition, Benefits, and Challenges. ACM Computing Surveys, vol. 9, no. 4, article no. 67.

The paper is available as a PDF file.

Platforms but no Platform Organizations

One result of our recent case study research on inner source is that companies may not always need platform organizations to get to a platform of shared reusable assets. They will certainly need platforms, but they won’t need a dedicated organizational unit to develop and maintain this platform.

You don’t have to read the research paper to come this conclusion; common sense is just fine: Through the Apache Software Foundation (ASF), for example, companies like IBM, Oracle, and SAP are able to collaboratively develop the infrastructure of the Internet. The ASF has almost no employees; all work is done by the participating companies (and a few individuals). If companies like these, who fight each other to the death in front of a customer, can join hands to develop competitively non-differentiating software, why can’t organizational units inside software companies do this?

This is the idea of inner source: You don’t always have to have a dedicated organizational unit to work on a particular component. If the component is of broad enough interest within the company, users of this component might as well chip in and collaboratively develop the component. In the extreme case, and perhaps this is also the best case, no dedicated organizational unit is needed any longer for the development of shared reusable components.

The idea of doing away with a platform organization flies in the face of conventional wisdom. Given that textbooks tell you that product line engineering requires a dedicated platform organization, and leading companies are typically set-up this way, doing away with the platform organization may indeed prove to be too disruptive in the short-term. For this reason, we have developed several solutions that let companies keep their platform organizations.

Read more in the paper or contact us through my group’s homepage for research or my company’s homepage for commercial consulting.

Challenges to making software engineering research relevant to industry

I just attended FSE 2016, a leading academic conference on software engineering research. As is en vogue, it had a session on why so much software engineering research seems so removed from reality. One observation was that academics toil in areas of little interest to practice, publishing one incremental paper of little relevance after another. Another observation was that as empirical methods have taken hold, much research has become as rigorous as it has become irrelevant.

My answer to why so much software engineering research is irrelevant to practice is as straightforward as it is hard to change. The problem rests in the interlocking of three main forces that conspire to keep academics away from doing interesting and ultimately impactful research. These forces are:

  • Academic incentive system
  • Access to relevant data
  • Research methods competence

Continue reading

Putting on their #Gearface (no Google Daydream)

With all the hoopla on Google Daydream coming up, I thought I’d share two photos of people high on Samsung’s Gear VR. I think Samsung chose a better name for their product. The second photo clearly shows a person with a gearface. Can’t imaging calling this a daydreamface. The future is so bright, you’ll have to wear a mobile.

Mitgründer für Startup mit existierenden Kunden gesucht

Für Uni1 ( suchen wir mind. einen weiteren techn. Mitgründer (oder frühen Angestellten, wenn weniger Risiko gewünscht ist).

Uni1 will die Zusammenarbeit zwischen Unternehmen und Hochschulen weltweit revolutionieren. Uni1 hat bereits Kunden und basiert auf einem erprobten Konzept. Wir können zur Zeit wg. (noch nicht) ausreichender Softwareunterstützung leider nicht skalieren.

Ideal wäre ein Full-Stack-Entwickler mit entsprechender Erfahrung in Java + Javascript und Web-Technologien. Sozialkompetenz und die Fähigkeit in einem schnellen Umfeld zu arbeiten sind ebenso wichtig. Als Ort ist Berlin oder Nürnberg ideal, aber kein Muss.

Bei Interesse bitte Email an mich.

Dirk Riehle,

An Example Charter for Inner Source Programs

Abstract: Inner source software development is firm-internal software development that uses the principles of open source software development to collaborate across intra-organizational boundaries that would otherwise hinder any such collaboration. Inner source breaks down the barriers to collaboration across development silos by setting up an internal ecosystem of readily available software components. To get started with inner source, companies need to define their goals and then set up a governance structure for an inner source program and the projects within to reach those goals. This governance structure is often codified in the form of a charter document. This technical report presents an example charter for an inner source program. The goal is for companies to be able to copy and adjust this charter for their own needs. Towards this purpose, the charter leaves open the many decisions to be made, but outlines the options that any company needs to decide upon when establishing an inner source program.

Keywords: Inner source, inner source charter

Reference: Riehle, D. (2016). An Example Charter for Inner Source Programs. Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Reports, CS-2016-05, August 2016.

The paper is available as a PDF file.