Twitter teaches a new generation of developers why proprietary platforms suck

Posted on August 17, 2012

The Interwebs have been up in arms since Michael Sippey of Twitter posted an entry on the company’s blog yesterday outlining some changes that are coming to Twitter’s API. (For my non-technical readers, the API is the mechanism that software programs use to connect to Twitter, allowing them to show you your incoming Tweets and post your own.)

There’s a lot of verbiage in that post, but it boils down to this: Twitter needs to be able to show ads to users to make money. If you use software made by someone else to connect to Twitter, that someone else can put in code to strip the ads out so you never see them. Therefore, Twitter is going to shut those applications made by other people down. They’re not going to do it all right away, of course; but the changes make it pretty clear that existing Twitter client applications’ days are numbered, and that anyone thinking about writing a new one will be so shackled down with restrictions and limitations that the prospect won’t be very attractive.

This has a lot of people angry, especially programmers, because one of the things that has been unique about Twitter since it first launched was how open it was to other people building software on top of their services. Now, though, Twitter needs to start making money; they’ve decided that making money means showing ads; and they can’t show ads consistently unless every user who reads a Tweet reads it through a channel they control. So all those developers who built the software that propelled them to success are going to be put out of business.

Despite what you may be thinking, though, this is not a post wailing at Twitter for making this decision. It’s a post wailing at the developers who are upset about it.

Because — let’s be honest — you should have known better.

The thing about Twitter is that, even though they provided an API for you to connect your software to, it was always, at root, a proprietary system. The only entity that has access to the whole thing — the entire stack of software and data that makes Twitter Twitter — is Twitter Inc. You can’t download the software that runs Twitter and run it on your own server; you can’t see the underlying data, other than what they choose to expose to you via the API.

This is what makes Twitter as a service different from an open system like, say, e-mail. E-mail is not the property of any one corporation. It’s a set of standards that let anyone who wants to build software that can connect to other systems that use the same standards. Anyone can set up a server and start sending and receiving e-mail, as long as their server plays by the same rules everybody else’s does; you don’t need to get anyone’s permission to do that. And if you run the e-mail server, you have complete access to all the mail sent and received by that server; you don’t need to ask someone’s permission to get to it.

The fundamental difference between open and proprietary systems is that developers who build on proprietary systems live or die at the whim of the system’s proprietor. In a proprietary system, the owner of the platform stands between the platform and anyone who wants to build on it. That gives them the power to set the rules that everyone has to play by to use the platform. And it also gives them the power to change the rules whenever the old rules stop being convenient for them.

Open systems operate differently. Because there’s no proprietor standing between you and the platform, no one person can just decide to put you out of business. Open platforms evolve, but they evolve slowly, and with lots of opportunities for those who participate in them to affect the direction they evolve in. Once upon a time, for instance, you couldn’t include formatting (bold, italic, underline, etc.) in an e-mail, or attach files to it; but people wanted to be able to do those things, different people tried different approaches to making them possible, a consensus arose that one approach (“MIME”) was the best way, and that approach eventually got codified as a set of standards. Today nearly every e-mail aware application on Earth follows those standards, and people can easily send formatted messages and attachments back and forth to each other without ever being exposed to the underlying plumbing. Millions (billions?) do so every day.

In a proprietary system, by contrast, new features only get added when the proprietor decides to add them. And the flip side of that is that the proprietor can choose to take features away at any time, too. What’s worse, if you’re a participant in such a platform, you don’t really have a lot of say in the decisions either way. You take what the platform proprietor gives you. And if what they want to give you today doesn’t support the business you’ve just spent five years of blood, sweat and tears building up, you’re just out of luck. Thanks for playing!

This is one of those lessons that everyone involved in technology learns at one point or another. But you shouldn’t have had to learn it the hard way. There’s just so many examples of it in the past. Here’s a few:

• In 2002, the then-young Google launched the Search SOAP API, an interface that let you use a standard protocol to run search queries through Google’s world-beating search engine from within your own software applications. This had all sorts of useful applications, and developers took to it with gusto. As Google’s business plan firmed up and it became clear that showing ads on search result pages was going to be their primary revenue stream, however, this API began to look like a threat, since it let developers show Google search results without Google ads attached. So four years later Google killed it, replacing it with a new “AJAX Search API” which, instead of just giving you back raw search results data that you could format and display however you liked, required you to carve a hole in your Web page where Google could display anything they wanted — including ads. Google gave existing SOAP API applications three years before they turned the lights out for good on them, which is generous as these things go, but the fact remained that developers who’d built applications that relied on that API were out of luck; those applications went from “viable products” to “dead ends” overnight.
• In 1991, Microsoft released a product called Visual Basic that made it possible for non-programmers to write simple Windows applications. It was a huge hit, and an uncountably vast number of these applications were written; people made careers as Visual Basic developers. Then in 2001 they released a new programming environment called .NET, and to encourage people to move over and start using the new shiny, they killed off Visual Basic. (As a sop to the orphaned VB developers, Microsoft provided a new VB-ish language, Visual Basic.NET, in the .NET environment; but VB.NET wasn’t backwards-compatible with “classic” VB code, and as a language it was sufficiently different to be less a simple move up from classic VB and more a whole new language that just happened to share some of VB’s syntax.) Suddenly all those people out there who’d bet their career on Visual Basic had to drop everything they knew and go learn a new language just to be able to keep working, and all those Visual Basic apps had to be either rewritten in a new language or stay frozen in amber as they were the day before the .NET meteor hit.
• In 1987, Apple released a product for Macs called HyperCard, which let users design hypermedia presentations called “stacks” where resources were connected by clickable links. In the pre-Web world this was a major advance, and HyperCard became a popular format for developing interactive presentations, especially in the education sector. When Apple developed OS X in the late 1990s, however, they decided not to include support for HyperCard in the then-new operating system. The result was that all those HyperCard stacks that people had lovingly built and tended over more than a decade were suddenly obsolete; you could only run them if you had an old, pre-OS X Mac available, and no easy way to make them playable on newer Macs existed. And all the HyperCard skills that those people had learned over that time were suddenly obsolete too. (Unlike with Google’s SOAP API and Visual Basic, HyperCard developers never even got the courtesy of an official explanation of the decision from Apple; HyperCard was just quietly dropped into the memory hole. The conventional wisdom is that it died because Steve Jobs, who returned to lead Apple in 1996, didn’t like it.)

The thread that connects these stories is simple: all of them are about developers who got burned by relying on promises from owners of proprietary platforms. Unless you have a legally binding contract with the platform proprietor, you should be aware that a proprietary platform vendor’s promises are worth nothing. All it takes is a change of management or a change of strategy by the proprietor and suddenly yesterday’s firm commitments are today’s forgotten ones. Building on a proprietary platform is building on quicksand.

This is why Dave Winer refers to developers who build on proprietary platforms as having been “locked in the trunk.” The platform is a car, and you’re not the driver. You’re not even a passenger. You’re locked in the trunk, and you’re only as free as the owner of the car will let you be.

It’s also why so many of us, having been burned by proprietary platforms in the past, flocked to the Web, which is a truly open platform. And why we resist the efforts of companies like Facebook and Twitter to take that platform and close it. Once you’ve been locked in the trunk, and managed to escape, you don’t ever want to go back in there again.

I wish each generation of developers didn’t have to learn this lesson the hard way. It’s a painful one, especially if you’ve made a big bet on a platform only to find yourself abandoned by its proprietor. But it’s a lesson that the industry keeps teaching us, over and over again. And it’ll only stop dishing out the lessons when we stop enthusiastically volunteering to go into the trunk.