What I'd like to see is some kind of unofficial, periodic publishing provided by the (say) top 3 vendors that implement a given protocol where they would spec a common profile and define the basic integration test suite - sort of like the CSS Acid tests.
Let's take the example of XMPP: the top server implementations could agree that in 2019 all of the servers should support XEP-{A, B, C, D}. In 2020, XEP-E and XEP-F could be added. In 2021, XEP-B can be superseded by XEP-G...
As it is now, it seems that most vendors want to compete and try to take whatever little market is left for XMPP. If instead they decided to collaborate, it would help immensely client application developers, they know that the important thing would be to ensure that they support the current profile.
My guess is that could lead to some kind of concentration of power and force smaller vendors into spending resources in Keep-Up-With-The-Joneses mode, just to get close parity. However, given that the protocol is open and most interesting implementations are open source, this doesn't seem too different from other technologies - how many different FOSS http/mail/amqp/ssh/RDBMS projects are there, and how much of a Pareto distribution do they follow?
I think the interoperability issues mostly happen on the client end with XMPP. The popular open source servers support most anything that anyone would want. The problems are with stuff like video and audio chat ... and interoperable end to end encryption for clients that still don't support OMEMO. So you could work on a set of client capabilities for voice/video chat. Such a minimum requirements list would help with all voice/video, not just XMPP.
> issues mostly happen on the client end with XMPP.
from what I have seen in comments over the years is that it's been spotty to make it so you could depend on things working / being delivered to the other (federated) clients - as most do not accept the same feature set as each other.
I had suggested that a chart is made of all the clients along with which features are not yet implemented there, along with the programming language they are written in. This way it should be possible to estimate the amount of hours to add all features to all clients, then estimate the cost - and maybe we could crowdsource the amount of money or volunteer hours to get most clients to reciprocate most feature interoperability.
It is interesting how the greatness of the conversations XMPP client has sort of created a defacto baseline. You have to go half way down the list before you get below 90% compliance.
The thing with an open protocol is that there is always going to be a vast number of clients that don't support much of anything. We really only need one really good free client on each major platform.
Let's take the example of XMPP: the top server implementations could agree that in 2019 all of the servers should support XEP-{A, B, C, D}. In 2020, XEP-E and XEP-F could be added. In 2021, XEP-B can be superseded by XEP-G...
As it is now, it seems that most vendors want to compete and try to take whatever little market is left for XMPP. If instead they decided to collaborate, it would help immensely client application developers, they know that the important thing would be to ensure that they support the current profile.
My guess is that could lead to some kind of concentration of power and force smaller vendors into spending resources in Keep-Up-With-The-Joneses mode, just to get close parity. However, given that the protocol is open and most interesting implementations are open source, this doesn't seem too different from other technologies - how many different FOSS http/mail/amqp/ssh/RDBMS projects are there, and how much of a Pareto distribution do they follow?