An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix?

Perhaps it is about providing the right hooks into the specification to not compromise the end user experience.

I think Docker is an interesting project to follow in this regard. They have shown the ability to get both startups and large players (amazon, google, microsoft) onboard by keeping the platform open. Yet they are clearly focused on providing the best experience for developer/ops interaction with cloud services. It will be interesting to see the rollout of their extension mechanisms and whether they can be a primary interface to cloud services or will become a second-teir compatibility layer. However, even in this case perhaps chat protocols could learn something here.

I think the real problem with XMPP (and the visible lag between state of the art and specifications) is that there's no single big vendor behind it. It's both a pro (in that the specs should accommodate what the community wants, not what the vendor wants) and a con (because specs are written when vendors feel like it).

An interesting example is Google with SPDY. They wanted something new, built it, tested it, and then wrote the specifications (along with other actors of course). I think it is fair to say that without the SPDY experiment we wouldn't have seen HTTP/2 coming so fast. Google and the other actors had enough incentive (and actual time and money to spend) to make it go further. In the case of XMPP there's no such actor, unfortunately.

Yeah, good point. USB-C wouldn't have ratified so quickly if Apple didn't hand it over [1]. Apple could also be credited with putting pressure on OpenGL to release Vulcan when they released Metal API a year prior. Before this, OpenCL/GL hand't changed drastically in years. It seems big companies are involved whenever positive momentum happens.

[1] http://9to5mac.com/2015/03/14/apple-invent-usb-type-c/

> An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix?

Its not broken. Standards are, ideally, distillations and applications of proven experience in a generally applicable way. You don't want standards trying to ride the bleeding edge, they want them to apply what is proven.

(OTOH, its good to have those working on the bleeding edge also opening for discussion how those experiments might be standardized while the experiments are still ongoing, and one vehicle for those discussions is draft standards or draft updates to existing standards.)

> why do standards tend to run behind state-of-the-art

Because otherwise you end up with design-by-committee.