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 …
"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.
Re: "API" is being used in two senses here
I think API has become one of those terms that has outgrown it's original definition. Is the Facebook Android app an API?
I was struck by this part of the article:
"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"
The exploitation is in the realm of privacy. I first stopped being shocked at how companies like Facebook (overwriting a phone's address book) exploit their customers, and I recently stopped being shocked at how customers allow themselves to be exploited.
We have a name for that kind of API around here.
It's called a "service". You may have to pay for it.
Whether the cookbook to access the service (the API as such) is proprietary, patented, copyrighted, hidden, open, open-sourced, GPL-ed or whatever is orthogonal.
"SMPP is an API. Sending SMS over SMPP costs in the case of one provider and is free in case of another."
"if you're not paying for it, you're the product" and an off the cuff remark about the Amazon AWS service downtime in the same article...
Please mind the gap while boarding this train of thought...
Seems to me that the underlying problem is the notion of making "Free!*" services which must then be funded by
Truly free services can't scale, as is readily apparent to Twitter, and if you're providing an effectively zero-value-add service that just republishes largely worthless user content there isn't really any way other than advertising to pay your hosting and bandwidth costs other than altrusim, and that will only take you so far.
So, there you go. Advertising hasn't just made the web an uglier place, it also encourages a business model which demands that services inhibit interoperability. Yay.
The sentiment is "if you rely on someone else's service it increases your vulnerability", whether because the provider decides to change the rules of its (free) service, or because their (paid) service experiences an outage.
And I'd say, creating an open source like definition for open APIs (/services) is not going to help here...
What about replacing Mr Asay with Mr Crosser... not so many words but 10x as clear and actually true?
Nah, that won't lead to controversy in the comments, ad revenue etc.
Exactly. Point of article:If you're a producer you rely on your suppliers - if the product they supply is not fungible you have a problem. So the Amazon thing is exactly not a relevant example.
"And I'd say, creating an open source like definition for open APIs (/services) is not going to help here..."
I don't think the article is specific enough to really judge that claim. Which is obviously a deficiency on the part of the article, but still, judging the claim is premature.
Matt didn't specify at all what kind of form this 'open source definition' would take. To me it's perfectly consistent with a very loose reading - the 'definition' might not just concern itself with what functions the API would provide, but it could include things like 'this API will always be available'. If you offer an API allowing access to certain data under this standardized definition, you commit to _always_ offering an API allowing access to that data.
Would that work? Hell, I don't know. But it seems to be a reading that's in line with the article.
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.
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.
Exactly the course the new gov.uk beta site is following
"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."
That is precisely what concerned me when I looked at the HTML source for the new gov.uk beta site. It's relying a lot on googleapis.com, wordpress.com and wp.com. Shouldn't what is supposed to become a central point of government services be somwhat more self-sufficient?
Re: Exactly the course the new gov.uk beta site is following
Depends if UK gov is using wordpress code (open source) or hooking into wordpress.com services.
I wouldn't beat on the Gov, they don't have any technical people. not a single competent CTO, no technologists in leadership positions or civil service positions. And certainly no MPs or council men. Is it any wonder they treat computers like imported magic? Pay the funny man with the magic beans enough money and you too could have a fully functioning IT system with no need to ever talk to any geeks.
Re: Exactly the course the new gov.uk beta site is following
If Google is the 3rd party as part of our coalition then you can bet they are helping the government somewhat.
Google seem to quite a bit better than the rest of the social sites.
(I have never used a social networking site yet other than linked in once for less than 5 mins).
The only good thing to come of advertising in recent times was when that guy became the poster child for the 55 gallon drum of personal lubricant.
Our society would change for the better if people stopped using advertising. (Anyone spending lots of money on advertising will have to sell the same product for more money than someone not advertising it) just having it in stock on their site.
Facebook and a want button is another sign of how bad people are these days.
Can you use the Facebook api to send a friend request to everyone on the site ?
"I don't know if there's a real shift in how the tech world treats its customers"
No different from the rest of the commercial world. Whereas in days of old the business model was to serve the customer and serve them well for repeat business and recommendations, the current model is to rip the bastard off for as much as you can get because, just like a bus, another one will be along in a minute.
Dont trust your communication to privately owned protocols
This kind of crap will never happen to SMTP, IRC, HTTP (although they keep trying), IMAP and so on!
We've been here before, both with IBM and more recently with Microsoft. The result will probably also be the same. Facebook and Twitter are probably large enough to be hit with anti-trust. That this is not happening likely indicates that this isn't a serious problem.
That is all.
- Does Apple's iOS 7 make you physically SICK? Try swallowing version 7.1
- Pics Indestructible Death Stars blow up planets with glowing KILL RAY
- Hands on Satisfy my scroll: El Reg gets claws on Windows 8.1 spring update
- Video Snowden: You can't trust SPOOKS with your DATA
- 166 days later: Space Station astronauts return to Earth