Compliments of Adopting InnerSource Principles and Case Studies Danese Cooper & Klaas-Jan Stol with foreword by Tim O’Reilly Adopting InnerSource Principles and Case Studies Danese Cooper and Klaas-Jan Stol Beijing Boston Farnham Sebastopol Tokyo Adopting InnerSource by Danese Cooper and Klaas-Jan Stol Copyright © 2018 O’Reilly Media. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online edi‐ tions are also available for most titles (http://oreilly.com/safari). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Andy Oram Proofreader: Jasmine Kwityn Production Editor: Justin Billing Interior Designer: David Futato Copyeditor: Octal Publishing, Inc. and Charles Cover Designer: Karen Montgomery Roumeliotis Illustrator: Melanie Yarbrough July 2018: First Edition Revision History for the First Edition 2018-06-15: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Adopting InnerSource, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors, and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the informa‐ tion and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation 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. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. This work is part of a collaboration between O’Reilly and PayPal. See our statement of editorial inde‐ pendence. 978-1-492-04183-2 [LSI] Table of Contents Foreword. vii 1. The InnerSource Approach to Innovation and Software Development. 1 Old Patterns of Development: Closed and Slow 1 Factors Driving Open Source 4 Proprietary Hierarchies 4 The Open Source Way 6 What Is InnerSource? 9 Why Do Companies Adopt InnerSource? 12 InnerSource Today 15 Why We Wrote This Book 16 Who Should Read This Book 17 How This Book Is Organized 18 2. The Apache Way and InnerSource. 21 Origins of The Apache Way 21 Fundamentals of The Apache Way 22 3. From Corporate Open Source to InnerSource: A Serendipitous Journey at Bell Laboratories. 29 Background on Internet Protocols for Voice Communication 30 SIP: A Brief Background 32 The Project: The Common SIP Stack (CSS) 34 Reflections, Insights, and Discussion 42 Acknowledgments 45 4. Living in a BIOSphere at Robert Bosch. 47 Why InnerSource 48 Starting the BIOS Journey 48 iii Establishing and Growing the BIOSphere 49 From BIOS to Social Coding 53 Success Stories 55 Success Factors 57 Challenges 59 Lessons Learned 60 Conclusion 62 Acknowledgments 62 5. Checking Out InnerSource at PayPal. 63 A Little Background 64 Attributes of InnerSource 64 The CheckOut Experiment 69 The Onboarding Experiment 71 Executive Air Cover 72 Meanwhile, in India 73 Beginning Symphony and InnerSource Brand Dilution 74 Initial Symphony Training 75 The Contributing.md File 77 Cadence of Check-Ins 78 Outcomes 80 The Rhythm of InnerSource Work 82 The Future of InnerSource at PayPal 83 Acknowledgments 86 6. Borrowing Open Source Practices at Europace. 87 Looking for New Ways of Organizing 88 Starting the Journey Toward InnerSource 89 Steps Toward InnerSource 93 InnerSource Principles 96 InnerSource Challenges 99 Conclusion and Future Outlook 101 Acknowledgments 102 7. Connecting Teams with InnerSource at Ericsson. 103 The Changing Telecommunications Landscape 103 Why InnerSource? 105 Starting the Community Developed Software Program 106 Selecting Components and Development Models 109 Making Collaborations Happen 112 Pillars of Community-Developed Software 113 Success: The User Interface SDK Framework 115 Lessons Learned 115 iv | Table of Contents The Future of InnerSource at Ericsson 117 Acknowledgments 117 8. Adopting InnerSource. 119 Comparison of the Case Studies 120 Guidelines for Adopting InnerSource 129 The InnerSource Commons 137 9. Epilogue. 139 Glossary. 141 Table of Contents | v Foreword Tim O’Reilly I’m told that I coined the term “InnerSource” in 2000, and sure enough there’s a blog post to prove it. I don’t remember writing it. What I do remember is an ear‐ lier conversation, in the summer or fall of 1998, not long after the so-called Open Source Summit in April of that year, to talk to an IBM team that was thinking of embracing this new movement. They were cautious. How might it affect IBM’s business? How would they con‐ tinue to own, control, and profit from their software? What kind of license might they use to get the benefit of user contribution but still manage and control their creations? The GNU Public License seemed hostile to business; the Berkeley Unix and MIT X Window System licenses were permissive but perhaps gave too much freedom. The just-released Mozilla Public License tried to find a new bal‐ ance between the needs of a corporate owner and a community of developers. Should they use that or develop their own license? I was never a big fan of the idea that licenses defined what was most important about free and Open Source software. I’d begun my career in computing in the heady days of the Berkeley Software Distribution of Unix, BSD 4.1, and AT&T’s Version 7. I had seen how Unix, based on the original architecture developed by Ken Thompson and Dennis Ritchie at Bell Labs, could attract a wide range of outside contributions from university computer science researchers despite being owned by AT&T. Many of the features that made the system most valuable had been developed at UC Berkeley and other universities. It was the architecture of Unix, not its license, that allowed these contributions to be treated as first-class components of the system. The system defined a protocol, so to speak, for the cooperation between programs, a design by which anyone could bring a new program to the party, and it just worked, as long as it followed that protocol. I’d then watched as the Internet and its killer application, the World Wide Web, had followed the same model, defining itself not by license but by the rules of interoperability and cooperation. I loved Linux, but it seemed a kind of blindness vii in Open Source advocates to focus so much on it. Open Source was the native development methodology of the internet, and the internet was its greatest suc‐ cess story. Network-centric architectures require interoperability and loose cou‐ pling. And the Internet allowed distributed development communities to evolve, and shifted power from corporations to individuals. I’d also been steeped in the culture of the Perl programming language, the idea that “there’s more than one way to do it,” and the sprawling extensibility of CPAN, the Comprehensive Perl Archive Network, which allowed programmers to share modules they’d built on top of Perl without ever touching the source code of the language interpreter itself. So I was convinced that much of the magic of Open Source was independent of the license. The things to think about were collaboration, community, and low barriers to entry for those who wanted to share with each other. And so I told Dan Frye, Pierre Fricke, and the other attendees at that IBM meeting, that yes, they could and should release software under Open Source licenses, but if they weren’t ready to do so, there was no reason that they couldn’t take advantage of these other elements. Given a large enough pool of customers using the same software, I told them, there was no reason they couldn’t create a “Gated Open Source Community.” For that matter, given a large enough pool of developers inside a company, there was no reason, I told them, why they couldn’t apply many of the principles and practices of Open Source within their own walls. That was what later came to be called InnerSourcing. I defined it at the time as as “helping [companies] to use Open Source development techniques within the corporation, or with a cluster of key customers—even if they aren’t ready to take the step all the way to releasing their software as a public Open Source project.” Not long afterwards, I heard the first stories of InnerSourcing in the wild. And as is so often the case, they weren’t planned. In 1998 or 1999, two Microsoft devel‐ opers, Scott Guthrie and Mark Anders, wanted to create a tool that would make it easier to build data-backed websites. They built a project on their own time over the Christmas holidays; other Microsoft developers heard about their work and adopted it, and eventually word reached Bill Gates. When the CEO called the two into his office, they didn’t know what to expect. In the end, their project became one of Microsoft’s flagship software offerings, ASP.NET. Twenty years later, Scott Guthrie heads all software development at Microsoft, and what was once a rene‐ gade InnerSource project is now a major part of Microsoft’s software strategy. Eric Raymond, the author of The Cathedral and The Bazaar, and one of the first theorists of the Open Source movement, once coined what he called Linus’ Law, “Given enough eyeballs, all bugs are shallow.” I propose a corollary, which we might call Scott’s Law, or The Law of Innersourcing: “Given enough connected viii | Foreword developers, all software development emulates the best practices of Open Source software.” Foreword | ix 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.