Loading
Introduction
This note describes the history of the Multics Software Development Process, sometimes called "The Multics Way," as it evolved from 1964 to the present.
CTSS
The 
Compatible Time-Sharing System (CTSS) was developed at MIT starting in 1961,
by a small team led by the late MIT Prof. Fernando Corbató.
Multics was a successor to CTSS, and many of the CTSS developers joined the Multics team.
The CTSS development process was experimental and informal, and this approach carried over into the
team process used by the Multics group at MIT Project MAC.
CTSS was initially documented by a users' manual published by the MIT Press.
The development process and internal documentation of CTSS was informal; the need for more formal documentation was seen later, when the CTSS team switched over to developing Multics, using CTSS as a tool.
Multics Software Development Over The Years
| 1960s MIT/GE/BTL | 1970s CISL/MIT/PMDC | 1980s CISL/PMDC | 1985-1988 PMDC | 1988-1992 ACTC | 2015-present simulator | |
|---|---|---|---|---|---|---|
| Requirements | FJCC Papers | Honeywell | Bull | Bull | - | online discussion |
| Design Docs | MSPM Repository | MCB MTB | MTB | MTB | - | online MTBs on Multics Wiki |
| Coding Std | MSPM BB | AN82 MCRB lore | AN82 Orange Book | AN82 Orange Book | AN82 Orange Book | AN82 Orange Book |
| Eng Decision | Daley | MCRB | MCRB | MCRB (online forum) | - | online MCR review on Multics Wiki |
| Code Review | ad hoc | audit | audit security audit | audit security audit | ? | audit security audit |
| Testing | ad hoc | ad hoc | Sys M regression | Sys M regression | Sys M regression? | GHM regression? |
| Exposure Usage | MIT | MIT, CISL | MIT, CISL, SysM | SysM | SysM | GHM |
| Performance Testing | ad hoc | MIT | MIT+SysM | MIT+SysM | SysM | GHM? |
| Library/Build | GE lib team | MIT IPC lib team | PMDC lib team | PMDC lib team | PMDC lib team | Eric Swenson |
| Formal Release | PMDC | PMDC | PMDC | PMDC | GHM |
XXX Here we could compare the Multics processes to others, if we could point to other process descriptions. If there are useful comparisons with FreeBSD, OpenBSD, Linux, Apple, Microsoft, we could point them out. For example, do some other processes skip steps we perform? Do some other processes perform steps we did not? Is the level of rigor greater or less?
Initial Development of Multics
From 1965-1969, during the initial development of Multics, Prof. Fernando Corbató ("Corby"), head of the Project MAC Computer Systems Research Group, led the system development. MIT, General Electric, and Bell Laboratories researchers presented six papers about Multics at the 1965 Fall Joint Computer Conference (FJCC). The development process emphasized documentation, because of the participation of Bell Labs and GE developers. The geographic distribution of team between Cambridge, New Jersey, and Phoenix also caused process adjustments.
The MIT/GE/BTL development team wrote 3000 pages of the Multics System Programmer's Manual (MSPM), 124 "repository" documents, and many other planning and administrative memoranda. These documents were circulated for comment before approving the final versions.
Bob Daley of MIT was the chief development engineer. He decided if an issue was important enough to extend the discussion or to consult with Corby. He decided how things would be implemented and what features were in and out. He decided whether to spend time speeding up a module or live with it, and similar choices.
Integration and bringup of Multics was organized and tracked in the Multics Planning Notebook, which defined a sequence of functional benchmarks for the integrated system, such as "Phase One", "Demonstrable Initial Multics", and "Limited Initial Multics."
Deployment at MIT
In 1969, the MIT Information Processing Center started running Multics as a service on the MIT GE-645, available to MIT researchers and other educational customers. GE and Project MAC Multics developers were the largest group of users on the MIT service.
Transition to GE/Honeywell
In 1969, Bell Laboratories dropped out of the Multics development effort. At the beginning of the 1970s, GE sold its computer division to Honeywell. Key MAC/MIT personnel took jobs at Honeywell Cambridge Information Systems Laboratory (CISL) in the late 1960s and early 1970s. At first, there was little change to the Multics development process.
Multics Software Development in the 1970s
Honeywell increased its commitment to Multics, introducing second generation hardware, and we adapted our process to support two code branches for a while. Announcement of Multics as a commercial product in 1973 introduced additional resource demands for supporting customers and accommodating their requirements. Honeywell established its Phoenix Multics Development Center (PMDC), in order to to support customers and benchmarks, and installed System M in Phoenix in 1972. Most Multics development was done at CISL, outside of the HIS/LISD rules and bureaucracy. The MCR Board was established with members from MIT/MAC/Honeywell in September 1973. CISL obtained its own small Multics machine in 1974 for test purposes. A few development projects were done in Phoenix, and submitted through the MCR board at CISL. Multics source library maintenance was done by a team led by MIT IPC. The index of MCRs lists some of the MCRs we have been able to locate.
Some major development efforts during the 1970s were the Access Isolation Mechanism, done at CISL, which made file system changes for multilevel security; integration of the ARPANet into Multics, done by MIT Laboratory for Computer Science (LCS) with funding from ARPA; and the New Storage System, which reworked the layout of files on disk and supported more storage, led by CISL. These projects modified many parts of the system and exercised the development process.
In the late 1970s, the Multics forum command was used by CISL and PMDC developers to discuss product development issues online.
Multics Software Development in the 1980s
A major project at CISL in the 1980s was the addition of the Data Management storage system, which supported transaction semantics on files. It led to multiple MTBs. Also in the early 1980s, the MCR Board process was reconfigured to increase the participation of Phoenix developers at PMDC. Dual MCR Boards were established and the process streamlined. This is described in MTB-650 Proposal to Reorganize the MCR Board (1984-02-28). Developers used a Multics program called opinion_analysis written by Lindsey Spratt to approve or reject MCRs.
The B2 project touched many parts of the operating system, and required additional process steps, and additional formalism and rigor in the process to satisfy NSA's Orange Book criteria. Some of these changes are described in MTB-712 Policy and Procedures for Software Integration. (1985-05-15) and MTB-713 MR11 Configuration Management (1985-05-17).
Right before the B2 rating was announced, Bull canceled Multics development. The cancellation of Multics development was announced by Honeywell in July of 1985, but it took a while to wind down. CISL was closed in June of 1986. Development continued in Phoenix for a while: the last MCRB packet was dated 1987-12-22.
Post-Honeywell
In April 1988, Bull transferred maintenance of Multics to ACTC Technologies, a University of Calgary spinoff. This company, under various names, continued to support Multics until 1998. From comments in the source code, we know they continued to assign MCR numbers until 1992.
Multics Revived for the Multics Simulator
When the Multics Simulator was released in 2015, a community of users online developed.
[GCD]:
Some active bug fixing began early in 2016.
The MCR review process is still used to describe and critique such changes.
See Multics Wiki MCR list.
[GCD]:
MCR numbers are assigned via the MCRs forum on Charles Anthony's SVE (Serenity Valley Engineering) Multics system.
A PDF document is created by the developer to describe the proposed change.
That PDF is installed on the Multics Wiki, and announced for review by the Multics community via mailing lists.
[GCD]: Eric Swenson runs the GHM (Gold Hill Multics) system. Eric has taken on the role of Multics distributor, handling system integration, testing of new releases, installation of new/changed software, etc. Eric is a former Multician, first at AFDSC and then in late years of CISL.
[GCD]: The two teams work together to create a runnable sim/OS combination, with separate distributions of those two components to people interested in running Multics. Many of these interested parties are former Multicians. Others are more interested in history of computing, and trying out early OS implementations.
[GCD]:
Eric Swenson and I have done a few large programming projects, for which MTBs were written,
disseminated for review and critique, with discussions via the mailing lists until consensus was reached.
Then MCRs were submission for permission to add these projects to the Multics software libraries.
The MTBs are posted on the Multics Wiki MTB list.
[GCD]: All changes are audited following AN82, Orange Book and word-of-mouth guidelines. I must admit, we've had trouble finding people willing/able to do such audits. Eric and I have done most of them; Olin Sibert did a few. But we're still following (and enjoying benefits of) the Multics Software Development Process.
[GCD]: I've tried to assist Eric in ways that whet my programming appetite: namely creating tools to assist in him (and others) in using Multics, trying things out, and installing software into Multics Libraries. Eric is the person doing all the distro work.
[GCD]: Eric has done a lot of the bug fixing:
- Applying Y2K changes developed by ACTC which never got installed into a release, so simulated Multics can run after year 2001.
- Fixing bugs reported by himself and others in using simulated Multics.
- Installing new/changed software; making system releases (including System Release Notes document, etc).
- Packaging new releases in a way that those running their own simulator can apply to an existing sim Multics system.
[GCD]: My work on Multics in the 2015+ time frame (other than consulting, and a few minor bug fixes) includes:
- Recreating call command, which can invoke subroutines directly, for testing purposes, using entrypoint parameter descriptors embedded in objects by the PL/I compiler to do argument conversions (from character representations to numbers, pointers, etc).
- Creating a Multics version of Unix command-line editor and command history mechanism. The Multics version is called input_history: built atop the Multics video system, which already supports editing of the current command line being typed; the input_history adds emacs-like requests to scroll backward to earlier input lines (or search for them by character string), and to edit and/or re-enter those earlier lines.
- Creating an mbuild tool which organizes change sets to be installed into the Multics libraries, and performs common operations on those change sets: analyzes when they fit in the existing Multics Libraries; compiles incoming sources; archives and binds the source/objects into bound segment components (source archive, object archive, executable bound object); generates an update_seg script (exec_com) to install the result into the Multics Libraries.
[GCD]: Around 100 installations have been performed since work started on simulated Multics; some large, some small bug fixes. 67 of these changes are documented by MCRs; 4 were large enough to warrant MTBs. Three of the recent MTBs were written by me to describe these larger programming efforts.
[GCD]: The distro work can be tedious. The installer applying changes to Multics Libraries has to know (and remember to apply) a lot of details about how/where Multics software gets installed. The mbuild tool captures Eric's and my knowledge of these details into software that attempts to automate some tasks and remove much of the drudgery.
page created 21 Mar 2016 THVV; updated 05 Oct 2019 with input from Gary Dixon [GCD].