Beyond Telecom: Bob Frankston on the Future We Make for Ourselves
Telecom and the Internet have always been strange bedfellows. On the one hand, we have an industry that's been around for 171 years or more (dating from the first commercial telegraph), and on the other, we have something new with an “end-to-end” model that doesn't require telecom at all to do what it does.
Yet to most of us, Internet access is gravy on top of telephone and television service—part of a bundle that telcos and cablecos call a triple play. Never mind that telephony and video are all made up of the same bits. The carriers want us to think only in terms of familiar and expensive services such as television.
In fact, these models are so highly familiar to our minds that we can hardly think of a world without them. Bob Frankston, however, insists that we should.
Best known as the co-inventor (with Dan Bricklin) of the first electronic spreadsheet (VisiCalc) and as a prime mover behind home networking during his employ at Microsoft in the 1990s, Bob is presently putting his energies into urging us to see past telecom completely—and to start communicating for ourselves, in our own ways, free of telecom's proprietary confines.
In a way, Bob is playing the same role for connectivity that Richard M. Stallman started playing for software when he insisted that it be free. Like RMS, Bob comes from free-as-in-freedom rather than free-as-in-beer. He wants us to be free from forced dependency on big companies and big governments that put us in silos and tell us how to connect and communicate with one another. And, he wants us to be free from the thinking that has us accepting telecom as a way to frame the Internet and everything we do with it.
Unlike RMS, however, Bob has no dogma, no manifesto, no canon. His thinking is too protean and broad for that. Instead, he writes and talks with energy as boundless as the possibilities he wishes to liberate by leaving telecom behind.
Which is why we're here. I think what Bob says about telecom is of founding importance to the future of the Net.
The interview that follows was conducted in January and February 2008, and is a tiny fraction of the total words exchanged. Here's hoping our severe editing will not fail to keep Bob from opening your minds to the possibilities of Life Beyond Telecom.
DS: You like to talk about connectivity rather than communications. Why is that?
BF: Connectivity is about relationships, while communications is what we do with those relationships. The power of today's Internet comes from letting us focus on the relations and our ability to communicate rather than the twisting passages through telecom's maze of copper, fiber and radios.
The networks in our homes are a good example. You “just” print without worry about negotiating for the printing provider.
DS: So the Internet should be a big home network?
BF: Yes, but we need to be careful since the network emerges out of our networking. Copper and radios are just a means we use. It's like the difference between driving and buying a ride from a railroad. We should have infrastructure rather than a choice of whose services we must purchase. DIY must be an option!
DS: Why the railroad analogy?
BF: Because we're still thinking in railroad terms. The FCC (Federal Communications Commission) was partly an outgrowth of the ICC (Interstate Commerce Commission), which regulated railroads. Given the opportunity—which they were—railroad owners became infamous robber barons. How different is that from today when phone companies charge you for the contents of your freight cars, rather than just for using the track? Take SMS, for example. It's just data—a small number of bits using idle capacity. Yet an SMS bit costs millions of times more than a video bit.
They can charge that because, like the railroad barons, they use their control of the infrastructure to force us to buy vintage services at arbitrary prices. These are phone and cable companies with railroad legacies. Not Internet companies.
The importance of the Internet lies in the dynamic process by which a very simple design decision made in the 1970s has become the defining infrastructure for the world. It's what happens when you give billions of people the opportunity to create their own solutions and share them. The infrastructure of telecom is not the infrastructure of networking. We must not confuse the two. The infrastructure of telecom is about billing for scarcity. The infrastructure of networking is DIY and connecting anything to anything.
DS: JP Rangaswami of British Telecom (disclosure: I consult BT on open-source strategy) says the core competence of telcos is billing.
BF: That's true. And it's their core cost as well. When the infrastructure was expensive, it made sense to account for each use of wires and switches. Today, those costs have vanished. Remember that the reason we pay for redundant broadband paths is to keep the bits in billable channels. Even on “TV” we still divide the “dial” into “channels” or dedicated frequency bands—a legacy of analog signaling.
DS: And, why even bother with pushing dozens to hundreds of streams down a “pipe”—because that's what we call it now—when the user is watching only one at a time, and in most cases, it's not even a live program?
BF: Yes! In fact, none of this analog baggage is necessary with digital signaling. Even the distinction between wired and wireless bits no longer makes sense. Why do we need megawatts to shout a signal over a distance from the tops of towers and mountains, when a few milliwatts in your living room or a street lamp can connect you to the whole Internet?
Signaling on single frequencies is a legacy from the early days of radio. You had to be careful to avoid stepping on others' signals. 802.11 puts the responsibility on the receiver and thus encourages innovation rather than caution. Why do we still use a system that requires a license to transmit? It's as if we weren't allowed to own anything blue because that color was taken.
DS: So, what do we really need, if we don't need telecom?
BF: We need surprisingly little—just the means to do our own networking using our community's copper, fiber and radios. We first connect with our neighborhood and interconnect neighborhoods. We don't “access” a far-off Internet. We internetwork.
DS: I think the shift you're looking for has a good model with construction. That industry was born in 1833, when Augustine Taylor built St. Mary's Church in Chicago. Taylor was the first to use what we now call 2x4s, 2x6s, studs and joists. He did it cheap and with amateur volunteer carpenters. It caught on. Suddenly just about anybody could frame and build anything. Old-time builders called it balloon construction, because they thought it would blow away. But it didn't. Instead it revolutionized construction by letting anybody build anything cheap. If you want to build Tudor, or Prairie, or an office or a cabin, you frame it up. As a result, construction is perhaps the largest industry in the world today. And, nobody “owns” it. So, what are the equivalents of 2x4s here?
BF: In telecom, we already have it—bits (or packets). We can run bits over any physical (or virtual) transport and interpret them as we wish. So we can take copper, fiber and radios (CFR) and just treat them as interchangeable bit paths.
Accountants have a term for this—fungible. You don't have to maintain the identity of each kernel of corn—you just count them. Bits are bits. Telecom is about monetizing the path, but if bits are fungible, the paths are no longer special—it's like rangeland versus small plots of land.
DS: It's hard to give up the idea of a network.
BF: We've already done that. Back in the 1980s, UUCP (Unix-to-Unix Copy) was a good example of networking without a network—just cooperating computers calling each other. As with the Internet, it was a learning experience. Today we can do a far better job of networking if we aren't confined to broadband pipes. But the telcos are hooked on that confinement—and providing it as a set of “services”. But, it's a losing proposition. By holding on to that model, they'll fail. They're like a monkey with its hand in a jar, unable to let go, even though that's the only way they'll become free.
DS: Haven't they made some progress?
BF: Not enough to save them. Or us. Today they know that abundance created by fungible bits is their enemy, and it's only a matter of time before they lose control. Too bad we focus on fixing the symptoms—for example, by trying to bolt neutrality onto the artificial FCC Regulatorium. Instead, we should recognize the problem is one created by regulations themselves—a product of the 1930s depression era. The technology and fears of those times make no sense these days. Yet we still accept that static solution instead of what I call the opportunity dynamic.
DS: What is the opportunity dynamic?
BF: We get Moore's Law-type hyper-growth by taking advantage of opportunities rather than allowing only narrow solutions. The dynamic has worked so well that today, even the carriers can't afford their own network. They too are using IP but insist on billing us as if they had special gear for everything. It's as if we had to put a 41-cent stamp on e-mail.
If we are dependent upon the phone company meeting performance requirements, we pay a high price for our dependency. With the Internet, we discover what we can do with what is available. Even better, thanks to software, we can easily share the results with others. At first, you couldn't make phone calls over the Internet, but you could send e-mail. Finding value in what we had drove a dynamic till today we have an ocean of bits, and voice “just works” thanks to statistics. It's not magic but a simple dynamic with demand actually creating supply, because we are taking advantage of available opportunities.
DS: Is this, then, “Frankston's Law”?
BF: Yes, “Marketplaces that provide opportunity rather than just solutions allow demand to create supply.” It's a generalization of Moore's Law. The bottom-line question is, “Why must everyone have to justify new ideas to a telephone company or, for that matter, to any intermediary?” The power of the end-to-end argument is that we can create solutions without depending on intermediaries.
DS: What other ideas must we purge from our minds?
BF: One is that infrastructure has to be expensive and owned by service providers. That's why we can never finish paying for it. The actual cost of copper, fiber and radios is far less than something as mundane as sidewalks. Imagine if sidewalks were a service.
There are so many ways to redefine problems and come up with solutions that are far more valuable—even if we never solve the original problem. Who needs to make sure video signals arrive within a few milliseconds when we can buffer them and provide far higher quality than would be permitted by streaming?
“Phone wire” carries just one phone call, but if you look at the physics of sending signals over copper, you'll realize that we've barely tapped the potential capacity. For example, we don't need to think of them as isolated “pairs”.
DS: We've seen this proven by the Internet, which was not created by telecom, even though we took advantage of telecom's copper and circuits.
BF: Yes, but we're still being timid, because we're still using the prototype Internet, which still has legacy limitations. I think of it as a class project done by friends and colleagues. For me, it was exactly that. It's a nice demo, but still only a demo.
DS: If it's a demo, what's it demonstrating?
BF: The power of the end-to-end constraint, of not depending on favors from a service provider. Of course, this breaks the fundamental presumption of the Regulatorium: that everything must be a billable service.
Where we are now is like the container shipping business, back when it was starting to happen. The old shipping companies opposed it, but they didn't own the ocean. Now look at how much less shipping costs today.
In The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger, Marc Levinson notes that the incumbent shipping companies were unable to control the ocean and prevent container shipping from happening.
Yet, the telcos have managed the amazing feat of controlling the ocean of bits. The problems with single frequency signals that I spoke about earlier provide a reason to take the limitless potential of wireless communication and lock it into fictional channels! Amazing!
This is perhaps the central issue: each of these bad decisions creates stakeholders who want to hold on to their own no matter what the harm done to society.
DS: Seems to me that Google gets the abundance side of the Net, today, no?
BF: Not entirely true. It does benefit from being the largest ship on a rising sea (perhaps an uncomfortable metaphor these days). Its advertising revenue model decouples it from the particulars of technology and the network. But, it seems to want to tether users to its service platforms. After all, an advertiser depends on delivering customers to buyers.
Decoupling is important. This is why at Microsoft I made sure that home networking was available as a technology rather than being treated as a profit center. It's valuable because of what it enables.
DS: What should Google do then?
BF: Why not give away 100,000,000 open access points instead of spending billions on the 700MHz spectrum auction? It would cost less and benefit us all. Or, simply announce it is going to spend a few million to fund connectivity in Silicon Valley. That would drive the dynamic.
The idea of owning the transport reminds me of the days when roads were privately owned and you had men with pikes collecting tolls. We've long since recognized that value in the roads, as with networks, is in what we do with them and not in the roads (or networks) themselves. But the legacy lives on in the word turnpike.
DS: What about municipal Wi-Fi?
BF: The idea is laudable, but all too often muni Wi-Fi is in the mold of another telco system. If we opened up access points, it would be a non-issue, and then we could discover what to do with what we already have!
DS: Let's talk about history. You've been around since the early days of both Multics and UNIX.
BF: Yes. In fact, UNIX came out of the Multics Project. Although Multics defined much of what we think of as computing today, it was captive to Honeywell's business model, which kept it far more expensive than it should have been. UNIX was inexpensive and, thus, gave users a chance to experiment with owning their own systems.
PCs took this a step further. I even dispensed with operating systems when they got in the way. For a while, even UNIX was too much like an old-style mainframe. Things are different today—there is far more computing power, so we can afford to have operating systems.
The demos have driven the dynamic. That's what happened with early UNIX and the Internet. Imagine if we didn't hobble ourselves with the presumption of scarcity. And, if we focused less on patching up today's demo and more on taking advantage of connectivity.
BF: In order to build something that worked using 1970s and 1980s technology, we put in some scaffolding—today's Internet backbone. Today, we've confused this scaffolding with essential infrastructure. The 32-bit IP address was a clever hack—it was adequate for a prototype even though it created a dependency. Housekeeping was a problem, so the DNS was created to provide stable identifiers, only to fail because you don't even own your name—your lname. You lease it.
Too bad we continue to try to shore up the scaffolding. IPv6, for example, focuses on the network, not on our ability to do networking ourselves.
The 32-bit IP address was shim in the days when computers seemed immobile. The DNS was created to provide stable identifiers but failed. You can only lease your “identity”!
We deliver physical mail to addresses. Even the Post Office is smarter than that. They know the address is a hint, but the destination is a person.
The Internet ain't bad for a demo but far from what is possible if we take full control from the end.
DS: You've been accused of trying to destroy all of telecom—or at least of disrupting it severely. Isn't that where you're headed here?
BF: Disruption is a consequence and not a goal. For the most part, you want to get the benefit of community.
Modems are an interesting example, because they were accused at the time of destroying the phone network by tying up all that gear. But the bad behavior drove a dynamic. It turns out the problem was not in trying to send the data, but in a network that tied up resources even if you were sending only a few bits. If it weren't for the common carriage laws (inherited from railroads), they could've banned modems—we'd have never known about the Internet.
The carriers actually had a digital alternative, ISDN, but it was too tied to their business model—meaning they charged too much for it. They used it to bring back per-minute charging—you paid even when idle! Analog telephony was “worse”, but due to an accident of history, analog phone service didn't have the meter running, which meant we could stay on-line using dial-up! This shows how it is not about technology but how we think about opportunities.
Today, we are enamored with broadband—the new ISDN. And, like ISDN, it is technically better. But, like ISDN, it's fatally tied to a business model that is in inherent conflict with providing abundance. It allowed us to innovate past the telcos, and for that reason, it was far better. Today, broadband plays the same role that ISDN did.
The irony is that here too the copper wires provide a very cost-effective alternative. If we focus on connectivity first, speed will come. DSL (the technology, not the service) is just a faster modem and can drive the dynamic. And, if we don't care about controlling the path, we can use 802.11 to provide essentially 100% coverage with existing access points!
Why not repeat history and first light up existing copper at modest speeds and modest cost and complement it with open access points? That will drive the dynamic while broadband is a dead fish trying to swim.
DS: So here's the pushback. For most people, the entire frame of reference is the devil we know. The Internet is bundled by the carriers with phone and television, as just another service. And this is seen as a Good Thing. Why are you looking to solve a problem most people don't think they have?
BF: I'm reminded of when Ben Franklin was visiting the Court of King George and realized there was no middle ground between American independence and British rule.
We're not bargaining. We're reframing the problem. Bear in mind what Henry Ford said. If he'd asked customers what they wanted, they'd say, “faster horses”. VisiCalc happened because we took advantage of an opportunity. It wasn't that we set out to change the world. That was an accident. Who could have guessed? And no one even asked for it.
DS: Speaking of opportunity, most of our readers are exactly the kind of people who aren't happy being slaves, and who might not want just faster horses. These are the folks who should want to take advantage of your opportunity dynamic.
BF: That's good. Now you need to remember that it takes many people trying many ideas to get something that changes everything. What can you do with the bits you have? I'm sure a lot of readers are already reprogramming their access points, which are typically open-source Linux boxes.
DS: Count on it.
BF: Then it's clear how the value is in how we use the network and not the network in itself. The network itself is a cost center. Why would carriers want that burden if they can't use it to force us to buy services? They are in a trap. If they give us capacity, we won't need to pay for services. If the bits are fungible, they can't bill us for them. They need to escape the Regulatorium rather than hope they can retire before it all comes to a head.
So, rather than thinking of networks, we must think of common infrastructure paid for as such—it will cost less than nothing because we already have so much and haven't even taken advantage of what is already there. Why do cities even have phone bills or separate systems for each service?
Think of the savings if cities used this common infrastructure instead of separate ones for each purpose.
Ultimately, I see replay of divestiture. But if the issue is forced, they can change. It would be fair for them to cut a deal with the FCC to get some money for their shareholders. After all, the FCC put them in an untenable situation.
DS: Who, then, should own the physical infrastructure?
BF: The physical infrastructure needs to be owned and operated locally, like roads and sidewalks. The longer we wait, the more jarring the correction.
Doc Searls is Senior Editor of Linux Journal
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- New Products
- Weechat, Irssi's Little Brother
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Poul-Henning Kamp: welcome to
6 min 46 sec ago
- This has already been done
7 min 46 sec ago
- Reply to comment | Linux Journal
53 min ago
- Welcome to 1998
1 hour 41 min ago
- notifier shortcomings
2 hours 5 min ago
3 hours 42 min ago
- Android User
3 hours 43 min ago
- Reply to comment | Linux Journal
5 hours 36 min ago
8 hours 26 min ago
- This is a good post. This
13 hours 39 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?