Since you're a nonprofit that teaches coding, it could be a great time to consider self-hosting a FOSS chat tool.
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.
[0] https://once.com/campfire (recently became FOSS)
[1] https://zulip.com
> Also, if the data in chat is being held hostage, the org might be using chat wrong.
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.
> Searching in chat channel for a specific problem is not a good way to handle documentation
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.
It's not lazy, it's by design. We have chat messages because the actual knowledge is stored inside of people, and chat messages are the most searchable way to see what people know outside of being able to ask them personally.
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.
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.
I've never used Mattermost before today. After checking out their site, I can see they are also a for-profit company. What does Mattermost offer that Slack does not, other than a bill lower than $195K/year?
Last time I checked they cripple the self-hosted version, asking to subscribe for enterprise plan here and there. Source: deployed their chat locally a couple of weekends ago. Overall, I liked their Slack clone, they this one was a red flag to me. Now I’m not sure we want to deploy this, but I know very little alternatives. Zulip, but it cripples its self-hosted version too. It allows just 10 mobile users (notifications). Maybe Matrix it is then, but it’s not very suitable for airgapped company-wide deployment.
> Maybe Matrix it is then, but it’s not very suitable for airgapped company-wide deployment
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.
Matrix is the protocol, so doesn’t do implementations (just like w3c doesn’t do web servers any more). But the distribution from Element indeed is self-host first, and doesn’t break stuff if you’re airgapped. The paywall (such as it is) is that features which empower the enterprise over the user are paid, whereas one which empower the end-user are FOSS.
What's your case for calling it open-core? The whole thing is AGPLv3, so... I'd call it FOSS with some components optionally being usable under Apache 2 terms
> Mattermost is an open core, self-hosted collaboration platform that offers chat, workflow automation, voice calling, screen sharing, and AI integration
Interesting. Notably, they also call themselves "open source" in the "About" of the repository. I'm not aware of any critical extensions which are closed-source. The change you've highlighted was made 4 months ago under a commit that gives no explanation: https://github.com/mattermost/mattermost/pull/31247/files , and the discussion there is private.
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.
It sounds like the enterprise release is not open source? When someone above says "The whole thing is AGPLv3," I'm not sure everyone is talking about the same "whole thing"?
Is it? We've been using it self-hosted for years, together with GitLab. It meets all the needs of a small company, and is very pleasant to work with for devs too (i.e., basic Markdown just works, so you can post anything from code to log snippets in a sensible manner).
Setting up Mattermost was one of the best decisions we've made with regards to our tools.
Funny you would mention GitLab - I find it extremely clunky, especially compared to GitHub. Maybe GitHub is primitive in comparison, but it never makes me hunt for basic functionality and the search just works for about everything.
I afraid I nuked my installation already. There were insignificant features, like for their Playbook (or what the name is), where you are offered some extra feature, that goes with the enterprise plan. If I chose my self-hosted instance for some reason, I don’t really need that advertising in my interface all the time. I can understand the reason it’s there, but I don’t like it still.
First time I tested a self-hosted instance was a couple of weeks back. It was their official testing docker container. So perhaps there are versions without that, I don’t know. I assume you should be able to compile this without them, or at least fork the original project. Hence, I’m asking what’s about those banners in real world scenario.
Zulip is awesome. Super easy to self host. Upgrades go very smoothly. Their thread title concept is great (though they are relaxing its requirement lately). The only thing you don't get if you self host is the mobile notifications. This happened recently and it's a bummer but that's what they came up with to monetize the project, as is their right. Paying $5000 for chat is ridiculous to me when such good alternatives exist.
Why would you not be able to get notifications? I use various FOSS apps (and even Whatsapp) on GrapheneOS without Google Play services and notifications work just fine.
Botom line is that's how they want to earn money and it's not supported in their official apps without a subscription. I believe all the plumbing is in place but you have to build and maintain your own push sever intermediary and clients and push server.
Still, crippling the self-hosted version feels like a red flag. Later on, they can easily introduce more features out of self-hosted version. That makes me feel more like ‘we’re business first, but we allow you plebs to contribute towards our success for free’ instead of ‘we’re business and we’re contributing into the community, and as a bonus, the community helps us back.’
The problem with push notifications is that they need to go through the app provider and incur costs for it, that's not really their fault. If they'd not charge for it, they'd still go through their servers and would lose them money. So putting it behind a paid service you hook up to your self-hosted instance seems fair.
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.
Curiously if you ask if they would consider properly supporting notifications from the mobile web version then the answer is always no. Pwa would be perfectly fine but its crippled on Zulip
If you read their announcement for the new paid subscription they do not hide the fact that this is first and foremost designed as a revenue source. One could potentially fork the clients and add such functionality. But they will not do it on their own clients.
I have been following that project for a long time. They are "good people". They want to make sure the project survives. I am bummed about that change and I could probably get the their notification service free if i asked for it (little bit involvement with some things) but I didn't. I respect their decision. Though of course I do have the same concerns as you. I just want to think it won't happen.
Microsoft Teams dominates the team chat market thanks to anti-competitive bundling practices. Slack's proprietary "Slack Connect" federation system requires both users to pay for Slack for their entire workspace. Slack has very aggressive restrictions on exporting your organization's own messages (https://blog.zulip.com/2025/07/24/who-owns-your-slack-histor...).
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?
Hey, thanks for reaching out and truly appreciate the feedback from the team, not someone random on the internet. When I say ‘red flag’ in this context I never mean comparing Zulip to Slack. For me personally (but I believe for most others too, especially right here) Slack was a no-go since about a decade ago. Slack is just a poster child of a huge massive gargantuan Red Flag. I’d never even consider using it in any possible scenario. Whilst Zulip was my _primary_ consideration to deploy for a small organisation (still more than 10 people). Alongside Mattermost and Matrix, who don’t have these limits. So this thing _feels_ like a red flag in comparison. Here, in sibling comments I do write about Mattermost too, with their nudges to buy Enterprise edition here and there, and everywhere. And about their new limits too. (For which there’s Mostly Matter now.)
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.
They are indeed of Slack but the 4th says: “As you have probably read, Hack Club is moving to Mattermost”. But not here to litigate it. It’s easy to miss if you skim.
> Also, if the data in chat is being held hostage, the org might be using chat wrong.
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)
I think it is time we all start moving away from renting software back to owning it (or at the very least, owning a perpetual license). The subscription model is does not exist on a stable plateau. Every company that runs on a subscription model will (and must, by virtue of incentives) to attempt to "develop new revenue streams".
Interesting because the repo only lists a MIT license, with no mention of those requirements. IANAL but those license terms don't seem to be anywhere in the software repository.
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.