The big API gamble: When do you borrow vs. build?

Mozilla's move to build social networking features into its browser has spawned a series of potential ripple effects. TechCrunch's Michael Arrington notes that startup Flock could take a hit. Others add that it's dangerous to build solely on another company's technology.

For Flock, which is built on Mozilla's technology, the dangers of building on Mozilla's technology will become abundantly clear. CenterNetworks' Allen Page has some straightforward advice:

Build your own app. Leverage other technology where it makes sense but don't put all your eggs in someone else's basket. And if you do, understand that your position can change in an instant.

Page's advice makes a lot of sense and I've heard other executives, notably Zillow CTO David Beitel, make similar points. Beitel said in a December Q&A:

"Accessing the software of others can give you quicker builds, but you have to read the fine print and pick and choose. You have to make sure your partner will be around three years down the road and have contingencies in place."

Beitel pointed out what many newly minted startups may find out the hard way: The API game is a gamble. A larger point to be explored is what does borrowing APIs really mean for Web 2.0. If few of these companies have truly defensible technology how are startups going to survive? For instance, if MySpace features are built into Firefox why would someone visit MySpace. That point may be a bit extreme, but you get the idea.

To be sure building on someone else's APIs has always been a gamble. But in the Web 2.0 world the fallout could be more pronounced--many startups are mashups of borrowed technology.

So how exactly to you decide to borrow instead of build? A few points to ponder:

• Know your end goal. Is the goal to stay independent? Or sell out soon? A company like Zillow with larger plans naturally it will want something a proprietary in its corner. But borrowing APIs may work just fine if all you want to do is be acquired by the company that owns the APIs in the first place. And it doesn't take a YouTube-ish home run to be a success. Kieden built a Google Adwords module on Salesforce.com's platform and was acquired in August by Marc Benioff and the gang.
• Know the risks. There is a benefit to borrowing APIs--you don't have to reinvent anything. But the risks are plentiful. Terms and conditions can change. Or the company that owns the APIs can decide to do the same thing or go bust. Mozilla's likely impact on Flock isn't new. There were plenty of software companies that developed applications on Microsoft's APIs only to get squashed by the folks in Redmond. On the flip side, developing your own APIs takes time and money.
• Know the importance of time to market. The APIs you use should be weighed against time to market considerations. If you need to move quickly or a project's return looks better borrowed APIs make sense. For instance, FedEx is using Google Maps APIs. Why? It's cheap, got the project rolling quickly and FedEx couldn't build anything better.

I'm sure there are more considerations to consider with picking APIs, but the big theme is that it's always a gamble. The key is to know and manage the risks. Comments on the topic welcome.