This page contains some of John Hogg's thoughts on the subject of MTS and its place in the world.
Although I worked at UBC, these statements shouldn't be construed as some kind of UBC position paper. One of the entertaining and educational and productive things about the MTS world was that opinions differed significantly within MTS installations as well as between MTS installations.
Significance of MTS
Was MTS significant, and is there any remaining significance? If so, to whom was it significant, and how, and how much?
Students, faculty, and staff at MTS universities
For almost two decades. MTS provided the primary computing experience for many students, faculty and staff at the universities which ran the system. At UBC alone, back-of-the-envelope arithmetic suggests that at least 30,000 people cut their computing teeth on MTS in an era when computing was embarked on its expansion into so many corners of human activity.
As far as I'm concerned, this is the major contribution that MTS made. All these people had access to computing services that were more easily learned and much more widely available on their campuses than they would otherwise have been. It's no small matter to have participated in an effort than contributed to the learning experience of so many people.
MTS institutional relevance
I'm ill equipped to comment on the experience of other universities at the level of university management. However, I do know that at UBC, the history of university decision making with respect to computing is mixed at best.
During the MTS years, UBC got more computing power delivered to more people for fewer dollars than most other universities. That was certainly relevant to the institution, and it was appreciated by at least a few of the university administrators. However, that didn't seem to matter much when the university had the opportunity to make strategic decisions about resource allocation and direction. It's not just that they largely ignored the Computing Centre, they also ignored the Computing Science department and other departments in the Arts and Sciences and Engineering.
The one exception to this was in the area of networking. I think this was at least partly because the Computing Centre networking people were more politically savvy than other groups. At any rate, the early successes at making MTS available campus-wide provided the basis for some later successful efforts to network the campus more completely, at higher speeds, and using new protocols as they evolved.
The MTS developers and the MTS community
The unreasonable ineffectiveness of MTS
OK, so MTS worked well in a number of ways over quite a period of time. However, given all those early successes, it seems appropriate to ask why MTS is now so little known in the world at large.
In his book "Dreams of a Final Theory", Steven Weinberg refers to what Wigner called the "unreasonable effectiveness of mathematics." Then he turns Wigner's phrase on its head and uses most of a chapter to discuss the "unreasonable ineffectiveness of philosophy." If you'll allow me the privilege of a stretched analogy, I'd like to try to address what I see as the "unreasonable ineffectiveness of MTS".
When I say that MTS is somehow ineffective, I mean now, not then. It was certainly a very effective system in its time. However, given its history, you might expect it to be better known. After all, Multics still gets mention. For that matter, so does CTSS. I'd guess that both those systems were used by fewer people over their lifetimes.
Why? Let me suggest a few possible reasons. None of these reasons invalidate the many positive attributes of MTS. They're just possible explanations why MTS faded from the collective consciousness of the computing world. These are not in any particular order.
We didn't sell MTS
I think that, collectively, we (the MTS community) did much less than we could have to promote MTS. This was not entirely accidental. I can remember some heated discussions at MTS workshops on topics related to this. There were some people who wanted to do more, but the prevailing opinion was that we were willing to help people adopt MTS if they came to us, but we weren't willing to go to them.
A large part of this was fear of a possible "free rider" problem. All the MTS installations contributed lots of time and effort to the development of MTS. The idea that late comers might be able to walk in and use the system without contributing was offensive to many MTS people.
Another factor might have been (whisper this quietly) arrogance. We were here first, we thought of ourselves as top notch developers, and who might these other green newcomers be, and why should we listen to them?
So we missed the boat on promotion. I confess to guilt on both counts: "free rider" fear and arrogance. Interestingly, you can see signs of both of these things in the Open Source (or Free Software, pick your religion) community. That hasn't crippled the spread of GNU software and Linux, at least partly because the Open Source community has a good supply of promoters. In some cases, zealots might be a better word. And it seems to work.
Speaking just about UBC, I think UM was better at getting the word out about MTS than we were. For instance, several UM people wrote papers that were accepted and published in well known journals.
We alienated some of our user community
Later in the life of MTS, I suspect that some of us (including me) weren't as open to ideas for change as we should have been.
Example 1: at least at UBC, we didn't cooperate with the Computing Science department as much as we should have. For instance, they wanted to have a way for their senior students to work on the internals of a system. We dismissed requests to give them access to MTS. We should have tried harder to find a way to accommodate them. After all, there were possibilities: the virtual machine, a second hand 4341 ...
Example 2: many people hated being told what they had spent at the end of every session. We didn't listen carefully enough to those complaints. Consider the effort that cell phone providers, ISPs, and hosting companies put into providing varying billing plans. Some of those plans, tellingly, are designed to at least provide the illusion of flat rate. None of them inform their customers of the state of their account after each session or call.
Example 3: software developers outside the charmed inner circle could not deploy programs into a well defined public name space. Only the priesthood could create software whose executable name started with the magic asterisk. This meant that perfectly competent people who wrote perfectly competent and useful programs were made to feel like second class citizens when they tried to make those programs available to their colleagues, the campus, or the MTS world. I think we were less sensitive to the negative psychology of this and other insider/outsider distinctions than we should have been.
MTS ideas may have been invisible to most people
Many of the ideas that were developed in the MTS context were "internal". By that I mean that things like virtual memory, multi processing support, and clever paging algorithms weren't very accessible ideas to much of our user community. They were crucial to the quality and effectiveness of the service, but many people didn't understand them
Contrast this with Unix, in which things like the combination of pipes and unadorned text as a loose component coupling mechanism were directly exposed to the user community. Add the idea of replaceable command shells, and you have a very visible kind of computing style that distinctly represents the system.
This may have been a somewhat time-dependent disadvantage for MTS. When MTS was first developed, these internals were not widely understood. The MTS developers had to put energy into the user-invisible things because otherwise they wouldn't have had a viable system. Unix came along later, and many of those "internal" issues, if not quite easily solved problems, at least had lots of precedents to help.
MTS wasn't portable
MTS was trapped in the 360/370 world. When that world shrank, MTS had nowhere to go. In contrast, Unix migrated among various architectures.
MTS didn't scale well
Because MTS was very parsimonious in its use of resources, it should have been able to scale to desktop systems. As a matter of fact, there were some efforts to port it to smaller scale 370 clones and emulators.
We at UBC had connections to an Amdahl project manager (John Hiles) who failed in his attempt to get Amdahl to build a desktop 370. Partly out of frustration at this, he left Amdahl and formed his own company to do just that. He actually got the hardware built, but he failed in solving the software problem. He explored the possibility of using MTS, but it turned out that getting commercial licenses for many important MTS components such as compilers was effectively impossible. In many cases (IBM being the most important one) the companies that held the rights to the software wouldn't even negotiate with him. As a one-man company, he wasn't believable as a market. He also found it difficult to get clear answers to questions about commercial usage of MTS itself.