6 ms·

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 pro

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.

cromwellian 13y ago
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.
rjzzleep 13y ago
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.
- ChuckMcM 13y ago
  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). So the 'easy' choice is to not publish.
  - spankalee 13y ago
    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.
    - nightpool 13y ago
      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.
      - marcusf 13y ago
        Why not?
        mattmcknight 13y ago
        Because as soon as you release the spec, people will start building stuff against. This creates resistance to changing the protocol.
      - cwp 13y ago
        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.
  - deleted 13y ago
    [deleted]
- btilly 13y ago
  The problem is simple. 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.
  - tomkarlo 13y ago
    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.
  - DannyBee 13y ago
    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.
    - 13y ago
- mseebach 13y ago
  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.
- saraid216 13y ago
  We all remember Open Social, right?
- dlitz 13y ago
  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/ 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.
cube13 13y ago
Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
mtgx 13y ago
Google needs to bring WebRTC with VP9 and Opus to Hangouts already!
- legulere 13y ago
  At least in the iOS app license information webrtc and opus are already mentioned.
MatthewPhillips 13y ago
> 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.
greggman 13y ago
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. http://www.youtube.com/watch?v=v_UyVmITiYQ http://www.youtube.com/watch?v=v_UyVmITiYQ
- deleted 13y ago
  [deleted]
dserodio 13y ago
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.
Spooky23 13y ago
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.
drivebyacct2 13y ago
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.
bad_user 13y ago
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?
- Andrex 13y ago
  > 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.
  - bad_user 13y ago
    Yeah, both are pretty cool to have, I was exaggerating a little, though for companies Skype Premium isn't that expensive.

cromwellian 13y ago

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.

rjzzleep 13y ago

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.

ChuckMcM 13y ago
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). So the 'easy' choice is to not publish.
- spankalee 13y ago
  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.
  - nightpool 13y ago
    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.
    - marcusf 13y ago
      Why not?
      - mattmcknight 13y ago
        Because as soon as you release the spec, people will start building stuff against. This creates resistance to changing the protocol.
    - cwp 13y ago
      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.
- deleted 13y ago
  [deleted]
btilly 13y ago
The problem is simple. 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.
- tomkarlo 13y ago
  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.
- DannyBee 13y ago
  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.
  - 13y ago
mseebach 13y ago
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.
saraid216 13y ago
We all remember Open Social, right?
dlitz 13y ago
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/ 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.

cube13 13y ago

Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/

mtgx 13y ago

Google needs to bring WebRTC with VP9 and Opus to Hangouts already!

legulere 13y ago
At least in the iOS app license information webrtc and opus are already mentioned.

MatthewPhillips 13y ago

> 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.

greggman 13y ago

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. http://www.youtube.com/watch?v=v_UyVmITiYQ http://www.youtube.com/watch?v=v_UyVmITiYQ

deleted 13y ago
[deleted]

dserodio 13y ago

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.

Spooky23 13y ago

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.

drivebyacct2 13y ago

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.

bad_user 13y ago

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?

Andrex 13y ago
> 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.
- bad_user 13y ago
  Yeah, both are pretty cool to have, I was exaggerating a little, though for companies Skype Premium isn't that expensive.