Borrow My Brain

Last night there was a NextNY discussion on the role of business development for Web 2.0 focusing on the opportunities for bringing in traffic and revenues through crawling, APIs, widgets, mashups, and the like. The conclusion was that, while you still need to schmooze and make deals, these new tools are a powerful way to get others to use your service.

Among the topics discussed were mashup sites, sites that combine these features in new and creative ways, and whether they could ever be standalone businesses. Right now, they’re mainly “FNAC — Feature Not a Company”. Things like the New York City Subway Smell Map. Cool, but not businesses.

But there’s something to be said for building a new product out of other people’s code. It’s done all the time: the applications you run on your Windows desktop are basically just ‘mashups’ of the Windows APIs. Why can’t we do the same thing on the Web? What would it take to allow you to put together parts of other companies’ businesses, to create something more than the sum of its parts? And what do you need to pay attention to now if you’re a startup using APIs as part of your business development strategy?

• Reliability. When you call the sprintf function, you can be pretty sure it’s going to be there, ready and able to sprintf for you. It won’t be down for maintenance, hacked, or gone out of business. All of which can happen if you’re making an API call to another website.
• Trust. Developers must have faith they won’t be kicked off or blocked from the API, as MySpace has done.
• A not-free option. If you’re going to rely on a web service to run your business, you’ll want some kind of contract or subscription. Free services are fine for experimenting, but not when you’re using a service in a serious way. You’ll need some kind of service level guarantee and a real person you can call up when something goes wrong.
• Predictable charges. Right now, you can buy an ActiveX control or PHP script and pretty much know how much it’ll cost. It’s usually a flat upfront chanrge. But charging for web services can be unpredictable. What happens once your site takes off, and the service provider figures out you’re making a lot of money? Up goes the subscription fee!
• Predictable upgrades. If you’re mashing up another site’s API and they decide to upgrade, it could break your site. This isn’t as much of a problem with desktop operating systems, because upgrades are fewer and announced far ahead of time, and vendors usually take great pains not to break old applications. Not so with Web APIs. It’s best if the old versions of the API remain available for a while for sites that can’t adjust immediately.
• Speed. HTTP is not fast. It takes a long time to make multiple HTTP API calls in the background.

If you’re creating a site with an API, you have control over some of these issues. Will you offer your users a Pro version of the API, predictable upgrades, a real person to talk to, and a guarantee that you won’t kick them off, or will you offer only a free API, make it impossible to talk to a real person, and kick off developers whenever you feel like it? , Companies like Microsoft need to treat developers well to get them to write for their platform. The same goes for companies create ecosystems around their Web APIs.

If you want to use APIs, mashups and widgets as part of your business development strategy, treat your developers well.