Should your company offer an API for outside developers to build on? Should you engage in one of the fast growing developer platforms or with another company’s API? There’s a world of options opening up to leverage cross-site functionality and data exchange, but there are also some serious questions to ask about this emerging paradigm. [img: Flickr Mashups by David Wilkinson]
We discussed some of the common concerns about platforms and APIs with a circle of industry experts, executives and engineers last week and thought we’d share that discussion with you.
We asked questions regarding the efficacy and traction you can get from engaging with platforms and APIs, the investments required and whether the kinds of things being built in these environments are even serious technology.
You may find some answers to questions your company has in this conversation, you may find a useful articulation of thoughts you’ve already considered or you may feel inspired to take some things into consideration that you had not before.
Framing the Conversation
The technology press and enthusiastic geeks are thrilled whenever a new API is announced – and tech-savvy marketers circle anything that smells like it could be a big Platform. Offering an API is a great way to make developer friends and developing for a large Platform has the potential to bring your work to a huge audience.
Web apps consultant Dr. Baher Al Hakim points to the poster-child success stories so far. “Google Maps and Twitter are examples of great services with documented APIs which encouraged developers to use them,” Al Hakim said. “That contributed in turn to attracting more users and increasing these services’ popularity through organic growth.” [img. right: platform share of last two weeks’ new mashups in directory at Programmable Web]
Things get more complicated once the rubber hits the road. Esther Schindler, senior online editor at CXO Media, explained some of those complicating factors.
“Developer APIs can have all sorts of complications and side-effects,” she said. She emphasized that there has to be a win in terms of time savings or product capability in order for the investment of time to be worthwhile.
“That said, it often is a good idea,” says Schindler. “This kind of development can extend your own applications with relatively little of the work being done in-house and can give you access to whole new markets.”
Schindler summarizes the downsides as all-too-often poor documentation and a risky degree of reliance on another vendor’s product or service.
For detailed statistics regarding these types of questions, Schindler recommended checking out the Evans Data Corporation.
Valdes says that “a platform is a promise: of functionality, robustness, serviceability. But also longevity and, increasingly, ability to support an ecosystem.”
Saad, on the other hand, offers our first dark cloud. Though he’s spearheading a major international effort to advance standards in APIs and Platforms, he’s also a man with his feet on the ground. “Developer networks may,” he pointed out, “divert developers from building higher value, higher utility a-class apps on the ultimate platform.” Saad returns later in the conversation to cause more trouble. Thanks for livening things up, Chris!
If We Build It, Will Anyone Come?
A very logical question to consider is whether anyone would use your API if your company decides to offer one.
“Nothing says someone will develop with an API just because you open it,” said Paul Miller, who interviews leading developers on the blog of the semantic platform Talis and blogs about the semantic web at ZDNet. “You need the infrastructure, community and technical support around it. [For developers] the API has to do something you want, easier or better than you could it yourself, or bring some other benefits on the side.”
Beyond technical support and quality infrastructure, Chris Saad from DataPortability.org said that “if the network has no users, then it will have no developers…the reason dev platforms attract developers is because of their promise of distribution.”
On face that makes sense, but couldn’t some really compelling functionality be sufficient motivation for developers to engage someplace new that doesn’t have a substantial audience?
I asked others if they agreed with Saad and their responses were interesting. He certainly isn’t alone in this belief.
Kee Hinckley, CEO of stealth lifestreaming startup Somewhere.com said that if your platform doesn’t have a large number of users then it had “better have a real good growth plan to sell,” and some very cool potential apps, if you want him as a developer to spend resources growing dependent on your success.
Sean Ammirati, VP of Business Development at media recommendation engine mSpoke said, “I completely agree with Chris Saad on this one. However, the inverse is not necessarily true, that APIs + users equal a good platform.”
Dissenting thoughts came from several other participants, including Paul Miller from the 40 year old platform Talis. Miller said he believes that developers would be attracted to “clearly recognized potential.”
Developer consultant Nate Ritter said flatly that Saad’s argument was not accurate. “I believe the value of the API is what drives usage,” Ritter said, “not the users or network – at least [that’s the case] for innovators.”
Mashup developer Taylor McKnight explained his perspective.
“I disagree with Chris Saad, I think the reason myself (and others around me) chose to develop with an API is simply a time-to-release issue. It’s simply faster to grab somebody else’s event data they’ve collected or tags used to describe an artist [for McKnight’s PodBop, for example]. Why reinvent the wheel when there are wheels available for the taking? Now this may often correlate with API providers having huge networks of users but that is not required. They may have just done most of the data gathering themselves.”
Speaking as an exec for a company employing such an approach, Charlie Davidson, CEO of enterprise feed software Attensa put it this way: “We want to open APIs because we think we have value to add and people can add value to us, it has nothing to do with number of users. It’s about confidence in the value that you add and its ability to attract developers.”
Oren Michels, of API management service Mashery, put this discussion into the context of his experience. Mashery has helped launch and manage more than two dozen developer programs for companies large and small.
“One opens an API as a business development initiative, and so evaluating its success should be based on how it performs in that context. Our friends at Reuters took a look at their Calais API success after the first thirty days in this post – the good news is that they had over 1100 developers sign up, about 25% of whom are actively using the API. That is good. The bad news is that the specific app they were hoping for – a WordPress plugin – is still not built, even with a $5,000 bounty available. Shows that you can’t predict how people will use your API, which is good news, but can be disappointing too.
“Bottom line – if you start a biz dev initiative, API or otherwise, you need to do it right. Communication. Documentation. A path to success., so if you build something great it will scale and you can benefit from it. Support. Something worth using/building on. If you have these things, it’s a great idea, and it will work. If you don’t, it’s a lousy idea, and the fact that it is an API won’t save it.
“People use the term ‘developers’ to identify those who build new apps on APIs. Yes, there are of course developers building these. But an open, standards-based API allows companies to build, deploy and manage partnerships easily and economically. We launched Freewebs’s API with only a few dozen keys issued, but if you were to look at the companies registered for those keys, you would recognize all of their names. And as they add more, the new partners don’t need to be ‘integrated’ by the engineering team; they just need to get a developer key and review the documentation. So it’s not just random developers coming in. The API is the frictionless means for any two web-based services to interact and share data and capabilities.”
The Investment Required
Some of the first concerns that comes up when an API is suggested are that it could take more time to support than it’s worth and that, secretly perhaps, companies are wary of inviting outside developers into a messy code base they are embarrassed about.
Kee Hinckley, of Somewhere.com, says that “an API is going to enforce structure on your code and open up internal opportunities.”
That’s an optimistic perspective that might work out well for some companies, but let’s be realistic.
Nick Dynice, a member of the TechDirt Insight Community says it’s simply a matter of maintaining your relevance in the future. “I think web apps without APIs will be irrelevant,” he says.
[img: Intel’s MashMaker, photo by Josh Bancroft]
These ones seem like unresolved issues. Unless your application was built with an API in mind, and perhaps even then, supporting one will require an investment of time.
Peat Bakke, a scalability consultant to startups, said of these investments: “An API is like any other business service. If people are screaming for it, there’s probably a way to make it worth your while.”
That could be users screaming for an API or it could be a group of developers – but I would suggest that even if there isn’t anyone asking for one yet, it could be worth your while to explore the potential demand.
Are APIs for Serious Development?
What kinds of development can occur on top of APIs and as part of developer platforms? Is this your big chance to get your users throwing zombies at each other and finding out which Disney Princess they are most like, as is the case on Facebook? Are API-built apps quality apps?
Esther Schindler, of CXO Media, said in response to those questions that “ANY development can be lightweight crap. Using APIs isn’t really part of that issue. It’s all a question of good design.”
Big platforms may be different, though. Data Portability Working Group founder Chris Saad argues that while “web APIs can be part of an A-class app… APIs inside a [larger site’s] container often limit scope.” Though any API has limits set on it, it has seemed so far that the social network developer platforms have been particularly restrictive.
Web developer Jason Wehmhoener said that a lot of possibilities open up if you can “build your own product on your own API.” He called APIs useful, compared to core development (which is essential), and emphasized that these two sides of development can support each other.
Raju Vegesna, of web office suite Zoho, brought some cynicism to the discussion of developer platforms with these thoughts.
“We cannot call the current trend of developing on APIs as ‘Software Development’. It is more a matter of Scripting. I think the current platforms are used by power users. Not professional programmers. Based on the number of platforms out there, we might get into the different Integrated Development Environments situation yet gain, but worse.”
Speaking up for the power user, anonymous blogger and engineer Engtech of
pointed out that “developer APIs to websites are almost always unusable or slower than building your own web scraper for that site.” Three cheers for
, I say!
A man very familiar with Dapper, power users and serious engineers is Aaron Fulkerson, founding CEO of the respected and rapidly proliferating wiki platform MindTouch. Fulkerson took offense at the argument that APIs equal crap.
“Our platform is an amalgamation of web services, it’s an API! When employing a RESTful architecture like we do at MindTouch you’re going to be building entirely on REST services.”
MindTouch just published an overview of its technology that explains well the differences between traditional software development and the way the MindTouch/DekiWiki ecosystem works.
That kind of approach probably works best for MindTouch because it is integral to the company’s foundation. Developers may be less excited about working with a market full of APIs from companies less wedded to open standards and mashups.
The Importance of Standards
I asked Aaron Levie, CEO of online storage service and platform Box.net, what he thought of these issues. He emphasized the importance of standards, a theme that runs through the thoughts of many of the biggest API advocates above. “From a developers point of view,” he told me, “I find data portability more interesting than mashups.”
“There are dozens of proprietary application platforms that would love for you to build a widget or mashup on their service, but without standards, how do you prioritize which platforms to build on? We designed OpenBox [the Box.net platform] in a style which prevents even more platform wars. Third party services can integrate their API parameters into a Box.net developer interface, enabling users to move data between our respective applications on their own terms. While we recognize this won’t work for all platforms out there, we think that this model represents significant advantages for developers and users.
Conclusions and Resources
I’m hesitant to summarize the many diverse thoughts above but I do hope that the problems discussed can be worked out. The web of the near-term future isn’t about pages any more. It’s about data, flying around, hopefully under the control of users, and offering a world of possibilities that few of us could have imagined just a few years ago. Now seems like a good time for every company and service provider online to take a close look at the thoughts our guests above have shared.
Three good resources for remaining involved in this discussion are below. Thanks for reading.
“How to Make Developers Love Your API” a very good presentation by Dave McClure, former key player at the PayPal developer program. McClure gave this talk at last year’s Business of APIs Conference.
Programmable Web is the go-to source for learning about APIs as they are made available and the things people build on top of them.
The RWW Toolkit for 2008 includes a collection of resources concerning data portability, including top feeds, a best-of feed and a search engine for reference sites on the topic.