It’s time to hold companies to a higher standard when it comes to APIs. As software “eats the world,” it seems like it’s not enough for a business to just serve its customers and hopefully make a profit, they also have to be “platforms” — and, as any developer would respond, these days you just can’t be a platform without an API.Building APIs has never been easier. If you don’t have in-house developers who are API-savvy, there are a lot of great open-source frameworks to help with getting the code right — and there’s no shortage of vendors happy to sell you the tools you need (including my employer, Apigee, and others such as TIBCO, Computer Associates and 3Scale).
The strategy is simple enough: build API, launch API, run hackathons, get free apps and profit. Launching an API program and adding a “platform strategy’’ slide to your investor deck seems like a no-brainer, but the history of API programs reads like a travelogue on the good intentions highway.
There are many reasons to build an API, and even more reasons to use one. This is not an article about enterprise topics like service-oriented architecture or the role of microservices — we’ll leave that for another day.
This is about the API economy. It’s about how two companies can work together to create more value than either of them could independently. It’s about the great technology industry tradition of platforms and applications — the fundamental dynamics that allowed Microsoft to build its dominant position in the 1980s and early 1990s, and what made Apple’s App Store such a powerful model. There are plenty of variants of this; for instance, Google turning the web into its platform when it taught publishers to SEO then paid them back with AdSense.
The web API is the successor to this, and it’s been a long, bumpy road. Long before AWS, Amazon’s original platform was its retail business and their first API was the Amazon Product API that let you build storefronts and apps using Amazon’s deep product catalog. Maybe it was the materialistic mindset of the retail business, but Amazon didn’t delude themselves that developers would be writing apps to use these APIs to win a prize at a hackathon.
Amazon’s Associates Program let you profit from the sales you drove to Amazon. Likewise, eBay took the same approach with revenue sharing. Developers were incented to build and maintain quality apps, the platforms were incented to provide quality APIs. There are lots of business models for APIs — you don’t always have to be cutting checks like these companies chose to — but this all-too-uncommon notion of “win/win’’ was baked into these programs from the beginning.
In many ways, the current situation in APIs can be blamed on Twitter.
Twitter’s early strategy let developers take 100 percent of the immediate revenues (in the form of app sales) in return for Twitter taking 100 percent of the valuation opportunities (during the Twitter API heyday, they really needed traffic and users more than anything else). Once a future as a public company was in the cards, they needed all the monetization opportunities back from the developers in order to eke out every last dime of ad potential.
We’re just now waking up to the idea that you probably should never trust an API from a company that intends to make most of their money from advertising, even if they’re charging you for those APIs (see Parse). The end result, though, is that anyone looking to either provide an API or build on top of one is trying to avoid either ending up the bad guy who pulls the rug out from under developers or the victim of an orphaned API program.
Sadly, we see two things today when it comes to APIs: either the closed “partner-only’’ API model, where a company announces with some fanfare that it now has APIs, but you can’t use them unless you’re very important, or the mildly less-depressing situation where a company launches a technically great API, but does so with no developer business model.
We see both of these in the ridesharing world at the moment — Lyft’s API was partner-only until very recently, while their competitor Uber had launched a technically great API, but with an unrealistic monetization strategy for developers that it appears Lyft is now following, as well.
The closed-API model ends up missing the big opportunities because, unlike the “Biz Dev 2.0’’ approach of APIs, it relies on hand-crafted partnerships that inevitably try to pick winners and losers before a line of code has been written by quickly becoming about things like exclusivity and co-marketing.
In many ways, not thinking through API monetization is even worse, because it doesn’t provide sustainable incentives and rewards to either the API provider, the developer or the user. Uber and Lyft, for example, will both pay the developer a bounty for every user a developer signs up, but neither service will share any revenue from the rides booked.
A rational developer who pursues this program is going to focus on drive-by signups, and may not find incentive for supporting users beyond that point. While both companies have clearly identified user acquisition as their biggest priority, this mechanism may well have unintended consequences.
The best example of how this type of model plays out in the long term is the Yahoo Toolbar, which uses a similar reward system, with the end result being that your mom’s PC inevitably ends up with five or six toolbars installed by unscrupulous ad networks looking to cash in on the referral fees. Developers will inevitably game any monetization system; you need to make sure their incentives are aligned with delivering a great experience to your users first and foremost.
Uber’s new Trip Experiences API is a much better option because it lets developers pursue in-ride and post-ride monetization opportunities. One thing I’d recommend to Uber is to make sure they’re figuring out the best way to manage the ecosystem of developers who build upon this, much as Facebook did with their developer program.
Facebook knew from the outset that developers building Facebook apps needed monetization mechanisms and made clear to developers the rules for advertising inside apps. The last thing you want as a platform provider is to get in a land grab with your own developers.
So, who’s doing a great job with API programs that respect developer economics? In addition to some of the examples already mentioned, I’d point to Walgreen’s successful Photo Prints API as a great example of a traditional business that has embraced the API economy. The photo app category is a crowded space, with lots of developers finding new ways to make it easier to take and edit great photos. Walgreens’ API gives developers a way to monetize their apps by earning commissions on each photo printed to a local Walgreens store location.
Another great example is Slack, which is spawning an entire ecosystem of chat bots and integrated chat applications building on the powerful Slack API. Slack understands that developers need a viable business model, and lays out from the get-go what’s allowed and what’s not when it comes to charging for apps and displaying advertising, allowing developers to enhance the Slack experience in a way that’s great for the users while making sure there’s an opportunity for developers to build sustainable businesses around this.
Doing an API right isn’t very hard. Doing an API program right shouldn’t be that hard. If you’re going to open up an API for developers, ask what’s in it for them. It’s easy to host a hackathon and get a bunch of cool demos, but if the goal is to do something more, you need to figure out how to make it worth everyone’s while.
Developers are getting smarter about these things and, while they may come for the free lunch at the hackathon, they know there’s no such thing as a free API.
Comments
Post a Comment