A HISTORY OF COMPUTER COMMUNICATIONS: 1968 -1988
An Interview with
Conducted by James Pelkey
March 16, 1988 - Cambridge, MA
Severino knew on graduating from college that he wanted to be an entrepreneur. He joined Digital Equipment Corporation in 1967 as a design engineer for industrial control systems. In 1972, he left DEC and joined the start-up Prime Computers and, among other projects, designed a product to interconnect multiple computers. Then in 1976, Severino became a hands-on entrepreneur when he joined the unfunded start-up Data Translations, a company focusing on building data acquisition products. Although the company would become a success, Severino, wanted to head his own company, not just be a key member of management, and resigned in 1979 to find a compelling opportunity. In May 1981, he founded Interlan, an early Ethernet Networking company. By the fall of 1984, success forced the need for more cash and the Board of Directors decided to sell the company. On March 1, 1985, Micom acquired Interlan for $65 million. Severino became Corporate Vice President, Product Planning and Technology. Frustrated in a staff role. Severino resigned in September intent on founding yet another company. In May 1986 he founded Wellfleet, a company to become an early leader in Internetworking and in the years ahead a public company.
JLP: You started off with Prime in the late '60s.
PS: Until '72.
JLP: What were you doing there?
PS: I actually started off at Digital as a design engineer, and I actually worked in the area of industrial control systems for DEC, and I was very very interested in startup companies. By the time I got to DEC, it was a hundred million dollars in revenue so that part was past. It turns out that Data General started in '69, '70, somewhere around there, and I was just out of school, so I was also too late for Data General, so I kept my eyes peeled for a startup, and in 1972, wound up here at Prime Computer. And there weren't a whole lot of startups back in that day, by the way. Very few startups.
JLP: What was there about why were you looking for a startup?
PS: I just was enamored by the fact what had happened at DEC. What happens when I went to DEC, it was one of those places where they just throw you in. You come out of school with a BS degree and they throw you into here, go do it, and you have to learn, you have to learn real fast at a place like DEC in those days. And what happens is you have a bunch of senior people, engineering people, who help you, and those senior engineering people all happen to be people with badge number 50 and 60 and 70, and they talk about the way it started, and you say and I said to myself: "God, this is this sounds like really what I'd like to do."
JLP: And this was in interviewing you learned about this?
PS: Well, no, after I got there. It turns out, I found out actually found out about DEC from when I wan in high school. I went to a technical high school and it was a Catholic technical high school, and the priests wanted to buy a PDP8 in 1965, '64, so badly, and we used DEC logic modules, so I knew about DEC when I went, and RPI when I went to interview, I saw Digital Equipment Corporation, not very many people knew about it, and I went and signed up, and I was hired. So that's how that happened. But anyway, Prime started.
JLP: So you were aware of this kind of growth that they had gone through.
PS: Yes I was, and I also looked at the history. You know, when I took the job I saw a sequence of growth, etc. And DEC was an incredibly exciting company to work for in those days, and probably still is, but I've been out of there since '72, and DEC was just, you know, you go do it. Take it from beginning to end. You're responsible for a product, in those days, you're responsible and project engineer, responsible from womb to tomb, basically, on the product. From like conception right through manufacturing.
JLP: Oh, that's great.
PS: So it was a good, good experience. Prime started in '72 with a bunch of Honeywell people who spun off and formed Prime Computer, and they had a very tough time recruiting DEC people. In fact, almost all of the original people at Prime were from Honeywell 3C, in Framingham, and just a in fact, only two or three DEC people were over there. And the strategy at the time for Prime was to replace Honeywell minicomputers, and part of that the architects of the computers, etc., were all brought over from Honeywell 3C when they started in February of 1972, but what they needed was people who knew how to do industrial control kinds of products, and so that's how my name came up. And I went over and interview at Prime. It was in 7,000 square feet, there were about 30 people. There was one little box on a the desk, on a workbench, that was the prototype. People were working crazily on a couple of wire wrap boards that were the CPUs.
JLP: Oh, that must have been really enchanting for you.
PS: And I interviewed with Bill Poduska and Joe Cashen and decided that it was a good thing to do, so they made me an offer and I accepted it and I went down to Prime in 1972.
JLP: And what were your responsibilities? What did you go into Prime as?
PS: Well, there were only about seven or eight engineers, really designers, and what I did when I first started there, I actually was given the project of finishing off the I/O, the whole I/O bus for the machine. It had been started and we needed to finish the design, make sure everything worked, make sure it was reliable, and then do a sort of standard interface that was going to be used on all of the I/O peripherals. And so I got the job of doing that, and when I finished that, I went immediately into doing front ends for data acquisition front ends, A to D converters, digital I/O, industrial digital I/O, that kind of stuff, to make a real time industrial control computer. In fact, in the early days of Prime, not a lot of people know this, but the early orders that Prime received were for that kind of product.
JLP: No, I wasn't aware of that.
PS: Yeah, in fact, the first full year of business, and I don't remember the numbers, I think it was about $700,000 Prime did in the first full year, in 1973, half of that was from 3M, and it was a big industrial control system. So, it was important in those days. As the company grew, Bill Poduska, who had been at Multix at MIT, had the idea of putting paging and making a timeshared minicomputer. So he actually had put into the original design some logic that did paging. And in fact, the Prime 300, after a couple of years, became the biggest seller because it allowed like eight users on an operating system that we used to call DOSVM, Disk Operating System Virtual Memory. It allowed eight users to work to use a single minicomputer, and in those days, you know, it was 11 you're competing against 11/20s and 11/45s. Data General was still selling Novas. So there wasn't any concept of memory management or any concept of this what was done in Multix basically. You know, full virtual memory, segmented page virtual memory. And by 1974, we actually had started a project for doing a full blown 32 bit internal data path page segmented virtual memory minicomputer, with a 21 bit or 22 bit, if I remember correctly, real address space and a much larger virtual address space. And so that project was put together, but just before that was put together, Prime had a problem in that they wanted to someone had sold a system that had to have two computers that talked to each other, and I was sort of, I was sort of recruited to do this project, to make these two computers talk to each other. So what happened was, they threw out this spec to me that was a Honeywell Intercomputer ICCU it was called, Intercomputer Communication Unit spec, and they threw it to me and said: "Ok, we need this done. You know, we're late. The customer wants this. We don't have anything to give him. You got to do this project." It was a hardware project at the time. So what I did was I looked at the spec and it was just a parallel a 16 bit parallel interface between two computers. It was clearly done for the computer room. Just interconnect two computers. And I looked at it and I said: "Well, why don't we make this so that it extends a little bit and we'll make sort of a daisychain, and we'll make an eight computer interconnect, you know, host to host interconnect," and this is before this is in 1974, probably, '74, '73. And so what I did was I designed a twisted pair multitwisted pair interface, that was a parallel interface, that used that was asynchronous in nature. It looked like a computer I/O it looked like a Unibus is what it looked like, and I had a master/slave kind of relationship on it. Anyway, I made this eight computer network. Very high-speed network, daisy-chain. What happened was it just went through. You dropped it off and picked it up, dropped it off, and you know, you pass grants through and I guess it was like it was not a token ring or an Ethernet or anything like that, it was just a bus, but it was done, extended, and I used bus drivers and, you know, you could go probably 100 feet maximum on the thing. But anyway, we had this piece of hardware and I got, actually got only two computers working, and then we jumped on this other project. We shipped it. It was fine. There was no real need to do anything more than two at that time.
PS: And I never checked it out beyond two, but was working for two, and we did this Prime 400. The Prime 400 was the first 32 bit full virtual memory, segmented page virtual memory minicomputer, and it it was a very big success. In fact, it was the biggest it was THE product that made Prime. By the time we shipped the first one, Prime was doing about 10 million, and then shortly thereafter Prime went from 10 to 20 and then 20 to 40 and then the rest is history. It kept doubling all the time.
JLP: And this was the 400?
PS: That was the Prime 400. That was actually introduced in 1976, spring of '76, but right after that, right after the machine was introduced, I actually left Prime to do another startup company, and what happened was I still wanted to do a startup. Prime, I was there almost five years. Prime was doing fine. It was a struggle for the first bunch of years. Ken Fisher had come in. He was president, and I just wanted to I was still designing, and I wanted to do a startup, and I had two friends, two people that I knew who worked for Analogic Corp. and they actually spun off of Analogic and started to build a product called Data Acquisition Module, again this is going back to the data acquisition part of it. And they really they had this module and Bernie Gordon was suing them. There was a lawsuit in progress, and there was no venture capital.
PS: So they sort of they were sort of struggling through, trying to make this thing work, and what was missing was that they wanted to take this data acquisition module and put it on a board that plugged into some microcomputers, for example, LSI/11 was just beginning to take off, and the Intel Intel was bringing the 8085 and all that stuff together on boards. So I left Prime and went to this startup that had no funding and no way to pay anybody.
JLP: When was this?
PS: In the spring of '76. And anyway, the name of the company was Data Translation, and we started to work on that, and for the next five
JLP: Was Fred there?
PS: Oh Fred was the president, Fred Molinari, he was president, yeah. In fact, it was Fred and another guy by the name of Aaron Fishman, who left shortly after that, and me. That was it, and we built a company. We bootstrapped a company, until today its probably do about 40 million in revenue, public. So I spent the next five years doing data acquisition products on microcomputers, board level products, and I think the importance of that will come out later. But during that time, Bill Poduska decided that Prime should have a network operating system, and he took basically took some software guys and put them on this network operating system project, and the first piece of hardware they wrote for was this eightin computer interconnect that I did. And they did that and they started to do the first releases of PrimeNet back in '77, '78, and at the same time, they started to work on a token ring interface, a token ring network, basically. A 12 megabit, you know, token ring. It was Prime's own token ring network. It wasn't a standard. It had nothing to do with any standards, but it certainly was packet network, and I don't know exactly now all the years that Prime actually announced that and shipped those products, but if you look back on it, and there are some people that can tell you, and I can give you some names of people who can tell you about that, Prime was probably one of the first minicomputer companies to have a real LAN.
PS: A real LAN, not just a hardware LAN, but I mean software, hardware, the whole thing. It could do file transfer, terminal access, etc. But it all started with this first computer interconnect thing that we did in hardware and then Bill put some people on it to write some software around that.
JLP: Do you did you ever come to understand why they picked token ring?
PS: No. I wasn't involved in that. I had left by that time, but there are some other people there that you can talk to that would know that. In fact, I know the engineer who did the project, who's still at Prime.
JLP: Oh, great. Who is that ?
PS: His name is Bill Farr. He's still at Prime. He's a senior very senior engineer over there. In fact they used to call it, when he was working on it, they called it the FarrNet project. Now, you know, that sort of gives you the reason why Apollo's domain is a token ring as well. It came from that background. They first developed a token ring at Prime. Ok, data translation. I'm away from computer and networking and I'm in data acquisition, except I'm in microcomputers now. We did stuff for Multibus and for Unibus and Qbus and just the whole bus structures. Again, about five years goes by and I start to feel like, well, Data Translation is on the road, you know. Fred's really it's his company, even though I had a big part of it and I had a nice ownership piece, he was running it his way, and I just felt that it was time for me to think about doing something else. So that was in 19 the end of '79, probably, and I talked to a number of people. I looked at a number of business opportunities. I didn't want to compete with Data Translation, so I knew I had to do something else.
JLP: Were you head of engineering at Data Translation?
PS: Yeah, I was VP of Engineering. I didn't want to compete with Data Translation, so I was looking for something else, and the only other thing I had done was this computer interconnect stuff, other than computing computer designs, so I started to think about the fact is high speed networks, computer networks, there ought to be something there that we can go off and put something together on, but I couldn't see it until I saw the first Blue Book, Ethernet Blue Book spec. And what happened was the Blue Book spec appeared, and I heard about it, and I got a hold of one, and I looked at it, and I talked to a number of people, some DEC people I knew, etc., and everyone seemed to think that, you know, and I knew about the PrimeNet, the token ring at Prime, and I said: "You know, the biggest problem you have with doing something that's proprietary is from a small company is, that nobody wants to buy it." So, if this thing really looks like it could be a standard, this is the place to do it. And it turns out, by the time that I looked at this, there was only really one company that was visible in LANs and that was UngermannBass. 3Com hadn't really announced any products yet, and it was really a consulting house.
JLP: And this was summer fall of '79?
PS: The Blue Book came out in '80.
JLP: Excuse me, '80, yes.
PS: The first Blue Book actually appeared in the fall of '80, ok, but I knew about it ahead of that, a little ahead of that. I knew about the Ethernet, and the Ethernet specifications
JLP: Because you were poking around, looking for something.
PS: Right, right. But what convinced me was when I saw the published Blue Book.
PS: And, by that time, when the Blue Book was published, there was also a public announcement by DEC that they were going to support it and that Intel was going to build the chip set. So I said: "Ok, that's enough. It's time to move." And because of my contacts with some folks like, for example Russ Planiter who is at Prime, he was a VP of Marketing at Prime, he and I were good friends, and we had dinner a couple of time in this time period about some ideas I had, about some businesses I wanted to start. I was looking to him for some advice, and when I sat down and had dinner with him one time in well in the end of 1980, around October time frame, right after I saw the Blue Book, I told him I thought that I had finally found something that I really thought could go, and that was local area networks. And he basically informed me at the time that he had pretty much decided he was going to be a venture capitalist and he was entertaining joining J H Whitney, they had offered him a partnership, I guess, and he said that if I wanted to work on it, he and I could sort of work on it together, and all he asked me for was right of first refusal on the business plan. So that's what we did, and we built this business plan about a LAN company that was going to be board level oriented, which is a different approach from what was going on then.
PS: By that time Ungermann, I think, was he was shipping product, I think, or just starting to ship product, had announced product.
PS: But it was a big terminal connect box. And I was going to do board products. And business plan basically said first computers we'd connect to were VAXs or Unibus machines, PDP/11s and VAXs, Multibus machines, and Qbus machines. That was 1980, the end of 1980. And put the business plan together. Russ went over to J H Whitney. We worked on all the issues, decided that I had to have an Ethernet expert in the company, poked around and found Dave Potter. Now, a Saturday morning, one time, I just gave him a call, told him who I was, what I was doing and told him I wanted to talk to him about starting an Ethernet company. He agreed to talk to us, so
JLP: He was DEC's representative on
PS: He was DEC's representative on the IEEE committee, and doing a lot with the Ethernet spec. There were also some other folks, like Bill Seiffert who was working on that inside DEC, who actually joined who joined us even before Potter did, it turns out. He joined Interlan before it was Interlan, he agreed to come first, early early days. And so we started this LAN company, and it turns out that as we we didn't know it at the time, but 3Com I'm not sure whether 3Com had announced their transceiver yet or not, but it was around that time frame, and we found out sort of after we got into this, that 3Com was going to build DEC compatible boards as well.
JLP: Now, this is the beginning of '81.
PS: Yeah, this is the beginning of well, we actually incorporated Interlan in May of '81.
PS: And I believe at the time there was no announced there was definitely no announce board products, because we announced our board almost the same time as 3Com.
JLP: Right, which was in June of '81.
PS: Well, it was, no, we announced our first products in November of '81. So we actually had Ethernet products announced we had our Ethernet board products for DEC computers announced in November of '81, and we shipped we actually shipped the first ones in January of '82. That was another thing that we did that was kind of interesting. We started May we incorporated in May. We actually opened the doors on June 1st, 1981, ok, and we shipped our first products in January of '82, which is seven months later.
JLP: That's impressive.
PS: Yeah, it was a crazy, crazy time.
JLP: How many employees did you have?
PS: We only had about 15.
JLP: And it was a Unibus Unibus was your first product?
PS: Yeah, but very quickly after that we shipped Qbus and then we shipped Multibus shortly thereafter. We were shipping everything by June.
JLP: Of '82?
PS: What we shipped was we shipped, and this will be interesting to you, we shipped Unibus Ethernet, Qbus Ethernet, and Multibus Ethernet, and we had drivers, no protocols, just drivers, for VMS, RSX11, and on the Multibus I guess on the Multibus we didn't sell a driver for a while, cause there wasn't any real operating system on the Multibus at the time. And we shipped Olivetti transceivers, because we didn't want to buy transceivers from 3Com, cause they were competitors, and the only other transceiver on the market was TCL. You heard about TCL?
JLP: In England?
PS: No. TCL was a little company in the Silicon Valley, and I don't remember the founder's name, but he was a Chinese guy, oriental, and he was building transceivers. In fact, he was one of the first people to build transceivers for Xerox, and he built it in a little black box, and the problem we had with his transceivers was that the tap mechanism that he had was unreliable, so we decided we wanted a coax connected transceiver for reliability. He had a passable tap mechanism that was unreliable, that we felt was that Dave Potter felt was unreliable, in fact, so we had to find another source, and we decided to buy from Olivetti, and then shortly thereafter, probably about six or eight months later, we actually built our own transceiver, with the with the first amp passive tap. I don't know if you remember that one.
JLP: Absolutely. And you were shipping, at that point in time, Intel had chips out?
PS: No. There was no.
JLP: You were
PS: We made our own Ethernet, just like Ungermann and so did 3Com, and in fact I believe probably I don't know whether Bridge did. I think Bridge did as well.
JLP: Yeah, they must have.
PS: And ours was actually we actually did it twice. It turns out what we did we did something really right there. We had boards that were we had a motherboarddaughterboard approach, and the reason for that was twofold. One was that we wanted to have a family of products that started out with a board that allowed you to build your own Ethernets, and then use that on our own boards so that we can take and put them on different kinds of interfaces, Multibus, Unibus, Qbus, whatever. And also
JLP: That allowed you to get your products out quickly.
PS: Yeah, and also, if we had to make a quick change to some other thing, like a token ring. Even back in 1981, IBM was talking about token rings, and we didn't know whether Ethernet was going to be the network of choice, or the right network, so we felt that if we had to make a quick choice over to a different media, by doing one board instead of however many we had done, keeping the interfaces the same, which meant that we kept the software the same, the drivers the same, then we wouldn't have to do anything about it, we wouldn't have to change things. So we actually sold a lot of those modules that were just Ethernet modules. The first one we did we did with a Z80, and it was way too slow.
JLP: A lot of people picked the Z80, I mean, the Z80 was a chip back then.
PS: Z80 was, you know, the first thing we did was a Z80, but the second one we did, which was very shortly thereafter, was a bit slice, and that's the one, in fact, that's the one that's even still shipping. For Interlan it's still shipping those. What happened was, it's a kind of interesting thing that sort of evolved, we came out and we were very strong on the DEC side. 3Com was not as strong on the DEC side. In fact, 3Com's first we heard that 3Com our board was a peripheral, a Unibus peripheral that you would see in a high performance Unibus system. It had a DMA interface. You know, you set it up with program I/O and then you tell it to go and it does DMA into memory, which is exactly what you want to do with a high-speed network.
JLP: And you did that because of your experience at Data Translation
PS: And DEC.
JLP: Because you knew how to
PS: Right. 3Com, on the other hand what we heard had happened at 3Com, and Bob might be able to tell you something different, we had just heard that they had actually thought about building a two board set for the Unibus, whereas one board was going to be the Ethernet interface and the other board was going to be intelligent, sort of an intelligent board and run a protocol.
JLP: Yes. That would have been his orientation.
PS: A TCPIP protocol. And what happened was that we came out, we were so fast that we had heard that our impact on the market, in being in that market, made them sort of cut back to just doing their link board, and their link board was a nonDMA that ran with just two packet buffers, and you literally had to just bring data in and then do a move transfer over the Unibus.
JLP: Ah, so it was not competitive with your products.
PS: Well, it was cheaper, it was lower cost. It didn't start out that way but it started out that it was lower cost. I think where we we really had them sort of on the run in that area, but what happened to us is when we found that the Z80 thing didn't go as fast as we wanted it to, and we didn't have a lot of time to figure that out because we were so fast getting to market, that we there was a little hiatus there where 3Com gained some ground because our board was more expensive yet it was the data rate on the Ethernet side was slower until we changed it to a bit slice.
JLP: And when did you come out with your bit slice?
PS: Oh, it was only it was like in July or August.
JLP: Of '82?
PS: Yeah, so it wasn't far. It wasn't fast. It wasn't far along. But what happened was, probably the biggest area of business on Unibus Ethernet connects in those days was the fact that Berkeley was coming out with a release of VAX, Berkeley UNIX release.
PS: 4.2, and there were only two board manufacturers, us and 3Com, and what Berkeley did was finally they just tested both boards and then they said: "Ok, there's drivers for both. You chose what you want," but we sold an awful lot of Unibus Ethernet boards, and awful lot. It was a big part of the business in those days, just because of the Berkeley release.
JLP: Now, what was DEC doing? Didn't DEC have boards?
PS: DEC finally came out with a board about a year and a half later. I don't remember exactly when it was, called a DEUNA, and that was a two board set. It was very expensive. It was basically slow and people that Berkeley VAXs just weren't interested in it. You know, we never saw them as real competition.
JLP: So if someone bought Berkeley VAX, they bought your board?
PS: Pretty much they bought ours or 3Com's.
JLP: Which would mean that the government, and anybody that had a relationship
PS: Oh, we used to sell pot-loads of them to people like Techtronics, yeah, to the government. I mean orders used to just come in from (unintelligible). We didn't even have to
JLP: You didn't have to sell, they just came in, cause Berkeley UNIX was just a rich
PS: In fact, it's still in fact, if you buy Berkeley UNIX today, I guess maybe they've extended the latest UNIX release to it supports some of these intelligent boards, like Excelan's now and Interlan also has an intelligent board, but that was the early networking on minicomputers, it was all VAX.
JLP: Oh, well Berkeley UNIX made TCP/IP.
PS: Right, exactly.
JLP: I mean, it was out there, but until that free code got out through and Bill Joy's buggy version of it
PS: Well, and the other thing that happened in the early days was kind of funny. You know, Bill Poduska, who is the founder of Apollo, he was on our board of directors, and I was out doing a lot of selling in those days, and I spent a lot of time on the west coast, and one day I actually was brought in by a regional manager to this new startup company called Sun, and I walked in and there was Bill Joy and Andy Bechtolsheim and Vinod and I think Scott McNeely was in the back room sort of doing manufacturing.
JLP: I tried to take them on as a consulting company when they were six employees.
PS: Right, and we all sat around and Bill and Andy and they all looked at our Ethernet products and they really they were looking at it and they really liked what we had done, cause they liked the fact that we had a DMA interface, but in their three slot Sun workstation, they really were fully memory managed, and all they cared about was looking at packets that were looking like they were memory, and so a DMA interface on the Multibus just didn't work as well, so they decided to use the 3Com board in the interim until they actually did their own. They actually had done a 3 megabit Ethernet interface at Stanford, and they were looking for a 10 megabit interface.
JLP: How do you become aware of Berkeley UNIX?
PS: Well we had some of our internal engineering people were very aware of what was going on at Berkeley, (unintelligible). They came from DEC.
JLP: Were they worried that Berkeley was doing this port contract by DARPA?
PS: Yeah, absolutely, cause DEC was very aware of that. We went out there and talked to them. We told them about our hardware and they wanted to use it and the deal was cut and they started using it. I don't remember whether we gave them boards or whether they bought them at a big discount or something, but
JLP: Was that important at that point in time at the management level?
PS: Yeah, we thought it was very important. In fact, one of our sales managers who actually made the first contact really pushed very hard that it was very important, and we all agreed with him that it was.
JLP: Yeah. Now at that point in time were protocols an important issue to you?
PS: Yes, they were. We had what we had done is once we had the hardware out, we decided, and this is another interesting story, we basically wanted to make a decision about what protocol we were going to support, and there were a choice of two, XNS or TCP/IP, and we looked at we did a study on both protocols, and at the time, this was before Berkeley, although we knew Berkeley was important to sell in a certain area, for our own products, we were looking for protocols that had certain characteristics, that were efficient, that could be made to go fast, you know that had
JLP: So you picked XNS.
PS: So we picked XNS, along with Ungermann and Bridge and 3Com and everybody else in the field, because if you looked at the two protocols from a technical point of view, XNS was designed for Ethernets, and TCP was designed for big wide area communications systems and had lots of overhead to it. And we picked XNS and we set about implementing our XNS protocols.
JLP: Did you write your own protocols?
PS: Yes. We wrote our own XNS protocol.
JLP: Where did you get the understanding of what they were?
PS: There was XNS level III and IV there was a published specification. Problem was that we got we implemented XNS level III and IV, and we started to sell packages of software and boards, and the idea was that as soon as we had the ability to get the chips, we'd put processors on boards and start to sell protocols on the board. Our first set of protocols we ran in hooks. So we ran XNS protocol under VMS.
JLP: And when did you do you recall when you released that?
PS: Yeah, that was in that was I think at the end of '82, close to the beginning of '83, but I could look back to find out for you.
JLP: Ok. Now when you were and going back to the end of '80, beginning of '81 when you were thinking about starting a local area network company, were protocols important to you at that point in time?
PS: Protocols were, but we felt that, you know, you had to get some hardware out there first in order to get people starting to use this thing.
JLP: What were people going to your concept of what were people going to be able to how would they use it without
PS: What were they going to run with?
PS: Well a lot of it see, we were building boards, and a lot of the people we talked to for those boards understand that there were a lot of companies that were looking for a standard way of interconnecting CAD stations, workstations, I mean Apollo was doing their first workstation projects. They had some first workstations out where they were actually doing interconnects. They were not running, by the way, any protocol, Apollo. They were running Domain, but if you look at the Domain protocol, it was a very simple ACK/NAC protocol for packets, ok. So there was a need to get onto a bussed network, and Ethernet was a standard, an emerging standard, ok, so a lot of the OEMs that we talked to just wanted to get hardware, and they were willing to write their own protocols and do whatever they had to do, ok. And that was only for a very few months, basically, and then we started to you know, then we knew we had to do a protocol, so we went out and started
JLP: And you knew it conceptually or you knew it because the marketplace was asking for it?
PS: No, we knew because there was a seven layer model, and it said that if you're going to be in the LAN business, you better be in all layers, and so we started at the bottom layers and we worked our way up.
JLP: Now, was Bill, because obviously Bill knew Multix, which had a big impact, and MIT was, in '79, got back into kind of local area networking in terms of doing the study where Metcalf was back here and they made the decision to go token ring and not do chaosnet or Ethernet or whatever else there I mean, so
PS: There was a lot of Chaosnet at MIT.
JLP: Yeah, AI. All the AI labs were Chaosnet.
PS: In fact, I can tell you about some of our first customers. One of our first customers at Interlan was Symbolics. Symbolics was one of our first signed OEMs, and we did real well with them, and they just bought boards and they ran them on Chaosnet software. PDP/11 type Chaosnet software, and they actually, in the early days of Symbolics, they actually sold PDP/11 based systems, and they bought a lot of product from us.
JLP: Now, were you aware, I mean, about any of those going on or were you
PS: Yeah, we were, but, you know, we felt that XNS would be the right choice.
JLP: Because of the studies you had done in terms of its speed and throughput performance.
PS: Yeah, we thought TCP was just like very it was going to be very difficult to implement. It was going to be difficult to test. It was going to be a lot of overhead associated with it, so we decided to go with XNS.
JLP: And all of a sudden, everybody had it free.
PS: Well, that was the problem. Well see it didn't hurt us too much on the business side for the boards because what happened was it was free, people would just put it into their workstations and bought our boards, our Data Link layer boards. And then when we got and then the next see what happened at Interlan was the next thing we did after we did the first board level products, it was just when the Intel chip set was starting to become available, we decided that, you know, we had host connections. What we should try to do next is that terminal stuff, and we thought that would give us a niche in the marketplace that the Ungermann’s and the Bridge’s really didn't have, which was host to host plus terminal to host access.
JLP: Cause they were terminal to host.
PS: Only to terminal to host. So we did our own terminal server in 1983, and we, in fact we I think we did the precursor to what terminal servers look like today. We did a very small box, eight ports, no disk in it or anything, all of the configuration of ports was done in EAROM, so once it was configured it was in EAROM, and we downloaded everything over the network, from one master terminal server, basically. We downloaded the, not the port configurations, we downloaded the code, you know, the XNS and all the terminal name servers and all that stuff, and it was an eight port terminal server and it was, you know, the cost per port was very low and, in fact, it's probably still one of the smaller terminal servers. And we think that a lot of the future terminal servers, in fact even the DEC Server 100, sort of looked at what we had done on that terminal server side. It was very cheap. We made it cheap, low cost. We had one 186, and we used a 586 chip so it was compact and we did very well with it for a while, until DEC came out with the DEC Server, and then we saw a lot of resistance in the DEC marketplace. But initially, we did very well with it, and in fact, it's still now it's a TCP terminal server and Interlan, probably, 1000 per quarter of those things.
JLP: Now Bridge and UngermannBass continued to sell terminal servers right through DEC's announcement.
PS: Yeah but they had taken a different approach. Their approach was, they were starting to Ralph was doing broadband by that time. Bridge was going in that direction. And they also were going in to solve a lot more of the terminal connect problems. All we were interested in was asynchronous terminals. We had no other protocols. We had no synchronous. We were just doing it we just did our own terminal server. And you know, one thing that we just understood, just prior to this DEC was very, very long in their product development cycles, and they never when they did come out with something, it was like the DEUNA. They had two boards versus we were at one, and we thought: "Well, they'll come out with something, but it'll be this clunky thing," and what happened was they first their first terminal server was a big clunky thing, but the DEC Server 100
JLP: Was a killer product.
PS: was a really very competitive product, and you know they were selling it into their own environment and people were just buying the whole package, and so we saw a lot of resistance, but basically we started to get sort of reoriented. We were starting to do some PC networking stuff. We had boards now for the PC, the IBM PC, and we were starting to we had decided to go off and do something in TCPIP, which was late. We should have done it a year sooner.
JLP: This was in '83?
PS: But we just didn't have the resources. I mean, the thing about Interlan that was so much different from the other LAN companies is we didn't we hardly raised any money, compared to everybody else. I mean our total amount of venture capital from the very beginning to the time we sold to Micom was $5 million, total, so as a result of that, this was we didn't have the dollars and the resources that were being thrown at the problem from some of the other vendors, but we did very well. We always made our numbers and we were profitable for six quarters before we sold to Micom.
JLP: Now, during that period of time as you were growing your company, getting to profitability was an important issue. You didn't have a lot of capital and
PS: Right. We, see I had my background was Prime; DEC, Prime, Data Translation. DEC was a hundred million dollar company run by Ken Olsen. It was very bottom line oriented. Prime started with the smallest amount of venture capital any minicomputer company ever had. We almost went out of business once. We almost couldn't make payroll one time. So we were always doing things like a startup, ok, always. Data Translation was a bootstrap, ok, so my theory about companies is you start them, you build them, you get venture capital if you need it, but you don't finance the company like it's going to be a $2 million company. You finance it to get to its profitability point and then you grow the business. And I think in that LAN business, what I didn't factor in was the fact that there was going to be a lot of competitors out there who had big financings, and they were going to be able to go after the business much differently than the way the early minicomputer companies, for example, went after their business. So, I think you learn that and then you realize that if you're going to be competing with other companies, you've got to compete with them on the same level all across. But we did get to profitability exactly on schedule. In the summer of '83 we were profitable, and we were on our $6 million year. So we did in '82 we did $2.4 million, I believe. In '83, we did $6.7 million, and we turned the corner of profitability in August of '83, and then in '84 we did $18 million.
JLP: Now, once you got profitable, the constraints on product development in terms of, plus this background, the mental set you came to the problem with, that is you had 10 or 15% of whatever there was that you allocated to engineering. Did you have a discipline about that that said
PS: Yes. We did plans. We did operating plans every year. The idea was to try to get to a model that said, you know, we're making 20% profit. We're spending about 11% in engineering, about 20% in sales and marketing, and about 6 or 7% in G&A.
JLP: The old 20% bottom line.
PS: You made 60% gross margin, which we did do. We made 60% gross margin consistently at Interlan. So
JLP: How did you given that 11%, were you aware of other products that you wanted to do that you couldn't fit into your 11%?
PS: Well, yeah, we wanted TCP/IP. We just kept putting it off because we had done the terminal server, I mean we started to do some PC boards, and then we tried to get XNS. What we did was, we went to Xerox and Xerox finally let us have the filing protocols and the, I don't know if they had terminal protocols the filing protocols and there was another one. And my feeling was that if we can get the filing protocols, then we can start to provide this multivendor file transfer capability, ok.
JLP: When did you get those file transfers
PS: We got the filing protocols in the end, like around in '83, the end of '83 maybe, and so what we did was instead of going back and implementing TCP, which is a transport layers thing yet, we went up to the filing protocols on XNS. And it was just difficult because we said: "Gee, we got to add value here. Let's get the file transfer stuff put together between UNIX," and the idea was UNIX, VMS and MSDOS, those three. So we'd have a system where and terminal server. So you had a system where you could connect a VAX with terminals. You can connect UNIX workstations and you can connect PCs and you can do file transfer across. And in fact that's exactly what people are buying today, using TCP with FTP and virtual terminals, but that's exactly what they're buying today. That's exactly what's important today. That's what's making TCP fly, just those three; UNIX, VMS and MSDOS. Now there's some TCP/IP connections to the mainframes. People like Fibronics, Spartacus. There's some TCP/IP connections into Macintoshes. You know, it's become that transportability protocol, but the multivendor-ness, what we were trying to do, is exactly, I think, what's happened.
JLP: It just took longer to get there.
PS: It took longer to get there, yeah, and we had the we went the XNS protocol route, all the way up to the the question was: "When do you stop investing in XNS and when do you go over to TCP?" And we finally stopped you know after Micom acquired us, they finally stopped investing in XNS and went to TCP fully, which is the way to go.
JLP: Now, given this period of time from . . .
Tape Side Ends
PS: . . . TCP back, like Computer Vision was one of the first OEMs that Sun really got as an OEM against Apollo, and in fact, we were the other Ethernet supplier for Computer Vision. We supplied them with connections into their present machines. We supplied them with transceivers. We supplied them with some VAX boards, things like that that they were looking to do for interconnects.
JLP: So you were really were kind of the OEM supplier
PS: Yeah, we were an OEM supplier.
JLP: whereas UngermannBass and Bridge
PS: Are enduser suppliers.
JLP: Were enduser suppliers.
PS: In fact, our first OEMs were Calma, Computer Vision, Apollo, Symbolics, Techtronics. We sold to a lot, and Techtronics was really their Berkeley network, so that was like an enduser sale almost. Who else, God there was oh, GE Medical Systems, LTX. We also had a Data General Ethernet connection.
JLP: I didn't know that.
PS: Yeah, we did. We had the first Data General Ethernet connection.
JLP: Did you ever sell much of that?
PS: Yeah, we sold a fair amount, because Data General finally started to they wanted to buy it at first, and then they decided not to, and then their project slipped, so they actually did joint marketing with us. So we sold a lot into the Data General environment.
JLP: So you didn't compete with who did you compete with then?
PS: We competed we had we competed with 3Com in the early days.
JLP: But by the beginning of '83, they got out of the
PS: They got out of that business.
JLP: that business and just strictly went for the PC.
PS: Right, and Excelan was starting to come up on the Multibus side.
JLP: Ok, that was in '83 maybe?
PS: That was in '83, end of '83, Excelan was starting to come out with the Multibus side, and they were selling TCP and we were selling XNS. What they also had was they had the first intelligent board, really, Excelan did, so they had the protocol on board, and they you know, it took them a while to get that moving
PS: but they got it moving good, and then TCP helped them a lot.
JLP: Yes. So you didn't really for a period of time, after 3Com kind of backed out of the market and until Excelan started to come in on the Multibus side, other than for the fact that DEC started shipping Ethernet connections in the VAX free, I mean they just put them out, right? They just included it.
PS: Not the DEUNA. I don't think they in the MicroVAX they do, but not in
JLP: But when the MicroVAX came out
PS: Yeah, but that had nothing by the time MicroVAX came out, that was
JLP: Long gone. So you just dominated OEMs. I mean you were the OEM supplier to the industry.
Tape stops to change batteries
JLP: This is a catch up because the battery died. Some of the comments that we've made while I wasn't aware that the battery was dead, is that the university marketplace really drove Ethernet, in terms of adopting it readily, and some of that was because of Berkeley UNIX getting into that marketplace, that the engineering workstation marketplace and DEC was really Ethernet, and because you were the OEM supplier, you really lived in that and were really of that whole broadband /baseband, all that. It didn't really matter. You were focused on Ethernet. You had limited resources because of this kind of financial discipline you had brought with you, and you knew it was going to be successful because you were selling product and you were aware enough of the trends in the marketplace to say: "This is going to be successful." And that eventually, with the terminal server product, that took you into being more of an enduser and starting to run into Ungermann and Bridge, but you were still selling into your same marketplace, kind of the DEC marketplace, and even in the marketplace, as you were saying, you would sell the terminal to host and DEC would sell it's DEUNA’s with DECnet on it host-to-host, but you would still continue to sell in that same environment. And you had gone to $18 million in revenue in 1984, '83 I guess it was, and by the end of '84 it was a crappy IPO market and in '84 you were starting to think about the issue of: "Wait a minute. We have a very successful company on our hands." Competition was getting fiercer, and the issues about exitstrategy and about capitalization, about strategy and so on were becoming focused and the idea of consideration of an IPO was something that was, you were beginning to think about.
PS: Yeah, the other thing that I mentioned was the fact that we had been selling terminal server, we had been starting to build a direct sales organization, and we sort of needed more time on the sales organization to prove that it could be productive. We just didn't have the you know, what we had built in the past was OEMs with reps, and we needed a little more time on the direct sales organization, so we decided not to do an IPO in October
JLP: Of '84?
PS: Right, and right after we decided not to do the IPO, the concept of teaming up with a bigger company was raised, and what we said was: "If the right company comes on the horizon and the price is right and the strategy looks good, we'll do it."
JLP: And who do you recall who raised that?
PS: It was just raised internally on our board. They said: "You know you really " The concept was that you really had to have $20 million to get going in this market, in cash, and by the time we were there, you know, 3Com had gone public. I don't think Bridge had gone public.
JLP: Ungermann was public.
PS: Ungermann was public. 3Com was public, and we needed to get some cash. We, by the fall of '84, we had no cash and we actually had a little debt, ok, so we just needed to have cash in the door, and we just could not grow the business the way we thought we could grow it without having cash in the door. And we just didn't feel that the market and the company was really ready to go out to the public markets. My feeling is that if I were to take the company public, I'd have to feel very, very strongly that I'm going to make all the numbers I'm talking about. I just don't want to get into a situation where you're selling stock and not getting there. It's not the kind of way I like to do business.
JLP: Yeah. It's bad karma.
PS: So what happened was that when we said that, we worked with Alex Brown and Alex Brown just sort of put some hints down that there might be something. A partnership with Interlan was possible, and frankly a lot of companies came to the door to look around. Not to look around but just, raised their hands and said: "We're interested in that kind of thing." But the one that looked the most acceptable to us, and clearly the one that had the capitalization position that was going to allow us to get the price we wanted, was Micom. Micom's capitalization at the time was like $700 million. Micom also was facing the same kind of problems in data PBXs that we saw in dealing with DEC. DEC was taking more and more of their own networks. So we worked the issues with Micom. They were very aggressive. They wanted to do the deal, and came quickly to a conclusion from, literally from October to December.
JLP: And who from who was Micom? Whom from Micom were you
PS: Mostly Roger, Roger Evans. The reason I thought that it would work was, first of all, I was excited about Micom because Micom was an exciting company.
PS: Secondly, I thought that what we could do was to take the PBX technology which allowed for cheap terminal connects, and back end it with LAN technology, add PC connects, ok, PC networking, and start to really integrate some of these things for the Micom PBX customers. And on top of that layer on the fact that you can move files around the network. That was the real strategy. There was a lot of reason why it didn't get executed properly, but that was the real strategy.
JLP: That was a great strategy.
PS: I thought it was good, especially with Micom's installed base.
JLP: Oh, yeah. They owned that midlevel organization.
PS: So that was the strategy. We did the deal. It turned out to be about a $65 million deal. I can tell you that every investor at Interlan made a lot of money. Most of the founders did pretty well, at that price, and the problems came when the day after literally the day after the merger when, you know, just everything changed. The distributors and the reps were cut loose. The Interlan distributors and reps were cut loose. Roger wanted an operating guy in who basically was going to glue the PBX and LAN business, and it turns out he was the wrong guy. He turned a lot of people off. Most of the officers of Interlan got turned off one by one and left, and I think that was a big mistake. I think, and then on top of that Micom was hitting walls with the regular with their standard business, and so what happened was the stock started to drop. Interlan business just flattened out because we had no salesmen. Nobody was selling the products. And product development almost came to a screeching halt for a while, because this new guy came in and decided to reorganize and do everything differently.
JLP: And what did you do?
PS: Well, the idea for me, I had been trying for a few years to get out of day to day operations and become more a, sort of a strategy technology oriented person, but still doing that but also with my eye on getting the next generation of products out the door. And what I wanted so the deal that was cut with Micom was that I would become a Micom VP and I would be looking at this whole corporate strategy thing, which I did for the first four or five months. But the problem was that the Interlan side was just being kept closed, even to me, and I wanted I knew that Micom had to make some leaps in order to really compete again, and I wanted to take off a group and just go build the next generation of product, and Roger and I just couldn't come to an agreement that that was the right thing to do.
JLP: Why do you think he resisted that?
PS: I really don't know. I don't think he likes that kind of style in the company. He doesn't like to have a group. He doesn't like to have a skunkworks kind of a group go off and do something, although it you look at almost every major company, that's how they get their next generation products out. DEC, Data General, Apollo, just about every major company takes that kind of an or to get a real leapfrog, they take a group of people, they separate them away and they go do something. Roger's approach is to is been what it has. He acquired businesses and he tries to meld them into what he's got. Sometimes that works and sometimes it doesn't. It worked great on Black Box. There were a number of other businesses acquired where it didn't work, and with Interlan, we were big enough and strong enough so that, you know, sure, it hurt for the year or so, but once it got going again, it's now it's doubled again. So, you know, different cultures. I just think it's a different cultural approach. Also, the founders of Micom things changed a lot there. Bill Norred got less involved. He's the engineer. He got let and less involved to where now he's basically on the board. So it's a different culture, and I think that was that precipitated the whole issue.
JLP: So they were driven at some level. They came to the table and they were driven to do a deal that fast. I mean, they were anxious to do the deal, because of their dataPBX business, which was
PS: Was starting to hit the wall.
JLP: was starting to hit the wall, and they thought it was because LANs were going in and PCs were going in and terminals weren't going in and DEC was taking over the data PBX business in terms of their strategy
PS: Well, terminals were going in, but DEC was getting more and more of the connect business, but clearly I mean, think about it. DEC was growing like crazy. Micom's data PBX business was going like crazy. It was one of the few solutions that made sense to connect terminals to multiple VAXs. And, you know, the Ungermann networks were a little bit more were a lot more expensive, so there was still a big price advantage in data PBXs, and you know, you still didn't have this acceptance that putting in this LAN was going to allow you in the future to put other kinds of devices on the network and allow that to interconnect. That was Ungermann and Bridge were selling terminal access, but still Ungermann was growing at a great rate, even in those days, and so was Bridge. So they were losing business there, and then DEC started, and that's when that business really in fact, even today, if you look today, it's down at almost 50% on a yearly basis where it was three years ago.
JLP: Now, this process of when Micom you were aware that Micom really needed you.
PS: Well, we felt that we my feeling was that we wanted to build a partnership here. The problem was that it wasn't executed that way. It was not a partnership, it was a in fact
JLP: Take over and we're going to run it.
PS: In fact what we did wrong, if I were to re-characterize how to do I mean, I've said this before publicly and I'll say it again, if you're acquiring a company for a product, then get the product and get rid of the people. If you're acquiring a company for a business, a running business with a bottom line, then make sure you keep the people, because those people are the ones that make the business go. What we should have done is we should have taken a board seat, we should have kept a major element of control and we should have ran that thing as a business and tried to do some joint things, and really leveraged off of Micom instead of becoming part of that. I think we could have done it that I think we could have kept growing the Interlan business and at the same time given them what they wanted, but Roger and Micom felt very strongly they had to control this thing to integrate it quickly, and they just didn't integrate it at all. I mean I wanted to build a 128 port terminal server with PBX technology with LAN back ends, cause I thought you could do connect, per connect that would be very, very
JLP: A lot cheaper. It would be outrageous.
PS: And I thought that was at least competitive, and that's exactly what's happening today when you look at what DEC's doing with DEC Server 500s and Xyplex has done with the Max Server 500. Try to get more ports. Go after the bigger networks, basically, and back end it with LANs and then add PCs. That was sort of the thing that I felt we should we do. And then, frankly, even the concept of LAN interconnects into the wide area was just starting to emerge, at least in my thoughts, and Micom could have been a pretty natural company for that.
JLP: There were four to five months you were at Micom
PS: Six months totally.
JLP: Did you become more away of wide area networking and the telephone line, if you will?
PS: Oh, absolutely. In fact, the problem I had was that, in all honesty, the guy who came in to Interlan just didn't want me around there, ok, so I spent most of my time with the guys in Simi Valley.
JLP: So the whole concept of why you're in networking and so on, some of the things that obviously caused you to realize: "Wait a minute, these local area networks are going to have to be connected with the wide area networks "
PS: Well, I didn't you know, that hadn't gelled totally for me when I was there. In fact, when I left, in September of 1985, I actually started working on a project to build a company that was going to be doing factory automation systems. I was going to go back to my Data Acquisition days, but I was going to do it with MAP.
PS: Cause that, at 1985, in the fall of 1985, MAP was starting to really get into a crescendo, and I said: "maybe finally there is a real opportunity in factory networking, finally."
JLP: Cause you had seen INI
PS: But I wasn't going to be a networking company. I wanted to be a computing company. I wanted to provide the workstation of the factory that was networked like an Apollo system. I wanted to do this real time cell they call it cell controllers real time cell controller, UNIX real time, with integrated MAP networking and literally using the MAP network as a mechanism by which you could have real time networked operation over the network. The problem that we found we looked at that for six months, there were about four of us. The problem we found? First of all, factory users don't buy from new companies. Secondly, there isn't an application in the factory that drives a network like there is in CAD, like there is in the engineering environment, like there is in just a distributed data processing environment. There isn't an application. The only application that we found that drove a network into GM was literally downloading programmable logic (unintelligible), numerical controllers with programs instead of ROMs. That was the only application that we found, and clearly that's not a fancy application, so we just made the decision, even though we had a plan and we had figured out what the products should be, we just said: "This is crazy. This is not going to be where you grow in the networking business," and in fact, I saw Ralph Ungermann at a Alex Brown conference in '86, and I said to Ralph I had seen him at the Autofax show in November of '85, and he says: "What are you doing here." I said: "Well, I'm looking at factories." He said: "You're not going to go be an industrial networking company are you?" I said: "No, no I'm looking at the computer side of the business," which I was. I saw him at the Alex Brown thing afterward in the spring, in March of '86, and I said: "Ralph " He said: "Did you start that company?" I said: "No, I didn't." He said: "Why not?" I said: "I can't find an application that's going to drive networks in a factory." He said: "No, it's there. We got it. We got all the OEMs lined up. It's all happening." I said: "Ralph, I'm telling you, I just can't put my finger on what's going to drive users to install networks in a factory. It isn't flexible manufacturing. It isn't this concept of time cards all over the factory. I don't see it."
JLP: And what was it in the engineering environment that drove it? What was the application?
PS: Oh, just the fact that you want to just have lots of engineers working on different working on different designs and just having being able to transfer those designs from one to the other and modifying it. Just fast movement of all this design data and the CAD world. Keeping things in a central file. It's like a drafting department, right? Somebody there's a central file server so it can be kept backed up and everything else and just things like that were just driving the need to do this. And also the fact that a lot of CAD systems were back ended with bigger computers, so you want to move it up there, get in it and move it back. And in the software environment, the engineering environment it was just, hey, file servers, diskless nodes, that kind of thing.
JLP: So at some level, again to come back to this issue, I had asked the question before in terms of the user, that environment was that the user the workstation becoming available, and CAD software becoming available, which was automation of drafting in the early days, caused there to be large data files, and the desire to push, to move these large data files around and have a central library of them was what said: "Wait a minute. We need to connect these things with some high speed interfaces."
PS: High speed LANs, right. But in the factory you couldn't find that anything that was driving it at all. So we just decided not to do it, and right after that, I said: "T1. T1."
JLP: When did you become aware of T1?
PS: I became aware of T1 when I was poking around for Micom looking at different kinds of companies. X25, T1, in fact, the first time I actually became aware of T1 was when I actually went down to visit Avanti.
JLP: When you were at Micom?
PS: And, you know, I'm a fast learner, as you can tell. I learned from Data Acquisition board to the Ethernet
JLP: To T1.
PS: Yeah, now to T1. But it became clear to me that T1 was important and that, if you believe the way I do, that LAN traffic is going to dominate what happens in computing and computers, computer systems are going to be connected with LANs from now on until I can see, LAN technology. As soon as you understand that then the next step is, ok the world still needs to be interconnected. Companies still have remote sites and they still want to get at the classical Datacom problem, therefore you need different kinds of devices than modems and multiplexers. You need routers and bridges. You need things that work differently, and if you mate those up with the technology of T1, you ought to be able to access a group of customers and have that problem and make a business out of it.
JLP: When did you start Wellfleet?
PS: June of '86.
JLP: June of '86? Did you take venture capital right away?
PS: Yeah, we did. We had to. This time we knew we had to raise a lot of money.
JLP: So this time you said: "I'm going to compete with wealth, well healed people."
PS: This time I said, the difference between the Wellfleet approach and the Interlan approach; Interlan approach was I had my eyes focused on a particular segment and I was not I didn't care whether I was the number one company or number two company, all I wanted to make was a profitable business. I wasn't shooting for being
JLP: King of the hill.
PS: Yeah, I wasn't.
JLP: But you are now.
PS: But now we are. Now we are, so we raised a lot more money, and we made a bigger you know, our product is going after a segment which we think is going to be a very important segment, and we're going after it with a product that's very fully functioned as we come out the door.
JLP: And you introduced your product in the end of '87?
PS: Yeah, and we're in sites. We're in a bunch of sites right now; some Beta, some evaluation as we call them, and we're shipping well hopefully we'll be shipping by the end of this month.
JLP: Good for you. Let me get back for a moment to Micom. When you said that during that period of time a number of companies approached you, other data com companies?
JLP: Would you care to other modem kind of companies?
PS: Well, see I don't know whether I should talk about who they were because that sort of gives away maybe some of there it was sort of confidential in those times.
JLP: Yeah, but
PS: They were other datacom companies and other kinds of companies.
JLP: The other kinds of companies I'm the most interested in, but some of the other modem guys? I mean, those kinds of datacom companies?
PS: Well, let me think. No, it wasn't a modem company. There wasn't a Codex among them, for example. or a Racal. It wasn't any of them.
JLP: Why do you think that those companies didn't participate in LANs, weren't in the LAN business?
PS: I don't think they understood it. LANs were developed by the computer people: they weren't developed by datacom people. They were developed at Xerox PARC. They were developed by Prime, by IBM, by DEC. They just were not developed they weren't and they were developed initially to be a local computer interconnect
PS: and these guys were doing remote interconnects, so why get involved in a business the only one that really was in the local business, or not the only one but there were other ones that were in the dataPBX business were people that were in the dataPBX business, and Micom led the pack in that, so they saw the LAN problem
PS: before anybody else did, and Codex saw the fact that they wanted to Codex decided that they wanted to be in the LAN business, and they went, they literally spent $20 million and got absolutely no return from it. They had a strategy and they went out and they hired all these people, Murray Bolt ran it pretty much, and they OEM’ed from Ungermann and every time they had a big deal Ungermann and competed against them. I mean it was just crazy, and I can tell you, after knowing Dick Kendrick now for a while, Dick Kendrick sold he didn't sell to LAN he didn't sell to people on the local, inside the company, he sold to the datacom manager. Datacom managers were not necessarily installing LANs in those days. Department managers were doing LAN installations.
JLP: From the perspective, from a historical perspective, do you think that they conceptualized their business wrong? Too narrowly?
JLP: These traditional datacom suppliers? I mean, clearly
PS: Well, you know, I think the one that they really missed on was not so much the LAN business. I think the one they really missed on was the T1 business, cause that was right in their marketplace.
JLP: Why did they miss T1?
PS: They didn't understand it. I mean, they were dealing with modems and they were dealing with analog leased lines, and
JLP: Most of them had statistical multiplexers.
PS: Some of them did. Well, Codex did. I think Codex
JLP: The one that didn't miss it was Timeplex.
PS: Timeplex led it. Well GDC led it, I guess, but Timeplex really cleaned up on it, right. Codex, and I'm not sure about this, and you can talk to Codex people, my sense was Codex understood it, they just couldn't figure out how to develop the product. They have a hard time developing product inside Codex, new products.
JLP: Many big companies do.
PS: Micom, Micom should have seen the PC side of the business, the PC networking side because that's the lower end and they should have seen that. They should have been able to say: "That's the new low end," and had they been able to do that they would have been a real win.
JLP: Yes. Quite honestly, they didn't see the PC though.
PS: No, they didn't see it at all. They didn't see it AT ALL. It totally went by them.
JLP: Roger's view, by the way, just for is that his distribution channel was a bunch of fat cats, and they had made so much money and they were so happy that and he, as he says, when he went out and talked to them, it was like they partied. It was like a celebration as opposed to the channel of distribution he established didn't give him feedback saying: "Wait a minute. This is what's next," because they had made more money that they ever thought they were going to make in their life, and they just, I mean, they lost touch.
PS: Well, that's the problem. That's the thing that I think maybe one of the reasons why Roger wanted me to do the strategic thing, be only involved in strategic, was that he thought that maybe if he had done that early on he might have seen the PC coming.
JLP: He feels strongly he takes heavy responsibility for that.
PS: For missing the PC?
PS: Well, that was clearly a missed opportunity.
JLP: And the T1. They, his view was that
PS: Well T1 is a higher end
JLP: Yeah, it was high end. He wasn't high end, and no one expected tariffs to drop the way they did.
JLP: I mean tariffs just fell through the floor.
PS: Now, T1, I can see that Micom wouldn't have seen T1. Even if they saw it they wouldn't have been able to do anything about it because they didn't have any products that were that high end at all. None.
JLP: Right, but Codex missing it was a sin.
PS: Codex missing it was a real problem, and you know some of the others; Racal, Paradigm.
JLP: Yeah, those guys missing it (unintelligible). Paradigm lost it when they got into legal problems.
PS: Yeah, I don't know. I'm trying to think about I always, as you've been trying to focus on the issues of how this business grows and why things happen and, if you look at DEC, DEC is a very interesting company to model yourself and look at. Somehow or another DEC has maintained a tremendous amount of product capability in that company, and they've done the right things for a long time, which is why they're where they are. You know, I'm not sure you know, they were not necessarily they were first in minicomputers. They weren't first in 16 bit minicomputers, Data General was. And then there were a bunch of other companies, and then they came in and did it with the PDP/11 and they did it well, but Data General also did well in that time frame, and there were a lot of other 16 bit minicomputers sold, like Honeywell and Modcomp and General Automation and a bunch, InterData, a whole bunch. And they weren't first on 32 bit minicomputers and virtual memory. That was Prime, although there was a 32 bit InterData machine.
JLP: But they were a bigger company than Prime. I mean they were significantly larger at this point.
PS: Yeah, but you know, they were a year and a half or so, maybe two years behind Prime in the introduction of the VAX. Now when it hit, it really hurt Prime a lot, but Prime's a billion dollar was a billion dollars almost on its own.
JLP: I would argue the point that other than having a consistent operating system and the connectivity, I mean DEC had missed the PC, and not to be a player in the PC marketplace, given their strategy, is a major faux pas. I mean that's their not being a major PC supplies and participant is as bad as any of the things we've talked about the data companies. Wouldn't you agree?
PS: Well, I would agree, except for the fact that how much performance can a company provide? I mean, that company is just
JLP: Oh, I agree, but in terms of your saying, to model yourself after
PS: I mean it just goes to show you that it's almost impossible you really. It's very difficult when things are changing to move an organization to go after something. You really have to have very strong people inside to do that, and you have to have people willing to take risks. And as companies get bigger, it's much more difficult to do that.
JLP: Over dinner we can talk about this, cause I have some strong views about why and how that happens.
PS: Yeah, I'd like to talk about it, cause I think it's important.
JLP: I agree, and that's a subject the subject of this book is about that issue.
PS: But you know for me, one of the things that happened with me is I've sort of I've never worked for a datacom company, except Interlan, which is one I started, and for a short time Micom, I've worked for computer companies and data acquisition companies. So I've sort of had a wide, sort of wide line view of things. I think datacom is still, I think it's a great area, and I in starting Wellfleet, I guess I've sort of said this is where I want to be, so I expect that I'll be in the datacom business for a while, and I think there's still a lot of opportunity in it.
JLP: I agree. Intellectual property, you shared with me a little bit of your own, of how these ideas developed, and you also went about and recruited people who had specific knowledge and expertise in these areas. Were those people like yourself? They had backgrounds that took them through Xerox PARC’s or through other environments where they came in contact with some of the big research areas or development areas that were going on in other companies?
PS: Well, not so much other companies. We had people that had done work well, I'll give you an example, if you look at the people that are in Wellfleet today, the engineering people, we have people that are out of BBN, we have people that are out of AT&T, we have people that are out of the computer companies that are doing LANs, that kind of thing. Just a wide, sort of a wide spectrum of people with different kinds of expertise. We're a it turns it there's probably more networking expertise in the west than there is in the east. BBN is good, but it's a little bit fragmented now. A little bit fragmented. On the west, Berkeley has been excellent, I mean Berkeley has been really good, some of the universities, but it's hard to get people out of the universities and into companies. They really love what they're doing. They like it a lot, what they're doing.
JLP: Well, actually, it's good that they stay, too.
PS: Yeah, but, you know, DEC has been a a lot of networking going on at DEC, and it's very difficult for people to leave DEC right now. They love it there. They're financially tied in, but we developed a lot of our own people. We developed a lot of expertise in Interlan, for example. People that never new anything about protocols came in and did protocols.
JLP: Let me ask you one last question before we have dinner, email. When did you become aware of email.
PS: Probably, well, we were always pretty small, so we never really had a big email system going on. I think that was there are some people who thought that email would drive LANs. I never thought that.
PS: I just I thought people put LANs I didn't think that people would spend that much money on a LAN just to get the ability to send mail over a wire inside a facility. I just thought that they would I thought they were putting in that much money to get high speed movement of data around, high speed. Get the work done, and email was sort of an extra added feature. That's the way I viewed it.
JLP: Did email ever become important in
PS: No, not in our no, we never had anything to do with it. We never supported any mail or anything else. We just weren't part of that.
JLP: Do you use email in Wellfleet?
PS: Yeah, we use it on the Suns.
JLP: Do you use it?
PS: No I don't use it. I don't have a Sun. I have a Macintosh, and by the way, Macintosh networking is pretty basic yet. I don't even think there is an email package for Macintosh is there?
JLP: Yeah, there is.
PS: Yeah, well, we don't. I don't Anyway, we're so small, but the engineers do it. They leave messages on their own mail systems all the time.
JLP: Going back to one other question, did you ever see Sytek?
PS: No, never saw Sytek.
JLP: You never saw Nestar or Corvus? They were completely different.
PS: No, never saw Nestar or Corvus.
JLP: Ok, good. I greatly appreciate your time.
Entrepreneurial Capitalism & Innovation:
A History of Computer Communications
1968 - 1988
By James Pelkey
An overview of the book schema is presented in the Introduction. It is organized by these three dominant
co-evolving market sectors and standards making.
One can explore any market sectors from vision to adaptation - below.