A HISTORY OF COMPUTER COMMUNICATIONS: 1968 -1988
An Interview with
Conducted by James Pelkey
June 17, 1988 - Campbell, CA
In the late 1970’s, Kaufmann led the strategy/planning functions of Intel reporting directly to Andy Grove. With a background in communications theory, Kaufman naturally envisioned a future with communication products consuming silicon. Learning that Digital Equipment Corporation (DEC) was talking with Xerox about Xerox’s Ethernet technology, Kaufman called Gordon Bell of DEC, who he knew from IEEE standards making. Bell connected him with David Liddle of Xerox. With early assist from Bob Metcalfe, Liddle, Bell and Kaufman led the creation of the consortium of DIX (Digital Equipment Corporation – Intel – Xerox) and the beginnings of Ethernet becoming an IEEE standard. In mid-1982, Kaufman left Intel to become President of Silicon Compilers that in partnership with Seeq and 3Com had just produced the first Ethernet semiconductor chip.
JLP: My understand is that you were the critical person at Intel, but the process of how Intel got involved -- I have multiple stories. One story is that someone from Intel went to NBS and said: "We have this unique 25 megahertz technology," and Bob Metcalfe followed up and walked in to Intel to make a presentation to a group of people, and you greeted him. Another story -- Gordon's view -- is that DEC contacted Intel and proactively said: "You ought to get involved in this project." Maybe you could help me first by telling me how Intel ever got involved in this in the first place.
PK: It's certainly mushy, and it probably happened in multiple of those ways. Let me tell you, from my perspective, what was going on. At the time, I was working as staff to Andy Grove, looking at strategies and directions for the company: where we ought to go. It happens that my background is communications. I came out of school in '64 with a background in communications theory and signal processing at the University of Michigan; where I had done things like writing simulations of multiplexed telecommunications systems for the telephone company type applications. I hadn't done much of that, but I had a good background in communications. I had also been heavily involved in pushing forward on the IEEE floating point standard. The essence of that was: "Let's find places that consume silicon," and nothing consumed silicon, at the time, more than computation, and the idea of doing a floating point standard was ripe. It was clear that the only way to make floating-point work was to have a standard, because everybody was doing it differently, and if you wanted to sell a lot of the same chip, you had to have a standard. The same kind of thought came into play in communications. Clearly, communications was going to be more pervasive than it had been. The PCs were taking off, and local area networks of some kind were going to be pervasive. So, a lot of different people were searching for 'what should we do in local area networks to make local area network controllers?'
JLP: Now, what time frame would this have been? This must have been '78.
PK: Yeah, that sounds about right. It was -- Liddle was at Xerox and Gordon was at DEC, and -- '78, '79 sounds about right. I have a very poor memory for dates, so you'll have to check it against reality.
JLP: My understanding is that Gordon first wrote a letter to Xerox in February of '79 --
PK: That's about right.
JLP: -- and the Blue Book came out in September of '80. The announcement was in the spring of '80.
PK: Gordon's involvement between DEC and Xerox predated my involvement. As I was looking around at communications and some of the people in the peripherals group were looking around at what chip we should build, the issue, obviously, came down to what protocols should be used. Now, the one protocol that had actually been used somewhere was Ethernet, as done at PARC. Everything else was something else -- everybody was inventing on the fly. We took a good look at Ethernet and all the papers that had been written and said: "It doesn't matter whether it's good or not, it exists and it works. Let's see if we can take off from there." Now, somehow, and I don't remember how, at the time, I had heard that there was the beginning of a discussion between Xerox and DEC, that DEC was interested in Ethernet, and that Xerox might be interested in somehow making Ethernet a non- proprietary network, because if Xerox had patents on Ethernet, if they were going to hang onto it, then we were all going to turn some other direction. So, I contacted Gordon and found out who Dave was and contacted him, found out what was going on, and we started a whole bunch of informal discussions. The essence coming out of Xerox was: "Yes, it was probably, but not certain, that they'd basically release it into the public domain." So we concocted this idea, based on what had gone on with standards before, that the only way to make a viable standard is companies making standards, not standards committees making standards. So, if we could get multiple companies together and all endorse the same standard, then we could present it to the IEEE and say: "Endorse it or not. This is the way we're going." So we started a series of meetings between DEC, Xerox and Intel to try to put this together for a combination of both very selfish reasons and very altruistic reasons. We started out from scratch and said: "We're going to put this in the public domain. We will win if there is a standard." Obviously, we're building parts at the same time.
JLP: That concept, did that precede -- Bob Metcalfe's view is that there were legal issues that existed about any of the three of you getting together, and the only way to get around the legal issues was if you, in fact, agreed that you were in a standards- making process and you were going to put this in the public domain, and therefore, the three of you could meet.
PK: Well, my view was that to do it and make people accept it, and for it to be worth working on at all, from Intel's perspective, we had to be shooting to put it in the public domain, and I think we all were. Now, even though we were shooting to put it in the public domain, in this country, there has been, although it's eased off a little bit, all this horrid antitrust stuff. What our attorneys essentially told us was that we could not write a three-way agreement to work on the project to develop the technical specification even though we were explicitly going to put it in the public domain, and that we could not have tri-lateral meetings if there were any marketing people present from any company. What we ended up evolving to was putting together a technical team from all three companies and trying to divi-up the work, working towards the specification, because although Xerox had had a running Ethernet, it clearly wasn't as complete and well specified as we wanted to make, and up to the final state of the art that we wanted to release. So, we ended up writing an agreement between DEC and Xerox, and a second agreement between Intel and Xerox, each of which referenced the other one, but there was no one agreement with three parties to it. To me, it was all absolute nonsense, but as always, you will succeed what you want to achieve and ask them how, rather than ask them: "What can be achieve?" So, we set up these technical committees to work on various aspects of the agreement from what should the cable be to what were the details of the specification, with the explicit goal to write the standard and deliver it to the IEEE. The result of that was, with much agony, the Blue Book, which, as I recall, was printed by Intel on my budget, some 25,000 copies, and passed out to the world. What we tried to say was: "Here it is. We've signed up for it. We're going to make this work, and if you want to put a standards stamp on it, that's fine." Of course, we didn't really take into account the fact that there were lots of other people in the world with other axes to grind that would try to perturb the standard, and in hindsight, maybe we should have just held it quiet for another couple of years until we were delivering, but we took it to the IEEE and a lot of people spent a lot of money. In parallel with that, we tried to get other companies to buy in.
JLP: Prior to the Blue Book being released?
PK: Prior to the Blue Book being released. In particular, the guy at Hewlett Packard who had the job that was parallel to mine, this strategy/planning, was Dave Crocket. You may know Dave, who subsequently went to Dataquest. Dave and I used to get together every couple of months for lunch, because we had similar jobs and bemoaned the process of trying to make strategy. Dave was also looking at networking and thought that networking was very important to Hewlett Packard, and within HP, there were multiple standards developing. So, the strategy he developed there was that the only way to get all of Hewlett Packard to salute one thing was for it to be an external thing, because all of Hewlett Packard would never salute one group's. He did a lot of work to push HP in the direction of Ethernet, and we worked, trying to influence a lot of other companies, because for us, the whole goal was, besides some altruistic one about making communications work and advancing the state of the art, is we wanted to build customers who were ready for the chips we were going to build. So we released the specification, continued to develop it. During that time, we had a development team going in Israel building a part, and we spec'd it as the Blue Book. We put it into the IEEE process, and of course everybody came out of the woodwork with their own axe to grind, particularly IBM, whose axe to grind was 'there shall not be a standard unless IBM has been shipping it for at least five years.' IBM, in its inimitable fashion, came to the standards body not as IBM but as multiple groups of individuals, because of the fiction of the IEEE, that it doesn't represent companies, it represents individuals, each of whom had a different idea and a totally different approach and none of whom spoke for IBM. Of course, that's where all the big push for Token Ring came from. So as we were going along through all this process, we started saying we weren't building an Ethernet chip, we were building an 'EitherNet' chip, and it would be whatever net came out when the world finished moving around, and if the world didn't finish moving around, we'd just ship what we had. The interesting coincidence of it was that that kept going on, I left Intel the middle of '82. The standards process was still chugging along. The chip development was still chugging along, and I came to Silicon Compilers. Now it turned out that, unbeknownst to me or anybody else, Silicon Compilers had been developing their design tools and wanted to build a part to prove the design tools were good. Ed Chang had picked to build an Ethernet controller to show that he could build one. Ed and his guys had built an Ethernet controller to the current standard as published before I got here, and it had just come out in working silicon when I got here, so I ended up coming here having the world's first Ethernet controller despite the fact that I started it at Intel two and a half or three years prior to that, and Intel was still working on the chip. So the first Ethernet controller to ship commercially was the one designed here, which was licensed to Seeq, not only as the foundry but as a commercial source.
JLP: There were four sources then. There was the Seek, there was the Intel, there was the AMD, and there was a Japanese one.
PK: Right, there was the Japanese one. Now, the further interesting complication was that while Intel was building its part and cooperating with DEC and Xerox on the specification and everything was going along well, DEC needed an Ethernet controller. DEC knew what Intel was doing and had some fears about what Intel was doing, that Intel would control the market and maybe it wouldn't be quite right for their machine, and DEC, almost unbeknownst to Intel, went out with their own specification, and it was split between AMD and somebody else -- Mostek maybe -- to build a multi-chip set specifically for DEC to interface to DEC buses. So those were all going, but Silicon Compilers was the first one that built a chip that went out on the market that worked and shipped.
JLP: Seeq is really been a non-factor in the market, right? PK: Well, they shipped an awful lot of them. For a long time, it was certainly the highest volume communications controller on the market, because it was a year and a half before anybody else actually shipped one.
JLP: When did Intel start shipping?
PK: I would have to guess that they actually started shipping it about the end of '83.
JLP: It was '84 before the (unintelligible) AMD chip came out, I think.
PK: And the AMD chip was probably six or eight months behind that. So, as that happened, those chips took over, because part of what let Silicon Compilers build the chip first is, rather than be grandiose, aggressive, about all the stuff that was going to go on the chip, we didn't put much on it.
JLP: Right. It was a minimal function, but it did --
PK: But it did the job and it met the specs, so as the more highly integrated parts came out a couple of years later -- but it was probably three years before the Intel chips and the others that came out on the market overtook in volume. It was probably at least three years.
JLP: Now, going back, just in trying to be accurate, do you recall Bob Metcalfe coming to Intel and giving a lecture?
PK: I don't recall specifically, but I'm sure he did, because he was out promoting Ethernet.
JLP: Right. Did he play much of a role in getting DEC and Xerox and Intel to work together?
PK: He may have played a role with DEC. He and I had spent a lot of time together, talking about Ethernet and where it was going and stuff, so he certainly had influence there.
JLP: Was this pre '79, when you were thinking about what to do in networking?
PK: This was all right around the same time.
JLP: He was never a consultant to you, though?
PK: Not that I recall. He may have been a consultant in the peripherals division that I didn't know.
JLP: But this momentum internally at Intel was there. There was a recognition that --
PK: There was a momentum towards communications as a site, and the momentum to really do Ethernet came from the idea that we really could put multiple companies together and make a standard.
JLP: That came in the spring of '79?
PK: Sounds about right.
JLP: Because you had heard, from wherever you heard, that Xerox and DEC might cooperate. You placed a call to Gordon Bell, saying that you'd be interested in that process --
PK: Right, because I was going to get DEC -- get Gordon sooner or later, because I hadn't gotten him to change the VAX to the IEEE standard floating point. Close, but no cigar.
JLP: So you contacted Gordon. No, do you ever remember a -- you described to me this morning as a picturephone meeting between Intel and DEC?
PK: I do remember a picturephone meeting between myself and Gordon, because there was an earthquake in the middle of that picturephone meeting.
JLP: Gordon's perspective is that the two of you just couldn't get together. DEC really wanted this to get done, and he was frustrated at the pace at which it was getting done, and you finally just resorted to a picturephone.
PK: I remember a picturephone meeting with Gordon, between Intel and DEC, and I remember it because we were in AT&T, or Bell, offices in San Francisco, sitting at one of these conference tables, and Gordon was there, and there was an earthquake at the time, and we dove under the table. All the telephones in the building went out, and the elevators were banging against the shaft, but the picturephone kept working because it was a dish. My recollection was that that meeting was an IEEE floating point meeting that would have been some time before that, but I could be totally confused, because what I remember about the meeting was that it was Gordon and I and there was an earthquake.
JLP: So when you got involved in it, your intention was to be standard?
JLP: Because that was critical to --
PK: It was critical to Intel, to sell parts.
JLP: Where did the idea of the LAN -- what Xerox was doing -- PCs, all there was was the Apple at this point in time?
PK: There was Apple and --
JLP: Osborne I guess maybe --
PK: -- and Osborne, and there were minicomputers.
JLP: There were certainly minis, but LANs weren't -- there were some experiments. Data General had a LAN, and Prime had a LAN.
PK: Right, and Datapoint was working on one. Generally, the consensus was that communications between computers, locally, was important, that the technology would let us do quite high speeds. That's where the pressure -- there was a lot of debate about whether or not Ethernet should come out at two or three megahertz, or at ten, because the PARC ones were running at one or two or three.
PK: It came down to: "If we're going to write a standard, we ought to push the standard forward, because we can build chips that will do that."
JLP: That must have been Intel's perspective of 'let's go to ten.'
JLP: Which some people held that, by pushing the envelope that much, you pushed the cost up, which really hurt it in the early years. Do you share that view?
PK: I don't think so. The issues really were cabling and controller chips. There was no problem in making the chips run at 10, and there were lots of issues about cabling, and I think what pushed up the cost mostly, in the early years, was Xerox and DEC's insistence of having coax, because they were most interested in all the very real problems of installing this stuff and making it work and making it reliable, whereas the rest of us were much more hackers. We were willing to pull anything if it would work.
JLP: So the transceivers were the hairy part --
PK: The transceiver part was the hairy part.
JLP: That's what Mostek (unintelligible).
PK: The transceiver stuff and -- there was all debates about 'could anybody build a transceiver that would really work at any speed reliably,' despite the existence proof of what had been running at PARC. This was a black art by one guy in a closet, about how to build transceivers, and a lot of the time developing the Blue Book was a lot of theoretical work by people on 'what should a transceiver do and could it work?' That's where all these specs about how far apart transceivers could be and things like that, from all the analysis of what was going on in the coax. Of course, nowadays people are running it on twisted pair, and that's where we would have liked it in the first place. The goal that I had inside Intel was to, over a couple of years, make the delivered cost to the consumer of a ten megahertz Ethernet controller and transceiver match the cost of a 300 baud modem, which at the time was 150 or 200 bucks. There isn't any reason why we shouldn't be there today, but basically that was the goal; use the technology to bring the communications into the same price range.
JLP: So you contacted Gordon, and then --
PK: So I contacted Gordon and it's likely that, at the same time, Bob had been talking to some of the technical people, because we had been researching what were the right protocols that could be used, and what were the alternatives. So I got in touch with Bob and with Dave Liddle, who was running the activities there.
JLP: So you contacted Dave (unintelligible) -- Gordon point you to Dave?
PK: Somewhere; I either got Dave's name from Gordon or from Bob, because I hadn't known Dave before, and from that point on, and because someplace right around then, Bob left Xerox. Do you remember what the date was?
JLP: He left in '78.
PK: Because he had either just left or was just --
JLP: In '78. He did consulting at MIT, for the first five months of '79, and then he formed 3Com.
PK: Right, because I remember the time when he formed 3Com and I couldn't for the life of me figure out how he was going to make any money at it. He didn't know what he was going to do, except something in networking, and at the time, there was no market to build add-in boards for PCs in any volume, and mostly he was just doing consulting. So it was Dave and I that got together regularly, because we were local, to push this and make sure that things kept happening. It was Dave that fought all the battles inside Xerox to get their business and legal agreement to license their patents for $1,000 a company, or something, because if we couldn't cross that hurdle, we had to scrap the whole things and invent a new protocol.
JLP: Right, so you and Dave met frequently; frequently being weekly, bi-weekly?
PK: Gosh, any place from weekly to monthly through a fairly long period of time.
JLP: Was it difficult for you to marshal support within Intel for this project?
PK: No, not really. We had an ongoing commitment to build some kind of communications controller, and the issue within Intel was 'what should it have on it, what protocol, and how aggressive should it be with all the other stuff that was on it like memory management and things like that?' We drove to make it a tremendously complex chip that did a lot of work, because that was Intel's advantage. If we could set the high-water mark that everybody else had to come up to to have a viable controller, there'd be something that we did best, we'd take advantage of our ability. So, that first chip really was a whole computer. It managed all the data queues in and out of memory, and it was very complex.
JLP: Intel wasn't doing anything in modems at this point?
PK: No modems.
JLP: Why not?
PK: Because Intel wasn't big in analog and modems.
JLP: So you were looking for something that would be digital communications.
JLP: There weren't a lot of options at that point.
PK: There weren't a lot of options, and interestingly, one of the attractive things about the Ethernet technology in that vein is that the transceiver is a separate animal, and in the original implementation, virtually always mounted elsewhere.
JLP: You needed a transceiver, then, for that project.
PK: Well, we tried to get multiple people to go into the transceiver business. For a while, DEC was going to build transceivers. They were in the building business and they were going to sell them to everybody, and we were going to try to get a couple of other people out. DEC fell on their sword trying to build transceivers, and for a long time, transceivers were only available from a couple of garage shops, which was a real impediment.
JLP: How did it finally get resolved?
PK: I guess gradually the art spread, and more people could build it. DEC finally started building them, mostly for internal use. I don't think they sold many to the outside market, and then 3Com took over and started building them. We scrambled for a long time even to get enough transceivers to test all this stuff, to test all the software.
JLP: Were you involved in much in the standards committee work?
PK: Well, I didn't go to most of the standards committee meetings, because they very quickly got down into real heavy technical arguments, and we had a group of people that just kept going, and we could see that that was going to be an infinite argument that was going to go nowhere.
JLP: The first point -- I don't have my dates with me, but the 802 Committee existed, but it dealt with the physical and the data and everything else. They were trying to get for one standard.
PK: Everybody was trying to go for one standard.
JLP: And then there was one vote at one meeting in which you needed a two-thirds vote, and over 50% voted for Token Ring, but they couldn't get the two-thirds, and then they decided that they would make multiple standards, and they converted from these three types to the 802.2, .3, .4, and .5.
PK: Well, you get on my hot button about IEEE standards, because I think they're absolutely absurd and they do a great disservice to the industry.
JLP: Would you say the same thing about standards in general?
PK: No, I think standards are wonderful, but I think the absurdity of the IEEE is this idea that it represents individuals and not companies in standards. Individuals don't make standards, because individuals don't build products, and individuals don't buy products. Yes, they needed a two-thirds vote, but who could vote was whoever came to some series of recent meetings, so if you had a real axe to grind, as IBM did, you simple sent lots of people to a few meetings in anticipation of when the vote was going to be.
JLP: Right. I agree. So that process you were aware of, but other people in the organization, more technical people --
PK: Yeah, we had other people in the organization that were sitting in on it, and our strategy fundamentally was 'they're not going to kill Ethernet, and if IEEE kills Ethernet, we don't care because there's nothing else there at this point.' IBM was talking about Token Ring, but had no spec, and if they did have a spec, they wouldn't release it, and the people they sent clearly didn't speak for IBM and kept saying they wouldn't speak for IBM. So what the IEEE was talking about in terms of Token was a non sequitur to us. We were going to ship CSMACD no matter what, and we were going to follow the IEEE, and if they settled on something, we'd ship it that way. If they didn't settle on something by the time the chip was ready, we'd ship the chip, and that's why we were calling it the 'EitherNet' chip, because of all the variations that were coming along in CSMACD, not because we were going to make a Token Ring part of it. Nobody knew how to make one of those.
JLP: Right, and whatever was in the Blue Book, that's the chip that you --
PK: So we started building the Blue Book, and as we saw what was being brought forward to the IEEE, and there were a lot of good consultants with good ideas on polishing CSMACD, as we saw those things, we said: "Make the chip flexible, so that whatever way some of these details land, we can handle it." There was great argument over how many bits the address word should be, or what kind of CRC should be used. I said: "We don't care until almost the last minute on the chip how to do it, and if we have to make it programmable, we'll make it programmable." So then the IEEE ended up splitting it up into all kinds of different variations, so we have multiple non-standards.
JLP: Now, I think that helps clarify my perspective of -- the primary motivating force was your strategy requirements. DEC had similar strategy requirements, and Xerox, at some level, was an unwilling bride --
Tape Side Ends
PK: I think Xerox still had a goal of being a power in office automation, and thinking that their knowledge and capabilities in networking would help them, because, after all, they had all this experience on Alto networks and Ethernet that should have brought them out into leadership. As one of the stories -- I had an analyst tell me that, at the time we announced the Blue Book publicly, Xerox stock went up, because it was the first instance of something useful and potentially profit making coming out of PARC.
JLP: Incredible. When I started this project, I had this view that semiconductor technology was an important issue. Now, there was semiconductor technology that was critical, ie memory and processors and microprocessors and so on. The data communications industry used them, but it wasn't -- the motivating force wasn't data communications industry. Originally, there was the operational amplifier in the '60s, which caused the modems to be able to get down in cost and open the modem market up if you will. There's the UART, which was a chip that was clearly a data communications chip. Then you come almost to these LAN controller chips. The semiconductor industry has always -- after there's a systems design, has maybe reduced it, but there hasn't really been a driving force, as there was in the case of this Ethernet controller chip, to really try to make a market by going out there and investing and --
PK: We were really trying to make a market. We were trying to do, from Intel's perspective, we were trying to do the same thing we had done with floating point. We were deliberately looking for 'what's going to consume silicon?'
JLP: But do you agree with the statement that semiconductors -- can you think of other examples where semiconductors played a role in data communication?
PK: Well, I haven't thought about it in that way. I think the UART was significant, but I don't know if you really want to say that was the semiconductor technology pushing it more so than -- if you say it wasn't semiconductors because it was just integrating what was already there before, then really the LAN controllers were really the first one, besides Codex, that really something didn't exist at all until the semiconductor technology allowed it to exist, because the types of controllers that were being used for high-speed LANs were, before we could put it all on a chip, were just going nowhere because they were clearly going to be too expensive forever.
JLP: Maybe the SDL stuff?
PK: Well, I don't know.
JLP: I'm ignoring, basically, IBM.
PK: Well, that's a good thing to do.
JLP: They didn't really innovate at all.
PK: Yeah. We looked at doing -- we looked seriously at doing a local area network with SDLC protocols, and it was the physical level and the electrical levels that were more important, because there was no premise there for what it should be.
JLP: One other general kind of question. I hold a view that the research process in the United States is in great disarray. With ARPA becoming DARPA, and Bell Labs post-divestiture, NSF funding individual professors at universities, but the needs of today of systems projects where you cross disciplines and there are many people and they are big projects, and if we don't start investing in research in a different way, in terms of these information technologies, we're living today off stuff that was done in the '60s and early '70s, for the most part.
PK: Oh, I agree completely.
JLP: And where are we making the investments today that we're going to see, in 20 years time, that's what's become (unintelligible)?
PK: I think there's a vast hole to do the kinds of systems, if you will, research that the Bell Labs -- Bell Labs, Xerox PARC, Sarnoff Research, those don't exist in the same form today, even if they exist. The companies that are still doing it are doing much less of it, and much more short term product-oriented. At the same time, as you say, the government funding is going into one-off kind of things, and mostly researching the past. A lot of the universities are turning from real research to product development. I consider that, for example, that Berkeley's done a lot of wonderful stuff in CAD, but they haven't done research. They've done product development. They've been a low-cost employee product development team. That's very nice, but it isn't research, and it isn't really advancing the state of the art, but it's where they can get funding. Companies will fund them because it's short term.
JLP: I think it's a real issue for us as a society. I'm going to address it in this book.
PK: I'll tell you a related issue that you may want to think about, which is one I've been giving a lot of thought to, and that is 'how do companies do research and product development?' In the US, venture capital drives the disassociation of companies, and new start-up companies and small companies, and the nature of a start-up company is you have to do everything, but you have to build your product from scratch too. Fifty or 75% of what you put into R&D is building stuff that isn't innovative and isn't part of the essence of the technology you deliver, and has no secondary use because you're a small company and you don't have any other place to put it. Big companies, where they have some cross-fertilization potential, at least in the US, are notoriously bad at doing it, and I can't say that I know how to do it. I spent a lot of time at Intel trying to drive synergy, and I'm convinced that's the wrong thing to do, that big companies should be holding companies and at most they should drive communications, but the ones that are doing it best are the vertically integrated Japanese companies, not the American companies, of reusing things, and the relatively larger companies. If Mentor develops a schematic editor, they can use it across a very broad products line. If we develop a schematic editor, we use it across 500 customers. One of the things that I've been trying to come up with is a way for multiple small companies to share technology, not just technology but real products that are developed, that aren't in their mainstream.
JLP: Right. I agree.
PK: And nobody's come up with a way to do that, but I've been trying to work on some things like that, and other efforts --
JLP: Actually, you should get together with Gordon, because Gordon just gave a speech last week that he was telling me about, where he was saying that he wants companies to break up their engineering efforts. He thinks you only need one fifth the number of engineers doing engineering. In fact, a lot of engineers are doing enabling things, such as testers and so on. Those should be shared across companies.
JLP: So it's the same vein. He's going to try to write an article for Spectrum on this issue.
PK: Well, I've got a paper that I've written and circulated to a number of companies that I call a Technology (unintelligible), on how to try to do things like that. It was dastardly hard to do, because you've got NIH and management issues.
JLP: One of the issues I address because I'm addressing technology industries is that we, in this country, going to your point, have been very good at building small companies. We haven't been all that good at building big companies. If the trend of today continues, we need more big companies in order to be able to compete on this global basis with the pan-European and the Japanese companies, and we're not doing that. Is that important or not important?
PK: I think it depends on what you mean. Now, maybe my perspective is biased, being in a $30 million company, but I think we need more $300 million companies, not more $3 billion companies, because I don't think anybody in the world knows how to manage one of those.
JLP: I think you're right, and I think -- my premise is that the $3 billion companies are going to be broken up into these $300 million companies, and, as you say, they're going to be holding companies, because of the natural affinities of the market, but I don't really have any --
PK: You know, the other research type activities, like NCC, are just horrible holy disasters, because they are chartered to fail.
JLP: In the sense of?
PK: Well, in the sense that they are not chartered to build product, and they are not chartered to do real 'go for twenty years and do fundamental research.' They are chartered to dabble, and nobody in any of the funding companies is absolutely committed to using what they've got, and they have no hard- driving goals as a result. So they're chartered to fail. They have to fail.
JLP: Thank you very much for 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.