I have a large family (many siblings, their SOs, some siblings of SOs, some cousins, etc). Many of us are not on Social Media, and the “group text” became untenable. I was able to get everyone to buy in on Slack sometime in 2017… it was great for awhile. Eventually, we hit message limits, and I wasn’t thrilled about Slacks data policies.
After a bit of research, I landed on Mattermost. I explained the reason for the shift, and migrated the whole family over sometime in 2019. As far as the family is concerned, the process was painless, and other than the lack of collapsible threads (recently fixed as mentioned in TIFA!) everything has been great. I run the whole thing on a $5/mo VULTR VM, that also also acts as a WireGuard and PiHole server.
On the backend, I’ve only had one major bump [0]- I went too long between server upgrades (I think I jumped from 5.21 to 5.29). The SQL encoding changed and caused messages to stay “unread.” Took me a day to find/correct the issue, and it’s been smooth sailing ever since.
My experience with being "the person who wants others to switch to the non default option" is that you need to be willing to do all the work: set up, helping people get started, technical support every day of the year, if something breaks because of (in this case) a Mattermost change take the blame, apologize for features that are missing or working differently than in the default option, live with the slight condescension of other who now have to make "all this effort" to install one extra app etc.
So either nemosaltat is incredibly lucky with his family, or he is an extremely patient person. Kudos either way.
That's true but switching family to secure solutions which doesn't require any maintenance say like Signal itself is turning out to be impossible.
I'm talking from my experience in India, WhatsApp has embedded itself deeply in the lifestyle, It is not just a messaging app but 'The gateway for Internet' as smartphones are the first computer for the majority.
So they see a personal connection to it, It has disproportionate level of trust leading to severe misinformation/disinformation issues; Especially alarming during pandemic w.r.t vaccination.
Everything from Govt. messages to banking messages arrive on WhatsApp. I've given up trying to convert people to secure solutions and so I have sandboxed WhatsApp in a VM to receive WhatsApp messages via email[1].
This has been exactly my experience. My family is used to me advocating for various “security best practices.” I’ve always been the “family tech support guy,” so I have ~15+ years of accumulated goodwill. Some folks were a little more resistant than others, but so far there’s been enough family/social pressure.
I’m not the most patient person, but I’ve made extra efforts to be patient with this. I’ve also done everything I can to include/involve interested family members in the process. We have a channel dedicated to feedback on Mattermost itself, and I’ve been able to recruit a few folks to help me evangelize.
I may not be able to change the world, but I can make a difference to those closest to me. I am extremely fortunate to have a family that humors me.
I have wanted to do something like this for a while, but I don't want to end up becoming tech support for my extended family and friends. So will stick to WhatsApp groups.
Maintenance overhead is a genuine problem and a real opportunity, yep.
It'd be nice to see it become as safe and easy to run an infrastructure service (like Mattermost) as it is to manage and update apps on a phone.
We're not too far off from that; small computers like the Raspberry Pi - or even smartphones themselves - could act as servers, and then container images could be used to package and distribute application updates.
Persistent data management becomes an issue at some point.. but that's already true for on-device chat messages. Perhaps SyncThing or similar tools could help there.
> It'd be nice to see it become as safe and easy to run an infrastructure service (like Mattermost) as it is to manage and update apps on a phone.
Sandstorm is basically this. Requires a bit of setup at the start, but afterwards installing apps is like installing phone apps, the apps and Sandstorm itself update automatically, etc.
A few of the apps get regular updates, but admittedly a lot of them have gone stale. Sandstorm's security model makes it so that this isn't a security risk in the way it would be on other platforms, but it's certainly disappointing if you're looking for the latest versions of apps.
It's no longer supported by a company so its pace of development has slowed, but it's still an active project, albeit one run by a small number of volunteers. I'm sure they would appreciate any contributions.
Cloudron is really useful for these situations. They greatly simplify self-hosting by automating upgrades and backups for a bunch of open source apps. Don’t think it runs on RPi’s yet, but they do have packages for both Mattermost and Syncthing.
I'm normally a self-host maxi, so respect for your solution. But may I ask why you didn't use Discord?
I self-hosted a Matrix server for family chat reasons but the encryption key changes (Let's Encrypt) and frequent need to re-login became a hassle for me and the "membership group" at large. Tried out Discord, haven't looked back.
My mother-in-law even created her own Discord "server" (all done very easily in-app) with no help from anyone.
Very slightly worried about content not being in my control, but shopping lists, pictures of the cat being cute, and requests to pre-heat the oven aren't high on my snooping paranoia list.
I wanted a solution I could self host. Discord doesn’t allow self-hosting, and at least according to their feedback forum, they don’t plan to[0]. I remember reading an explanation (an FAQ on their site I think, but can’t find it now). It was to the effect of “Our CI strategy is designed to provide all users with the best experience, so we can’t allow versions to get too far behind…” or something like that. Whatever their reasoning they’re closed source, proprietary, and commercial, and unlike SelfHosted [1], I don’t mind the hosting fees or extra work to run it myself.
That option doesn't seem to work for me, but personally, if I need to use another discord account, I just use another Discord client, as Discord has 3 official ones (Stable, PTB, and Canary) <https://support.discord.com/hc/en-us/articles/360035675191-D...>, which all use their own account/data. For mobile, my OnePlus phone has a built in multi account app thing called Parallel Apps, and there are apps for it on Android.
Thank you, it's good to know, but is it supported on mobile apps? I think it's more problem on mobile, because on desktop, mostly Discord can be used in browser so Chrome profile or Firefox container works.
Oh, I don't really use it on mobile :( . It's on my work laptop where like you I keep my private and work accounts separate :) . You could certainly do it with multicontainer on android firefox but not on iphone :( . I suppose you could install multiple browsers in that case but again I only need in emergency situations on my phone.
Sounds like you didn't set up certificate renewal automation for LetsEncrypt via something like certbot? I can imagine that could be a hassle.
I'm curious by what you mean by frequent need to re-login in the context of Matrix? I've had a Matrix server for several years now and never needed to re-login.
The Riot android client would, periodically, require re-signing in.
The certificate issues were more specifically related to Apple devices not liking that an accepted certificate had expired, and a new one had taken its place, and wouldn't even allow for the updated certificate to be "trusted" in place of the expired one. On Android I'd have to accept a new certificate to trust, and it allowed me to do so - although possibly this resulted in the requirement to re-login (and if memory serves, old messages would be unreadable).
These issues may have been of my own making, or may be fixed now, but I've been using Discord happily for a whole now.
P.S. I don't multi-account on Discord (because I didn't know you could), but I do have different names depending on the server context.
> The certificate issues were more specifically related to Apple devices not liking that an accepted certificate had expired, and a new one had taken its place, and wouldn't even allow for the updated certificate to be "trusted" in place of the expired one. On Android I'd have to accept a new certificate to trust, and it allowed me to do so - although possibly this resulted in the requirement to re-login
Huh, that doesn't sound right. You shouldn't be having to accept anything -- a renewed certificate should just work, transparently, without any interruption. You shouldn't even notice it changed.
Given that a large part of the web now uses LetsEncrypt, if this wasn't so, you would've already had problems on other websites as well.
> (and if memory serves, old messages would be unreadable).
This may have been the case if you managed to lose your keys. This is quite unlikely now since (encrypted) server-side backup of keys is supported. Additionally, if you have more than one device, one of them will likely continue to have keys and can share them with the new device once it is verified.
It may have been a quirk of the Riot client app. All I know is, whenever the cert got updated, the ipad app spat the dummy, although the message about a different certificate seemed to be more a basic ipad security warning than Riot-app-specific.
The Android Riot client was fine with the updated cert, other than the cert update possibly being the catalyst for needing to re-login.
This was three-odd years ago, not sure how much progress there's been since (including on my side in the use of certbot).
I use certbot to automate certificate updates on a couple of self-hosted sites, and it works fine for them - it really was just the ipad being repeatedly / repeatably finicky back then.
agreed. I use Certbot for my server and Mattermost requires re-login every 30 days. I believe there’s a setting in the admin console to change the required relogin frequency.
Hmm, based on what i've heard, Mattermost is indeed pretty popular software - it seems to have a whole bunch of integrations with other platforms, for example, GitLab!
That said, personally i use Rocket.Chat, which has been pretty easy to self host: https://rocket.chat/
I'm sure that someone who has experience with both could drop by and share their experience, but if nothing else, it's at least nice to have these options to choose from.
Either way, i can definitely confirm that most of these platforms indeed are very well off on smaller VPSes, as long as you don't have too much data in them (think file uploads rather than just messages).
Getting more support for something like that in the company that i work in, however, is another story entirely. For a while they tried Nextcloud Talk, but it was a bit too barebones: https://nextcloud.com/talk/
And ever since, sadly, there has been little to no interest in setting up another self-hosted platform, even if there are teams whose old messages are eaten away by Slack's limitations, the management seemingly having little to no interest in paying a bit of money for it.
We run a stupidly simple (though small scale) gitlab instance in docker (official image its kinda one-click install). You get mattermost automatically, just need to enable it in the gitlab config and it will install/run mattermost within the gitlab container without any troubles.
So if you already have (self-hosted) gitlab, mattermost is easy to setup and maintain (actually no extra effort at all). Depends of course on the number of users, I guess...
The integrations with gitlab issues/groups/etc are also look neat but are barely used tbh. Cant compare with rocket.chat.
As former Slack users, threaded messaging is huge for us. I wonder if teams who landed on Mattermost before using an alternative which used threaded messaging feel the same way?
Note: you do need to flip the feature flag to try it out:
Account Settings > Display > Collapsed Reply Threads (Beta).
Personally I cannot stand threaded messaging - maybe it’s the IRC user in me, but I cannot stand having new messages randomly pop up at random points instead of at the bottom. If you have a discussion that is longer term or needs a separate context then spin it off to a different/new channel, otherwise I’ll spend forever searching for it again anyway.
This is an UX problem. There's supposed to be a list of threads so that you can find the one you're looking for easily. A thread is essentially a lite channel which shares all of the members of the original channel automatically.
Mattermost has both! Messages always appear in sequence. Replies in a thread are visually identified as reply including the thread it is part of. This way you can do both grouping of discussions and follow the discussions from higher over.
You only need custom builds if you want to use your custom push notification server. Since push notifications are handled by GCM (Android) / APNS (IOS), for some customers, they fail compliance regulations.
If you just want to self-host mattermost, push notifications should work out of box.
I've been running a MM server for about three years. It's been great, though lately I've been a little worried about it. They added stuff like in-app marketing to admins, under the guise of being helpful — you know, teaching us about exciting new premium features — oh, and by the way, you can't turn it off. When apps start to do things like that, it feels like more drastic monetization strategies can't be far behind.
Mattermost CEO here, sorry to hear you had a negative experience with the admin adviser. Thank you for the feedback.
Mattermost Team Edition is designed for teams (I.e. groups of people that work together and trust each other) and there were issues when Team Edition was deployed to unintended use cases—-like hosting hundreds of users, saving millions of posts, or other scenarios outside of what a team was meant to do.
Admin adviser was meant to help admins who hit those scenarios, and some of the advisory in scenarios Team Edition wasn’t intended to handle was for the Enterprise Edition. It sounds like that came across the wrong way and we should revisit.
Note: I think a fair chunk of admin advisor was paused a while ago. Not sure how much is running these days. Regardless we should take a look.
I run a fairly big instance with hundreds of users. We wanted to support/promote a more free/libre alternative to Slack, but you are basically saying we should not use Mattermost?
(I think that channel deletion was a concern at some point, but archiving mitigates it, we are happy users in general)
We offer a non-profit license for open-source projects [0] with special nonprofit pricing. We also plan to move the System Permissions Scheme into the open source Team Edition with the 6.0 release on September 15 [1].
Thanks for being a user, feedback is always welcome!
Yeah we (a University CS department) had the same experience. We've run Mattermost for a number of years but the advisor bar was a bit of a blunt instrument. The only way to dismiss it permanently was to share your email address with their sales team and consent to being contacted. We'd have had a similarly unfavourable view if Nginx, Ubuntu or Thunderbird done the same thing.
And now when you enter the system console, the very first thing you so is the Upgrade to Enterprise Edition CTA button. It concerns me that they'll keep pushing free (OSS) users towards the paid product. They've eroded some of our trust and given the choice we'd probably go in another direction in the future.
Really appreciate your feedback. We had intended to pause the admin advisor notifications couple of months ago but due to an intended bug some of the messages are still coming through. We've queued an update to pause them in the next release (v5.38). [1]
The original vision for the admin advisor notification feature was to guide administrators through proper activation and configuration of the system as the needs of their user base evolves, with some additional capabilities in the Enterprise offering. However, based on the feedback we received, it was evident that the experience felt spammy with limited value which was not the intent, negatively impacting the trust with our community. Hence why we've decided to pause admin advisor notifications at this time.
I can also recommend a console client (in Haskell) - Matterhorn [1]. For me, the biggest obstacle right now is the lack of support of chat categories in mobile [2] client and Matterhorn [3]. These chat categories are available in the web interface.
Thanks @xvilka, Mattermost CEO here. Categories are a new feature, in beta in a lot of deployments. It’ll take a little bit for the other clients to catch up. Definitely one of the most popular new features.
I tried using Mattermost for internal projects a while ago. Apparently, it needs to call the mothership every so often and doesn't seem to work/install otherwise (IIRC, tried running docker images on "internal" network only), which i found to be pretty strange and a big nono. Ended up spinning up an IRC server instead.
But MM is still nicer than slack/discord in terms of controlling your data.
I can confirm that's not the case. We have diagnostic and error reporting functionality built-in which is documented here https://docs.mattermost.com/manage/telemetry.html and can be disabled either through the config file before starting the server or in the UI afterwards.
We have quite a few customers deploying Mattermost in air-gapped environments, so even for the enterprise versions we don't require internet connectivity.
There are some things that may not work without any internet connectivity, such as mobile push notifications, since that requires Mattermost Server to connect to our Push Proxy by default. You can host that yourself but will need a custom Apple/Android mobile app then, and the push proxy still needs internet connectivity in the end to reach Apple/Android Push Notification Services. Also our plugin marketplace may not work and you need to download and upload plugins manually.
So overall, some convenience functions may not work, but overall Mattermost can be deployed air-gapped and doesn't have any phone-home aside from optional diagnostics. Let me know if there are any other questions!
(Disclosure: I am working at Mattermost in Security)
even for the enterprise versions we don't require internet connectivity
That's an odd phrasing to me. I would expect the enterprise version to offer more admin features, so of course that version would have the option to disable the Internet requirements. Can you confirm it's the same for all other versions?
As @jasonblais confirmed, it's the same across all versions. I added this specifically since some software requires internet connectivity for license checks and wanted to clarify that this isn't the case with either Mattermost version, open source or enterprise.
Mattermost is great, but I wish they natively supported the Matrix protocol to enable federation. Or — at least — made it possible to integrate a "natively-looking" third-party bridge, similarly to how Gitter does it.
1. It's the most expensive chat out there, at $10/month and no free plan.
2. Focalboard is being integrated to be part of the chat. Focalboard doesn't currently do much that I find interesting, but I have hope that it will with time.
On 1), our SaaS version is equivalent to our higher end Enterprise Edition E20 and aimed at larger orgs. For small orgs we have the open source version that can be easily self-hosted. That said, it sounds like price is material for you, so maybe there’s something we can do at a lower price tier, with features closer to our open source product.
On 2), Focalboard is still in its early days. We are using it internally and with early adopters of the open source version and are pretty excited about where it could go—replacing Trello, Asana, Notion, Jire, Confluence on-prem and as SaaS in the long run, and on an open source platform you can customize.
Our hope is in future there could be a “Why we switched to Mattermost and Focalboard” with a blog post on replacing a fair chunk of the collaboration stack with an open source alternative that could be extended.
When looking for a slack alternative, please primarily look at matrix. It's open source (not open core or source available) and based on open federation. And it keeps improving at a nice rate.
Matrix/Element's UX is abysmal, it's not a viable alternative to anything. I continue to get 4 popups (two of them modal) every time I login, and I have to login every time I open it because it doesn't remember logins. And it happens not on just one system, but on two different browsers on two different PCs.
The only even close to being something I could let my non-techy friends or relatives use is FluffyPokemon or RainbowUnicorn or something like that.
And even it's still missing features.
Cinny (https://cinny.in) is the first Matrix client that actually looks promising. They just plain stole Slack's UX and it's working. There's no need to be unique for the sake of being unique when it comes to UX.
Matrix the technology is pretty good, partly excellent.
The clients though... whooo boy. Element is so bad that it hurts to use it. The worst part is that it doesn't have a singular major flaw, it has a hundred tiny issues that are just a bit wonky.
Matrix is not community-driven, it's linked to and driven by some shady company rooted in the israeli intelligence sector. If you want real messaging freedom you should consider xmpp instead.
Will OpenSSL reject properly implemented features contributed by third parties, because you sell paid features on top of OpenSSL and said contributions happen to make your product redundant?
That's the difference. Mattermost won't ever accept contributions, that reimplement features from their paid product. If you want to use such features, you would have to fork, and forced to keep the fork public, since it is AGPL.
Having used essentially all of these kinds of software (life as a freelancer, I think I had 8 different chat apps on my laptop at one point :/) I can genuinely say that Zulip combined with Jitsi Meet is the happy path (at least for me). I found MM quite clunky (although it's been about 2 years since I saw it in the wild) and Slack intolerable.
Weirdly, I actually didn't mind Teams too much, after you stop creating new conversations instead of replying (which took me WEEKS), it was reasonably stable and it just sort of worked for me. Although I hear a lot of people gripe about it.
The content marketing came on a little strong for me, but a good post nonetheless. Messaging is the heart of a remote org and it should be “on premise” by default.
Well said. We are strong believers in open source and zero trust but reading the post with fresh eyes instead of writing it does make me realize there are some parts of that post in which we can dial back our enthusiasm (OP here). Thanks for the candid comment.
That said, it worked on me :) I've subjected people to using VPNs and I would rather have a worse security posture than to do that again. I'm really intrigued by Netfoundry and agentless zero-trust networking. I've POC'ed ZeroTier + whitelisting but doing so in the app sounds like a great approach!
> Messaging is the heart of a remote org and it should be “on premise” by default
Really not sure about that. I work at an MSP/MHP that has infrastructure everywhere ( multiple DCs, AWS, Azure, GCP, OVH, etc.) and recently we had a huge network outage at a few of our on-prem DCs due to a firmware bug in some redundant networking equipment. Having the communications software "in the cloud" allowed collaboration on fixing and communicating about the issue.
Sometimes it's a good idea not to have all the eggs in one basket. In a similar vein, if your "on-prem" is dead, how do you access the documentation helping you debug/connect/etc.?
Having multiple comms channels totally makes sense. I quoted “on premise” as most remote orgs are pretty much all cloud (though some may use colo)- which is really to say on hardware where a SaaS vendor doesn’t hold the keys. I can’t imagine how catastrophic a Slack hack would be for many orgs, and in that scenario you’re entirely dependent on their security and disclosure. It’s completely within their TOS to read your messages for various purposes, along with any apps that have been given access. That’s a pretty weak security posture if dealing with secret IP or other sensitive info. While nothing is guaranteed to be secure, limiting access to your team only seems like a smarter place to start for those who need privacy. Many companies really don’t, or at least accept a small level of risk.
In terms of losing systems that you need to access while troubleshooting systems issues, that can be a mess with self-hosted tools, but nobody is immune. When AWS had a cascading network failure at US -East-1, their team was unable to access their logging service which made triage incredibly difficult. That’s super rare, and unlikely to happen again for AWS in that manner, but outages can cripple any ops team. Runbooks are a great thing to copy offline!
I don't think the messaging platform should always be on-premise. You can consider running it on premise, but it's not an obvious decision.
I worked on a couple of teams, and somehow no IT team could make the chat apps run reliably: we always had disconnects, terrible loading times, lost messages and we had to jump through hoops to enable the most basic integrations. No regular updates, outdated apps that are years behind in looks, features and integrations.
Whenever we just simply used Slack, it was snappy, reliable, and it was easy to set up connectors for different external services.
Do the Mattermost mobile apps let you log into multiple teams at the same time yet? That was always the sticking point for my social groups and the reason we went with Slack or Discord. I looked and saw some rather inconclusive JIRA tickets, ranging from "it's impossible" to "it's on the roadmap".
This is the thing that keeps me from recommending Mattermost in education. We had no end of trouble with MS Teams for the same reason. Students logged into our instance couldn't access their work systems. MS has made some progress to fixing this, though it has a way to go before it's as easy as Slack/Discord etc.
In my mind the gold standard is Discord. One login/password/mfa and I have access to hundreds of "servers". I have over 30 slack passwords and MFA tokens in my password manager and I know people with many more. Though I suspect the ability to self host Mattermost will make it more like Slack than Discord there.
I would also like to say thank you. Mattermost is one of the few products I've seen that doesn't lock MFA behind an enterprise subscription. I can't stress enough how happy I was to see that.
Discord still has basic usability issues there if you want to, for example, keep your work and personal accounts separate. Slack is really the gold standard because it understands the need for that separation.
It's a pain, in my opinion to switch between accounts in Slack. I've only been able to keep up with one a time, especially on mobile. I realize that is a feature, but I haven't wanted to introduce Slack outside work setting since I didn't think I could keep up.
Could someone explain what is zero trust in this context? In what way using Slack differs from the zero trust approach? (Is this about being able to self host?)
Zero trust means this solution does not depend on ('trust') hosts or networks (VPNs, firewalls, SD-WAN,etc) to communicate between the Mattermost client and the Mattermost server.
This means:
1. You limit your attack surfaces.
Threats on your LAN, WAN or Internet can't communicate with the user computer or the server, e.g. they can't be landing points (attack surfaces) for malware or ransomware.
2. You isolate any damage
In a full zero trust architecture, if one app is compromised, then there is no network for the virus to leverage to spread. For example, a ransomware loader can't call home to acquire more robust functionality, and can't find other data on your network to infiltrate and encrypt. This is because the loader is not on a 'trust' network in which it has access simply because it found its way into a network.
Other solutions are open to networks (large attack surfaces) and are susceptible to spreading attacks (as they spread through the 'trusted' network).
My small team uses and loves Mattermost. It's a great FOSS project.
And, direct access to the PG database has been awesome for integrations. (Watch out tho, seems to be missing a bunch of FKs (that I think should be there))
We used MM in the past and switched to Zulip. The docker upgrade path of MM is a pain and lacks support. (They switched to a new postgres version without providing any upgrade tutorial.) But honestly if you like to use a team chat to get work done Zulip works the best. The thread tagging inside a group and the keyboard support makes it easy to follow different conversations in a stream.
This may differ between countries, but locally - knowing a specific app exists. A clinic buys software that fulfills the requirements and knows nothing about the license. As long as someone can install it, operate it and provide support, it can be literally anything.
As long as the decision makers know something is available and actually provides value (and the decision makers are not stubborn and set in their ways for decades), it will be implemented.
Caveat - people writing most medical/billing software don't have any incentive to release it as FOSS and they have more money for promotion than any FOSS project.
In healthcare one should be very strict about who gets to see patient data. At least our healthcare laws say that only healthcare personnel involved in the care of a patient can see health information of that patient
So one cannot use e.g. slack channels to shout to everyone about some problem. The usage pattern should be closer to email or an issue tracker with only involved doctors and nurses added to each patient or case. Email is of course unsuitable because of how easily information can slip out unprotected.
Unfortunately, doctors are people like the rest of us, use whatsapp and facebook to ask thousands of colleagues for help with their patients. Totally against the law.
My team at work piloted using Mattermost before my company finally settled on Microsoft Teams company-wide. Something about Mattermost was just so much more engaging than Teams. People chimed in with answers and opinions on things way more. There was team bonding in the form of custom reactions and plenty of "off-topic" banter in the appropriate places. Teams just feels so dead in comparison. Maybe it's the way channels and notifications work. Maybe it's the lack of custom reactions. Maybe my team just had too much turnover. I don't know.
We've been using MM for about a year now as a company group chat, and it's pretty great! The only gripe I have now (besides collapsed threads looking awful: which seems to be fixed in the latest beta!) is that the data (i.e. chats) is stored unencrypted in our MySQL database. Being a tech company lots of ours engineer 'theoretically' have access to this database. I believe MM suggests to some higher level db encryption to solve this, but this is not ideal.
I have used local FOSS mattermost with my entire team and it was much better experience then alternatives. Much better.
The only thing I missed is FOSS LDAP connector, I am strong believer that at least in some basic form it should come in such products - after all, you don't use such tools if you are not in enterprise and not having at least login is seriously problematic. We finished using Gitlab auth instead of it but I don't like that we are coupled to it.
I’ll have to give MM a try. I’m fairly unhappy with the basic quality of Slack, but it hasn’t been a showstopper for me.
I’m definitely not a Slack “power user.” In fact, I had to be dragged kicking and screaming into using it (I don’t like IM communication, in general), because everyone else uses it.
That “everyone else uses it” is the biggest hurdle for MM.
We (well I) managed to get Mattermost pretty much standardised as a chat platform in a previous job.
It was easy to just whip up a Docker container with it with the help of our IT folks and then it's go time.
We managed to get the on-site license approved by appealing to the corp's high focus on security (the head of security was ex-military, so he was _strict_ about security). Slack would've been WAY too expensive to get approved.
All this before the penny-pinchers figured out that Teams would've been free. At that point Mattermost was integrated into dev processes everywhere and it was too late to move out.
I've run a Linode-hosted Mattermost server for four or five years now, mostly so that my brother and I can chat over multiple topics and projects. No regrets. Low maintenance.
It's been mostly free of hiccups of any sort. Occasionally it crashes, but I haven't been curious enough to figure out if it is something I can fix.
Quality of Life reasons in my opinion. I think, for one, emoji reactions add a lot to a group chat. If there's no option to simply "like", "laugh" etc, people will write their reactions as text, and that quickly pushes the original message up, out of the screen maybe too. (Same problem with old style forums, vs a reddit-like interface).
But this is just UI candy, could be implemented in an IRC client too. From a protocol standpoint, what IRC really lacks is the consistent handling of chat history. I can imagine IRC handling this too; every registered user could always be "online" on the server, and therefore receiving all messages, and when their client actually connects, they would see the messages similarly how the IMAP works for email. But this is really reaching now, isn't it? Why not just use something that's similar in spirit, but actually updated to the moders internet, like the Matrix protocol?
I would be curious whether they considered Zulip or any of the other open source chat alternatives in this decision, and how they compared.
my sense is that chat is one of those areas where there's not so much obvious differentiation from the outside, and a lot of stickiness once you land somewhere, which implies there will remain 5-10 players in the space for some time to come.
Hmm... your post is useful for others who are considering Mattermost -- certainly may help others who have similar priorities. That said, I think you could have made the same point without being negative about other product. You aren't trying to be negative, but it does come off that way. I think you could make the same statement and impact without even mentioning Slack or its negatives in your case -- just focus on the positives of Mattermost for your use case.
We're on Slack and gave Rocket.chat a chance, but the UI is cumbersome and wasn't very well received. Slack is not only free (we use it for hundreds of employees and we don't even pay a dime), and Rocket.chat is self hosted. Easy choice, for the time being.
.org and .com is common practice for many project - just maybe should make sure there is a link between 2 sites - I checked your site .com and even when opensource is mentionnned, it's on the .com site - instead of linking to the .org... just my 2cents
I don’t know what the parent comment said, but more screenshots on your site would be great! The .org site you linked to had screenshots on the front page, which was great, but a gallery link would be fantastic.
After a bit of research, I landed on Mattermost. I explained the reason for the shift, and migrated the whole family over sometime in 2019. As far as the family is concerned, the process was painless, and other than the lack of collapsible threads (recently fixed as mentioned in TIFA!) everything has been great. I run the whole thing on a $5/mo VULTR VM, that also also acts as a WireGuard and PiHole server.
On the backend, I’ve only had one major bump [0]- I went too long between server upgrades (I think I jumped from 5.21 to 5.29). The SQL encoding changed and caused messages to stay “unread.” Took me a day to find/correct the issue, and it’s been smooth sailing ever since.
[0] https://forum.mattermost.org/t/solved-after-upgrading-to-5-2...