University of Nevada, Las Vegas
published : 13 September 2002
email's success lies a history of extended social interactions
among ARPANET developers, programmers, and users from relatively
heterogeneous backgrounds. An analysis of social identifications
present in online discussions about email development found
that inter-organizational computer networking allowed an increasingly
wide variety of programmers and users to interact; assumptions
about users to be openly stated and challenged; and the prototyping
and testing of new technologies in heterogeneous social and
technical contexts. Technical interoperation and its social
analogue, social collaboration, became key challenges in the
development of networked email and led to "arrested
closure" in the form of flexible standards.
interoperability, users, arrested closure, message systems,
networked email, ARPANET, collaborative standard development,
Request For Comment, RFC
II. Defining identities and
III. Collaboration in computer
Questioning the technical user's relevance
Notes and appendices
mail, developed informally by a small, elite group of computer
experts to serve their own communication needs, has become
a "mundane" technology, much like the pencil.
Email use is now common in the U.S. and developed nations.
Louis Harris and Associates recently reported that sending
and receiving email was the most popular online activity
among online computer users in the U.S.: Sixty-three percent
of online users reported using email "often." [end of page 1]
The number of worldwide email accounts by the end of 1999
was estimated at about 570 million (although an unknown number
of people have multiple accounts), over 130 billion email
messages were sent in 1999, and the most common use of the
Internet continues to be email.
In September 2001, 45.2 percent of the U.S. population reported
of networked email masks the technical and social challenges
that influenced its development during the early days of the
Foremost among these challenges was that of "interoperation,"
the goal for the network technologies to smoothly operate
with each other. In this paper, I argue that the expanding
ARPANET research network not only became rapidly dependent
on email for administrative and collaborative reasons, therefore
reinforcing the need for technical interoperation of email,
but it also provided an increasingly heterogeneous social
environment in which a parallel social "interoperation"
was necessary in order to negotiate email standards.
of networked email faced a few unique challenges. Although
email had not been a goal of the ARPANET's project, it arose
out of the instrumental needs of coordinating the network's
development and administration.
Email was an unexpectedly popularbut technically unsophisticatedapplication
of the innovative network. It resembled (and still resembles)
the simple store-and-forward telegram, and did not require
the network's innovative path redundancy nor its real-time
interactivity. Given email's low level of sophistication and
an interpretation of ARPANET resources as primarily technical
rather than social, funding for the development of email programs
and standards was a low priority. This meant that volunteers
were especially important in programming and supporting email
services across the network, and created concerns among institutional
users who increasingly regarded email as an essential utility.
examines the development of email standards and systems on
the ARPANET as a process in which technical considerations,
and technological closure were influenced by social identifications.
The social aspects of the ARPANET have rarely been examined;
most histories thus far present institutional perspectives
or focus on computer hardware. As Rosenzweig notes, the varied
backgrounds of social groups"wizards, bureaucrats,
warriors, and hackers" in his wordsinvolved in
the networks' development deserve closer examination.
ARPANET design was a remarkable technical feat in which participants
continually reconstructed their environment; it was also a
remarkable feat of social collaboration in which the design
values, goals, and scenarios of different social groups were
negotiated. As with the ARPANET, networked email had to operate
across different technical contexts, and the organizations
in which it was usedranging from the military to the
academicwere contexts with different norms for communication.
Groups and individuals influencing the ARPANET included the
Information Processing Techniques Office (IPTO)
managers, liaisons, consultants, "hackers," various
types of users, formal and ad hoc committees, and graduate
students. [end of page 2]
In studying networked
email, I examine a mutual shaping context in which a communication
technology was simultaneously being developed, used, and revised.
This research is not intended to be a complete overview of
emailthis important and multifaceted history, addressed
in passing in many works, remains to be comprehensively researched.
Instead this research focuses on the important period from
the mid-1970s to the mid-1980s when the ARPANET, and later
the Internet, was rapidly expanding in number and heterogeneity
of nodes and user population. I argue that during this period,
the ARPANET's technical and social environment facilitated
the development of robust email standards because of two factors.
First, the technical factor, ARPANET (later Internet) technologies
provided a basic yet flexible infrastructure for the development
of more complex communication services.
Second, and the
primary focus of this study, is the socio-technical factor.
Development of a software-based communication technology is
a complex social as well as technological process because
of the assumptions about social interactions embedded in it,
particularly if the software is used to support its own development.
The ARPANET was designed to link heterogeneous computing environments.
Thus, interoperability was of critical importance. As network
connections proliferated, the heterogeneity of both the computing
environments and the social groups with access to and influence
on the network increased. With this increase came broader
participation which encouraged a form of software development
incorporating an increased number of user and programmer perspectives,
and in which discussions about software design processes themselves
occurred ("meta-design"). In addition, email's
early programmers were able to discuss, critique, and troubleshoot
email software as they used it, both in terms of technical
interoperation (e.g., test messages were sent out and the
results reported on) and social collaboration (e.g., the social
contexts of email use were discussed).
Both the broader
participation and the ability to shape the technology in use
had important implications for the final form of email standards
and the programming of email software. It is important to
note that participants in the larger online group examined
in this case study initially discussed the standardization
of email software, in particular which commands and
functions would adequately reproduce "real-world"
administrative tasks and how they would be invoked (e.g.,
storing and retrieving email messages were compared to filing
memos and filtering messages was compared to sorting incoming
postal mail). As the difficulty of agreeing on email characteristics
appropriate for the ARPANET's diverse social/administrative
contexts became apparent, this group's efforts shifted to
discussing the structure of email messages. Agreement
on minimum standards for message headers enabled the interoperation
of email systems from the widest set of computing environments,
while the standardization of how to extend header information
enabled specialized uses and future expansion (such as the
ability to add email enclosures). [end of page 3]
Finally, the following
study examines the role of inter-organizational networking
on the construction of user identities and the development
of email. While the larger online group examined in this research
was initiated to encourage closure with regard to email functions,
and a second unofficial online group emerged to handle specific
technical challenges, there is little evidence for a direct
connection between the online discussions and specific email
features and standards. Rather, the online discussions had
a subtler impact. The participants in both groups resisted
"premature closure" in email standardsthat
is, stabilization before sufficient perspectives were addressedby
serving as vocal proponents for interoperation. Through online
discussion and demonstration, both groups demonstrated the
need for simple but flexible email standards while providing
forums that attracted an overwhelming constituency of email
software programmers to implement them.
of email user identities and their implications for email
system design are evidence of the social nature of software
development. In the following sections, I summarize the challenges
programmers face in defining users, outline the historical
homogeneous and heterogeneous networking contexts and their
implications for email system development, introduce two
inter-organizational ARPANET online discussion groups, and
summarize constructions of organizational and individual email
users presented in this group.
identities and software users
A core challenge
in designing software is understanding the context of its
use, and how this context differs from that of its development.
Users are constructed explicitly or negotiated implicitly
as part of the design process and philosophy. Given that people
with differing skills use technologies in different contexts,
the notion of a singular "user"as in "the
email user"is misleading.
Who are the experts who influence the design? What are the
relative influences of the programmers and the users?
representations of users and uses are by no means the only
challenges to successfully rolling out new softwareothers
include the difficulty of large-scale testing and revising,
building a critical mass of users, high development costs,
and user resistanceit is essential to identify and analyze
typical usage contexts, and compensate for these contexts'
differences from the simplified and idealized conceptualizations
present during the early stages of their creation. When developing
software for specialized contexts, programmers are likely
to consult experts; but when the context appears commonsensical
or part of quotidian experience, as communication services
might easily appear to be, software, as with other technologies,
can suffer from the consequences of "tunnel vision."
[end of page 4]
The success of
some softwaresuch as the graphical user interfacehas
been attributed to the variety of conceptualizations about
potential users, and to "bootstrapping" (the notion
that designers' decisions should be actively informed by their
own use of the technology), a concept proposed by Doug Engelbart
at the Stanford Research Institute (SRI) during the 1960s
with important implications for the communication software
If the software being designed is used to support collaboration
during its development, then the social interactions taking
place during the design process are likely to influence perceptions
of the technology, especially in the identification of drawbacks
and desirable features.
in computer networks
development, and inherent challenges, mirrored the development
of networking technologies. The earliest computer networks
served relatively homogeneous user groups that typically consisted
of non-proximate business or military users. For example in
1952, the "Magnetronic Reservisor" linked American
Airlines offices in New York City via telex in order to coordinate
seat reservations. The more sophisticated U.S. military SAGE
(Semi-Automatic Ground Environment) system, conceptualized
in 1946 and put into operation in 1963, linked radar and computing
centers for real-time processing for early warning of enemy
Before the ARPANET, email systems used a single time-sharing
computer attached to multiple terminals but isolated from
other computers (in Figure 1a, this is represented by the
host computer contained in the dotted rectangle marked "A").
Figures 1a-c. Email systems in increasingly
heterogeneous network environment. Rectangle "A"
encloses a single host; "B" encloses a single
network with multiple hosts (ARPANET model); "C"
encloses multiple networks (internet model). Modified version
of image appearing in V. G. Cerf, "Internetting and
Electronic Message Systems," paper presented at the
AFIPS Workshop on Technical and Policy Issues in Electronic
Mail and Message Systems, Washington, DC., 1980.
[end of page 5]
Rectangle "A" encloses a single host.
Figure 1b. Rectangle
"B" encloses a single network linked to multiple
hosts (only one is visible here), as in the ARPANET. [end of page 6]
Rectangle "C" encloses multiple networks, as in
One of the earliest
examples of email on such a system was MIT's Project MAC,
which allowed the
of messages from one user to another in the computer.
On logging into the computer a user may be informed by
the machine that there is a message in his "mail
box," and the computer will then print the message
[end of page 7]
This type of system
would be technologically and socially homogeneous: users were
either geographically proximate or had similar organizational
ties, and systems used a single set of technical standards.
A more complex
network (shown schematically within the larger dotted rectangle
B in Figure 1b) linked different types of host computers,
as in the ARPANET configuration.
Specialized network computers ("Interface Network Processors"-IMPs)
connected different types of host computers serving different
organizations to a single network, and the "remote subscriber
terminals" were connected via TIPs (Terminal IMPs), which
were similar but linked inexpensive "dumb" terminals
to the ARPANET. TIPs were popular because they provided access
to network resources at relatively low cost.
An organization without a mainframe could use another organization's
software remotely via TIP access.
The ARPANET was
innovative not only because of its packet-switching technology
but also because it linked computing systems having different
technical standards and work groups having different social
norms. It was originally designed to link sites to share military
contractors' computing resources and to test network technology
for reliability and robustness, under the management of the
Information Processing Techniques Office (IPTO). The IPTO,
founded in 1962 as part of the U.S. Department of Defense's
DARPA, provided research support to partnerships between the
U.S. defense and academic research communities. The office
was influential in the development of computer science theory,
practice, and education, although its original focus was the
use of computers for command and control applications.
Before the ARPANET
was operational, IPTO directors J. C. R. Licklider (1962-64,
74-75) and Robert Taylor (1966-69), described the computer
as a communication device based on their experiences at the
Stanford Research Institute with group "project meeting"
Their article suggested the networked computer's potential
for communication before widespread network access: "A
communications engineer thinks of communication as transferring
information from one point to another in codes and signals"
want to emphasize something beyond its one-way transfer….
Creative, interactive communication requires a plastic or
moldable medium that can be modeled, a dynamic medium in
which premises will flow into consequences…. Such a medium
is at handthe programmed digital computer.
online collaboration can be traced back to the IPTO's goal
to not only share computing resources for military research,
but also to create closer ties among computer science and
engineering communities, in particular among the researchers
and graduate students responsible for operating the new network.
The original ARPANET contract was given to a distributed group
to encourage collaboration
because an earlier experiment with network technology had
demonstrated the difficulty of encouraging researchers to
collaborate. [end of page 8] IPTO's first funding for network research (in
1964 under Licklider) went to UCLA to link three computer
centers. However, it failed because of "strong local
disinterest: The directors of the three centers appeared not
to want to work together."
A key feature
of ARPANET design collaboration was the careful documenting
of design debates. The Network Working Group, which solved
problems in linking computers to the ARPANET, fully documented
its work starting in 1966 to help solve problems that they
expected other network users would later encounter.
By 1969, when the ARPANET became operational, proposals for
technical and social norms for information exchange were instituted
in the Request For Comments (RFC) documents that were soon
distributed online. Graduate student Steve Crocker set the
tone of the RFCs when describing a Network Working Group meeting
(comprised mostly of other graduate students) about communication
between host computers and IMPs: "I present here some
of the tentative agreements reached and some of the open questions
encountered. Very little of what is here is firm and reactions
In RFC 3 of April 1969, entitled "Document Conventions,"
content of a NWG note [the early name for RFC] may be any
thought, suggestion, etc. related to the HOST software or
other aspect of the network. Notes are encouraged to be
timely rather than polished. Philosophical positions without
examples or other specifics, specific suggestions or implementation
techniques without introductory or background explication,
and explicit questions without any attempted answers are
all acceptable. … These standards (or lack of them) are
stated explicitly for two reasons. First, there is a tendency
to view a written statement as ipso facto authoritative,
and we hope to promote the exchange and discussion of considerably
less than authoritative ideas. Second, there is a natural
hesitancy to publish something unpolished, and we hope to
ease this inhibition.
These early RFCs
sent a welcoming signal to others interested in contributing
to and improving the ARPANET. Brian Reid, later a Carnegie
Mellon graduate student and a participant in MsgGroup, told
them "I did not feel excluded by a little core of protocol
kings. I felt included by a friendly group of people who recognized
that the purpose of networking was to bring everybody in."
increased rapidly from four connections in 1969 to twenty-three
in April 1972. ARPANET email was introduced in 1972 when
Ray Tomlinson of BBN modified existing mainframe email and
network file transfer software to create a tool for coordination
among network developers.
He is credited with selecting the "@" symbol to
designate the host to which the message should be transferred.
This addition facilitated the use of email for inter-organizational
Email soon became
the dominant use of the network, a surprising "smash
hit" in the words of Frank Heart, manager of the ARPANET
project at BBN.
One reason was that email supported the numerous administrative
tasks necessary for operating the ARPANET. [end of page 9] It was asynchronous,
allowing time for reflection and for people in different time
zones and with different work schedules to participate; it
was scalable, allowing a variety of people to participate
either directly or via copies of messages; and it allowed
people from a wide geographical region to participate. Using
email automatically created machine-readable documents that
could be stored, forwarded, or commented upon, and context
information (date, time, sender) was generated automatically.
For some people, there were disadvantages that included having
to type (although sometimes done by secretaries), and the
technology could be difficult to use.
documents were available both by email and by postal mail.
The Network Information Center (NIC)
on the ARPANET did have an interface in the early 1970s to
send postal maila clerk would print and mail messagesbut
this stopped because of high cost and an increase in online
The first RFCs to explicitly discuss ARPANET email, in 1971,
describe it in terms of a "mail box" to simplify
the exchange of administrative information about the ARPANET,
in particular for the NIC to deliver and receive messages
This protocol also defined what would become "headers"
to provide information for a person to distribute the messages:
the head of the message or document sent to mail box number
0 [the default mailbox to be connected to a printer] there
is to be an initial address string terminated by a form
feed. This address string is to contain the sender's name
and address, and the receiver's name and address formatted
in some reasonable, easy-to-read form for a clerk to read
As the importance
of managing and automating email became apparent, standardizing
the contents and format of these headers would become the
subject of extensive debate. Much as an expanding railroad
network earlier created pressure to standardize timekeeping
for efficient coordination of trains, linking far-flung computers
created pressure to standardize metadata such as time-stamps
to allow efficient data sharing. On pre-network computers,
time-stamps were based on local times and used varied formats.
Networking required an acknowledgement of time zones and agreement
on time formats so that messages could be ordered chronologically.
By October 1973,
Jon Postel, who served as the RFC editor, required that
protocols … be submitted in the form of online documents….
This will greatly facilitate the review process and enable
editorial and substantive changes to proceed quickly. This
also will permit timely updating of protocol documents as
may be necessitated by future decisions. Online documents
are also easily distributed to the network community.
Using email at
this stage required different programs to edit text files
and read and send messages. A series of user interface improvements
were made. Larry Roberts wrote the first email management
program (RD) in 1972 or 1973, based on Ray Tomlinson's SNDMSG
By 1975, John Vittal had developed MSG, the first all-inclusive
email program including replying, forwarding, and filing
capabilities. At this point, the "ARPANET directory listed
well over one thousand people who had network electronic mail
addresses." [end of page 10]
At the 1974 National Telecommunications Conference, Stephen
Lukasik, ARPA director from 1971 to 1974, described how the
ARPANET message service had been used to "improve [ARPA's]
internal management and operating efficiency."
By 1975 the ARPANET
was linked via "noisy" satellite circuits to Hawaii
and Europe, but most nodes were in the continental U.S. (see
Figure 2. The 57 IMPs and TIPs on
the ARPANET in July 1975. Photograph courtesy of the Charles
Babbage Institute, University of Minnesota, Minneapolis,
as adapted from ARPANET Completion Report Draft, September
Not only did the
ARPANET link together geographically distant locations, but
it also linked government, military, academic, and commercial
organizations. During these early stages of the ARPANET, the
conceptualization of tools for social communication was still
wide open. A "messaging system" could encompass
a simple email system, an automated conferencing system,
a database system managing online archives, and even include
real-time chat systems. Each conception had different design
characteristics, appropriate for different user groups and
organizational contexts, as was reflected in the terms used.
In 1977, Panko and Panko noted that such systems were variously
termed "computer mail, computer message services, computer
teleconferencing systems, and electronic message services."
The data structure
of the email message is divided into two parts reflecting
its origins from the administrative memo and the ARPANET data
packet. The header section contains a series of data fields
about the message (these are typically read and generated
by software), while the body contains the message itself (this
is usually read and generated by the user). Most email standards
discussions and RFCs focused on defining and refining the
header fields and their uses. [end of page 11] In particular, RFC 822 defined
the structure of Internet email messages and remains influential
today; RFC 821 defined the "simple mail transport protocol"
(SMTP) that described how messages should be transferred from
host to host; and RFC 1123 corrected and updated these standards.
A message on an
internetwork (shown schematically within the largest dotted
rectangle C in Figure 1c) could take the route shown by the
dotted line, crossing multiple networks and being read on
a completely different system than the one on which it was
composed. Figure 1c represents multiple networks with multiple
computers linked by gateways (marked by G) which "translate"
the message data as it moves from network to network. As the
networks grew in complexity, the interoperation challenge
grew and technical standardization became more critical. A
major technical challenge was properly routing messages to
destinations at other organizations and through other networks
and properly routing the replies back, as well as translating
key header information. Another challenge was accommodating
the widening range of technologies used to compose and read
email. Users might read messages through a slow line printer,
a rapid video terminal with monospaced character fonts, or
the innovative Xerox Alto system, which used proportionally-spaced
characters and whose designers conceptualized handling and
formatting text in an entirely different manner.
labels and technical proficiency
and heterogeneous networks not only linked together multiple
technologies, but also multiple groups of users. Stereotyped
social identifications existed during the time-sharing and
early ARPANET development, when programmers developed a wide
range of identity labels. These labels described the technically-proficient
(such as implementers, hackers, and wizards), varieties of
users, and "bureaucrats."
identities are culled primarily from the perspective of the
technically-proficient, as expressed in the New Hacker's
Dictionary, a resource which typifies both the playfulness
of computing cultures and a desire to exert authority over
the labeling of technology and those who work with it.
These identity labels were created and defined by many of
the same people who participated in the online discussion
groups examined in this paper, and these labels appeared regularly
in their online discussions. The original Jargon File
a collection of hacker jargon from technological cultures
including the MIT AI Lab, the Stanford AI lab (SAIL) and
others of the old ARPANET AI/LISP/PDP-10 communities including
Bolt Beranek and Newman (BBN), Carnegie-Mellon University
(CMU), and Worchester Polytechnic Institute (WPI).
Of these organizations,
the MIT AI Lab, SAIL, BBN, and CMU had members who participated
frequently in email development discussions. [end of page 12]
is a complex identity label exhibiting the tensions of stereotyping
and differing ingroup and outgroup definitions. In popular
culture, "hacker" is a pejorative term that emphasizes
maliciousness and the invasion of computer systems; but within
the hacker lexicon, these individuals are known as "crackers."
Within the social group itself, the term emphasizes technical
proficiency, intellectual curiosity, and creativity. According
to Raymond and Steele, a hacker "enjoys exploring the
details of programmable systems and how to stretch their capabilities,
as opposed to most users, who prefer to learn only the minimum
necessary", "programs enthusiastically (even obsessively)
or who enjoys programming rather than just theorizing about
programming," is "good at programming quickly"
or an "expert at a particular program…as in a 'Unix hacker.'"
Note that this last definition indicates the contextual nature
of hacker: someone can be a hacker with respect to one technology
and not with respect to another.
From a hacker's
are two classes of people who work with a program: there
are implementers (hackers) and lusers [sicsee below].
The users are looked down on by hackers to some extent because
they don't understand the full ramifications of the system
in all its glory.
is a relative term: a "skilled hacker may be a user with
respect to some program he himself does not hack."
Other types of
users are less technically proficient. The "real user"
is one who is paying money for computer use, is a commercial
user, or is "someone using the system for an explicit
purpose (a research project, a course, etc.) other than pure
The "luser" is a user "who is also a loser,"
a term coined in the mid-1970s at MIT as joke variation of
the user label on one of its ITS systems.
After this coinage, "[t]here ensued a great controversy,
as some of the users didn't particularly want to be called
losers to their faces every time they used the computer."
However, later "one of the ITS machines supported 'luser'
as a request-for-help command."
user" (naïve, this is, with respect to the technology,
not the context in which it is used) was represented sympathetically
if the reason for the naïveté was inexperience.
A naïve user "[t]ends to imply someone who is ignorant
mainly owing to inexperience. When this is applied to someone
who *has* experience, there is a definite implication of stupidity."
The "naïve user" was taken more seriously during
the 1970s in personal computer design and is reflected in,
for example, Ted Nelson's call for redefining the user in
his politicized guide to computing Computer Lib/Dream Machine:
"A naïve user (no offense)" is an "ordinary
person who doesn't need to know any [technical] things in
order to do something useful with the computer. Creating programs
to help him is the frontier of computing." [end of page 13]
included "manager," "bureaucrat," and
"suit," which were all derisive terms. Managers
were famed for "their distance from actual productive
work and their chronic failure to manage," and their
"social technologies" of formal committees, politicking,
and voting were regarded suspiciously by hackers.
labels become important as we examine the role of an online
discussion group that not only incorporated people from multiple
organizations, but also attempted to develop email standards
and software for multiple types of users.
of an inter-organizational discussion group
Email was a critical
communications link between and among IPTO administrators,
developers, and users, and an underlying technology essential
to the administrative operation of the ARPANET. But while
RFCs provided an important early forum for publicizing mailing
standards, the development of ARPANET email standards lagged,
perhaps because the RFC system was a relatively slow, contemplative
process or because it was reaching and incorporating the views
of the only most dedicated standards creators. Of even more
concern was that email RFCs were sometimes not acted upon.
Because of the decentralized nature of ARPANET administration,
the need to test standards during their development, and the
lack of funding for email system development, the adoption
of email standards was rarely achieved through direct administrative
edicts, but rather largely through a voluntary "opting-in"
process on the part of host sites.
In an attempt
to develop consensus and develop support for the emerging
standards regarding email, IPTO administrator Steve Walker
agreed to sponsor an open online forum among ARPANET users.
The result, the main focus of this case study, was "Message
Group" (or "MsgGroup" for short), an early
online discussion list started on June 7, 1975, by computer
scientist Dave Farber and lasting until 1986.
This group is worth studying because it was initiated to homogenize
standards, its membership consisted of people involved in
early and subsequent email technology development (see appendices
B and C), and it was regarded as influential both during its
existence and in retrospect.
The group's demise in 1986 was attributed by its former participants
to the availability of other online discussion forums, the
solution of the basic messaging problems, and a focus on other
to link together people already involved in the development
of messaging systems, as well as others who might have been
interested in the topic. At this time, a variety of systems
were in development or recently completed: MSG had just been
developed by John Vittal, BBN had started developing Hermes
under contract to IPTO, and MSGDMS at MIT and RDMAIL at CMU
were under development (#1157, 30 April 1979). [end of page 14]
Formation of the
group was prompted by the following message from the IPTO
reason for seeking to establish a group of people concerned
with message processing was (and remains) to develop a sense
of what is mandatory, what is nice and what is not desirable
in message services. We have had a lot of experience with
lots of services and should be able to collect our thoughts
on the matter.
goal at present was not to establish "another committee"
but to see if a dialog can develop over the net. I sense
that to some extent this has already happened but there
are many who have not entered the discussion. There are
lots of possible reasons for this and I do not wish to force
anyone to participate but I strongly urge anyone with comments
(positive or negative) to toss them in (#2, 7 June 1975).
As with RFCs,
MsgGroup contributions were assigned sequential numbers and
archived for later reference by its moderator.
However, MsgGroup contributions covered a broader range of
issues and, because membership was open, aired the views of
a wider group of people concerned about the development of
email. While specific standards were not discussed in detail
within the groupthey continued being published as RFCs.
Many of MsgGroup's contributors credit the group with influencing
the development of networked email. There were three other
groups that addressed issues similar to MsgGroup, all of which
shared a large overlap in membership. The Message Service
Committee and the IPTO-funded CAHCOM (Computer-Aided Human
Communication) committee were smaller, more exclusive groups
than MsgGroup and had official mandates while the unsanctioned
"Header-People" discussion group had a more technically-oriented
membership, had no moderator responsible for the list (it
was an early example of an "automatically rebroadcasting"
listserv), and focused on specific design and implementation
details of email header information.
contributors (about sixty of whom could be considered core
members because of the number of messages they contributed
or length of their membership)
were distributed across the United States (and in later years
Europe), at a variety of military, academic, and consulting
organizations, and contributed a total of 2,578 messages to
the list. According to the first distribution list posted
to the group, MsgGroup messages were sent to nineteen mailboxes
on six host computers (#13, 12 June 1975). In April 1979 there
were 133 mailboxes, and it took about two hours to send each
message to the list (#1012, 10 April 1979). The last distribution
list posted to the group, version 46, had 191 mailboxes (including
several group mailboxes such as the CMU mail developers mailbox
RdMail@CMUA, and MsgGroup@ECL, RAND-MsgGroup@RAND-UNIX, Future-NET@SRI-KL
and MsgGroup@UDEL) on forty host computers (#1583, 22 December
An early message
about the appropriate technology for use in the discussion
indicates that founding MsgGroup members wanted to make the
list as accessible as possible. Email was considered more
appropriate than teleconferencing systems because it was very
convenient for most members, allowed "passive observation,"
and facilitated easy deletion of messages. [end of page 15] Using an interactive
chat program, TCTALK, was regarded as a "very inefficient
process" because other participants would have to watch
the others type. The then recently-developed FORUM system
was not recommended because it had a "long start-up curve"
and required that everyone have access to the same computer
clearly felt that robust email standards should be developed
quickly before inferior existing technology propagated:
no mistake-what our 'toy' systems do to us today is going
to happen to a hell of a lot of people tomorrow. In the
computer game there is a distressing tendency for an informal
set of operating procedures to become a de facto standard
through rapid diffusion. And the wider the diffusion the
more difficult even desirable change becomes (#908, 11 March
of email developers and users
developers have been portrayed as elite and insensitive to
social issues, members of MsgGroup repeatedly reflected on
social aspects of their technology (email), both with regard
to the group itself and to wider society. Of the 86 substantive
that took place in MsgGroup, 32 involved discussions of social
issues in relation to the group and 48 involved discussions
of broader social issues in the design of email systems;
in contrast, 57 involved technical discussions (I classified
the threads into multiple categories if appropriate).
The primary goal
of MsgGroup was interpreted by its moderator as exploring
"netmail from a users point of view through discussion
of issues among the message system development and application
community within the ARPANET" (#1157, 30 April 1979).
The group linked together the few people at each organization
concerned about the topic. Early members included "some
managers, some users, some customers …, some implement[ers],
and some hackers" (#1157, 30 April 1979). Of the nodes
represented in Figure 2, the academic hosts participating
in the development of email included MIT, Stanford, Carnegie-Mellon,
and UCLA; the governmental/military hosts included ARPA, National
Bureau of Standards, and various military sites including
Ames; and the consulting and commercial sites included BBN
(Bolt Beranek and Newman), CCA (Computer Corporation of America),
RAND, and, later, Xerox PARC.
As with the ARPANET,
specialized online groups such as MsgGroup and Header-People
linked "resources"people with specialized
knowledge and experiencesfrom different computer sites.
Using ARPANET email systems, both online groups enabled people
who would not normally interactpeople who were not "Principal
Investigators" given travel reimbursement to attend face-to-face
meetingsto build social networks across organizations
focusing on email system design. [end of page 16] Although
pragmatic collaboration was encouraged on the ARPANET, it
could be threatening to the more traditional organizational
structures. The creation of Header-People, the unsanctioned
technical email list, was initially questioned by MsgGroup's
moderator and by a member of an ARPA-sponsored committee who
wrote "You can't go on forever, merrily communicating
with other system hacker types…" ("What the 'standard'
is and isn't," September 27, 1976).
with widely differing social norms presented challenges. Norberg
and O'Neill point out that a barrier to military units accepting
the ARPANET was that the "network would make it easier
for subordinates to send messages to other agencies without
the approval of commanding officers, possibly circumventing
the military's chain of command."
This tension between structured and informal collaboration
was to be expected given ARPA's hybrid academic-military nature
and its emphasis on decentralized ARPANET development. In
exchange for academic research and technical expertise, early
ARPANET managers tolerated off-topic online discussions, unusual
work schedules, network testing, and lax network security.
The DoD finally resolved this dilemma in 1983 by splitting
off 68 of the then-total 113 ARPANET nodes into a separate
(and more secure and stable) MILNET network, and leaving the
remaining ARPANET nodes for network research and development.
discussions reveal two self-identified subgroups: administrative-oriented
professionals and technically-oriented hackers.
Participants emphasized their social identities by highlighting
their administrative and technical experiences, and some participants
explicitly described themselves as having backgrounds in both
areas. Of the approximately sixty core members, ten percent
were predominantly administratively-oriented and about half
as many were predominantly technically-oriented, with about
one-quarter appearing to fit in both categories. The remaining
participants did not give sufficient information to be categorized.
The ARPANET connected
governmental, academic, and commercial organizations, and
identifications of all three types were present in MsgGroup
discussions. During MsgGroup's 1975 to 1986 duration, increased
internetworking and the use of gateways connected new organizations,
socially and technically, to the ARPANET and MsgGroup. In
1982 Xerox-PARC's internal mail system was gatewayed to the
ARPANET. International users began to contribute to MsgGroup
using the ARPANET directly or via gateways. Messages from
University College in London first appeared in 1981, and messages
from University of Stockholm's OZCOM system were gatewayed
through MIT's network in 1984. [end of page 17]
Linking new organizations
and email software presented technical and social challenges
that were reflected in the online groups' discussions. Three
examples of discussions representing organizations as having
specific (and problematic) differences in technical standards
are, chronologically, the "ARPA order," the "decent
header," and the "Xerox woes" threads. The
"ARPA order" thread (6 to 15 March 1979, 26 messages),
was seeded by a message from an IPTO manager asking Carnegie
Mellon to modify its RDMAIL software in direct contrast to
the then standard, RFC 733, because BBN's Hermes software
could not process RDMAIL messages. One member wrote about
ignoring the RFC 733 standard to accommodate BBN (#882, 7
March 1979). An MIT hacker noted that the ARPA "bureaucrats"
were interfering with "one of the most democratically
adopted standards" and that the order was retrogressive
(#884, 7 March 1979). A CMU member explained why they agreed
to modify RDMAIL to meet this request:
is the only site on the net which generates recipients with
imbedded spaces. From the point of view of anyone managing
time or money, it makes more sense to have one site make
a change rather than many, especially if the change is as
small as this one is (I expect to take a total of about
1/2 hour to make the change) (#887, 7 March 1979).
the role of ARPA funding Hermes software development, and
questioned whether BBN or the Federal government (which contracted
with BBN) owned the software (#904, 8 March 1979). Hermes
was perceived by hackers as being flawed not only because
it was inefficient, but because they could not access and
modify its proprietary source code. An SRI programmer wrote:
is a hungus [humungus?] monster of a program that should
never have been given birth. Any mail program that brings
the system to a screeching standstill whenever it is started
and any program whose core image is almost as big as INTERLISP's
is a crime against nature. It is the most inelegant program
I have ever seen (#1026, 13 April 1979).
headers" thread (4 April to 28 August 1979 in several
bursts, 59 messages) demonstrates differences between MIT's
older messaging systems and other messaging systems on the
ARPANET. The thread started when a message from a user of
the ITS operating system on an MIT computer contained information
not compatible with other messaging systems, which resulted
in protests from MsgGroup members. Members complained that
ITS users often forgot to include "subject" information
in their messages. One ITS user noted that the "ITS header"
problem was well-known but would take too much effort to fix.
MsgGroup's moderator had to manually correct the ITS headers
and compared the technical problem of ITS headers to a social
problem: they were "bad breath out here in the rest of
the net" (#958, 6 April 1979).
Woes" thread (26 August to 12 September 1982, 52 messages)
demonstrates the challenges of communicating with innovative
messaging systems. It started when group members from Xerox
sent email with formatting that resulted in very long text
lines. Xerox's attitude, too, was deemed "anti-social"
(#1820, 26 August 1982). [ end of page 18] MsgGroup members then discussed whether
there should be a standardized line length, given that devices
on the ARPANET used different line lengths, and whether the
sending or receiving software should be responsible for message
format. Finally, a member from Xerox stated the organization's
official position, and complained about attacks on Xerox (#1859,
31 August 1982). A similar, earlier thread was "Please,
no 80-column texts!" (8 to 18 September 1979; 42 messages)
in which a BBN member asked that others send their messages
in the 72-column format because it was compatible with a wider
range of output devices.
These three examples
demonstrate that in this networked environment, organizations
were associated with their software's characteristics: MIT's
and Xerox's software (and their users) were considered rude
for being incompatible with other systems. In addition, ARPA
attempted to control the standardization of the technology
to the point of negotiating between BBN and CMU, and effectively
neutralizing an existing standard, RFC 733.
were often discussed by MsgGroup participants in the form
of actual and potential users of messaging systems. Many MsgGroup
members described themselves as email users, and clearly they
were users in the sense that to participate inor just
observethe group they had to be familiar enough with
messaging systems to access and send messages. The extent
to which group members used the technology, and the manner
in which they thought it should ideally function resulted
in the varied user conceptualizations, or varieties of "constructed
The early ARPANET's research focus limited the heterogeneity
of its online groups. Access limitations excluded most developers
of commercial systems, actual "naïve users,"
and academic organizations other than those with elite computer
science departments. But the transition to the Internet in
1983, which simplified connections with other computer networks,
expanded the influence and heterogeneity of MsgGroup (and
other ARPANET groups).
of users within this group fit into three general categories:
Administrative users, naïve (or future or novice) users,
and hackers (or implementers or programmers) as users. The
first type of user was an administrator operating within an
organizational context. MsgGroup members with administrative
backgrounds compared messaging technology to secretaries,
and such a system had to easily handle typical administrative
functions such as sorting and filing mail, allowing managers
and secretaries to function as a single entity. This user
represented the administratively-oriented members of the group
during this period when access to messaging system accounts
were restricted because of expense. [end of page 19]
The second type
of user was the generalized naïve user, which included
clerical staff (when messaging systems where discussed in
the context of large organizations) and the potential wide
group of future users (when messaging systems were compared
with the ubiquitous Postal Service). The naïve user was
often discussed in gendered terms, particularly when secretaries
were described. The naïve user appeared to be used as
an idealized identity when discussing the importance of simple
systems. The administratively-oriented members viewed catering
to naïve users as a prerequisite for marketing messaging
systems to large organizations, while technically-oriented
group members regarding assisting naïve users as an evangelical
duty, and described the liberating effects of computer technology
for such users.
The third type
of messaging system user, and ultimately the most influential
type, represented the technically-proficient ARPANET members
of the group itself. Although not without controversythe
members repeatedly debated their representativeness as messaging
system usersgroup members critiqued the systems with
regard to their own experiences, and in particular demonstrated
problems they encountered using the technology. Online debates
about "bootstrapping" indicated that MsgGroup members
had differing notions of the opportunities to generalize their
experiences with email systems.
The next three
sections describe in detail the group's discussions about
administrative and naïve email users, and the relevance
of technically-proficient users' perspectives on email.
the administrative user
Near the beginning
of MsgGroup, its moderator suggested that plans for messaging
systems be evaluated by group members (#131, 15 August 1975).
At this early stage, however, members were primarily either
managers or closely associated with people in managerial positions;
the more technically-oriented (and independently-minded) systems
administrators and hackers joined later. For example, managers
wrote introductions such as:
a 'user' and a 'critic' without portfolio (#526, 26 April
am not a Computer Scientist. I am however one of those rare
birds, a USER, and also an interested onlooker (#993, 8
am a customer and a user. … I am not the expert that most
of you are, but I am a good listener and willing to give
feedback from a user standpoint when specifically requested
(#453, 8 February 1977).
In the early days
of MsgGroup, the predominately administratively-oriented members
evaluated plans submitted by developers of messaging systems.
The "Nomenclature: Comparison of Mailsys, MSG and HG"
thread (14 October to 29 December 1975, 20 messages) is a
good example of contrasting such developer and administratively-oriented
user perspectives. [end of page 20] The user-liaison for BBN's messaging system
project asked for feedback from the group on a report comparing
terminology from three messaging systems: BBN's MAILSYS, John
Vittal's MSG (written in 1975 and at the time the "most
popular message-reading program on the ARPANET" (#474,
18 March 1977)), and James Calvin's HG (written in 1974, and
which combined mail reading and mail composition features
(#474, 18 March 1977)).
One member questioned
whose perspective should be used in developing terms. In his
view, the "manager's perspective" was not sufficient
and software should adapt to many users and groups:
of the msggroup correspondence seems to propose that message
systems should be viewed from the point of view of the office
manager. I also feel … that message systems such as those
we are speaking of are useful for interactions between non-managers.
A circuit designer using a "computer-mediated-interaction"
system … will not want to view his interactions from the
same viewpoint or in the same language as an office manager
or for that matter a university professor who is using the
system to do research with colleagues at other remote sites.
So the basic problem with evaluating the terms used in the
message system is whose point of view should we take. Of
course another point of view on the problem is to say that
we will never have real agreement and thus why not provide
a mechanism for each different group or for that matter
individuals to provide their own environment (the personal
terminal attitude) (#180, 14 October 1975).
noted that terminology for simple operations should work whether
"whether you're a major, or office manager or a research
engineer" (#183, 15 October 1975). MsgGroup's moderator
thought that the BBN report represented a programmer's perspective,
rather than a "normal person's":
some general comments about the difference between normal
people and programmers. Programmers are a little like mathematicians.
… [The] FILTER [command:] I don't like at all because it
is backwards from the way us non-programmers think about
searching for things. We don't think in terms of building
a filter and then passing the file through it. We think
of "going through the file looking for a match."
Thus we need a SEARCH MASK, or a MATCH [command] (#186,
20 October 1975).
users differed from other users, such as hackers, in that
theyor their organizationswere paying customers
(#1066, 15 April 1979). Military users were a specialized
example of such an administrative user:
military user currently is used to a prompting message creation
system (the message creation form DD173) and would probably
feel more comfortable (at least initially) with some prompting.
… I am extremely gratified and excited to see the [message]
group interacting and that those interactions appear to
be converging around real capabilities that I think can
be sold to the operational military guy (#49, 23 June 1975).
A common complaint
from administrative users and the group's moderator, who had
to manage large amounts of mail in this role, was that the
tricks that they had to learn to use message systemsor
to actually make them functionwere unreasonable (#1335,
20 October 1979), especially for potential future users. [end
of page 21] MsgGroup's moderator noted this twice. In the
first posting, he expressed concern that while powerful text
editors such as EMACS could be used for composing, reading,
and printing email messages, they were too complex and limited
in terms of other features needed for email processing, such
as filing messages:
am also looking at things beyond the level of hacker/users.
My work involves the transfer of these technologies into
organizations and businesses that will not tolerate a need
to think in editor terms to get the work done (#973, 6 April
In the second
posting, the moderator responded to complaints about his sending
a personal message to the list ("CC'ing") rather
than only to the intended recipient:
should be clear that we cannot expect future multitudes
of computer mail system users will accept responsibility
for dealing with system designs that provide trap doors
to fall through and goblins that jump out to grab the unwary
(#1336, 28 October 1979).
This was a common
problem at the time and remains so today; the "trap doors"
and "goblins," while identified, were not resolved.
The "organizations and businesses" and "future
multitudes of…users" represented a very different type
of user than that represented within this group.
In sum, administratively-oriented
MsgGroup members placed messaging technologies within familiar
organizational contexts and roles; this suggested that technology
design should adapt to existing organizational structures
and mimic existing tasks. The administrative perspective was
exemplified by this unfavorable comparison of early messaging
systems to one contributor's efficient secretary, "[who]
is knowledgeable enough to make an almost perfect assessment
of the 'rightness' of giving out clearly private information
DEPENDING upon the circumstances of the request. … I wait
for our efforts to get much more sophisticated than they are"
(#809, 24 February 1979).
the naïve user
members expressed concern about developing messaging systems
for "naïve," "novice," and "future"
users, representative ones were rarelyand in the last
case, not yetavailable. The naïve or novice user
was commonly cited but was represented differently by administratively-
and technically-experienced members. The former regarded them
within bureaucracies while the latter appeared to see them,
perhaps in light of the activism of the era, from a more personal
The concept of
"naïve user" was present in MsgGroup discussions
from 1975 to 1979 (with one mention in 1982), but these concerns
decreased as more technical issues were addressed in the group.
In addition, the variability of user needs was largely relegated
to the user-interface portion of messaging technology rather
then the underlying transport standards. With the division
between user interface and underlying standards, the underlying
mail transport could be standardizedalthough still expandablewhile
the user interfaces could be specialized for different organizations
and types of users. [end of page 22]
Given the stated
importance of designing for naïve users, it is surprising
that MsgGroup members reported only two cases of directly
contacting such users to examine their views of message processing.
In the first instance, a member conducted an "experiment
to determine command vocabulary selection" (#280, 29
January 1976), in which he "interviewed three secretaries,
asking them what they do, after initially receiving a stack
of mail for their boss, to determine… the next step for processing
the mail" and an appropriate command for examining incoming
messages. (He found that secretaries "scanned" incoming
mail.) The other instance took place during a discussion about
the appropriate uses of the "carbon copy" command,
when another member "did a quick survey in our company,
and asked several non-computer friends to do the same"
(#1370, 30 October 1979). Based on his survey, he concluded
that typical organizational uses of carbon copying had not
been portrayed accurately in the discussion.
members viewed defining and catering to naïve users as
a prerequisite for marketing messaging systems to large organizations:
future goal is for this to be used by anyone and everyone
who works in offices. That means that the use should be
designed to fit their needs, not ours. The systems are meant
to improve the productivity of currently-existing offices,
and must facilitate their existing operational patterns.
… Business communications are structured, not only in government,
but in any large corporation. There really is a chain of
command; it must be recognized and considered in preparing
a marketable product for our customers (#1360, 30 October
One concern was
how to simultaneously meet the needs of a variety of users,
and how to handle naïve users as they became more sophisticated
through their own experiences or as computer systems became
more common. The following excerpts demonstrate concerns about
developing systems for changing users ("exhibit growing
sophistication") and multiple groups of users ("novice
as well as experienced"):
would like to suggest that tailorable systems should have
a graded set of sophistication levels available as default
options to facilitate new users who will exhibit growing
sophistication and hence need a growing set of capabilities
(#212, 18 November 1975).
of the really important issues in the controversy is "How
do we make it easy for all usersnovice as well as
experiencedto find out what features are available,
and how they can best utilize them" (#809, 24 February
In contrast to
the above administratively-oriented views of users, the technically-oriented
members of the group reported working with naïve users
in their roles as liaisons and computer support staff, and
for the most part expressed sympathy with these users' perspectives.
is unacceptable to have the attitude that because a user
is naive s/he is "stupid." There are a lot of
bright people who do not know every in and out of a computer
system and don't intend to learn, but at the same time must
use it. A computer system typically makes strange demands
at odd times to a user, and all too often the "consultant"
simply says "do this" or "type that"
without any explanation; perhaps because the user did not
want an explanation (#932, 4 April 1979). [end of page 23]
of users were particularly clear in the administratively-
and technically-oriented views of gender in relation to technical
competence in naïve users. This may have been due to
differing organizational experiences, ages, or social views
between these two groups. Several early male administrators
had secretaries type their messages and send them using the
secretary's mailbox accounts.
This led to a series of threads discussing how to handle multiple
people involved in the creation of a message and the difficulty
of designing technology for secretaries, including a thread
entitled "Helping Secretaries Answer Boss' Mail."
This discussed how two people ("Boss" and "Secretary")
can collaborate in sending messages and about tools for delegating
email management, and members ended up discussing standardizing
header fields such as "SENDER:", "FROM:",
and "REPLY-TO:", as well as how software should
handle these fields (for example, whether to send replies
to the FROM or the SENDER address).
In several cases
when features were discussed for a variety of users, naïve
users were envisioned as secretaries (#280, 29 January 1976)
or "housewives" (#577, 9 June 1977). The activities
of messaging systems were compared to those of secretarial
staff. The moderator, for example, repeatedly evaluated new
features by applying his "time-honored" secretarial
test: "If your secretary reformatted your incoming mail
without asking, would you fire him?" (#1246, 10 September
1979); "If my secretary, without my directive, told anonymous
inquirers 'when I last read my mail,' I would fire him"
(#805, 23 February 1979). The use of the masculine pronoun
for secretary in the above quotations was not unusual in this
group. Other members describe secretarial functions in earlier
messages as follows:
secretary then tells MSG to Answer each piece of mail, allowing
him/her to also send a copy [to the] Boss' directory (#54,
24 June 1975).
our operative, a secretary, X. When X comes in, in the morning,
he (traditionally a neutral pronoun) begins mail processing
by seeing what's been placed on the mail stack (or mail
box, or "in box") on his desk. How does he do
this? By … (#277, 25 January 1976).
One thread about
secretaries as current and potential future users of messaging
systems is worth exploring in detail because of the reactions
of members to the characterizations of secretaries. During
a discussion about efficiencies of various email and operating
systems that resulted in a debate about whether message systems
should be simple or powerful, the topic changed briefly to
"systems even a fool can use." A male hacker distinguished
between the experiences of "intellectual" programmers
and those of clerical workers and their implications for user
interface design, and a subsequent response linked clerical
workers to women: [end of page 24]
must also remember that most clerical workers are women
and have been taught they shouldn't be too bright or aggressive
or know a lots about computers cause computers are 'definitely
a masculine thing'. This in addition is why suggestions
that clerical workers (and it applies to clerical workers
of either sex) are happy being dumb (I am exaggerating and
characterizing here) are so obnoxious; however in the case
of female clerical workers such a suggestion is extremely
obnoxious (#1085, 19 April 1979).
In general, hackers
seemed especially sensitive to gender concerns in MsgGroup
discussions. This observation is supported by events in the
Header-People discussion group, which consisted primarily
of hackers. RFC 724 addressed how to handle messages sent
by secretaries as follows:
Jones logs in as Jones on his Host. His secretary, who logs
in as Secy on her Host (SHost) sends mail for him. Replies
to the mail should go to George, of course.
An MIT hacker
in Header-People not only critiqued the RFC's technical aspects,
but also criticized the assumption that secretaries were women:
the RFC, secretaries are always referred to with feminine
pronouns, while other people are always male. While this
reflects an almost true state of affairs, it is a shameful
state, and we ought not to go about writing documents that
implicitly assume that it is so. Such implicit allusions
tend to lull people into an unthinking acceptance of the
situation. Why can't we have a mail standard which isn't
a male standard? ("RFC724", 12 May 1977).
When a revised
version of RFC 724 was finally released, it incorporatedin
addition to many technical modificationsrevisions to
the secretarial references (which were irrelevant to the technical
characteristics of the standard). They were rewritten to disguise
the sex of the secretary (but not that of the boss):
Jones logs in as Jones on his host. His secretary, who logs
in as Secy sends mail for him. Replies to the mail should
go to George.
In short, the
naïve user was viewed differently by administratively-
and technically-oriented members of MsgGroup. The former tended
to view the technology as supporting naïve users in their
existing roles in organizational structures, while the latter
tended to question assumptions about the technical capabilities
and the sex of such users, and express hope that such users
would find computing technology intellectually stimulating.
the technical user's relevance
of bootstrapping (designers using what they design) occurs
when developers identify themselves as typical users and design
based primarily on their own needs. Many MsgGroup members
stated that they approached computer systems from both developer
and user perspectives: [end of page 25]
am responsible for the implementation of BBN's mail system
…. Also I am a fairly extensive user of mail systems … (#250,
5 January 1976).
am mostly a user and infrequently an implementer of message
systems. … I have been involved in protocol development
for the ARPANET and more recently for other networks too
(#532, 27 April 1977).
am a] user and critic, with a strong interest in future
network systems for use by the general public [and] an implementer,
in the sense that I am part of designing/writing multiple
interactive applications (#491, 12 April 1977).
It is clear that
technically-oriented people had a great deal of influence
on message systems from their perspective as users of the
technology. For example, the introduction to the manual for
Carnegie Mellon's own email program "RDMAIL" thanks
members of the school's computer science department for their
The extent to
which technical-oriented participants could represent broader
categories of email system users was repeatedly discussed
within this group. A representative thread about this topic
began with a self-described hacker writing: "I claim
that essentially all of us have almost exactly the wrong set
of experiences and backgrounds to do the job properly. Our
tendency is to judge a feature based on our personal preference
for it" (#1075, 16 April 1979). In response, another
we indeed may have the wrong set of experiences and backgrounds
to standardize message systems PROPERLY. But it appears
to me that we still have a professional responsibility to
translate our experience and knowledge from the current
environment into meaningful guidance to the multitude who
will be using electronic mail systems in the future (#1077,
17 April 1979).
administrator distinguished between designer and user perspectives:
must … use the systems they design to test their designs
and in so doing often become super users, but they are a
different breed of cat from users who only wish to use the
system and are not deeply concerned with the mechanism of
how it runs. It is important to keep these distinctions
in mind (#1088, 18 April 1979).
users were able to influence the technology's development
based on their own experiences. When MsgGroup's or Header-People's
members identified a technical problem with email systems,
they could demonstrate the problem publicly and discuss possible
solutions. Technical problems with the lists themselves led
to troubleshooting discussions. The MsgGroup list served as
an interoperability "test site" as its members deliberately
tested the limits of their email systems by sending a long
message or a message that followed or disregarded a standard.
In these cases, others would report how well their systems
While most discussions
in MsgGroup, particularly during its later years when there
was a reduced presence of administrators, focused on concerns
from technically-oriented users about messaging system features,
there were concerns expressed about the ability to generalize
from these experiences by group members. [end of page 26] For example, in response
to a call for more complex message systems, another member
wrote that complex systems did not accurately reflect the
needs of most users:
don't doubt that a vote among the message community would
strongly support the proposed "progress" toward
more advanced but more complex systems. What concerns me
is the knowledge that there is a group of very unsophisticated
message system users out there, and the strong suspicion
that they better characterize future message system users
(and the future for message systems) than the present user
population does (#267, 15 January 1976).
concerns, hackers only twice reported collecting data from
social and technical closure
Full closure (or
social consensus) rarely occurred in MsgGroupin the
sense that group members rarely agreed on topics after discussion,
or made firm technical decisions. This is particularly apparent
because some discussion topics were frequently repeated, including
internetworking challenges, defining and using header fields,
and adherence to standards.
Rather, it appears
that the nature of closure in this group was twofold: the
group served to prevent premature closure by discussing and
organizing responses to deficient standards, and it provided
members with social and technical "lessons learned."
By "premature closure" I mean that the decision
to stabilize the technologyin this case email softwarewas
forced before the perspectives of most relevant social groups
were taken into account. This is the technological equivalent
This common challenge
in creating standards is described by Vannevar Bush, who managed
the development of U.S. military technology during World War
II, in his introduction for an official history of the United
States National Bureau of Standards, as the problem of choosing
the point at which to "fix" standards, since "ambiguity
or inaccuracy can slow down accomplishment… [y]et too much
speed [to fix standards] can sometimes pin matters down in
ways that are later found to be clumsy or expensive."
How did messaging
system and ARPANET standards achieve closure, given the apparent
choice between having an exclusive standards committee make
uninformed and unpopular decisions, and a large, heterogeneous
group such as MsgGroup which was not able to reach consensus?
In the early days of email, this lack of closure was an advantage.
As the experience with the isolated Message Committee group
demonstrated, decisions made without a wide variety of opinions
and without the support of multiple parties would fail for
reasons that were technical (because they did not work in
all of the contexts present in the increasingly heterogeneous
network) and social (because the exclusionary process by which
they were developed was not respected by the technically-oriented
implementers). [end of page 27]
The MsgGroup and
Header-People online groups deliberately developed flexible
standards, what I term "arrested closure." The key
solution was to settle on simple, extendable, and flexible
standards. The most basic elements of email technology became
standardized and were rapidly adopted because consensus could
be reached about these elements and because their simplicity
and flexibility allowed them to be rapidly (and inexpensively)
implemented in a wide variety of contexts. This flexibility
took two forms. Email technology was conceptually divided
into "user agents" (which mediate the interactions
between the computer and the user and can be adapted for various
types of users) and "mail transfer agents" (which
handle the transmission of messages from computer to computer;
their standards are strictly-defined);
and email header standards allowed an extendable series of
data fields (primarily computer-read and generated), quite
separate from the actual message.
case study suggests that premature closure, a problem with
early messaging standards creation, was avoided through social
interactions among people with differing individual and organizational
user identities. Alternative sophisticated email and collaboration
tools existed during the case study's period, such as NLS/AUGMENT,
FORUM, EIES, and the "MARS" message archiving and
These systems (and their collaboration features) did not flourish
because of their complexity, lack of transferability across
technical systems, and, fundamentally, the lack of a broad
constituency of providers and users. In comparison with these
collaborative systems, email "makes virtually no assumptions
about the nature and structure of collaboration."
In its "arrested closure" form, the networked email
standards eventually developed were simple, generalizable,
and had an overwhelming constituency: everyone with the desire
to communicate across computer hosts.
email standards were made outside of MsgGroup in other small
groups and decisions about their implementation were made
in, depending on the specific standard, either a decentralized
fashion site-by-site, or enforced by the agency funding ARPANET.
Technical closure, such as it existed, resulted from discussion
about "Request for Comment" files, which were typically
created by a few authors (some of whom were MsgGroup members),
as well as hackers' support for overwhelming "good ideas"
and pressure from the source of funds for the ARPANET: the
Department of Defense. As one MsgGroup member noted, there
were two techniques: "by edict" (such as the TCP/IP
and the "ARPA order" with regard to CMU's RDMAIL
in 1979) and informal peer review: "Somebody does it,
and the rest of us decide it's a good idea" (#1978, 21
April 1983). In the latter case he gave the example of MIT's
mail list software: "remember when MIT was the only place
that had mailing lists?" [end of page 28]
The actual process
of closure in the context of the ARPANET was administratively-influenced
by the specific DoD office responsible for the network at
This pressure was grudgingly accepted because that office
controlled funding for the ARPANET. Yet closure was not enforced
in the manner one might expect in an organization linked to
the military. The "edict" technique described above
required that network administrators cajole programmersat
least those at academic organizationsand receive criticism.
Norberg and O'Neill argue that the IPTO had an unusually innovative
and lean management structure strongly influenced by the academic
The combination of edict and technical peer review supports
Besides the technical
influence of MsgGroup members on email technology, such online
standards groups also indirectly influenced the social process
of Internet standards development. While the exclusive ARPANET
committees lacked sufficient experience and authority to develop
standards for the heterogeneous and decentralized ARPANET
environment, the MsgGroup could not reach consensus because
of polarized views and a multiplicity of opinions. Later efforts
at building standards appear to have developed a middle ground
that combines in-person consensus building groups with open
membership, along with online discussions that encouraged
debate about standards.
A prime example
of middle-ground collaboration is the Internet Engineering
Task Force (IETF), whose first meeting was in January 1986.
The IETF has "primary responsibility for the development
and review of potential Internet Standards from all sources."
Crocker, an influential email standards developer and former
MsgGroup member, attributes the success of the IETF standards
development process, in part, to "rough consensus,"
diverse contributions, online collaboration, and the participants
being users of the resulting technology.
original ARPANET effort involved very focused research on
basic issues of packet switching. However, much of the use
of the technology was subject to development by happenstance.
The informality of the process had the detriment of relying
entirely upon the energies of one or a few "champions"
rather than the more deliberated outcome of an organizational
commitment. … Another feature of the informality was that
a scribe could make "enhancements" to the specification
and have them implicitly acceptedif no one objected
too loudly. The original ARPANET mail facility was the result
of just such a casual, private decision.
Crocker then describes
the IETF's conflict resolution process, which does not rely
on formal procedures such as voting (since there "is
no formal membership") but allows parties to protest
perceived slights. Similarly, MsgGroup and Header-People groups
had no formalized membership and provided environments for
objecting to specifications, for resisting closure on standards,
and for protesting standards development processes and specifics. [end of page 29]
This case study
demonstrates the importance of assumptions about social interactions
in relation to the development of email software and standards.
Networked emailsimple, reliable, and now taken for grantedproved
technologically and socially challenging. Although originally
started by an IPTO program manager as an attempt to encourage
closure with regard to email standards, MsgGroup did not reach
closure in either technical or social terms despite the use
of voting, reports, and other organizational techniques.
The early ARPANET,
and subsequently the Internet, linked a wide variety of technical
and social contexts, enabling interactions among people with
differing conceptualizations of email users. This study found
"arrested closure" in email standards because of
the wide variety of opinions and systems available on the
network; that is, the conceptual leap in email standards
development involved leaving them deliberately flexible in
two ways: (1) by dividing the system into two components,
the user agent (which could meet different users' needs) and
the mail transfer agent (which adhered to specific standards);
and (2) by defining the email "header" as having
a minimum but expandable series of meta-data fields.
The key lesson
learned, based on experiences working with different systems
and differing interpretations of standards, was to simplify
the challenge of interoperation by designing systems which
would be flexible in accepting incoming data and consistent
in producing outgoing data. This technical challenge was phrased
in social terms, for example, to not foist "bad breath"
on the network or be "anti-social."
The ARPANET case
suggests that when developers are presented with a context
in which they realize their own perspectives as users are
not representative, they use information seeking strategies
to extend their understanding of user identities. During this
process, developers constructed and debated hybrid user/developer
identities that resulted in alternative conceptualizations
of the technology. The increasingly internetworked environment
in which email standards were developed shows evidence of
both an increasingly broad range of user constructions, and
meta-discussions about the generalizability of developer-based
identities. Social as well as technical interoperability was
the goal of these online groupsmembers with quite different
backgrounds and user constructions strove to collaborate,
although the archived messages indicate that this process
was quite frustrating at times.
of networked email is an early example of informal inter-organizational
online collaboration. ARPANET users and programmers had effectively
pioneered an online "collaboratory" (a contraction
of "collaboration laboratory")
in which social interactions were key in negotiating the users
and uses of the technology, as well as the experimentation,
and rapid prototyping of a new communications system. Early
online discussion lists such as these provide an important
but neglected perspective on technological developmentone
not previously available from official documents or professional
[end of page 30] As Lukesh notes, the broader social history
of early online interactions urgently requires study before
the data is unreadable and its contributors pass away.
While the collaboration
styles of groups such as the Network Working Group, MsgGroup,
and Header-People presage those of the Internet Engineering
their contributions have been neglected apart from recent
popular accounts such as Hafner and Lyon.
A group of authors concerned about the lack of user participation
in the development of non-Internet electronic mail standards
recently wrote that:
the past five years [i.e., since 1991], almost countless
electronic fora … devoted to user issues have sprung up
on the Internet…. We suggest that standards organizations
look urgently at how the exchange of views and dissemination
of information afforded by these services could facilitate
greater user-participation in standards-setting. … It cannot
help but seem ironic that communications standards committees
are failing to exploit the communications technology to
its full potential.
In essence, these
authors are arguing for reinventing an MsgGroup or a Header-People,
which together provided surveillance of existing standards
and organizing responses, the announcement and demonstration
of technical problems and the negotiation of solutions, the
publicizing of "lessons learned" about social and
technical issues, and a forum for collecting a variety of
analysis demonstrates a rich variety of social interactions
and user constructions in early online discussions about the
development of networked email, an apparently mundane communication
technology. This supports the notion that software development,
and especially communication software development,
is a complex socio-technical process involving not only technical
but also social interoperation challenges. [end of page 31]
Kilker, "Social and Technical Interoperability, the Construction
of Users, and 'Arrested Closure': A Case Study of Networked
Electronic Mail Development," Iterations: An Interdisciplinary
Journal of Software History 1 (September 13, 2002): 1-51.
Katz and P. Aspden, "Motives, Hurdles, and Dropouts,"
Communications of the ACM 40(4) (1997): 97-102.
Taylor, "On-line Population Spends an Average of Six
Hours on the Internet or Web per Week," Poll Summary
18 (New York: Louis Harris and Associates, March 24, 1999).
Lake, "Metrics: Message in a Packet." The Industry
Standard, (July 24, 2000): 202-3.
Department of Commerce, A Nation Online: How Americans
are Expanding Their Use of the Internet (February, 2002).
ARPANET research network, the precursor to the Internet, was
developed under the auspices of the Information Processing
Techniques Office (IPTO) of the Department of Defense's Advanced
Research Projects Agency (DARPA). While a comprehensive discussion
of ARPA, the IPTO, and the genesis of the ARPANET is beyond
the scope of this paper, its development has been examined
by historians emphasizing the IPTO's innovative organizational
perspective and relying on interviews with administrators
and project reports; see A. L. Norberg and J. E. O'Neill,
Transforming Computer Technology: Information Processing
for the Pentagon, 1962-1986 (Baltimore, MD: Johns Hopkins
University Press, 1996). It has also been examined by journalists
focusing on the computer talents of a small group of employees
at Bolt Beranek and Newman (BBN), the contractor for the underlying
network technology; see K. Hafner and M. Lyon, Where Wizards
Stay Up Late: The Origins of the Internet (New York: Simon
and Schuster, 1996). The transition from ARPANET to the Internet
and the flexibility of the network technology are covered
by J. Abbate, Inventing the Internet (Cambridge, MA:
MIT Press, 1999).
and O'Neill, Transforming Computer Technology.
shift of focus on an institutional rather than social interpretation
of "communication" is reminiscent of early views
of the telephone as a business tool rather than social device;
see C. S. Fischer, America Calling: A Social History of
the Telephone to 1940 (Berkeley: University of California
Press, 1992). Similarly, the initial design of the French
Minitel system emphasized instrumental rather than social
communication over computer networks; see A. Feenberg, "From
Information to Communication: The French Experience with Videotex,"
in Contexts of Computer-Mediated Communication, ed.
M. Lea (London: Harvester-Wheatsheaf, 1992), 168-87.
J. Pinch and W. E. Bijker, "The Social Construction of
Facts and Artifacts: Or How the Sociology of Science and the
Sociology of Technology Might Benefit Each Other," in
The Social Construction of Technological Systems, eds.,
W. E. Bijker, T. P. Hughes, and T. J. Pinch (Cambridge, MA:
MIT Press, 1987), 17-50.
Rosenzweig, "Wizards, Bureaucrats, Warriors, and Hackers:
Writing the History of the Internet," The American
Historical Review 103 (1998): 1530-1552.
have defined recurring acronyms and technical terms in Appendix
of the works examining email are Abbate, Inventing the
Internet; T. Bardini, Bootstrapping (Stanford,
CA: Stanford University Press, 2000); Hafner and Lyon, Where
Wizards Stay Up Late; Norberg and O'Neill, Transforming
Computer Technology; M. T. Rose, The Internet Message:
Closing the Book with Electronic Mail (Englewood Cliffs,
NJ: Prentice Hall, 1993); and P. H. Salus, Casting the
Net: From ARPANET to Internet and Beyond. (Reading, MA:
Addison-Wesley Pub. Co., 1995), among others.
Inventing the Internet.
E. Agre, "Conceptions of the User in Computer Systems
Design," in The Social and Interactional Dimensions
of Human-Computer Interfaces, ed., P. J. Thomas (Cambridge:
Cambridge University Press, 1995), 67-106.
A. Norman, The Design of Everyday Things (New York:
D. Hellige, "From SAGE via ARPANET to ETHERNET: Stages
in Computer Communications Concepts between 1950 and 1980,"
History and Technology 11 (1994): 49-75.
M. Fano and F. J. Corbato, "Time-Sharing on Computers,"
Information (A Scientific American Book (San Francisco:
W.H. Freeman, 1966): 76-95. [Quote on p. 80.]
In this figure, the T represents a "dumb"
terminal of the era, with which a user would access an email
program (or other software) on a mainframe computer. Figure
from V. G. Cerf, "Internetting and Electronic Message
Systems," paper presented at the AFIPS Workshop on Technical
and Policy Issues in Electronic Mail and Message Systems,
Washington, DC, 1980. Current email systems use a different
"client-server" technology, in which the "client"
is a personal computer that transfers complete email messages
to and from the email "server" (which temporarily
stores messages) as needed.
and O'Neill, Transforming Computer Technology, 174.
and O'Neill, Transforming Computer Technology. The
Information Processing Techniques Office (IPTO), an agency
of DARPA, guided the original development of the ARPANET and
was instrumental in early computer developments such as time
sharing, networking, graphics, artificial intelligence, and
parallel-processing. On the innovative nature, within the
military context, of IPTO management, see Norberg and O'Neill,
Transforming Computer Technology and J. E. O'Neill,
"The Role of ARPA in the Development of the ARPANET,
1961-1972," IEEE Annals of the History of Computing
17:4 (1995): 76-81. The Advanced Projects Agency (ARPA) was
founded in 1958 in response to Cold War concerns about falling
behind in military technology and to stimulate military research
in response to the Soviet Union's Sputnik. ARPA's name was
changed to DARPA (adding "Defense" at the beginning)
in 1971, back to ARPA in 1993, and back again to DARPA in
1996. See B. M. Leiner, et al., "The Past and Future
History of the Internet," Communications of the ACM
40:2 (1997): 102-108. ARPA, which had a very lean management
structure, sponsored high-risk projects without concern for
C. R. Licklider and R. Taylor, "The Computer as a Communication
Device," International Science and Technology
(April, 1968): 21-31.
Hafner and Lyon, Where Wizards Stay Up Late; and Norberg
and O'Neill, Transforming Computer Technology. Even
though closer collaboration was a goal, this was seen from
a functional rather than social perspective.
Network Measurement Center at UCLA studied the network traffic,
the Network Information Center at SRI coordinated administration,
and the Network Control Center at Bolt Beranek and Newman
(BBN) monitored the network's operational status and handled
IMP upgrades. BBN, a consulting firm in Cambridge, MA, with
close connections to MIT, was the major contractor for the
ARPANET's underlying technology (it received contracts for
the IMPs and NCC). Licklider, the IPTO's first director in
1962, originally worked for BBN. See Hafner and Lyon, Where
Wizards Stay Up Late; and Norberg and O'Neill, Transforming
and O'Neill, Transforming Computer Technology, 156.
Crocker, RFC 1: Host Software (Network Working Group,
Crocker, RFC 3: Document Conventions (Network Working
Group, 1969), 1.
and Lyon, Where Wizards Stay Up Late, 144-5, italics
et al., "Past and Future History."
and Lyon, Where Wizards Stay Up Late.
Heart, interview conducted by Judy E. O'Neill, Cambridge,
MA., 13 March 1990, OH 186 (Minneapolis, MN: Charles Babbage
Institute, University of Minnesota).
ARPANET Network Information Center was located at Stanford
Research Institute in Menlo Park. The NIC's "mandate
was to act as a depository and dissemination center for network
information, particularly documents, and to make this information
available to network users," from E. J. Feinler, "The
Identification Data Base in a Networking Environment,"
paper presented at the National Telecommunications Conference,
New York, 1977. The choice of SRI was influenced by the presence
of Doug Engelbart's NLS team (see Appendix B), but Engelbart's
interest in cultivating a large group of ARPANET users for
the specialized NLS system was not successful because of the
overriding interest among users in standards linking heterogeneous
systems; see Bardini, Bootstrapping.
challenges of the NIC's information dissemination role are
apparent in the RFCs it released. RFC 95: Distribution
of NWG/RFCs Through the NIC (4 February 1971) describes
the postal process, while RFC 185: NIC Distribution of
Manuals and Handbooks (7 July 1971) asks for assistance
in making copies of large documents for distribution. RFC
511: Enterprise Phone Service to NIC From ARPANET Sites (23
May 1973) describes spending about $800/month on providing
(voice) telephone access to the NIC for assistance calls from
selected ARPANET sites, and problems with the answering service
used during off hours.
W. Watson, RFC 196: A Mail Box Protocol (Network Working
Postel, RFC 580: Note to Protocol Designers and Implementors
(Network Working Group 1973).
E. Kahn, A. Vezza, , and A. D. Roth, eds., AFIPS Workshop
on Technical and Policy Issues in Electronic Mail and Message
Systems, (Washington, DC: American Federation of Information
Processing Societies, 1980).
and O'Neill, Transforming Computer Technology, 178.
J. Lukasik, "Organizational and Social Impact of a Personal
Message Service," paper presented at the National Telecommunications
Conference, New York, 1974: 386
R. Panko, and R. U. Panko, "An Introduction to Computers
for Human Communication," paper presented at the National
Telecommunications Conference, New York, 1977.
D. Crocker, RFC 822: Standard for the Format of ARPA Internet
Text Messages (Network Working Group, 1982); J. Postel,
RFC 821: Simple Mail Transfer Protocol (Network Working
Group, 1982); and R. Braden, RFC 1123: Requirements for
Internet Hosts-Application and Support (Network Working
Lampson, "Personal Distributed Computing: The ALTO and
Ethernet Software," in A History of Personal Workstations,
ed., A. Goldberg, (New York: ACM Press, 1988), 291-344.
S. Raymond, and G. L. Steele, eds., The New Hacker's Dictionary
(Cambridge, MA: MIT Press. 1991).
and Steele, The New Hacker's Dictionary, 4-5.
E. Denning, "Concerning Hackers Who Break into Computer
Systems," paper presented at the 13th National Computer
Security Conference, Washington, DC., October, 1990.
and Steele, The New Hacker's Dictionary.
212. ITS is the acronym for "Incompatible Timesharing
System," an operating system "written for PDP-6s
and PDP-10s at MIT and long used at the MIT AI lab."
Nelson, Computer Lib/Dream Machines (Chicago, IL: Self
published, 1974), 12, emphasis in original. Here, Nelson is
emphasizing the user as opposed to computer experts, although
he is also inadvertently reflecting the largely male-oriented
computer culture. I address gendered user constructions later
in this article. See also T. Bardini and A. Horvath, "The
Social Construction of the Personal Computer User," Journal
of Communication 45:3 (1995): 40-65.
and Steele, The New Hacker's Dictionary, 234.
rare example of an attempt to enforce a standard was RFC
733: Standard for the Format of ARPA Network Text Messages.
This RFC was "supported by the Defense Advanced Research
Projects Agency of the Department of Defense, under contract
Nos. N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181,"
and was written by a subcommittee of ARPA's Committee on Computer-Aided
Human Communication (CAHCOM). Another example of funding was
minimal support for the moderator of MsgGroup, the online
discussion group examined in this paper.
case study was conducted as part of my doctoral research.
MsgGroup archives were made available by The Computer Museum
in Boston (now part of the Museum of Science, Boston). Details
about MsgGroup, including its context, participants, and lifecycle,
as well as further information about my research methodology
for this case study, are in J. Kilker, "Networking Identity:
A Case Study Examining Social Interactions and Identity in
the Early Development of Email Technology" (Ph.D. diss.,
Cornell University, Ithaca, NY, 1999). An analysis of design
identities and their implications for collaborative development
based on MsgGroup interactions is published in J. Kilker,
"Conflict on Collaborative Design Teams: Understanding
the Role of Social Identities," IEEE Technology and
Society 18:3 (1999): 12-21. A popular account of MsgGroup
and the development of networked email are in Hafner and
Lyon, Where Wizards Stay Up Late. Dave Farber and many
other MsgGroup and Header-People (a parallel group) participants
were and remain influential in Internet circles, although
they have received varying degrees of attention and acknowledgement.
Participants Einar Stefferud, Ken Harrenstein, Dave Farber,
Richard M. Stallman, Richard Gumpertz, Raymond Panko, Mark
Crispin, Rich Zellich, and David Crocker kindly responded
to my requests for interviews.
my interviews of former MsgGroup participants, the central
role of MsgGroup and parallel more technically-oriented group
Header-People in email development were described as follows:
[MsgGroup] was *the* list - lots of other
traffic took place on it because there were no other pertinent
lists. Other mailing lists that were formed at the beginning
stayed pretty much on topic, because people were already
using MsgGroup as the catchall forum (sort of an "everybody
who is anybody is on MsgGroup, so that's the place to ask
my question" situation). It was also probably the most
serious and important set of discussions going on at the
time, too (Richard Zellich, personal communication, 1998).
At the time, [MsgGroup] was *the* place
for discussion of these issues. I was actively involved
in implementing and maintaining email systems and other
ARPANET systems at UCLA and/or Rand at the time (depends
on the period we're talking about), and we all represented
a pretty small universe in absolute numbers back then. It
was natural for those involved to participate in the group...
(Lauren Weinstein, personal communication, 1998).
I designed the MU mail program for Unix
and participated in the design and roll-out of MM for TOPS-20
and DEC's product MS. MsgGroup played a part in all three
programs (Stuart McLure Cracraft, personal communication,
I would say that between MsgGroup and Header-People
nine-tenths of the development of interoperability standards
was there. In terms of development of how email worked,
that sort of thing (Richard H. Gumpertz, personal communication,
A more tempered view is that MsgGroup facilitated rather
than broadened the participation in email development. A
long-time member of MsgGroup noted that
We all knew each other, both professionally
and personally. ... MsgGroup was one of the means that we
used to communicate with each other. It was the collection
of people, not the mailing list, that caused the influence.
We would have all known each other even without MsgGroup;
it was however a useful vehicle (Mark Crispin, personal
messages are cited in this manner with message index number
and date sent information. The group's moderator inserted
a sequential index number in the message's subject line and
archived all messages; for unmoderated messages (those sent
after the list was automated) I extended this indexing system
to identify all archived messages. The final index numbers
range from #1 on June 7, 1975 to #2578 on June 11, 1986. I
do not attribute online discussion quotes even though these
discussions were "public" and there was little,
if any, expectation of anonymity. At the time of this writing,
the Computer Museum (now part of the Museum of Science, Boston)
Web site maintains copies of these files at http://www.tcm.org/msggroup/.
clarify meaning, I have made only minor corrections to spelling,
grammar, and typographical case. The archived messages often
contain errors because their authors either were typing informally
or could not correct their typing. People using older messaging
systems, for example those based on Teletype terminals, noted
that they could not easily review messages before sending
Stefferud, a computer management consultant with a professional
interest in email, was subcontracted to maintain the list
and was initially paid a token sum by ARPA for his efforts.
The group's day-to-day maintenance requirements were high
because of the rudimentary mailing list technology at the
time and because of the steps necessary, at least in the group's
early days, to index and archive the messages. The moderator's
role varied depending on the technical structure of the discussion
list which changed both as the technology matured and other
people assisted in providing technical resources. From 1975
until early 1979, the moderator sent administrative messages
to the group indicating address additions, removals, or changes
(for those who wanted or needed to use address directly) and
was responsible for redistributing the group's messages. In
February 1979, the list was converted to an automatic redistribution
list based at MIT when the moderator went on vacation (#824;
#828, 25 February 1979) and in July 1982, the list was moved
to a Ballistics Research Labs (BRL) site (#1797, 17 August
1982). While the moderator guided the discussion at times,
there is no evidence from the postings or my subsequent interviews
that he excluded messages.
boundaries and overlaps among these groups are discussed in
Kilker, "Networking Identity." The existence of
"Header-People" demonstrated the challenges of email
in undermining traditional organizational structures. The
group was controversial among ARPA administrators because
of both its unofficial nature and the emotional intensity
of its technical discussions. According to "Header People"
founder Ken Harrenstein, archives of the group exist on 7-track
computer tape, a format for which it is exceedingly difficult
to find a reader. This problem of the gradual loss of digital
data as the storage technology (data readers, the media, and
the standards) becomes obsolete is increasingly common; see,
for example, comments about the apparent loss of early Usenet
articles in J. S. Quarterman, The Matrix: Computer Networks
and Conferencing Systems Worldwide (Bedford, MA: Digital
Press, 1990), 244-5. Harrenstein was able to locate printouts
of the group's early discussions and send me photocopies;
I used these messages in addition to those from MsgGroup.
use "membership" loosely here, as membership in
the list was neither formalized nor exclusive (beyond the
inherent exclusivity of access to ARPANET email).
Vallee, H. M. Lipinski, and R. H. Miller, Group Communication
through Computers; Volume 1: Design and Use of the FORUM System
(R-32) (Menlo Park, CA: Institute for the Future, 1974).
define substantive threads as having five or more messages;
shorter threads typically contained "For Your Information"
exchanges rather than discussions. Discussion topic threads
are cited by dominant subject title, dates of first and last
message, and total number of messages in the thread.
focused on the identification and categorization of developers
and users of email technology present in MsgGroup and early
discussions on Header-People. My methodology involved developing
a database of MsgGroup's participants with identifying information
(both self-described and from other sources) and descriptive
membership statistics, developing a database of messages contributed
to the group, and categorizing the group's discussion threads
by their social and technical content. I then used these databases
to identify message threads, themes, and social identifications.
Obtaining background and role information about each member
involved gathering information from that person's and other
people's postings, as well as examining RFC documents and
using present-day searches on the Internet to locate online
CVs. I was not able to locate any information for 175 of the
329 contributors to the group; 126 of them were either people
who contributed a single message without any identifying information
whatsoever (118 cases) or were on the group's distribution
list but did not contribute a single message (8 cases). The
development of these databases was complicated and time-consuming
for the following reasons, some of which were due to the specific
research context and some of which are likely to be shared
by other research projects on long-term online groups: (1)
key terminology-such as that for "messaging systems"-varied
substantially during this period, see Panko and Panko, Computers
for Human Communication; (2) the standards used in the
email headers (such as the date formats) changed during the
ten years; (3) regular distribution lists for the list were
not available; (4) people had others post messages for them,
or posted documents with multiple authors; (5) people could-and
did-post messages from different mailbox addresses, including
those of other group members; (6) people neglected to "sign"
their messages with identifying information; (7) people disappeared
from the group for long periods of time; and (8) some people
received messages from the list through intermediaries rather
than directly through the distribution list, either forwarded
by colleagues or through mailboxes on the list-RdMail@CMUA
(#887), and MsgGroup@ECL, RAND-MsgGroup@RAND-UNIX, Future-NET@SRI-KL
and MsgGroup@UDEL- that either rebroadcast or archived messages
from the group (there were at least five such mailboxes).
Despite these challenges, I was able to create reasonably
comprehensive databases summarizing the group's activities.
messages are cited in this manner with message subject and
date sent information. There are no index numbers because
Header-People had no moderator. For reasons noted earlier,
the Header-People archives are not currently available in
and O'Neill, Transforming Computer Technology, 270.
in programmer and the Department of Defense views about work
habits and security were addressed in several MsgGroup threads.
One of these (16 to 17 December 1979, 13 messages) describes
the challenges programmers faced when they needed assistance.
In it, a participant noted that most serious problems occurred
at odd hours when people were difficult to locate by telephone
but might be online. He complained about another person's
message: "Buried in your message was the implication
that those 'odd' hour people are just hackers who should be
willing to wait for the 'real' day if they want to do any
serious work" (#1435, 16 December 1979).
In a later thread entitled "ARPANET access control"
(19 to 20 March 1980, 11 messages), an SRI participant wrote
that a "collection of hosts on the east coast at a well
known institute [MIT]" give out accounts to "randoms
[who] try their sharp hands at cracking and breaking into
the various systems around the net" (#1489, 19 March
1980). His example problems caused by "randoms"
The piece de resistance of this was when
Col. [name] was director of IPTO at ARPA, we got a link
from "him" supposedly on the AMES-TIP via RSEXEC,
which said "your contract has been canceled, and your
host will be removed from the net". The other piece
de resistance was a link from "the almighty himself"
from the UTAH-TIP (#1489, 19 March 1980).
these are my analytical categories, they summarize terms used
by group members who identified themselves during polarizing
discussions and in introductions.
and Hovarth, "Social Construction of the Personal Computer
messages end with secretarial initials such as "TOE/ph"
(#7, 10 June 1975).
Pogran, J. Vittal, D. Crocker, and A. Henderson, RFC 724:
Proposed Official Standard for the Format of ARPA Network
Messages (Network Working Group, 1977), 26.
RFC 822, 37.
L. Janus, Groupthink: Psychological Studies of Policy Decisions
and Fiascos (Boston: Houghton Mifflin, 1982).
C. Cochrane, Measures for Progress: A History of the National
Bureau of Standards (Washington, DC: U. S. Department
of Commerce, 1966), iii.
The Internet Message.
NLS/AUGMENT, see D. Engelbart, "The Augmented Knowledge
Workshop," in A History of Personal Workstations,
ed., A. Goldberg (New York: ACM Press, 1988), 185-232.
On FORUM, see Vallee, et al., Group Communication through
Computers. On EIES, see S. R. Hiltz and M. Turoff, The
Network Nation: Human Communication via Computer (Reading,
MA: Addison-Wesley Publishing, 1978). On MARS, see J. Sattley,
RFC 744: MARS - A Message Archiving and Retrieval Service
(Network Working Group, 1978).
Easterbrook, "Coordination Breakdowns: How Flexible is
Collaborative Work?" in CSCW Requirements and Evaluation,
ed., P. Thomas (New York: Springer-Verlag, 1996), 91-106.
[Quote on p. 94.]
in-person groups officially sanctioned by IPTO, Message Service
Committee and CAHCOM, were chaired by established computer
scientists and had limited memberships. Some in-person meetings
about email were reported in RFCs (see Appendix C). This
exclusivity, based on traditional goal-oriented meeting styles,
alienated members of the wider ARPANET community who were
charged with implementing the standards, yet perceived that
they had little influence on them; the founder of Header-People
summarized his impressions about standard creation as follows:
"My sense is that most of the decisions were arrived
at by a few people in back rooms" (Ken Harrenstien, personal
communication, 1998) and MsgGroup's moderator noted:
In general, actual standards in those early
days were a result of ARPA funded research groups, so the
actual drafting of specs was done outside MsgGroup, though
some discussions were threaded through MsgGroup discussions
(Einar Stefferud, personal communication, 1998).
The latter comment is supported by the partial overlap in
MsgGroup participation and in-person meeting attendees (see
Appendix C). Complaints about the exclusivity of standard
discussions became particularly apparent when programmers
encountered problems that were attributed to the lack of openness
in the process.
Control Protocol/Internet Protocol (TCP/IP) is the Internet
protocol suite developed between 1973 and 1981 partly under
ARPA sponsorship; see V. G. Cerf and R. Kahn, "A Protocol
for Packet Network Interconnection," IEEE Transactions
on Communication 22:5 (1974): 637-648. These protocols
provided a robust communications architecture and one "that
could accommodate multiple types of communications services
over a wide variety of networks"; from Quarterman, The
Matrix, 48. The ARPANET implemented TCP/IP in early 1983
(the official switchover was January 1, 1983, but some sites
were delayed); this facilitated its interconnection with other
networks and transformed the ARPANET into the Internet.
responsibility shifted slightly-not always IPTO in later years.
and O'Neill, Transforming Computer Technology.
Malkin, RFC 1718: The Tao of IETF: A Guide for New Attendees
of the Internet Engineering Task Force (Network Working
Chapin, RFC 1310: The Internet Standards Process (Network
Working Group, 1992), 3.
Crocker, "Making Standards the IETF Way," StandardView,
1:1 (1993): 48-54.
Research Council, National Collaboratories: Applying Information
Technology for Scientific Research (Washington, DC: National
Academy Press, 1993).
from early online discussion lists are important for both
their under-examined perspectives and because of the lack
of accessible official documents. For example, Norberg and
O'Neill, computer historians with access to and funding from
the DoD for IPTO research, noted that "not only are the
IPTO records incomplete but, more important, they vary in
content and quality over the twenty-five years of [our] study."
See Norberg and O'Neill, Transforming Computer Technology,
S. Lukesh, "Email and the Potential Loss to Future Archives
and Scholarship or the Dog that Didn't Bark," First
Monday 4:9 (1999). Available: http://www.firstmonday.org/issues/issue4_9/lukesh/index.html.
Borsook, "How Anarchy Works," Wired 3 (October,
1995): 110-118; Crocker, "Making Standards the IETF Way."
and Lyon, Where Wizards Stay Up Late.
Jakobs, R. Procter, and R. Williams, "Users and Standardization:
Worlds Apart? The Example of Electronic Mail," StandardView
4:4 (1996): 183-191. [Quote on p. 191.]
A: Glossary and acronym list
ARPA The Advanced Research Projects Agency
(at certain times retitled "DARPA")
BBN Bolt Beranek and Newman
BRL Ballistics Research Laboratory
CAHCOM Computer Aided Human Communication
CCA The Computer Corporation of America
CMU Carnegie Mellon University
DARPA See ARPA
DEC Digital Equipment Corporation
IETF Internet Engineering Task Force
IMP Interface Message Processor; compare with TIP
IPTO The Information Processing Techniques Office,
part of ARPA
ITS "Incompatible Timesharing System"
MSG First all-inclusive email program providing replying,
forwarding, and filing capabilities.
MsgGroup Message Group, an online discussion list for
issues related to email development.
NIC Network Information Center, at Stanford Research
NLS The oN-Line System, Engelbart's innovative-but
system at the Stanford Research Institute. It was accessible
on the ARPANET, but only operated on specific host computers.
NCC Network Control Center, at BBN
RD First email management program which listed and
allowed selective reading, forwarding, and responding to messages.
Written by Larry Roberts in 1973 while IPTO director.
RDMAIL Carnegie Mellon University's mail reader
RFC Requests For Comment. These documents, most of
which are available online, were started by Steve Crocker
(then a graduate student at UCLA) in April 1969 to document
the efforts of the informal Network Working Group.
SAGE Semi-Automatic Ground Environment, a computerized
air defense system.
SAIL Stanford's Artificial Intelligence Laboratory
SMTP Simple Mail Transport Protocol originally specified
in RFC 821 (J. Postel, 1982). It defines how the envelope
for delivering messages in RFC 822 format, and how to perform
SNDMSG An early intra-machine email program by Ray
Tomlinson of BBN for use on individual PDP-10s; in 1972 he
modified it to send messages across machines, setting the
stage for networked email.
TIP Terminal Interface Message Processor; compare with
Appendix B: Networked email technologies
These tables provide a select overview of email and computer
conferencing technologies, and what connection, if any, their
developers had with MsgGroup. This list is not comprehensive;
for more information about email technologies and conferencing
systems see J. S. Quarterman, The Matrix: Computer Networks
and Conferencing Systems, 1990; M. A. Sirbu, "A Survey
of Electronic Mail Technology," in Electronic Mail and
Message Systems: Technical and Policy Perspectives, eds, R.
E. Kahn, A. Vezza, and A. D. Roth, 1981; and Appendix A of
J. Postel, RFC 808: Summary of Computer Mail Services Meeting
Held at BBN on 10 January 1979, 1982.
"Mailbox" programs were
available on early timesharing systems such as CTSS
at MIT's Project MAC. See R. M. Fano and F. J. Corbato,
"Time-Sharing on Computers," Information
(A Scientific American Book), 1966: 76-95.
Doug Engelbart's oN-Line System (NLS)
developed at SRI beginning in 1963, funded by ARPA.
NLS was an "integrated office automation system,
offering extensive document composition tools, forms
systems, and other office-related tools" (#474,
18 March 1977). NLS was later renamed AUGMENT in the
1970s and transferred to the Tymshare network, owned
by McDonnell Douglas. Engelbart was on the MsgGroup
distribution list, but did not contribute to the group.
Many NLS/AUGMENT developers and users were long-term
members of MsgGroup.
||SRI included Journal
Mail in its NLS collaboration system "to distribute
messages, pre-prepared documents, data, line-drawn pictures,
and other information" (#474, 18 March 1977). This
was a "very sophisticated mail system with user
identification, catalogs, and all sorts of fields that
you could use to send and answers things.
could send whole documents." From D. Engelbart,
"The Augmented Knowledge Workshop," in A
History of Personal Workstations, ed., A. Goldberg,
1988, p. 212.
||Ray Tomlinson of BBN
developed message sending program SNDMSG and reading
program READMAIL for BBN's TENEX operating system for
the DEC PDP-10 (#474, 18 March 1977). Tomlinson was
not an MsgGroup member.Jacques Vallee and colleagues
at Institute for the Future first implemented FORUM
group communication system; first "real world"
version 5 was available on the ARPANET in 1973; see
Vallee, et al., Group Communication Through Computers,
vol. 1, 1974. Two people associated with the FORUM project,
Paul Baran and Dave Farber, were involved with MsgGroup
(the latter as founder). FORUM had a very limited presence
on the ARPANET after 1974 (#474, 18 March 1977).
Networked Email Technologies
||Larry Roberts, IPTO Director, developed
RD based on Tomlinson's SNDMSG and READMAIL; RD was
coded in TECO (a text editing program) macros (#474,
18 March 1977). Roberts was not an MsgGroup member.
Martin Yonke and John Vittal at USC's
Information Sciences Institute (ISI) wrote WRD, and
Yonke wrote BANANARD. Vittal was a member of MsgGroup.
James Calvin of Bolt Beranek and
Newman wrote HG (the chemical symbol for mercury).
Ted Myer, also of BBN managed the development of MAILSYS,
which became the ARPA-sponsored HERMES (Military Message-Handling
Experiment) project. Both HG and HERMES systems combined
mail reading and composing functions. Hermes was available
to non-ARPANET users via Telenet, a commercial network
based on ARPANET technology and owned by BBN. Myer
and several others involved with the HERMES project
were members of MsgGroup.
John Vittal wrote MSG, a popular
ARPANET message-reading program. Vittal was a member
Mike Brooz, working under Al Vezza
of MIT's Dynamic Modeling System project, developed
a message program called MSGDMS which handled large
message databases and automatic archiving. Vezza was
an early member of MsgGroup.
Carnegie-Mellon's RDMAIL program
developed by Phil Karlton, based on Vittal's MSG,
with later assistance from students in the CMU Computer
Science department. Karlton and several other CMU
programmers/students were MsgGroup members.
Dave Crocker of Rand Personal Computing
project began development of MS message system. Crocker
was an MsgGroup member. See T. H. Myer and J. Vittal,
"Message Technology in the ARPANET," paper
presented at the National Telecommunications Conference,
New York, 1977.
New Jersey Institute of Technology's
collaboration-oriented Electronic Information Exchange
System (EIES) began operation. EIES was based on an
earlier system, EMISARI, designed for crisis management.
There was an extremely limited presence of EIES developers
late in MsgGroup's existence. See S. R. Hiltz and
M. Turoff, The Network Nation: Human Communication
via Computer, 1978.
||Swedish National Research Institute's
COM conferencing software developed based on EIES. Subsequently
revised as PortaCOM (1984), SuperKOM (1989) and KOM-96;
partially funded by European Community (EC) and used
mainly at European academic sites. Jacob Palme, COM's
development manager, was a late member of MsgGroup,
and a few other COM users participated.
Rand Message Handling (MH) system
developed by Bruce Borden, Stockton Gaines, and Norman
Shapiro. MH comprised a flexible set of programs each
having a different task and usable from within the
UNIX shell. (In 1981, UC Irvine began developing MH.)
Gaines was a member of MsgGroup.MMDF (Multi-channel
Memo Distribution Facility) designed by Dave Crocker,
Ed Szurkowski, and Dave Farber. MMDF later implemented
the SMTP (Simplified Mail Transport Protocol) for
MMDF was also used by MAILNET, a
joint project of MIT, EDUCOM, and fifteen sites with
funding from the Carnegie Foundation. MAILNET was
an "inexpensive mail network connecting heterogeneous
computer systems at academic institutions" until
1986; from J. S. Quarterman, The Matrix, 1990,
p. 146. Crocker and Farber were MsgGroup members.
Doug Brotz, Roy Levin, Mike Schroeder,
and Ben Wegbreit build the Laurel user mail system
for the Xerox Alto. Brotz was an MsgGroup member.
See B. Lampson, "Personal Distributed Computing:
The ALTO and Ethernet Software," in A History
of Personal Workstations, ed., A. Goldberg, 1988:
Eric Allman developed Sendmail, an
internetwork mail router that handles converting mail
formats and address structures. Subsequent versions
now route and deliver most Internet email. Allman
was briefly a member of MsgGroup after developing
the initial version of Sendmail. See E. Allman, Sendmail,
an Internetwork Mail Router, (Unix Programmer's Manual
||CSNET email implemented.
Pine, a "simple, easy-to-use
mailer for administrative staff at the University
of Washington in Seattle" was developed for UNIX
by the university's Office of Computing and Communications
(it was ported to PC-DOS in 1993). Part of the software-the
"C-Client library and IMAPd"-was authored
by Mark Crispin, a former member of MsgGroup, at UW
Seattle. Crispin originally authored the Message Access
Protocol (IMAP), which provides a way to manipulate
mailboxes on remote servers as if they were local.
The other Pine developers were not MsgGroup members.
In "the 80's" Steve Dorner
created the Eudora email client at the University
of Illinois at Urbana Champaign (as well as PH, an
Email and telephone directory program). In 1992, Dorner
left for the Qualcomm Corporation, which now owns
the rights for Eudora. Dorner was not an MsgGroup
Appendix C: Overlap of in-person meetings
||February: In-person meeting held at
SRI-ARC to discuss network mail system specifications
using FTP. See M. D. Kudlick, RFC 469: Network Mail
Meeting Summary, 1973.
||Four of the 15 attendees
were later MsgGroup members.
||January: In-person meeting held at
BBN to discuss the "state of computer mail in the
ARPA community and to reach some conclusions to guide
the further development of computer mail systems such
that a coherent total mail service would continue to
be provided." From J. Postel, RFC 808: Summary
of Computer Mail Services Meeting Held at BBN on 10
January, 1979, 1982, p. 1.
||Twelve of 33 attendees
were MsgGroup members; most attendees were from non-academic
institutions such as BBN, ARPA, and RAND, although two
MIT hackers were present.
||January: Two in-person meetings held
at USC Information Sciences Institute. The first, on
January 11, was to anticipate addressing of computer
mail as mail relaying was to become common with the
internet. See J. Postel, RFC 805: Computer Mail Meeting
Notes, 1982.The second, on January 12, was to "discuss
common interests in multi-media computer mail experiments,
and to agree on some specific initial experiments."
From J. Postel, RFC 807: Multimedia Mail Meeting
Notes, 1982, p. 1.
||Six of 22 attendees were
MsgGroup members.Three of 18 attendees were MsgGroup
||July: In-person meeting held at BBN
to address "progress by groups who are building
multimedia mail systems." From H. Forsdick, RFC
910: Multimedia Mail Meeting Notes, 1984, p. 1.
||None of the 12 attendees
were MsgGroup members; most were contractors.
Back to Top
| Table of Contents | Previous
Article | CBI Home