Dan's Take

APIs and the Art of the Lock-In

While they seem great at first, they might lead to a prison from which you can't escape.

• By Dan Kusnetzky
• 10/24/2014

I often get messages from small software suppliers or startups telling me the exciting news that the company is now offering an API, making programmatic access to features and functions of its product possible for developers. Woo hoo! The company is hoping I'll become enthusiastic about the flexibility and power it's bringing to developers, and write a glowing review of both it and its technology.

The truth of the matter, however, is that I'm very skeptical and think more about the software lock-in that's being offered, rather than the ease of development the company would like me to focus on.

Software Lock-In
What is a software lock-in, you might ask? These are proprietary features and functions of a software product that can be found in only one place: that supplier's products. Lock-in can be created through the use of proprietary file formats, communications protocols, development environments and, in some cases, through the use of company-specific development languages. Some suppliers have used this tool as a way to gain leading or dominant positions in their market.

One of the deeper levels of customer lock-in comes from having developers link their code to the supplier's products using a proprietary API. After all, once developers choose to use that API as a way to create needed applications and services, they're locked in to using that company's products. This means they're locking themselves, their company and, potentially, their customers into a long-term relationship with the supplier of the technology to which they're linking.

This, by the way, is one of the primary reasons Platform-as-a-Service (PaaS) offerings aren't as popular as either Software-as-a-Service (SaaS) or Infrastructure-as-a-Service (IaaS) offerings. The proprietary development languages, application frameworks and runtime services make it difficult or impossible for applications to be moved in-house or to another supplier.

Golden Shackles
Locking yourself into the products and services of a single company isn't all bad if you're careful. If the supplier has a long-term track record of creating useful products, has built a large ecosystem of partners and provides the solutions to problems the developer's company faces, accepting the golden shackles for the company may be worth the risk.

Golden shackles, by the way, look pretty and appear to have some type of advantage. But they're still shackles, regardless of how nice they look.

Caveat Startup
Committing to the APIs of a startup, on the other hand, is putting the company's future in the hands of an unknown. The startup could fail, be purchased by another supplier that isn't favored by the company or, even worse, lock the company out of new technology that might be needed in the future. So when a startup -- a company just coming to market with its product for the first time -- announces that it's offering an API, my primary thought is "Who would be foolish enough to tie the future of their company to an unknown?" It's never, "Wow, that's marvelous!"