Sharecroppers, nomads, and early open source
<p>The responses to my previous post, on <a href="http://esr.ibiblio.org/?p=5277">the myth of the fall</a>, brought out a lot of half-forgotten lore about pre-open-source cultures of software sharing.</p>
<p>Some of these remain historically interesting, but hackers talking about them display the same tendency to back-project present-day conditions I was talking about in that post.  As an example, one of my regular commenters inferred (correctly, I think) the existence of a software-sharing community around ESPOL on the B5000 in the mid-1960s, but then described it as &#8220;proto-open-source&#8221;</p>
<p>I think that&#8217;s an easy but very misleading description to land on.  In the rest of this post I will explain why, and propose terminology that I think makes a more useful set of distinctions.  This isn&#8217;t just a historical inquiry, but relevant to some large issues of the present and future.</p>
<p><span id="more-5284"></span></p>
<p>For those of you who came in late, the B5000 was an early-to-mid-1960s Burroughs mainframe that had a radically unusual trait for the period; its OS was written not in assembler but in a high-level language, a dialect of ALGOL called ESPOL that was extended so it could peek and poke the machine hardware.</p>
<p>B5000 sites could share source-code patches for their operating system, the MCP or Master Control Program (yes, <cite>Tron</cite> fans, it was really called that!) that were written in a high-level language and thus relatively easy to modify. To the best of my knowledge, this is the only time such a thing was done pre-Unix. </p>
<p>But.  Like the communities around SHARE (IBM mainframe users) and DECUS (DEC minicomputers) in the 1960s and 1970s, whatever community existed around ESPOL was radically limited by its utter dependence on the permissions and APIs that a single vendor was willing to provide. The ESPOL compiler was not retargetable. Whatever community developed around it could neither develop any autonomy nor survive the death of its hardware platform; the contributors had no place to retreat to in the event of predictable single-point failures. </p>
<p>I&#8217;ll call this sort of community &#8220;sharecroppers&#8221;. That term is a reference to SHARE, the oldest such user group. It also roughly expresses the relationship between these user groups and contributors, on the one hand, and the vendor on the other. The implied power relationship was pretty totally asymmetrical.</p>
<p>Contrast this with early Unix development.  The key difference is that Unix-hosted code could survive the death of not just original hardware platforms but entire product lines and vendors, and contributors could develop a portable skillset and toolkits. The enabling technology &#8211; retargetable C compilers &#8211; made them not sharecroppers but nomads, able to evade vendor control by leaving for platforms that were less locked down and taking their tools with them.</p>
<p>I understand that it&#8217;s sentimentally appealing to retrospectively sweep all the early sharecropper communities into &#8220;open source&#8221;. But I think it&#8217;s a mistake, because it blurs the importance of retargetability, the ability to resist or evade vendor lock-in, and portable tools that you can take away with you.</p>
<p>Without those things you cannot have anything like the individual mental habits or collective scale of contributions that I think is required before saying &#8220;an open-source culture&#8221; is really meaningful. </p>
<p>This is not just a dusty historical point. We need to remember it in a world where mobile-device vendors (yes, I&#8217;m looking at you, Apple!) would love nothing more than to lock us into walled gardens of elaborate proprietary APIs, tools, and languages.  </p>
<p>Yes, you may be able to share source code with others in environments like that, but you can&#8217;t move what you build to anywhere else. Without that ability to exit, developers and users have only an illusion of control; all power naturally flows to the vendor.</p>
<p>No open-source culture can flourish or even survive under those conditions.  Keeping that in mind is the best reason to be careful about our terminology.</p>
