Conformance vs Comprehension

Summary

In 1991, a young student from Finland changed the world. In the mid-1990s I lead a team working on software configuration management tools for IBM — loosely an on-prem, pre-internet GitHub, with version control, issue tracking, and continuous integration. Overly ambitious for its time; trivial by today's standards — in no small part because that same student from Finland came back in 2005 and turned version control itself into a primitive, with Git. Hold that thought; I'll come back to it. Our target market was enterprise, so we supported all the major Unix systems of the era: Solaris, HP-UX, and of course IBM's own AIX. Our code was C, and every source file opened with a thicket of #ifdefs to paper over OS differences. I saw this new thing called Linux, and one weekend I ported our code to it. My management appreciated the initiative, and as luck would have it, a visiting executive was coming to town — she had me present what I'd done to him. Suffice it to say, he was not impressed. He saw no future in open source, least of all for enterprise customers. I could end the anecdote here by calling him an arrogant fool, or by noting that the distribution I'd happened to choose was Red Hat. But neither is my point. Given the information available at the time, his call was eminently defensible. Open source was — and remains — chaotic and unpredictable. Enterprises require governance. What I want to suggest is that he wasn't wrong about open source. He was wrong about where to look. He was governing the artifact — the code, the thing you inspect, certify, and support — and the artifact was not where the durable enterprise value was going to live. A decade and a half later, IBM paid thirty-four billion dollars for Red Hat. Red Hat did not sell the kernel. It sold conformance, certification, and indemnification: a way to govern open source without inspecting every line of it. The asset had relocated, from the code to the thing the code answered to, and the old model couldn't...