Unix != open source

Yesterday a well-meaning hacker sent me a newly-recovered koan of Master Foo in which an angry antagonist berated Master Foo for promoting an ethic of open-source software at the expense of programmers’ livelihoods.

Alas, I knew at once that he had been misled by a forgery, or perhaps some dreadful chain of copying errors, at whatever venerable monastic library had been the site of his research. Not because the economics was wrong – Master Foo persuades the antagonist that his assumption is in error – but because the koan conflates two things that were not the same. Actually, at least three things that are not the same.

Eighteen years into the third millennium, long after the formative events of Master Foo’s time, many people fail to understand how complex and contingent the relationship between the Unix tradition and the open-source ethos actually was in the old days. Too readily we project today’s conditions backwards in a way that impedes understanding of history.

Here’s how it was…

There are at least three different things one can mean when one speaks of the practice of open source.

The first, and oldest, is an unreflective folk practice of code-sharing. At this stage people just…share code. They don’t worry about licenses because they think of the activity as one that only involves an informal peer network of consenting sharers; there’s no concept in anybody’s mind of having to defend code-sharing, or of any collision with third-party interests. Nor is there ideology about the practice, nor any name for it – there’s just custom and utility. I’ll call this “Level One” or “unreflective” open source.

Another stage is reached when people begin to reflect on open source as a practice and articulate the pragmatic advantages of it. At this point one begins to get folk theory about it – claims like “sharing code is good because it reduces wasteful duplication of effort” or “code sharing is good because other people can notice problems that the author doesn’t.” But these claims are not connected by any generative or prescriptive theory; other than technical conventions about how to pass around code, there aren’t any norms. We’re still at folk-practice here, but folk practice becoming conscious. I’ll call this “Level Two” or “emergent” open source – you have an ethos, but not yet an ethic.

A third stage is reached when prophets try to systematize a theory of open source. What’s characteristic of this stage as distinct from the others is the assertion of strong normative claims attached to an explicit theory of the consequences: “you should share code, and here is why”. Only at this point can one really speak of an open-source “ethic”. I’ll call this “Level Three” or “ideological” open source, because when you get here practice starts to change in response to the developing theory. There are manifestos, and the manifestos matter.

Historically there have been at least two competing theories of open source, one associated with Richard Stallman and the other with me. But for the purposes of this post that distinction is almost completely unimportant; only the time of arrival of Stallman’s theory (1985) and to a lesser extent mine (1998) actually matters much.

The koans of Master Foo address the Unix design tradition, which began around 1969 and reached a recognizably modern form by the early ’80s when it incorporated TCP/IP networking. Right away we can see a question here; the early formative period of Unix long predates public Level Three thinking about open source.

This is why I knew that koan had been forged or corrupted. The Level Three language in which someone could berate Master Foo for promoting an ethic of open source did not yet exist in the legendary age of the early Unix patriarchs. It is true that you can find some evidence of Level Two thinking as far back as Ferdinand Corbató’s reflections on Multics in 1963, and there are quotes in the early Unix papers out of Bell Labs that suggest it. But we don’t see actual normative claims – full Level Three – until the GNU manifesto arrives in 1985.

Until then there is no concept that code-sharing could be in conflict with programmers making a living, because nobody has proposed that it be done systematically as a replacement for closed source. Master Foo’s antagonist in that supposed koan is anachronistic for early Unix, a back-projection of later concerns. Master Foo would have understood the proposition that source code has a longer expected survival time than object blobs, but not the ethical claim.

Now, I’m not arguing that the development of the Unix tradition and the open-source ethos were completely disconnected. It is a historical fact that the Unix tradition incubated open source, and worth looking at why. I’ve written about some of this before, so the following is a reminder more than a full exposition.

You can’t have open source if you can’t port software between machines – and not just between machines of the same make, but across architectures. It was Unix that made this possibility normal by systematizing the idea that APIs and retargetable compilers could decouple source code from the machine.

The other direction of entailment doesn’t work, though. You can have Unix without open source – and until Linux most of us did, most of the time. Bootleg source tapes and things like the Lions book deepened our understanding but didn’t free us from dependence on closed-source kernels.

It seems highly unlikely that there will ever be another closed-source Unix implementation in the future; the coupling is pretty tight, now. But remember that it was not always thus.