@roelant @muzirian Your views on bridging are, firstly, irrelevant to this thread. But since you have chosen to start this…
It’s quite fashionable to set up bridges, but the issues behind them are invariably downplayed -@roelant and @muzirian 's answers are excellent examples. I’ll ignore the commonly-acknowledged ones - feature mismatches, bad UX, spam - and focus on some critically understated ones.
Merely “principle”?
Eschewing proprietary software is not merely a matter of “principle” but of pure practicality. To use proprietary software is to open yourself up to exploitation at the hands of the copyright holder.
But even if it was just a matter of merely “principles”, those principles are the same as those of OpenStreetMap itself. Which means that the OSM community should avoid being hypocritical and have solidarity for those principles…and that means supporting free software, and boycotting proprietary software (including by de-bridging with it).
Data control
Bridges may allow the use of proprietary services with free software clients, but they also allow said proprietary services to easily access all data pertaining to the communities.
Some like to claim that this doesn’t matter for public channels, but “public” is a spectrum, not a binary. Even a “public” XMPP channel has control over who may or may not join, who may or may not see the logs, how long the logs are retained on the server, etc. Even public IRC channels (like #emacs) can forbid public logging. But bridging to a network with promiscuous data sharing policies like Matrix, or to a proprietary centralized network, effectively hands over all data to them without even trying.
Favoring the rich
Bridges also favor those with more financial power. Consider Network A, funded and developed by the free software community. Then consider Network B, funded and developed by a company worth billions or by a VC-funded startup. Network B will obviously have better clients, more features, better UX, better infrastructure, etc. If one can join all (or even most of) the same communities through both Networks A and B, that gives people the incentive to move to Network B. Most will conveniently ignore that this opens them up to the inevitable mistreatment expected of private companies - as I pointed out in the earlier GitHub thread.
Why communities should care
Communities constantly create pressure on participants to use their media of communication. For example, I’m forced to use IRC because OSM is on IRC. If I had to talk to the StreetComplete developers, I’d have to join their proprietary Slack or GitHub. And each time a community chooses a proprietary platform, or chooses to bridge to one, we’re creating value for the proprietary platform and social pressure to join it.
So why not take cognizance of the consequences of these choices, and make a stand to change things for the better? That’s what the XMPP-only community has done. It’s an example worth following.
Those in favor of bridging are like the people who want to be “apolitical” (another fashionable myth in tech circles). Anybody with an ounce of sense will recognize that all an “apolitical” person is one merely preserving the status quo. It’s as foolish a position as contributing to both OSM and Google Maps - such people have my unvarnished contempt.
I have no interest in preserving the status quo, be it the dominance of proprietary maps or that of proprietary software. I’m here to do my part to change the world for the better.
The solution to fragmentation is to select ONE time-tested and future-proof solution, forget about bridges, and proactively onboard people. To the best of my knowledge, XMPP fits the bill perfectly.
My position on bridges and free software has resulted in me onboarding loads of non-technical users to XMPP (both into OSM and other communities). The pro-bridge/“apolititcal” people cannot boast of such positive impact. If more people were to support us, we could have the whole world weaned off proprietary platforms in no time.
EDIT - Those not in support should consider using their words and actually refuting the content of the post, instead of merely downvoting it. (cc @Negreheb)