1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Yahoo recently announced it will be killing off several services to focus on "search, communications and digital content."
Wait, Yahoo has a search engine? Who knew? What Yahoo won't have in the very near future is a developer favorite by the name of <a href="http://pipes.yqlblog.net/post/120705592639/pipes-end-of-life-announcement">Yahoo Pipes</a>.
Yahoo Pipes has always been something of an odd duck, not just within the company, but on the web at large. There's no migration plan for Pipes users and no real way to get your data out of Pipes because there'd be nowhere to go with it. Pipes was unique and come September 2015, it will be gone.
Pipes's oddball status is summed up by one commenter in the Pipes forum who drolly <a href="https://developer.yahoo.com/forums/#/discussion/comment/22653">writes</a>, "I'm also somewhat curious how much staff time will be saved in discontinuing a service that already received no updates."
It's true, Pipes has been abandonware for some time. In that sense the news of its demise is not unexpected, but that's part of what makes Yahoo's decisions so puzzling to those who use it -- if seemingly nothing is being done with it, why bother shutting it down?
Whatever the reasons may be -- if there even are actual reasons -- thousands of developers and users out there who use Pipes to build RSS feeds, aggregate news, create maps and the hundreds of other things you could do with Pipes will soon be out of luck. That's bad for users, but the effects don't stop with users and developers. All that stuff, all those applications and aggregated feeds that depend on Pipes will also cease to function shortly. Every web service shutdown creates a ripple that affects the web as a whole.
This isn't new. Especially for Yahoo. The company has already killed off the once popular Delicious bookmark hosting services and countless other APIs. Yahoo Maps is also on the chopping block with Yahoo Pipes, which means any developers relying on that API will need to look elsewhere.
While Yahoo happens to be an egregious example of the bizarre, build it (or buy it), ruin it, shut it down business strategy, but it's hardly alone.
Google has also hyped countless new services only to shut them down a few years later. Remember Google Reader? Wave? Knol? Buzz? Notebook? Talk? Then there's Microsoft, the Redmond giant has killed off Silverlight, the third-party Skype API and it looks like even Internet Explorer will soon be a thing of the past.
Perhaps the most famous example of ever-shifting APIs is Twitter. The company initially embraced developers with a very open set of APIs which played a key part in popularizing the fledgling social network. Then Twitter abruptly changed its mind, shut them all down, locked developers out and killed off most the ecosystem that had developed. Later Twitter seemed to reverse course slightly and begrudgingly allowed a select few big names privileged access, but by then most developers seemed to have learned the lesson -- don't build a business on the Twitter API.
There's much ink spilled in the tech press about the "permanence" of things on the web, but for developers at least the lesson of the web is about transience, not permanence. Easy come, easy go.
What's perhaps most curious about all this that developers keep coming back for more. In the not too distant future Yahoo will announce some new service with a new set of APIs -- presumably related to "search, communications and digital content" -- that will convince hundreds, maybe even thousands of developers to jump in and start building things that rely on whatever APIs and tools this new service offers.
Even if perhaps, as with Twitter, developers are done with Yahoo, there will be something that gets us. Even as I write this eager developers are busy incorporating Google's new Photos service into their apps.
Why do we as developers keep falling for the same song and dance? A new API or service appears, 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: "<a href="http://www.theregister.co.uk/2015/05/29/google_photos_free_storage/">Google spins up 'FREE, unlimited' cloud photo storage 4 years before ad giant nixes it</a>."
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 is 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 like -- and often is -- a convenient springboard from 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 clamoring 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 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.
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.
|
