4 ms·

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 an

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.

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.