Foreword
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 earlier 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 continue 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 balance 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 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 success story. Network-centric architectures require interoperability and loose coupling. 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 developers, 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 renegade 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 developers, all software development emulates the best practices of Open Source software.”