Social Computing, before the Internet

Author's Note: Recently, on Mastodon, Jason Self posted a nice little blurb in celebration of the 57th anniversary of the Incompatible Time Sharing (ITS) operating system (OS), enumerating some of its cool features. His list was good, but there's a feature of ITS that I've always felt isn't given its due, so I responded at length with my thoughts about that. Lars Brinkhoff suggested that I should put those thoughts in a more easily-referenced place, so that's what I'm doing here. I've done some light editing to make this read better of context. No attempt was made to make this a precise mirror. Let's call the original a rough draft and this cleaned up version the official version.

Oh, and in my personal experience, this operating system is pronounced as three separate letters (“I-T-S”), not like the possessive pronoun (though see notes at end for some exceptions). Glad we got that cleared up. Now let's dive in.

The big, underappreciated thing about the ITS operating system, too easily seen as a weakness, was the nearly complete lack of security. Seriously.

Today, of course, security is absolutely essential. But the luxury of working without it back then resulted in a huge productivity gain, enabling us to do early experimentation with ideas that otherwise were destined to seem impossible for another few decades.

What do I mean by a lack of security? Well, ITS existed on the net (ARPANET, not yet Internet) for years with

• no file security,
• no protection against any user (even a not-logged-in user) shutting down timesharing,
• tools that let any user spy on any other, and
• commands to read interactive messages or email that took a command line argument of whose messages to read.

Yet the level of abuse of these gaping security holes was negligible/tolerable for a long time. You heard me right. Years.

It was partly an artifact of the time. Maybe some combination of

1. most folks not thinking to make mischief in the first place,
2. most users knowing how precious it was and being asked to behave like adults and respect it,
3. using those same tools to see what others were doing and mutually policing,
4. using spy tools to make sure people weren't floundering and frustrated but helped to succeed,
5. treating even guests (tourists) with respect,
6. "security through obscurity" still worked back then.

I didn't understand how critical this was until I started using a Digital Equpment Corporation (DEC) commercial TOPS-20 OS on basically the same (PDP-10) hardware. I felt suddenly way less productive and was at a loss for why. I went back to an ITS host and enumerated all the programs in the system directories (SYS, SYS1, SYS2, and SYS3) to see what was missing.

One realization was that most of that software just supported other ITS software. It wasn't what was missing.

The other realization, something I then had no name for but with benefit of history I now do, was that ITS was an early form of social media. I think that's a better, less nutty way to make sense of its spying capabilities, such as the DDT (shell) command called “os” (for “Output Spy”) to say whose console to spy on.

What passed for display back then was more primitive than you may be thinking. In most cases, and I'm not going to go into exceptions here, it wasn't even bitmapped, just 7-bit ASCII characters assumed to be in a fixed font determined by the console display device. If you saw that device, you might imagine it to be a personal computer, but it was just a display. All computation was on a centralized mainframe operating system the size of a room, and running the ITS operating system, a timesharing system that let multiple users be connected at once.

Note that this was not camera spying. There were no cameras on these machines. No real provision for that kind of thing. This was just a view into the stream of character text and display codes that were rapidly flying by on the way to the user's console. The “modern” (or, perhaps better, “surviving”) analog would be the ANSI escape codes you can use on things like a Linux terminal window to get simple display effects without presuming much about the specific font size or family.

Like in Star Trek TNG episode “I, Borg”, TOPS-20 made me feel like Hugh did: There were “no other voices in my mind”, voices of other users that I might “hear” on ITS. (Metaphorically “hear”. We had no audio back then.) The difference between ITS and TOPS-20? I was lonely, just as Hugh was. I could send messages on TOPS-20, but only private ones. Socializing information, knowing what others were doing, sharing work? All very hard on TOPS-20. The silence was deafening.

Similarly, you might ask: Why would anyone be allowed to see somebody else's screen? Why would that ever not be creepy? Why would someone want you to read their messages to/from others?

Well, isn't that what we do on Facebook in the modern era? Or on tools like Slack at work? Somebody starts a conversation and others arrive to see it, see what's been said so far, and add to it. That's how ITS felt. The metaphor used by these other systems is not “spying” but in practice it's very similar. You'd login, notice friends were online, read their recent messages to find out what was going on, and then (once caught up in conversations), join in. Details were different, but in the social media paradigm it's easier to see why it felt not so much creepy as fabulously useful, especially compared to the isolation of other OSes of the time—and even some now, though that's finally changing, catching up with ideas we explored decades ago. In the context of the era, it made us enormously more efficient than you might have expected by creating synergies not available on commercial systems that had to try to be secure.

And the ability to watch somebody else's screen? Well, we do that in zoom today by screen sharing, though we now elect when we do it and when we can't. Still, it's powerful. In fact, ITS had mechanisms to let someone else not only watch but intervene in and type to your console as they watched. That was more powerful than you can do with simple screen sharing now, though more elaborate tools do exist. It's all a matter of trust, and back then we afforded ourselves more trust than one might today imagine.

Social trust, more often called “freedom” is a tricky thing. It accepts a certain risk along with almost a prayer that people will use it wisely. Once it's abused, it's quickly a tragedy of the commons. Preserving such trust, such freedom, is more important than people realize. It wasn't enforced by programs, but by social conventions, by who we revered and who we did not. There is an analogy to be made to real world society and politics today, but for brevity I'll leave that as an exercise to the reader.

My point, though, is that people too easily imagine it was uniformly more primitive back then. There were technical limitations, certainly. But it was different too. Not easy to compare. No camera, just screen, and no ability to opt out of sharing it. And it wasn't really the screen you were sharing, just the codes that had been sent to draw on it, obtained starting from an arbitrary point in the output buffer (a sort of low-level, ephemeral event queue). Often it looked crappy on a slow terminal trying to watch a fast one because of data loss trying to keep up, or trying to watch a screen with sophisticated display capability from a screen (or even “paper terminal”) lacking such capability. And it could be hilarious or frustrating if you spied on someone who was spying on you, with those characters just going back and forth in an endless loop. Even so, most of the time, it worked pretty well. You could usually tell what someone else was doing.

It was also an early interactive, collaborative development environment. Programmers worked with each other and users (who they could watch using those programs to learn directly how well they worked). We had no lack of ideas and a very specific sense of what was working and what wasn't in the things we had. A lot of today's “new inventions” may be things we knew we wanted. We were limited by what tools were implemented, so progress started slow. And processors were slower than today, so that didn't help. But people were clever, and much more careful with time/space efficiency than today.

As just one example, I recall Emacs starting in about 3 seconds on ITS, on a PDP-10 with 10-15 users. I'm sure it took longer with 20 or 30 users logged in at the same time. Today, on much faster personal hardware, Emacs starts fast but still not instantly. Of course, more happens now under the covers. And more flexibility— and sloppiness—are allowed. But Emacs (then implemented in TECO, not yet Emacs Lisp) was a real wonder in both size and space efficiency.

Back then if something didn't work, you sent a bug report. Bug reports were something everyone learned to write as part of their civic duty to make sure stuff got better over time. Another social detail. You could report a bug on anything by mailing to BUG-whatever. Host names were optional, defaulting to the local host. It was a small community. If there was no actual whatever corresponding to the bug address sent to, the mail was delivered to BUG-RANDOM-PROGRAM to make sure nothing got lost. Someone seeing the report, who might be a maintainer or even just someone casually peeking in on that maintainer's mail, might say “show me”. So you'd reproduce the bug on your console and assume they were able to watch along as you did. Again like Zoom (the screen sharing part, not the video).

Most stuff lacked formal documentation. If there was a "Help" option in most programs, it usually just told you that documentation would get there eventually. A major exception was Emacs, because TECO libraries forced you to document each function, and most people did. But most other programs had no help at all. I remember being surprised, years later on a commercial system, that someone was able to figure out a program. “I looked at the documentation,” they said. “Oh, I replied, people are actually doing that now?”

But lack of formal documentation did not mean ITS users went without help. Many just typed queries to the DDT (shell) command line, vaguely like you might do with Copilot in a modern system. The user would probably see a syntax error if they typed such a question that way, but often someone would be spying on them, especially if the user was new, to make sure they were doing OK. So they might volunteer an answer based on what they saw the user doing, syntax errors and all, maybe before the user asked. ☺

It was primitive tech, but we pushed it to its limit. And the lack of security helped a lot by not wasting programmer time, program memory, and execution time doing things we had no need of.

We built many sketches of our imagined futures. ITS was all about that in a way other OSes of the time were not.

---

Author's Notes:

If you got value from this post, please “Share” it.

The two PDP-10 photos were taken by me.

Sources for a meticulously reconstructed approximation to the ITS environment are available at GitHub. It is intended to run on an emulation of PDP-10 hardware (the KLH-10 or the SIMH emulator). Although you might want to join the ITS-Hackers discussion forum and find an existing emulation. It's a social system, after all, and you'll have more fun and learn more if you find a place where there are others to commune with.

I'm told by Lars Brinkhoff, subsequent to publishing this article, that some people did pronounce “ITS” like the single syllable “its”! He cites Barbara Liskov and some “Zork people” as having confirmed this. There were four ITS machines (AI, ML, MC, and DM). DM (“dynamic modeling”) was where Zork arose, and always seemed to me a community slightly more insular from the other three. Perhaps this was a result of that same cultural separation. I'm just speculating, though.

Some follow-up discussion about this essay occurred on a Google groups thread.