
Why should anyone ever use a Google API again? - bauchidgw
http://googlecode.blogspot.com/2011/05/spring-cleaning-for-some-of-our-apis.html?showComment=1306481143396#c3564212561169948866
======
wccrawford
You mean, why should you build a for-profit product while relying on someone
else's not-for-profit API?

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.

~~~
bad_user
Google's App Engine is pretty much a for-profit API.

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!

~~~
nhoj
I never liked app engine. To me it seemed like you have to lock yourself into
google as a vendor because your application has to be designed for app engine.

~~~
kkowalczyk
I never liked Linux. You have to lock yourself into Linux APIs because your
application has to be designed for Linux.

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.

~~~
prodigal_erik
Relying on a service hosted by a third party is fundamentally different.
Nobody, not even Torvalds or van Rossum, could throw a switch and shut down
your Linux boxes or your Python interpreter, so any needed migration to an
incompatible system can happen at your convenience.

~~~
borism
have you tried migrating to Python 3.0 yet?

~~~
georgemcbay
Irrelevant to the grandparent's point because your Python 2.x interpreter
isn't going to stop working at the whim of an outside party.

~~~
saurik
This argument come up often, but makes no sense as it ignores the fact that
software rots. I cannot keep running Python 2.x indefinitely without
maintenance because knowledge of its flaws will slowly escalate until it is a
security risk to keep operating it. If this doesn't happen to the tool itself,
then it will happen to one of its critical dependencies, like an old version
of SQLite it requires, or the previous generation of OpenSSL.

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?

~~~
glenjamin
There's a big difference between flicking a switch to turn off python 2, and
slowly deprecating it over a period of years to a new (better) system with
well doucmented differences and a clear migration path.

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.

~~~
saurik
Upgrading to Python 3 is simply not an option for me at this time as I am
depending on libraries that still require me to be using Python 2: Python 2->3
is an "all or nothing" endeavor due to the horrendously incompatible way they
have handled this transition. I mean: the fact that five years /have/ passed
and Python 3 is still a silly pipe dream for almost all users of Python should
tell you something about how poorly this was done.

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.

~~~
rbonvall
> the fact that five years /have/ passed and Python 3 is still a silly pipe
> dream for almost all users of Python should tell you something about how
> poorly this was done.

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.

~~~
pnathan
I work with Python 2.x on a regular basis. I have no cause to recommend Python
3.x at this point in the game. Depending on Ubuntu 12/13's choices , I may
push my team towards moving away from Python altogether.

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.

------
jcampbell1
Google cites abuse as the reason for shutting down the translate API. I find
it ironic that they have engineers smart enough to write software that can
translate human language between hundreds of language pairs, but can't write
software to stop abuse.

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.

~~~
SoftwareMaven
The cost in goodwill (and perhaps even real money) of using translate to fill
hundreds/thousands of google ad-filled spam sites in hundreds of different
languages may be much higher than they could ever conceivably recoup in
charging for the API.

Once you charge more than any legitimate user would be willing to pay for the
API, you are effectively shutting down the API anyway.

~~~
cookiecaper
Are spammers going to be willing to pay x cents/call just to fill spam pages
with translations? We must make x high enough that spammers will not make
enough profit to justify the expense but legitimate businesses that depend on
the API will still be able to pay for it.

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.

~~~
dmoney
The spammers would only have to translate each page once. Further, they could
translate only the pages that users request in language X as needed and cache
the results.

~~~
cookiecaper
And what stops them from doing this with any of the other translation services
out there? translate.google.com isn't going anywhere, and if they're actually
having a problem related to abuse (as they claim on the Translate API's site),
I seriously doubt that spammers are going about this in this way. The notice
seems to say that the Translate API is overloaded -- charging x c/call would
definitely diminish the load, especially if we consider that most spammers are
not going to want to give real payment data to Google in the first place
(since it can then be subpoenaed and used to prosecute or otherwise identify
the spammer).

------
DanI-S
The original post mentions a 3-year deprecation period. Given the speed of
technological progression, that would be pretty difficult for me to complain
about.

Edit: The Translate API, specifically mentioned, will be deprecated December
2011. That's pretty soon.

------
jmathai
I can't state this enough. Building your company which heavily relies on an
API provided by someone else is risky business.

Why are we still in this infatuation stage of ignoring the pitfalls of this?

~~~
chc
You mean like .NET? Or Cocoa Touch? Or DOM? Or Node? Or POSIX?

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.

~~~
cookiecaper
The difference is that those APIs are "non-cloud". The code necessary to run
those APIs is spread far and wide and no one can just centrally "turn off"
.NET or POSIX. Perhaps over time the programs written for unmaintained APIs
will fail on newer platforms, but you will always have the means to go back to
the old system and run your dependent programs there. In Google's web-based
system, Google is the only one with the keys necessary to keep that engine
running, and if they take their ball and go home, all of that API's users are
screwed.

------
jsdalton
I don't mean to be a stickler, but this is an egregious example of
editorializing in the title. Can someone edit it please?

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).

~~~
corin_
This submission is linking to a comment, not a news story, and that comment
asks _"why should any developer, any company which wants to build a valuable
product for the long term use any of your APIs ever again?"_

So, still slightly editorialised title here on HN, but pretty much on the
money.

~~~
jsdalton
I totally missed that. Thank you for clarifying.

------
baconner
Amazing sense of entitlement in this comment. Google built the apis, they host
the apis, they incur costs from this yet provide them for free. Presumably
this is because they intend to get some benefit. So its Google's decision if
they want to continue to provide them or change the way they work.

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.

~~~
pettazz
Came here to say this. This guy is complaining because Google is shutting down
a service that started to become more of a burden on them to provide than a
benefit to the actual developers using it. They're not the goddamned Red
Cross, they're a business. A very cool, developer-friendly business, yes, but
still.

------
thetrumanshow
Google has made some unpopular developer-facing moves lately (App Engine
pricing changes come to mind), and it seems entirely out-of-character.

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!

~~~
bane
I agree, something strange is definitely going on internally at Google.

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.

~~~
rachelbythebay
Computing power, sure, but who's running it?

------
tomkarlo
Offering an API, paid or unpaid, is not making an unending commitment to
support it forever. If it was, businesses would simply not offer APIs.

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?

~~~
dhimes
Nobody is arguing that they don't have the right, but there are social
implications to doing so. People have the right to not like them because of
it.

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.

~~~
tomkarlo
I can understand being unhappy because they've decided to deprecate a free
API. I disagree with the rage of the OP.

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.

~~~
wolfhumble
Yes I agree, one should always be grateful!

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.

~~~
dhimes
Exactly. Would you accept the next gift? Especially when giving the gift isn't
a selfless act-- it's only given if it benefits the giver.

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.

------
Gunther
I would be very interested in seeing how many developers would pay for the
Translate API if Google had decided to monetize it instead of deprecating it
then shutting it down as some of the commentors on the blog had suggested. At
the same time if the Google Translate API is such a popular service then maybe
there is enough demand to support a startup providing a Translate API ;)

~~~
frisco
Starting a startup to replace Google Translate wouldn't be a simple
proposition. Google's translation algorithms are considered best-of-breed and
involve highly sophisticated statistical machine learning trained over a
significant portion of their web crawl corpus data. Their staff scientists and
engineers working on Translate are some of the best in the field, and the
complexity here should not be underestimated. That said: yes, there's very
obviously an opportunity here for the right team; but that opportunity is so
big, its been there this entire time, even with the Google Translate API
around.

~~~
juiceandjuice
Right... Some problems are fine just throwing resources at them, some problems
need experience and knowledge, and in my opinion, you're not going to get the
intellectual capital you really need for something like this, especially with
a lean startup, unless you are the intellectual capital.

------
michaelpinto
Question: Can anyone recommend another Translation API? The problem is that
the translation work that Google does is the best out there that I've seen,
and I'm not even sure if there's a decent alternative to be found.

~~~
Klonoar
_Full disclosure: I currently work with the company detailed below (myGengo)._

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:

<http://www.microsofttranslator.com/dev/>

~~~
mromaine
_Full disclosure: I'm the CTO of myGengo_

I would also add that because translation is core to our business, we would
never deprecate the translation API :)

------
magicalist
I keep hearing about hypothetical for-profit products and people's weekend
hobby projects being affected by this change, but does anyone have any example
of an _actual_ business that will be affected by this change?

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.

~~~
jcampbell1
Yes. I hire many translators. We use google translate, and license
professional dictionaries to speedup the process. I estimate that Google
translate saves us $20k/year. I personally would be willing to pay a lot for
continued access to the translate API. (I'll probably just end up using some
sort of iframe hackery when the translate API goes away)

The actual business is <http://www.yabla.com/>

~~~
xpaulbettsx
Check out <http://www.microsofttranslator.com/dev/> \- I find the translations
aren't always as good with idiomatic phrases, but it does a pretty good job
and the API is complete and easy to use.

------
jdvolz
I'm leery of building anything on top of someone else's API. I built on top of
an API while also keeping in active contact with the company to let them know
what I was doing, going as far as talking directly to their legal department,
and they still shut me down when they couldn't handle the volume of usage. And
this is in a situation where every marginal use of their API made them money.
Collectively I was going to make them revenue of (projected admittedly) $1.2M.
Didn't stop them from shutting me down.

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.

------
orblivion
Google shuts down several of countless, FREE APIs, on which the foundations of
many startups rest.

"Google is just another company who doesn't care about developers."

What? A little gratitude, at least, before suggesting how things could be
better.

~~~
chc
Gratitude for what? Ripping out "the foundations of many startups"? In many
cases, offering something and then rescinding at the last minute is worse than
not offering in the first place.

(I'm not personally mad and wouldn't have built a business around this API.
But creating false expectations is not a good thing.)

~~~
orblivion
That's reasonable, but I think it's sortof unclassy to ignore the fact that
they "cared" (as much as a company can really care) enough to offer it in the
first place, and everything else they still offer.

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.

------
dstein
It's really too bad. The Translate API was super, super fun to play with. I
made myself a cute little interface to translate JavaScript or CSV arrays into
multiple languages simultaneously. I envisioned being able to build fully
self-translating web applications. And there's no other company providing this
type of technology in this fashion.

If there's any startup working in this area, here's your chance.

~~~
cookiecaper
Agreed. This is a great opportunity for a startup to swoop in, clone the
Google API so the only change necessary is authentication tokens and URI, and
get everyone to switch to their (paid) platform.

~~~
jan_g
It's hard for a startup to "swoop in", because Google uses statistical
analysis in it's translation software if I understand correctly various
articles about this topic. This means that they have thousands of correctly
translated documents from which the software learns. And (so they say) it gets
better and better with time, because they feed it more and more documents in
various languages. I'm sure I've overly simplified the Google's implementation
and there's a lot more to it, but I'm trying to make a point :)

In short, it takes considerable amount of resources to make it work on a
Google translate level.

~~~
cookiecaper
Sure, but a business that depends on this functionality would probably take
"somewhat worse translation quality" over "completely dead translation
capability". As the startup gets funding and customers, they can focus on
performing the same kind of analysis and focusing specifically on translation,
instead of the buckshot approach taken by Google. I am completely confident
that a startup staffed with talented people can match Google Translate's
quality in a reasonable amount of development time, and in the meantime,
something is better than nothing.

------
nekitamo
Glad I stuck to scraping Google Translate, and not using the API. Cheaper and
a better long-term solution.

~~~
dstein
What did you use instead?

~~~
akanet
He said he scrapes the HTML output of the actual Google Translate web pages.

------
neovive
The announcements seem impact the smaller, niche, API's. It's unlikely that
this would ever happen to large API's such as Maps, Analytics, etc. However,
the Translate API was definitely very cool.

~~~
taken11
it happened for the search api

------
nhebb
The way I look at it, Apple and Microsoft have ecosystems that allow others to
profit from software development. Google has an ecosystem that allows others
to profit from advertising. Of course, you can development software products
around Google's platforms, but I'm only seeing a handful of success stories in
comparison to the other two.

------
iqster
Quote from Fred Wilson at TC Disrupt NY:

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...>)

------
adulau
Some of the Google API are released early to get contributions, testers and
inputs to improve their services. In other words, they abuse their
contributors to improve their services without thanking them or helping them
on the long-term. The translation service is one of them, the massive
improvement of the translation service came from the many inputs received by
people using their API.

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.

------
krisrak
Never rely on anyones API, building something with API is mashup/side-project
not a startup/company.

~~~
code_duck
Pretty sure that's not what TweetDeck is thinking this week.

~~~
kenjackson
But it's probably what all the other Twitter clients are thinking. :-)

~~~
code_duck
Doubtlessly. I hate being in the thrall of a company in such a way too. It's
dangerous to be dependent upon someone else's their API. But is the chance of
great success lower than for with other businesses? Probably better to start a
Twitter client than a to-do list site or something.

------
krisrak
Fred Wilson said it the best at TechCrunch Disrupt, - "Don't be a Twitter
bitch, Google bitch or facebook bitch. Be your own bitch"

------
rbranson
If they feel as if they can only launch APIs that have indefinite lifetimes,
this will seriously hamper their ability to justify building new public APIs.
Deprecation is a risk taken anytime software is built on an API, for-profit or
not. This is why software should be characterized as "living" and not a static
entity.

------
lalmalang
Far more likely than 'abuse' (they could have just charged afterall) is
probably Google's realization that they have an uncontested lead in machine
translation - and there is a _lot_ of money to be made here.. They recently
won a contract with the European patent office to machine translate patents
for them...

------
sharjeel
Facebook made exactly the same mistake and I believe it is hurting their
platform a lot even though they've opened new doors to support new ideas for
their evolved API.

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?

------
toddh
My guess is Google setup these APIs to help train their learning algorithms.
Now that they are trained there's no reason to keep up the service anymore.
Maybe the key is to stay away from APIs that do work and don't contribute to
revenue?

~~~
rryan
For e.g. the translate API, how could they train their algorithms? There is no
feedback associated with it (that I know of).

~~~
chris-hexx
Static analysis of lots of human translators' output. Given the input and
output of a strange human filter, they're trying to approximate the filter
using machine learning. When their algorithm's output approximates the best
translations, they're done.

~~~
rryan
That's one way to train a translation system, but that's not related to the
Translate API -- I'm asking, what benefit does Google receive from usage of
the API? They already have the entire Internet in their index -- it's not like
they need a better source of what phrases exist. The parent implied that
Google was using the API to train their MT systems, which I find hard to
believe.

------
mmccomb
Pruning old APIs wouldn't put me off. What puts me off is the inter-
dependencies between APIs. Want to use Google Prediction API? Well you'll need
a Google Storage API account for that. Oh and, you can only have one of those
for free. And just in case, they'll take your billing info.

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.

------
anorwell
How frustrating. I built something just last week using the translate,
transliterate, and diacritize APIs. These are/were really useful APIs for
creating language tools.

------
invisible
Solution that they chose not to use: API keys. Really messed up of them to
jump to completely shutting down without giving some sort of rate limit/access
control.

------
ankimal
Dint Fred Wilson say this at Disrupt NY last week:
[http://techcrunch.com/2011/05/23/fred-wilson-be-your-own-
bit...](http://techcrunch.com/2011/05/23/fred-wilson-be-your-own-bitch/)

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.

------
alanh
Given they are deprecating the FeedBurner APIs, is there a good alternative to
FeedBurner at this point?

------
modernerd
Sad to see the Translate API go. Will be interesting to see if crowdsourced
translation engines such as <http://duolingo.com/> will one day come to fill
Google Translate's shoes.

------
latj
Google was ok giving you a connection to translate because you were helping
them build up the system. Now the most powerful database of human language is
going to be locked up. We should all learn a lesson from this...

~~~
rryan
How does using the translate API help Google? They already have the largest
source of natural language text in existence (the web) -- why would they need
your translation queries?

------
senthilnayagam
Google aura is gone, without free let us see how it competes with apple,
micrsoft

------
smackfu
Are these APIs really so unique that they can't code for some other provider's
replacement? Is it just that a for-pay translation API, for instance, is too
expensive for a product without a solid business plan to use?

~~~
AashayDesai
And what of open-source projects that rely on such APIs? Are they expected to
figure out a way to switch to for-pay APIs as well? Example:
<https://github.com/Marak/translate.js>

------
ojilles
FTA: "... so you decided to "das kind mit dem bade ausschuetten" (translate
it) ?"

Classic :-)

------
hessenwolf
Hotmail deleted my account after 28 days and i lost contact with all the
people i met in my year of travelling.

Yahoo killed their spell checking api in april and now i need a new word
splitter. Any ideas?

------
pnathan
Why should anyone build a business on an API that there isn't a contract in
place to require uptime, with appropriate fiscal penalties for downtime?

------
rachelbythebay
There are two kinds of APIs: the ones which are deprecated and the ones which
don't exist or work yet.

------
johnx123
Why this FUD? Let's scrap or sniff Google tools as before!

------
frytaz
booo! where's api replacement ?

------
whtswthelogin
Google admits it doesn't know _sh!t_ about running a stable business.

Thanks Google! Ya dumb fvcks.

