Hacker News Reader

Comment by rjzzleep | Hacker News Reader

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.

View on HN

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.

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.

Why not?

Because as soon as you release the spec, people will start building stuff against. This creates resistance to changing the protocol.

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.

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.

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.

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:

  <message type="normal" from="wave.initech-corp.com" id="1-1" to="wave.acmewave.com">
    <request xmlns="urn:xmpp:receipts"/>
    <event xmlns="http://jabber.org/protocol/pubsub#event">
      <items>
        <item>
          <wavelet-update xmlns="http://waveprotocol.org/protocol/0.2/waveserver" wavelet-name="acmewave.com/initech-corp.com!a/b">
            <applied-delta><![CDATA[CiIKIAoFCNIJEgASF2ZvenppZUBpbml0ZWNoLWNvcnAuY29tEgUI0gkSABgCINKF2MwE] ]></applied-delta>
          </wavelet-update>
        </item>
      </items>
    </event>
  </message>

1. http://xmpp.org/extensions/xep-0239.html

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.

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.

We all remember Open Social, right?

Reply on news.ycombinator.com