This is the risk of building your business on somebody else's platform; there's always a degree of sharecropping involved, and in this realm, landowners are not bound to any law.
I wonder how many "big" startups will offer APIs from now on. Many API-friendly services (delicious, twitter) have changed their stance, and Google didn't even want to release an API for G+. Many "new" APIs are basically useless, as companies are scared to death by piggybackers.
The "tale" of many of the big startups you mentioned is that they still can't figure out how to effectively monetize their platforms. For instance, if you look at Twitter, they made a huge push to get the developer ecosystem to fill in holes Twitter itself couldn't cover; the end result being a growing community and revenue streams Twitter got nothing from. Seeing this, I think Twitter came to the belief they needed to completely control their platform in order to monetize it, so they severely curtailed the development ecosystem and tried to inject themselves into as many revenue streams as possible. I think the end result will be companies that view themselves as content companies will issue severely restricted APIs and companies that view themselves more as data companies (i.e. Factual http://www.factual.com/ Standard I don't work there but like what they're doing disclaimer applies here) will push APIs out the door because they want to be the data provider whose integrated into every application possible.
I don't understand why the likes of Twitter can't simply have set prices, ala AWS: X token activations + Y requests = $ Zk p/month developers have to pay. Clear, easy, fair, progressive. Surely there's a way to keep everyone in business.
I started writing a reply and realized your question was harder than it first looked when it comes to companies like Twitter versus a service like AWS.
Short Answer: AWS provides a agnostic service focused on utilization with no specific purposes in mind, hence a metered system makes perfect sense. Twitter only exists with user driven content and needs a constant pipeline of the stuff to survive, and because the web application is free in order to eliminate barrier to entry, implementing a metered system for developers would remove incentives to build new applications because they're having to pay to compete with something people can get for free.
Long Answer: You can easily explain why a metered system works for a company like AWS because you're renting a agnostic hardware platform you can do anything on from building the next Twitter to serving cat videos to grandmom's mobile device. In this case, they can consider all usage and bits equal and charge accordingly. It gets murkier when you look at companies like Twitter or Facebook that are trying to be content companies and global platforms at the same time. These kinds of companies make money by getting users to post content to their service, letting them sell targeted ads, compiling user profiles they can sell / reuse, and by selling content to third-parties who can analyze (i.e. Salesforce purchasing access to the entire Twitter firehose). Subsequently, most consumer oriented development on these platforms focuses on the posting and accessing of content and, in many cases, consists of standalone applications ranging from open source to paid for with a couple SaSS platforms thrown in for good measure. Monetizing this ecosystem poses two separate challenges. First, the external applications hide user data from the content company. Coming through an application, the app can send the bare minimum necessary for an HTTPS connection to the API and the company won't know if the user's on a mobile device or computer, what O/S and version they're running, the actual time of the interaction (for instance, sending a delayed tweet) and a whole host of other user metrics. This decrease in information hurts Twitter's ability to build user profiles and vector the user to things they might pay for. By tightening their grip on the third-party ecosystem, Twitter ensures the flow of information necessary to keep building these profiles.
Secondly, creating a metered usage system for a content company would flip the revenue system, developers would be subsidizing users using the content platform unless they send users a monthly bill for their usage of the app. This would completely destroy any third-party ecosystem since the web app is free. Why pay a monthly bill to use a otherwise free service? Sure, you might see some adoption, but I would argue it'd be microscopic compared to an ecosystem built on a free API.
Many Western cultures struggle with the Japanese way of doing business. It's all about slow, face to face, building of relationships. Trust is earned over a long time and once you gain that trust, there is a heavy sense of duty to maintain it.
It's just a lot harder to screw someone over when you have to look them in the eyes to do it.
If you have a business model that's based on a one sided relationship, then the chances of it going sour is significantly higher. Plenty of companies start out relying on 3rd party APIs and most of the time it's a happy relationship, but see what happened when the 3rd party needs monetise like Twitter did.
The scary thing is that most sites have such vital relationships, e.g. with TLD registries. Can you actually rely on nic.ly or nic.in keeping your domain safe forever?
It's not so much one way with the TLD registers though, there's a formal business relationship where a price is agreed for a level of service (usually). Granted, a lot of the power remains in their court, but there's a two way relationship going on. The problem with the 3rd party API is for the most part it's all free, thus leading to the power remaining solely with the provider.
It's amazing how much businesses often depend on single sources for services, TLD's is a great example.
If you rely on a 3rd party for your business, then the 3rd party is in control of your company future.
In that regard, its not about risk. Yes, using 3rd party API for your business model is risky, but thats a secondary effect. The major issue is than the future of the company, and any promises and investments done is completely dependent on that third-partys' whims. To some degree, your even in less control than if you were employed for the 3rd party company, as there are employment laws to protect employees, but no laws in place to protect you against changes by the 3rd party to the API.
I just started reading "the signal and the noise" [0], and he talks about the difference between "risk" and "uncertainty": "Risk" is a known factor, something you can calculate with. Something might be risky (50% chance of failure) but at least you can calculate and reason about it. "Uncertainty" is "worse" because you can't easily reason about it. We often assign numbers to uncertain events anyway, but they might be off by several orders of magnitude.
He goes on to say something like: Risk fuels capitalism and the marked, uncertainty grinds it to a halt
Edit: I forgot to tie this in to what we where talking about :)
As I see it, relying on someone else (with out any guarantees) is not just risky but uncertain. You can't really know how likely it is that they will change down the road. Doesn't mean it can't work out though..
It's not the fact that you are using 3rd party APIs. There are plenty of legacy companies that created products based on 3rd party APIs from Microsoft, Oracle, Sun, etc, that did perfectly fine. Microsoft in particular is extremely professional and will bend over backwards to ensure backwards compatibility. You can still install many 20-year old programs on Windows 7 and they will run perfectly.
As I mention in my post, the issue is that these Web 2.0 companies don't offer support contracts, and don't have a formalized API that guarantee backwards compatibility. THAT is the problem. We ALWAYS bought a support contract whenever we integrated with an API. The support contract gave us some legal rights, but these days there are no such legal rights, and that is what is really risky.
Because there is no competition. If you decide to build rocket launchers and the company you source, say the warheads for the rockets, starts sending you lemons (rockets without the high yield explosives you used to get for example), you start sourcing your warheads from someone else. Hell build you own and get on with it.
Now if a company patents a specific warhead that only they can make and you decide to make a rocket launcher that is made specifically to launch rockets with those warheads and no other warheads are compatible with your launcher and suddenly the source company decides that their warheads suck anyways, you just lost your business.
My Takarov can fire any type of 7.62×25mm Takarov ammunition, albiet some is better than others. If it could only fire a specific type of surplus ammo that might not longer be available tomorrow, my gun could end up being useless in a blink of an eye.
I'm also a bit perplexed how a business model based 100% on a 3rd party social graph discovers in January, when preparing for launch, that they were adversely affected by an API change apparently made in August.
It also sounds like a change LinkedIn were considering for a while that might have been avoided by sending an email stating "We're planning on building an app dependent upon the the X API call to do Y. Could you please let us know of any changes planned to this feature." If my business model was that tightly coupled to LinkedIn's API and nobody got back to me I'd take that as a warning sign.
Everytime I get excited about using linkedin data/API to build something that could be more than a side project, I see posts lke this and understand that relying primarily on any 3rd party provider can never be a good business model.
I'm getting an error with a really nice description:
Error
The website encountered an unexpected error. Please try again later.
Error message
PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {semaphore} WHERE (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1) AND (expire <= :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] => variable_init [:db_condition_placeholder_1] => 203428328950f00b0bbd0484.53523159 [:db_condition_placeholder_2] => 1357908748.7708 ) in lock_may_be_available() (line 181 of /export/content/data/dlc/shared/www/developer/includes/lock.inc).
Anyone have any context? It kind-of seems like they built something following the documentation, and when they launched they found out that the docs weren't correct anymore?
Did LinkedIn change this overnight, without any sort of "deprecated period" ?
Changing important parts of your features or API without even warning your users & partners seems unnecessarily cruel..
Linkedin is behaving perfectly reasonably, it makes sense that for privacy reasons you want to restrict access to the work history of connections.
Imagine someone you're connected to using linkedin on a recruiter's website giving them access their linkedin account. That recruiter now has full access to your work history, do you consider that acceptable ?
I would agree with you, but given that many LinkedIn profiles are public and discoverable when doing Google searches, with the work history included, I don't think this is an issue privacy, as those people wanted for their profile to be public. Anyway, a simple crawler would do the trick for public profiles.
It's sort of ridiculous how little information you can get from LinkedIn via their API. Case in point, I don't think you can get Twitter handles from even first-tier connections any more. I made the appropriate API calls, waved my hands, and all I got were empty values. The docs do clearly state that you should be able to download every Twitter handle associated with an account, so WTH? It looks like they've revoked this functionality without changing the docs?
More broadly, it would be cool for a developer-oriented company to de-risk their API by adding some guarantees that they won't pull this kind of stuff. Right now developer agreements pretty well only restrict what the developer can do; adding conditions to limit how the interface can change would be a big selling point. The problem is, as long as VCs keep throwing money at companies that exist at the mercy of LinkedIn et al, there's no reason for them to. They get to open up the platform, watch for popular apps, then consume or copy them and lock down the API again to prevent competition.
Well put, Albert[1], but the promise of opening up APIs was supposed to be to encourage an ecosystem, which locks users in because all their apps are there. Rather than LinkedIn trying to hoover up every penny that might be generated by their data, the goal is supposed to be:
- LinkedIn collects a ton of user data, and had some idea to monetize it
- clever developer has a different idea about the same data, uses the API to achieve it
- users love developer's app, and they stay on LinkedIn because they love all the ecosystem apps
- maybe LinkedIn gets jealous and implements their own version. This is fine, if they don't break any laws, or cut off the original service for no real reason
Partnership sounds like some Facebook-Zygna type relationship. That seems like a really high barrier to entry. If you look at a service like Wolfram|Alpha, they're doing it right by putting reasonable restrictions on API use, and saying up front "license this commercially, contact us". This is a win-win: WA makes money, you're a real customer with bargaining power. Throwing a half-assed api out there for anyone to use, whinging about not making any money, then revoking bits piecemeal is not good for anyone.
1. Your writing seems to lose a certain quality online, maybe stick to prose? L'etranger was very good.
As a LinkedIn user, I'm actually relieved that they're considering my privacy. And with regards to the API behaving like the web page, there's a big difference to me between a machine scraping my data and a human looking at my profile (one might just be interested, the other is trying to use me for something).
But at what cost? I get a job today, fine. But then the company that found me the job is pressured to monetize better. Then what do they do? To whom do they sell my data or something based on my data in a way that I do not necessarily approve of?
I generally don't like things tied in to my social networks. This is not because I don't think they are useful, it is because I don't have long-term trust in the companies doing them.
Thinking like this and having a profile in LinkedIn seem incompatible, for several reasons. In any case, by closing API access LinkedIn is not making nefarious use of your data impossible, only a bit harder. In fact, it's almost guaranteed that most 3rd party use of your profile data will be nefarious now, since they have to violate the ToS to get it in the first place.
I'm not worried about criminals though. I'm worried about legitimate businesses that will do things I object to. The criminals will do what they want, and I have remedies available to me in case I am victimized. But if some over-zealous startup with an API key screws me over, there's nothing I can do about it assuming they didn't violate any of the LinkedIn rules (and almost nothing even if they did, since LinkedIn would be the party that was wronged).
One time I decided to spruce up my job title on linked in to better reflect what I do.
Well the next day I was hearing from people I hadn't talked to in years congratulating me on my promotion! It turns out Linked in had emailed my connections and said I got a promotion. That was pretty creepy. I need to turn that off somehow I guess.
They have also been betraying their customers. Information that used to be available via common search is now behind the "paywall". If you don't know someone, you basically can see their picture, name, job, company and a little more. Which means, I am putting up my information for friends or people who pay money for my information.
Obviously they have investors and a business to run, but it's just more of the same bs.
Perhaps there should be some soft of NO IPO, NO VC standard moral code page, which basically tells customers, we aren't going to screw you on behalf of the few. I would sign up in a second.
They have also been betraying their standard users. Information that used to be available via common search is now behind the "paywall". If you don't know someone, you basically can see their picture, name, job, company and a little more. Which means, I am putting up my information for friends or people who pay money for my information.
Obviously they have investors and a business to run, but it's just more of the same bs.
Perhaps websites should have some sort of NO IPO, NO VC standard moral code page, which basically tells customers, we aren't going to screw you on behalf of the few. I would sign up in a second.
This is an overly dramatic response. And flagging because the author of the overly dramatic response self-posted this to HN.
Spending a year "and investors money" developing two applications that rely so heavily on being able to pull peoples past job titles that when the policy turns out to be different you have to start all over? That's not a business model.
Suppose I owned a shoe store and the only supplier I chose to work with was Nike. I built my store on top of Nike's product, became an expert at it, had lots of customers and knew the market well. One day, Nike sees how many orders I've been making lately and decides to cut off my supply and open a Nike Store in my town. No contract with Nike, I'm SOL. I start wishing I had diversified my supply a little more.
In traditional business, there is a known threat to nearly all companies called "supplier power". If the power your suppliers have on you is strong, you're in a weak position and should try and increase your power over the supplier. I don't know if this is unavoidable or it's simply neglected within the tech community, but I'm never shocked when APIs get restricted or shut down by their parent company when others are monieizing it.
There have been enough high-profile examples over the past year or two that any business relying on a data pipe from another company needs to be on top of the relationship. The business itself should also be figuring out ways to protect itself should the pipe become clogged or shut off all the way.
And it doesn't necessarily have to be a "bad will" from the power supplier.
I know a store who went down because they were relying on a unique supplier and, at one point, the supplier experienced an issue at their factory, outside of their control (a flood).
The supplier was big and strong enough to deal with the momentarily slowdown (it lasted months) but the store I knew simply couldn't handle their customers' orders and couldn't accept new customers. It quickly degenerated: unable to pay the salaries, then unable to pay the bills, the tax, etc.
And the store, after years of "faithful" services, went bankrupt after a few weeks/months. The sad thing is you could see them trying desperately to stay alive and they were nice people.
So it's as you said: be careful to not depend on a power supplier because several things may go wrong.
Though I personally dislike LinkedIn as a company, I think this is unfair criticism.
They modified their API to be more sensitive to users' privacy concerns. There is nothing inherently wrong with a company respecting its users' privacy.
The complainant is understandably disappointed, but he is wrong in suggesting that an API is a contract that the host company can never change. Changing an API can be part of improving your product, and that seems to be the case here.
Previously, in companies that I've worked with that based their products on APIs from Microsoft, Oracle, Sun, etc, we would purchase a formal support agreement so that when things changed, we would have the ability to actually get some level of support.
It seems these days that companies like LinkedIn, Twitter, Google, Facebook, etc, not only do not have any real forms of support, you can't even purchase a support contract if you wanted. Also, they don't have the professional courtesy to maintain their APIs to ensure backwards compatibility, unlike companies in the past.
I'm not sure why people would invest money and time into integrating with products that don't offer some level of formal support, as well as backwards compatibility. If you have no contracts and no stability with your underlying service provider, you are completely at their mercy. This means that any and all apps based on Facebook, Twitter, LinkedIn, etc are suspect, and anyone who does business with companies like Twitter and LinkedIn who are notorious for screwing over their developer community by changing things willy nilly, is basically stupid. The only development use case is if their goal is to create a popular app quickly, and then exit quickly. If they intend to create a product/company with a long-term vision, they are completely at the mercy of these companies.
When will people learn not to be completely dependent on a third-party, especially one like LinkedIn, whose API was always restrictive? If privacy was a concern for LinkedIn, why do partner companies (aka $$$) have a less restrictive API?
63 comments
[ 3.0 ms ] story [ 135 ms ] threadDon't they know that bigger fish can swim away any time they want? Oh, and they might just turn around and swallow you.
To further mix my metaphors - we have had "Cathedrals" and "bazaars" and now we have shacks leant against the city walls.
"Hey we built this feature on your site, it's really cool. So, erm, want to buy us?"
I wonder how many "big" startups will offer APIs from now on. Many API-friendly services (delicious, twitter) have changed their stance, and Google didn't even want to release an API for G+. Many "new" APIs are basically useless, as companies are scared to death by piggybackers.
Short Answer: AWS provides a agnostic service focused on utilization with no specific purposes in mind, hence a metered system makes perfect sense. Twitter only exists with user driven content and needs a constant pipeline of the stuff to survive, and because the web application is free in order to eliminate barrier to entry, implementing a metered system for developers would remove incentives to build new applications because they're having to pay to compete with something people can get for free.
Long Answer: You can easily explain why a metered system works for a company like AWS because you're renting a agnostic hardware platform you can do anything on from building the next Twitter to serving cat videos to grandmom's mobile device. In this case, they can consider all usage and bits equal and charge accordingly. It gets murkier when you look at companies like Twitter or Facebook that are trying to be content companies and global platforms at the same time. These kinds of companies make money by getting users to post content to their service, letting them sell targeted ads, compiling user profiles they can sell / reuse, and by selling content to third-parties who can analyze (i.e. Salesforce purchasing access to the entire Twitter firehose). Subsequently, most consumer oriented development on these platforms focuses on the posting and accessing of content and, in many cases, consists of standalone applications ranging from open source to paid for with a couple SaSS platforms thrown in for good measure. Monetizing this ecosystem poses two separate challenges. First, the external applications hide user data from the content company. Coming through an application, the app can send the bare minimum necessary for an HTTPS connection to the API and the company won't know if the user's on a mobile device or computer, what O/S and version they're running, the actual time of the interaction (for instance, sending a delayed tweet) and a whole host of other user metrics. This decrease in information hurts Twitter's ability to build user profiles and vector the user to things they might pay for. By tightening their grip on the third-party ecosystem, Twitter ensures the flow of information necessary to keep building these profiles.
Secondly, creating a metered usage system for a content company would flip the revenue system, developers would be subsidizing users using the content platform unless they send users a monthly bill for their usage of the app. This would completely destroy any third-party ecosystem since the web app is free. Why pay a monthly bill to use a otherwise free service? Sure, you might see some adoption, but I would argue it'd be microscopic compared to an ecosystem built on a free API.
It's just a lot harder to screw someone over when you have to look them in the eyes to do it.
I hope they can pivot the work they've done to something more standalone.
It's amazing how much businesses often depend on single sources for services, TLD's is a great example.
In that regard, its not about risk. Yes, using 3rd party API for your business model is risky, but thats a secondary effect. The major issue is than the future of the company, and any promises and investments done is completely dependent on that third-partys' whims. To some degree, your even in less control than if you were employed for the 3rd party company, as there are employment laws to protect employees, but no laws in place to protect you against changes by the 3rd party to the API.
He goes on to say something like: Risk fuels capitalism and the marked, uncertainty grinds it to a halt
[0] http://en.wikipedia.org/wiki/Nate_Silver#Book
Edit: I forgot to tie this in to what we where talking about :) As I see it, relying on someone else (with out any guarantees) is not just risky but uncertain. You can't really know how likely it is that they will change down the road. Doesn't mean it can't work out though..
http://unreasonable.is/opinion/entrepreneurs-are-scientists/ https://news.ycombinator.com/item?id=5042525
As I mention in my post, the issue is that these Web 2.0 companies don't offer support contracts, and don't have a formalized API that guarantee backwards compatibility. THAT is the problem. We ALWAYS bought a support contract whenever we integrated with an API. The support contract gave us some legal rights, but these days there are no such legal rights, and that is what is really risky.
Now if a company patents a specific warhead that only they can make and you decide to make a rocket launcher that is made specifically to launch rockets with those warheads and no other warheads are compatible with your launcher and suddenly the source company decides that their warheads suck anyways, you just lost your business.
My Takarov can fire any type of 7.62×25mm Takarov ammunition, albiet some is better than others. If it could only fire a specific type of surplus ammo that might not longer be available tomorrow, my gun could end up being useless in a blink of an eye.
LinkedIn doesn't have the best experience for everyone.
It also sounds like a change LinkedIn were considering for a while that might have been avoided by sending an email stating "We're planning on building an app dependent upon the the X API call to do Y. Could you please let us know of any changes planned to this feature." If my business model was that tightly coupled to LinkedIn's API and nobody got back to me I'd take that as a warning sign.
Error
The website encountered an unexpected error. Please try again later. Error message
PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {semaphore} WHERE (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1) AND (expire <= :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] => variable_init [:db_condition_placeholder_1] => 203428328950f00b0bbd0484.53523159 [:db_condition_placeholder_2] => 1357908748.7708 ) in lock_may_be_available() (line 181 of /export/content/data/dlc/shared/www/developer/includes/lock.inc).
-- PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {semaphore} WHERE (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1) AND (expire <= :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] => variable_init [:db_condition_placeholder_1] => 112720946350f00b3f105ad8.99608950 [:db_condition_placeholder_2] => 1357908800.0644 ) in lock_may_be_available() (line 181 of /export/content/data/dlc/shared/www/developer/includes/lock.inc). --
Why would somebody spit the SQL exceptions on the browser instead of the log file?
Did LinkedIn change this overnight, without any sort of "deprecated period" ?
Changing important parts of your features or API without even warning your users & partners seems unnecessarily cruel..
Imagine someone you're connected to using linkedin on a recruiter's website giving them access their linkedin account. That recruiter now has full access to your work history, do you consider that acceptable ?
(Linkedin don't let you access public profiles via the API; but that's a separate issue)
More broadly, it would be cool for a developer-oriented company to de-risk their API by adding some guarantees that they won't pull this kind of stuff. Right now developer agreements pretty well only restrict what the developer can do; adding conditions to limit how the interface can change would be a big selling point. The problem is, as long as VCs keep throwing money at companies that exist at the mercy of LinkedIn et al, there's no reason for them to. They get to open up the platform, watch for popular apps, then consume or copy them and lock down the API again to prevent competition.
- LinkedIn collects a ton of user data, and had some idea to monetize it
- clever developer has a different idea about the same data, uses the API to achieve it
- users love developer's app, and they stay on LinkedIn because they love all the ecosystem apps
- maybe LinkedIn gets jealous and implements their own version. This is fine, if they don't break any laws, or cut off the original service for no real reason
Partnership sounds like some Facebook-Zygna type relationship. That seems like a really high barrier to entry. If you look at a service like Wolfram|Alpha, they're doing it right by putting reasonable restrictions on API use, and saying up front "license this commercially, contact us". This is a win-win: WA makes money, you're a real customer with bargaining power. Throwing a half-assed api out there for anyone to use, whinging about not making any money, then revoking bits piecemeal is not good for anyone.
1. Your writing seems to lose a certain quality online, maybe stick to prose? L'etranger was very good.
Giving/finding you a job?
I generally don't like things tied in to my social networks. This is not because I don't think they are useful, it is because I don't have long-term trust in the companies doing them.
Well the next day I was hearing from people I hadn't talked to in years congratulating me on my promotion! It turns out Linked in had emailed my connections and said I got a promotion. That was pretty creepy. I need to turn that off somehow I guess.
Obviously they have investors and a business to run, but it's just more of the same bs.
Perhaps there should be some soft of NO IPO, NO VC standard moral code page, which basically tells customers, we aren't going to screw you on behalf of the few. I would sign up in a second.
Obviously they have investors and a business to run, but it's just more of the same bs.
Perhaps websites should have some sort of NO IPO, NO VC standard moral code page, which basically tells customers, we aren't going to screw you on behalf of the few. I would sign up in a second.
Spending a year "and investors money" developing two applications that rely so heavily on being able to pull peoples past job titles that when the policy turns out to be different you have to start all over? That's not a business model.
In traditional business, there is a known threat to nearly all companies called "supplier power". If the power your suppliers have on you is strong, you're in a weak position and should try and increase your power over the supplier. I don't know if this is unavoidable or it's simply neglected within the tech community, but I'm never shocked when APIs get restricted or shut down by their parent company when others are monieizing it.
There have been enough high-profile examples over the past year or two that any business relying on a data pipe from another company needs to be on top of the relationship. The business itself should also be figuring out ways to protect itself should the pipe become clogged or shut off all the way.
And it doesn't necessarily have to be a "bad will" from the power supplier.
I know a store who went down because they were relying on a unique supplier and, at one point, the supplier experienced an issue at their factory, outside of their control (a flood).
The supplier was big and strong enough to deal with the momentarily slowdown (it lasted months) but the store I knew simply couldn't handle their customers' orders and couldn't accept new customers. It quickly degenerated: unable to pay the salaries, then unable to pay the bills, the tax, etc.
And the store, after years of "faithful" services, went bankrupt after a few weeks/months. The sad thing is you could see them trying desperately to stay alive and they were nice people.
So it's as you said: be careful to not depend on a power supplier because several things may go wrong.
Change the analogy to, you are opening a Nike store (not yet open), and your business relies on Nike having shoes with Nike+ built into them.
And then Nike decides to discontinue Nike+.
Nike didn't betray the not-yet-open store owner in that case.
They modified their API to be more sensitive to users' privacy concerns. There is nothing inherently wrong with a company respecting its users' privacy.
The complainant is understandably disappointed, but he is wrong in suggesting that an API is a contract that the host company can never change. Changing an API can be part of improving your product, and that seems to be the case here.
It seems these days that companies like LinkedIn, Twitter, Google, Facebook, etc, not only do not have any real forms of support, you can't even purchase a support contract if you wanted. Also, they don't have the professional courtesy to maintain their APIs to ensure backwards compatibility, unlike companies in the past.
I'm not sure why people would invest money and time into integrating with products that don't offer some level of formal support, as well as backwards compatibility. If you have no contracts and no stability with your underlying service provider, you are completely at their mercy. This means that any and all apps based on Facebook, Twitter, LinkedIn, etc are suspect, and anyone who does business with companies like Twitter and LinkedIn who are notorious for screwing over their developer community by changing things willy nilly, is basically stupid. The only development use case is if their goal is to create a popular app quickly, and then exit quickly. If they intend to create a product/company with a long-term vision, they are completely at the mercy of these companies.
When will people learn not to be completely dependent on a third-party, especially one like LinkedIn, whose API was always restrictive? If privacy was a concern for LinkedIn, why do partner companies (aka $$$) have a less restrictive API?