There are loads of amazing options for online communications.
Some do text, some do voice, some do video, some do file/photo sharing. Some offer one-on-one messaging, some group messaging, some both.
Whether there is an out-of-box solution to suit any given person's requirements or wishes is a different matter. One might need to pick the solution which is the best fit, rather than searching for - or complaining about the absence of - a perfect fit.
Or, rather, complain away! It might solve something, it might not.
It might "just" make the complainant feel better, which could be important in itself.
Complaining that a volunteer, writing something in their own free time, has not implemented a feature that they don't feel like spending their free time implementing? I struggle with that, perhaps aside from complaints about lack of accessibility, which I'd love to be just a baseline requirement.
I suppose that I come at this from a "scratching your own itch" perspective.
Someone writing something which does what *they* want it to do.
If there's a plan to write something to appeal to others then, sure, it would make sense to take into accounts the requirements and wishes of others... it is hard to argue that people are not using the service if it does not work for them.
Similarly, one cannot please all the people, all the time, *especially* perhaps if there are more unfunded feature requests than people available to implement them.
There are a bunch of conflicting goals here. XMPP, for example, explicitly defined a large number of different clients and servers. This let it adapt to different use cases easily, but also led to enormous fragmentation. It's improved a lot recently, but for the first decade or so it was hard to (for example) transfer files between two different clients because there were so many different protocol extensions and everyone implemented a different subset.
XMPP selected a server as the reference implementation, but did not do that on the client side. The thing a new protocol really needs is a permissively licensed client library that implements the protocol. This makes it very easy for someone to implement a client that interoperates with other clients and is mostly feature complete.
What is your best guess at how to combat vendors pulling an MS EEE in that scenario, if there is economic utility for them to do so...?
I can't think of anything but tax-payer-backed, public funding being offered for vendors who stick to the standard, who must in turn prove that their supported solution meets the published test suite, and that it works seamlessly with the reference client library? In other words, a public, legislative moat with an incentive bridge?
The key thing is 'if there is economic utility'. If you create a thriving interoperable ecosystem, it's very hard for people to do this. There are loads of things that want to replace email, but none have succeeded. Even Microsoft implements SMTP.
For government procurement, it's easy to require interoperability and second sources. The same is true for big companies.
It's incredibly hard to sell differentiating features in a market that is already commoditised. If you want to avoid EEE, then you want to make sure that the market becomes commoditised as quickly as possible. That means removing as many barriers to entry as you can.
@neil I am with this up to the point when advocates for these alternative services (as is depressingly common) start getting upset more people don't use them, or blaming users for not doing so.
It's one thing to not want to respond to random demands as a volunteer, it's another entirely to not listen to user feedback and then get upset that people prefer something that works better for their purposes. (See the frequent discussions on here about how people sacrifice privacy for "convenience" on here - yes, people don't want to be inconvenienced! That is not their problem, it's the software developers'!)
Oh, it would be amazing if there were no compromises. Absolutely.
I'm not sure that that is realistic, though?
