www.dbooks.org

Andy Oram

Getting Started withInnerSource

www.dbooks.org

978-1-491-93758-7

[LSI]

Getting Started with InnerSourceby Andy Oram

Copyright © 2015 O’Reilly Media, Inc. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA95472.

O’Reilly books may be purchased for educational, business, or sales promotional use.Online editions are also available for most titles (http://safaribooksonline.com). Formore information, contact our corporate/institutional sales department:800-998-9938 or corporate@oreilly.com.

Editor: Nan BarberCopyeditor: Holly Bauer

Interior Designer: David FutatoCover Designer: Randy Comer

July 2015: First Edition

Revision History for the First Edition2015-07-22: First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Getting Startedwith InnerSource and related trade dress are trademarks of O’Reilly Media, Inc.

While the publisher and the author have used good faith efforts to ensure that theinformation and instructions contained in this work are accurate, the publisher andthe author disclaim all responsibility for errors or omissions, including without limi‐tation responsibility for damages resulting from the use of or reliance on this work.Use of the information and instructions contained in this work is at your own risk. Ifany code samples or other technology this work contains or describes is subject toopen source licenses or the intellectual property rights of others, it is your responsi‐bility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents

A Robust Approach to Team Collaboration. . . . . . . . . . . . . . . . . . . . . . . 7Where Open Source Principles Work 9How PayPal Adopted InnerSource 13

v

www.dbooks.org

A Robust Approach to TeamCollaboration

Inspired by the spread of open source software throughout the areasof operating systems, cloud computing, JavaScript frameworks, andelsewhere, a number of companies are mimicking the practices ofthe powerful open source movement to create an internal companycollaboration under the rubric InnerSource. In these pages, you’llread about the experience of the leading Internet commerce facilita‐tor PayPal and see how InnerSource can benefit engineers, manage‐ment, and marketing/PR departments.

To understand the appeal of InnerSource project management, con‐sider what has made open source software development so success‐ful:

• Programmers share their work with a wide audience, instead ofjust with a manager or team. In most open source projects, any‐one in the world is free to view the code, comment on it, learnnew skills by examining it, and submit changes that they thinkwill improve it or customize it to their needs.

• New code repositories (branches) based on the project can bemade freely, so that sites with unanticipated uses for the codecan adapt it. There are usually rules and technical support forremerging different branches into the original master branch.

• People at large geographical distances, at separate times, canwork on the same code or contribute different files of code tothe same project.

• Communication tends to be written and posted to public sitesinstead of shared informally by word of mouth, which provides

7

www.dbooks.org

a history of the project as well as learning opportunities for newproject members.

• Writing unit tests becomes a key programming task. A “unittest” is a small test that checks for a particular, isolated behaviorsuch as rejecting incorrect input or taking the proper branchunder certain conditions. In open source and InnerSource, test‐ing is done constantly as changes are checked in, to protectagainst failures during production runs.

InnerSource differs from classic open source by remaining withinthe view and control of a single organization. The “openness” of theproject extends across many teams within the organization. Thisallows the organization to embed differentiating trade secrets intothe code without fear that they will be revealed to outsiders, whilebenefitting from the creativity and diverse perspectives contributedby people throughout the organization.

Often, the organization chooses to share parts of an InnerSourceproject with the public, effectively turning them into open source.When the technologies and management practices of open sourceare used internally, moving the project into a public arena becomesmuch easier.

Advantages of adopting an InnerSource strategy include:

• Code reuse across the organization grows immensely. Program‐mers from each team can understand the code and architectureof modules developed by other teams, and contribute code.

• This cross-team collaboration becomes relatively frictionless.Contributed code rarely has to be rewritten by the team receiv‐ing it, and no discussions are required at a high managementlevel.

• Development becomes faster as programmers learn to use unittests, code coverage, and continuous integration to remove bugsat an early stage of development. The written commentsexchanged among team members, although taking up sometime, more than pay for themselves by helping new program‐mers learn the system faster.

• Programmers learn to document their code better, both for‐mally (as in-code comments and documentation) and infor‐mally (on discussion lists). The documentation provides a his‐

8 | A Robust Approach to Team Collaboration

tory of the project, and helps outsiders understand it so thatmore can contribute to it.

Where Open Source Principles WorkBefore thinking about what InnerSource could accomplish for yourorganization, it’s important to consider where the source of thesepractices—the free and open source software movement—has beenfound to work well, and where it has historically been less success‐ful.

Cross-Organizational CollaborationOpen source software development crosses the boundaries of teams,companies, and nations, letting individuals around the world collab‐orate on such major computing advances as Linux and Apache. Thestereotype of scruffy hackers creating code in a basement some‐where is outdated (if it was ever relevant): the major contributors tocentral open source projects such as Linux now work for major cor‐porations.

A lot of important open source projects start out as the brainchil‐dren of independent programmers, but they are frequently adoptedby large companies. In other cases, open source projects emergefrom within such companies, including PayPal. What remains cru‐cial to their open source success is that people inside any singleorganization allow outsiders to play a major role in developing, test‐ing, documenting, and promoting the software, creating as level aplaying field for all contributors as possible.

The Difference Between Geographically DispersedDevelopment and Agile ProgrammingThe cross-boundary activity of open source contrasts strongly withpopular corporate development approaches, such as Agile andScrum. The latter development methods were explicitly designed forteams working in a single office, communicating face-to-face. Notonly must the developers in such projects work together, but theymust meet with the software users and other stakeholders regularly.All this informal information sharing reduces the need for docu‐mentation and formal requirements. But such development meth‐

Where Open Source Principles Work | 9

www.dbooks.org

1 Stol, KJ, P. Avgeriou et al. “Key Factors for Adopting Inner Source.” ACM Transactionson Software Engineering Methodology (TOSEM) (2014): Vol 23, No 2.

ods don’t work as well in environments larger than a single worksite.

If Agile and Scrum pay a price in scalability, open source develop‐ment pays a price in speed. Open source projects just can’t move asquickly as dedicated teams working in a single office. This priceobviously makes a big difference for start-up ventures with tightdeadlines (sometimes insanely tight deadlines). The difference alsohas a subtle effect on the types of software that are well-suited toeach development model, as you’ll see in “Value for Software Infra‐structure” on page 12.

Despite the limitations on speed of progress, many open sourceprojects keep strict deadlines and have predictable releases. How‐ever, they often sacrifice features for predictability. Some enhance‐ments that are planned for a particular release may have to be post‐poned in order to avoid slipping the deadline.

Agile programming does not have to be the enemy of open sourcedevelopment—in fact, the literature reports teams who combine thetwo.1 But understanding their different requirements and assump‐tions can give you a better understanding of open source.

Continuous Testing and DevelopmentIn general, open source projects maintain quality and trust amongcollaborators by setting up a rigorous system of objectively testingeach contribution. Many open source projects have adopted suchcommonly recommended practices as unit testing and continuousintegration and have developed formal organizational models toensure their use. Open source developers have turned quality con‐trol into a science.

Although test-driven development is not required for open source,unit testing is taken very seriously. Whether or not an open sourceproject maintains a quality assurance team, each programmer isexpected to write unit tests to assure the quality of her own code.Tools and protocols for committing changes require the tests to berun and produce a clean result before the code can be accepted into

10 | A Robust Approach to Team Collaboration

the repository. The process offers assurance not only that the codeworks the way it was promised to work, but that it doesn’t reactbadly with some other piece of code elsewhere in the project.

Modern techniques such as code coverage tools and static analysisare used less often in open source communities, and they’ve beenadopted with dedication at PayPal.

Overall, testing and continuous integration play two importantroles. Foremost, of course, they keep the product from breaking. Butthey also help to identify good coders who can be given greaterresponsibility for the project. For instance, getting a large number ofcommits accepted into the repository is usually a prerequisite togaining the coveted status of a trusted committer. The trusted com‐mitters review and approve other programmers’ work, and canmake changes without needing such approval themselves. They alsoprovide mentorship to promising contributors whose code doesn’tyet meet quality standards.

The Importance of DocumentationAnother tenet of open source development, stemming from the dis‐persion of its practitioners over geography and time, is full docu‐mentation. Open source projects tend to be weak on user documen‐tation (a failing they share with most proprietary projects), but thedevelopers obsessively write for each other about their assumptions,decisions, and implementations.

This practice represents another contrast with Agile programming,which calls for some documentation but generally favors “workingsoftware over documentation” (an oft-quoted clause from the AgileManifesto). It should be noted that working source code is also theplatinum standard in the open source community (as well as stand‐ards bodies dominated by developers), but these communities stillconsider it important to document what has been done.

Every facet of communication in open source software is written.Comments on GitHub are a key driver of many projects. Opensource projects depend on mailing lists for discussions leading to alldecisions, and you often hear, “If it’s not on the mailing list, it didn’thappen.”

One value of documenting decisions and implementation details isthat a history of the project is created for anyone new who wants to

Where Open Source Principles Work | 11

www.dbooks.org

join. Anyone who can take the time to peruse the discussionarchives can pick up the project’s culture and best practices.

Every collaboration assumes that participants share a common lan‐guage. Given the geographic diversity of open source projects, ofcourse, English has become the lingua franca practiced by all pro‐grammers (although there are significant open source projects inother languages as well). Making decisions through written commu‐nication plays a democratizing role here, because more people canlearn to read and write a foreign language than learn to speak it flu‐ently. These people could participate more in open source projectsthan in tightly knit teams using a language they don’t know well.

Value for Software InfrastructureOpen source software has traditionally worked well for lower layersof the software stack: operating systems and hypervisors, tools usedby programmers such as compilers and editors, security software(which benefits from open code reviews to detect weaknesses), andother things tucked away where the end user doesn’t see it.

In contrast, the user interface (UI) has proven stubbornly resistantto open source development. It’s hard to point to an open sourceend-user tool that has achieved mass adoption. Mozilla Firefox is arare example.

Looking back at the contrast between open source and Agile devel‐opment (“The Difference Between Geographically Dispersed Devel‐opment and Agile Programming” on page 9) gives you a clue to thereason for this lack of success. The Agile model has been widelyadopted because it keeps programmers in close contact with users.Developers get user feedback and can start working with it in a mat‐ter of days. Most open source projects involve end users in relativelyold-fashioned ways, such as through alpha and beta releases.

The emphasis on unit testing (“Continuous Testing and Develop‐ment” on page 10) also marks open source as appropriate for infra‐structure. About five years ago, Agile expert Mike Cohn described atest pyramid that puts various layers of infrastructure underneath asmall user interface layer. He mandated unit tests for as many layersof the software as possible, reducing dependence on functional test‐ing.

12 | A Robust Approach to Team Collaboration

The UI layer, by contrast, is very hard to check through unit testing,and these tests show decreasing reliability and value at that layer.Here’s where functional testing enters to check the overall operationof a system and ensure that each action taken by the end user pro‐duces the desired result.

Thus, the testing process that undergirds quality and trust in opensource is weak at the user interface level, which may be another rea‐son that open source tools are less popular at that level.

Finding the Right Level for Open SourceOpen source and free software has traditionally been contrastedwith proprietary software (especially Microsoft Windows and theOracle database). A more common approach to proprietary devel‐opment nowadays is software as a service (SaaS). With this softwaredelivery model, you can use the guidelines in this section to deter‐mine what should be developed in an InnerSource or open sourcemanner, and what to do in a more closed manner using Agile orsome other team-oriented methodology.

Lots of companies mix these models. Such companies could becalled "closed core,” because they keep the software critical to theirbusiness behind SaaS, but freely share infrastructure software. Thisarrangement benefits the wider programming community, makes iteasier to recruit and train employees, and brings them the benefitsof outside contributions.

How PayPal Adopted InnerSourcePayPal’s path to InnerSource involved a series of historic, large-scalecorporate decisions. It adopted the model as one of several shiftsconsciously made in tools and corporate culture, as is often the case.

In PayPal’s case, the shifts that preceded the adoption of Inner‐Source included:

• A search for technologies that would promote faster develop‐ment (replacing Java with JavaScript and Node.js on manyprojects, for example)

• A consequent interest in a better understanding of the opensource communities and development models tied up in thenewly adopted technologies

How PayPal Adopted InnerSource | 13

www.dbooks.org

• Use of GitHub for collaboration both internally and externally• A heightened concern for quality

PayPal, therefore, adopted some open source technologies and evenopen sourced some of its own code before experimenting with theInnerSource model. Other companies may take the reverse route:they may try out the tools and practices of open source within theirown walls before producing any open source code, although thatroute is generally thought to be more challenging. In either case, afamiliarity with open source tools, along with sites such as GitHubthat facilitate collaboration in an open source manner, is crucial.

Although the various changes at PayPal took place together andclearly had impacts on one another, the next few sections willdescribe each change individually, focusing on each one’s particularactivities.

Starting at the EdgeInnerSource at PayPal started with Regional Sales Engineers, work‐ing outside the United States, who modified user-facing code to sup‐port local usage preferences and sometimes to support regional pro‐motions. These programmers could not get their changes acceptedby the core teams in the timely manner required. Often, thesechanges required the intervention of a VP somewhere to demandthat they be merged in, after which an embattled core engineerwould rewrite the submitted changes before merging them.

At the same time, inadequate documentation was being filled inthrough email exchanges carried out on an urgent basis betweendevelopers on different teams. Although these messages containedvaluable information, they were unseen by most developers. Manyregional organizations independently started efforts to cut and pastethese messages into wikis.

A number of regional engineers were flown to the San Jose head‐quarters to spend a month learning directly from the core teams, butthat method of bootstrapping trusted committers did not spreadknowledge widely enough and was not worth the investment. Nowritten documentation developed from it. After the engineers wentback to their home countries, they were forced by distance to seekcore mentorship through written queries.

14 | A Robust Approach to Team Collaboration

Eventually, it was suggested that InnerSource might be a better wayto go. Teams found that InnerSource really streamlined theirprojects, and the trusted committers on the core side found the pro‐cess much better. Remote engineers could pull code samples fromGitHub.

In addition to learning how to work with regional collaborators bet‐ter, the core teams started to get clues (through their mentorship ofregional contributors) about where to refactor core code to increasemodularity and understandability. They were also able to notice pat‐terns between work done in different regions that allowed them topromote experienced regional engineers as mentors to their peers inother regions.

A Speedier Development ProcessPayPal started life with a relatively monolithic C++ platform.Although some legacy elements are still in C++, new developmentfor a time was done in a more modular fashion using Java Spring.Even after this shift, as developer Jeff Harrell put it, a lot of “tribalknowledge” was embedded in each product. It took several weeks toroll out even a small change, and each new hire required a six-weektraining period.

Three years ago, PayPal made a major shift by adopting Node.js.According to Poornima Venkatakrishnan, a Node.js developer atPayPal, the platform was used there first for prototyping. Happywith the results, developers wanted to deploy it in production. Firstthey tried an experiment where teams developed the same function‐ality side-by-side on the Java Spring platform and on Node.js. Thecompany compared the platforms on the basis of development time,number of lines of code, and number of engineers required fordevelopment. Node.js was an obvious winner.

The announcement that PayPal was adopting Node.js worried manyprogrammers, especially those who remembered the change fromC++ to Java as long and grueling. However, PayPal demonstratedthat the change to Node.js was completely different. It scheduled justtwo days for the transition training. According to Harrell, partici‐pants quickly realized they were entering a new, vibrant, and excit‐ing world. PayPal was also lucky to have on staff a leader in the fieldof JavaScript, Douglas Crockford, to do the training. (Crockford is

How PayPal Adopted InnerSource | 15

www.dbooks.org

the author of a highly popular book, JavaScript: The Good Parts, andcreator of an O’Reilly JavaScript Master Class video.)

Much new PayPal feature development still uses Java, but thoseteams have adopted the InnerSource practices that were pioneeredby the Node.js teams.

Engaging with Open SourceTraining for the move to Node.js was quick and painless, because somuch instructional material was available online and because adop‐tion of the software required less customization than the previousmove to Java. Essentially, two days of training was enough to pre‐pare staff to continue their own learning processes.

According to Harrell, it took some time to convey to PayPal pro‐grammers that they could simply search for basic information onsites such as StackOverflow (or just use a search engine) instead ofasking senior programmers on an internal PayPal mailing list. Buteventually the queries for information broadened into a whole-hearted engagement with open source communities.

Most companies find that adopting open source technologies—which may originally be attractive simply because they’re high qual‐ity and free of charge—leads to a sustained entry into the communi‐ties that produce the technologies.

This happened to PayPal when they adopted Node.js. By now it is apretty mature technology. Some commentators even suggest thatNode.js has passed its peak and that JavaScript programmers arelooking at alternatives. (The pace of change in open source technol‐ogies, as you will see later in this section, alters decision-makingabout which ones to adopt.) But PayPal came in at an early stage,where there was plenty of room to develop useful tools for theNode.js community. PayPal also became a very active member of theNode.js foundation and the ECMAScript Technical Committee 39.

To promote the twin goals of programmer self-education and imme‐diate productivity among new hires, PayPal enthusiastically broughtother popular open source tools along during the move to JavaScriptand Node.js. For instance, Selenium is widely used for testing, Jen‐kins for continuous integration, and such tools as TestNG, JUnit,and Mockito for Java testing. Along the way, PayPal developed andopen sourced a number of tools compatible with the open source

16 | A Robust Approach to Team Collaboration

components, such as Nemo (originally written by Matt Edelman),SeLion, and Illuminator.

Since PayPal adopted Node.js when it was early in development andlacked certain tools, the company developed Kraken, a frameworkfor controlling Node.js architectures. Harrell says the team decidedto develop the framework as open source to make sure it was of gen‐eral value, free from the “tribal” knowledge that Harrell had seen inother PayPal code. Kraken became what is probably their most suc‐cessful open source project.

Venkatakrishnan lists the following open source practices thatentered PayPal at this time:

• Setting high quality standards. Before code is committed, codecoverage tests must run on at least 90% of it. When someonesends a commit, it triggers an automatic rebuild to make sureit’s of sufficient quality to be merged.

• Requiring documentation for all code in the repositories them‐selves.

• Conducting all discussions on GitHub to enable collaborationand to facilitate input from people outside the team. There’s aprivate GitHub repository for in-house projects as well as publicGitHub repositories for open source code.

• Making everyone feel they can innovate.• Teaching engineers that not all expertise needs to come from

one team. With open source software, help can come from any‐where in the world. Also, contributing to public open sourceprojects adds more visibility to the company and shows its com‐mitment to the community.

• Cultivating pride in the work done in teams, encouraging themto speak about it at conferences and write about it in PayPal’sengineering blog.

Harrell points out that the higher one goes in a software stack, themore volatile the technologies are. Change in software developmentis ongoing, especially with open source technologies. So PayPalencourages a team to constantly evaluate their technologies. Contin‐uous learning is expected of each developer.

Inevitably, the evaluation of alternative tools leads to a diversity oftools from one team to another. Developer Matt Edelman points outthat this phenomenon is particularly common in open source,

How PayPal Adopted InnerSource | 17

www.dbooks.org

because developers like to develop tools along the lines suggested byUnix patriarch Ken Thompson: many small programs workingtogether.

Thus, teams use a variety of cutting-edge technologies such as Reactand Angular. Programmers are expected to do a toy project to tryout a tool before recommending it, and to compare alternativescarefully before making a choice.

Open source architectures often feature plug-ins to permit alternateimplementations of technologies that extend their functionality.Edelman says that PayPal develops some Kraken plug-ins internally(through the InnerSource model) and others as open source.

GitHub CollaborationOne company holds a uniquely important place in modern codedevelopment: GitHub. Originally a SaaS platform to make life easierfor developers using the Git version control software, GitHubevolved into a sophisticated collaboration platform with tools thatdevelopers find indispensable. Two resources on this topic includethe book Git for Teams and the Collaborating with Git video.

In addition to putting code for open source projects such as Krakenon GitHub, PayPal has set up an internal GitHub Enterprise reposi‐tory so that programmers within the company can collaborateexactly as public GitHub users do. Code reviews, commits, and teststake place in an open source manner, but on the internal repository.Most crucially, each team gets accustomed to accepting new codefrom PayPal programmers outside the team.

Before the move to GitHub and InnerSource, according to Edelman,PayPal programmers felt competent to contribute only minor bugfixes to another team’s work. If they contributed larger chunks, theteam accepting the code would scrutinize it and often do so muchrewriting that there was little advantage over doing the code fromscratch. High-level managers would often have to get involved tonegotiate the acceptance of code between teams.

These days, substantial new functionality can be checked in with norewriting. One reason is the new focus on documentation. Edelmanstresses that InnerSource projects must rest on a broader program‐ming base than a few privileged programmers who deeply under‐

18 | A Robust Approach to Team Collaboration

stand the system. Anyone can study a project and suggest majorchanges.

Also thanks to documentation (both in the code and the GitHubcomments), developers come to recognize the need for architecturechanges. If you have to explain four times to various people whysomething is complicated and counterintuitive, you start to thinkabout changing it.

Empowering programmers across the country also promotes greaterintellectual growth and job satisfaction. Programmers think morecomprehensively about the design of the code, while learning newskills in doing code reviews, testing, and writing documentation.Edelman says InnerSource “raises everybody’s game.”

Edelman mentions one security-related bug that turned up in thecore infrastructure module. One function wasn’t following the speci‐fication (RFC) precisely. At first a lot of email was exchanged, withpeople outside the infrastructure team pressuring them to do a fix.But then one outsider—for whom security was not a specialty—tooka look at the RFC and realized he could handle the fix himself. Heturned in a fix that worked, and it was quickly merged by the coreinfrastructure team. This anecdote illustrates two principles: theimportance of programmers taking initiative, and the value of fol‐lowing well-documented standards.

Quality ImprovementAt the same time that PayPal was moving large parts of its platformto Node.js and adopting open source practices, it made a commit‐ment to better quality. According to Quality Assurance leader DougSimmons, steps toward this goal at PayPal included:

• More unit testing• Continuous integration• Code reviews• More code coverage reports• Static analysis

Not all conversations have to take place in public, but the commentprocess on GitHub has improved quality in several ways. Trustedcommitters effectively act as mentors for newer programmers hop‐ing to get their code accepted into the repository. The back-and-forth comments between submitters and trusted committers are

How PayPal Adopted InnerSource | 19

www.dbooks.org

2 Ibid.

3 Stol, KJ, AB Muhammad, et al. “A comparative study of challenges in integrating OpenSource Software and Inner Source Software.” Information and Software Technology 53(2011): 1319–1336.

educational for both the submitters and other programmers whocan watch these dialogs and learn from them.

Culture ChangeA corporate move as significant as adopting InnerSource calls forsensitivity in handling employee fears and expectations. PayPalhired outside experts in open source development to aid the transi‐tion.

Observers from many companies seem to agree that the mostimportant cultural change is to give employees the confidence tocontribute code to other teams. Full documentation and good men‐toring can achieve this—but as Edelman points out, staff have tochange their habits from complaining about bugs to going in andmaking fixes.

Harrell remembers persuading team members to let other PayPalprogrammers outside the team make contributions. The team mem‐bers commonly objected that they’d end up spending all their timevetting outside code and not writing their own. In a study ofanother company, programmers worried about the burden that newcontributions would add to future maintenance.2, 3

As you know by now, these drawbacks proved less fearsome thanexpected, because the rigorous testing and build process ensured thequality of contributions. In any case, Harrell told them, vetting con‐tributions required sophisticated skills of its own. And the contribu‐tions multiplied the value of the code created by the team.

Edelman writes, “Module authors are expected to curate their soft‐ware by being open to feedback and changes from the community,while enforcing quality and consistency standards.” He says develop‐ers have evolved from complaining about the task for writing testsor doing code reviews to insisting on them.

In the quality arena, when programmers submit InnerSource bugreports, they go initially to the person who is responsible for the

20 | A Robust Approach to Team Collaboration

module. This programmer may then pass them on to the originalcontributors of the affected code.

Modular architectures and well-defined APIs have also been identi‐fied by many programming teams as crucial to encouraging contri‐butions from outside the team.

Because InnerSource development practices are essentially the mostpopular open source practices, open sourcing a project that wasdeveloped inside the company is fairly easy. Technically, all the teamhas to do is move the code to a public repository and start dealingwith external bug reports and code contributions the way they havebeen dealing with such input from other members of their company.

However, a few legal barriers may stand in the way. If programmersincorporated outside code into the project, the legal departmentmust examine all licenses to ensure they have the right to open thecode and that their license is compatible with the licenses on thecode they incorporated. Some branding review may also beinvolved. At PayPal, the legal team consulted with open sourceexperts and developed a web-based process for going through thenecessary steps.

Modern programmers learn to thrive on change. Aside from newtechnologies and tools, a change of culture can help them stay nim‐ble and keep skills up to date. InnerSource is a step toward all theseachievements.

How PayPal Adopted InnerSource | 21

www.dbooks.org

About the AuthorAndy Oram is an editor at O’Reilly Media. An employee of thecompany since 1992, Andy currently specializes in open sourcetechnologies and software engineering. His work for O’Reillyincludes the first books ever released by a US publisher on Linux,the 2001 title Peer-to-Peer, and the 2007 bestseller Beautiful Code.