Note: if you come to this article from the BBS community, please read it with an open mind. It is not exactly complimentary, but it is not intended as a slight.
About twelve years ago, I read the “Voices in My Head” essay about the birth of MindVox by Patrick “Lord Digital” Kroupa. I revisited it recently and, as before, found it interesting in giving some insight into life on the “digital frontier” of the early BBS community. However the bulk of the essay is Kroupa lamenting the homogenization that came with the settlement of that frontier, which turns into explaining the motivation for a kind of rebirth with the creation of MindVox. He writes well and draws the reader in, but he only gives a glimpse of a world that is difficult to imagine if you weren’t there at the time and then, like a magician, he pulls his cloak tight and hides it from sight, as if to say, “no; you’re not one of the chosen few.” This had to be deliberate, of course; a way of generating that most powerful of marketing drugs: hype. After all, he was starting a business.
I’ll give him props for showmanship.
But while Kroupa claims that he and the early “pioneers” were on the forefront of the technology wave, one can make an argument that they were actually behind: in particular, his essay does not mention, and therefore discounts, the existence of other systems and the work being done in the research community at the time the BBS community was forming.
Reading between the lines, and having seen something of the desert of cookie-cutter track homes he describes that replaced the frontier settlements, something else grabs my attention: he’s right.
But before I get to that, let me mention an annoyance: a thing I have noticed is that the enduring writing from that place and time are all voiced with this pseudo-formal register that I found captivating at the time, but in retrospect I find pretentious and frankly irritating. The ridiculous “handles”, the uniformly grandiose writing styles; all of it comes across as sophomoric. Hell, the mere fact that Kroupa’s document is subtitled, “The Overture.” What nonsense.
Further, the descriptions are stale and come off as the analysis of a group of posturing amateurs who managed to gain facility with the facade of a technology few had been exposed to but that they didn’t really understand, and who similarly adopted the facade of the pseudo-academic techniques used to present and justify the resulting tale. Unfortunately, this is just auto-hagiography; bad academics.
And yet, I find myself longing for that distant past. Why? One word:
Nostalgia.
Nostalgia is a dangerous thing, because it is almost always disappointing. If one succumbs to its siren song often enough, one eventually realizes that nostalgia is a desire to reconnect with a time and a place and people that no longer exist: the time has passed, and the place has moved on as a result. The people you remember are usually no longer there, and if they are, well, you generally find out that you’ve changed and they haven’t (or vice versa) and if they haven’t, then there was a reason you stopped hanging around with them in the first place. In any event the thing you were nostalgic for is just no longer what you rosily remember. The events have faded in your mind, the jagged edges of the irritating or just plain bad being slowly dulled by the shifting sands of time until what is left is a shell of the actual reality you experienced: a pleasant memory of the good parts. But trying to recreate what you faultily remember inevitably dredges up the bad and the whole experience becomes a frustrating let-down.
And yet, we do it anyway.
So let’s try and head the disappointment off now, shall we? What were the bad parts of the BBS experience?
In the Trailing Wake of the Technology Wave
First, the hardware and software. These were anemic at best; under-powered microcomputers and single-user, single-tasking program loaders in lieu of real operating systems. The programs were buggy and crashed often, occasionally corrupting the files they depended on for proper operation, if not the underlying filesystems. Running a BBS meant dedicating a computer to it, which meant it couldn’t otherwise be employed for useful work, despite being idle waiting for callers most of the time (or waiting for the transmission of a byte representing a keystroke modulated over an analog telephone line).
The real excitement and adventure in computing and communications was happening in industrial, government and academic research labs connected by networks far more capable and interesting than anything that the BBS community could have dreamt of. The level of work was infinitely more sophisticated at these research centers than at the local 2600 meeting or on a DOS-based BBS. To the extent that these innovations were considered at all in the BBS community, it was as a group of outsiders looking in, not the pioneers and innovators. To be perfectly honest, most BBSes were a hobbyist concern and not exactly innovative or important systems.
But in the minds of the participants it was important. In the collective BBS imagination, wars were waged, dragons slain, and everyday Joe-Schmoe hobbyists fancied themselves a new breed of sheriff on an electronic neuvo-Wild West frontier. In actuality, this was more like a sound-stage and the sheriff’s, knights and pirates more like actors than the real thing: more LARPers than Lord of the Rings.
That’s not to say that the BBS community didn’t have an impact: it surely did. And while demonstrably valuable, shortly after Christensen and Suess it became derivative of and applied onto pre-existing creations rather than truly innovative or original work.
But, they had a community and a culture and it was fun for them, and isn’t that what really counts? The high-schoolers didn’t take down the system, and the earnest but dim Radio Shack employee didn’t thwart IT crime by setting up a BBS on his home computer and plugging it into a modem in his spare room. And figuring out how to install a UART driver and produce a set of “AT” commands didn’t make the sysop a computer expert. But in this fantasy world, none of that mattered: one could plug in and escape and be someone else for a few hours.
The kids distributing poorly written text files with “instructions” for breaking into telephone switches or minicomputers were merely exploiting shortcuts that engineers and technicians had put into those systems for their own convenience; they were rarely discovering anything particularly new or novel. The persistent myth of the “uberhacker” who could hack into any system, leaving no trace, was about as realistic as the idea that a regular joe setting up a BBS to “combat computer piracy” in his local calling area was going to stop kids from trading stacks of floppy disks in the junior high school cafeteria. In reality, the “k-rad” callers of the local “‘leet boards” were simply not master hackers teetering on the edge of obtaining nuclear launch codes, despite all the hype to the contrary.
So is it wrong to mourn the death of the BBS community and subculture? Not really; they had fun. But it is important to contextualize the Fat Dragon by understanding that the death of that community and subculture was inevitable: they weren’t the pioneers and experts, so couldn’t ride the wave when the technology changed and their wave crashed over them.
In short: they weren’t equipped to deal with the changes they found themselves caught up in. So they stagnated and died.
The Last Piece of the Historical Puzzle: Public Access Unix Systems
But there is something that persisted: public access Unix.
This is basically what the name implies: Unix systems that were (or are!) publicly accessible.
Recall that in the previous post on history and motivation, we quoted Dennis Ritchie saying the following:
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.
(From http://cm.bell-labs.co/who/dmr/hist.html)
The researchers at Bell Labs, coming off of the Multics project, strove to create an environment that encouraged communication and collaboration, not just typing in programs.
I think that the earliest BBS experiments were exactly that: Christensen and Suess’s November 1978 article in BYTE magazine is all about this neat hack that they came up with to foster communication in their local computer club; they were engineers interested in building a social community around technology. On the primitive microcomputers of the day this was accomplished through simple, menu-driven captive interfaces because those machines weren’t packing the horses for much else. Certainly, they weren’t powerful enough to support running a multiuser, multiprocessing operating system like Unix (this is somewhat debatable actually, but true to a first-order approximation: Ken Thompson got a PDP-7 to do some amazing things, but he’s a virtuoso).
But BBSes quickly became a hobbyist hotspot, and those hobbyists determined what the systems did and why. As it turns out, I think the more technically inclined quickly moved on from CP/M and DOS and the limitations of single-tasking, single-user program loaders like them to what they probably wanted all along, which were multi-user timesharing systems. Perhaps Unix specifically wasn’t a requirement: I’m sure some would have loved to have a PDP-11 running RSTS/E or a VAX running VMS, but recall that those cost real money at the time. But by the late 1980s, Unix was expensive compared to DOS but not out of the price range for a well-employed engineer, scientist or programmer. One could get a reasonable version of System V that would run on a beefy but not inordinately expensive PC of the era, whereas a VAX would have cost like USD 30k in 1988 dollars. So the pure hobbyist types stayed with the captive menu-driven user interfaces on PCs running DOS and similar systems, but the tinkerers and experimental types moved on.
To the extent that the latter folks wanted to cast the net for a wider audience, you had things like public-access Unix systems because, frankly, you could do so much more with them. They were less widespread because they were more expensive and required more expertise to run than the simpler BBS programs, which often wrapped all of the administrative functionality up into a pseudo-graphical, menu-driven interface geared toward the more novice “sysop” types.
Looking Forward
All of this is hindsight, but will inform us as we look forward.
It’s interesting that at the time of Kroupa’s writing (1992) there was already a sense that the BBS community had stagnated and was in need of a reset. So supposing we were to analyze the architecture of the average BBS; what’s really worth preserving?
Thinking about these things is what informs us going forward. We’ll start from the basis of a public access Unix system in the next post.