Inopia

DomainsBot Domain Suggestion API for Developers

DomainsBot's new Domain suggestion API is now live - see here for the 3scale post and here for the developer portal.

Love this API from DomainsBot - since it's something intrinsically about the infrastructure of the web - there are tons of interesting things to do with it - brainstorming apps or apps which maybe extend things like domize. 

It's also a functionality which up until now has been mainly available to the big regitrars - and now can be used by anybody - again another thing which the Web and APIs should be about - making technology available to more niches and more interesting uses!

Survery of 1000 Latest APIs - Not just Tech Startups Anymore

Over at 3scale we put together a mini-survey of the latest 1000 APIs to get listed on programmable web and came up with some interesting results: 

• Only 17% of the APIs in the last 3 months came from what would be seen as Tech Startups.
• Most APIs come from small and medium companies - but the true long tail has yet to emerge.
• Business Models are becoming consolidated.
• Mobile is a major driver for APIs - although the number of APIs serving purely mobile was lower than expected, over 60% of all listed APIs targeted mobile in some way.

Looking forward to people's thoughts on the trends!

Welcome to the New 3scale!

Super happy we've just launched the new 3scale platform - a lot more feature to help people publish and manage great APIs. 

• The Team news: Welcome to the New 3scale – more power to you!
• The Press Release version: 3scale Democratizes APIs With New Free Self-Service API Management Infrastructure

A lot of new APIs in the pipeline.

 

My Data, Your Service - The thin red line of User Data Access APIs (LinkedIn shuts out BranchOut and Others)

Today's news that Linked in has shut off API access to Branch Out, BeKnown, Visible.Me and a number of others once again illustrates the tension between openning data and controlling monetization (in a similar way to Twitter's service changes recently). LinkedIn's reason for shutting down the access is primarily that these companies may be planning premium services which draw on LinkedIn's data (and potentially be a threat to LinkedIn's own monetisation plans).

 

It would be easy to say that this is a mistake on LinkedIn's part (because of the chilling effect it will almost certainly have on usage of the API) or that it's a no-brainer since other companies are getting (free) access to LinkedIn's prized asset. However, there is another factor to take into account which is neatly put in BranchOut's response to LinkedIn:

"we believe user data should be owned by the user, and that people should be allowed to share their data with the new services and contexts that provide the most utility."

While this may appear a little self serving, LinkedIn profiles are curated by the owners - LinkedIn is effectively the channel for these profiles to reach an audience. Although LinkedIn's terms of service may have all manner of restrictions within them and LinkedIn adds a large amount of value this still raises the question - is LinkedIn an effective channel for distribution of my profile information if it chooses to exclude a broad range of uses of it's API?

In other words, as a LinkedIn user one of my greatest utilities is that I can point people to my profile, have them find me and connect to keep in touch. This is not disimilar to Tweets on Twitter - the fact that Twitter pushes tweets to others by many channels is one of it's major value adds. Shuting off API access actually reduces that value and might make me seek alternatives. 

So how can this circle be squared? 

I'd argue that rather than shutting off access, LinkedIn should instead;

• Put a price on this access above a certain volume.
• Potentially even as a %age of revenue that value added services earn.
• Set rules such as "no caching" beyond a strict time limit to ensure data cannot be entirely replicated.
• See these services as a value add that will actually drive more users to add profiles to LinkedIn because distribution is wider.
• Set clear rules of engagement and not change them over time.

Might some of the services conflict with LinkedIn's own plans? Possibly, but as long as the price is right, this may even be a net gain. 

Facebook seems to be ahead of both LinkedIn and Twitter in this respect - it's 30/70% revenue split with Zynga and other games already ensures that there is always cashback for innovation that draws on it's platform.

BranchOut's statement that the loss of API Access is not a big deal ring a little hollow, however LinkedIn's actions certainly mean that people may begin to seek other places to host their professional profiles that allow more distribution.

 

 

 

 

 

Twitter client restrictions - bad for everybody (including Twitter)

It's a shame to see Twitter putting restrictions on client development via their API (more on GigaOm here). Obviously there's speculation as to what the business reasons might be - and the effect on the ecosystem - the move seems more than likely to be about controlling advertising real estate. The original post is here. 

The post makes some valid points about privacy and no doubt Twitters transition to the consumer mainstream has promted some of this, but it still seems to be unfortunate step.

Quote from Ryan Carver (via techcrunch): 

“We need to move to a less fragmented world, where every user can experience Twitter in a consistent way.  This is already happening organically – the number and market share of consumer client apps that are not owned or operated by Twitter has been shrinking,” he writes.

While that might make some sense - mostly likely because it gives Twitter closer control over the Ad real estate associated with the last milimetre to the customer - the twitter client is (almost) the new browser. No doubt this is a major driver - Facebooks monetisation prospects w.r.t. Twitter are simply so much greater simply because most people experience Facebook on almost entirely Facebook controlled real estate. 

Promoted tweets may be one way of advertising but they are annoying for users and interupt the application itself - whereas "out of band" ads on the side of a device attract less ire and can be omni-present. 

The question is - does this make good business sense? and does it signal bad news for "open API" strategies?

The twitter team are smart and no doubt a lot of thought has gone into this change and the perceived economic benefits must have outweighed the risks/negatives (developer anger, loss of innovation and goodwill). However firstly it seems unlikely that this means bad news for the open strategy (that's what got twitter here in the first place and this restricts one dimension of the APIs usage), further for a couple of reasons I think it's a bad move for twitter itself: 

• The loss of developer trust and confidence is not to be underestimated - and although this would seem not to affect "niche" clients for specialist devices/environments (which Twitter will never likely cover), people will be much less free with their innovation.
• The move defacto forces existing twitter clients to integrate other services in addition to twitter - when many might have been content to stay twitter only. 
• Twitter is betting on it's clients being one of the "goto" apps on any device going forward (alongside facebook, the email client, google search etc.) but this is by no means a given - particularly if the number of twitter client options drops. Over time there is a significant risk the facebook and others squeeze twitter into the background (particularly if they offer a channel to twitter).  

There seems to me to be no good reason why Twitter could not have continued to innovate heavily on it's own clients while giving everybody else free reign - if they were better, they'd get more audience. In fact it's precisely the biggest reach clients like TweetDeck which Twitter hasn't restricted. 

So given there is money to be made from ads and the last milimeter to the user, what should Twitter do other than what it has? In my view the right strategy would be to permit and even encourage client innovation but to add revenue share restrictions and requirements on openning up ad real-estate where possible. E.g. 

1. Allow development of twitter clients and use of the API.
2. Provide additional APIs for advertising feeds (potentially provided by 3rd party ad networks).
3. Require clients seeing any kind of volume to either carry ad inventory or pay pay volume fees. 

This is obviously harder to enforce than a blanket "ban", however Twitter's current approach is likely to lead to a "smaller" pie with more for twitter rather than a "larger pie" with more creativity in terms of business models. 

Hopefully in time the decision will get reversed and API innovation will flow once more!

 

 

What is an API? Your guide to the Internet Business (R)evolution

There's a new whitepaper up on the 3scale website - What is an API? Your guide to the Internet Business (R)evolution - definitely worth checking out. It's always tough to find the right metaphors to explain the value of APIs, so we've given it a shot. 

Dion Hinchcliffe summarizes it best:

“We are nearing the time when opening our supply chains across the Web isn’t just a good idea, it will be essential for competitive survival"

A nice timely reminder since just a couple of days ago programmableweb crossed 3000 APIs in their directory - impressive and more to come no doubt!

Facebook Rocks the Web

Facebook's F8 Keynote is a must watch (http://www.youtube.com/watch?v=CfLBZcEpG_I - four parts) for the future of the web. The announcements have already led to a lot of commentary - and alarm in some cases about what it might mean for the openness of the web. Check our Chris Messina's posts here and here for great commentary in the text and comments. It's even lead to to a nascent group to provide an alternative mechanism for some of Facebook's new features - openlike (see here for the homepage).

There are ton of things in Facebooks's announcements: 

• Simplyfing their own API (check out: http://graph.facebook.com/stevenwillmott -> that's me in JSON format, if you were authorised you could also get /events /updates, /whatever...) - couldn't be simpler. 
• A number of plugins for web sites that can overlay facebook's information from your profile correlated to the domain of the website your visiting on that site.
• New meta-data to mark up web pages with semantic information which facebook can use to understand people's relationship with the content on the page - Michael Bleigh hits the nail on the head when he calls it a private beta of the semantic web. 
• One particular plugin which provides a "like button" that allows a user to "like" content on any site using the plugin and signal that like back to facebook - either into the activity stream of the user or even to create a meaningful connection if some of the aforementioned meta-data is present (for example all of IMDB's movie web pages now include meta-data so if you "like" one of them it goes straight into your list of favorite movies on facebook).
• Facebook adopting openAuth (oAuth) as it's authentication standard - a great step for openAuth adoption.
• Some deeper integrations with selected web sites which allow deep access to the user profile even without logging in. 

Together with the strong growth of Facebook connect these announcements are really powerful - as Mark Zuckerberg puts it in the keynote - the web is becoming "social by default" and facebook is putting itself at the center of this people centric web (maybe a bit too central too quickly).

The changes mostly mean the potential for a better web - with more meta-data and more information available to all, as well as more gravitation to standards like openAuth, but there's clear concern that they facebook's march will lead to a single provider world for identity and social relationships. To me, the moves they made make huge business sense - and they are right to push the envelope - throwing down the gauntlet to others to innovate. However, there are several things which are worrying:

• While the meta-data formats are open and some data can be extracted back out of facebook, facebook is in effect making itself the curator of the link information - of what is connected to what - this is hugely powerful, important information (Yuval Kogman makes the same point). 
• While it's possible to get data back on a person by person basis (using open auth) the aggregate data isn't available unless Facebook chooses to release it, for some things such as friend links this makes sense since it's private data arguably, however for others such as "likes" it's not obvious that this wouldn't be better available publicly - the web would be a better place of "like" data was open (openlike would be a good thing if it succeeds).
• The moves will massively reinforce Facebooks lead as an "identity provider" - the place where users aggregate their lives on the web - not just on facebook but increasingly on all other web properties. Healthier would be if multiple such providers large and small could co-exist.

Obviously many social sites walk this thin line between retaining information as competitive advantage and for user privacy reasons and exposing it to add to the information on the web. The more of the "edges" of the graph that facebook keeps private the worse for the web (and the more self-serving for facebook) these announcement's are. 

I suspect that F8 next year or the year after could see the announcement of the opening of not only READ APIs into facebook but also more and more WRITE APIs which allow everything from friending to user creation. Facebook.com will become just one of the many consumers of the facebook API. This will allow third parties to build essentially parallel facebook.com's with different interfaces. While Facebook might now want to do this for brand control reasons, it makes total sense in the long run. 

This might in turn be of huge benefit to the web since the APIs in turn might become standardized and adopted by other identity / profile providers - the social graph might open right back out again if it becomes possible to "friend" across providers. 

Open APIs and Open Standards

John Borthwick has been advising companies for a while now to build APIs that mimic the Twitter API. His reasoning is that if your API look and feels similar to the Twitter API then third party developers will have an easier time adopting it and building to it. Makes sense to me.

via www.avc.com

There was a great thread on AVC this week on the impact of twitter's API being specs being reused by others (check out the lengthy comments thread as well).  I think this is the beginning of a trend and we'll see a lot more of it in different types of apps:

• APIs for different content types are likely to come in similar forms (there just aren't that many ways to build a half-way efficient blogging API).
• Familiarity helps adoption and reduces friction for everybody 
• Although different services often have unique features there's likely to be a "common core"

Actual standardization (W3C et. al.) is probably not on the cards right now but some convergence looks inevitable and beneficial to all. There are two interesting dimensions to look at: 

• Convergence by application/content type: where you could see standard patterns emerging to for video, audio, messaging, blog posting, news etc. 
• Convergence by individual type of operation: e.g. user account creation, payment, creation of relationships (friend, follow...), search etc.

In the second case building blocks can be recompiled into complete APIs. 

I hope we see more moves in this direction since it will reduce friction in API provision and usage - making it easier for everybody to focus on the business of building great apps with third party APIs. 

Predictions for Web APIs in 2009

As you may have noticed - a little less blogging over the last couple of months than I'd hoped. We've had an amazing year at 3scale (new offices, great new team members, techcrunch50, product launch, leweb and some great early customers - thanks most of all to them), but it's also been amazingly busy, so tough to get back to the blog.

Still, a bit of time to reflect over the holidays makes it easier to get back to posting and since the end of the year is the time for whacky, way off predictions about the year to follow (yep - of course they're likely to be way off) I thought it would be fun to do the same.

Probably the thing that strikes me most about what we've done at 3scale is the sheer number of companies we've talked to who have APIs on their roadmaps and the great things they plan to do with them. It really seems like we're seeing the tip of Iceberg right now and I think 2009 will be the year were we see a lot of great new stuff. Programmable Web's index has just been growing month on month and the APIs have been exposing more and more interesting functionality. On 3scale's platform we've also seen some very neat services from general utility like ISBNdb's Book information API to the super niche like Dilog's Dive Record API - check them out.

So from that - what will 2009 hold? I can't promise anything as good as ReadWriteWeb or Fast Company's predictions but here's a shot for the API world - be great to hear what other people think. In no particular order:

1) ProgrammableWeb's directory will break 2,500 APIs in total - up from a bit under 1100 at the end of 2008.

2) There'll be a significant increase in the number of services which come with commercial terms of service - not just "use at your own risk and for non-commercial purposes", but serious business APIs.

3) High quality data providers who already provide high quality API based services to big ticket clients will increasingly set them free and release versions at lower ticket prices for a broader range of customers.

4) At least one of the TC50 2009 companies will be a pure play API company - a company which effectively has no usable functionality provided via it's human accessible web pages, but only a powerful API.

5) It will continue to get easier and easier to publish APIs - REST and SOAP are already supported in most major web languages, but we'll see more and more modules for packages like Drupal as well. The vast majority of Web APIs will still be lightweight HTTP/XML, REST, Javascript etc. - rather than heavier SOAP variants.

6) oAuth will continue to make inroads and become the defacto way of establishing remote data access (here's hoping anyway!).

7) openID will grow too - but big players like Google, Yahoo etc. will all still resist welcoming incoming openIDs from other services for their own systems (but they may crack in 2010).

8) Web APIs will make it onto the Gartner hype cycle for emerging technologies in the the technology trigger phase.

9) SOA technologies more common in Intranets will start to pop up in Infrastructure for Web APIs with SOAP standards like WS-Addressing, WS-Security, governance tools and other bits and bobs showing up in lightweight versions.

and, finally

10) (the most obvious) - Amazon will continue to be king of the hill in the Web Services infrastructure space. They've done an amazing Job in 2008 and it's going to be hard to match them.

Hard to say how they'll play out but in any case it will be interesting to see - look forward to following events this year. If you've got the prediction bug there are plenty of people smarter and more entertaining than me making them - check out Dion Hinchcliffe's list here.

No doubt everybody predicting will have to eat some humble pie come this time 2010 - and if you're up on your Black Swan theory you'll know that the big stuff wont be on anybody's list!

ProgrammableWeb hits 900 APIs

ProgrammableWeb just reached 900 APIs listed in it's directory - this is an amazing number since there were just 600 on Jan 14th this year - there's also been a slight dip in growth rate over the summer - with people probably storing up their launches for the fall, so I'd bet on being past 1000 by mid October by the latest (hopefully 3scale will help make that happen!). It's hard to over-estimate how important this is as a trend - programmable web is the reference site for APIs and so provides an important benchmark.

The fact that we're on course to double the number of APIs in what might be just a little over 12 months is incredible. Moores law (18 month doubling) would already be impressive if it was happening - but API deployment is a parallelisable process - not a serial one like chip design - so in principle API deployment could explode even faster.

Look for API "enablers" getting built into standard web tools (from drupal to systems like iceberg and others) - this was the secret sauce of RSS) and then I bet we'll see spectacular growth rates.

Great job to programmableweb as well for tracking all of this!