Betrayed by LinkedIn

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.<p>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.<p>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.

I get this drupal error.<p>-- 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 &#60;= :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] =&#62; variable_init [:db_condition_placeholder_1] =&#62; 112720946350f00b3f105ad8.99608950 [:db_condition_placeholder_2] =&#62; 1357908800.0644 ) in lock_may_be_available() (line 181 of /export/content/data/dlc/shared/www/developer/includes/lock.inc). --<p>Why would somebody spit the SQL exceptions on the browser instead of the log file?

Yet another flawed business model based entirely upon the goodwill and co-operation of a bigger fish in the pond.<p>Don't they know that bigger fish can swim away any time they want? Oh, and they might just turn around and swallow you.<p>To further mix my metaphors - we have had "Cathedrals" and "bazaars" and now we have shacks leant against the city walls.

A business model based 100% on a 3rd party social graph API is not a business model.<p>I hope they can pivot the work they've done to something more standalone.

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.<p>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.

This is an overly dramatic response. And flagging because the author of the overly dramatic response self-posted this to HN.<p>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.

I'm getting an error with a really nice description:<p>Error<p>The website encountered an unexpected error. Please try again later. Error message<p>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 &#60;= :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] =&#62; variable_init [:db_condition_placeholder_1] =&#62; 203428328950f00b0bbd0484.53523159 [:db_condition_placeholder_2] =&#62; 1357908748.7708 ) in lock_may_be_available() (line 181 of /export/content/data/dlc/shared/www/developer/includes/lock.inc).

Linkedin is behaving perfectly reasonably, it makes sense that for privacy reasons you want to restrict access to the work history of connections.<p>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 ?

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.<p>It's just a lot harder to screw someone over when you have to look them in the eyes to do it.

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 <i>to me</i> 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).

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?<p>Did LinkedIn change this overnight, without any sort of "deprecated period" ?<p>Changing important parts of your features or API without even warning your users &#38; partners seems unnecessarily cruel..

One time I decided to spruce up my job title on linked in to better reflect what I do.<p>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.

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.<p>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.<p>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.

Though I personally dislike LinkedIn as a company, I think this is unfair criticism.<p>They modified their API to be more sensitive to users' privacy concerns. There is nothing inherently wrong with a company respecting its users' privacy.<p>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'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?<p>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.

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 <i>primarily</i> on any 3rd party provider can never be a good business model.

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.<p>Obviously they have investors and a business to run, but it's just more of the same bs.<p>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.

It 404's. Here's a cache link: <a href="http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fdeveloper.linkedin.com%2Fforum%2Fretrieve-all-positions-profile-including-past-ones%23comment-20856&#38;rlz=1C1ASUT_enUS502US502&#38;oq=cache%3Ahttp%3A%2F%2Fdeveloper.linkedin.com%2Fforum%2Fretrieve-all-positions-profile-including-past-ones%23comment-20856&#38;aqs=chrome.0.57j58.2037&#38;sugexp=chrome,mod=11&#38;sourceid=chrome&#38;ie=UTF-8" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...</a>

It is not the first time "betrayed" and "LinkedIn" were used in the posting on HackerNews: <a href="https://news.ycombinator.com/item?id=4148915" rel="nofollow">https://news.ycombinator.com/item?id=4148915</a><p>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?

There's no reason you wouldn't be betrayed by LinkedIn, because LinkedIn is the digital equivalent of herpes.

Response from LinkedIn Dev Rel: <a href="https://developer.linkedin.com/comment/20907#comment-20907" rel="nofollow">https://developer.linkedin.com/comment/20907#comment-20907</a>