Medium as Process: An Overview

The IBMPC computer conferencing facility first opened for business on October 8, 1981. Although the opening of the facility represented something of a landmark for IBM, the opening was a quiet one, and it was to be some weeks before the facility would record serious activity. The first week in which counting contributors would require the use of ten fingers didn't occur until December of that year, and there would never be more than 33 contributors in a week through the end of 1982 (the average number of contributors in 1982 was 15 per week).

This comparatively low volume (by comparison with today's IBMPC) counts both regular contributors (who probably had something to say nearly every week) and occasional contributors (who, at the extreme, may only have appended once ever). It may, however, be deceptively low, as it does not count noncontributing participants (those who read or used information on the facility, but never added any).

When it opened, IBMPC was the only computer conferencing facility in the company. The possibilities and conventions it pioneered would become the reality of other computer conferencing facilities, but the opening of a second such conferencing facility remained two years in the future. Its administrators would soon have a vision of what the facility might become, but no one was imagining a facility encompassing thousands of forums, tens of thousands of users, or volumes in excess of 1000 appends per day.

Indeed, no one thought enough of the events that followed its opening to record when some of the important things happened or who did them. Although the event is made possible by software that the founder of IBMPC, Walt Daniels, and others had been developing for several years, the opening was, in many ways, an accident of timing, an attempt to meet an emerging need with a recent innovation that exploited existing capabilities. The recent innovation was a new piece of software called TOOLS that automated the distribution of information. The existing capability was IBM's computer network, VNET, that allowed the distribution of information to thousand of computers around the world. The emerging need was information about IBM's new Personal Computer.

Finding information in the midst of innovation

IBM announced its IBM Personal Computer in August, 1981. The first IBM Personal Computers actually shipped to customers during the first week of October in that same year. There was little software available for the new computer, and even less information about how it worked. The demand for information and software was extreme, and the months immediately following first shipments of the IBM PC saw the emergence of a number of vehicles for the exchange and distribution of such information, including users groups, software exchanges, electronic bulletin boards, and magazines.

An example of the emergence of such vehicles can be seen outside IBM in, for instance, the Connecticut IBM Personal Computer User's Group. The beginnings of this group can be traced to casual meetings between early purchasers of IBM Personal Computers, all of whom shared the same problems of needing both better information and better software. Discussions of forming such a group started in November, 1981. The first meeting of the group was in February, 1982. The first exchange of member-contributed software occurred at its second meeting, in March, 1982. A newsletter emerged to announce the topic of the third meeting in April, 1982. A club electronic bulletin board opened for the first time in June, 1982.

The Connecticut IBM PC User's Group was hardly unique in this development. Dozens of similar groups formed around the U.S. at roughly the same time. Most initiated each of these forms of information exchange. Similar developments occurred inside IBM as well. The IBM PC was developed by a small team working outside normal company channels. As a result, the IBM PC was as much of a mystery to most IBM employees as it was to other prospective customers, and the same kinds of information channels emerged inside IBM that were emerging outside the company, including internal users groups and internal newsletters.

Perhaps the first such vehicle to formally open for business, however, was the IBMPC computer conferencing facility, which opened for business within a week of the IBMPC's first customer ship. The facility started when a member of the already existing Microcomputer Club at IBM Research adapted a newly developed on-line software distribution tool, called TOOLS, to provide an IBM internal electronic bulletin board called IBMPC.

At its opening, IBMPC was more an electronic repository of information than a true computer conference. It was possible to share information with others on an ongoing basis, but only through fixed documents that provided little opportunity for real interaction. For the first few months the facility was really little more than a collection of files, each containing information concerning one feature or another of the IBM Personal Computer and its software. Different people owned different files. As new information came in, file owners would add it by replacing the entire file. The TOOLS software provided the essential controls that allowed individuals to own, create, replace, delete, and get a file from a central repository, but it was nothing fancy.

The capabilities of TOOLS, at this early date, were rather less than those associated with electronic bulletin boards that could (even at that time) be called up from home by anyone with a telephone, modem, and microcomputer. In particular, there was no concept of an appendable file or forums that collected a series of appends from different individuals. The focus was clearly on the message, the sharing of information about the IBM Personal Computer, rather than the medium.

VNET: Main Street in an Electronic Village

The typical electronic bulletin board, in 1981 and today, is based around a microcomputer, a modem, a telephone, and some software. The person who wants to access that bulletin board uses a microcomputer, modem, telephone, and terminal software to call up the bulletin board. If the phone isn't busy, the electronic bulletin board answers the call, establishes modem to modem communication with the caller, and displays a menu of things that can be done on the bulletin board.

While the telephone company provides an extremely flexible network that allows the bulletin board user to access any one of thousands of currently active bulletin boards, most share the same fundamental limitations. Only one or a few individuals can access the bulletin board at a time, and if one person asks a question, for instance, they will usually have to call back another time to get the answer. They might, of course, leave their phone number if they'd like a more immediate answer, but no one can reach them if their phone is busy as they interact with various bulletin boards.

The environment in which IBMPC was started was very different. It was, like many computer conferencing systems, implemented on a timesharing system that allowed many people to use it at the same time. The mainframe computer that IBMPC was implemented on, YKTVMV, was the electronic home of several thousand IBM employees, and IBMPC was simultaneously available to any and all of these potential users. More importantly, however, YKTVMV was interconnected with hundreds (now thousands) of other mainframe computers throughout IBM via an internal communications network called VNET. This network made IBMPC available to many thousands of other potential users throughout the company.

The function of VNET, like BITNET, CSnet, EARN, ARPAnet and other computer networks, is to provide a continuous communication link between the users of diversely located computer systems. The connection offered by VNET offers a variety of capabilities, including the ability to access and, if you have a local user ID, use remote computer systems, much as one might dial up a microcomputer based electronic bulletin board with a modem and telephone. More important from the perspective of IBMPC, however, is network support that allows VNET to operate as a large real-time store-and-forward post office delivery system, allowing employees at almost any IBM location to exchange messages and files with other IBM employees.

In October, 1981, VNET had been in existence for over 6 years, had become an established feature of the IBM landscape, and was in the midst of rapid growth. Today over 90% of all IBM employees make use of VNET for electronic mail and document interchange. Indeed, survey results indicate that electronic mail may be second only to face to face communication as a mode of interpersonal communication within IBM. Use of VNET is not restricted by international boundaries. VNET nodes dot the globe. Indeed, the effect of VNET has been to turn IBM into a giant electronic village, in which employees in wildly disparate locations can and do exchange messages regularly.

Setting the stage for conferencing

A variety of experiments predate, and to a certain extent presage, the development of the TOOLS computer conferencing software. In one such experiment, Walt Daniels evolved MAINTAIN, a software facility that allowed for many individuals to share software through a central repository. IBMPC was initially implemented using MAINTAIN, but was quickly (within a few weeks) shifted over to TOOLS. In another experiment, electronic newsletters, an "editor" collected "articles" together and periodically mailed them out to a mailing list. In yet another experiment, the developer of a brand new computer language (REXX, now one of IBM's key development languages) used VNET to distribute language specifications and new versions of the language while collecting comments from volunteer testers.

These experiments were made possible, at least in part, by the development of REQUEST, a program that allowed individuals to distribute things (files, documents, programs, etc.) across the network more easily. To use REQUEST, the distributor needs only to create a "PACKAGE" file that describes the files that will be shipped to requestors. Once that is done, anyone who knows about a given package can request it by executing the REQUEST program, which sends mail (named XXX Request, where XXX is the name of the package requested) to a specified user ID. Requests are satisfied when the individual providing the package specifies the PROCESS option when running the REQUEST program (REQUEST PROCESS). When run in this manner, REQUEST scans the user's mail, looking for mail named "XXX REQUEST", and sends the requester the files listed for the requested package.

The effect of the REQUEST program is to reduce the amount of work the distributor of information has to do. It does not, however, automate the electronic distribution of information. It is no longer necessary to take notes on who has asked for something and then manually send the files. One now simply runs a command that services the requests that have been received. REQUEST is still generally manually invoked, however, requiring the distributor to remember to take action. The distributor must, moreover, wait while the REQUEST program runs. The requestor is often inconvenienced as well, as receipt of the requested package is dependent on the distributor's action. As a result, requesters frequently have to wait hours, days, or even weeks before the requested information is delivered.

TOOLS: The Innovation

The original TOOLS software attempted to overcome these limitations by fully automating software distribution. The approach is simple and derivative of both the mail-oriented distribution style of REQUEST and the software repository capabilities of MAINTAIN. This approach is important, as it makes a computer conference built with the TOOLS software accessible to anyone who can send mail to the conference, regardless of what computer they use or where they are located on the network. As implemented, however, TOOLS differs from REQUEST and MAINTAIN in several important ways.

Two programs from one

First, TOOLS is implemented as two separate programs, TOOLS and TOOLSRUN. TOOLS is an end-user program which accepts TOOLS commands and sends them to a designated node (a computer) and user ID (usually a person who uses that computer). TOOLSRUN is a request processing program that accepts mail sent by the TOOLS command and takes action based on the content of that mail. It is, in effect, the REQUEST PROCESS command expanded into a separate program.

Continuous operation

Second, TOOLSRUN is designed to run continuously. It assumes the use of a "shared" user ID which, from the standpoint of how it is used, belongs to no one in particular. This user ID runs the TOOLSRUN program. The TOOLSRUN program operates in a perpetual loop, looking for incoming mail and processing it as received. The user ID that operates TOOLSRUN is usually referred to as a TOOLSRUN machine.

This mode of operation transforms REQUEST PROCESS, whose operation is much like a telephone answering machine, processing a series of messages in a burst after they have collected for a while. TOOLSRUN operates more like a telephone answering service; attempting to satisfy each message as it is received. The action of the answering service may be as simple as taking a message. But it may also entail passing a message back to the caller or signaling the callee that something needs to be done.

Importantly, it also makes it possible to serve many masters. A telephone answering service can take messages and other actions for a large number of people. So can a TOOLSRUN machine. Where an invocation of REQUEST would typically distribute information for a single user running a program on a single user ID, TOOLS typically distributes information for many individuals, each with their own user ID, but their information distributed via a common TOOLSRUN machine.

Functions

Third, TOOLSRUN extends the concept of the request message to allow a variety of actions to be invoked via mail. The actions that could be used in the first version of TOOLS included (IBMPC MEMO, December 8, 1981):

LIST: This sends you a list of all or selected files on the IBMPC disk.
GET: This sends you the specified file from the IBMPC disk.
OWN: This sends an explicit request for ownership of a name. You will be prompted for a short description of the new file and its category.
REPLACE: This replaces a file or adds a file to the IBMPC disk. You will be prompted for a description of the changes that were made.
HIDE: This hides the file on the IBMPC disk. This is equivalent to erasing it, except that the file is renamed rather than actually erased - thus ensuring that a backup is available and also prevents someone who is reading that file from getting a disk error.
REGRESS: This undoes the last change you made. i.e. it hides (permanently) the specified file, and makes the backup copy the "current" copy again.
NEWOWN: This transfers ownership of a name to another user. You should specify the userid (or the node and userid) of the new owner as the first line of the description. The node and/or userid of the new owner may be specified as "*" to allow any (authorized) user to change the file.
CLEAN: This cleans up back up versions of files on the IBMPC disk.
METHOD: Specifies the method of communication used when sending messages to a TOOLSRUN machine (the existence of this command says more about the evolution of VNET, which has supported a number of message formats, than it does about TOOLS, which no longer supports this command).

Three types of user

This small set of commands considerably extends the capabilities of REQUEST, which only offered one of these options (GET), to support three distinct sets of users:

Requestors of information are able to obtain two kinds of information from a TOOLSRUN machine. They can obtain a LIST of the files that are available from the TOOLSRUN machine. They can GET any of the files that are available. LIST allows people who wish to participate in (get information from) a conference to find out what is there. When used on an ongoing basis, moreover, it allows users to see what has changed and what is new.
Contributors. The existence of contributors is, in many ways, TOOLS' key innovation over REQUEST. Contributors can establish a file on a TOOLSRUN machine with the OWN (now made obsolete by an improved CREATE command) command, which registers them as the owner of that file. Once a file is owned, the contributor can create or replace that file with the REPLACE command. Other commands allow a contributor of a file to control its availability (HIDE and REGRESS) or assign its ownership to someone else (NEWOWN).
There are two levels of contribution to IBMPC, each of which has a different set of responsibilities. A contributor is responsible for his or her own appends. A forum owner is responsible for keeping discussion within a forum within its topical constraints and the conference rules. The range of TOOLS commands and options which need to be mastered to function at these two levels varies. A contributor can frequently get by with knowledge of only one or two TOOLS commands. A file owner will frequtently have to master at least a half a dozen such commands.
Administrators. The people who are technically responsible for a TOOLSRUN machine are generally referred to as its administrators. IBMPC's administrators run the conference facility. They can usually take any action against any file on the TOOLSRUN machine, and have a special set of commands that are used to help keep the TOOLSRUN machine going. The first (and, at the time IBMPC opened, only) such command was CLEAN.
There are three variations of administrator. The first and most important is the management owner of the conferencing facility who takes responsibility for insuring that IBMPC is used for IBM management approved purposes. IBMPC has only had one formal management owner, Jerry Waldbaum. The other two roles are reviewer and administrator. The conference administrator worries about the operation of the conferencing facility's software and acts to insure that the medium doesn't stop working. The reviewer worries about the rules of the conferencing facility and acts to insure that they are observed by contributors. The conference administrator needs to have a good understanding of most of TOOLS commands and options. The reviewer need only understand a half dozen or so.
There need be no formal division between these roles. A single individual can act in all three roles if they are also an IBM manager. A single individual has acted as both administrator and reviewer of IBMPC at several points in its history. The administrators of IBMPC are responsible for creating and maintaining its formal rules. The role of the reviewer will be discussed in considerable detail in a later chapter.

These commands are sufficient to establishing an electronic library. It is possible for a large number of people to contribute and maintain documents. It is possible for large numbers of people to obtain the documents which have been contributed. They are not, however, sufficient to running a computer conferencing facility. The only way to change a file is to replace it entirely. The only people who can change the file are the file's owner and the conference administrators. It is not possible to have an ongoing conversation.

From Electronic Library to Computer Conference

With little information about the IBM Personal Ccomputer available, TOOLS offered the possibility of concentrating the information that did exist in a single centralized repository that would make it more accessible to large numbers of people. Because participation was a possibility for virtually anyone on VNET, moreover, IBMPC opened the possibility of obtaining information from unexpected sources. Hence while IBMPC was not a true computer conferencing facility during its first two months of operation, it provided a valuable service to a growing number of users even in its early months. IBMPC may, at this point, have been an electronic library where contributors published electronic documents, but the development of the system into a true computer conference was already underway.

The transformation to a computer conferencing facility occurred in early December, 1981, when Walt Daniels added the APPEND command to TOOLSRUN. APPEND, as documented in the original (December, 1981), IBMPC MEMO "appends a file to one of the same name already on the IBMPC disk." The implementation and action of APPEND is simple (and arguably even trivial, given the things already implemented in TOOLS). From the perspective of the contributor, the command sends a file to the IBMPC disk just as it would if the REPLACE command had been issued. From the perspective of the TOOLSRUN machine, the file received is simply added to the end of an existing file.

The effect of the APPEND command is also simple. It is not, however, at all trivial. APPEND allows IBMPC participants to use a file on a TOOLSRUN machine to have a conversation. It is in such conversation that IBMPC becomes a computer conferencing facility and the stage is set for its future growth.

The growth of IBMPC

If the opening of IBMPC is a landmark event for IBM, it is hardly apparent in its early use. IBMPC's history files show that the facility was accessed by fewer than 50 people in its early months, with little indication of accelerating growth until late 1982. The record may be deceiving, as a number of individuals in Yorktown are able to access the conference disk directly and undetectably. Still, it provides a baseline against which subsequent growth (shown later in this chapter) can be assessed. Even the most optimistic estimates don't place the early IBMPC community at more than 150 participants.

By the end of 1983, however, it was clear that use of IBMPC was accelerating fairly rapidly. Use of the facility had increased by a full order of magnitude from the usage levels of early 1982 and tripled from the usage levels of late 1982. In the week of September 19, 1983 (the first week of this participant observation), 95 different people ("appenders" or "contributors" in the vocabulary of IBMPC) made 150 contributions ("appends") to over 30 different "forums".

Variable estimated		Number of appends per week (unstandardized beta)	Standard Error of estimate	T-test of estimate	Probability of estimate
Intercept (Dec. 1981)	-66.597	36.19	-1.840	0.0666
Growth in 1983 & 1984	5.328	0.66	8.075	< 0.0001
Baseline since 1/1985	977.907	62.41	15.669	< 0.0001
Growth since 1/1985	15.541	0.50	30.740	< 0.0001

Phases in append growth on IBMPC: Linear Regression of weekly appends to IBMPC against three time measures of growth. Growth in 1983 & 1984 proceeds at an average rate of 5.3 appends per week per week. This growth establishes a new baseline for appends beginning in January, 1985. Growth since the beginning of 1985 proceeds at a rate of 15.5 appends per week. The mean for residuals (the intercept) does not differ significantly differ from 0.

Use of IBMPC accelerates exponentially during the period between early 1983 and early 1985. At the beginning of this period use of IBMPC accelerates at 1 or 2 appends per week per week. By the end of this period the acceleration of IBMPC is approaching 15 appends per week per week. The average acceleration in the append rate over the two year period is 5.3 appends per week per week. IBMPC also experiences an acceleration in the number of contributors (2.7 contributors per week per week) and number of files (2.1 files per week per week).

Variable estimated		Number of contributors per week (unstandardized beta)	Standard Error of estimate	T-test of estimate	Probability of estimate
Intercept (Dec. 1981)	-14.45	11.43	-1.264	0.2071
Growth in 1983 & 1984	2.66	0.20	12.794	< 0.0001
Baseline since 1/1985	453.38	19.71	22.992	< 0.0001
Growth since 1/1985	5.55	0.15	34.767	< 0.0001

Phases in contributor growth on IBMPC: Linear Regression of weekly contributors to IBMPC against three time measures of growth. Growth in 1983 & 1984 proceeds at an average rate of 2.6 additional contributors per week per week. This growth establishes a new baseline for contributors beginning in January, 1985. Growth since the beginning of 1985 proceeds at a rate of 5.55 new contributors per week. The mean for residuals (the intercept) does not differ significantly differ from 0.

Use of IBMPC increased by roughly an order of magnitude during this period. In the second week of 1985, 324 contributors make 636 appends to 271 files. It appears that IBMPC passes through the lower knuckle of the diffusion of innovation curve at about this time. The exponential increase in acceleration ends. The acceleration of IBMPC's use has been fairly constant since:

the rate of appends has been accelerating at 15.5 appends per week per week.

the number of contributors has been accelerating at 5.5 contributors per week per week.

the number of files appended to has been accelerating at 1.1 files per week per week.

Simple time series models of these phases in IBMPC's growth between October, 1981 and September, 1988 can account for:

92% of the variance in the number of appends (R**2=.9248, F=1450, df=3/354, p<3E-198). This model is shown in the first table above.

95% of the variance in the number of contributors(R**2=.9486, F=2177, df=3/354, p<2E-227). This model is shown in the table immediately above.

86% of the variance in the number of files on IBMPC. (R**2=.8583, F=714, df=3/354, p<9E-150). This model is shown in the table below:

Variable estimated		Number of files per week (unstandardized beta)	Standard Error of estimate	T-test of estimate	Probability of estimate
Intercept (Dec. 1981)	17.74	7.09	2.499	0.0129
Growth in 1983 & 1984	2.07	0.12	16.032	< 0.0001
Baseline since 1/1985	277.75	12.24	22.688	< 0.0001
Growth since 1/1985	1.18	0.09	11.903	< 0.0001

Phases in file growth on IBMPC. Linear Regression of the number of files changed on IBMPC against three time measures of growth. Growth in 1983 & 1984 proceeds at an average rate of 2.1 changed files per week per week. This growth establishes a new baseline for files beginning in January, 1985. Growth since the beginning of 1985 proceeds at a rate of 1.2 changed files per week. The mean for residuals (the intercept) does not differ significantly differ from 0.

The only oddity in these models is the decline in the acceleration in the number of files since 1985. There are two elements to this oddity, and both are easily explained. The real decline is attributable to the creation of the PCTOOLS software distribution facility. All software on IBMPC was moved to PCTOOLS in early 1985, and IBMPC stopped accepting software on the facility starting at that time.

Even with this attribution, however, the rate of increase in the use of individual forums seems low, as new forums are generally created on IBMPC at a rate of 2 or 3 a week. The relatively low 1.1 file per week acceleration in contribution to files on IBMPC appears to be a function of short duration and/or intermittent discussion on many forums. Many forums receive contributions only every few weeks or months. Other forums are abandoned entirely after a period of use. Some newly created forums never attract any interest, moreover, and appear in these statistics only once, in the week of their creation.

There is no evidence that IBMPC has reached the upper knuckle of the diffusion of innovation curve yet. Numbers of contributors, appends, and files continues to accelerate (see the figure below). In late 1988, the IBMPC computer conferencing facility is almost an order of magnitude larger than it was at the beginning of 1985. During the week of September 4, 1988 (the last week of data collection for the growth statistics explored here), 1397 contributors made 3526 appends to over 400 different forums.

Growth of IBMPC: The growth of the IBMPC computer conferencing facility, displayed as appends per week.

Growth of IBMPC: The growth of the IBMPC computer conferencing facility, displayed as maximum number of weekly contributors.

This growth continues unabated. Projections from the models presented here suggest that IBMPC will entertain 5000 appends a week by the beginning of 1990. In mid-1989, that projection looks quite safe. A 1000 append day was recorded in January, 1989. A 5000 append week has already been recorded. Regularly occurring 5000 append weeks seem probable in the near future. IBMPC remains today, as it was in 1983, one of the largest computer conferencing facilities anywhere.

Enhancements to the IBMPC conferencing software

This growth hasn't occurred without change. Indeed, the IBMPC computer conferencing of 1989 bears little resemblance to the facility as it existed in 1981. These changes have taken a variety of forms. Some involve the evolution of formal and informal rules on IBMPC. Others are related to the administration of IBMPC. Another set of changes, discussed in a coming chapter, involve the effects of IBMPC on its users. Still others, discussed in the pages that follow, entail changes to IBMPC's software and structure. The "append" verb was just the first of many similar changes to IBMPC.

Subscriptions

There were only two basic methods of using IBMPC when it opened in 1981, and the user's choice of method was generally more a question of location than anything else. Those fortunate enough to have a user ID on the computer systems that IBMPC was running on (The IBM Research division mainframes in Yorktown Heights, NY) were able to directly "link" the disk on which IBMPC's contents were stored. Such access allowed participants to view a list of the files on IBMPC with existing disk utilities (FULIST and FILELIST, for instance) and directly view their content with a text editor like XEDIT.

Everyone else received contributions to IBMPC via electronic mail, initially through a multi-step process that proceeded as follows:

Request a list of the files on IBMPC. The list is sent by mail.
View the list and order any files that one hasn't seen. The files are sent by mail.
Read those files.

There are substantial inconveniences associated with this method of access, however. First, the process is fairly time consuming. One must first order the list of files, then wait for the list to come back, then order files, then wait for the files to come back, and finally read the files, making sure to skip over any previously viewed content. Indeed, the process is sufficiently time consuming that it cannot be managed all at once. Second, it depends heavily on human memory and the speed of text editors.

A solution to this set of problems was eventually found in a new "subscribe" capability which allowed users to receive new additions to forums automatically. This capability is similar to that used to distribute appends to COMSERVE and other network based conferencing facilities on BITNET, ARPANET, USENET, and other networks. This development has the advantage, relative to directly linking files, of insuring that one needn't remember where one left off when one last read the file, and also reminds the user to read new appends as they arrive. Subscriptions entail the clear disadvantage, however, of putting a great deal of mail in one's electronic mailbox, where volume is often very inconvenient.

Shadows

Another solution was found in the process of replicating the Yorktown master of IBMPC at other sites. This process, developed by Dave Chess, is known in IBM as "shadowing". IBMPC's shadowing software put a complete copy of all of the files on IBMPC on remote systems, with files automatically updated over the network as soon as they were changed at the master. The advantages of shadowing are found in both convenience and the style of conferencing it enables. IBMPC participants located on systems that maintain shadows are able to directly access the files maintained on IBMPC without tying up their mailboxes or waiting for requested files to arrive.

The disadvantages of shadows are found in the disk space they entail. A copy of IBMPC currently entails approximately 180 Megabytes of mainframe disk space at a cost of, even at 1989 prices, several thousand dollars. Mainframe disk space is often a premium commodity at IBM sites (as it is in many places). Hence the need for this fairly large amount of disk space is often a difficult one to satisfy. The cost can, however, be at least partially offset by an overall reduction in communication network traffic to the IBMPC master.

This difficulty is apparently more than offset by the advantages of having a shadow, however. The first shadow of IBMPC was established in late 1982. The acceleration of IBMPC's growth that begins at about this same time is almost certainly directly related to the appearance of shadowing capability, as it made IBMPC much easier for people to access on a casual or occasional basis. Shadows of IBMPC have proliferated widely through IBM. There are now hundreds of IBMPC shadows distributed throughout the company, and the structure is widely regarded as one of the most valuable features of the facility.

Respondents to the 1986 survey of IBMPC users regarded shadows as an extremely valuable feature. 51% of respondents rated the feature as extremely valuable (the median). 69% of respondents rated the feature as at least very valuable. The evaluation is even stronger in the 1988 survey, where 45% of respondents assess local shadows as extremely valuable (the median); 82% as at least very valuable; and 94% as at least valuable. When the 1988 results are compared with the 1986 results, it appears that shadows have grown significantly more valuable (t=2.05, df=280, p<..03) in the interim.

Another question in the 1986 and 1988 surveys asked users how they accessed IBMPC. Options included linking the master copy of IBMPC, linking a shadow copy of IBMPC, requests to the master copy of IBMPC and requests to a shadow copy of IBMPC. There is a significant shift from requesting against the master to using shadows between 1986 and 1988 (X**2=41.37, df=3, p<..00001). The percentage of respondents doing requests declines from 33% of respondents to 16% of respondents. The entire shift is to shadows of IBMPC.

Specialized forum following tools

Direct access to forums via shadows of IBMPC was not entirely convenient, however, especially as forums grew longer. A regular participant would typically jump to the end of a forum, page backwards to the beginning of the new content, and then read through to the end. Perhaps the biggest drawback to this method was its reliance on human memory that proved increasingly unreliable as IBMPC grew larger. These inconveniences were sufficient to spur the development of specialized front end software that made it easier to follow computer conferences on IBMPC and other conferencing facilities. A series of such forum following tools has evolved over the years since.

The first of these tools were simple. They presented a list of the forums on IBMPC, remembered which forums were read and the last line read in them, and positioned you at that line when you started to read a forum again. Some of these tools presented appends individually rather than as a block of text containing several appends.

Later tools took on a series of advanced features:

As the number of forums on IBMPC increased, forum following tools allowed you to rank forums in the order of their importance and presented them in that order.

As new features of IBMPC allowed appenders to change their appends, forum following tools started remembering the date and time of the last append read as well as the line number of the last line of that append.

As appends began to be inserted into forums in the order of their creation rather than the order of their receipt, these tools started checking the IBMPC history file and showing inserted and modified appends as well as new appends.

As appends incorporated subject lines, forum following tools incorporated alternate views in which only header and subject lines were displayed, and gave participants the option of viewing appends selectively.

As appends incorporated reference lines, these tools added features that allowed readers to jump back and forth between subject appends (questions, for instance) and referencing appends (replies, for instance).

Today's IBMPC participant uses forum following tools both to restrict their reading to a subset of the several thousand forums on IBMPC and to quickly skip past uninteresting content. Tomorrow's forum following tools will probably incorporate features that will automatically skip past specified subjects in forums a user usually reads and expose selected content in forums the participant doesn't normally read.

Changing individual appends

An append to IBMPC was, before 1985, a fairly permanent and unchanging addition to the IBMPC database. While it was possible to add an append to the IBMPC master disk and propagate the append out to the IBMPC shadows, there was no software to change an append on the master or the shadows. The only mechanism for changing appends within a forum was editing of the entire forum and replacing it in its entirely. This action was not available to the average appender. Only the forum owner or IBMPC administrators had the ability to make changes to a forum.

The inability to change an append to a computer conferencing facility is hardly unusual. It is characteristic of much of the computer conferencing software that is in use today, including electronic mail based implementations that this writer is aware of. One computer conferencing facility which is representative of many others in this respect is COMSERVE, operating on BITNET from Rensallear Polytechnic Institute. The software on which COMSERVE operates is frequently referred to as a list server, a computer conferencing facility that collects appends from contributors and mails them out to participants. Although COMSERVE maintains a file of all appends to a given topic which can be requested as a unit, there is no architected interface that allows users to delete or modify the appends in that file.

There is at least one benefit to this level of function. Appends that cannot be readily deleted or modified make for very clean conference transcripts. Subsequent analysis will reveal appends with errors in them, subsequent retractions, etc. Still, the situation is hardly desirable for the individual who does not wish to make a monument to posterity of an error. Indeed, there are several reasons why the modification of individual appends would be a desirable feature in computer conferencing software.

Individuals and appends

The first of these, quite clearly, are the occasional errors and errors of judgement made by individuals. People will occasionally spell key words incorrectly, sometimes invoking unintended meanings in the process. They will sometimes inadvertently leave out important words (like "not") or material (sometimes the entire meaningful content of the append). They accidentally include material they did not intend to append. They send appends to the wrong forums. They supply incorrect information. They make poor choices of words that lead to misunderstandings. They submit appends that are inappropriate given the rules of a given conference or conferencing facility. They make appends that they regret making, sometimes almost as soon as they have been sent.

There is nothing unexpected about this. The contributors to IBMPC are people. They make mistakes, poor judgements, and have regrets. Like most people, they do what they can to correct such problems when they arise. Before 1985, however, the only way an appender to IBMPC could change or delete their own append was by asking the forum owner or an IBMPC administrator to take action for them.

Forum owners and conferencing administrators

These requests are only one of several reasons for editing a forum. Forums sometimes grow too large, requiring that they be split in two. Lines of discussion sometimes occur which are inconsistent with the theme of the forum. Appends are sometimes made which violate the formal rules of the conferencing facility. Before 1985, however, the only means for taking these actions available to either a forum owner or conference administrator was the editing and replacement of the entire forum.

This method of change was hardly convenient. Large files travel relatively slowly on computer networks. Smaller appends, by contrast, travel much more quickly. Hence it was commonplace for at least some of the appends submitted after the forum was replaced to be inadvertently erased. The copy of the forum at the IBMPC master was not affected by this. Shadow copies would frequently lose appends, however.

PRUNE and APPEND MODIFY

Changes made to the IBMPC conferencing software starting in late 1985 changed this situation. An APPEND MODIFY verb allowed individual appenders to replace an append they had already made with a corrected copy; and allowed forum owners and conference administrators to delete or modify appends that did not adhere to the editorial policy of the forum or conferencing facility. Changes made with append modify changed very little for users who followed IBMPC via electronic mail. It simply added an updated copy of the append to the participants mailbox. Append modify radically changed things for those who read forums using forum following tools, however. Modified appends were changed correctly at both the IBMPC master and all shadows. Hence many participants frequently never saw the original append at all.

The addition of a PRUNE verb gave forum owners and conference administrators additional control of forum contents. A prune of a given forum deleted all of the content of that forum between the first append (called the header), and the first append of a given date. Content deleted by prune is returned to the "pruner" so that it can be archived for future use. The deletion is propagated from the IBMPC master to all shadows, moreover, insuring that forums look the same on the master and all shadows.

Prune and append modify give IBMPC participants great freedom to modify individual appends and entire forums without compromising the integrity of forum contents. While these features soil IBMPC's audit trail and ongoing record of appends, they give the individual appender greater control of his or her words, forum owners greater ability to enforce the subject matter and rules of individual forums, and conference administrators greater ability to enforce a conferencing facility's rules.

Respondents to the 1986 survey of IBMPC users rated Append-Modify as a very valuable feature of IBMPC. 30% of respondents rated the capability as extremely valuable (the median). 57% of respondents rated the feature as at least very valuable (the mode).

Spin-offs

When IBMPC was started in 1981 it was the only generally available computer conferencing facility in use in the company. It retained this distinction for three years, with its only competition for the honor coming from a companion software distribution facility, PCLIB, that eventually closed down because of inadequate development and support. In any case, PCLIB, which opened in May, 1982, was not a computer conferencing facility so much as an electronic publishing service. Indeed, many of the software packages that were distributed on PCLIB were discussed in forums on IBMPC.

The next real conferencing facility, IBMVM, didn't start up until November, 1984, almost exactly three years after the opening of IBMPC. There are reasons why this should not be surprising. Computer conferencing remained a new idea in IBM, and many people, including the manager/owner and other administrators of IBMPC, were skeptical of its chances for survival within the company. To encourange the use of conferencing, IBMPC's manager allowed it to encompass a variety of topics which were only indirectly related to PC's, including discussions of other IBM mainframe and minicomputer hardware and software. Other interest groups in IBM had, moreover, well established channels of communication in the form of annual meetings. VMITE, for instance, brought IBM's internal VM user community together once a year in California. Hence there was probably less pressure among members of these interest groups to innovate a new channel of communication.

As IBMPC grew larger, however, the breadth of its content became increasingly unsatisfactory. Participants who were principally interested in IBM PC software and hardware found the non-PC discussions increasingly difficult to skip over. Participants who were principally interested in other operating systems and larger computer platforms increasingly found the noise from the PC-related discussions unduly distracting. Hence IBMVM was just the first of many conferencing facilities to break away from IBMPC. The formal subject matter of the conference was IBM's VM operating system for mainframes.

IBMVM (VMPC) would be the first of many such facilities which started as a collection of forums on IBMPC. The IBMUNIX facility, for instance, seeded itself with the UNIX related discussions on IBMPC. IBMARTS, IBMTEXT and other facilities have similar roots. Today there are well over 200 open computer conferencing facilities in IBM, and perhaps 500 confidential facilities that service a constrained group of participants. It would be incorrect to say that many of those facilities are direct descendents of IBMPC, but IBMPC continues to take the lead for most such facilities by introducing new participants to computer conferencing and setting precedents for how computer conferencing facilities should be run and what they can be used for.

One of its most important precedents was established in early 1985. The failure of PCLIB was complete, but continuing growth in both discussion made the distribution of software on IBMPC increasingly problematic. Software was increasingly difficult to find in the profusion of forums. Participants frequently had to skip over large numbers of software packages while reading forums. The amount of space required to maintain both was becoming unmanageable. Hence the opening of PCTOOLS in March 1985 represented an intentional effort to resolve these problems.

Although it is really an electronic software distribution (or electronic publishing) facility, PCTOOLS has, from its opening, been formally recognized as a sister facility to IBMPC. All PC software on IBMPC was moved to PCTOOLS. All discussions of software distributed on PCTOOLS are maintained on IBMPC. The facilities are administered separately, and at different IBM sites, but the administrators of the two facilities work together to define common usage guidelines.

This basic model of a conferencing facility with a separate associated software distribution facility has been adopted for many other computer conferencing facilities in IBM. IBMVM includes discussions of software distributed on VMTOOLS. IBMUNIX includes discussions of software distributed on RTTOOLS. The IBMOS2 confidential computer conference discusses development software that is distributed on a test basis from a separate software repository. IBMTEXT includes discussions of software distributed on TXTTOOLS. This model is only one of many in which IBMPC and PCTOOLS, as the oldest and largest conferencing and electronic publishing facilities in IBM, have taken a lead in defining structures for other IBM computer conferencing facilities.

The process of building a spin-off

The process of spinning off new conferencing facilities from IBMPC continues today. The process generally starts with one or a few forums which attract substantial interest. In many cases these forums meet all of the usual criterion of IBMPC conferences. Although all must be business related, it is sometimes the case that the rule concerning PC relatedness will be relaxed to accommodate a topic which, though important to the IBM business, does not yet warrant a conference disk of its own.

Growth of interest around this topic will generally be apparent in several kinds of parallel developments. First, one can expect to see an acceleation in the amount of discussion in the subject forum(s). Second, one can expect spin-off conferences to start up. Third, one can expect tools to be developed that are related to the subject, in some cases with related IBMPC forums started up.

When a decision is made to form a new conferencing facility, it is generally done in an attempt to broaden discussion into more specialized forums and centralize access to both tools and discussion in the particular topic area. If any of these new forums relate to IBM product plans and strategy, the new conference disk will likely be made confidential, with access restricted to a list of individuals. Conferences like IBMVM, IBMTEXT, and IBMUNIX have no such constraints, and remain accessible to anyone in the company.

Regardless of the form the new conferencing facility takes, it can be expected that it will seed itself with the related forums that already exist on IBMPC. In most cases it will continue to share those forums, with appends made to the forums on either facility sent to the other. It can also be expected that the conference will adapt the IBMPC RULES to their facility, often with little change beyond the name of the conference disk and its administrators.

The key role of IBMPC, as IBM's largest computer conferencing facility, in this process is one of providing a broad potential audience to a topic. As interest forms around the topic, that audience can then be developed into an audience for a new conferencing facility. By continuing to share some forums with IBMPC, moreover, the new conferencing facility continues to publicise its existence, hence providing a path for others to find it.

IBMPC's vocabulary

The participants in IBMPC have developed a distinctive vocabulary to describe their world. An individual conference on IBMPC is called a "forum", a contribution to a forum is called an "append", and the person who makes an append is often referred to as an "appender". These words come from strikingly different roots. "APPEND" is the name of the subcommand/command which is used to send a contribution to IBMPC. It was selected as a command because the effect of the command is to "append" the contribution to the end of a file. "Appender" is an obvious extension of the word append to describe the person who makes the append.

"FORUM", by contrast, emerged from general use. Early conferences on IBMPC went under names like "IBMPC TRICKS", "GRAPHTRX MEMO", and "8087 QUERY". Indeed, the first conference using the word forum, "LINKEDIT FORUM", didn't appear until IBMPC was over 6 months old. The word caught on, however. By 1983 almost all discussion oriented conferences on IBMPC had a name of the form NAME FORUM, and it had become commonplace to refer to all discussions as forums.

Other specialized namings caught on as well. Hence NAME PROCS is expected to contain code that can be used with a program or programming language called NAME, NAME QUERY is expected to contain a short discussion on a constrained question. NAME IVORY is expected to contain an IBM product announcement. NAME AVAIL is expected to contain an IBM internal use only program announcement, NAME PACKAGE is expected to contain a list of other files that constitute program NAME. Other words that have understood meanings when used in conjunction with a file on IBMPC (and most other computer conferencing facilities in IBM) include CATALOG, MEMO, RULES, ANNOUNCE, SCRIPT, README, DOCUMENT, COMBIN, EXEBIN, FLSBIN, and BENEFITS.

IBMPC's specialized vocabulary is hardly limited to these kinds of namings, however. The main repository to which appends are sent is called a "master". Copies of IBMPC (which exist on hundreds of computers around the world) are referred to as "shadows". These shadows are maintained by "shadow owners". Individual conferences on IBMPC are maintained by "conference owners". The people who checks to make sure that the rules of IBMPC are adhered to are known as the "reviewers" (as opposed to either "censors" or "editors"; more on this in a coming chapter). The administrators of IBMPC (including the reviewers) are sometimes known as "the royal family" (a name frequently bemoaned by its members).

The Structure of appends

The typical append on IBMPC before 1985 was structured in three pieces, including an automatically generated header, content, and a signature. The forum header automatically generated by the computer conferencing software contained (in a single line) information about when the append was made (when it was received by the conferencing facility), the conference it was appended to, and the person who appended it (their computer user ID and node). The content of the append was whatever the user wrote in the append (usually one or a few paragraphs of text). The signature was a one line personal identification. Some users signed their appends with their full names. Others signed initials, first names or other "handles".

The typical append on IBMPC today contains at least four, usually five, and sometimes six parts. The header hasn't changed much, but now records the time at which the appender sends the append (standardized to Greenwich Mean Time). This standardization helps to ensure that appends are properly sequenced. It allows appends to be sequenced in the order they were created, and ensures that shadows of IBMPC will maintain appends in the same order they are maintained at the master. This change is an important one, as it negated the once-common problem of a short answer to a question arriving at shadows of IBMPC before the longer question did.

While the content of today's appends to IBMPC has not changed, it is most typically is preceded by two additional elements, a subject line and a reference line. Subject lines give a short (one line) declaration of an appends content, and have become a nearly universal element of appends on IBMPC. Because subject lines are frequently generated semi-automatically by the software used when writing an append, they are not always accurate indicators of content. By providing a general indication of the thread of conversation to which the append belongs, however, they make it easier for participants to skip over discussions which they consider uninteresting.

Reference lines provide a pointer to the previous append to which a new append replies. These lines are generally created automatically by the conferencing software with which appends are written, and have enhanced IBMPC forum following tools by allowing participants to refer back to a subject append (a question or controversial statement, for instance). The addition of subject and reference lines to appends reflects a general drive to manage the scope of IBMPC. With the weekly volume of information contributed to IBMPC in the range of several novels per week, no participant on IBMPC reads every word (or looks at every append) anymore. Subject lines make it easier to skip whole lines of discussion within a forum. Reference lines make it easy to refer back to something one may have missed.

Signatures haven't changed much either (many IBMPC participants sign appends today just as they did in 1983), but signatures were, for a time, increasingly followed by an "append epilogue". These append epilogues come in several forms, and include pictographics, randomly or semi-randomly selected words of wisdom, and other content. Growth in the use of append epilogues appeared to be related, at least in part, to the involvement of IBM employees in other computer conferencing communities, including USENET, where append epilogues are commonplace.

Use of such epilogues has recently become a point of controversy on IBMPC and in IBM. Opponents argue that such epilogues should be banned as a waste of time (for the reader) and space (on the computers which store the forums). Proponents argue that such epilogues allow the appender to express their individuality and present a personality to other participants. The issue probably will not be resolved. It is doubtful that epilogues will be banned, if only because of the difficulties entailed in enforcing one (how does one automatically differentiate an overlong signature from regular append content). It is equally doubtful, however, that people will stop finding them irrelevant. There is a growing consensus on IBMPC that a one (or possibly two) line append epilogue is acceptable. Appenders who add long append epilogues increasingly face considerable pressure to shorten or eliminate them. This social pressure appears to be very effective, and even those who routinely add long epilogs to other electronic correspondence rarely use them when appending IBMPC.

The formal structure of appends continues to change. The large number of different computer conferencing facilities in IBM has led to suggestions that the facility name be included in the header of each append. With the continuing growth of information on IBMPC, the administrators are beginning to explore the possibility of hypertext branching and cross referencing within appends that may result in other formal structures.

Change and Purpose

These changes are hardly random. They are purposeful changes to the workings of IBMPC whose intent has been that of making the facility more productive for the people who use and maintain it. Shadows, subscriptions, forum following tools, append-modify and prune capabilities, companion software distribution facilities and new conferencing facilities are only some of the more important innovations. Other changes to the IBMPC software have:

allowed the IBMPC administrators to selectively scan appends for problems.

allowed the IBMPC administrators to selectively preview appends to specific forums or from specific individuals and locations (more on this and the selective scanning of appends in a coming chapter).

provided IBMPC users with the ability to conduct informal surveys.

This process of innovation continues in both formal and informal development efforts scattered throughout IBM.

These innovations have inevitably changed the way people use IBMPC. The participant who read 15 contributions a week in 1982 could read everything that happened on IBMPC without significantly impacting either their mailbox or their schedule. The participant who wishes to read everything on IBMPC today will find it a full time job. Indeed, IBMPC participants currently generate the equivalent of a copy of this study in forum content every three days. Today's IBMPC participant reads a selection of forums. The most important may be directed to the participant's mailbox, but most will be selected and followed with a forum following tool that prioritizes the participant's readings according to the preferences of the participant.

The participant who made an error in an append in 1984 would most likely either ignore the error or post a correction in a subsequent append. The participant who makes an error in a 1989 append will most likely modify or delete the append, sometimes with a short explanation or apology substituted for the deleted content.

For all these changes, however, the essential purpose of IBMPC remains unchanged. When people in IBM need information about how to use their personal computer, they frequently turn to IBMPC first. This information function of IBMPC is illustrated, in a rather distinctive fashion, in the next chapter.