Adopting InnerSource

Chapter 1. The InnerSource Approach to Innovation and Software Development

With Andy Oram

InnerSource is a software development strategy rapidly spreading throughout large corporations—and it is also more. At its essence, InnerSource enables software developers to contribute to the efforts of other teams, fostering transparency and openness to contributions from others. But beyond that, InnerSource represents a collaborative and empowering way of involving employees in making and implementing decisions throughout the corporation. It embodies a philosophy of human relations, an approach to rewards and motivations, and a loose, adaptable set of tools and practices.

This book presents case studies at a range of companies to show when and why InnerSource may be useful to your organization. The case studies candidly discuss the difficulties of getting InnerSource projects started, along with the progress so far and the benefits or negative fallout. We hope that readers will be inspired to advocate for InnerSource within their software development groups and organizations.

InnerSource is an adaptation of Open Source practices to code that remains proprietary and can be seen only within a single organization, or a small set of collaborating organizations. Thus, InnerSource is a historical development drawing on the Open Source movement along with other trends in software. This chapter introduces InnerSource and locates it in the history of software.

Old Patterns of Development: Closed and Slow

Most people still think of the normal software development model as a team working by itself, communicating with the outside world merely by accepting lists of requirements and feature requests, then shipping prototypes and final versions of the software for testing. Many newer models of development challenge this norm, specifically the free and open software movement and various Agile and Lean development strategies such as Scrum, Extreme Programming, and Kanban.

The closed model is neither as old nor as rigid as usually thought. Early software developers shared their code. In the first decades of computing, it was hard enough to get the code working in the first place. Developers saw no commercial value in the code, or held an academic attitude toward open publication, or just lacked a business model for licensing it and collecting money. In addition, companies outsourced much development and every team depended on libraries from third parties, leading to much frustration and gnashing of teeth because of mismatches in requirements.

Commercial software—Microsoft being the obvious poster child—became commonplace during the 1970s and 1980s. In response, a conscious free software movement emerged, codified in Richard Stallman’s GNU Manifesto of 1985. It formalized code sharing, and the Open Source movement added a recognition that there was tangible business value to sharing. InnerSource taps into this business value while sharing code just within the walls of a single institution, or a consortium.

In a parallel historical development, software got bigger and more complex, eventually crying out for some kind of formal development model. Practitioners attempted to enforce strict adherence to a model of requirements definition, coding, and testing, spawning the movement called “software engineering” whose historical milestones include a 1968 NATO conference and a 1970 paper by Winston W. Royce¹ listing the rigid order of events in what he derisively termed a “waterfall model.”

Much derided now, the waterfall model and other accoutrements of software engineering made sense given the coding constraints of that era. Here are some reasons that the waterfall model caught on, along with the changes in the environment that render it inappropriate for most software development today (even where high-risk products such as cars and power plants are concerned):

Coding speed

Early computer languages, although astonishing advances over assembly language, required many lines of code. Modern strategies such as modules and patterns were slow in coming. Any small change in requirements could add weeks to the schedule. And loose language definitions, weakly supported by compilers, meant that a typo in a variable could lead to subtle errors requiring hours of investigation.

Nowadays, common coding activities have been encapsulated so expertly that one can implement a web server or a machine learning algorithm in a dozen or so lines of code. Tweaking and updating are routine activities and are expected.

Testing speed

Coding was not originally the most time-consuming part of development—testing took that prize. For much of computer history, developers tested their code by inserting temporary PRINT statements. Submitting code to quality assurance and developing tests included many manual steps.

Test frameworks, mocking tools, continuous integration, and branch support in version control systems make testing go much faster. Any change can be integrated into the project and run through automated tests quickly. The degree of automation makes test-driven development—where the developer creates tests in tandem with the code being tested, and strives for complete coverage—appealing to many organizations. Static and dynamic code checking also help.

Speed of build and deployment

Old applications were monolithic and might require overnight builds. They had to be manually installed on physical systems, and any change meant downtime and lost revenue.

Nowadays, most organizations strive for some form of modularization and packaging—aided by new tools and practices such as containers and virtualization, and infrastructure-as-code—the most recent instantiation of this trend being microservices. One can make a trivial fix and replace all running instances without the end users noticing at all.

As you can see, trends in hardware speed, software development, and networking have made collaboration methods feasible that are suppler than the waterfall method. Less obviously, they facilitate coding communities and collaborative development as well, and thus lead to the power of Open Source. The waterfall method always appealed to managers, sales forces, and customers because it promised products on supposedly reliable deadlines, but all too often those deadlines proved laughable (a constant theme of the popular Dilbert cartoon, for instance). Less rigid development methods have proven to be actually more reliable.

Factors Driving Open Source

The story behind Open Source has often been told, in works ranging from the popular book The Cathedral and the Bazaar² to the more academic Wealth of Networks.³ Some communities definitely aired philosophical views that code should be free like speech, but others sensed early in the movement an even more powerful incentive: that they could achieve more by working together than by having each organization set up barriers around their code and figure out a way to monetize it. Environmental factors that contributed to the tremendous growth of free and Open Source software included:

Ubiquitous networking

As more of the world joined the internet, and connections got geometrically faster in the 1990s and 2000s, more and more developers could download code and submit changes. Collaboration on mailing lists, chat channels, and other forums also became relatively frictionless.

Faster computers

Even the cheapest laptop could run a GNU/Linux operating system (in fact, that operating system was more suited to a low-resource environment than proprietary systems) fully loaded with cost-free development tools.

Improvements in collaboration

Free and Open Source developers took advantage of all common communication tools to create worldwide communities. A simple innovation made communication much more valuable: archives for mailing lists, which preserve the history of every decision made by a group potentially for decades. Centralized version control was supplanted by distributed version control, making it easy to work on a separate branch of common code and create extensive new features in isolation from the larger community.

Cascading effects of coding

Each advance in languages, libraries, and tools allowed more developers to pile on to projects and enhance their efficiency. Current Open Source developers stand on the shoulders of the giants who came before.

Proprietary Hierarchies

But how can communities compete with hierarchical environments? Critically, a set of best practices developed over time. Lost in history are the thousands of poorly run Open Source projects that did not handle their communities well: projects torn apart by nasty mailing list exchanges, projects whose leaders did not respond in a timely manner to contributions, projects that developed an inner sanctum mentality and stopped attracting new developers. Successful Open Source projects today share a number of healthy behaviors, which translate well to InnerSource and will be covered in this book.

InnerSource has to compete with hierarchical and closed development models, and there are certainly traits in those models that appeal to hierarchical organizations:

• Managers like to know who is responsible for a given task or deadline, a mentality associated with the distasteful phrase “one throat to choke.” The adversarial competitiveness denoted by that phrase contrasts strongly with the ethos of Open Source and InnerSource. Managers’ comfort with that situation is illusory: placing the responsibility on one team leader, or even one team, does not guarantee that goals will be met.

• Resources are easier to plan and distribute when work is assigned to a single team with a known set of developers. But this simplicity is also illusory, because schedules in software development are notoriously unreliable.

• Small, geographically colocated teams can be astonishingly efficient. However, they can also lack diversity and develop groupthink. In the long run, software projects can suffer because end users were not sufficiently represented during design decisions, and because the tacit knowledge within the team gets lost over time, disrupting maintenance.

• If software is developed to be licensed and monetized, it’s tempting to define the investment and compare it to the expected income. But because of unanticipated changes of direction, results may be disappointing.

This review of corporate practices leads to a more general look at the research into knowledge workers, economic motivators, and innovation. Although the literature in these areas is huge, we can pick out a few common themes:

• Creative people like to feel in control and empowered to experiment. InnerSource gives them free rein while ensuring their work meets corporate standards before going into the product.

• Beyond a basic salary and set of benefits, intrinsic motivations drive more innovation and participation than extrinsic ones.⁴ The chance provided by InnerSource to see one’s idea adopted, and the ability to work directly on a project that matters, are powerful incentives to positive behavior among contributors.

• Diverse teams produce more useful products that meet a greater range of needs.⁵ This diversity includes demographic considerations (race, nationality, gender, etc.) as well as diverse viewpoints and experiences. Open Source and InnerSource maximize diversity, although project managers must consciously aim for it and take steps to nurture diverse participants.

The Open Source Way

What makes Open Source software development different? Initially, of course, the difference came from the sheer topology of the teams. Asynchronous collaboration over the internet ran in direct opposition to the then-recommended optimal way to build software. This sort of peer-based massive collaboration relies on the complete transparency of both the actual code and the project’s governance. This transparency is important to several aspects of Open Source: it allows people donating work to see how their donation is governed, it allows self-selection of tasks and self-organization of developers, and it allows work to be distributed globally in an asynchronous fashion, constructed holistically.

Open Source also promotes higher quality code, since transparent code and processes open every line up to wider review than is practical within a single proprietary team. This massive peer review has famously given rise to Linus’s law, coined by Eric Raymond, “given enough eyeballs, all bugs are shallow,” meaning that defects are fixed more readily in Open Source because more people can read the code and come up with a broader array of possible fixes. In other words, with a sufficiently large workforce, there is bound to be someone who knows the solution for a given defect. This is not a perfect guarantee, of course. The famous Heartbleed Bug, which remained in the Open Source OpenSSL security library for years, showed that subtle issues can be missed by the community.

As work on an Open Source project progresses, a natural meritocracy emerges. The best contributors are given more responsibility for the running of the project. They are rewarded for excellent technical contributions, but also for taking time to mentor new contributors. Open Source communities are increasingly paying attention to the tone of mentor interactions, seeking to increase civility to be as welcoming as possible to the largest pool of contributors. For the same reason, communities are taking documentation more seriously. Traditionally a separate, labor-intensive effort (and therefore relegated to an afterthought), it now emerges semi-spontaneously as Open Source projects archive communications between mentor and mentee. In fact, all project-related communication is collected, indexed, and archived, creating de facto documentation that allows rapid onboarding of new contributors.

Another difference between Open Source and traditional methods of software development is “mission attachment,” held in common by a majority of the participants. This is partly nurtured by the idealistic philosophy of “free software,” which pins itself on ensuring “code freedom” so that contributed code is perpetually available to the whole community to use, modify, distribute, and deploy. These “4 Freedoms” first recognized the value of freedom in code, but other contributions are also recognized. Ideally, nontechnical contributions such as cleaning up documentation count as well in the meritocracy. The 4 Freedoms also allow contributors to “fork” the project, cloning a complete copy so that the person initiating the fork can make modifications as desired. This is a failsafe measure to protect contributors from misuse of their contributions—they can always fork and start a new project if they disagree with the direction of the original project to which they contributed. This is what has happened, for example, to the OpenOffice.org project, which led to the LibreOffice fork of the project and the community.

The concept of Enlightened Self-Interest must be introduced to explain the motivations behind Open Source development. This is the idea that all participants are ultimately motivated not only by altruism, but also by personal needs to get something specific done—what Raymond characterized as “scratching an itch.” Many well-known Open Source projects started out because of the creators’ personal “itches”: Larry Wall had to create reports but wasn’t quite happy with the tools available to him, which included C, Awk, and the Bash shell, and so he created Perl. Linus Torvalds created the Linux kernel simply because no Unix implementation was available for his 80386 machine (see Open Sources by O’Reilly⁶ for a more detailed history). These motivations to start projects can be personal needs, but projects may also be driven by other types of motivations, such as curiosity, the directives of an employer, or the desire to increase personal reputation.

Why Does Open Source Development Succeed?

While a detailed explanation of why Open Source development succeeds is beyond the scope of this chapter, Open Source software development seems to have found solutions to some of the long-standing challenges in the software industry: notably developer motivation and timing.

A key challenge of large software development projects is coordination: how can large Open Source communities deliver complex products such as the Linux operating system without project plans, requirements documents, and a large number of managers who would ensure that the necessary work gets done?

The answer is of course not straightforward, but a number of key factors play a role. For starters, when Linux was first announced, it attracted many other volunteer developers who were also interested in getting a Unix clone on their personal computers. Developers are motivated for several reasons: they have a sincere interest, they may use coding as a form of learning (which seemed to be Torvalds’s original motivation), or they simply enjoy contributing. In any case, the motivation to contribute is reinforced by the sense of achievement engendered when contributions are adopted and used by others. This level of involvement is not something that you would typically find on a commercial software development project—hired developers are told what software to develop, and while this doesn’t mean they can’t enjoy their work, it is unlikely that developers are passionate about all the software they are developing.

A second factor that facilitates the implicit coordination found in large projects is modular design, or what Tim O’Reilly has called the “Architecture of Participation.”⁷ Modularity refers to the level of independence of different subsystems. For example, the Linux kernel comprises several different subsystems, and furthermore there is a clear distinction (inherited from Unix) between the kernel and external drivers that communicate with hardware. Modularity enables a large number of people to work on different subsystems without getting in each other’s way. Having good tool support (e.g., configuration management tools and version control systems) is of course important too.

Traditionally software development projects commonly face the famous three-way tension between delivering high-quality software in a timely fashion and within budget. Open Source projects tend to deal with this tension in a different way.

Open Source projects have a strong emphasis on quality, for several reasons. Open Source projects generally rely on rigorous peer review. And while Open Source projects increasingly see contributions from firm-employed developers, many traditional volunteer developers are intrinsically motivated and take pride in their code—they won’t take shortcuts so that they can deliver more quickly. Whereas commercial software development projects usually have a delivery date—either announced to the market, or agreed with a paying customer—Open Source projects often don’t have a deadline. Because there is no paying customer, it is far easier to simply delay a release if developers aren’t quite satisfied with the quality, although such delays may affect the project’s credibility if that happens too often. Indeed, Linus Torvalds has delayed releases of the Linux kernel when he wasn’t confident the code was sufficiently stable.

Frederick Brooks describes in his famous essay “No Silver Bullet” that adding more staff to a project that is already late will make it later—this has been coined Brooks’s law.⁸ The explanation for this is that adding more people to a project adds significant communication overhead. The induction of new staff will effectively delay the current project team in getting the project finished in time. In Open Source software projects this isn’t so much of an issue, because much of the discussion and information about design decisions is captured online. Granted, not all Open Source projects succeed in capturing this well, and when the amount of information exchange becomes too large, it should be formalized in well-structured documentation to summarize the essence. But due to the dispersed nature of the community, developers are more independent and forced to figure things out on their own.

We can now turn to the big question: can we borrow the best practices of Open Source to solve the challenges of software development in industry? This idea was suggested about 20 years ago, and is called InnerSource.

What Is InnerSource?

InnerSource is, simply, the use of Open Source principles and practices inside proprietary organizations. InnerSource empowers individual engineers to contribute code from within their team to another team in order to speed up the process of adding functionality (features) or fixing defects. InnerSource also democratizes development and control over the direction of the project by encouraging pull requests over feature requests. The traditional development practice put all decision making and control in the hands of a single team that maintained the code, who were petitioned by users to add enhancements through feature requests. In contrast, with Open Source and InnerSource, anyone who wants to make a change downloads his or her own version of the code through a pull request (a term popularized by the prevailing code management system GitHub), adds the desired feature, and submits the code for approval.

Mirroring the Open Source approach, submitted contributions are reviewed by someone sufficiently knowledgeable to determine whether the submission is ready to integrate into the master codebase, and to guide the contributor to make any necessary changes. This process of review and providing guidance is preferably done in writing so that the exchange of information can be indexed into a persistent, searchable archive, supporting the desired Open Source attribute of lazy accretion of actionable documentation.

Companies adopt InnerSource in different ways. Vijay Gurbani and his colleagues⁹ described a simple taxonomy that distinguished two different modes of adoption:

Project-specific InnerSource

A dedicated team has responsibility for a particular software asset, typically something that is a key asset to the business (as opposed to simply a development tool, for example). The dedicated team is funded by other business units.

Infrastructure-based InnerSource

In this model, the organization provides the necessary infrastructure for storing and sharing source code and documentation, and to facilitate communication. Anybody can create a new project, but each project initiator is responsible for maintaining their projects. This means that the level of support that a user can expect will vary greatly.

This taxonomy is useful because it established some basic terminology that we can use when we discuss InnerSource programs.

It’s also useful to briefly discuss what InnerSource is not. InnerSource is not simply adopting GitHub or GitLab within your organization and arguing that all source code is now transparent. While tooling is important, it’s only an enabler and not a guarantee for success. Also, InnerSource does not mean paying your developers to work on Open Source projects: that’s simply sponsoring Open Source development. When you release the source code you’re working on to the public with an Open Source license, it’s not InnerSource.

InnerSource is also not a development method like Rapid Application Development (RAD) or Scrum, which defines a number of roles (e.g., Scrum Master), ceremonies (e.g., the daily standup), and artifacts (e.g., the sprint backlog). No fixed set of “roles” and “ceremonies” constitute InnerSource.

Instead, InnerSource represents a different philosophy for developing software in-house, which can complement existing methods such as Scrum. Rather than simply adopting new tools and practices per se, InnerSource involves changing the philosophy of working and of leveraging and empowering the developers within your organization. Because every organization is different, there is no single recipe to adopt InnerSource, and that’s what makes it so hard!

A History of InnerSource

The term “Inner Source” was originally coined by Tim O’Reilly in 2000.¹⁰ At the time, O’Reilly served on the Board of Directors of CollabNet, a company he co-founded with Apache Software Foundation cofounder Brian Behlendorf and Bill Portelli in 1999. CollabNet’s mission “is to bring Open Source–style collaborative development to the software industry as a whole.” As such, CollabNet was the first company that helped its customers to engage strategically with Open Source software, and among its first customers were Hewlett-Packard¹¹ and Philips,¹² both of which implemented InnerSource programs.

It’s vital to have an appreciation for how important tooling was back in those days. Although software version control systems were already widely used in industry in the 1990s, there was a confusing array of systems, both Open Source and commercial. Among the commercial offerings were ClearCase and Rational, and Open Source solutions included CVS and Subversion (SVN). (Git’s first release was in 2005, and GitHub, the company that made Git available to the masses, was only founded in 2008.) When the first InnerSource programs were started, the diversity of version control systems was far more prevalent than today. This variety in tools was, to use Frederick Brooks’s terminology, an “accidental” complexity of software development rather than an “essential” complexity.¹³ Difficulties arising from tooling are not inherent to software development, but they can represent major challenges to software teams.

Though the term “Inner Source” was coined by a single person, different organizations that started InnerSource programs in the early 2000s did so independently. As such, different organizations used different terms.¹⁴ Hewlett-Packard used an umbrella term “Progressive Open Source” within which “Inner Source” refers to one approach; the program at Bell Labs has been named “Corporate Open Source,” and other terms in use included “Internal Open Source” or “Community Source,” although those names were also used to describe variants of Open Source practiced publicly by proprietary organizations that were mostly unsuccessful.

These early visionary individuals, teams, and companies were the first ones to adopt InnerSource. However, InnerSource did not attract attention from the wider software industry immediately. Younger companies, particularly ones founded in the “Internet Age”—Google and Facebook are the archetypal examples—were of course more agile and were already familiar with “The Open Source Way.” Other organizations, however, were not paying attention to this trend, and so the adoption of the “InnerSource paradigm” was quite limited until after the triumph of Open Source in the marketplace.

Why Do Companies Adopt InnerSource?

There are many reasons why companies adopt InnerSource.¹⁵ Here we discuss some of the most important ones.

Breaking Down Silos and Bottlenecks

Perhaps the most important motivation to adopt InnerSource is to break down the silos that inevitably exist in large organizations that have optimized at some point for specialization or ownership culture. Partly this is explained by Conway’s law, which states that organizations tend to build systems that are structured according to the organization’s communication structures.¹⁶ Having different teams take ownership of a specific component with a well-defined interface makes a lot of sense, as long as the interface is respected by both the implementer of the component and its users. After an interface is defined, communication between different teams can be minimized, leading to a high level of specialization within those organizational units. The very existence of hierarchy and different organizational units usually leads to an “us versus them” attitude, for several reasons:

Local optimization

Mid-level managers who are responsible for a team tend to be concerned mostly with the performance of their team, because ultimately that is considered to reflect their performance as managers. This is a clear example of “local optimization,” rather than optimizing for the company as a whole. Consequently, there is no direct motivation for these managers to help other teams.

Not invented here

The “not invented here” syndrome seems to be a fixture of the software engineering profession, to the point that many professionals are suspicious of the quality and maintainability of any software they didn’t personally write.

Developer incentives

Engineers who have in the past been measured and rewarded solely on their individual coding skill and speed are often reluctant to spend time reviewing others’ code.

Developer priesthood

A division into units and teams inevitably leads to a high degree of specialization. Engineers who work on their specific product or component have a deep understanding of their code, including its function, form, glitches, and shortcomings. They know the rationale for why the software is the way it is. Outsiders tend to lack that, which may lead to misunderstandings and disagreements.

Perceived job security

Finally, the software engineering industry has long been plagued by practitioners who believe that hoarding expertise is the only job security.

All of these impediments must be mitigated for InnerSource to effectively reduce bottlenecks, and to improve collaboration across an organization.

Reuse

An important reason to adopt InnerSource is to increase reuse, which software engineering researchers and professionals have long considered the Holy Grail of software engineering. After all, constructing software is a lot faster when you can reuse already-extant high-quality components developed elsewhere in your organization. A key barrier to reuse, of course, is the lack of transparency that simply leaves developers unaware of other potentially similar efforts within your organization. The increased level of transparency that InnerSource provides takes away at least this barrier. Another issue is that available components tend to have slightly different use cases, or different features from the ones required in other teams. Again, the transparency offered by InnerSource can help here, by enabling and facilitating closer collaboration between a component’s “owner” and its users. For example, teams might suggest—and help implement—additional features, or rearchitect an existing component in collaboration with its owner. Sure, this is easier said than done, and other things will have to be put into place, in particular organizational commitment at the highest level manifested as time and budget.

Knowledge Sharing and Full Stack Teams

Specialization and ownership culture both drive the creation of silos of knowledge. Over time, cross-silo knowledge can be lost within an organization, which can be damaging if you need to quickly mobilize resources to another area of the stack (onboarding can be difficult). Best practices, such as establishing an effective DevOps practice, assume that at least some full-stack or cross-platform experts exist to take a holistic view when considering sweeping changes. Once full-stack knowledge has been lost to a specialization and ownership culture, it can be difficult to stimulate regrowth. InnerSource mentoring and extrinsic rewards can begin to break down silos and reward cross-stack collaboration.

Innovation

At least one very large organization originally implemented InnerSource to help break down barriers to innovation. In very regimented organizations, thinking innovatively may have been intentionally suppressed until it is effectively extinguished. Giving engineers who were previously closely managed a measure of autonomy, emotional safety, and the sanctions to pursue unorthodox hunches via InnerSource methods can unleash their innovative creativity in productive ways while protecting production outcomes through applied mentorship and review. Sun Microsystems’ Cofounder and Chief Scientist Bill Joy famously had the insight that “no matter who you are, most of the smartest people work for someone else.”¹⁷ This is true within a company, as well, and allowing input from outside your silo can really open your eyes to new possibilities.

Improving Quality

As previously mentioned, the effect of Open Source on the quality of the resulting software has been summarized as Linus’s law, which talks about increasing the resources brought to bear for code review. But the mere awareness that code will potentially be reviewed by a large number of strangers has the effect of causing us to strive to put our best foot forward, because nobody wants public humiliation. It has been well documented that Open Source developers tend to be more careful when developing code they will post for the world to see. Another Open Source maxim, “release [code] early, release often,” means important defects that could negatively affect an entire project, such as security holes, are generally discovered and patched much more rapidly than in proprietary settings.

Staff Mobility and Process Standardization

Most InnerSource implementations assume transparent code hosting using a distributed development platform such as GitHub Enterprise, Bitbucket, Mercurial, or the like. That standardization of tooling reaps an inherent benefit of making it quite a bit easier to onboard new hires or transferred employees. Recruitment and onboarding are both easier because the development environment and processes, such as the review cycle and merge and deploy protocols, are now much more standardized within the organization.

InnerSource Today

The role of software has become much more important for many organizations that have not traditionally developed software. For example, software is transforming sectors where software did not loom large originally, such as the automotive sector: the amount of software in cars has risen exponentially in recent decades, and this trend is likely to continue. So, organizations outside the software industry now also find themselves in a position where they have to deliver complex and innovative software of high quality and within budget. These organizations that are new to software are now eagerly looking for new approaches that can help them overcome the bottlenecks found in traditional development approaches.

The limited attention for InnerSource changed in recent years. In 2014, one of us (Danese) was hired by PayPal to head the company’s Open Source programs. She quickly came to the conclusion that PayPal would benefit greatly from an InnerSource practice. In 2015 she gave an influential keynote at the annual OSCON conference stating her conclusion that InnerSource would be an important practice going forward as more organizations undertake work to modernize their engineering practices in the direction of Open Source. In that talk, she also announced the creation of the InnerSource Commons, an industry group that seeks to bring together like-minded professionals who are interested in implementing InnerSource.

Since then, we have seen a significant increase in interest and momentum. To establish the community, we started a Slack channel that now (mid-2018) counts over 270 individuals representing over 70 different companies—and these numbers are growing fast. Twice a year, the InnerSource Commons community organizes a Summit during which attendants share their knowledge and experiences. The community follows the Chatham House Rule, which states:

When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.

PayPal also sponsored the publication of two booklets with O’Reilly. The first one is a brief introduction, titled Getting Started with InnerSource, authored by Andy Oram. The second one, by Silona Bonewald, also currently employed by PayPal, is titled Understanding the InnerSource Checklist, in which Bonewald presents a checklist of preconditions that must be in place before organizations can adopt InnerSource successfully.

A dedicated team within the InnerSource Commons community has also started to document the various lessons learned and has adopted the concept of “patterns” to encode this knowledge. Ultimately, our goal is to develop an InnerSource pattern language. The work on distilling patterns is an ongoing activity, and this “patterns subcommittee” is actively disseminating its work in various ways, including webinars, videos, and papers.¹⁸

Why We Wrote This Book

Our work with the InnerSource Commons community has taught us that there is broad interest in a collection of case studies that both illuminate the motivations of organizations on their InnerSource journey and justify experimentation with InnerSource as a practice. Many individuals have told us they are seeking permission to start InnerSource experiments at their places of work, but they need persuasive examples. Others have already begun experimenting but aren’t sure how to plan for scaling out the practice across the organization or how to measure success and justify broader adoption. Still others are unsure how to get started.

In order to get InnerSource to flourish inside an organization, you must first understand what aspects of the existing culture stand in the way of transparent collaboration and acceptance of contributions from outside a team. Some common cultural impediments to InnerSource include (but are not limited to):

• A general fear of change

• The “not invented here” syndrome

• A belief that developers external to a team are less skilled or will submit defect-ridden code

• A lack of sufficient time or resources to get existing work done

• An unwillingness to engage in mentorship, or lack of knowledge on how to be a mentor

• Mid-managerial conflict over the team’s charter

These existing cultural forces will vary per organization, and even per business unit or team. Identifying and providing extrinsic motivators to change away from deeply ingrained beliefs and behaviors can be tricky (but necessary).

With so many people and companies interested in this topic, we feel the time is ripe to present a set of interesting case studies of InnerSource in practice. Because each case of InnerSource differs from the next, together these cases represent many different experiences in different contexts. This can be very useful to other individuals and companies who want to learn what other companies have done. Furthermore, while each chapter presents a rich description of one specific case study, we also think that you, the reader, may want to get some support in starting off in your own organization. So we’ve included a chapter with practical tips for crafting your first experiment.

Who Should Read This Book

This book targets professionals at all levels. For executive managers, this book presents convincing evidence (we believe!) that InnerSource is the way to develop software in the future. Yes, InnerSource adoption will cost resources: you need to make available some budget to roll out InnerSource and provide support to the people on the ground. But, we ask you to see this as a long-term investment. No community has ever ramped up within a short time. Things like learning to collaborate and building trust take time. Additionally, money alone isn’t enough: InnerSource is not a product or service that you simply purchase; hiring a consultant alone is not enough. You need to identify and support the “change agents” that make things happen—these are the champions you’ll need to evangelize and talk to the naysayers. Remember, ultimately InnerSource is about empowering people, and Good Things will happen.

For mid-level managers, we hope this book provides inspiring stories that encourage you to revisit your responsibilities as a team manager. We’re not saying to take on more responsibilities, but instead to redefine them. Rather than optimizing for the team you’re responsible for, we’ll try to convince you that supporting your developers to participate in an InnerSource initiative is ultimately a Good Thing. Obviously, we also recognize that you as a manager will need to get the means and resources, and therefore we also wrote this book for your bosses.

For developers, we think this book is interesting because it tells the stories of so many other developers, who also don’t have decision-making powers, and who increased their productivity, their happiness, and the ability to use their creativity. As we’ve already pointed out, InnerSource is about empowering people, and ultimately this means developers and users of software. The various case studies in this book illustrate how individual developers were empowered, how they increased their job satisfaction, and how they overcame the various challenges that resulted of lacking any decision-making power. For developers, initiating an InnerSource program that gets full management support is not trivial, but we hope the stories in this book provide some inspiration. Furthermore, InnerSource gives companies a taste of the benefits of Open Source, which has become an essential part of the software engineering ecosystem that can’t be ignored. InnerSource offers an internal training ground for companies on the way to a full Open Source investment, either by joining existing Open Source foundations or by open-sourcing their own assets.

Finally, as the first dedicated book on InnerSource, we believe it will be of interest to software engineering students and academics who study software development methods and tools. As we mentioned before, we consider InnerSource to be the future of software development, and as such we think students should learn about it, just like they learn about traditional and agile methods. For researchers, we believe this book is useful because it compiles a series of detailed case studies of InnerSource.

How This Book Is Organized

This book tells the stories of several companies that have started the journey to adopt InnerSource. As we mentioned, InnerSource is not a defined development method or framework, such as Scrum. Instead, it’s a development paradigm, and each instance is unique and tailored to the specific context of the organization.

InnerSource often refers to the “Open Source development paradigm”—and in particular we refer to “The Apache Way.” In Chapter 2, Jim Jagielski, cofounder and director of the Apache Software Foundation (ASF), discusses InnerSource and introduces “The Apache Way.”

Chapter 3 presents one of the early cases of InnerSource. It describes the Session Initiation Protocol (SIP) stack project at Bell Laboratories, which was part of Lucent Technologies at the time the project originated 20 years ago. This chapter, contributed by the project’s “Benevolent Dictator for Life” (BDFL) Vijay K. Gurbani, and his co-authors James D. Herbsleb and Anita Garvert, describes the origins, motivations, and evolution of the project.

In Chapter 4, Georg Grütter, Diogo Fregonese, and Jason Zink present the InnerSource initiative at Robert Bosch GmbH, or “Bosch” for short. Bosch is a large German company that operates in many different domains, including the automotive sector and consumer electronics. Bosch started the Bosch Internal Open Source (BIOS) program around 2009 within a specific R&D setting.

Chapter 5 presents a case at PayPal, which started adopting InnerSource back in 2014 when the company hired Danese Cooper as Director of Open Source. PayPal has run a number of InnerSource experiments to evaluate process improvements. In 2016 PayPal’s InnerSource Team ran a large experiment to determine whether an InnerSource mandate would work on a core component where the teams had previously been reluctant to do InnerSource. In that same year, a small grassroots InnerSource experiment quietly launched and ran itself out of PayPal’s Chennai office. The two cases confirmed each other’s findings.

In Chapter 6, Isabel Drost-Fromm presents the journey of Europace toward InnerSource. Europace is a medium-sized company in the financial sector that was searching for new ways to become more self-organizing.

Chapter 7 presents the case of Ericsson, a global leader in the telecommunications domain. John Landy discusses his experiences and lessons learned with setting up the Community Developed Software (CDS) program. The case presents a greenfield development project, in which Ericsson adopted a platform-based architecture, but without the corresponding platform organization. The key reason for doing so is that platform teams tend to become bottlenecks, as feature teams make a large number of feature requests.

Finally, after reading these exciting cases, we hope you feel sufficiently inspired to try InnerSource in your own company. For that reason, we lay out a set of guidelines for adopting InnerSource in Chapter 8. Based on the recurring patterns that we observe in the case studies, we offer advice about how to choose and structure your first InnerSource experiment.

Visit Us Online

On this book’s website you’ll find much more information. We’d also very much like to hear from you—any suggestions, feedback, or comments are welcome. We hope you enjoy reading this book as much as we enjoyed writing it!

Acknowledgments

This book isn’t just the result of a couple of months of writing. Klaas has conducted research in this domain for about 10 years, during which his research has been kindly supported by the Irish Research Council (under IRCSET grant RS/2008/134 and New Foundations grants in 2013 and 2014) and Science Foundation Ireland (grant 15/SIRG/3293 and 13/RC/2094 to Lero—the Irish Software Research Centre), allowing him to travel across the globe to visit many companies for his field research. The insights gained from these field trips have been foundational for this book.

¹ Winston W. Royce, “Managing the Development of Large Software Systems,” Proceedings of IEEE WESCON (August 1970): 1–9. Reprinted in the Proceedings of the International Conference on Software Engineering, 1987.

² Eric S. Raymond, The Cathedral and the Bazaar (Sebastopol: O’Reilly Media, 1999).

³ Yochai Benkler, Wealth of Networks (New Haven: Yale University Press, 2007).

⁴ Rachel Mendelowitz, “Here’s What So Many Leaders Get Wrong about Motivating Employees,” Fortune, July 3, 2016, http://fortune.com/2016/07/03/leaders-motivate-employees-business/.

⁵ David Rock and Heidi Grant, “Why Diverse Teams Are Smarter,” Harvard Business Review, November 4, 2016, https://hbr.org/2016/11/why-diverse-teams-are-smarter.

⁶ Chris DiBona and Sam Ockman, Open Sources: Voices from the Open Source Revolution (Sebastopol: O’Reilly Media, 1999).

⁷ Tim O’Reilly, “The Open Source Paradigm Shift,” in Perspectives on Free and Open Source Software, eds. Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani (Cambridge: MIT Press, 2005).

⁸ Frederick P. Brooks Jr., “No Silver Bullet – Essence and Accident in Software Engineering,” Proceedings of the IFIP Tenth World Computing Conference (1986): 1069–1076.

⁹ Vijay K. Gurbani, Anita Garvert, and James D. Herbsleb, “Managing a Corporate Open Source Software Asset,” Communications of the ACM 53, no. 2 (2010): 155–159, https://doi.org/10.1145/1646353.1646392.

¹⁰ The term “Inner Source” was coined in a response to Matt Feinstein’s question on O’Reilly’s attitude on Open Source and OpenGL. The original response is available online. To make the term easier to find (try searching for “inner source” and you’ll find references that are not software related), we’ve removed the space in between and adopted “camel case” capitalization.

¹¹ HP’s program is documented in a paper by Jamie Dinkelacker, Pankaj Garg, Rob Miller, and Dean Nelson, “Progressive Open Source,” Proceedings of the 24th International Conference on Software Engineering (2002): 177–184.

¹² Philips’s program is documented in an article by Jacco Wesselius, “The Bazaar Inside the Cathedral: Business Models for Internal Markets,” IEEE Software 25, no. 3 (2009): 60–66.

¹³ See Frederick Brooks’s essay, “No Silver Bullet: Essence and Accidents of Software Engineering.”

¹⁴ Klaas-Jan Stol, Paris Avgeriou, Muhammad Ali Babar, Yan Lucas, and Brian Fitzgerald, “Key Factors for Adopting Inner Source,” ACM Transactions on Software Engineering and Methodology 23, no. 2 (2014).

¹⁵ Klaas-Jan Stol and Brian Fitzgerald, “Inner Source—Adopting Open Source Development Practices within Organizations: A Tutorial,” IEEE Software 32, no. 2 (2015): 55–63.

¹⁶ Melvin Conway, “How Do Committees Invent?” Datamation 14, no. 4 (April 1968): 28–31.

¹⁷ See the Wikipedia entry on Joy’s law.

¹⁸ Erin Bank et al., “InnerSource Patterns for Collaboration,” Proceedings of the 24th Conference on Pattern Languages of Programs, 2017.