Why should anyone ever use a Google API again?
googlecode.blogspot.com
googlecode.blogspot.com
I'm guessing you shouldn't!
I've seen a lot of neat projects come from Google APIs, but that's as far as I'd taking it.
Relying on someone else's good will for the lifeblood of your company is insane.
1 exception, though: Getting started. I could see using Google to get off the ground and then switching to a more reliable API (read: paid for) afterwards.
I know from experience that a number of Google's APIs are just some engineer's idea of how to hook into the data stored in the back end which Google puts out there for some easy (and free) goodwill but without any commitment ever to actually do the necessary foundational work to support it as a product (which they are really really bad at, in case you haven't noticed).
So the point is they use the API internally, exposing it gives them additional testing and additional feedback on how to make it better. Once the cost incurred by offering it for free exceeeds the benefits of the testing they pull it back. Continuing to use the now 'well tested and well rounded' API internally.
GOOG-411 was a great example of this. It was a great way to get voice samples from a lot of people by bartering a service. Once their voice training parameters weren't getting better they turn off the service, (cuts costs) but they still get the durable benefit of a well trained voice recognition library.
Nasmorn's Law
But if developers knew that APIs could easily go away, then people wouldn't build businesses on top of those APIs. The risk would be too high.
I don't know the history but it seems that Google could've implemented some simple solutions to prevent abuse of their APIs while catering to the business community such as simply charging for use. Any legit business would be willing to do this.
Guessing Google has bigger fish to fry than making the world nicer for people who want to build apps on translation APIs.
The comment I replied to basically implied that only neat projects have come from Google's APIs and nothing more. This came after his comments about how one shouldn't build a business off a not-for-profit API.
In my mind it's an incredibly ignorant remark to make. THAT was what I was making a counterpoint to. I could point out some very obvious examples like Tweetdeck or the numerous applications that use the Facebook API. I just thought it was incredibly obvious and not worth my time.
Most of today's exciting APIs are "not-for-profit." That is, companies do not charge for the APIs themselves. By your advice, nobody should be trying to build for-profit, real companies based on them. The primary reason why these APIs are created are so that they can create their own economies that are dependent on their platforms.
My comment was also generalized (much like the comment I replied to) to APIs beyond Google's Translate API. I guess you were too busy fixated on this one scenario.
* Everything Google does is free. So it can be argued that the API is in fact for-profit. * In this case, translation is not something a small company can do by themselves. The API's whole value proposition is that it enables startups without the infrastructure like Google can create interesting applications using the API. Google wants people to do that and its very much a big part of its success so far.
So the developer is not entirely at fault.
I would not rely on that one API itself for my business but he/she chose to do it.
And now they've announced a change in their pricing scheme, which if true, would change App Engine from pay-what-you-use to same-as-amazon-aws-but-pricier scheme, which makes it hugely expensive for a large portion of devs that have built on top of App Engine. And migrating away from App Engine is a total pain in the ass.
I truly hope that the blog-post missed important details or that they'll keep providing the old option too (i.e. paying per cpu-hour instead of instance-hour).
I know App Engine was beta, but people have built on it expecting instability in the implementation, not in its pricing scheme. I mean, come on!
https://groups.google.com/forum/#!topic/google-appengine/ob-...
Clarifies that you will be paying per instance hour, instead of cpu.
Nothing is in concrete yet, if there is enough outrage amongst users maybe they will change their tune.
I never liked relational databases. You have to lock yourself into SQL because your application has to be designed for SQL.
I never liked python. You have to lock yourself into python because your application has to be designed for python.
Why can't we all be friends and blossom like flowers in the fields?
Projects like Python, that simply don't care about maintenance costs of things that rely on it are simply being naive: they are pretty much saying "yes, you invested a ton of time into building code for Python 2; but those days are over: we, at some random shifting date in the future, are going to drop support for this, so if you want to get security updates to it, or hell: even upgrade to a newer version of Ubuntu with minimal pain, you now need to drop everything you are doing and reread all of that code to update it for our seemingly arbitrary changes, retesting the whole thing in the hope of finding any regressions you introduce; that, or go off-grid, maintaining this code and related infrastructure yourself". Seriously?
Imagine if Linux 2.6.100 decided to drop support for socket(), because it is (truly) a painful API to support multiple transport layers with; /even if/ they said "dude, you can still just type socket_old, and we have a crazy preprocessor that hopefuly, if your code is obvious enough, does this search and replace for you", would you still be able to take their dedication to being a platform seriously?
Python 3 started in 2006 (http://www.python.org/dev/peps/pep-3000/), if you've managed to stave off software rot for the last 5 years, I'm sure you can take the extra step to support python 3.
Now, of course, to the extent to which I can, I've used Python 2.7's "from __future__ import" mechanism to pull as many features as I can from Python 3 to help transition, but even that has been stupidly painful: importing Python 3's gratuitously different division operator (which you can't automatically process and convert as you need to know whether the denominator is a float or an integer) was very very VERY painful on all of my careful image processing code (suddenly getting, or not getting, half pixel offsets and widths in various places).
Meanwhile, I don't see any benefit at all to me making these changes... requiring "as" instead of a comma for exceptions?... /removing/ the 2.7 ability to mark a string constant with a b-prefix, forcing an ambiguity between 2.6 str and 3.0 bytes? Are you seriously telling me that these were so important as to cause there to be a five year rift in the language community?
In all seriousness, a better usage of my time (rather than messing around porting my 2.x code to 3.x code) would have been to make a patch to Python 3.x to let you "from __future__ import hindsight" to let you use Python 2.x syntax with the Python 3.x interpreter, at which point 99% of these incompatibilities would be irrelevant. Of course, hindsight /is/ 20/20: I can't go back in time and reinvest that time better; but, I certainly have learned my lesson about using Python.
So far, it has been just how it was meant to be. It was never the goal for Python 3 to be the default Python version by year 2011.
I don't see that the Python team really made the right choice here. I have no good transition path from 2 to 3 besides an intensive rewrite.
Plenty of companies do exactly this with Linux.
In this case, you're not the only one building an empire on the quicksand (which by the way, was freely provided by voulenteers, which only make changes to the quicksand in an effort to _improve_ it).
The effort to keep the platform working to support your old castle will usually be shared with others, just like with the Debian project which keeps old software versions updated with backported security fixes for many, many years just so that you can sleep well each night.
Instead, when there are discussions on business-oriented sites like Hacker News about what investing in technologies (like Google APIs, in this case), I make certain that people don't make flawed arguments about the cost tradeoffs involved in maintaining your own dependency chain, and it turns out that Python 2/3 is a great example of this (and one I didn't even bring up).
Unfortunately, bringing up personal stories of this tradeoff is going to come off as "whining", as you call it, to some people, but frankly that just comes off, to mr, as name calling. I think the Python 2/3 split is a great example of a particular area of quicksand that a smart businessman (which I apparently wasn't, I will add) will avoid, and I think that is an interesting idea to keep in mind ("what is the percentage chance that I will have to maintain this thing that is not my core business myself after a few years") whenever adopting a technology, new or old.
It feels like whining to me mostly because these stories are often brought up, but rarely without any mention of the alternative: Without the wealth of open source software to build upon, we startups would either have to license the software/service or make it ourselves at great expense.
By saying that the "pro open source" argument makes no sense, you're implying that the risk exposure is more or less equivalent whether you depend on an open source stack or a proprietary web service. And to me, that's clearly wrong. There's a world of difference between someone killing your product at the flick of a switch and some piece of software becoming unmaintained a few years down the line.
Would you be a smarter businessman if you had chosen to build your software on a proprietary, well maintained programming language which would only run on Google App Engine or an Amazon web service? I certainly wouldn't think so. Still, a lot of people do something very similar, and they become surprised when they discover that the big companies don't run charities.
I'm guessing Digium would have liked it if the Skype protocol was open, _even_ if it was changing every 6 months), but it's not. Now they have to discontinue their Skype for Asterisk product because Skype changed their mind.
You are now conflating "prorietary" with "charity", which is ironic at best, and seem to be disagreeing with my arhument not because you disagree with it's logic, but because you dislike some indirect ramification to a cause you believe in, which is sad. :(
Open Source is not some magic bullet that makes something fundamentally maintainable: it simply affects the cost of one option, which is accepting the lock in and operating the project yourself. 99% of the time it will be cheaper to take another alternative, like "migrate to another solution", which is certainly something you can do with a proprietary solution.
So no: I disagree with you; if you are choosing an open source project just because it is open source, you are a bad businessman. Example: if you chose mod_python for your web architecture today--a discontued (with prejudice: the sole remaining official maintainer hated it) project that I seem to be the only remaining user of and which (honestly, despite what I tell people) wasn't very good in the first place--over a proprietary alternative that actually had a working business model, like ASP.NET, solely because you could maintain the former yourself, that would /clearly/ be a very poor and highly costly decision for your company, and would easily allow a competitor to run circles around you on cost of development and maintenance. There may even be reasons why mod_python would be chosen over ASP.NET (such as a plausible, if painful, migration path to mod_wsgi combined with the now know to be incorrect preference of coding in Python ;P), but this one in specific is simply irrational.
As for Digium: an ecosystem (like Skype) is fundamentally different than a hosted API, and I'm confused as to why you feel it appropriate to compare them... I can replace Google Translate (an API I rely on and do not regret choosing), but I cannot replace Skype, even if the entire client were open source.
I never said open source is a magic bullet for anything. My original point was simply that you cannot equate relying on a third-party API to relying on an open source project. There's a risk to both, but they're very different risks.
Even perpetually licensed proprietary software that you download and run yourself has the advantage that you yourself decide when you want to stop using it.
For instance, even if ASP.NET might be discontinued at some point as was VB6, nobody from Microsoft is going to come knocking on your door telling you that you need to shut down your webserver.
However, if you built your platform around Azure and used tons of services and libraries only available there, you'd have a huge problem the day the Microsoft decided to discontinue Azure or quadrupled the price.
Some APIs are easy to replace, and some are not. I brought up the Skype API because it's one that is not easy to replace. I agree that ecosystems are different, so maybe that was a bad comparison. A better example is relying on Google App Engine or Amazon EC2/EBS, or some other API that has no viable alternatives. More complex and differentiated APIs have higher value, but also higher risk since you can't move away from them as easily.
Really, really? Come on, these very same concerns (pricing, it's beta) were/are brought up regularly. If you choose to ignore warnings/recommendations and use GAE that's your fault.
I regret, that didn't choose AWS EC2 in the beginning.
Even if you have a business with all of your employees on free gmail, you hardly rely on gmail, because you can probably switch to some other email system without going out of business.
Additionally, gmail is not even really a "good-will free" API. Advertisements more than make up for the costs.
Web Services are different in that when they're no longer supported, you can't use them.
read the Raymond Chen blog about how they used SimCity as a benchmark to test if their backwards compat was working. Marc Andreessen is even on the record as being an admirer of the Windows backwards compat work. they put a lot of work into it and placed a high value on it because they did not want to break developer trust.
Tweetdeck anyone? And Zynga (FB is its lifeblood)
Google shutting down an API that thousands of developers are relying on without much warning is insane.
The web is an increasingly competitive space and there are lots of walled gardens to worry about. Google openly encourages developers to build on top of and use its APIs and it prides itself on its "Don't be evil" policy.
Like it or not, companies like Google, FB, and Apple are platforms that developers are building on top of simply because these companies and their services are the "web" these days.
Exceptions are not the rule.
I probably agree with you though. Starting up is all about finding the right set of services to match the right set of needs...by any means possible.
What constitutes 'much warning'? Translate API users have six months. Were you thinking of a different API?
People using the APIs knew the policies for deprecation in the ToS, I presume?
in the case of apis, the risk is that there is some probability that the api will go down. the benefit is that you don't have to write your own stuff, and in some cases, the benefit is the entire value proposition of your application. for example, should you use the google translate api? there is some probability that the api will go down. whatever you estimate this probability to be, that's how you have to weigh your benefit. you probably can't recreate google translate, so the benefit is whatever benefit your application provides, or the marginal benefit that google translate provides to your application.
also, consider the fact that all apis will go down, but you can always create value in the interim. no api is going to be around forever, but will html even be around forever? how long is your application going to be useful? maybe the chance that the api will go down in the medium term is low, so that's an acceptable lifetime for your application.
Remember the now legendary "beta" moniker. It applies, even where it's not explicitly designated.
I'm not defending Google. Just saying.
I'll let Google in on a little secret: If you charge more for a service than it costs you to provide, then there is no such thing as abuse.
Once you charge more than any legitimate user would be willing to pay for the API, you are effectively shutting down the API anyway.
Spam is all about maximum distribution and massiveness, so I don't think the pricing would have to be very high to take the profitability out of the spam operations.
Edit: The Translate API, specifically mentioned, will be deprecated December 2011. That's pretty soon.
Why are we still in this infatuation stage of ignoring the pitfalls of this?
http://raganwald.posterous.com/this-shit-still-happens-and-p...
When you pay per request for access to an API, at a level that can make the provider as well as you profitable, you can have some comfort in the fact that if your provider goes down there will likely be a competitor to spring up in its place.
If your startup could survive if you switched off the API, then you're fine.
This would 'self correct' folks who weren't doing the extra work.
However for things where there isn't really a credible way to come up with an alternative you are kind of screwed. But then it would become a Google problem if they didn't get API adoption without offering some sort of indemnification in the event they need to take it back.
I presume the 'translation abuse' is people using it to send spam in 141 different languages.
With a library you can continue to use it, and slowly rebuild your product to use a different library (or even use that library forever if it works for you), but with a web service it works 100% today and tomorrow it doesn't work at all.
At some point, we're all relying on APIs provided by somebody else. I think that's why it's so easy for people to ignore the pitfalls of just a little bit more.
I don't see why NetFlix would have to be more paranoid about AWS, then say Apple about Foxconn. Business is business, except at Google.
I was already well aware of the API deprecation story, but I clicked on this link thinking it was a new article from Google defending the move (or something of the sort).
So, still slightly editorialised title here on HN, but pretty much on the money.
I use some free apis in my commercial apps but I'm aware that I don't control them nor am I entitled to them. They may change in such a way that I'd have to discontinue a product but that's a responsibility I took on when I decided to use them. Google and other free API providers don't bear reposibility for my decision.
From now on, any API announcement from Google should be accompanied with a GIANT expiration date stamped all over it by default. Then, if it keeps going... happy surprise!
Of course, I imagine that sort of thing would hurt adoption quite a bit.
I actually attribute it to starting with the shutdown of Wave and the floundering about with Buzz and other products since then.
One thing that Google has been excellent at doing is building up the perception that they have near limitless computing power at their disposal. These kinds of shutdowns, and the reasons given, are doing immense harm to that cultivated image.
When someone offers a product or service, they have to right to decide later on to not offer that service any more. That is simply the nature of any business arrangement where you are depending on an entity not under your control.
Would the OP prefer that Google and other companies simply not offer APIs?
You also have the right to not write thank-you cards when people do nice things for you, but those people have the right to react to your selfishness.
This was a free service and they're no longer going to offer it, and they're shutting it down in an orderly manner. That's not selfish.
This is more like someone giving you a birthday present every year, and then when they fail to send you one, you write a nasty post about how greedy and selfish they are.
I think it is difficult to compare this to a birthday present you did not receive, though. It is more like they want you to throw away the birthday present you got last year; a present you were grateful for and that now plays an important part in your daily routine.
I don't use their APIs, and am not building a business on anybody else's platform, so it doesn't affect me personally. But if I were doing that, this would make me change my mind.
It's also a little hard to believe that it was
a "financial burden" for one of the richest
corporations in the world.
Assure yourself, if you are using a free google-anything, somehow or other, it adds to their income.
I (or more specifically, the client) would certainly pay for something like this. If anyone does have a replacement that is roughly as simple to use and isn't £1000/mo then you have a customer right now.
http://mygengo.com/services/api/
Works, no? It's human-based translation, though; a tad bit slower, but generally higher quality overall. ;)
Full Disclosure: I currently work with this company.
People should also definitely (at least) be aware of the Microsoft Translate APIs.
Depending on your needs, you could consider human based translation, which is generally more accurate than machine-based translation. Over at myGengo (http://mygengo.com/) we offer an API to help people get translations done by an actual translator, as opposed to a machine (think Mechanical Turk, but focused on translation). Feel free to check it out - various libraries abound:
http://mygengo.com/services/api/
An advantage to going with this approach is that the myGengo API can also return a machine translation while a job is being worked on; a takeaway here is that even if a service like Google shuts down, it should be fairly simple to use another service behind the scenes, keeping a nice level of transparency for you.
Of course, if you'd like to stick with general machine translations, you could check out the following - should be close enough:
I would also add that because translation is core to our business, we would never deprecate the translation API :)
Note that most of these APIs have 3 year deprecation policies and so will continue to be around; only the translate api is going away (and that's in December).
I have serious doubts that almost anyone would actually pay per translate (and if you would, it's likely you could work out a license deal independent of a public API anyway). It seems like the reaction to this has more to do with annoyance that another cool free service is going away and remaining anger over app engine pricing changes.
The actual business is http://www.yabla.com/
Long story short: Building on someone else's API is a recipe for disaster. Are there times when you have to? Sure. But you need to know what you are getting into.
"Google is just another company who doesn't care about developers."
What? A little gratitude, at least, before suggesting how things could be better.
(I'm not personally mad and wouldn't have built a business around this API. But creating false expectations is not a good thing.)
On the other hand I'm having mixed feelings now, trying to reconcile this with the way I feel about how Facebook's privacy policy affects users. I just don't get the impression that Google is careless the same way.
Many folks are crying out for a paid version of the Translate API for example.
I question the motive behind shuttering a useful and unparalleled API like translate without considering putting a pricetag on it.
If there's any startup working in this area, here's your chance.
In short, it takes considerable amount of resources to make it work on a Google translate level.
Don’t be a Google Bitch, don’t be a Facebook Bitch, and don’t be a Twitter Bitch. Be your own Bitch. (link: http://techcrunch.com/2011/05/23/fred-wilson-be-your-own-bit...)
It shows again the importance of building free software along with their free network services. That's quite challenging and difficult but it shows that initiative like http://autonomo.us/2008/07/franklin-street-statement/ is not completely useless on the long run.
I think a better statement is "Never rely on anyone's API unless you have a contractual agreement and SLA in place, and a backup plan for if/when the API goes away; building something on an API otherwise is a mashup/side-project not a startup/company."
I launched an app back in May 2007 right after their platform launch. After the four years the app is quite broken now and every now and then a user sends me a message about it. Today I decided to spend a day to translate all those "old" API calls into "new & improvides" API calls but due to lack of documentation, unavailability of search results due to all that legacy documentation better SEO'ed and the hectic task of re-testing all the workflows I've previously tested thoroughly, I gave up!
Why should I put in so much effort in re-writing my code just because you don't like a function name or you think same functionality could be achieved by another one so this should be dropped?
I was psyched to start playing around with the prediction API but just got totally put off by the new API pricing/management. I'd argue that the restrictions are now so tight and cumbersome that there's no real sandbox environment to encourage devs to try out the services. I'm a touch disappointed.
They should charge for it at the very least. Whats stopping anyone from using a proxy service and hitting their web page? I m sure people would rather pay a little than go through these unnecessarily complicated and unethical practices.
Classic :-)
Yahoo killed their spell checking api in april and now i need a new word splitter. Any ideas?
Thanks Google! Ya dumb fvcks.