Total bankers: Twitter and LinkedIn's cynical API play

Open ... and Shut In tech today, it has become a truism that "if you're not paying for it, you're the product". Somehow we have applied this wisdom to consumers without recognising that the same principle applies to enterprises and their developers. Recently, however, Netflix and LinkedIn have reminded us just how precarious it is to build on someone else's platform - or API.

Paul Graham, one of the founders of Y Combinator, has described APIs as "self-serve [business development]". It's a great story: open and document your API and watch a thousand businesses bloom, bringing you cash and legitimacy. All of which may be true, if done correctly.

But the other side of Graham's "business development" is the difficulty of predicting the business planning on the other side of the API. Twitter was pretty free with API access in its early days when it was seeking adoption rather than income. Now that the company has grown up and continues to tighten its grip on how and where users interact with tweets, Twitter terminated its tweet syndication partnership with LinkedIn and has promised to clamp down even more tightly on how developers use its API. Twitter is doing this because it can, as professor Joel West points out, but also because it must: its advertising business depends upon it.

Not that LinkedIn can complain. After all, it has been playing now-we're-open-now-we're-closed API games with its own development partners, as well.

Still want to use those Twitter and LinkedIn APIs?

Many developers will. Those same developers are likely to bump into the harsh realities of a new mercantile API economy, as VMware's James Watters dubs it. Just when you're cruising along the highway of someone else's API, you may find yourself cut off when it no longer suits the API owner's business goals.

Pando Daily's Sarah Lacy nails this theme in writing about the rise and fall of the widget economy. Widgets were supposed to be ways to extend one's web service throughout the web, on others' sites. It didn't quite work out that way:

Platforms may help you get more reach faster, but they come at a cost. The more sites you rely on, it doesn’t necessarily mitigate that risk. Sometimes it just means you own that much less of anything truly valuable.

Those APIs drive value to the owner. Building on them lets you ride on their train for a time, but you are always a second-class citizen, as LinkedIn discovered with Twitter and BranchOut and others discovered with LinkedIn. As an API consumer, you are the product. You are being sold.

Not that this means we should run screaming from open APIs. Far from it. We just shouldn't build our businesses on someone else's platform. Zynga is learning that with Facebook, and a number of companies learned that last week with Amazon when AWS's power outage took down Instagram, Pinterest, Netflix and Heroku. The lesson, whether you're snacking on someone else's API or infrastructure, is the same: expect access to be cut off and hedge.

There's one other thing to consider, as venture capitalist Bill Davidow opines in The Atlantic, and that is the very real possibility that this API mercantilism is a sign of how the technology world is changing, and not for the better:

At both Hewlett-Packard and Intel, where I next worked, money was important – but it wasn't the top priority. The goal was to do the right thing and do it well. If you did that, over time, rewards followed and shareholders supported your efforts...

Many other things have changed in the valley over the past five decades. I've become increasingly concerned about one thing that is seldom discussed: the valley is no longer as concerned about serving the customer, and even sees great opportunity in exploitation. We are beginning to act like the bankers who sold subprime mortgages to naïve consumers...

Or sold developers subprime APIs?

It's worth considering. I don't know if there's a real shift in how the tech world treats its customers, but the API opportunism that is currently en vogue will likely lead to developers mistrusting open APIs and rolling their own services from the ground up, end to end. Yes, that's how it used to be. But it's also inefficient and a poor use of resources.

Perhaps we need an Open Source Definition for APIs and platforms, generally, much like we have for open-source software. With open source, you don't have to trust the intentions of upstream or downstream developers. Trust is baked into the licence. That, to me, seems like a much better recipe for developer success than reliance on open-today-closed-tomorrow APIs. ®

Matt Asay is senior vice president of business development at Nodeable, offering systems management for managing and analysing cloud-based data. He was formerly SVP of biz dev at HTML5 start-up Strobe and chief operating officer of Ubuntu commercial operation Canonical. With more than a decade spent in open source, Asay served as Alfresco's general manager for the Americas and vice president of business development, and he helped put Novell on its open source track. Asay is an emeritus board member of the Open Source Initiative (OSI). His column, Open...and Shut, appears three times a week on The Register.