Total bankers: Twitter and LinkedIn's cynical API play
Not doing evil pays better
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.
"API" is being used in two senses here
Which makes the argument a bit meaningless. What can be open-sourced is the API definition. That is probably uncontroversial, and probably of little value, as each service has its own API requirements.
However, what cannot be "open-sourced" is the actual data the API provides access to. Fundamentally, the data has only been provided for free in order to create interest in the underlying service - business as usual in the Web2.0 world. There is no need or obligation on the hosting sites to hand out their product for free.
There is this curious tendency for web developers to treat privately-run services as generic public-service utilities. Heck - the internet only looks like a utility if you don't ask who pays for it.
If your business critically depends on the use of a third party API - and these APIs are provided almost universally free of charge - then you need a business relationship with the third party to ensure that they provide you with an API with some form of SLA. If you can't get one, you absolutely need to be agile and be prepared to degrade or remove services, and hedge on a variety of the third party's competitors. The old adage of "you get what you pay for" applies to everything - ignore it at your peril.
Of course, what's not mentioned in the media is what conversation took place between LinkedIn and Twitter, particularly what conversation took place about money. LinkedIn may have been "cut off" in one sense, but in another, more grown-up sense, the two companies failed to negotiate an agreement for continuation of the traffic. This could just as easily have been LinkedIn saying "fuck you, we won't pay $X, we don't need you that badly" as it have could been Twitter taking its ball home. All we see from here is the relationship ending, and the post-hoc PR rationalizations that fact generates.
The only pattern seems to be that APIs will be free and easily available from startups, and the ones that succeed will later try to monetize that traffic the way they monetize their other traffic, and they'll do that not when their own business reaches a certain size, but when they have a large enough user of the secondary traffic that it becomes an issue for them.
No amount of "open source" ethos will change the fact that companies need to not have their business cannibalized by competitors. It might be fairer if startups declared that the APIs won't be free or unrestricted forever, but then a little common sense on behalf of API consumers would go a long way too. This should be documented in an industry standard? Really?
"If you're not paying then you're the product" is a paranoid declaration, but the grain of truth it contains should cause businesses to pause before rolling out products that rely heavily on other commercial entities with whom they have not even a Memorandum of Understanding. Frankly, such businesses shouldn't even get past the family-funded stage, and now Bubble 2.0 has burst they probably won't in future.