Open API backlash, or just a blip?

[Carl Zetie]

I just read that LinkedIn is severely curtailing open access to its API, expressing concerns about poor quality apps and 3rd party competition to its own business model. In future it will mostly work with certified partners. (See, for example, http://venturebeat.com/2015/02/12/linkedin-revamps-its-developer-program-to-focus-on-partnerships-will-limit-its-apis-on-may-12-2015/)

This is the second major example of this that I've seen recently -- in November last year, Netflix did the same.

So are these the first signs of a growing trend, where companies decide that the costs of allowing open access exceed the value and innovation generated? Or just a couple of isolated examples, specific to these two companies and their business models?

And if it is a trend, is a secular one (i.e. a permanent change as companies better understand the value of APIs) or a cyclical one (i.e. a temporary rebound from irrational exuberance about the power of APIs)?

Opinions?

Carl Zetie
Not speaking on behalf of my employer.

[Jack Repenning]

On Feb 12, 2015, at 10:41 AM, Carl Zetie <carl....@gmail.com> wrote:

And if it is a trend, is a secular one (i.e. a permanent change as companies better understand the value of APIs) or a cyclical one (i.e. a temporary rebound from irrational exuberance about the power of APIs)?

How about "market correction" from irrational exuberance?

-- 
Jack Repenning
Repenni...@gmail.com

[darrel...@gmail.com]

Carl,

ESPN did the same thing http://developer.espn.com/blog/read/publicretirement

<soapbox>

I believe this is simply a recognition that producing an API with the attitude “if we expose our data, developers will do great things with it” is not economically scalable.

It’s my opinion that APIs should be built to address specific known scenarios for clients that are not web browsers.

If developers find creative ways of using that API to do things other than what you intended it to do, and you like what they are doing, then create more resources in your API to optimize that new scenario.  REST based systems enable “serendipitous re-use”.  Which, in other words, means the re-use was not planned.

The trend of API providers closing their APIs to the public will likely continue until developers realize that public APIs built by for-profit organizations should be built to deliver services not data.

</soapbox>

Darrel

Sent from Surface

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Jack Repenning]

On Feb 12, 2015, at 11:10 AM, <darrel...@gmail.com> <darrel...@gmail.com> wrote:

REST based systems enable “serendipitous re-use”.  Which, in other words, means the re-use was not planned.

Ah, now, _there_ is a great nuance!

-- 
Jack Repenning
Repenni...@gmail.com

[Mike Kelly]

Do RPC systems not enable serendipitous re-use?

[darrel...@gmail.com]

Mike,

I believe the focus on semantics in the message, the principle of least power, self-descriptive interactions, anonymous endpoints via hypermedia and publicly published message formats gives REST a significant advantage when it comes to producing something that “by coincidence” can be used for another purpose.  

Darrel

Sent from Surface

[Kijana Woodard]

+1 for rant.

It is counter to what I've seen as API project plans which amount to:

"Our [stakeholder] says we should have an API in time for [marketing driven date]. Make *everything* available via the API".

[Andrew Braae]

I'd say its just market forces.

Companies that are big enough and ugly enough to really dominate their spaces (LinkedIn definitely fits that description) get to call the shots.

APIs are one of the tools you use to get to that fortunate position - but once you're there, its time to pull up the drawbridge, dig out the moat a bit more, and pour boiling oil down on the heads of the wailing savages milling below.

The risks of course are that you leave yourself open to new entrants, who *do* play nicely with the developer community. But for a company like LinkedIn, where the network effect is enormously strong, that's probably not much of a risk - or at least, you'll have time to react and counter it before it becomes a significant threat.

Ironically the more (justifiably) exuberant we all become about the power of APIs, the more threatened encumbents might feel, and the more likely they become to want to lock down this stuff while they still can.

[Sam Ramji]

One of the things we should distinguish is the business model of a company that offers APIs.  When a company is trying to become relevant, break in to a market, or take over someone else's share, they use openness and interoperability.

Once they have plurality/majority, then we can know more about their business model & philosophy.  Are they a *developer platform* business that will grow through existence of many more apps and experiences, constantly growing and adding new users and data to their fold?  Or are they a closed platform that that sees more risk than reward in having third parties handle their users and data?

In most cases starting with an open API is a no-brainer as long as you're ready to support the developer engagement required.  Keeping an API open afterwards

There are many examples of this lifecycle (openness/interop to drive share and closing the border once they've won) - think Windows Networking in Win 3.1 to gain share vs. Windows SMB and WebDAV.  APIs are only one of the possible instantiations of the open/closed techniques for managing market share.

Sam Ramji | ramj...@gmail.com | +1-510-913-6495

--

[Kijana Woodard]

"Keeping an API open afterwards"

...

Did something get deleted?

[MattM]

+1

I agree this is more a sign of "mission accomplished" for the open API than seeing it as a flaw with the concept of open APIs.

What will be more troubling is if patent wars start impacting the open API space.  Let's hope we're not coming to the end of our Prague Spring...