They're using their own protocol. By freedom, I meant ability to iterate fast, break compatibility, not have to support unwanted clients etc.

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

Presumably though even if you're iterating hard and breaking stuff, once you're out of alpha you're not going to introduce many backwards-compatibility-breaking protocol changes? I can see doing that for v0.1 to v0.2 and maybe from v1.9.x to v2.0 but nothing about making those changes seems incompatible with sharing the details of final protocols used in your production level clients.

Take a very real example: Discord is working on video chat right now. As part of that work, it's not unthinkable they'd need to severely rework the voice/text protocols because they want to bring all of them in line with one another, reduce their tech debt or what have you.

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.

>If it's an open standard, they need to check in with everyone //

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.