Just as you wouldn’t build a house without a door, you wouldn’t launch a new web platform or mobile service without an API. Organizations have now strategically recognized the importance of APIs as a means of giving developers programmatic access. By giving developers access to new data or functionality, organizations get a way to extend reach and revenue.
Developers extend platforms that make them deeper integrated and more firmly placed within an IT ecosystem, and they unlock value from big data by putting it to work inside their mobile app or website. The ROI on APIs will depend on the volume and quality of developers engaging with it, making it very important to cultivate high value developers. Not all developers are equal. An ecosystem of two may be more valuable to an API publisher than an ecosystem of 100 if those two build something that truly drives reach and revenue.
For API publishers, acquiring developers therefore has to be tempered with the goal of ensuring that they are active, engaged and effective. Having more developers often won’t mean more money or reach. Drive-by developers may toy with your API, but will they create sustained value for you? Renting developers may increase your developer count, but owning your developer will get you ROI. Multiple metrics can be used to measure the success of an API. While the “number of registered developers” is one such metric, the true measurements of success must measure the business value that specific API calls deliver.
Several middleman services promote their ability to drive developers to API publishers with the catch that they – not the API publisher – own these developer relationships. Renting may juice your developer count, but if the middleman services own the developer, what assurance do you as the publisher have that the developer will be active, engaged or effective? How do you build a relationship with someone that never asked to be your date?
This is why API registration numbers alone don’t matter. A middle-man can tout their thousands of “Key Wielding” developers, but an API publisher can’t expect to benefit from developer relationships it does not own. The most you can hope for in such a case is to borrow them for a little while knowing all along that if you break your relationship with the middleman, the developer community goes with them.
Having helped a number of organizations publish APIs, my advice is to always own your developer and work to strengthen those relationships. Don’t buy into the promise of access to hordes of developers. Remember that the only developers that matter are the ones engaged directly with you, because those are the ones that care about your API. Developers engage within a mutually beneficial relationship, which is the essential ingredient for growing a flourishing business ecosystem. Once a developer’s livelihood depends upon access to an API, that API has achieved becoming an ecosystem. An API provider makes this relationship compelling by showing the financial rewards, either as direct revenue from using the API, or from deriving benefits such as consulting work to provide platform integration.
That said, make it easy for high-value developers to access your APIs. For example, there are millions of current, high-quality GitHub developers waiting for the right project. Giving engaged GitHub developers the ability to use their credentials to access your APIs is smart, but be sure to apply technology that enables onboarding and Single Sign-On from GitHub and other deep pools of active, engaged developers. And be careful not to get caught up in the developer equivalent of a feel-good payday loan. You will pay a high price in the long run.
About the Author
Dimitri Sirota is the co-founder and Chief Strategy Officer at Layer 7 Technologies. An accomplished entrepreneur and a pioneer in the security field, he previously co-created VPN provider eTunnels Inc. and worked in senior product marketing and channel development roles at AT&T and Telus.
Latest posts by Guest Author (see all)
- Guest Post: ‘Virtualization 2.0′ is your on-ramp to the cloud - July 27, 2016
- To unlock Big Data’s potential, learn to use fast data - August 17, 2015
- 5 reasons Google+ failed: One power user’s observations - August 3, 2015