Julian Kilker
University of Nevada, Las Vegas
Date
published : 13 September 2002
Abstract: Behind
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.
Keywords:
interoperability, users, arrested closure, message systems,
networked email, ARPANET, collaborative standard development,
Request For Comment, RFC
I. Introduction
II. Defining identities and
software users
III. Collaboration in computer
networks
IV.
User identities
V.
Questioning the technical user's relevance
VI.
Conclusion
VII.
Notes and appendices
Introduction
Electronic
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.[1]
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."[2] [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.[3]
In September 2001, 45.2 percent of the U.S. population reported
using email.[4]
The familiarity
of networked email masks the technical and social challenges
that influenced its development during the early days of the
ARPANET.[5]
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.
The development
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.[6]
Email was an unexpectedly popular—but technically unsophisticated—application
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.[7]
This research
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.[8]
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 words—involved in
the networks' development deserve closer examination.[9]
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 used—ranging from the military to the
academic—were contexts with different norms for communication.
Groups and individuals influencing the ARPANET included the
Information Processing Techniques Office (IPTO)[10]
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
email—this important and multifaceted history, addressed
in passing in many works, remains to be comprehensively researched.[11]
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.[12]
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 standards—that
is, stabilization before sufficient perspectives were addressed—by
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.
The discussions
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.
Defining
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.[13]
Who are the experts who influence the design? What are the
relative influences of the programmers and the users?
While realistic
representations of users and uses are by no means the only
challenges to successfully rolling out new software—others
include the difficulty of large-scale testing and revising,
building a critical mass of users, high development costs,
and user resistance—it 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."[14]
[end of page 4]
The success of
some software—such as the graphical user interface—has
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
development.[15]
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.
Collaboration
in computer networks
Email technology
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
bombers.[16]
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]
Figure 1a.
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]
Figure 1c.
Rectangle "C" encloses multiple networks, as in
an internet.
One of the earliest
examples of email on such a system was MIT's Project MAC,
which allowed the
depositing
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
on command.[17]
[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.
Networking
heterogeneous systems
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.[18]
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.[19]
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.[20]
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"
software.[21]
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"
but
We
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 hand—the programmed digital computer.[22]
Inter-organizational
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.[23]
The original ARPANET contract was given to a distributed group
to encourage collaboration[24]
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."[25]
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.[26]
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
are expected."[27]
In RFC 3 of April 1969, entitled "Document Conventions,"
Crocker wrote:
The
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.[28]
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."[29]
ARPANET access
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.[30]
He is credited with selecting the "@" symbol to
designate the host to which the message should be transferred.[31]
This addition facilitated the use of email for inter-organizational
purposes.
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.[32]
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.
Initially network
documents were available both by email and by postal mail.
The Network Information Center (NIC)[33]
on the ARPANET did have an interface in the early 1970s to
send postal mail—a clerk would print and mail messages—but
this stopped because of high cost and an increase in online
mailboxes.[34]
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
and documents.[35]
This protocol also defined what would become "headers"
to provide information for a person to distribute the messages:
At
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
and distribute.[36]
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
proposed
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.[37]
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
and READMAIL.[38]
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."[39] [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."[40]
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).
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
9, 1977.
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."[41]
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.[42]
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.[43]
Identity
labels and technical proficiency
Time-sharing computers
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."
The following
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.[44]
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
was
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).[45]
Of these organizations,
the MIT AI Lab, SAIL, BBN, and CMU had members who participated
frequently in email development discussions. [end of page 12]
"Hacker"
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."[46]
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.'"[47]
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
perspective:
there
are two classes of people who work with a program: there
are implementers (hackers) and lusers [sic—see 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.[48]
Importantly, "user"
is a relative term: a "skilled hacker may be a user with
respect to some program he himself does not hack."[49]
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
exploration."[50]
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.[51]
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."[52]
However, later "one of the ITS machines supported 'luser'
as a request-for-help command."[53]
The "naïve
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."[54]
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."[55] [end of page 13]
Other identities
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.[56]
These identity
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.
Development
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.[57]
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.[58]
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.[59]
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
technical challenges.
MsgGroup started
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).[60] [end of page 14]
Formation of the
group was prompted by the following message from the IPTO
program manager:[61]
My
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.
My
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.[62]
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 group—they 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.[63]
MsgGroup's 329
contributors (about sixty of whom could be considered core
members because of the number of messages they contributed
or length of their membership)[64]
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
1980).
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
host.[65]
Group members
clearly felt that robust email standards should be developed
quickly before inferior existing technology propagated:
Make
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
1979).
Categorization
of email developers and users
While computer
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
discussion threads[66]
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).[67]
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 experiences—from different computer sites.
Using ARPANET email systems, both online groups enabled people
who would not normally interact—people who were not "Principal
Investigators" given travel reimbursement to attend face-to-face
meetings—to 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).[68]
Networking organizations
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."[69]
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.[70]
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.
MsgGroup's archived
discussions reveal two self-identified subgroups: administrative-oriented
professionals and technically-oriented hackers.[71]
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.
Organizational
identities
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:
CMU
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).
Hackers questioned
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:
HERMES
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).
The "decent
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).
The "Xerox
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.
User
identities
User identities
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 in—or just
observe—the 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
users."[72]
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).
Constructions
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 controversy—the
members repeatedly debated their representativeness as messaging
system users—group 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.
Constructing
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
1977).
I
am not a Computer Scientist. I am however one of those rare
birds, a USER, and also an interested onlooker (#993, 8
April 1977).
I
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:
[Much]
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).
Another member
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":
First
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).
Administrative
users differed from other users, such as hackers, in that
they—or their organizations—were paying customers
(#1066, 15 April 1979). Military users were a specialized
example of such an administrative user:
The
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 systems—or
to actually make them function—were 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:
I
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
1979).
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:
It
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).
Constructing
the naïve user
Although MsgGroup
members expressed concern about developing messaging systems
for "naïve," "novice," and "future"
users, representative ones were rarely—and in the last
case, not yet—available. 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
sympathetic perspective.
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 standardized—although still expandable—while
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.
The administratively-oriented
members viewed defining and catering to naïve users as
a prerequisite for marketing messaging systems to large organizations:
…the
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
1979).
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"):
[I]
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).
…one
of the really important issues in the controversy is "How
do we make it easy for all users—novice as well as
experienced—to find out what features are available,
and how they can best utilize them" (#809, 24 February
1979).
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.
For example:
It
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]
Differing constructions
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.[73]
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:
The
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).
And:
Call
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]
One
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:
George
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.[74]
An MIT hacker
in Header-People not only critiqued the RFC's technical aspects,
but also criticized the assumption that secretaries were women:
In
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 incorporated—in
addition to many technical modifications—revisions 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):
George
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.[75]
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.
Questioning
the technical user's relevance
The challenge
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]
I
am responsible for the implementation of BBN's mail system
…. Also I am a fairly extensive user of mail systems … (#250,
5 January 1976).
I
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).
[I
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
user comments.
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
member wrote:
Yes,
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).
Similarly, an
administrator distinguished between designer and user perspectives:
Designers
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).
Email's technically-proficient
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
responded.
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:
I
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).
Despite these
concerns, hackers only twice reported collecting data from
actual users.<
