One day when I was in the ninth grade, I was in my high school’s library and a ran across a Dungeons and Dragons acquaintance perched in front of an old Apple ][ computer. As I went to say hello, what was on his screen grabbed my attention: it was a “splash” graphic from Tradewars 2002; the one of the space station orbiting a planet, drawing line by line at 1200 BAUD on the raster display of the Apple //e in all its amber monochrome glory.
“What’s that?” I asked. “A game,” he replied. “But there are no games on that computer….”
Which was true.
But our town was host to a major research university just down the road. To “enrich” the experience of its students, the school had connected this small computer with a modem in an out-of-the-way corner of the library to a little-used analog telephone line and allocated it for calling into the catalog system at the university’s main library. Ostensibly to assist students with (high school level) research, a laminated sheet with printed instructions for dialing the modem into the university’s terminal server and connecting to the library system was taped to the wall next to the aging machine.
With only its dual 5.25” floppy drives, 6502 processor, mere kilobytes of RAM and builtin keyboard bearing mute witness to the proper use of this resource, nothing prevented the enterprising student from dialing a different telephone number and directing the high school machine to connect to a different computer.
Of course all of this was unknown to me. It was 1991 and I was far more into punk rock and skateboarding than computer games. My aging NES, dutifully purchased during the 1986 rush, had lain unused in our basement for the better part of 4 years. While I had some vague idea that computers could communicate with one another (I had seen the movie “War Games” after all), that they could do so in anything other than an utterly static, proscribed way was a concept I had never really bothered to ponder; Matthew Broderick very nearly starting World War III between sips of Tab was merely Hollywood embellishment, just like Joshua’s computerized voice. And besides, who cared?
But here was my friend in the high school library, explaining to me that he was dialing into a BBS run by another classmate, and that using the antiquated Apple //e, one could, in principle, call any other computer that was connected to a modem. Again, on some plane I already knew this; but there’s a difference between knowing and experiencing.
He walked me through creating an account on this BBS and setting up to play Tradewars myself. Here was something new and exciting, but beyond just playing games, there was the possibility of sending and receiving messages.
Of course there were no games on the anemic Apple //e in the high school. After all, it really was strictly for calling the University’s library; the breakthrough was in realizing that it could be repurposed to call another, different computer and play games on that machine. In a literal sense it was merely the conduit, but in some other sense it meant that games were accessible on, or more precisely from, that machine. Along with an entirely new world.
Spaces within spaces
Stumbling onto a BBS for the first time might be where I first realized that multiple realities coexisted with and overlapped the real, physical world. I don’t mean realities in a metaphysical sense, or in the sense of parallel dimensions or universes, but rather in the sense of the lived experiences of different people.
Years later I was walking down Wall Street in New York City and crossed an intersection where a homeless man was begging while a wealthy stock broker passed by from one direction and myself from another. For a brief moment all three of our lives intersected in that shared physical space as we walked past one another, but we each inhabited very different worlds: my world was not the opulent wealth of the stock broker and similarly my world was not the homeless man’s austere existence. The idea that those worlds were multiplexed onto the same physical space but that our lived realities were so vastly different from one another was intriguing.
Discovering the local BBSes was a much earlier variation on this theme, though at the time I couldn’t articulate it as such. But in retrospect, finding those message bases was like tripping through the rabbit hole and finding a fully formed virtual world on the other side; a world that I didn’t know existed, but was alive in the same physical spaces I’d inhabited my entire life and that had as major players many of the kids I’d passed by in the hallways for years. The kids in the know at school had a place where they spent time creating a communications network that existed right under the noses of the arrogant jocks and “popular” kids who picked on them at recess and then tripped them in the halls, or the “adults” who were too distracted to notice.
These kids had a sophisticated means of conversing among themselves in a social space that was totally outside of my previous experience in every way. While I had been noisily rolling down the street, they had been busy indoors harnessing technology to sidestep my lived physical world, creating their own reality instead. I had never stopped to consider what these people did when they got home in the afternoons, but they had forged their own reality. Discovering this was a revelatory experience and I became interested in exploring these mysterious digital caverns.
And of course that world does have a physical component. But it is a component of modulated signals, of magnetic fields and electrical pulses in a semiconductor wafer. While real in a physical sense, it is still different than a face-to-face conversation because it’s mediated by a machine. While the same might be true of the telephone, it too is different because of, in some sense, the extremity of the medium: the interposition of a digital layer and all that entails is different than the analog reproduction of sound, or even digitization of analyzed sound, which at least attempts to faithfully reproduce the original input. But this world was text on a screen; a pure abstraction. In the same way that a novel is a physical object but contains a fictional world that is not the book, so these text-based systems contained real worlds but that were not themselves the computers, modems, phone lines, floppy and and hard disks, and masses of telecommunications infrastructure that made them up.
BBS History, an Interlude
The BBS did not come first.
By that I mean that the BBS was not the first computerized social system. I’ve written about this on my personal blog, but briefly research into socialization via computer, as exemplified by timesharing systems of the era, had been ongoing since the 1960s, a subject we will return to later. And experiments like Community Memory, hosted on a mainframe system, started exploring the idea in the early 1970s.
But the BBS, coinciding with a microcomputer explosion that was itself catalyzed by a dramatic drop in the price of consumer electronics, popularized digitally mediated social interaction and moved it out of the lab and into the hands of the hobbyist. Perhaps for the first time, mere mortals could set up the infrastructure for computerized communication.
The origin of the BBS, as it was understood by the time I saw one in the early 1990s, is commonly taken to be the creation of the CBBS (“Computerized Bulletin Board System”) by Randy Suess and Ward Christensen in the late 1970s. Christensen and Suess were both were members of CACHE, a Chicago-area computer club. A blizzard in early 1978 left Christensen snowed in at home, so he called Suess and the two talked about building a microcomputer-based system for electronically disseminating information for their computer club. Christensen had previously written a program for transferring files via modem between CP/M systems that he called “MODEM” (but that was quickly renamed “XMODEM”) and Suess reportedly said, “you do the software, I’ll do the hardware” and the result was CBBS, which allowed users with a modem to dial a phone number (in Suess’s home; Christensen lived in the suburbs outside of Chicago’s city calling area, but Suess lived in Chicago proper, so they located the system at Suess’s in order to avoid long distance changes for the majority of callers).
The CBBS system was described in an article in the November, 1978 issue of BYTE magazine “Hobbyist Computerized Bulletin Board”. The system it ran on was minimal: an Intel 8080 processor, several kilobytes of RAM, a floppy drive, a hobbyist 300 BAUD Hayes modem and miscellaneous peripherals, all tied together using CP/M. The BBS software itself was written in assembler, based on a mock-up written in BASIC. The BYTE article goes into detail on both the hardware and software configuration.
The user interface was captive and mostly menu-driven, reminiscent of commercial data processing applications of the time. This makes sense in that the article alludes to a desire to keep users from accessing CP/M directly, but the application was probably also pushing the limits of the underlying microcomputer. Almost by necessity, the BBS software was simultaneously simple and entirely self-contained: it was user interface, user management, messaging, file organization and transfer, etc, all in one package. But importantly the machine it ran on just wasn’t capable of being used as a multitasking, multiuser timesharing system: hardware resources were simply too constrained.
Fast-forward five or so years and a suitably powerful IBM PC capable of running Unix would be on the market, but by then the die had been cast. For better or for worse, Christensen and Suess did not just build the first recognizable BBS, they also created the archetype for all BBSes to follow. Thus, the initial years were marked by similarly primitive systems, which carried forward the same basic structure even as the underlying computers became capable of much more.
The next nearly 20 years find BBSes enjoying almost exponential growth. By the heyday of 1996, nearly 150,000 BBSes are in operation in the United States alone.
By this time, BBS software packages are often commercially supported operations and turnkey applications, including relatively sophisticated menu-driven configuration and management tools, editors, etc.
Concurrent Developments
Of course, things were happening in the industry outside of the hobbyist domain while all of this was going on. The Multics project had started as a joint effort between the Masschusetts Institute of Technology, Bell Laboratories, and then-computer manufacturer General Electric to build a “computing service”: the vision was of a “computer utility” analogous to the familiar telephone or electrical utilities. One would simply plug a terminal into a machine and access a timesharing system running on a powerful computer that could provide for the computational needs of the entire city of Boston. Multics was wildly ambitious but it was proved much harder to deliver on its many promises in a timely and cost-effective manner than originally anticipated, and Bell Labs had pulled out of the project in 1968.
Beginning in 1969, two veterans of the Multics project at Bell Labs, Ken Thompson, and Dennis Ritchie began implementing a simple timesharing operating system on a little used PDP-7 minicomputer at the Bell Labs site in Murray Hill, New Jersey. The result was jokingly called “Unics”, a pun on the name “Multics” (which stood for Multiplexed Information and Computing service; “Unics” jokingly was a portmanteau for “Uniplexed Information and Computing Service”). Initially implemented by Ken Thompson based on a hypothetical design by Thompson, Ritchie and Rudd Canaday from the year prior, Thompson’s skunkworks activity caught Ritche’s attention, who quickly joined the effort. Between the two of them, they were able to produce something interesting enough that they convinced their management to fund the installation of a PDP-11 minicomputer; Bell Labs changed the name to “Unix” and the new system proved to be a pleasant programming environment that rapidly became the focus of the computing sciences research group at the labs.
But the system wasn’t just for programming; from the start it was also a communications medium. As Ritchie put it in a paper titled, The Evolution of the Unix Time-sharing System given at the Language Design and Programming Methodology conference in Sydney, Australia in 1979:
What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.
Unix was an incredibly important system throughout the 1970s, and became the system of choice for University computer science departments, being the example used to train a generation of computer scientists and software engineers.
In 1978, the same year as Christensen and Suess’s BYTE article, Digital Equipment Corporation released the VAX minicomputer; a “super-mini” machine with a 32-bit address space. The machine would go on to achieve enormous popularity running it’s native VMS operating system, as well as Unix, which was ported to the VAX in short order.
As the VAX went on to become the system of choice in universities and other research organizations, students at the University of California, Berkeley, added demand paging to Unix to support Lisp environments and large relational database systems. This work formed the basis of the “Berkeley Standard Distribution” of Unix, or BSD. BSD on the VAX would be selected by ARPA, now called DARPA (the Defense Advanced Research Projects Agency) as the standard for defense contractors in the 1980s, leading to an explosion in the growth and popularity of both Unix and the VAX. Timesharing would grow in popularity throughout the 1970s until the introduction of graphical workstations in the early 1980s. Designed as powerful systems for scientists and engineers, workstation vendors gravitated towards Unix as the base operating system for their offerings. While “personal computer” offerings continued to offer simple, single-task, single-user program loaders as operating systems, professional users came to expect Unix.
Decline
Unbeknownst to most hobbyists, in 1969 an obscure research project was funded by the Advanced Research Projects Agency (ARPA) of the US government to develop a packet switched network interconnecting government-sponsored computer centers at universities and other institutions. The resulting ARPAnet showed great promise and grew rapidly through the 1970s, though the initial 8-bit addresses used by the ARPAnet Network Control Protocol (NCP) was found inadequate for continued expansion, and in the mid- to late- 70s, attention turned towards designing and implementing an expanded Internet Protocol with 32-bit addresses divided into host and network components. Additional packet-oriented User Datagram Protocols (UDP) and stream-oriented Tranmission Control Protocols (TCP) layered on top of this IP protocol; the suite is known as “TCP/IP”. On January 1, 1983, flag day is declared and the newly emergent but otherwise unknown Internet officially switches from NCP to TCP/IP. Within a decade, there are well over a million systems connected to the Internet; an order of magnitude more than the total number of BBSes.
The Internet remained a research project until the early 1990s, when the Clinton administration opened it up for commercialization, and by 1995, commercial Internet Service Providers were offering dialup access to the Internet with broadband access following shortly thereafter. Combined with the emergence of the World Wide Web, uptake was explosive.
The effect on the BBS market was immediate and devastating. Almost overnight, users dumped dialup BBS systems in favor of the far richer content of the Internet.
To understand this, one must see that using a BBS was sort of like visiting someone in their home. That person graciously invested in the infrastructure for you to visit: s/he provided a computer running the BBS software, customized the content on that system, paid for a telephone line and modem for you to dial into and connect through. And while many systems asked for a nominal financial contribution to help defray costs, the expectation was very much that one conduct oneself as if one were a guest in another’s home. Indeed, BBSes were often “themed” to the tastes of the system operator, so dialing in would give you a taste of what that person found interesting or exciting, giving a glimpse into the host’s personality. One did well to honor the implicit social contract by being polite.
But this could also be stifling. Arguments might flair up, only to be unceremoniously tamped down by the will of the system operator, or “sysop.” The effect was along the lines of, “you may come into my house, by don’t track mud on the carpet.”
The Internet, in contrast, was a green field of openness. And where BBSes were focused on a particular geographical location, the Internet was truly global. One could connect to a computer a continent away in more or less the same manner one connected to a machine in the next room. There were no international or long distance telephone charges involved. One could literally criss-cross the globe for the cost of a local phone call, sampling whatever content struck one’s fancy. Instead of downloading from the meager supply of “files” local to each BBS, one could peruse entire catalogs of useful software, most of which was free for the taking. Instead of exchanging messages with a handful of local users, one could avail oneself of high quality, global conversations on USENET. Instead of chatting with the handful of users – again, all local – who could dial into a multi-line BBS system, one could experience globally distributed real-time communications with thousands of other people on IRC. You weren’t limited to some small number of minutes connected to a BBS, but rather could languish online for hours. And instead of the stifling figure of a sysop standing over one’s shoulder, there was an ethos of freedom of information exchange that was unsupervised and unfettered.
Was it any wonder the users left?
Alternative histories…?
But here we have to take a step back and ask ourselves, what did these early BBS pioneers really want? Suppose they had had access to a minicomputer running a timesharing operating system such a PDP-11 running RSTS/E, RSX-11m, or even Unix. Would they have pressed that into service over their homebrew microcomputer system, even modulo the differences in power consumption, space and heat dissipation? Randy Suess went on to run the Chinet public-access Unix system, which would tend to indicate that yes, they probably would have.
Consider that many custom functions of the CBBS software would just have been built-in features of a timesharing operating system for a minicomputer: user management, for example, was a function of the operating system, not something one should have to write oneself. In addition, more advanced systems had a process model, editors, development tools including user interface toolkits, a security and permissions system, and a suite of associated software: mail systems, pagers, chat programs, etc.
But a PDP-11 or a Pr1me or similar machine (let alone the recently announced VAX) cost real money in 1978, whereas a microcomputer was newly accessible at reasonable cost for motivated individuals like Suess and Christensen. The choice was pragmatic.
But what if they could have done it differently? Thinking about this is our motivation: what would it be like if we engineered a BBS from the ground up on a more sophisticated platform? The result of this experiment is the Fat Dragon.