

Betrayed by LinkedIn - SandroG
http://developer.linkedin.com/forum/retrieve-all-positions-profile-including-past-ones#comment-20856

======
ssharp
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.

~~~
unreal37
I don't think this is a great analogy in this instance.

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.

------
narad
I get this drupal error.

\-- 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?

~~~
notzach
Clearly they don't understand how to configure drupal.

~~~
ahi
It's a big club.

------
bdfh42
Yet another flawed business model based entirely upon the goodwill and co-
operation of a bigger fish in the pond.

Don'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.

~~~
EwanToo
Of course, the "swallow you" option is what lots of these types of start ups
both expect, and want.

"Hey we built this feature on your site, it's really cool. So, erm, want to
buy us?"

------
mtkd
A business model based 100% on a 3rd party social graph API is not a business
model.

I hope they can pivot the work they've done to something more standalone.

~~~
watty
Why do you think this? It's certainly riskier but there have been many
successful companies that start out relying heavily on a 3rd party APIs.

~~~
belorn
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.

~~~
gizzlon
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_

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

~~~
gizzlon
Found a blog-post with that quote in its context:

<http://unreasonable.is/opinion/entrepreneurs-are-scientists/>
<https://news.ycombinator.com/item?id=5042525>

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

~~~
floppydisk
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.

~~~
toyg
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.

~~~
floppydisk
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.

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

------
bartkappenburg
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).

------
ig1
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 ?

~~~
bad_user
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.

~~~
ig1
The thread isn't talking about public profiles, rather profiles that your user
account is privileged to access.

(Linkedin don't let you access public profiles via the API; but that's a
separate issue)

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

~~~
adrr
That would mean developers would have to build up a relationship and trust
before linkedin would give you an API key.

------
smoyer
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).

~~~
muyuu
> the other is trying to use me for something

Giving/finding you a job?

~~~
glesica
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.

~~~
muyuu
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.

~~~
glesica
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).

~~~
muyuu
For you nothing has changed then. This change doesn't benefit you in the
slightest.

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

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

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

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

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

~~~
camus
well contact the company and ask for a partnership,you cant get stuffs for
free forever.

~~~
alanctgardner2
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.

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

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

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

------
donretag
It is not the first time "betrayed" and "LinkedIn" were used in the posting on
HackerNews: <https://news.ycombinator.com/item?id=4148915>

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?

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

------
kamloops
Response from LinkedIn Dev Rel:
<https://developer.linkedin.com/comment/20907#comment-20907>

