3rd Party APIs - Can’t Live With or Without Them
There has been renewed discussions today on the use of 3rd party API after Facebook announced that it was going to shut down the Face.com face-recognition API. The Next Web featured an article covering the news here and Hacker News and Twitter are hot with developer reactions. Back in February, we had to deal with a very similar situation at Picdish when SimpleGeo announced that its spatial database service was being shut down, following an acquisition by Urban Airship. I need to mention that spatial database is core to Picdish’s ability to capture unified and real-time experiences based on location. Our own experience (and initial panic!) led us to put a lot of thought into the use of 3rd party APIs and I wanted to share some of the conclusions.
If there is demand, there will always be a solution: As it turns out, we were not the only ones who needed a spatial database like the one provided by SimpleGeo and Parse jumped on the opportunity and delivered a very effective solution and a smooth transition. I was just following on Hacker News that an alternative to Face.com is already being built by Stephen Balaban.
Be innovative in your own technology, not how you use 3rd party services: There are so many areas to get creative in when developing your core technology. You should absolutely own the innovation in terms of knowledge and implementation. But when it comes to the use of 3rd party services, you want to use it in the most generic way it was designed for. This will ensure that when things go wrong, you can more easily switch to an alternative and as mentioned above, you are not going to be alone.
Risks are there whether API is free or not: Several people are of the opinion that something free cannot last long. I disagree because some of the best tools and solutions I use and have done so for a long period of time are in fact free. And SimpleGeo is a good example that shows that your risks are not mitigated because the vendor has a defined business model because acquisitions and change of focus can happen to anyone.
Benefit outweighs the risks: There will always be a risk in having dependencies on external services. But, this is what specialization is all about and it is here to stay. If the risks are understood and managed, the benefits are tremendous. 3rd party services allow us not just to launch to market faster but more importantly, focus on the innovation and unique value that we offer to our customers.
[Photo Credit: Geek and Poke]
Should Foursquare Restrict API Like Twitter?
There has a been lot of discussions lately (Dalton Caldwell: What Twitter could have been and Andre Torrez: Twitter Hindsight) on Twitter’s recent moves to restrict it’s API. I also just read a post by Semil Shah Mapping out Foursquare’s Final Check-in where he points out “Foursquare has been partly disrupted by applications that grab location passively like (Instagram)” and it got me thinking about the impact its API is having on its monetization strategy.
Let me start by saying that we use Foursquare API in our app Picdish and like thousands of developers, we are very grateful for its amazing service. I am sure users of these apps contributed to the significant growth of Foursquare check-ins and the stats are great for Foursquare to communicate to venues and to create a high valuation for its own business. Slowly but surely, greater portion of the users will use the “other” apps because of the value added service such as sharing photos, capturing experiences, finding friends and not use the actual Foursquare app where they have a chance of monetizing their service. Foursquare will become a Google Maps like solution that no one would want to pay for.
I am of the opinion those components of the API, whether its Foursquare or Twitter, that ensure the service can be monetized on its own platform should always be closed. I do believe that these services would have been better off to start that way rather than change course so late in the game. Foursquare may still have a chance by building a monetization scheme on its API like Urban Airship because it offers a clear value to app developers.
- What Twitter’s API Announcement Could Have Said (dashes.com)
- Changes coming in Version 1.1 of the Twitter API (dev.twitter.com)
- Interpreting some of Twitter’s API changes (marco.org)
