In what way? The chief complaint I've heard about XMPP over the last couple of years is about excessive power consumption on mobile. And my own experience is that those concerns are highly over-stated.

I've never seen users actually complain directly about an app's "excessive power consumption". Can we all admit that one has always been an excuse?

The only other complaint I've heard about XMPP was that it was too extensible. There wasn't enough mandatory features in the base protocol to expect good clients for fancy things and there were too many extensions to need to follow to write a good client if you tried to track "fancy thing du jour"... which is as much a feature as a bug (and the whole reason for that X in XMPP).

Discord's product isn't a hosting service, their product is the quality of the service as well. This quality would be impossible with XMPP as it exists today, within the constraints of a startup. Remember, they do voice and they want to do video as well. Google's own efforts on Jingle failed due to performance.

As for mobile, it's not just power consumption, it's connection lifecycle. XMPP last I heard had extremely poor support for lossy connectivity.

Again, power consumption/connection lifecycle isn't directly a competitive advantage because your user doesn't care so long as it works. (Slack and FB Messenger seem to have terrible power consumption and connection lifecycles for mobile but also seem to be doing just fine.)

(Not to mention those are also things that could be fixed in an open standard, if people cared to contribute that effort. The unfortunate reality is that isn't a competitive advantage either.)

The competitive advantage is to find excuses to dismiss open standards, whether the arguments are technically or factually correct is another matter, and build walled gardens.

But more crucially to my previous point, being technically superior isn't really a competitive advantage if a user doesn't notice it and in fact, can slow one from getting first mover advantage by shipping something/anything faster and sooner. I really don't think that on a power consumption or connection lifecycle standpoint any of the closed source protocols are really all that much better, and we have mostly nothing but anecdotes to trade on that question because the companies want to maintain their secret sauces.

Can you expand on that. Are Discord using someone else's closed protocol then in preference to their own (which they could open) or an already open one?

Or did you mean "freedom" as in "ability to use lock-in", or something else?

It's something you care about less once you're big, but it matters a lot when you're starting.

If it's an open standard, they need to check in with everyone, document the move, potentially have to explain it or depending on popularity won't even be able to justify doing it. And suddenly, you see they're losing their competitive advantage for the sake of pleasing a few people on HN.

If it's a closed standard, they do whatever they want, don't have to justify or explain it to anybody. They can turn the protocol into fairy dust, run two versions of it for a while, and require a client upgrade if you want video chat.

Now, a few years down the line once Discord is established, has a solid business model and the protocol is clearly not changing anymore, then we can talk about making it open, allowing third party clients and we can really seriously start bugging them about it.

I very much want this to happen but Discord does need to be successful first. You'll get nowhere by bugging a startup to spend time on what could potentially kill the business.

You're​ missing the point I think (or I got cross-threaded). It's Discord's standard, making it an open standard just means the protocol details need to be public such that a third-party client that uses their protocol can send and receive messages to & from their client(s).

The people to be pleased are not just HN readers but everyone who uses an IM system as each system could, if desired, then speak direct to others. In theory it wouldn't matter that I have Facebook and you have Google, I could still message you. If the market works effectively the best protocols could then win, as could the best UX, even if they came from different companies.

If I were drafting a law on this then it would have an exclusion for SMEs or new companies, it would as you say be an unnecessary regulatory burden to require protocol openness prior to establishment of a service. We're looking at million user plus systems.