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!

Services, Apps and the API Powered Web

Last week I had the opportunity to do a series of talks on fun subjects for the open informatics program at CTU in Prague. It was a good opportunity to reflect on some of the trends different people in the API, Web Services, Apps world are picking up, so for one of the talks I tried to pull together some thoughts on APIs, Apps and the Web (embedded below).

There are some great presentation on this subject already out there (check out Sam Ramji's Darwin's Finches for example), but as more APIs emerge it's also becoming clearer just how fast this innovation is happening. 

I've also included some of the API business model material we use with our customers are 3scale - hopefully that provides an insight on what people are doing with APIs.

Services, Apps and the API Powered Web

Many thanks again to the team at CTU for the invitation and the chance to spend some time deep diving into these topics!

API First, Mobile Second, Web Third

Fred Wilson wrote a post about how companies build their mobile presence first, and their web presence second, showing a shift in how people use the internet.

I would probably modify this idea, with the following:

API First, Mobile Second, Web Third

The most important consumer of your product in this age is not necessarily a person, but a machine.

via www.switzer.org

Great post by Scott Switzer and wholeheartedly agree - an API is becoming genuinely essential to launching a online company - and for companies starting from scratch, the API should be first on the drawing board. 

What Foursquare should do to compete with Facebook - "Go Public"

I'm sure the foursquare team has their strategy well in hand after the announcement of Facebook places and maybe this is way off base anyway, but I was suprised to see little real press analysis on what paths they might take (instead is was mainly doom and gloom - (TNW, CNN)). But it seems to me there are clear paths and one of the them could be to yank the steering wheel to one side and "Go Public" (not in the IPO sense - in the social network model sense!). 

To explain this, one of the things that always struck me as the *key* difference between twitter and facebook is: twitter is public broadcast, facebook is group narrowcast. I.e. twitter has asymmetric relations, facebooks are symmetric.

So facebook (although there is a public mode) requires both parties to friend.

This makes twitter and facebook fundamentally different - and I think means that twitter can and will continue to grow very strongly. Because of the type of data shared on facebook it's simply difficult for them to push asymetric relationships.

On location I could see the same thing happening. The "normal" way of thinking about location is "I share with my friends" - symmetric relationships. This also makes sense for security in some sense.

So it seems to me that if foursquare is able to push it's asymetric relationships - i.e. anybody can follow anyone for location information:

• it would make a big change to the service 
• but it would give it a much different utility to facebook.

broadcasting location publically has the chance to create chance meetings, to interact with locations / brands in a way narrowcasting to friends doesn't. Also facebook is unlikely to open the privacy settings much (or make the defaults public) because it is already embroilled in various privacy issues.

An example would be, people checking into a bar in Barcelona - they might post on facebook so their friends know, but they might also post on foursquare so "everybody" knows (basically this is equivalent to posting "I'm at Harry's Bar in Barcelona" on Twitter). Facebook places may allow you to do this also but the focus is different and theres a big risk of confusion between public and private settings. 

Basically a foursquare which focused on a twitter like public broadcast of location could provide a much different platform to facebook places and become the basis of different types of location aware services. You may post there "less" but you'll post there when there is some real utility to doing so like meeting new people in a bar, collecting coupons & points, getting timely information etc. 

P ≠ NP-- Greg and Kat’s blog

P ≠ NP

August 7th, 2010, 8:21 pm UTC by Greg

An email I was recently forwarded (a couple of steps removed) from Vinay Deolalikar from HP Labs:

Dear Fellow Researchers,

I am pleased to announce a proof that P is not equal to NP, which is attached in 10pt and 12pt fonts.

The proof required the piecing together of principles from multiple areas within mathematics. The major effort in constructing this proof was uncovering a chain of conceptual links between various fields and viewing them through a common lens. Second to this were the technical hurdles faced at each stage in the proof.

This work builds upon fundamental contributions many esteemed researchers have made to their fields. In the presentation of this paper, it was my intention to provide the reader with an understanding of the global framework for this proof. Technical and computational details within chapters were minimized as much as possible.

This work was pursued independently of my duties as a HP Labs researcher, and without the knowledge of others. I made several unsuccessful attempts these past two years trying other combinations of ideas before I began this work.

Comments and suggestions for improvements to the paper are highly welcomed.

The paper is about 100 pages, and looks serious (but being a decade away from last thinking about complexity, I am unable to give any more useful evaluation than that). I’ll refrain from posting the paper itself.

Deciding P ≠ NP is a Millennium Prize Problem and I don’t think I’d get much argument to say it is the biggest open problem in computing science.

Update: I see someone else has uploaded the paper. I should point out that in the email thread I got, Stephen Cook said “This appears to be a relatively serious claim to have solved P vs NP.

via gregbaker.ca

Would be stunning if the proof is validated. Although it wont radically alter out day to day as much as a P=NP result would have (Q mass panic since every encryption system out there would be breakable - and vast amounts of computational problems would become soluble!), it's still a big deal.

The synopsis of the proof sounds intuitive though I have no idea on many of the details. I like the idea of interconnectedness at great distance in the solution space causing the breakdown in linear algorithms. Seems like the right kind of idea that might also help people figure out if quantum computing can ever bridge this gap and how it might do so.