Today, I gave a keynote at the 2018 spring Inner Source Commons summit at Bosch, in Renningen, Germany. I talked about our experiences with ten years of inner source projects at the companies we have been working with. The slides are available as a PDF.
The photo above is from the first keynote of the day, by Stefan Ferber, CEO of Bosch Software Innovations, celebrating the diversity and global distribution of software development at Bosch.
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.
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.
I’ll be giving an invited research talk (“journal-first”) at FSE 2016 in Seattle today, Nov 15, 2016. It is in Session 5, right after lunch. The underlying Transactions on Software Engineering (TSE) paper is available here. More on inner source here.
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. (If you would like a DOC version, please get in touch with me.)
Abstract: Inner source is an approach to collaboration across intra-organizational boundaries for the creation of shared reusable assets. Prior project reports on inner source suggest improved code reuse and better knowledge sharing. Using a multiple-case case study research approach, we analyze the problems that three major software development organizations were facing in their product line engineering efforts. We find that a root cause, the separation of product units as profit centers from a platform organization as a cost center, leads to delayed deliveries, increased defect rates, and redundant software components. All three organizations assume that inner source can help solve these problems. The article analyzes the expectations that these companies were having towards inner source and the problems they were experiencing in its adoption. Finally, the article presents our conclusions on how these organizations should adapt their existing engineering efforts.
Reference: Riehle, D., Capraro, M., Kips, D., & Horn, L. (2016). Inner Source in Platform-Based Product Engineering. IEEE Transactions on Software Engineering vol. 42, no. 12 (December 2016), 1162-1177.
The 12th International Symposium on Open Collaboration (OpenSym 2016) is the premier conference on open collaboration research and practice, including open source, open data, open education, wikis and related social media, Wikipedia, and IT-driven open innovation research.
OpenSym is the first conference series to bring together the different strands of open collaboration research and practice, seeking to create synergies and inspire new collaborations between computer scientists, social scientists, legal scholars, and everyone interested in understanding open collaboration and how it is changing the world.
OpenSym 2016 will be held in Berlin, Germany, on August 17-19, 2016.
Abstract: Inner source is an approach to collaboration across intra-organizational boundaries for the creation of shared reusable assets. Prior project reports on inner source suggest improved code reuse and better knowledge sharing. Using a multiple-case case study research approach, we analyze the problems that three major software development organizations were facing in their platform-based product engineering efforts. We find that a root cause, the separation of product units as profit centers from a platform organization as a cost center, leads to delayed deliveries, increased defect rates, and redundant software components. All three organizations assume that inner source can help solve these problems. The article analyzes the expectations that these companies were having towards inner source and the problems they were experiencing or expecting in its adoption. Finally, the article presents our conclusions on how these organizations should adapt their existing engineering efforts.
Keywords: Inner source, product line engineering, product engineering, software platforms
Reference: Dirk Riehle, Maximilian Capraro, Lars Horn, Detlef Kips. “Inner Source in Platform-based Product Engineering.” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Report, CS-2015-02. Erlangen, Germany, 2015.
According to this article, Google’s 20% time never really existed. I’ve always guessed as much, joking with Google friends that their 20% time really could only be taken on Saturday and Sunday. Which is all the same: Engaged employees do what they feel needs to be done no matter what and when.
Hackathons, however, exist. Facebook, SAP, and Suse are example companies that organize them with the purpose of prototyping potential new products. For all that I can say, the dirty little secret is that there are no successful hackathons without 20% time (make it +/- 15%). I’m betting that rarely was there a successful hackathon without a run-up to the hackathon that involved significant preparation, that is, “20% time”.
As a consequence, for hackathons to succeed, employees must not be disenfranchised or overworked. Otherwise they won’t spend their personal time talking about and preparing for a hackathon. Also, they should have a purpose, that is, be tuned in to the company’s mission. I guess this means that the better the company is doing, the more likely it is to get something out of their hackathons.