Inner sourcing is the use of open source best practices within companies to improve engineering productivity. In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source to their engineering organizations. Using three generations of projects, we report about our experiences and how we are turning those into a practical handbook for inner source governance. Continue reading “Upcoming Talk on Ten Years of Inner Source Case Studies at UC Santa Cruz”
I was recently asked why I argue against company-internal marketplaces for software components yet emphasize the need for pricing components that cross company boundaries within the same holding company (also known as transfer pricing). The answer is simple: Setting up an internal marketplace is a managerial choice and pricing the movement of code (IP) across company boundaries is a taxable event that you need to deal with: It is not a choice.
Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.
I just listened to Eberhard Wolff’sBED-Con talk on microservice-based system architectures, which he prefers to call Independent Systems Architectures (ISA). One purpose of calling it ISA is to emphasize that there should be no common data model and no shared reusable libraries between microservices. Obviously, by discounting reuse, ISA may increase development speed short-term while increasing cost and quality problems long-term. Eventually, in his talk, Wolff came around and argued that microservce implementation independence and reuse are a trade-off rather than an either-or decision.
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.