Just under a month ago LinkedIn terminated API access to a handful of third-party services like Beknown and Branchout. If you haven’t noticed the trend here of late, let me break it down for you. What LinkedIn is doing is just the most recent in a series of similar actions regarding terms of service violations in relation to API usage.
These get figured in our community as, “Startup X or Y overstepped their bounds, shame on them, I guess they better get with the program. I sure wouldn’t want to piss off company Z.”
Shion Deysarkar is the CEO of 80legs, as well as Datafiniti, a stealth newco that leverages 80legs‘ platform for fun and profit. In a previous life, Shion ran a predictive modeling firm. He enjoys playing poker and basketball, but is only good at one of them.
Twitter and Facebook have both in the past year gone through the same (very public)
with members of their developer ecosystem over TOS-related oversteps that resulted in termination of access.
I hope many of you join me in arguing that the breaching parties (i.e. the developers holding the API key) should not be held in contempt of court, as it were.
When has it ever been okay for a business partner, iin the midst of doing agreed-upon business, to suddenly do a 180-degree turn and change the structure of the deal?
Let’s be really clear – these violations are not clear-cut. They are instances of innovators pushing the edges and becoming successful in ways that the provider did not imagine. TOS are being aggressively interpreted, and or changed outright, pulling the rug out from underneath companies large and small that have a made a serious commitment to and investment in a given platform.
And even when the violations are legit, they’re never overt, or malicious. I’ve seen these arguments go down firsthand. There are no compromises, negotiations or discussions you’d find in a typical business partnership.
Developers aren’t being treated like the high-value business partners they are. Recognition is not given to the added value they bring. Value that turns a service like LinkedIn from a website to a platform.
The Conflicting Business Model for Developers Today
According to LinkedIn, the reason for the termination of API access was that these services were charging a fee for access to the LinkedIn API, which is against their API TOS. The LinkedIn API is freely available.
That may sound wrong at first glance, but let’s take a look at how any business (not just the selling of data) is structured and then apply our model to an API.
First off, most businesses purchase raw materials, assemble them in some special way, and then sell the new, finished product for profit. To illustrate this for you, this process usually looks something like this:
Acquire Raw Materials ? Assembly ? Finished Product ? Sell to Customers
When this basic model is applied to how LinkedIn makes money, it looks more like this:
Acquire Users ? Organize into Social Network ? Productize Data ? Sell to Ad Firms or Offer to Developers
The competing interests of revenue generation and platform adoption put the data provider in a dilemma. By offering a free API, they risk developers creating applications that remove the need for people to view their site, thus cannibalizing their primary revenue stream.
The problem lies within the fourth part of the business chain. Because of market competition and public perception, offering data to developers is done freely. This creates two completely different prices for the data: free and some dollar amount for the ads. The competing interests of revenue generation and platform adoption put the data provider in a dilemma. By offering a free API, they risk developers creating applications that remove the need for people to view their site, thus cannibalizing their primary revenue stream.
In order to protect themselves against this problem, the data provider uses TOS as a cudgel, enforcing it in unclear and inconsistent ways. As a result, developers are faced with sneaky TOS changes and watered-down agreements that keep them from being able to work with companies like LinkedIn. They have to be prepared for a bait-and-switch: being promised interesting data, but then being punished when their interesting app goes beyond expected use-cases.
In truth, just about anything can be construed as charging for data, and therefore in violation of a company’s TOS.
Developers have many options to make money, certainly. But at this stage in the maturation of the programmable web, it all amounts to selling data in the end, whether that’s results and feedback analytics to advertisers, premium feature sets with more baked-in intelligence, special reports and visualization tools, facilitated introductions, suggested or promoted content, …the list goes on.
And it all runs on data.
Developers derive additional and/or unseen value from free or cheap data, and sell that value as part of a product that they provide to customers. That’s just classic business.
So, what’s the fix?
My View of Building A Sustainable Future With Developers and Open APIs
No matter how much traction the data is seeing elsewhere, if things look a bit shady from the outside (small developer community, lots of lawsuits or legal scuffles, few financially successful platform applications) then developers start to question how the sausage is made.
We quickly reach a stalemate. Startups are only able to develop services on top of APIs that have limited market impact; and in the long run, the developer ecosystem can only ever be mediocre at best. This is the awful truth of the situation and a detriment to innovation as we know it.
No matter how much traction the data is seeing elsewhere, if things look a bit shady from the outside (small developer community, lots of lawsuits or legal scuffles, few financially successful platform applications) then developers start to question how the sausage is made.
For any business model, a simple maxim holds: if no serious ROI can be made from it, then no serious investment can be put into it. Any normal businessperson would say the same. And yet we’ve somehow deluded ourselves into believing otherwise.
What if we all just put our time and resources into building better, original apps with new functionality, and never had to ask for permission, or forgiveness, again? That’s how Twitter got started, how LinkedIn got started, how Facebook got started. What if the pendulum swung the other way?
There’s another solution, though, that’s less combative.
The recent issues with LinkedIn could easily be washed away if they just agreed to offer premium services for their API – in other words, directly charging developers for access to it’s API, with added calls, SLA’s and an enterprise-grade approach to legal, and legality.
From LinkedIn’s point-of-view, this would subsidize any lost advertising revenue and perhaps even exceed it if the developer community grew bigger, which they would now have an incentive to do.
Twitter too, should have up and done this a long time ago.
Nova Spivack, a serial entrepreneur and a co-founder of Bottlenose, wrote an extremely detailed post on this exact topic. Here, he gets at the heart of the issue, using Twitter as his lens, on how to get back to a place of normalcy and KISS when it comes to API’s and making money.
Ultimately, I don’t think it’s very hard to align everyone’s interests here. Users want to customize and extend the functionality of the websites they use. Developers want to build sustainable business models on top of data. And platforms like LinkedIn want to encourage an ecosystem that increases the value and viability of their platform. Adopting an open data stance or an SLA strategy accomplishes this alignment. Let’s dispense with the mixed messages and get down to business.
