Setting up Mattermost was one of the best decisions we've made with regards to our tools.
I'm quite sure they are open to pull-requests..
people can have an opinion you know. this is my opinion.
Element is literally built for airgapped company-wide deployments - this is precisely what https://element.io/server-suite is? It was originally built to install onto SIPRnet; it's been airgap-first since day 1.
> Mattermost is an open core, self-hosted collaboration platform that offers chat, workflow automation, voice calling, screen sharing, and AI integration
Notably, they do have some "source-available" code that goes into the enterprise release, at https://github.com/mattermost/mattermost/tree/master/server/...
This mainly seems to relate to metrics and fuzzy search, though it's possible more will move here in the future (it looks like this is a relatively recent development). Until recently they also had experimental support for Bleve full-text search (now seemingly deprecated), but the elasticsearch enterprise feature seems to be the replacement (otherwise they use postgres's ILIKE for built-in text search)
So, all told, Mattermost was open source, and may be moving to open core. Which means now is probably the best time to create a community-maintained fork. The team edition, and almost all features, are currently still open source.
If those any of those 4 screenshot snippets are of Mattermost, it's not very clear. All I see is screenshots of what appears to be Slack.
This is so important these days. A lot of project send users to discord, slack for documentation and help but they are not made for this purpose. Searching in chat channel for a specific problem is not a good way to handle documentation. I can't even use search engines to search that.
I just wanted to highlight this. I am so happy seeing this written down explicitly and finally.
Throughout the years I struggled so much finding relevant and accurate information about a feature of a product because it was scattered in chat channels, inadequate for providing reliable data (out of date or uncertain staleness, evolving or straight up wrong suggestions found, tangential only, patial, ...). Big names do it (Unity3D, DevExpress, ...). To make the matter worst both official support personel and power users promote its use, defend its use against critique to the last blood, despite of the obvious shortcomings and unreliability for average users. It is just the lazy excuse of providing the necessary knowledge.
So why don't all of these people simply write it down in a notion/document store and meticulously keep it all up to date?
Because the business does not want that. We demand efficiency, so we understaff engineering departments sufficiently that there is always a little crunch, so that slightly-too-few engineers have to work slightly-harder-than-they-want to make the business successful. The end result of this intentionally engineered "lack of time" is that things like maintaining meticulous documentation are ignored, and the only time the knowledge is shared is in a frantic slack message.
The business is designed to do this. It's not laziness. It's the standard operating procedure to increase efficiency and profit.
This is so true.
And it is making the industry eating itself.
The purpose of the software is not profit, but usability. Profit for the organization/owner is a tool to achive that, in some instances (it is very valuable, but not essential).
The primary self-serving focus of bigger and quicker profit leads to serious erosion of trust in technology, making the life of those building a livelihood on top of it shaky at best.
If you want to avoid it you'd need to build patched versions of the app and distribute them yourself to your users, so you pay Google/Apple directly for notifications instead of going through Zulip.
And yet the "red flag" being discussed is Zulip having monetization for self-hosted business use? (Mobile notifications have always been free for most communities, and we have discount programs for various use cases detailed on our pricing page).
Look, in 2025, and one should be very wary of rugpulls. But Zulip has no venture investors. I've personally funded the project for almost a decade now, so that it can operate in line with our values (https://zulip.com/values/).
I want to use applications that are ethically managed, self-hostable, privacy-supporting, open-source, and excellent. Zulip aims to be that kind of project, and even with all the community contributions that we've fostered, I don't see how we could maintain Zulip responsibly without our professional team.
Should it be a red flag for an open-source application to have monetization that charges businesses for using services operated by its professional team? Or would the red flag be a project that lacks a professional team who one can count on to maintain it responsibly?
This also is a massive red flag for me, and while I understand that they and you Zulip team has to support a professional team, and you have to do that, and you have every right of doing that, and I’m personally very supportive of this-— still, this move leaves the fear of ‘today this, tomorrow something else.’
Speaking of this very case of 10 mobile users limits, I have a few thoughts. First, it’s entirely possible that you communicate this piece not very well, as I had this impression that Mattermost and Matrix don’t do that, hence maybe it’s possible to host the whole thing on my own and have the notifications. Perhaps they just allow users to use their servers for that for free. This moment is unclear for me, and I had to do my research, which mostly failed, since I still do a guesswork here. I am left with this bitter taste that the issue is artificial on Zulip’s side. Again, not saying it’s your fault, I could be someone who did the research poorly. That was my weekend attempt, and I was super limited on time. Next time I may have more time for that research again (I plan to), but it would happen early next year.
Second, it was mentioned somewhere here as well, the active users strategy. You allow for 10 users, meaning if you’re small team or group, go ahead and use Zulip. But I am a part of an organisation who needs their chat, and they are about 100 people across the country (and the country is Ukraine, meaning they have bigger things to worry about than a chat). But among these 100 people most of them are drivers or cars maintenance team, they mostly need no company chat. If they would use it, it’s a couple of messages a day tops. However, there are managers, and they would use the chat very actively, all day long. They are either less than ten or more than ten (up to 15, 20). I not aware of the exact number of people, since in my city they have just three managers, plus two developers, so there are five people plus me who’d use the chat actively. But since there are others, and they need mobile notifications, we cannot consider Zulip (even when we are able to host in on our own entirely) for this, unless we pay. While the company is for-profit, I cannot even think of asking for anything, and understand the company is better to pay and support you. Yet in this very situation, I’m having hard time explaining it to the boss. He won’t pay for these drivers and cars maintenance teams, as they’re dead souls, technically. They are to receive some instructions and ok them, that’s 90% of the communication for them. So while I’d try my luck with pitching company chat (instead of just using WhatsApp or Facebook or Viber or Telegram), that makes sense only for active users, not for mostly idle users that won’t use the chat actively. And in this very situation, it’s mostly texts, so no heavy images or video calls.
Apart from that, your chat looks one of the best among self-hosted options, I plan at trying it with a group of friends, which is less than 10 people. Forgive me if all this is easily verifiable when you actually used the chat. I only deployed it locally to check the interface (was mostly okay), and researched on the perspectives of using it within a relatively big organisation.
Cheers!
A lot of the data people are worried about is their chat history, because Hack Club isn't really just a nonprofit that gives people things, it's also a community. So it's less about documentation and more about people's chats with each other. (disclaimer: i am not official hack club hq)
The code was made free in 2025 per X post dated Sep 12, 2025 by Jason Fried [0], screenshot available [1].
A quote from Fried's tweet:
Campfire...it's now 100% free...and open source.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction...
Suggestions: Campfire [0] or Zulip [1].
Also, if the data in chat is being held hostage, the org might be using chat wrong. Right tool for right purpose. If starting over, perhaps consider if it would make sense to put that documentation or whatever it is that will get "lost" from Slack into a wiki or repo or other appropriate tool?
Big empathy, though. It must be pretty crushing. But that is why serious geeks have long been for FOSS.