Google discontinues support for hangouts API
siliconangle.com
siliconangle.com
HN 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.
There's a lot of confusion (because Hangouts != Hangouts) about this closure, but this line from their FAQ sums it up pretty well.
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.
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:
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
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)
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.
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?
Below the team drive one.
Advice: don't use Google API's for any business related stuff that you anticipate sticking around for awhile.
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.
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.