As a Googler (who does not work on Hangsout) my own personal opinion is that I fully agree with the EFF here:
"In public explanations of its dropping XMPP support, Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable. Releasing the specifications for Google Hangouts would be a good first step. Releasing free/open source clients and servers should follow. It's clear that some of Hangouts' video features have been implemented in some very Google-specific ways. But that's no excuse for leading us toward a world where the only practical choices are proprietary chat clients and protocols."
I hope the specs at some point are opened. The Hangouts team probably has good reason at the moment to strictly focus on a core set of functionality and get it working with good UX on all the platforms. People are complaining that stuff like voice calling, and some Talk features are missing, but it's probably due to focus on shipping something that works good first. It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. In the late 90s, early 2000s, I remember using reverse engineered Java libraries that could talk to these services.
Google Wave was done in the opposite way, as was Open Social. They came with specs, but they did not focus on core user experience in the beginning. It's hard to win with open specs without getting consumer traction.
As another Googler, I mostly agree with you, but I also sympathize with the product and engineering teams.
They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use.
Sure Hangouts could publish their protocol like Wave did, but Wave was a complex mess of different protocol formats and transports and publishing that as a "standard" was way premature. Who knows how good the current Hangout protocols are, or how well they might play with real standards like WebRTC. It's probably too early for them
I remain optimistic that these things can be standardized in the future.
I agree with you, history is pretty much full of committee designed specs that failed, but full of defacto standards from commercially successful products that are later standardized.
A lot of the features, like group video calling, first need their use cases polished by user trial, then hopefully, they can be implemented on top of either existing standards, provide inputs to change those standards to satisfy the requirements.
OpenID/OAuth is an instructive example. The specs were built very much driven by committee oriented thinking, and the resulting UX implementations out of the gate were much more complicated than the Facebook Connect experience. I think actually focusing on the "design" aspect of how users use it, and then extracting the relevant technical requirements into a spec works better.
Here's how I see it ... my company is currently using Skype and for us Skype worked really well. By using Skype for example I can call any number in the U.S. for reasonable fees, something which Google doesn't allow me to do, since Google Voice is not available in my country. Skype's clients for my Android or for my Ubuntu laptop also work well.
Basically, Google is late. And the only thing that would make us switch to Google's alternatives would be an open protocol (not necessarily approved by a standards body, but at the very least with the specs published). That's because we don't trust Skype, but we would trust a protocol that has public specs. Even more than that, we would trust an open P2P protocol that wouldn't drop our connections to our list of contacts if your servers die.
And no, you won't win us by shoving that awful chat box down our throats, like in GMail or in Google+. You have to do more and be more than Skype currently is. Because you're late. And you won't win with consumers either, because consumers are already using Facebook's video chats, which is integrated with Skype. And you're late to the party all over the board, even though putting moustaches on people's faces is kind of cool.
Speaking of Skype and open P2P protocols, since Skype was acquired by Microsoft, want to bet that they'll up-yours on this one?
> And no, you won't win us by shoving that awful chat box down our throats, like in GMail or in Google+. You have to do more and be more than Skype currently is. Because you're late. And you won't win with consumers either, because consumers are already using Facebook's video chats, which is integrated with Skype. And you're late to the party all over the board, even though putting moustaches on people's faces is kind of cool.
Free group video chat and Hangouts on Air (free YouTube exporting, basically) are enough for me to seriously consider Hangouts over Skype for most interactions.
Wave was built on XMPP wasn't it? If I understand correctly XMPP is fully extensible which means Google can add whatever data they want and still be inter-operable with all the common parts and then define the new parts.
Video seems like it could be out of band using WebRTC and initiated by new XMPP data.
Watching the Wave introduction presentation from Google I/O 2009 it's hard to buy that a new protocol was needed.
i'm sorry i fail to see the argument. it's perfectly fine to have your own proprietary format, but publish the specs so others can interact with it. who said anything about ietf having to sign it off.
This is exactly right. It is a false choice to suggest that "open" means "slow". But that is fostered in part by folks who think "open" means "community driven."
It is perfectly reasonable to publish the specs of what your doing with no commitment of support, simply for folks to see and possibly use at their own risk.
That said, the reason companies don't do this is often one or two reasons. Reason one is that it results in a 'noisy' side channel as people who read the specs share their opinions, but they also get bent out of shape if something they said, or think they said, appears in the spec later. The other issue is that there is always a sanitization/prep process to take essentially internal information about a service and create an external representation for consumption (even if that consumption is unsupported).
I certainly don't think open means community driven, and there are many more than two reasons companies don't publish unsupported specs.
One of the biggest is that they're just not ready for 3rd party clients in any fashion. The protcol may be _very_ rapidly changing. The auth workflow might be tied to some other system. And, regardless of messaging to use at your own risk, if you publish people will get mad when you break them. Finally, it's just a lot of work to go through if it's truly unsupported.
If your protocol is that rapidly changing, you shouldn't be launching anything to the public, period. Especially if you're replacing an existing service with it.
If it wasn't being used by the public, then the protocol wouldn't be rapidly changing. Internal use, even by a company as large as Google doesn't give enough variety of circumstance and use-case to drive the changes.
Once you've published it, you're under pressure to remain backwards compatible. But until you've got experience with it working in the real world, you don't know what really works. And then before publishing it, you need to go through a lot of work to make the published spec clear enough that someone else can reimplement from scratch and it will actually work.
For all of those reasons, there is pressure to not publish a spec until after the technology has matured.
This is mostly crap, to be honest. It's all about messaging.
I wrote most of the first version of the wave federation spec (I cannot remember how this happened, but im pretty sure it involved being in Sydney temporarily, alcohol, and Soren being Soren. I'm fairly sure I got the short end of the stick on this one).
It was absolute and complete crap.
But it kinda worked.
We were clear it was a first draft, and folks understood it would completely and utterly change.
Within an hour of publishing it, the wonderful XMPP folks emailed me and asked me to fix a few things (like accidentally using some reserved namespaces/etc), and asked how they could help, pointing out the XEP process, and pointing out we were doing some things others were working as well.
With their help, it ended up as a "mostly sane" spec.
Realistically, pressure comes from improper messaging.
If you tell people "here's our current thoughts, in spec form, this is all gonna change", you can do a lot of work in the open without too much customer pressure.
Now, will this slow adoption?
Maybe, it depends on what kind of product it is.
But the argument that you get this pressure out of thin air is wrong. Pressure is mostly caused by self-inflicted wounds where people are not being clear about the state of the world as they see it.
That is an excellent point, and I'm glad it worked out for you. What I'd be more curious about is how well it would have aged had it not been discontinued. Comments below suggest that if you had longer to do it you would have done it differently. Which suggests to me that developers 5-10 years later would likely have wanted something quite different.
The reason that I'm cautious is that I've suffered through code that has to jump through hoops to remain compatible with something someone thought was a good idea 10 years ago. Things that seem like a good idea now don't always a few years later. When you control both ends, you have a potential upgrade path to fix it. When you don't, you're stuck.
But for most of the API's and protocols we are talking about here, 5-10 years later, developers always want something different, regardless of whether you designed it right or wrong. That's just the nature of the speed of our industry.
I'm, of course, not suggesting that you should never try to design something that will last 5-10 years, but in most cases, you can only standardize what people want to use now, and hopefully design a way of extending the protocol to be able to standardize what people want to do in the future as well.
As you say, otherwise you have to try to remain compatible with something someone thought was a good idea 10 years ago.
That usually means it wasn't a good idea 10 years ago, it was something that 10 years ago, they thought would be good in the future, and they predicted wrong.
Past that, sometimes you have to just accept that the useful design life span of some protocols is not going to be as long as some customers would like.
Are you talking about the base64 encoded protocol buffers here? The Google Wave Federation draft spec reminds me much more of XEP-0239[1] than anything else.
As a reminder, here's how to send a tiny update to a wave:
This isn't necessarily true. Rust, for example (disclaimer: I work on Rust), was open very early on, and the language when it was released looks almost nothing like the language now. The various transitions have been painful, but the community is really understanding and helpful, and the language has a small but vibrant community as a result even though it's far from production ready.
It's this. You end up living with the consequences of your v1 design almost indefinitely, and that's a major tax on a team for what can sometimes be relatively minor benefits. Even in areas like Android where you _have_ to publish APIs, etc, I've seen the regret teams can have about a standard or API that seemed like a good idea at the time but turned into a major albatross.
IETF is probably hyperbole, but it's a valid concern. Publishing an open standard leaves you vulnerable to people expecting you to support it, especially in terms of backwards compatibility. If Google is agile and pushes a new version of the standard (obviously supported by their infrastructure) weekly that breaks backwards compatibility (which they can do because they control the entire ecosystem), they will be criticized for not taking openness serious, because competing implementations will always be playing catch-up and thus never become a viable competitor.
A completely good faith (and perhaps naive) read on the situation is that they need to settle the protocol to the point where they can commit to some level of good faith long term support and giving proper notice of breaking changes, then they'll release it.
The point isn't to get IETF to "sign it off". The idea is to get some extensive peer review from a wider audience, so that you don't end up with a widely-used protocol that's difficult to implement, missing important features, or both.
A single vendor working in a vacuum is how we end up with horrible kludges like the Public Suffix List. http://publicsuffix.org/
A lot of the failed IETF standards are ones where the IETF was constrained to trying to fix an already-deployed protocol after the fact.
I can sympathize with this notion, except that there are plenty of similar protocols that implement proprietary stuff on top of XMPP. Cisco UC, for example.
I'm not so optimistic. If their intention was to open and publish the protocol and specs, they'd announce this intention and avoid (or at least minimize) this PR backlash.
> They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use.
But the only feature that matters in a messaging app is knowing the person you want to contact also uses the app. In this case by choosing to "innovate fast" they are guaranteeing failure.
I think this auto meme that "open standards" = "unable to innovate" is complete and utter hogwash.
Reminds of a project posted to HN a while back that had taken someone a month. I replicated it in the evening using all open source, open protocol components instead of being stubborn and falling prey to NIH syndrome.
As a bystander, this comes across as "we aren't smart enough to figure it out", or "we are smart enough, but this is a business decision with ulterior ("evil") motives". Neither of those look positive for Google.
I don't expect multi-person video conferences to work, but plain old textual messages, as already work today, shouldn't be a problem.
Wanting to maintain a competitive advantage is not evil in and of itself. Google Hangouts is far from a monopoly and they are under no obligation to make every product completely open. Not only would it be competitively stupid, but it would also hinder product development to be so heavily tied to standards publication.
Google has a marketing approach of being different by not being "evil", being open & accessible, and having smart people work there. The steady drumbeat now is one of being no different than the other guys. Google held themselves up as taking the high road, which is why so many are calling them out on this (and why people don't call out other companies for the same antics).
The issue isn't even about making hangouts open, but rather about chat messages in hangouts also being able to relay with federated XMPP servers - something GTalk does today just fine and has done so for many years.
| It's inevitable people will reverse
| engineer the client, as was done with MSN,
| Y! Messenger, and AOL
That's not the end-all be-all though. I remember that AOL was pretty aggressive about keeping unauthorized clients off of their Oscar protocol (the original protocol was 'toc,' IIRC and didn't support all of the 'advanced' features like Buddy Icons, idle times, etc). At one point, AOL's servers would require random chunks of the official AOL IM client's binary as a protection measure. Obviously you can get around this, but it's not something you can do out in the open (distributing AOL IM with, say, Pidgin/libpurple would be copyright infringement).
As an Android user, the new Hangouts app that replaced the Talk app feels like one step forward and four steps back (in terms of UX). The one step forward is that the chat windows look prettier. The four steps back, from most annoying to least annoying:
1) Chat windows give me no indication of the presence of the other participant(s) in a conversation. If they sign off, I have no idea they've signed off. They frequently get messages from the tail end of a conversation much later, which is confusing for them.
2) The contact list is in alphabetical order, regardless of their presence. Talk used to separate online contacts from offline ones. This was nice because I have a lot of contacts in my gmail account, and only a dozen or so ever sign in to chat. There's no obvious way to change the sort in Hangouts.
3) The UI is higher latency. If I touch a notification in my tray, I often have to wait upwards of two seconds for the Hangouts app to load. The various screens within the app also take longer to load.
4) I used to have a custom notification set when I received a message. Hangouts replaced it with its own and there's no obvious way to change it back.
I hadn't noticed Hangouts had abandoned XMPP. I find this rather unfortunate. Adium on my Mac still connects fine, but for how long?
> It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL.
I hope you're right, but to my knowledge, this has never been done with Skype, and to this day you can only call a Skype-using friend/colleague if you use the official, closed-source Skype client. So let's not be sanguine.
I hope you're right, but to my knowledge, this has never been done with Skype
It was done, but Skype has a rule about this which they apply quickly: Press the cease and desist button.
I've been using IM clients with support for skype, only to see it get dropped. Which makes it doubleplus sad that MSN (which was fairly interoptable) got ditched for Skype and not the other way around.
The only "supported" way for third party IM clients to access Skype's network without risk of lawsuits is piggybacking on its COM API and have the user download and log into the official client, and have that handle all the actual communication.
You probably think "He's gotta be kidding", but sadly I'm not.
TLDR: Skype does not only not care for or provide an open-source implementation, but they are actively fighting it.
I was so hopeful they would release that at a library so all the open-source IM clients could link to it and get Skype integration. They indicated, years ago, that it was going to be released, but as far as I know, you can still only get it via a developer account.
I was always under the impression that the core Hangouts protocol _was_ the Wave protocol, in which case it's _already_ an open standard. What would be awfully nice is if Google (which is a category mistake - what I really mean is "the Hangouts team") would clarify this, release any updates to the protocol that they've made, and perhaps define something more than the weak API provided for the current Hangouts platform.
In particular, the right test of openness is this: can I build an interoperable client that could participate in a Hangout as a first-class entity?
As a former google wave developer, I can only say that I hope this isn't the case. Wave's federation protocol embedded an XML-like data structure (wavelets) in protobufs (binary) which were then encoded using base64 and embedded in XMPP extensions (ie, more XML).
Here's a thought: what constitutes a very smart person? How often do those occur in the global population? Now, how many people are there on the planet and how big is the company?
The Earth may not be big enough for that to work out. This is before you remove people who aren't in this industry, people who are too young or too old to work there, people who don't want to work there, people who DID work there and left, and so on.
It might explain a lot, particularly when they go on a hiring bender. Where are all of these new people coming from?
Thats been the case with xooglers interviewing with my company. It seems like there are a lot of average to below average people working at Google for some reason. Or at least the below average people interview a lot.
The internal architecture of wave was very abstract.
a lot of this abstraction was exposed in the first federation spec, somewhat due to necessity, somewhat due to lack of time.
> I was always under the impression that the core Hangouts protocol _was_ the Wave protocol
I've never heard this. Do you have anything that backs you up? I found a Quora answer that says that the Hangouts API is based on the the Wave API, but that's it.
With the implicit assumption that there is any expectation or obligation for Google to conform to some level of openness, especially in (relatively) new products, as if it were paid for with taxpayer money and they owe us something in return. We can say that we wish it were more open, or that we won't use it because it isn't open, but I don't understand the attitude that they are committing some colossal ethical lapse or failing some social contract by not having it be more open at this stage.
The EFF is correct. Google is in lock step with the US governments plans of the complete erosion of our privacy rights. Google knows a lot about us all and the feds want that info.
It certainly seems as if it does. They repeatedly pursue strategies to gain access to private data and actively work against compromise or safeguards. If that is too strong, I think everyone has to agree that shoring up privacy rights is something they are clearly hindering.
It always seems to be my look Google is heading in the direction of a WebRTC based messaging service/client and then suddenly the product group veers off into another direction. WebRTC has been nearly here for several years now but it does seem to arrive...
It seems they'll use open standards only as long as it serves them, but when they've grown big enough to dominate the competition, they'll turn around in a heartbeat and exploit that.
Just look at what they did to the open web with Chrome.
First they said "Web standards are important, so here is a good, fast and web-standards compliant browser. Feel free to try it". After a while that was not enough, and on every single web-page they had they had a big "Use Chrome!" ad for every visitor not using it already.
Once they had gained enough dominance, suddenly Google started using non-W3C HTML in their production web-sites. HTML which had not been fully drafted or ratified and which was only available as they saw fit in web-kit.
And then all the other non-Google browsers were suddenly "slow" on "adopting new HTML standards". Basically through its internet dominance, and now its browser, Google pushed through its own implementation of proprietary HTML features as standards other browsers had to implement, without any discussion, feedback or other input.
Google just decided that they alone should dictate how the HTML-standard is from now on.
After seeing that happen, I lost all belief in Google as a company which I will rely on for anything more than I strictly need to.
> It seems they'll use open standards only as long as it serves them, but when they've grown big enough to dominate the competition, they'll turn around in a heartbeat and exploit that.
I don't see how Google is dominating the competition. Gchat used to be a dominant player, I believe, but that was before mobile existed. I think the dominant players now are:
iMessage. Propriety, only runs on Apple devices, can only communicate with other iMessage users.
Facebook Messenger. Proprietary, only runs in Facebook site and app, can only communicate with other Facebook users.
WhatsApp. I think based on XMPP? Only runs in WhatsApp application, can only communicate with other WhatsApp users.
Notice that every single one of those is a walled garden.
Are you from the future? Because Chrome is leaving webkit in the coming weeks but they still haven't yet. Chrome uses the full set of W3C standards in use though webkit and not any custom version of it.
This is not the case at all, though. WHATWG is a good example of several browser makers cooperating. The only thing entirely Chrome-only is NaCl and it's not exposed to web pages (just extensions).
It let people seamlessly move to gchat from compatible chat services, which led to quick uptake (it's the only reason I started using pretty much as soon as it was available) and got Google a lot of chat logs to datamine.
Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable.
Indeed. If basic XMPP wasn't good enough for whatever reason, (or SIP or whatever other protocol already exists) then the "right thing to do" would have been to work with the respective standards body to extent / modify an existing standard to overcome whatever the restriction was. OR, as a secondary option, Google should at least release detailed specs for their new protocol, along with an open source reference implementation.
Creating more new walled-gardens is not a positive step forward here.
To be fair, releasing an open source reference implementation takes a separate engineering effort. You can't just take Google services engineered for Borg/Spanner/et al, and drop them in OSS. It took Google Wave team a lot of resources to open source a non-Google-datacenterized version. Hangouts is also intertwined with lots of other Google services, so it's not a matter of just code dumping.
Imagine that you have a small team trying to hit 3 platforms (Web, Android, iOS), in time for Google I/O launch, packaging up an OSS release along with spec document is probably the least priority.
If the reason they can't document is because they have a small team, then this is an easy solution for Google - hire some people to document the system. They don't even have to be in direct contact with the actual development team, just access to the source code and developer design documents should be enough. For a company the size of Google with the amount of profits they make, 'small team' is just not an excuse for anything.
The move is definitely deliberate, they can't have Skype come in and allow people with Skype to make calls to hangout when the hangout client can't make calls into Skype. It would make them look bad.
I think you've got it backwards. If Google was really concerned with making Hangouts a competitive moat by blocking interoperability, why would they be plowing so much effort into WebRTC, a technology which pretty much commodifies Hangouts and makes it possible for anyone to implement peer to peer video or audio group chat? Skype is actually trying to block WebRTC, as is Cisco WebEx, and Nokia.
I don't really see that Google would have anything to gain by blocking interoperability with Skype, Skype is the market leader, it is usually those who are not market leaders in a particular area to push for interop, and usually those who have a hold on the market to resist.
I think that the reason that these aren't contradictions is because Google isn't a person. So if they do one thing that is open and a second that is closed, we aren't using it as evidence to search out a human being's soul or true intentions. An organization of this size can do both things at the same time. If there was a master plan, you could say that the openness is great PR that allows them to do closed stuff without getting as much of a backlash. But again, that is just anthropomorphic BS. In one case people within a personalityless organization are doing one thing. In another case different people in the same organization are doing another. The two cases should be treated separately.
I work at Google, openness is not PR, it is part of the culture. People here believe in it, which is why I was the first person to bitch about this, and I'm not alone.
Often if someone is doing something that cries for an interop spec, but they aren't doing it, chances are they have some good reasons that don't involve a corporate master plan to "talk about openness to make people like us, but secretly silo-the-world" Often, it revolves around having a task list of a gazillion things to work on and prioritize, and often open-spec is 'nice to have, but not critical for launch' kind of thing.
Really, when you look at the market, 99% of the folks are shipping closed apps, where more time is spent on cute emoticons than on infrastructure. Google risks becoming "open, but irrelevent" in a market of iMessage/WhatsApp/FaceBook messenger, where a niche audience is supremely happy they can build third party clients, but which becomes a service unused by the great unwashed masses.
The network effect requires other users to increase value, so they've got to double down on things which delight and wow end users first, and developers second.
All good questions, but I think the idea of open source or open spec is not an "either your 100% or your not". For me, it's more about attitude and orientation, not achieving perfection. Even companies which are primarily open source non-profits keep secrets.
I look at Search and Ads and Datacenter secrecy being closed as necessary evils to fund everything else, you've got to have a rich uncle who will let you work in his basement if you want to work on open software. Search in particular, represents a challenge, since even if Google were to just ship the source to it's search engine, it would likely devalue the search engine by showing blackhat SEOs exactly how to spam.
Like I said, the natural proclivity of many Googlers is to lobby for open specs and source, to bitch and moan about it internally. Sometimes they win, sometimes they don't. Many googlers don't like secrecy. Google will still have a competitive advantage over most other companies because of the datacenters, so the source availability is often not a threat IMHO. I could give you the source to Gmail, chances are, you won't be able to run it competitively without investing a billion dollars in infrastructure.
That said, Google has published papers on it's crown jewels, like Spanner, Borg, GFS, Map/Reduce/ et al, stuff which makes its services scale very well.
Very true, but the network Google is looking to expand is Google+. The point of having a more competitive IM system is not to build a IM network, but to bring their IM users into the Google+ network. Therefore, a proprietary solution where users are forced to use Google's service is a feature.
Disallowing third-party clients can even be spun into a move towards openness: since the ultimate goal is to have everything on the open web, the main interface should be the one on Google's website; native clients are a necessary less-open evil on current mobile platforms, not something third parties should waste time on.
It seems that there are any of a number of non-open parts to the Google culture. How many server machines do you all have? How are dirty SEO methods detected and thwarted? What are the details on the influence made by the $18M spent in lobbying D.C. in 2012?
That's not to say they shouldn't be private. It's me asking you what it means to be "open" as part of the culture.
Openness being part of the culture doesn't mean that everything Google does is disclosed publicly. Openness to the public, and openness within a company are two entirely separate issues, and there are obvious practical limits to both (at different levels) if you want to be competitive.
I believe the previous poster was only talking about openness to the public. (Is Google distinctively more "open" internally than, say, Microsoft or SAP? I think that's a different topic, and one that I'm not so interested in.)
As I wrote, I agree with the view that parts of Google are not disclosed publicly.
My question is, we all know that Google has some closely held secrets. In that case, how do I tell if (public) openness is part of the culture? Can I use that to estimation method if the level of openness has increased or decreased at Google over the last decade?
How much is "open" with Google that actually matters to the company being a company? As in stuff that makes Google money? Search, Adwords, almost all data relating to either of those? The data Google has that "personalizes" search? Etc
WebRTC gives Google's solution to group video chat an advantage over both established competitors like Skype and newer competitors by allowing them to integrate it into the GMail web application. Suddenly, everyone who's got a GMail account can be called via Hangouts - instant network effect.
Sure, anyone else can also implement group video chat relatively easily thanks to WebRTC, but why would people use the new services? All of the people they'd want to call are on Hangouts, not that new service - and thanks to Google killing federation, you can't call Hangouts users from other services.
True, but I still think they should commit to doing it eventually. Even if they just came out today and said "We'll have an OSS reference implementation and detailed spec available within 6 months" I think most people would be OK with that (as long as they followed through).
But just throwing a new protocol over the wall and creating more walled gardens is not cool.
That's a good question. In strictly financial terms, it would be hard to quantify, because you wind up talking terms of subjective measures like "user good will" and "brand perception" etc. There might not, in fact, even be a strictly financial argument that favors doing this.
I still think it's the Right Thing To Do though. I know the old saw about "don't be evil" is probably over quoted and that it's just a tagline and not a binding legal agreement, but for a company like Google, given their history and reputation, this feels wrong.
Standards are a mechanism that allow new and innovative market entrants to compete with established giants.
Now that google are an established giant, there probably isn't much financial incentive for them.
You're right that it's the right thing to do though - it leads to more competition, better services for consumers and faster innovation, enriching humanity.
In the past, google knew that having a healthy web platform was more important to their long term profits than huge numbers of tightly tied in users. That no longer seems to be the way they see things.
Is the implication here that Google would like to do this but cannot because it doesn't have enough time and resources? If that is the case and they care for openness, why not just wait to kill their open product until they are able to do the right thing according to their values with the new product? After all, Talk already exists and works.
It is hard to say whether Google as an organization is something you can characterize as "nice" or "mean" but the actions taken here have clear implications. They are deleting the open protocol and replacing it with a proprietary one. Whether their heart is in the right place or they just have some rotten circumstances to deal with doesn't matter really. Perhaps Microsoft with Skype might say that they are closed on purpose but Google will say they are closed by accident because, well, you know, of all the things they can do, this is the one that is too hard. But it doesn't matter. It is the exact same effect.
> To be fair, releasing an open source reference implementation takes a separate engineering effort.
So what. More effort that's required to do things properly. Create a protocol, publish it, start deploying (especially if it breaks what's working now). Doing things the other way around creates a horrible mess.
And in the same time, their competitors (Facebook, who isn't known for being open exactly) can use the same resources to push out more features.
Being open only helps in that users see it as a feature. Right now, not enough users see it as a feature to make being open as a priority for this product. And those who do prioritize openness are already starting to move away from google because it's gotten too big.
Who cares what kind of features others add, if they can't even communicate with each other. Google of course define their priorities. So far they claimed that interoperable protocols are basis of their features. If it's the features they are after and they don't care about interoperable protocols then they aren't better than Facebook and other "competitors" who disrespect their own users by not letting them to communicate with others, as if we are in the stone age of computing, when one couldn't send e-mail from AOL to Compuserve. If that's the case, it should be a good reason to advise others to dump Google services.
They gain advancing interoperable and connected IM network. If they are OK with creating another walled IM mess for selfish interests (as if we don't have enough of these Skypes, Whatsapps and etc.) then let them be boycotted.
> the "right thing to do" would have been to work with the respective standards body to extent / modify an existing standard to overcome whatever the restriction was
Generally, the way you work with a standards body to extend or modify an existing standard is the same way you work with a standards body to create a new standard, and that is:
1. Build a prototype product,
2. Get some use on it so you can find and knock off the rough edges,
3. Once your comfortable that you've knocked off enough of the rough edges, submit the new or revised protocol to the appropriate.
Larry inspired me with his talk the other week, in which he lamented that Microsoft (and others) were playing silly zero-sum games in their own closed ecosystems.
I've immediately stopped using as many Google products as I can in response to this after trying out the new hangouts a few days ago and finding I couldn't connect with my friends that weren't on Google.
I'm sad - this directly removes choice and is a sort of lockin. I now can't use Google to communicate with people who choose not to participate in Google's ecosystem for whatever reason.
By leaving, I also make it harder to communicate with many friends who are on Google.
The bigger issue here is that Google is integrating everything into G+. They are moving away from being a search engine, towards being a social network with better search capabilities than Facebook. The problem is that the average Google users (read, non hacker, and generally not computer smart) does not understand the changes. They just go to Google to learn about a new chicken recipe, or what side-effects does Singulair has. They don't go there to socialize. And Google is forcing this into everybody. Which is a significant deal, because for a lot of people out there ( a lot) Google is the internet. Just like AOL was in the 90's, Google is now. They are diluting their brand, and going in every direction. Before you say anything else, I use google products. I like Google. I remember their old nerdy logo. I loved how they took on the old search engines of yore, and beat them at their own game. But it has reached a point where Google is now a faceless corporation simply driven to profit. All of their actions point to that. They seem to no longer really care about the users. Just like IBM, MS, and all the old tech giants. Management has taken over. The true hacker spirit seems to not be found anymore.
Disclaimer: As a Google Engineer, this is my understanding of Google+.
I think Google+ could be understood better once you realize that Google+ is not a social network in the traditional terms. Google+ is truly a social layer across all Google services.
The average users who are just looking for a chicken recipe (as you mention) would always love to find the particular chicken recipe that their friends have recommended. Even more relevant to me (since I don't cook) is that if a friend finds a todo app useful, I'd definitely want to know.
If Google has this social layer, it'll really unleash more expressive search results that would help the vast majority of users. This is what Google+ is.
Google+ is literally Google Plus More.
Of course, to get these benefits you really have to start using Google+ on different Google services. I guess this is the reason that Google employees who actually use Google+ services continue using it and prefer if their friends do it too.
Those are all things that nobody wants. Not only do we not want them, we abhor the thought. That's what Google isn't getting.
We just want to search. Or keep using email like we have been for a decade. People switched to Gmail because it was like hotmail with a nicer interface and a large mailbox limit.
Maybe some people do want those other things. That's fine, give them their own corner, let them play with the toy social network or social layer or however you want to pitch it. Stop force-feeding it to the rest of us. I don't want to know what my friends are searching for or what recipes they like. It's just unwanted noise.
And let's call a spade a spade - "sharing" has very little to do with friends and everything to do with advertisers. It's very disingenuous and insulting of Google to pretend that the primary purpose of +1 buttons is to "share with friends".
> And let's call a spade a spade - "sharing" has very little to do with friends and everything to do with advertisers. It's very disingenuous and insulting of Google to pretend that the primary purpose of +1 buttons is to "share with friends".
This is calling a spade a turkey. How did you possibly come to that conclusion?
> I don't want to know what my friends are searching for or what recipes they like. It's just unwanted noise.
On the right-hand side of your search page, there's a button for turning off personalisation.
On the right-hand side of your search page, there's a button for turning off personalisation.
For now. Maybe not tomorrow. Google has already demonstrated its willing to run roughshod over some of its users in order to advance its agenda for Google+, which clearly is much more in Google's interest than the interest of Google's users.
The information I store with Google is actually quite a bit more valuable than anything I might post on Facebook so their recent willingness to stuff all their other services into a shitty social network with a creepy "real name" policy has me eying alternatives.
If they want me to trust them with that much information then what they seem likely to do with it is extremely relevant to my decisions about how much I rely on them today.
Even a few years ago I had no second thoughts about depending on Google for critical web services but their tactics with G+ have me seriously second guessing them.
I think that the problem is not the personalisation but all the stuff they had to build to make it happen, the side effects of prioritising Google+.
I don't mind a functionality that I can disable, the real issue is all the stuff I need to go through to have that functionality that turns out... I don't need or want!
So Hangouts will provide some advantages over XMPP, at a cost. It doesn't matter I don't really need/want the improvement if I can't keep using the stuff that was already useful to me.
The problem is that not everyone knows everything about 'the market'. Advertising partially solves that, but relying on your social graph is also a really good way to find out which kinds of things in the market you'd like.
If I see 50 restaurants nearby, but ten of them have been +1'd by people I know and trust, that's great and helps me. And I'm happy to recommend my favourite places, books, games too. I think it's an important problem that Google (and others) are solving and it actually reduces the need for advertising.
What I really hate though is facebook selling their 'likes' to appear in your feed again and again, long after you liked it. It's a lie, because it gives the impression that you're liking it again, right now, which might not be true. For example let's say you liked tiger woods, that might be news feed worthy at the time. And if someone searched for tiger woods then yes show the like as part of that information, but to put it up again at a later date, say immediately after he's caught being dishonest is misleading people and sending the wrong message. The fact that they're being paid just makes it worse. What's more they don't even show you what likes they're putting on on your behalf in your own news feed which would give you the option to unlike <x> if necessary.
Good and fair points. The big issue here is the fact that all of what you said is tied to a persons real life identity. I think people should have the option to choose whether they want to surf the web using a pseudonym, or doing it with their real name. Google forces people to use their real name in order to be able to squeeze out more profits per user.
Socially slanted search is the future, and I agree with that. But not in the way that Google is doing it. Not everything has to be social.
I'm not entirely sure whether or even how real names could really help with increasing profits for online advertising. I'd say interests and preferences would matter but I can't see how the name would.
Google+ does support nicknames and pseudonyms now, but yes there is a preference for users to use their real names. Also personally, I don't really think real anonymity truly exists on the web anymore and in such a scenario I trust the bigger companies more than the thousands of tracking companies but I'll write that rant sometime else.
Coming back to real names in Google+, I'm not entirely sure why Google+ prefers it, but I think it ties in with generating better social signals. Facebook really showed the way here. If people use their real names it's easier to find real friends. I also would care about signals/content created by friends with real names.
I'd care more what a particular friend I know has recommended more that what rockstar_spongebob has. Also if I'm rockstar_spongebob on a website, I'd lose the incentive to connect with only people who are my "real" friends and I'll end up adding lots of people at random. I think this is what happened on Digg and these "friendships" had no true affinity (atleast on Digg). I truly would never have cared about restaurants recommended by my Digg friends. Of course these reasons are just my guesses and I really have no research/data to back it up.
I think it would be fair to say that you're trying to compete with google. Yahoo! is a Google competitor, Microsoft is, Apple too. The rest of us, we're just trying. As long as we're not on their radar we've failed to establish any mode of competition that matters. Even DuckDuckGo (for now) does not qualify.
>I think Google+ could be understood better once you realize that Google+ is not a social network in the traditional terms. Google+ is truly a social layer across all Google services.
This is what we hear all the time from google executives, when explaining what google+ is. As a user, I dont see any difference between google+ vs facebook. In terms enabling social interaction, google+ is same as facebook. posting picutres, videos, chatting with friends, liking stuff on internet, games, etc. Also dont see why they try to spin this in any other way.
Google+ goes a step further by integrating into search,Ads etc.
I disagree with their mobile efforts they need to start unifying all these disjointed services, like they did with hangouts. It makes sense to associate your google accounts with your google mobile account along with your data storage as well.
We have different concerns for how our data is used with respect to different accounts. I certainly don't want my name associated with any public-facing element of my accounts. My name's for close personal friends only - you can do a lot of damage to someone if you know their name and even more if you have a picture of them. The more stuff you stick together into one account, the more control the person loses and the greater your risk across all the elements of the service becomes in all respects - privacy, security and even in terms of google screwing you over for something.
In some ways this manifests as people just not using certain elements of the service - I have to have a google+ account to review apps now. So, I don't review apps anymore. I have to have a google+ account to correct tags on maps. So, I don't correct tags on maps anymore.
In others ways people don't always get the option to opt out though, or don't understand it, the choice having been purposefully obfuscated - and there it's a fairly straightforward attack on their privacy. People are not the same person across all the elements of the service - and for good reason.
It's just a really really aggressive, nasty solution to a problem that no-one seemed to be making much of in the first place. Let's integrate everything, let's force everyone to have an account they don't want on our social network, let's force everyone's names out into the open. Bleh.
What does it cost you to have a Google+ account, if you only use it for reviewing apps, and things like that? You don't have to use the stream.
And if you ever want to read reviews of an app written by your friends instead of complete strangers, and want your friends to read your reviews, which is a feature many people like, how do you suggest that Google should implement that feature? Having one friend list for every single Google product like before?
> What does it cost you to have a Google+ account, if you only use it for reviewing apps, and things like that? You don't have to use the stream.
Well, there are two strings to that. Decency and effect. For me the first one is the main one.
===============
Decency:
My attitude towards relationships is based on standards of, among others, fairness and decency. There are some things that reliably nice people just don't do except in direst need - and even then they pay a price for doing it, (good people don't kill in line utilitarian ideals and then shrug about it and go home whistling a merry tune for example. Doing bad things should make you feel bad if you desire to see yourself as good.) So, to a large extent, the cost is in how the thing is done. Google could be forcing me into something that I was really going to enjoy and I'd still resent them for it. I hate the feeling of being bullied, of having control taken away from me, and now I'm an adult I don't have to put up with it. The cost to me, a very large part of it, is that I'm encouraging bullying behaviour in society - and that's not something that makes sense if you're against bullying, and it feels bad to violate your standards in the same way that lying to someone you really love feels bad.
I think that's a fairly general feeling in our society; being forced into something/acting against our values being bad that is; and I think it's one that makes a lot of sense when you're playing iterative games. We don't like to be told that there's something for us to do, but we like to be asked if we can lend a hand. We don't like to be obligated but we like to help. We feel bad when we lose our tempers and yell at our kids. We feel good when we make people smile and laugh. Most people want to live in a world where fairness is important, where others respect their reasonable boundaries and where when things change they change to benefit both parties who freely consent to the change. We like to believe lots of things about ourselves, and about each other, and unless we behave as if those things matter to us - why ought they to matter to anyone else?
Consequently, if you treat people like crap, violate accepted standards of socialising, then there's a social cost that you have to pay whenever interacting with anyone who operates with strong standards of behaviour; your presence becomes in a sense disgusting to them.
That's the decency side of things. Maybe that doesn't mean as much to you as it does to me, but it means a lot to me. Your worth in the world, to me, comes down to what sort of person you are inside - what sort of likely ways of thinking give rise to your actions.
===============
Effect:
'I certainly don't want my name associated with any public-facing element of my accounts. My name's for close personal friends only - you can do a lot of damage to someone if you know their name and even more if you have a picture of them. The more stuff you stick together into one account, the more control the person loses and the greater your risk across all the elements of the service becomes in all respects - privacy, security and even in terms of google screwing you over for something.'
Now you could say, and quite reasonably, google has so much information about you, what do you care if they have your name too? Does it really make any difference if they know that computer #1,4357,56 is actually Cassandra? I think it does. I think they're going to publish that that's your name and I think it's going to tie into a lot of your other online activities. It will make you searchable, and vulnerable - even without malice on the part of the other party, in a way that you weren't previously. It will translate real world relationships to a digital realm, and vice versa.
You don't even have to make much use of the account for it to contain information about you. Others in your peer group will find you, and they'll start tagging you in photos and suddenly there are pictures of you on the internet alongside your name and location and the people you associate with. Social accounts represent a point of vulnerability. If you don't manage them, then others will do so for you - and rarely to your benefit. I mean honestly, when's the last time someone actually asked you before they tagged you in a photo?
What are you going to do? Not friend them? Now who looks like the anti-social arsehole... The whole situation is of course avoided by default if you don't have an account.
Even if we put that to one side for a moment there are other problems though.
Even just in terms of account security: What happens if someone makes a complaint against your youtube account if you're linked into all the services as one? People have gone after my account before just because they didn't like a girl doing tech tutorials. You get these sorts of really creepy cave-dwellers who are just out to attack everything vaguely creative and decent in the world and suddenly you've overlaid the part of your risk profile that's vulnerable to them with every aspect of your digital life.
Now my name would be tied to every review I made - what happens if someone takes exception to it? People have been threatened with legal action over reviews that companies don't like before. Now my business 'friends' can search out what I do and review, what happens if I say something they don't like? Am I going to give an honest review of something ever again if someone can see that I thought their product needed more work? No, that's the sort of thing that can come back and bite you in the arse.
What if some random arsehole just decides to see how far they can screw people over? Before, without a name, it wasn't much trouble. Now, I wouldn't be so sure. You can do a lot of damage to someone with their name and a few other details. Especially so outside of Europe where the data-protection laws are either less powerful or just flat-out non-existent. It's noticable easier, for instance, when someone's doing research to find someone specific in the US than it is in the UK....
If it were just a name floating around, unattached to any actions that the person took and impossible for people looking for them to tie back to their real identity, then that would be one thing. Any attack could come up with a whole list of people's names just by randomly hashing common names together - what would really be the point? But it's going to be tied to meaning - that's why Google want it in the first place, after all.
I really don't want random people on the internet to have my name, or for random people in real life to follow me back home and onto my computer via the internet. I like my life to have huge brick walls between its different aspects. My work is my work, my friends are my friends, the internet is the internet. For them to have that sort of integrated weapon to use against me is not desirable. Especially when I'm not going to know, if one of them turns around and screws me, who they are - there's a power asymetry for the first person to act on the internet that combined with anonymity is truly scary.
===============
But maybe all that sounds paranoid to you. I don't know, maybe you don't mind people who you don't know on the internet having your real name - after all, it's not like they can look you up on government registers once they've got your name. Maybe... maybe none of them on their own seem very likely or very significant if you were to assume that they happened to you.
But look at the number of them. And what have we got on the other side of the scale? Correcting map mistakes and reviewing apps is something that I do that adds value to Google's service. It's a favour if you will, I just happen to like helping people. But if they really want to make it difficult, if they think they've got something that can use against me and they're prepared to use it, then ... why should I pay these sorts of risks and social costs?
> And if you ever want to read reviews of an app written by your friends instead of complete strangers, and want your friends to read your reviews, which is a feature many people like, how do you suggest that Google should implement that feature?
Just make it a function of integrating your friends lists. There's no reason you can't have one friends list referenced from multiple places and or read differently by different accounts - or several friends lists with different access settings. Heck you could even have one account that has different access settings that restricts cross-contamination between private spheres and public spheres. It would look more or less the same from the outside bar that the infrastructure to control your disclosure and to limit your risks would be there from the ground up. It's not particularly complicated to integrate or synchronise the parts of your service that customers want integrated and still maintain functional seperation.
But, in any case, my complaint isn't that people have the option of integrating their accounts. Demanding that they not have that option would make me no less of a bully than Google. If you want to, while I might advise against it (Google can't change their mind about disclosing what they don't have), that's really your business. My complaint is that pressure is applied to try to make people do it.
If you want the luxury of single sign on across multiple properties and services then you it absolutely makes sense. Otherwise create a new account for each service you want to use. Google makes it easy to switch profiles or have multiple profiles.
I have little issue with that. Though the problem is how they handle it. If you, for any reason (read: error on the part) get your account suspended, then you are royally fucked. You loose all of your data, across all services. What good does that do? But if I had a separate account for each one (with the same login credentials), then I would not be locked way from my data. If I have an issue with Gmail, then Drive would still be available. But no, they wont have that.
Does any company do that? I can't think of any that do that for e.g. Terms of Service violations (as opposed to just going over a quota or something), even accounting for false positives.
It sounds like you really just need to diversify the providers of the services you use.
if you want the luxury of single sign on, across multiple services you do need to do that. Otherwise create a separate account for each service. Whats it matter.
Yeah, so when a script calculates a probability that you're violating some TOS, your whole access to Google is shut down, including GMail, including GDrive, not just that one individual service for which there's a 70% probability of a TOS violation - and then there won't be somebody on the phone you could talk to, because Google is too busy and can't possibly be offering any kind of support, you ungrateful bastard.
I actually know the owner of a business that is using Blogger and Google Apps and at some point freaking YouTube asked for her date of birth, she then selected the wrong year and Google cut her access to GMail, not to mention that it took their blog offline. She then called me desperatly to do something about it. Fortunately they allow validation of birth date by credit card now, but I remember some point not so long ago, where this wasn't the case.
I've found that those who see fanboys everywhere do it because they are total fanboys of something or other themselves, so that's the lens through which they project everything. So really all you are saying with comments like this is that you yourself base your own beliefs on fanboyism, whether you realize it or not.
That's one reason to dislike Google. They push free (as in beer) services and standards until they kill all competitors, then let it rot. To me what they do is even worse than going with proprietary solutions from the start and charging for it, at least that's honest and fosters competition. Just look at what they did with Google Apps.
Nowadays I only trust services where they profit (aka. anything that includes advertising), and none of the open standards they push forward.
Except this is just generic Google comment #4 and has nothing to do with the current situation. AFAIK Google Talk is nowhere near the most popular chat service, there are a ton of competitors, and the problem here is the exact opposite of letting it rot: it's changing the communication format so completely that it's breaking the former adherence to XMPP.
Google Apps doesn't seem especially relevant, but it also has lots of competitors (including, just like chat, very active open source projects), hasn't been left to rot, and they've actually moved to only charging for it, instead of having an ad-supported version.
> AFAIK Google Talk is nowhere near the most popular chat service, there are a ton of competitors, and the problem here is the exact opposite of letting it rot: it's changing the communication format so completely that it's breaking the former adherence to XMPP.
That's not how I see it at all.
You make it look like they are improving the service and that requires breaking compatibility with XMPP, but it's yet another strategy to force users into Google+ by consolidating Google Talk under the "Hangouts" feature. Commitment to open standards is only skin deep.
That's, again, something totally different from what you described in your original post.
Letting a service rot generally means abandonment. I'm certainly not saying that the opposite of letting something rot means improvement, I'm saying that making a major change like this is not at all an example of letting that service rot.
Google hasn't killed competitors. Google chat is losing ground to iMessage, Facebook Messenger, and WhatsApp, all of which are proprietary walled gardens. If XMPP federation was an important feature for end users, why would those products, which are all newer than Google's chat, have been able to supplant it?
Sure, I'm sad that Google is turning off federation too, but I'm happy that it will let the team move faster to make a product that adds value to people's lives.
I am not clear why EFF is lobbying on behalf of the XMPP standards foundation here. The entire computing industry is cluttered with opportunities for interoperable standards, some of which haven't been tried, some of which worked out, and some of which were attempted but (often correctly) jettisoned in favor of progress.
Standardization is a good thing, but not the only good thing, and it always worries me when people make arguments that effectively demand that new offerings justify themselves (either with time or money) to existing standards groups.
Why do you have a problem with EFF lobbying for a standard? They lobby whenever they feel like it's necessary and this isn't the first time they lobby for privacy or for open standards, after all, their motto is "defending your rights in the digital world" and I think that dropping support for federation or for disabling the archiving of chats is within their goals.
At this point, standardization for video chat is one of the most important steps forward. We already have proprietary video chat services. We already have the likes of Yahoo, Skype and Facebook.
Why do we need another proprietary protocol to throw in the mix? What could possibly be more important than an open standard at this point? And yeah, Hangouts has some cool stuff in it, but not enough to justify the breaking of a promise, but then again, it's not the first time where I feel like Google is disappointing.
Every time software progress threatens the status quo, partians of the standard argue that the new functionality proposed doesn't justify degrading standardization. Who are those partisans to say?
There's a difference between advocating for a particular standard because one has a vested interest in that particular standard (e.g. lamenting that JSON isn't XML) and advocating for openness in principle (in this case, lamenting that Google is promoting a proprietary, unfederated IM service in a world dominated by other such services). I think you're confusing the latter for the former.
IMO, any "progress" in the form of a proprietary service which erects boundaries for communication is not progress at all.
True, but at the very least they should keep the support for XMPP they had until now and make an effort to publish specs (not as standards, but as public documents), such that at the very least we can have third-party clients and not leave it up to third-parties to reverse-engineer the protocol badly, violating some TOS in the process.
Or at least commit to doing it in the future at some point. Nobody's rushing them into doing it right now, but changes such as these create anxiety. I mean, what next? Are they going to drop POP3/SMTP support from GMail or something?
If it costs $X dollars to retain XMPP support and $Y dollars to build their new offering out and their budget can't accomodate both $X and $Y, then the choice is indeed between progress and placating standards advocates.
I can't imagine a standards issue I would care less about (among standards I routinely use) than Google Mail dropping POP3 support, unlikely as that may be. Most mail users are better served by web interfaces. POP3 and IMAP are archaic. People that want those interfaces have plenty of options for maintaining them.
You have never had more freedom in how you can avail yourself of technology than you do in 2013, no matter how many restrictive app stores and giant email providers you choose to concern yourself with. (I don't mean that to sound snide.)
These standards, archaic as they may be, also allow you to export your emails should you want to. I pay for my wife's Yahoo email account, such that GMail can use POP3 to connect to it and retrieve the emails that she gets on that account. Not to mention that email clients work best if native. iOS users didn't have to wait for Google to release a half-baked client for them.
As an alternative, of course, we can do better than POP3 or IMAP. Sure, lets burn them, but name an alternative first and it has to be a standard supported by Google, no?
I can't believe that you think this. You're basically arguing for the sake of arguing.
Btw, you're mentioning "web interfaces". How would you have liked it if everybody had their own browser-like app, communicating through their own http-like protocol, speaking their own language for hyper-linked documents?
This isn't so much about XMPP. Dropping federation, without notice to cross-boundary contacts, is the bigger thing for me. I am personally disappointed about the whole affair, especially because there is still no clear picture on why that would be necessary.
As an XMPP Council member I can say that general consensus within the XMPP Standards Foundation is that we will just move forward, no longer constrained by things, like network security, Google never got around to implement.
Am I misunderstanding, or does your last paragraph rule out social pressure as a force for standardization? Are you proposing that we simply allow standards to evolve according to the local incentives of individual agents?
Sometimes. Standards bodies are not themselves entirely benign. They're extremely susceptible to capture, and the incentives of those people not in service of some commercial agenda are often not aligned with users either.
People sometimes lose sight of the real goal, which is interoperability. Interoperability is harmed not just by deliberately idiosyncratic implementations of old ideas, but by refusal to adapt to new ones.
Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable.
Well said. Google made a bad move with breaking things before enabling interoperability by publishing their protocol. It's not the proper way of doing things. Firstly, they could extend XMPP, Jingle etc. instead of creating something from scratch.
If they can't (though they didn't explain why), they need first to develop a protocol, publish it, and then start deploying it. Not other way around! Right now they are moving towards cutting the connection between Google users and users of other XMPP servers. Connection which works already now. I can understand that they might envision new communication patterns, but it doesn't mean one has to break what already works before enabling others to interoperate. It's completely immature on Google's part. Going the right way might take more time - but it will not increase the horrible mess that the IM scene is today. What Google does now is creating only more mess.
Google is getting clobbered in the messaging space by these apps. If Google thinks they can move faster by dropping XMPP support, I'm fine with it.
Imagine if Google sticks with XMPP and continue to lose market share in messaging. They might have to shut down Talk. We know what happens when Google sunsets a product, lots of angry people.
It's XMPP at core, but - AFAIK - they also do not support server-to-server federation. So you can connect to Facebook chat with any XMPP compatible client, but if you run your own ejabberd server, you can't connect to your server, and then message your Facebook friends.
It's not. As https://developers.facebook.com/docs/chat/ explains, "Facebook Chat should be compatible with every XMPP client, but is not a full XMPP server. It should be thought of as a proxy into the world of Facebook Chat on www.facebook.com.
Er, so isn't that the exact same situation as Google? You can still connect with any XMPP client, but XMPP support is now just a proxy into the world of Hangouts.
Yes, my pidgin is working just fine right now. You have to log in through a google account now, you can't connect through a federated account, but AFAIK all previous XMPP clients still work just fine.
It supports client federation, not server federation. Server federation is what it allows XMPP servers to send messages between each other, while client federation allows for other clients to connect over XMPP.
What I don’t quite get is how server federation is much more difficult than ‘client federation’. s2s XMPP looks extremely similar to s2c XMPP, and since they still have s2c XMPP, they don’t seem to have a problem with only exposing parts of their architecture via XMPP.
Really, I can only think of laziness and trying to build a walled garden as reasons to support c2s but not s2s connections.
Both of which are not exactly good explanations for one of the largest companies in software engineering.
As stated by Google officially, and by all accounts of everyone using external clients, XMPP works fine. Federation doesn't, just like with Facebook as mentioned above.
Even though Facebook uses XMPP, they aren't federated, so they are cut off from the rest of the XMPP network. Therefore the benefit of them using XMPP extends only on using different clients. I.e. it's half good, half bad.
Google isn't abandoning open standards for instant messaging. They're abandoning instant messaging. They've moved from a real time communications tool to a messaging tool. This is incredibly frustrating for those who used previously used Google Talk for instant messaging purposes, but now have to look for other options outside the Google ecosystem.
Google has dropped support for XMPP (chat) and calDAV (calendar syncing). What's next? cardDAV? IMAP?? Honestly I can see that Google is no longer interested in open protocols. They are afraid that it's too easy for their users to simply migrate everything away. Their response is to build a wall around their users. Enough red flags have been raised for me to, unfortunately, say goodbye.
Perhaps I may still buy their hardware, but they want to isolate my data from every company but them. They are no longer reliable.
I would also like an open standard but I had to laugh at the final sentence of the EFF statement:
> To be clear, even the earlier [off-the-record] setting was far from perfect from a privacy perspective: disabling chat history only kept the logged messages out of your Gmail account, and didn't prevent other users, or Google itself, from keeping a record of the conversation.
How on earth would you expect an open protocol to prevent the other keeping a record of a conversation? It's like asking for perfect DRM with open clients.
They could[0] implement some client side actual OTR[1], at least blocking Google from keeping the clear-text message. No idea how they would want to force the intended recipient of the message not to store it, though.
[0] In theory with infinite resources and time. Maybe.
by down-voting this is getting even more evil, I don't mind what google does, just please don't wear a 'dont be evil' outfit while doing it, you can't have it both ways, why bother.
I hope we can have a google competitor on the horizon, it does not matter what google claims, once it starts to monopoly, it starts to get evil, i.e. forget about the interoperability, forget the open source, my way is the best,etc.
google is becoming microsoft quickly under the new CEO, like many others, I'm finding alternatives for all related google services, I'm ok with that actually, just find its 'dont be evil' slogan becomes even more so ridiculous.
Google doesn't have a monopoly in instant messaging. Far from it, they are lagging behind Facebook, WhatsApp, etc. What good is Google doing for the world having an open product that almost nobody uses?
It's often not in the best interest of private companies to use open standards. If using an open standard is a net financial loss, why should the company do that? It's simply the result of how the system works. I've been thinking whether the rules (=laws) can be changed somehow to provide incentive for using open standards, but it's quite a complicated problem.
Instead of adding more rules with their inevitable unintended consequences, I'd rather we'd kill the rules that promote closed protocols, like the anti-reverse-engineering clauses and overreaching "anti-hacking" laws.
It's just a matter of time before something like Vidyo [1] is replaced by WebRTC. There is too much at stake for Google to be the kitchen sink for all kind of technologies. They want you to connect to them.
Actually makes total sense. Companies like Google should always remain ahead of the curve. They should innovate much faster than any of the open standards could grow.
They can use XMPP as a base and build extensions for everything they need atop of that, then use these extensions immediately while they go through the XSF and eventually become a standard.
XMPP has sort of been designed with extensibility and innovation in mind.
I'm a lot more interested in them adding OTR encryption than having interoperability. However, if they never intend to add OTR (which being Google, seems very likely), then I'd want Hangouts to at least work with other IM's that do offer OTR, like Gtalk has worked so far.
OTR is important, but I don't think you really want your chat provider also providing the OTR implementation. Better to use a third-party client. Preferably open source.
Doing it browser-based also seems problematic, for all the usual javascript/encryption reasons. I've never heard of people using it in regular Gtalk, though. How does that work? Browser extension?
I've only ever seen things like using Pidgin with OTR, which should still work as long as you have a Google account (aka you don't need XMPP federation to talk to people on google's network).
That's just turning off chat history, which is confusingly also referred to as "off the record". Usually when people talk about OTR for chat, they mean client-to-client encryption, so not even the chat provider knows what the content of the chats were, analogous to using something like PGP for email.
Does anyone else see the radical changes going on over at Google? They are in bed with the US government. It's now less about serving up search results and more about retaining all information on you. Google is evil.
What, concretely, does Google gain from spying on you? In contrast, they have a very clear profit motive for search: they get paid a lot of money to put ads next to the search results.
The same motive. This isn't even a secret conspiracy, their ToS says they do it and says that is why they do it. The more data they have on you, the more ad money they make.
Why do you think the ads you see in a search just happen to contain items you were just emailing your mother about a day prior?
All individuals who seek to silence others with a take-it-or-leave-it are people who do not want to suffer the mental dissonance of being frustrated with a provider they themselves use.
I think Google Takeout is awesome, both as a concept and how it is being executed. That said, there is no takeout for Google Hangouts. I.e. with dropping federation, you can't set up your own server and reconnect to your contacts within Google Hangouts.
The sad thing is, no one has noticed that Hangouts is invoking a WebRTC plugin in my PulseAudio container, leading me to believe that they're already experimenting with WebRTC.
With WebRTC, a proper signaling protocol (they're probably using Jingle anyway, give the RTC history and the fact that RTC relies and builds on Jingle), and a relay server, there's not much to need to do to interoperate if they wanted to enable it.
This whole notion that they "can't" make it interoperable or that it will "slow them down", is complete and utter shit. Slow them down on what? All I've seen so far is more merging of GoogleTalk+GooglePlus and a rebranding effort. Basically no new feature, no integration with Google Voice, no seamless integration with SMS.
"In public explanations of its dropping XMPP support, Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable. Releasing the specifications for Google Hangouts would be a good first step. Releasing free/open source clients and servers should follow. It's clear that some of Hangouts' video features have been implemented in some very Google-specific ways. But that's no excuse for leading us toward a world where the only practical choices are proprietary chat clients and protocols."
I hope the specs at some point are opened. The Hangouts team probably has good reason at the moment to strictly focus on a core set of functionality and get it working with good UX on all the platforms. People are complaining that stuff like voice calling, and some Talk features are missing, but it's probably due to focus on shipping something that works good first. It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. In the late 90s, early 2000s, I remember using reverse engineered Java libraries that could talk to these services.
Google Wave was done in the opposite way, as was Open Social. They came with specs, but they did not focus on core user experience in the beginning. It's hard to win with open specs without getting consumer traction.