% fortune -ae paul murphy

From Chapter Four: The Unix and Open source Culture

This is the 40th excerpt from the second book in the Defen series: BIT: Business Information Technology: Foundations, Infrastructure, and Culture

Roots (1)

Almost everything you really need to know about Unix (or Unics as it was first known) and the open source movement can be gleaned from a paragraph in a paper Dennis Ritchie, one of the original Unix developers, called "The Evolution of the Unix Time-sharing System":

From the point of view of the group that was to be most involved in the beginnings of Unix (K. Thompson, Ritchie, M. D. McIlroy, J. F. Ossanna), the decline and fall of Multics had a directly felt effect. We were among the last Bell Laboratories holdouts actually working on Multics, so we still felt some sort of stake in its success. More important, the convenient interactive computing service that Multics had promised to the entire community was in fact available to our limited group, at first under the CTSS system used to develop Multics, and later under Multics itself. Even though Multics could not then support many users, it could support us, albeit at exorbitant cost. We didn't want to lose the pleasant niche we occupied, because no similar ones were available; even the time-sharing service that would later be offered under GE's operating system did not exist. What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

Those last two sentences, written in 1979 and so well before Linus Torvalds modified Minix to create the Linux kernel or Sun created its "the network is the computer" slogan, bear repeating:

What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

The story Ritchie tells about the origin of Unix is a story about the resolution of conflict between business managers and visionaries when the visionaries push their invention ahead despite management opposition, and then gain their reluctant co-operation when users adopt the product and become vociferous supporters. Management was not supportive but users were. Then, as now, Unix disrupts organizations by reducing the importance of hierarchal reporting relationships as information conduits in an organization.

That user orientation, like the focus on collaboration, was the complete antithesis of the approach taken with the IBM System 360:

IBM System 360 Unix
Within IBM, design and development of the 360 were both top down, management driven, processes. Within Bell Labs, the design and development of Unix was driven by technical experts and adoption was driven by users.
Multi-user access to the 360, and thus development of mainframe operating systems, focussed on keeping users, and user processes, separated. Development of Unix focussed on bringing communities of users together.
360 architecture sales were generally driven from the top down and focussed on cost cutting through job elimination and the automation of clerical tasks Unix deployments were generally driven from the bottom up and focussed on increasing the value of user contributions and control in both business and research.
Almost all System 360 applications were developed for business use by large well funded teams working with formal management to meet externally defined business system specifications. Almost all Unix applications started as individual or small group research and/or academic projects with clear functional goals but no formal project management or specifications.
Almost all System 360 sales to businesses were made to people who report to, or work in, corporate Finance departments. Almost all early Unix sales were made to front line staff in research or production.

Thus where Ritchie talks about users ratifying Unix by adopting it, mainframers talk about the strength of their user access controls and the laying off of clerical workers to fund systems development work.

Most fundamentally the mainframe culture is based on using machines to replace people while the Unix culture focuses on using machines to extend the reach of individuals and communities. Thus one focusses on automatic data processing on the 1920s card based model while the other focuses on using computers to defeat both time and space as barriers to communication and collaboration.

The resulting cultural conflicts between Unix users and mainframers have never been resolved. Today some mainframe data centers run Linux on mainframes in lieu of CMS as single user server processes with tight user controls --leaving Unix experts baffled as to why anyone would ever want to do anything so obviously absurd as to incur very high costs to impose rigorous separation on a culture that's fundamentally about cheap and effective information sharing.

The open source movement is often seen as a natural outgrowth of the Unix cultural focus on information sharing, but this view reverses the chronology. In fact, the core Unix design was influenced by open source ideas held by some of the key designers for Multics, the project from whose ashes Unix arose.

For example, in 1965, Corbató and Vyssotsky, co-designers of the Multics operating system kernel, wrote

It is expected that the Multics system will be published when it is operating substantially...Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.

In its present form this commitment to publication and peer review, originally derived from the core academic and scientific approach giving rise the science breakthroughs achieved in the forties and fifties, has given shape to the open source movement.

Some notes:

  1. These excerpts don't (usually) include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

    Notice that getting the facts right is particularly important for BIT - and that the length of the thing plus the complexity of the terminology and ideas introduced suggest that any explanatory anecdotes anyone may want to contribute could be valuable.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.