The information superhighway folks thought they were playing nice with each other, and believed that because of their standards effort that they couldn't lose.  The information superhighway crowd was dominated by DOW 30 corporations, which included the telephone companies and the big computer companies.  As a result, they figured that this was their time to rule.  In playing nice with each other, they even managed to get a bunch of politicians in government and the Defense Department to participate.  But, deep inside almost all of their companies were small groups of engineers who were working for the other side: the Internet.

​

The superhighway folks came up with something they called The Open Group (TOG).  Politically, it was seen as a peacemaking effort to develop some standards because of the horrific fragmentation of the world of UNIX that had occurred.  In 1990, no two UNIX systems could run the same software.  At TOG they got together and started writing standards. This didn't go well at first, so they stopped and came up with a set of principles which became TOGAF (The Open Group Architectural Framework).  By linking themselves with the International Standards Organization (ISO) they figured they were on the right track.  But, as I said in the introduction, they made two horrific mistakes.

​

Mistake number one was their target business model.  They decided that the world of networked computers would work exactly like the telephone network did for voice, circa 1922 (that's the year the very first automated switch went into service).  I wish I was making this up, but I couldn't. 

 

They figured that teach individual application service would be provided by a service provider, with the carriers being the providers of things like email and full duplex (two way) video.  Subscribers would pay a basic change to have each service, and a metered charge for how much they used it above a certain amount.  They totally failed to understand the implications of the revolutions that were taking place in the electronics and optics industries.  They really thought that some base rate for email such as $5 per month per address, plus a few dollars for each dozen kilobytes of usage above some nominal amount was going to fly.  It was absurd in the extreme.  The reality of what came to be known as "Internet growth rates" was something they failed to anticipate, even though Gordon Moore's seminal article in the April 19, 1964 issue of Electronics magazine had spelled it out in very easy to understand language, complete with the logarithmic trend charts.  As an aside, in the early 1970s, Moore's friend Carver Meade used that article as the basis for something he called "Moore's Law.."  But, if one actually read what Moore wrote, it was all about economics and the implications of of what was happening in semiconductors.  He even predicted the rise of the personal computer with a cartoon showing them being sold in department stores.  But understanding what was happening in their own industries was not one of the tricks that the executives and board members of those big corporations were into.  So they headed down the wrong path.  If their economics were bad, their engineering was worse.

​

They wrote ponderous complex outlines for what their technical standards needed to include, and then basically converted their outlines into the technical specifications.  This resulted in such things as email address strings that were completely impossible for even their owners to memorize.  And they moved so slow that the average glacer was fast by comparison.  They would write a standard, then convene to bless it, then give everyone four years to implement it, while they worked on the next iteration.  Literally, they would make no improvements to their systems as deployed for four years at a time.

​

Against this, the Internet "request for comment" (RFC) system which had begun in 1969 was lightening fast.  The average time between the proposal of a new bit of functionality for the Internet through the RFC process, and its universal implementation throughout the net prior to January 1, 1993 was eighteen months.  Compared to the superhighway folks, the Internet was evolving at lightening speed.  The various Wikipedia articles on the history of the Internet totally obscure the continuity of is continuous evolution.  It was the very embodiment of the ideal of lean continuous improvement from day one, with the continuity of involved engineers.  The periodic changes in the sponsorship, and organizational names does a pretty good job of hiding this.  The recorded history tends to sound like the ARPAnet was somehow succeeded by NSFnet, which had its day, and then went away.  And that the IETF arrived on the scene rather late and somehow started the systems engineering process anew.  That's all superficial nonsense.  It was the same people working together the same way and growing their community from its inception in the 1960s

​

On top of moving fast, the Internet engineers limited their RFCs to relatively small, well defined bits of functionality.  The KISS principle ruled.  Get something simple working first, and gradually improve as experience is gained with it in actual operation.  So the Internet worked better.

​

Finally, the Internet folks were working with leased lines.  Service billings for users were 100% predictable.  You could budget for your service and there would be no surprises when your bill came.  On top of that, applications could be put up by anyone who had a registered domain host.  There was complete freedom to innovate, while the superhighway folks allowed no freedom at all for their users.

​

In Al Gore's defense, he was actually straddling both camps, and ensuring that any needed public funding was being provided.

​

In Boeing, the official participants in the superhighway effort through ISO, TOG, and TOG and TOGAF was a group in BCS (Boeing IT), which was mostly supported by budget provided by the commercial airplane company.  They had a huge staff and an interoperability lab.  They even had a factory computing architecture collaboration going in parallel that was teamed with General Motors.  That was called MAP/TOP.  MAP was short for the Manufacturing Automation Protocol, and TOP was for the Technical and Office Protocols.  That mess was yet another high cost total disaster of complexity and failure to understand where applied physics and the economics of computing and software were going to go.

​

Boeing had a huge interconnected physical computer network, but by the summer of 1989 we were running something like twenty one separate transport protocols on it, and it was a total mess that was becoming impossible to keep running.  We needed to get to a single direction.  The Boeing network was a microcosm of the Internet as a whole, with many of the same challenges.  We had a big backbone network that was our intranet, running TCP/IP.  We were beg enough that all of the net's scalability issues were things we experienced.  Every piece was connected using bridges, which ensured that any protocols that relied on broadcast packets sent to all connected nodes would cross those bridges and potentially create havoc.  If too many of them got going at any one time, a broadcast storm would result, crashing the whole network.  Even packets addressed to specific destinations would be treated as broadcast messages at the LAN level.  This was because early LANs were built using coaxial cables with many connected nodes, not too dissimilar from the way Minuteman HICS had worked.  

​

Thus, from the point of view of the Boeing PC-LAN community of which I was a part, neither camp had a scalable solution in terms of the cost to simply plug your PC into a network, and they both had other issues as well.  So how people worked together to address the networking challenges was super important.  We were very sensitive to the way they behaved when we had to talk to them about a problem or needed configuration change.  On this point, there was a clear winner.

​

With the superhighway OSI crowd, we were lucky if we could get a satisfactory response in month, even for something as simple as adding another connection (I am not making that up).  With the Internet folks, it took a day or two.  In our own operations, for simple LAN connectivity changes such as moving a PC or installing another one, we could add a node to a Novell or AppleTalk LAN in a few seconds, unless we had to open a machine and flip a switch or add a board.  Then it might take five or ten minutes.

​

So a group of us had a chat with the Internet folks in Boeing, and they convinced us that they would add an automatic address management system to their stuff.  And, they had a pretty good track record, and it wasn't like they had to invent it.  Novell and Apple already had it working, so yeah, we threw our lot in with them.  That setup the big blowout meeting in the Fall of 1989.  Our guy in the meeting was Gabe Hanzelli, and Gabe explained the reality of things to the other attendees.

​

At the end of the meeting an announcement was made that Boeing's tactical direction would be TCP/IP, and that the OSI superhighway stuff would be strategic, and that we would look at it once it worked properly.   To understand why this became the triggering event that it did, it helps to understand a little more about the Boeing intranet.

​

Essentially, we had four flavors of LANs, connected to the net, plus a couple of our several dozen IBM mainframes had interfaces to it as well.  DECnet and VAXes were used by engineers who built hardware for Boeing products like Minuteman, Looking Glass, AWACS, and a bunch of others which are still classified.  They used their systems in four ways.  They would build simulators of the hardware to aid in the development of other hardware.  They would build simulators of the operating systems and extended environments so others could build software that ran on them.  They would provide the primary data storage services for other engineers, and they provided the interfaces to the outside networks, primarily the Internet through a connection at the University of Washington, and the external DECnet world through their connection to DEC West in Bellevue where Dave Cutler had his VMS systems development team. 

 

The Boeing VAX system administrators were not your ordinary sysadmins.  They were highly capable engineers who wrote their own drivers to be added to VMS so that the mission hardware that Boeing was developing for the military could be either simulated or directly connected.  They worked very closely with Cutler's team on a daily basis.

​

Another LAN group in Boeing in the 1980s was the UNIX crowd that mostly used SUN equipment.  These were the software engineers.  They would write the mission software for the hardware (avionics) that would go into our products.  Also, their one generation obsolete equipment would be used by the DEC folks to build our network gateways.  Before 1990, this was common in all aerospace companies.  For about ten years, the hardware of the Internet was slightly dated SUN workstations, something that SUN seemed to never understand about their product line, which was one of the major reasons they went out of business.

​

Yet another LAN community in Boeing were the engineers who designed electronic circuit boards.  They used mostly Apollo equipment.  Boeing had two different types of these folks.  One very large group was organized as Boeing Electronics Company located in Kent, Washington.  They mostly did work for commercial airplanes, or things for the defense side that did not need to be embedded at the program sites for either classified or practical reasons.

​

Finally, there were the new kids on the block, my camp, which was the PC-LAN community.  We were all about transforming the nature of all other work in the company.  

​

These four communities tended to have a presence at most Boeing locations in North America, and we were all linked on one big interconnected network.  The Boeing network in 1989 was comparable in scale to the whole Internet in 1979.  So, the computer companies and carriers tended to listen to us, and watch what we did very closely.  So when the big blow-up meeting to decide whether we were going to continue dabbling with the superhighway stuff or go with the internet came to its conclusion and we said it was all internet for now, it had an immediate impact.

​

One of the major design goals of VMS 5.0 that was under development at DEC West was to add the superhighway protocols, such as the OSI networking stack.  Our announcement meant that we weren't going to buy it.  A few days later, DEC pulled the plug on its VMS 5.0 project.  Bill Gates pounced and hired Dave Cutler. The divorce between IBM and Microsoft was accelerated.  Cutler took his codebase from the VMS project and used it as the starting point for what would become Windows NT. 

 

To follow through on their commitment to the Boeing PC-LAN crowd that they would fix the internet scalability problems, a group from Boeing led by Dave Denny went to Cisco and explained that we had to have an automatic client address management system.  A Cisco Fellow named Ralph Droms went to work on DHCP, which was finalized in 1993.  The reason that DHCP took so much longer than most early Internet protocol development activities is that it had to somehow build on what was already in the net as a deployed and generally accepted standard, and there was this really ugly thing called BOOTP that had to be accommodated.  But once that was done, RFCs 1531 and 1541 happened, and by the end of that year we no longer needed Novell's SPX/IPX system.  

 

Dave Denny also explained to Cisco that if we were going to continue to buy from them, we need to replace our bridges with switches, which at layer 1 was partially backsliding away from Paul Baran's packet switching to circuit switching at the LAN level.  Also, routers would need to have the ability to block all broadcast packets from crossing from one LAN to another, or out onto an intranet backbone.  Cisco did all of this.  And as they say, the rest is history.

​

So Boeing played a key role in at least two critical phases of the development of the early Internet.  Later when the global network was more mature and so common as to no longer merit capitalization, some of us still believed that we could catalyze the development of a couple of other badly needed core internet services.  More on that later.