On one hand, the playbook of exploiting Office's dominance to push Teams is very very reminiscent of exploiting Windows' dominance to push IE.
On the other hand, Slack's walled garden is also effectively anti-competitive; trying to create a monopoly via vendor lock-in to the Slack product & ecosystem.
It feels like a better bet would be for both of them to adopt and support open interoperability standards, so users can avoid being locked into any single vendor, and have full sovereignty over their conversation data. (Disclaimer: as project lead for Matrix I may be biased :)
> adopt and supporting open interoperability standards
Can you imagine not being able to send a UPS packet to a DHL address or not being able to call an AT&T phone from a Verizone one? And how long until I cannot send mails from my Gmail address to you Outlook one?
We live in the Wild West of the digital age.
I still remember the times that Microsoft was trying to own the WWW thru non-compatible Internet Explorer extensions. And, also, the time that Microsoft tried to own Java by adding Microsoft extensions to it. (https://www.cnet.com/news/sun-microsoft-settle-java-suit/)
Companies have many incentives to create lock-in software and proprietary protocols that go against the interest of their own users.
Can you imagine not being able to call a German phone number from the US?
AT&T's telephones still had to interoperate with (e.g.) the British Post Office's phones (and everybody else's) to remain relevant/useful. AT&T was very far from controlling all telephony equipment in the whole world.
One of the biggest reasons people have stopped hosting their own mail servers is precisely because there is genuine worry that GMail may simply reject mails from your server.
My thesis advisor falls into this group of people. He typically uses a custom server, instead of the Institute provided email and half his emails go to my spam when we occasionally communicate. Thanks to my thesis days' experience, I've begun checking my GMail once a month, and thoroughly, including spam.
One of them being complexity and and how fast you can move on new features. Adding features to a spec'd standard is a horribly slow process, this is the reason the developer of Signal decided against decentralization. You end up building XMPP, and that doesn't go so well if your specs are not very explicit. You can see this in how unreliable OMEMO is with multiple resources connected.
The Web is already a mature platform and has not actually made things more interoperable. It replaced a lot of the previous internet infrastructure that was (IRC, Newsgroups, SMTP which still somewhat clings to life)
> Adding features to a spec'd standard is a horribly slow process
It doesn't have to be. The Web evolves relatively rapidly these days, and Matrix does too (although it could be faster, for sure). It's important to support freedom as well as privacy - as per https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom.
> very very reminiscent of exploiting Windows' dominance to push IE.
The idea of Windows pushing IE by bundling it seems laughably quaint to me these days where most people can't even install a different rendering engine on their device than the stock and choice is purely illusionary and very few seem to bat an eyelid or even notice.
I think various custom Androids qualify. Most people don't know how to install apps, that apps such as Facebook and WhatsApp are preloaded onto the OS before shipping.
Even if they were both open standards it wouldn't affect this. The issue here is pricing, and specifically bundling. There's no way anyone can compete fairly when Teams is bundled with a seperate monopoly product.
> very very reminiscent of exploiting Windows' dominance to push IE.
Reminiscent? They recently pushed out a mandatory windows update that caused IE to take over your entire screen upon restart, pin itself to your taskbar, and attempt to set itself as the default app for numerous functions: https://www.theverge.com/21310611/microsoft-edge-browser-for...
> attempt to set itself as the default app for numerous functions
That's false, if you install any new browser -- Chrome, Opera, Firefox -- the next time you open a URL or HTML file, Windows will ask you if you still want to use your existing default browser or change it. This is done because apps can no longer set the default browser themselves and must ask the user to do it.
actually, come to think of it, an excellent way for Microsoft to fend off this anti-competition accusation would be to go embrace Matrix for use in Teams and demonstrate they support data portability, and are serious about not locking users in.
On the Matrix side we'd be happy to help them do so (we have a few big undisclosed projects already on the go to expose existing chat systems natively into Matrix :)
This is the "new" Microsoft. Just like the old Microsoft. The other two Es will follow just as soon as the optics permit.
eta: (Sorry to sound old and curmudgeonly, but... I am old and curmudgeonly. I do not believe for one little instant that any corporate culture is capable of reversing its lifelong ingrained habits and postures.)
XMPP and ActivityPub are the other obvious federated communication protocols (albeit with very different emphases; XMPP being message-passing at its core; ActivityPub being subscribing to activity streams at its core; Matrix being history-replication at its core).
Where Matrix needs competition most is in homeserver implementations. There are partial Go, C++/RockDB(?!), Rust, Elixir, and Java projects, but none full-featured.
It's nice that the full-featured Python one can use Postgres, and succeed at operating Matrix.org, but it's not nice that you have to frequently "restart its synchrotrons" for users to be able to adjust their notification preferences. Python is a capable language for smaller systems, but at >120K lines, it worries me.
It also worries me that there is no way to split traffic to an overloaded system out to two not-overloaded systems. Is that fundamental to the architecture? That seems like the top priority to fix. Can it be done without breaking the five other server implementation projects too badly?
There's a lot of stale/wrong info here. I'd say that we have pretty healthy competition in homeserver implementation these days. The four options currently in active development are Synapse (Python), Dendrite (Go), Conduit (Rust) and Construct (C++).
In terms of Synapse (https://github.com/matrix-org/synapse): originally the initial prototype for Matrix, historically it had performance and architectural issues given we were frantically implementing features to prove Matrix rather focusing on perf. Since hitting 1.0 a year ago though things have improved massively. Almost all of Synapse scales horizontally; we've switched to Python 3 and have almost finished switching to asyncio (improving perf and maintenance massively); and lots of schema perf issues have been shaken out. Unsure what you're thinking about w.r.t. "restart its synchrotrons", but that just sounds like a bug that got shaken out years ago.
Dendrite (https://github.com/matrix-org/dendrite), meanwhile, is in very active dev by the core Matrix team - there was a long hiatus while we had to focus exclusively on Synapse, but since the beginning of this year there are folks working fulltime on it, and it's looking super promising as a very microservices-driven model, with each service scaling arbitrarily horizontally, connected via append-only logs. All the P2P Matrix work is built on it (running it clientside, as it's such small footprint). It's effectively in competition with Synapse, and worked on by different teams. It federates today and can be run as late alpha, but the CS API is missing some features that we're currently adding.
Conduit (https://conduit.rs) is the new kid on the block, written by the community in Rust, using a strictly monolithic structure for now, using Sled as a key value store for storage. It's incredibly fast, and has impressively good CS API coverage (including E2EE, whereas Dendrite's E2EE support is only landing this week), but federation work hasn't begun yet (which is a bit worrying, as you need to design/build with federation in mind from square 1). It has a great community though, and is entirely independent of the core Matrix team, and you could say it's in competition with Dendrite.
Construct (https://github.com/matrix-construct/construct) is a C++ server using rocksdb for storage. It's a community project entirely independent of the core Matrix team; it federates, and has extensive CS API coverage, but unfortunately the project's author has been incredibly antagonistic to the core Matrix team over the years, which makes it rather hard for us to comment further.
TL;DR: Matrix homeserver dev is in a good place right now :)
I was going on public information, such as the FAQ about Synapse, which explained in detail how matrix.org could not shard out their Synapse server; it is good that the FAQ is now completely wrong on that. I will need to ask over at Construct about the nature of their disagreement with the core team.
I had asked at Element why it would not update notification preferences, and they said my homeserver probably needed its synchrotrons restarted. Does this mean the version of Synapse they run is badly outdated?
Fair notice yes, but you do not need to post a dis claimer. This is an internet chatroom, there is no need to file a disclaimer as if it has any legal currency.
In this case: Thanks for your fair notice, that's interesting you're working on Matrix, I'm intrigued and I might have some interesting comments and it got me thinking further. But no no I won't sign your disclaimer. There is no legal effect or otherwise statute limiting outcomes of posting a disclaimer.
And why not?
We all have biases, and posting a disclaimer won't absolve you of still having the intentions you may have and bring to a discussion. That's the nature of human society and simply by being an actor you already accept this fact. So in conclusion, nope, no disclaimer needed.
I like the disclaimers. I don't think they always need to be there, but when someone is working for or on a competitor or for the company being discussed I think it helps keep the discussion above board. It also means that there is less risk that the person is being accused of shilling since they have been up front about their association.
You are wrong. Disclaimers are a quick and simple way for users to let others know that there might be some specific view, or conflict of interest, or bias, so that the others can take that into account.
Disclaimer is exactly that; a disclaimer, it's a legal function. It's something you put in a contract or an agreement.
A disclaimer is generally any statement intended to specify or delimit the scope of rights and obligations that may be exercised and enforced by parties in a legally recognized relationship.
On the other hand, Slack's walled garden is also effectively anti-competitive; trying to create a monopoly via vendor lock-in to the Slack product & ecosystem.
It feels like a better bet would be for both of them to adopt and support open interoperability standards, so users can avoid being locked into any single vendor, and have full sovereignty over their conversation data. (Disclaimer: as project lead for Matrix I may be biased :)