Totally meta comment but I'm kind of tired of "quietly" in headlines to add a surreptitious air to something. Almost as bad as "finally" added to make everything seem like it's arrived years too late. Is it simply impossible for people to run a news site without blatantly pushing people's buttons?
> The company didn’t even officially announce the abandonment of the API. Instead, the notice came in the form of an updated Frequently Asked Questions page outlining the termination, and an email to developers active on the platform.
That doesn't seem to qualify as "quietly" to me. What did the author expect -- a full-page ad in the New York Times?
A blog article so that everyone who follows Google's announcement will be informed? Blog articles will also be picked up by many tech pages, so it's effectively the NYT equivalent for tech.
An article in their blog, at least, explaining their decision and making an official apology. It's good to let people know about it, but it's unprofessional to not publicly acknowledge it. At the very least it's a matter of respect for your community.
Seems to me that when you intentionally lead people to believe that they can depend on you for something in a way that they wouldn't otherwise have, you create an obligation for yourself to keep that promise.
In the case of Google, it's been building product during the last 10 years by doing the following:
- offering a free product;
- letting people build stuff with it;
- create some sort of business model and profit.
Google relies on the community to live. e.g: there would be no android without dev creating app for it, so they provide a system API letting you create something on it. Without that, Android would be an empty shell.
It's a win-win situation, but to work it needs respect from both sides. Here, I don't see any kind of respect from Google, just another beta product trashed.
They have the right to do it, but as a developer, I have the right to not want my time wasted. Hence, if Google wants its community to thrives, it needs to be nice with the people being part of it.
Because they wasted people's time building on their platform? A successful API requires trust that it will continue, or there's no point in using it. Erode the trust, erode the power of the API publisher.
Having been burned by Google API shutdowns before, I just don't use them any more. Obviously they're under no obligation to maintain APIs, but if they want people to keep using them for whatever reason, maintaining trust is important.
And in this computer age, we have to suspect keeping an API available is just some cloud resource of negligible expense. Shutting them down may feed some Google manager's OCD impulse, but can't be saving any money.
There is not just a computing resource cost involved - keeping an API around means continuing to support the quirks of that interface, which means code complexity and maintenance costs, especially when the system the API talked to gets refactored and/or overhauled. Google's internal refactoring strategy frequently relies heavily on a monolithic code repository and the ability to rebuild the world; the more that interfaces are unable to change the harder refactoring becomes.
+1000 to this. The "API" that developers see is the tip of the iceberg for what actually goes into publicly exposing a service to developers.
Yes there's quite a bit of internal maintenance that goes on (as mentioned, lots of things change frequently, though generally people refactoring chunks of code will "upgrade" your code for you, since if they don't they can't submit their changes since you were a good engineer and wrote defensive unit tests to protect your code).
Maintaining a public API can also mean having:
- Documentation (up to 15 languages)
- Sample code/example apps (up to 7 languages)
- Support (Stack Overflow, Quora, etc.)
- An on-call rotation
Um, they are also planning to discontinue the consumer-focussed Google+ Hangouts user experience that the API allows building apps for; Hangouts is being pivoted to be an enterprise messenging product. This change in direction has been announced previously, and is referenced in their information on the API discontinuation.
(And keeping a zombie API available without maintenance, which is non-neglible in cost, is in someways worse than discontinuing it even if the service it interacts with still exists.)
In that case the "quietly" is important, because the article explains that there was no official shout out of this from Google. They just updated their FAQ.
Breaking peoples product is bad enough, but not taking the time to make a clean announcement such as on their official blog seems unprofessional to me. Hence the "quietly".
> the notice came in the form of an updated Frequently Asked Questions page outlining the termination, and an email to developers active on the platform.
Any developers using the API in their product would've received an email.
They emailed everyone using the app and updated the documentation for the API itself, and are notifying anyone using an app that relies on the API through the UI.
Seems to cover anyone with an interest in the API more effectively than posting on any of Google's many blogs would.
I tinkered with the hangouts API a year or so ago, and got an e-mail from Google last week about it being discontinued. So not really 'quietly', they notified people who were using it by e-mail.
On a side note, the API was so broken, badly documented and useless that when we evaluated embedding an app into hangouts it just seemed as a half-arsed effort by Google to expose an API, and it was clear that they didn't really want people building apps inside hangouts. which is a shame, it seemed as a nice platform to extend with collab tools. I'm not at all surprised this got pulled.
Good luck with Duo. I had 9 contacts using it in August, that is, 9 contacts that installed it. I made two test calls and that's it. 15 contacts a couple of days ago, no more calls since August. I uninstalled it because I don't like to leave unused apps around.
I use it as it's the only cross OS app that supports Wifi to phone network switching in a call (others end the call when you lose connection), but I really don't like it. It's exactly as it was when they published it. iOS supports call screens for other apps since a while now (which whatsapp uses), Duo calls still only come as a notification. And they also sometimes fail if the other person hasn't used the app for a few days.
I really liked the concept of the app, and the quality is certainly at least on par with other apps. But I have the strong feeling that it won't be around for long.
Let's hope Whatsapp supports network switching soon so that I can get rid of Duo.
The question with Whatsapp is if Facebook is trying to cannibalize it into Messenger. They insist not supporting bots and if bots become big Whatsapp will be losing ground against everybody else. I'm puzzled by their strategy considering that FB is putting a lot of effort in supporting bots in Messenger. They could just use the same backend API and a passably similar UI in the app.
Sounds about right. Facebook messenger already has the most penetration solely by dint of total # of users. All my foreign-born employees and coworkers are whatsapp users because of free voice calling over wifi. Hangouts is strictly available because it's installed by default on Android and it mines contacts. Allo / Duo have even less use because except for limited Android phones it has to be installed.
Google's decisions on messaging have baffled me for years. Why get rid of gChat, a popular and useful service? Why not implement flawless SMS integration into Hangouts (send SMS from desktop) for people not on Google Voice? Why ditch Hangouts for Allo? Why would they think searching is something regular users would want in a messenger?
I think, though I have no way to confirm this, that it's down to internal siloing: gChat was there doing its thing, and meanwhile somebody was experimenting with Hangouts because they either couldn't or didn't want to deal with the gChat team. They produced their shiny object, and then gChat, which wasn't exactly ever given much love in the first place, was further marginalised and finally had its XMPP bridge killed in the face.
Then Hangouts turned out to be a total mess, but by then they were committed to it. Meanwhile, somebody else was messing with AI internally decided to turn what they had in to a proper chat app, giving us Allo. I suspect Duo started as a way to rescue the video parts of Hangouts with WebRTC support, but that's all speculation.
Edit: oh, and let's not forget Google's Spaces too! Seriously, Google need some joined up thinking when is comes to messaging.
People say that Google has a "Darwinian" product development process, where they pitch products against each other and only the "strong" products survive.
I think most of the product fragmentation/churn at Google comes from four things:
1. Googlers need to "explore all the possibilities their minds have to offer" (direct quote from a coworker)
2. Managers (both engineering and product) generally won't tell you "no"
3. Internal consensus building burns people out
4. The promotion process is based shipping things that demonstrate growth
Google hires lots of very smart, very creative engineers, and asking them to ["maintain legacy code", "answer support questions", "deal with rot but important tasks"] is a tough sell. Many of those people could easily go anywhere else and do whatever they want (this is the talent most companies are trying to hire for), and managers realize this.
Since managers don't want to lose talent, they kinda let engineers do whatever they want, within a given field. The way managers tell you "no" is by not funding/staffing your product/feature--shifting resources to something else. I've very rarely been told an outright, "no, we won't build that" and am more often faced with "that's an interesting idea, let's investigate that more" only to not have sufficient headcount to "investigate that possibility" by building a PoC, etc.
I assume there probably were efforts to "upgrade" Hangouts to have AI integration and a more modern mobile interface vs replace it with Allo. I assume there was a roving band of 10-20 engineers who were in between projects and thought "wouldn't be be great if...", prototyped Allo together on Hangouts infra, and then went to the Hangouts team and said, "hey, we built this cool thing, let's integrate and Make Hangouts Great Again™!"
I assume this was met with initial enthusiasm, until people started digging in to the cost of maintaining the "legacy" Hangouts infrastructure and supporting all the new features asked of them. There were also probably product differences like "Allo wants to log you in via phone #, Hangouts is Google usernames" that slowly became irreconcilable. Resources shifted, and the roving band of engineers probably said, "We'll build our own Hangouts, with phone numbers and chat bots. In fact, forget the Hangouts." [1]
Along similar lines, the path to promotion while building a new product is far more clear than upgrading/maintaining a legacy product. It's faster to build, easier to show growth, and probably "more fun."
I think it's not so much "no leadership" at Google, just an engineering driven culture with a different set of incentives. Instead of "Darwinian" I think Google has a "probabilistic" product development process: Keep smart engineers happy/engaged, there's a reasonable probability they will eventually create 10x products, since 10x products are better for users/developers/Google than 2x products, it's better for Google to have churn on 2x products than not have 10x products, even if that churn burns users/developers.
The main problem is that while 10x products can offer breaking changes, it's generally not reasonably for 2x products to do so. I think many things that are originally intended as incremental changes are touted as 10x improvements to get around having to maintain interoperability (which implies maintaining legacy stacks), but result in a poor user/developer experience. I just think too few of the things touted as 10x improvements actually are, leading to, "deprecations of the old product before the new product is ready."
(Disclosure: I work @ Google but not on any comms products, these are my opinions and not necessarily those of Google)
ad 2) the job of managers is to say "no", not always but when necessary, a manager that does not say "no" is a bad manager, same as a manager that does not say "yes".
ad 3) consensus is one way to reach a decision. if enough people are involved its worse than throwing a dice. (if you ask enough people to find consensus about a color you always end up with grey, if you ask enough designers about UX, you end up with material design.
ad 4) focusing on one metric for too long will always be toxic. once a product is big / major or marketleader growth is no longer meaningful, but retention or fluffy metrics like user happiness. basing promotion on one metric alone must be seen as toxic (see shareholder value @ yahoo)
five) it's great that google has an open enough culture that public comments like yours are possible
I'd heard talk from one of the devs maintaining Hangouts for Android that there was a lot of technical debt in the project, which is part of the reason progress on improving it had slowed down to a crawl.
I guess my main problem is that the protocols are being tossed away and the continual rebranding. It doesn't exactly inspire confidence, even if the underlying tech is solid. It's one thing to have that probabilistic development going on underneath the surface, but once it bubbles up to a certain level, somebody has to have their eyes on the big picture, and there's little evidence of that, at least as far as messaging goes. I think that's what's missing here.
Hangouts was very tied up in Plus. You can see why XMPP would disappear around the same time: the big move was to getting everyone in that walled garden.
The newer ones I don't know. They all seem very mobile centered. But keep in mind these were developed over a decade, and the situation has been changing rapidly the whole time.
I seriously miss gChat/Talk. It was an app that did one thing and did it well, with no other BS. It served the user, not the company. And of course we can't have that, now can we?
Think it's quite obvious by now, being a popular chat service for power users (gChat) or even pretty popular with a grab bag of users because you're a cleaner experience than Skype (Hangouts) isn't enough for them. They want to be the Gmail of the chat world and will keep having do-overs until it happens.
I agree with your sentiments. When reading about messaging and mobile platform lock-in, one theme that resurfaces is the "stickiness" of iMessage. It blows my mind that Google has yet to throw their entire weight behind a single messaging platform. Even just copying Apple's implementation would be major win for Google's ecosystem.
Well, there's currently an invite only preview of a totally new experience, and it's focused on enterprise users, and no one really used this API, so what's the big deal?
Google abandoning a platform or dropping support for an API is hardly even news. They do this constantly. It's a hard lesson we developers should always keep in mind when selecting a platform, language, or toolkit.
Personally speaking: Relying too much on 3rd parties (especially from companies like Google that have a history of removing systems) can break things. Design your systems to be resilient and standalone as much as possible.
I recognized that quality was a little bit better on Duo with really bad network (50-200Kbit/s). I hope they do not forget to optimize Hangouts in parallel to Duo.
Hangouts is being pivoted to be an enterprise messenger (which is why the API allowing building apps for the old, consimer-focussed Hangouts is being discontinued.)
Is this what they used to break their XMPP support ? I used to be able to chat with Google contacts without logging into Google, but that doesn't work anymore unless the other party is using XMPP with a 3rd party client (which is nobody).
I was recently comparing the hangouts API to the join.me API for a project I was working on. I chose join.me mostly because I have been burned too many times by Google shutting down API's.
Advice: don't use Google API's for any business related stuff that you anticipate sticking around for awhile.
I don't get the connection. Google's cloud doesn't suffer from more or less lock-in opportunities than AWS for example. Messaging is just a mess. The cloud platform market is quite a different thing.
Real world but maybe slightly noobish question here...
When Google shuts down an API, how much of it is actually shut down?
For example: I know they said they shut down the free Translation API back in 2011. If you go to their website they go on and on about how you have to pay for every use now...except...with a very simple query I can still throw requests through a Google server for free translations without any API key. So it's obviously not actually shut down.
So when an API shuts down, is it actually shut down or does it keep on living just in secret hoping nobody notices? Is Translate a secret but maybe not so secret exception?
My guess is there are no guarantees. No support. You may get a response you may not. Your request may take 2 ms or 20000 ms. The service may get overloaded, etc.
Have you tried to use the Translate "API" in any non trivial way? Google is very good at detecting this and will block your request (or present you with a captcha).
75 comments
[ 4.1 ms ] story [ 139 ms ] threadHN discussion: https://news.ycombinator.com/item?id=2592399
It's because they add value right now that would be hard to add in any other way.
That doesn't seem to qualify as "quietly" to me. What did the author expect -- a full-page ad in the New York Times?
Should be that way, anyway.
- offering a free product; - letting people build stuff with it; - create some sort of business model and profit.
Google relies on the community to live. e.g: there would be no android without dev creating app for it, so they provide a system API letting you create something on it. Without that, Android would be an empty shell.
It's a win-win situation, but to work it needs respect from both sides. Here, I don't see any kind of respect from Google, just another beta product trashed.
They have the right to do it, but as a developer, I have the right to not want my time wasted. Hence, if Google wants its community to thrives, it needs to be nice with the people being part of it.
Having been burned by Google API shutdowns before, I just don't use them any more. Obviously they're under no obligation to maintain APIs, but if they want people to keep using them for whatever reason, maintaining trust is important.
Yes there's quite a bit of internal maintenance that goes on (as mentioned, lots of things change frequently, though generally people refactoring chunks of code will "upgrade" your code for you, since if they don't they can't submit their changes since you were a good engineer and wrote defensive unit tests to protect your code).
Maintaining a public API can also mean having: - Documentation (up to 15 languages) - Sample code/example apps (up to 7 languages) - Support (Stack Overflow, Quora, etc.) - An on-call rotation
(And keeping a zombie API available without maintenance, which is non-neglible in cost, is in someways worse than discontinuing it even if the service it interacts with still exists.)
Breaking peoples product is bad enough, but not taking the time to make a clean announcement such as on their official blog seems unprofessional to me. Hence the "quietly".
FTA:
> the notice came in the form of an updated Frequently Asked Questions page outlining the termination, and an email to developers active on the platform.
Any developers using the API in their product would've received an email.
It's possible they do not see any significant use. It's also possible they contacted some developers directly.
You are making some assumptions here to reach the conclusion they are acting unprofessionally.
Seems to cover anyone with an interest in the API more effectively than posting on any of Google's many blogs would.
On a side note, the API was so broken, badly documented and useless that when we evaluated embedding an app into hangouts it just seemed as a half-arsed effort by Google to expose an API, and it was clear that they didn't really want people building apps inside hangouts. which is a shame, it seemed as a nice platform to extend with collab tools. I'm not at all surprised this got pulled.
All of these can be banned from HN and I'd be happy.
I really liked the concept of the app, and the quality is certainly at least on par with other apps. But I have the strong feeling that it won't be around for long.
Let's hope Whatsapp supports network switching soon so that I can get rid of Duo.
In other words, when pigs fly.
[1] https://bitbucket.org/EionRobb/purple-hangouts
Is there any other company that's gone through quite as many IM offerings as they have?
Why?
Then Hangouts turned out to be a total mess, but by then they were committed to it. Meanwhile, somebody else was messing with AI internally decided to turn what they had in to a proper chat app, giving us Allo. I suspect Duo started as a way to rescue the video parts of Hangouts with WebRTC support, but that's all speculation.
Edit: oh, and let's not forget Google's Spaces too! Seriously, Google need some joined up thinking when is comes to messaging.
The funny thing is gChat was well-loved. They had a great starting point!
Then they killed it and made a bunch of shit nobody wanted.
you're all idiots.
Those certainly the optics.
> The funny thing is gChat was well-loved. They had a great starting point!
I know! And did practically everything their current 'solutions' attempt to do almost a decade ago.
I think most of the product fragmentation/churn at Google comes from four things:
Google hires lots of very smart, very creative engineers, and asking them to ["maintain legacy code", "answer support questions", "deal with rot but important tasks"] is a tough sell. Many of those people could easily go anywhere else and do whatever they want (this is the talent most companies are trying to hire for), and managers realize this.Since managers don't want to lose talent, they kinda let engineers do whatever they want, within a given field. The way managers tell you "no" is by not funding/staffing your product/feature--shifting resources to something else. I've very rarely been told an outright, "no, we won't build that" and am more often faced with "that's an interesting idea, let's investigate that more" only to not have sufficient headcount to "investigate that possibility" by building a PoC, etc.
I assume there probably were efforts to "upgrade" Hangouts to have AI integration and a more modern mobile interface vs replace it with Allo. I assume there was a roving band of 10-20 engineers who were in between projects and thought "wouldn't be be great if...", prototyped Allo together on Hangouts infra, and then went to the Hangouts team and said, "hey, we built this cool thing, let's integrate and Make Hangouts Great Again™!"
I assume this was met with initial enthusiasm, until people started digging in to the cost of maintaining the "legacy" Hangouts infrastructure and supporting all the new features asked of them. There were also probably product differences like "Allo wants to log you in via phone #, Hangouts is Google usernames" that slowly became irreconcilable. Resources shifted, and the roving band of engineers probably said, "We'll build our own Hangouts, with phone numbers and chat bots. In fact, forget the Hangouts." [1]
Along similar lines, the path to promotion while building a new product is far more clear than upgrading/maintaining a legacy product. It's faster to build, easier to show growth, and probably "more fun."
I think it's not so much "no leadership" at Google, just an engineering driven culture with a different set of incentives. Instead of "Darwinian" I think Google has a "probabilistic" product development process: Keep smart engineers happy/engaged, there's a reasonable probability they will eventually create 10x products, since 10x products are better for users/developers/Google than 2x products, it's better for Google to have churn on 2x products than not have 10x products, even if that churn burns users/developers.
The main problem is that while 10x products can offer breaking changes, it's generally not reasonably for 2x products to do so. I think many things that are originally intended as incremental changes are touted as 10x improvements to get around having to maintain interoperability (which implies maintaining legacy stacks), but result in a poor user/developer experience. I just think too few of the things touted as 10x improvements actually are, leading to, "deprecations of the old product before the new product is ready."
(Disclosure: I work @ Google but not on any comms products, these are my opinions and not necessarily those of Google)
[1]
second ad 1) awesome
ad 2) the job of managers is to say "no", not always but when necessary, a manager that does not say "no" is a bad manager, same as a manager that does not say "yes".
ad 3) consensus is one way to reach a decision. if enough people are involved its worse than throwing a dice. (if you ask enough people to find consensus about a color you always end up with grey, if you ask enough designers about UX, you end up with material design.
ad 4) focusing on one metric for too long will always be toxic. once a product is big / major or marketleader growth is no longer meaningful, but retention or fluffy metrics like user happiness. basing promotion on one metric alone must be seen as toxic (see shareholder value @ yahoo)
five) it's great that google has an open enough culture that public comments like yours are possible
I'd heard talk from one of the devs maintaining Hangouts for Android that there was a lot of technical debt in the project, which is part of the reason progress on improving it had slowed down to a crawl.
I guess my main problem is that the protocols are being tossed away and the continual rebranding. It doesn't exactly inspire confidence, even if the underlying tech is solid. It's one thing to have that probabilistic development going on underneath the surface, but once it bubbles up to a certain level, somebody has to have their eyes on the big picture, and there's little evidence of that, at least as far as messaging goes. I think that's what's missing here.
The newer ones I don't know. They all seem very mobile centered. But keep in mind these were developed over a decade, and the situation has been changing rapidly the whole time.
Below the team drive one.
There's a lot of confusion (because Hangouts != Hangouts) about this closure, but this line from their FAQ sums it up pretty well.
Advice: don't use Google API's for any business related stuff that you anticipate sticking around for awhile.
When Google shuts down an API, how much of it is actually shut down?
For example: I know they said they shut down the free Translation API back in 2011. If you go to their website they go on and on about how you have to pay for every use now...except...with a very simple query I can still throw requests through a Google server for free translations without any API key. So it's obviously not actually shut down.
So when an API shuts down, is it actually shut down or does it keep on living just in secret hoping nobody notices? Is Translate a secret but maybe not so secret exception?