But... I... like... the... PAIN! Our secret addiction to 'free' APIs

Tut, tut – will you app developers NEVER learn to say no?

It's new! It's shiny! It's... oh

Why do we as developers keep falling for the same song and dance? A new API or service appears and we embrace it with wide-eyed enthusiasm, only to have it shut down a few years later.

If you've been using internet services for long enough – relying on APIs that change or disappear, whole services that get shut down or entire companies that just fold up and move on – you necessarily develop some cynicism about anything new. The Register's recent headline about Google's new Photos service captures this sentiment perfectly: "Google spins up 'FREE, unlimited' cloud photo storage 4 years before ad giant nixes it."

So why, even with the experience of disappearing services and APIs, do we continue to use these services and APIs?

In many cases the applications built atop these services and APIs are equally ephemeral. Many developers building with Yahoo! Pipes have long since ceased working on their projects anyway. The same is true of many other shuttered APIs.

The impermanence of APIs and free web services is matched only by the impermanence of the applications that depend on them.

Then there's the free part. Nothing seems to entice quite like free. It doesn't take a whole lot of experience or business savvy to know that depending on free commercial services you have no control over to build your critical infrastructure is probably a bad idea.

But hey, it's free. If you're a small-time developer without a big bankroll to fund your app, you don't have a choice – you use what you can.

These services and APIs are usually far easier to use and make for far quicker development time.

It's not that developers never learn, it's that you have to start somewhere and the world of free services and APIs seems – and often are – a convenient springboard on which to test your ideas.

Many developers live by the motto "release early, release often". You get from zero to 1.0 a lot faster if you take what's already sitting on the shelf, ready to go. Even if the plan is to roll your own once your app has gained some actual users, by then it's often too late.

The free services are embedded at a low level and going back and changing them is time consuming, costly and usually invisible to your users who are clamouring for more new features on their end.

Next thing you know, two years have passed and your application is still relying on the soon-to-disappear Yahoo! Maps API. Maybe you scramble to swap it out with something else, but that something else will probably be another commercial API offered as a free service. You can swap one king for another, but you'll still be serving at someone's pleasure.

You could argue that in some cases there are open-source alternatives. In the maps example, there's Open Street Map of course, but there's no open-source version of Pipes. Nor is there an open-source version of every other shuttered API out there. And open-source projects are ultimately just as vulnerable to disappearing.

Projects lose steam, core developers move on and pretty soon you're left with code that hasn't been updated in years. Nevertheless, the advantage with open source is that you can take the code and continue to develop it yourself.

It would be nice if there were an open source equivalent for every new service or API that pops up, but there isn't and there never will be. Developers will continue to use services that will continue to disappear, leaving users continually disappointed and without the tools they've come to depend on.

This appears to be, for now anyway, just the way of the web. ®