It's not using Matrix? What's the point in making an open source however non federated IM service?
Many companies using such a system wouldn't even want federation, and it adds a bunch of complexity.
Story of Mattermost: Open-Sourced Competitor to Slack
171–180 of 248 posts
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#172The open-source Mattermost intentionally lacks a couple of pieces of basic functionality to push you to pay, like the ability to stop regular users from deleting channels, and no way to set a reasonable password policy that requires more than 5 characters. Mattermost (and specifically their CEO, who is vigorously replying to messages on this thread, but probably won’t engage with this one) haven’t responded positivel…
As I’m reading it, Mattermost (as source) is released under the AGPL, which makes it both legal and ethical (indeed, they have explicitly consented to allow you to distribute modifications) to stub out all the license checking and enable all of the enterprise functionality without any payments, tracking, or phone-home. It seems to me this is the point of free/open source software: anyone can improve it and make it mo…
I believe they store the enterprise specific code in another git repo that has to be checked out, for one (from reading their Makefile).
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#173It's not using Matrix? What's the point in making an open source however non federated IM service?
Many companies using such a system wouldn't even want federation, and it adds a bunch of complexity.
So run a local server and turn federation off. Like you can run a private e-mail server. Why not use and contribute to the common protocol that does allow federation? I see no point for a FOSS project in proliferating non federated IM protocols, and wasting resources on that, while federated ones still didn't even reach wide adoption.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#174Used Mattermost for a year, and I can attest to it's shittiness. There is a bug during switching channels that pins your view to some random location weeks before the latest post. The result is that switching channel in Mattermost has a 60% chance of requiring you to spend the next 30 seconds scrolling the window to the bottommost-recent-message. Horrible.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#175Rocket.chat is also a very nice alternative and supports more use cases. We use it internally and also as part of our product.
I completely concur. We used Rocket.Chat (running containerized on OpenShift, our Kubernetes distro) for a time at Red Hat to support the bulk of Red Hat Consulting. Many thousands of messages per minute sustained throughput. All of Red Hat has "restandardized" in the last year but I personally miss Rocket.Chat.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#176Earlier quoted context omitted.
Many companies using such a system wouldn't even want federation, and it adds a bunch of complexity.
So run a local server and turn federation off. Like you can run a private e-mail server. Why not use and contribute to the common protocol that does allow federation? I see no point for a FOSS project in proliferating non federated IM protocols, and wasting resources on that, while federated ones still didn't even reach wide adoption.
Because then you're bound to the common protocol and it's development process, which is a waste if you have no intention of using federation.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#177Earlier quoted context omitted.
So run a local server and turn federation off. Like you can run a private e-mail server. Why not use and contribute to the common protocol that does allow federation? I see no point for a FOSS project in proliferating non federated IM protocols, and wasting resources on that, while federated ones still didn't even reach wide adoption.
Because then you're bound to the common protocol and it's development process, which is a waste if you have no intention of using federation.
I view it the opposite way. It's waste of time to reinvent the wheel and not concentrate resources. Federated protocol can be used without federation fine, but not the other way around. For FOSS projects, not doing it is strange, especially when lack of adoption for federated options is still a major global problem.
So I'd question the intent behind this particular project. For those who don't care about openness (like Slack), I'd expect such behavior. But for open projects - not really.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#178Earlier quoted context omitted.
Hi, Mattermost PM here. We also have other voice, video and screenshare integrations, including self-hosted on-prem and private cloud options. Zoom, Webex, BigBlueButton, WebRTC and more: https://docs.mattermost.com/deployment/video-and-audio-calli...
Cool, thank you both. I think WebRTC or Jitsi are closest to what I would be looking for, as I want to keep it open source, but I appreciate the Zoom and other integrations for how they could be useful to business. You guys might consider Mumble/Murmur integration, I think it could be a great addition, as it was my favorite voice app before Discord took over everything (still is).
Jitsi is WebRTC as well :)
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#179Earlier quoted context omitted.
> Potentially controversial opinion: This isn't really open source. I know you were looking for this but I don't agree. Let's remind that Open Source fundamentally means _no expectations_. No expectations of support, no expectations of features, not even expectations of goodwill. Whenever a company complains that this or that open-source software doesn't work as expected and should do this, we all shout in chorus "th…
> Let's remind that Open Source fundamentally means _no expectations_. No. Open Source, as defined, is about what the end user is allowed to do with the code they have. That’s it. What you describe is common , but not inherent. There are plenty of exceptions, like if you get Red Hat, you’ll get to have plenty of expectations, and Red Hat is still Open Source . Please stop the ancient FUD about Open Source means havin…
When I say open source means no expectations of support I obviously talk about the license the software comes with, not the overall idea and goals that are common in the open source world.
You want support! Great, it exists and can even provided by multiple different actors, with or without expected quality of service, and that's great! But that is not included in the license, you have to find another arrangement on the side. Maybe you can ask nicely and they will do it for free, maybe they'll ask you to pay them in beers, maybe they'll ask for a specific contract detailing everything. Same goes with features, you can ask for new ones but that is not part of the license. That's it, that's all my message was about.
Re: Story of Mattermost: Open-Sourced Competitor to Slack
#180What about zulip? They seem to fare well in terms of features against slack and mattermost.
We weren't too happy with Mattermost and moved to Zulip after a while at my place.. it's a bit nicer, but I'd still pick IRC if given the choice.