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.
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!
> expecting instability in the implementation, not in its pricing scheme. I mean, come on!
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 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.
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.
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?
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.
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.
> 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.
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.
What matters is whether or not the new version is a realistic option for new projects. It is not. That can't be the goal and if it is, the goal is crap.
If you feel your company has the resources to take over maintenance of something like this, with the understanding that you will no longer be benefiting from the open source contributions from the community (as Python 3's VM has diverged quite rapidly, destroying a ton of projects like mod_python and Unladen Swallow), all I can say is: more power to you. However, continuing to build your empire on land we now all know to be quicksand, just so one day you have the fun job of maintaining the water table to keep your expensive buildings from sinking, seems like poor judgement.
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.
This argument also never makes sense to me: I have never demanded that the Python developers change this mentality, I do not complain on their mailing lists, nor do I storm into their IRC servers demanding that they change either. And I certainly don't send them text messages at all times of the day, like thr users of my app do to me ;P.)
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.
I understand that you don't mean to complain to open source projects, and that's good :)
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.
(To respond to your first comment for a second: I run open source projects that have tens of millions of users, so I know quite a bit about the feeling on the other side of that specific issue: those text messages I mentioned I get all the time are about bugs in something I distribute for free under the BSD license.)
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 think you should reread my post regarding "charities". I said that it's easy for people to mistake Google and other companies for charities because they provide so many free to use services.
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.
None of those are examples of vendor lock-in. Linux, sql, and python all come from many different vendors. If you were using, say, Debian, SQLite, and IronPython, and they all exploded, you could switch to alternatives pretty easily, I think.
I somehow missed the new pricing model. It looks like my bill will skyrocket 2-3 times to over $2000/month. They explicitly tell, that old customers will be forced to move to a new pricing scheme. I wonder why there weren't a rage on HN front page about that?
I regret, that didn't choose AWS EC2 in the beginning.
Relying on someone else's good will for the lifeblood of your company is insane
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.
it's not so black and white. it's not like you should never use anyone else's api ever for your for profit stuff; it's simply a question of risk versus benefit.
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.
As a counterpoint, many companies are built off of APIs that are out there. That's the nature of business and that's actually great for the API authors out there.
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.
That's not really a counterpoint, is it? The comment you're replying to advised people not to build for-profit enterprises off Google's free APIs. It didn't weasel an excuse for maybe just using the APIs anyways because it probably would work out in the long run; it said, rightly, "don't".
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.
I'm just guessing here but in this case it could be that the abuse doesn't mean extra traffic but people using it to generate text to fill pages with, in effect tricking the search engine.
If you pay for an API, and it doesn't work, you can show economic harm and that gives you a basis to sue.
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.
Right. And this same argument means you should not rely on, for example, gmail, for your email. This is good advice for people in general, although perhaps not something google wants to hear, as they generally market themselves as someone you can trust. Obviously, google will let you down in exactly the same way that, say, apple or microsoft or facebook will. The pain for some people might be greater in this case, simply because the expectations were higher. I often wonder if they regret adopting that "don't be evil" motto.
No, the argument was that you shouldn't build a for-profit business that relies entirely on a good-will free API.
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.
If Microsoft did this with the Windows API ten years ago people would be going absolutely batshit crazy in here and the government probably would have intervened
Don't be surprised. I have seen a billion-dollar Brazilian megacorp using it for its core software, and several smaller (but still multimillion-dollar sized) companies relying on it as well (we have hundreds of VB6 apps at the insurance company I work for).
That was not a replacement but a completely different product with superficial simalarities and the same name.
The path was not a migration path but a runaway path.
Not sure I follow. Microsoft discontinues products too. I would imagine that anyone who based a company off supporting and integrating with Frontpage got screwed.
With DOS emulator.
There is no problem to run DOS app from 80s on Linux/MacOS/whatever with dosbox. By the way, dosbox is far better for some apps than DOS emulator from Windows XP/Vista/7.
you are not understanding the issue here. we are talking about the windows API - they have supported every aspect of it in a backwards compatible way since its inception.
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.
I completely agree that you are shooting yourself in the foot if you are relying on someone else's API for you entire functionality. But there are a few things here -
* 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.
One needs to keep in mind that a significant portion of Google's public facing deployment consists of "throwing stuff against the wall, and seeing what sticks".
Remember the now legendary "beta" moniker. It applies, even where it's not explicitly designated.
While you are pointing out a valid strategic risk in building on another’s platform, I’m disappointed to see the top post here is simply engaging in blame-the-victim.
This isn't rape, it is a business. What is happening is not illegal or even unethical. Victim blaming is not wrong when the supposed victim is completely to blame.
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.
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.
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.
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.
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).
Well, maybe not just that type of abuse, overusage without benefit to Google. Of course there could still be abuse of some sort, like somehow using a service to spread spam or malware.
Not in this case, but I don't think they consider spam and malware to be welcome. What I mean to say is that even profitable services can be abused, though if we want to choose a more specific word than 'abuse', the point may be moot.
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.
Actually this is even more specific, which is building your product on a webservice provided by someone else is risky. Unlike a library you download, a webservice ends the day they cut access to it.
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.
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.
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.
I think you can state this in a different way, "Why would I invest in a company which will be killed by Google changing its mind about an API?" I imagine (but it's pure speculation) that folks like YC, other Angels, or early stage VC's should as their due diligence point out this risk and without a reasonable mitigation option pass on funding.
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.
If the abuse is translating spam, then that's even more surprising - because that's exactly the kind of abuse that Gmail already prevents all the time. It even seems like a great opportunity for Google to gather spam data in all sorts of languages.
I think relying on a free API is the problem, not any API.
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.
I would be willing to bet that most of them have mitigation strategies in place that they can, at least in part, switch to. They don't use them because they are less cost effective than AWS (or other current providers) but they should be able to switch with relatively little notice.
I believe you, but I would be willing to bet those mitigation strategies are a few unmaintained word documents that would be grossly insufficient if it actually came that far.
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 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).
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.
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.
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.
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!
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.
Why not? Roll something out, and say you'll commit to providing it for a certain amount of time. If, after that time, it doesn't seem worth it to keep it going (by any metric you decide), pull it. You've given fair warning.
Of course, I imagine that sort of thing would hurt adoption quite a bit.
Google is doing the right thing that would be typical for an internet company. For any product they would need to have maintainers/owners who are continuously updating and monitoring. It is completely waste of time to maintain unused stuff.
You are making a false assumption. I personally use the FeedBurner API to keep track of feed subscribers, for example, and it was deprecated yesterday.
....and you still have 3 years to use it! (granted no more development will be done on the API.) So over the next three years which is like an eon in web years you can look for an alternative. Frankly Goolge might even bring out an alternative.
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?
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.
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.
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.
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 ;)
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.
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.
I wonder how much work it would be for Google to build a "Translation appliance" people could buy? I'd wager they'd do $100million in government sales alone the first year.
I commented on a different story about the API changes (specifically Translate) and thought I'd been stupid to miss a big "DEPRECATED" message when I started out several months ago. Seems there was nothing to miss!
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.
I would pay for what I use which isn't a whole lot, but it will be hard to find a programmable replacement like the Translate API. It's also a little hard to believe that it was a "financial burden" for one of the richest corporations in the world.
They have something like 37 Billion dollars in retained earning and don't pay a dividend. They didn't get that mountain of cash by losing money on things.
Assure yourself, if you are using a free google-anything, somehow or other, it adds to their income.
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.
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:
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 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.
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)
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.
Yabla seems very interesting. Care to share more details? How is it doing, who and where from are the largest user groups, how did you end up with the idea, etc.
We use Google Translate where I work for a some very small customer service related tasks. Our business is not "built on" Google Translate (and has nothing to do with translation), but it solves some small problems for us and is easily worth $10-20 a month for a low volume of requests. Actually, since we already have it integrated and are happy with it, we'd probably pay more just to have the problems solved so we can focus on really important things.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
Never rely on anyones API, building something with API is mashup/side-project not a startup/company.
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."
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.
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.
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...
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?
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?
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.
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.
GOOG-411 is an example of this process. Google got voice samples and users got a service. When the voice training parameters stopped getting better the service was shut off.
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.
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.
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.
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.
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.
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...
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?
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?
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
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.