Inner Source— Adopting Open Source Development Practices within Organizations: A Tutorial Klaas-Jan Stol and Brian Fitzgerald Lero—the Irish Software Engineering Research Centre, University of Limerick, Ireland Abstract. Inner source, the adoption and tailoring of Open Source development practices inside organizations, is a topic of increasing interest. While Inner Source offers a number of benefits, in our experience many practitioners are unclear as to what Inner Source is, and what steps to take towards adoption. In this article we present a tutorial in which we outline nine key factors, pertaining to product, process and organization, which we have found to be important in working with organizations who are interested in Inner Source. This paper illustrates these nine factors with three inner source initiatives that we have studied. Keywords: open source development practices, inner source, adoption, key factors, tutorial Introduction Open Source has had an enormous impact on the software industry. 1 Open Source Software (OSS) is widely adopted by software development organizations in a variety of ways. Besides adopting OSS products, either as productivity tools or as off-the-shelf components, a number of organizations have adopted open source practices to develop their software. This is known as ‘inner source’ as the software is ‘sourced’ internally, although different terms have been used such as “progressive open source” and “corporate open source.” 2 Unlike traditional approaches, developers of an inner source project do not belong to a single team or department. Instead, anybody within the confines of the organization can become a contributing member of this internal community, either as a user or contributor. Raymond compared traditional software development approaches to building cathedrals, while referring to open source style development as a “Bazaar.” 3 Hence, inner source may be viewed as a bazaar within a corporate cathedral. 4 Several large organizations have adopted inner source over the last decade. An early study described the experiences of Hewlett-Packard, 5 followed by other company experience reports including Alcatel-Lucent, 6 Philips Healthcare, 4 IBM 7 and SAP. 8 Each of these companies has taken its own approach to adopting inner source. While all development methods must be tailored to an organization’s specific context, inner source is not a defined methodology, such as for instance Scrum, which defines a number of roles, ceremonies and artifacts. 9 Instead, inner source is best captured as a philosophy, using those practices from open source communities that can greatly add value to an organization’s development approach. Some common open source practices are: 2 • Universal access to all development artifacts such as code and documentation, and allowing anyone to inspect and submit contributions; • Independent peer-review of contributions by others in the developer “community”; • Informal communication channels, such as mailing lists and Internet Relay Chat (IRC) channels to allow for ad-hoc communication that can be archived for later reference; • Self-selection of tasks to allow developers to identify parts of the software that they feel they can improve, or defects to fix; • Early feedback and frequent releases to keep a project alive and quickly improving. This is by no means an exhaustive list of practices, but the above are a very common subset in successful OSS projects such as the Linux kernel and the Apache webserver. There is an increasing interest in adopting inner source as it can lead to potential benefits such as the following: • Increased level of software reuse through software products and components becoming available as inner source projects for anyone within an organization to use. 5,7 In many organizations, teams cannot access other teams’ source code. • Improved quality through leveraging of Linus’s Law 3 —Given enough eyeballs, all bugs are shallow. 5, 8 Digital Object Indentifier 10.1109/MS.2014.77 0740-7459/$26.00 2014 IEEE This article has been accepted for publication in IEEE Software but has not yet been fully edited. Some content may change prior to final publication.