3 ms·
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 wit
by talideon 10y ago
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.
- dilap 10y agoSo, basically, no leadership at Google. 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.
- pg_is_a_butt 10y agomore like too much leadership. everyone is a leader. everyone is conquerer. you're all idiots.
- talideon 10y ago> So, basically, no leadership at Google. 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.
- asciimike 10y agoPeople 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) [1] https://www.youtube.com/watch?v=e35AQK014tI https://www.youtube.com/watch?v=e35AQK014tI
- patmcguire 10y agoHangouts 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.