Timeless Telephony

When I was a child, my family moved from the east to the west coast of Canada. After the move, I talked to my cousin on the east coast using some telephony software because in 1994 a long distance call would have damaged my parents’ bank account. I don’t remember the name of the software we used, but it worked well. When it was started it would display your IP address. My cousin would start the program and give me his IP address via email. I would type in his IP address, the programs would connect, and we would talk using the microphone and speakers. The sound quality was as good as a regular telephone, if not better. We felt like we were living in the future.

I’m pretty sure that if I were to take that software today, and ran it on a computer of that vintage, I would be able to call someone else who was using the same software. There’s no reason why the software would not work today just as well as it did back then. The underlying protocols haven’t changed¹, and aren’t likely to in the foreseeable future. The Operating System of the day is still floating around on CD’s somewhere. The drivers for the network cards are easily located (often on the same CD as the Operating System). The computers talked directly to each other, there was no service that we had to sign up and pay² for.

How can I be so sure that this software would be able to run well today? Because there were so few moving parts: the program was designed to talk to another copy of itself over a network. This is something we had known how to do quite well for many years prior to the release of this particular software. Because the program talked to itself, without a third-party broker in the middle, the only dependency was the program on the other end. A call could only be dropped if the program or network connection on one side stopped working. Such a failure would be immediately obvious to the person on the side that stopped working.

In fact, thanks to advances in emulation and virtualization, I’m sure I could run that software on my current computer. If the source code were available, I’d even be able to re-compile it and run it natively.

When comparing this software to a more modern replacement, such as Skype, it’s easy to see what the major difference is. The old software didn’t make use of a middle-man service. The software middle-man does things like tracking users, storing “profiles”, and funneling traffic. Those things are anti-features: we don’t want our “profiles” saved, we don’t want to be tracked, and we probably don’t want our traffic funneled. Time, energy, and money was spent developing “features” that no user ever wanted³.

Most software today, and more importantly the users of it, suffers under the weight of this needless complexity resulting from implementing anti-features. Skype has massive infrastructure, and employs thousands of people, so that they can do things you probably don’t want them doing. And charge you for the privilege.

People involved in software and technology love to drone on and on about efficiency, eliminating waste, and making things simpler. Why, then, are we building massive corporations, when small groups of people would provide better products? Why are we building infrastructure, and employing people to re-invent many wheels, when we could be automating, eliminating waste, and simplifying?

Science fiction authors have often talked about the post-scarcity economy. Put simply: an economy where things can be produced so effortlessly that they’re extremely cheap or free. By leveraging our skills, and focusing on simplicity, we have the skills to turn technical services into commodities that can be provided so cheaply they might as well be given away. Instead, we’re making simple problems needlessly complex, and making people pay dearly for the supposed privilege of letting those things into their lives.