App developers are getting understandably upset that they are starting to regularly experience the API equivalent of what one might politely call a "tease."
As a case in point, Soundcloud recently started to clamp down on third-party developers who hook into its service to offer audio as part of their app experience. The changes will mean an app's users will get a total of 15,000 plays per day. Collectively. That means if an app has, say, 10,000 users, they will get one piece of audio via Soundcloud a day. That's it.
It should be pointed out here that Soundcloud's terms and conditions had already warned against going overboard with its content, but the company's blog post refers to its decision as an act against "creator abuse." It emphasized that it was only a few bad apples spoiling the bunch, and that they had all been contacted via email. Then came the attempt to placate:
"This change is an opportunity for us to refocus our efforts and renew our commitment to developers. You're an integral part of the SoundCloud community, and we look forward to seeing what you build next."
I can no longer see comments below this post, but an earlier report on BusinessInsider suggested there was some major unhappiness. And you can see why.
Of course, developers must respect the T&Cs of other firm's APIs. But like Netflix, Twitter (and probably Uber before too long), there is an element here that reminds me of Lucy offering a football to Charlie Brown, only to pull it away as he went running towards it. Charlie Brown never seemed to learn his lesson. The question is, will app developers?
As enticing as it may seem to make use of APIs from highly popular mobile services, app developers need to be increasingly wary of what they're getting into, and managing their own risks before they face a fallout in terms of their app's performance. This is probably easier said than done, but a few thoughts:
- Consider APIs as a tactic in launching and growing engagement in your app, rather than as a long-term part of the experience. You don't own the intellectual property, and you never know when policies can change.
- Keep your options open by looking for two or even three complementary APIs that offer similar functionality. If those alternatives don't exist, you may be locking yourself into a monopoly you can't afford to lose.
- Consider your exit strategy before you deploy an API. Not only think about how you might change the app experience to survive without the API, but how can you communicate the changes to your users with minimal disruption?
Ultimately some APIs may always be a roll of the dice. If developers choose to gamble, though, they may look at recent policy switches and wonder whether the odds will ever be in their favor. --Shane