What you put in there is basically closed from the public, complete opposit of openness.
Does matrix / someone else solve it? How?
We provide our full Zulip Cloud Standard paid plan for free to open source projects (and various other worthy causes!). We also prioritize and build features specifically because OSS projects asked for them:
https://zulip.com/for/open-source/
Hundreds of open source projects, including Rust, Julia, MariaDB, and Clojure, use Zulip as their team chat platform. We often hear from large open source projects that they substantially prefer Zulip's topic-based model to the user experience in Discord or Slack, or that they found it made their open source community work. See for example these tweets from the last few weeks:
* https://twitter.com/mojavelinux/status/1409702273400201217
* https://twitter.com/ornicar/status/1412672302601457664
Also in contrast with open core products like Mattermost, Zulip is proudly 100% open source software. You can learn a bit more about Zulip's open source model here:
https://blog.zulip.com/2021/04/28/why-zulip-is-on-github-spo...
Personally, i find Rocket.Chat ( https://rocket.chat/ ) to be simple enough to set up in a Docker container and have running as a passable alternative to Slack/Discord. There are downloadable clients as well. The only real downside I've seen is somewhat bad support for calls because their WebRTC implementation is still new and integrating with Big blue button or whatever else they offered is hard.
I'm not sure about this detail of Slack's ToS. At a technical level, you can certainly export your data from a Slack (which is we implement https://zulip.com/help/import-from-slack); I imagine it's easy to write a tool to format and publish it.
FWIW Zulip maintains https://github.com/zulip/zulip-archive, which is a configurable API-based tool for creating a static HTML archive from a Zulip organization, with tooling to update it every few minutes. A lot of larger open projects use it. (We're also working on a native logged-out access feature with less janky formatting, which has a working PR that we need to integrate).
I suppose you could export your data from Slack, import it into Zulip, and then publish that using zulip-archive if you didn't want to write any code, but I'm sure the formatting would be better preserved if one avoided the "convert Slack markup to Zulip markup" step.
There is a hosted SaaS version of Mattermost as well. We don't have an established non-profit license for it yet, but you can contact community[at]mattermost.com and we'd be happy to discuss options.
Then no one can limit the messages that you can have in the chat or make you pay for many of the features or suddenly take the software away from you or make you have an outage due to external factors of any software vendor.
And if you want automatic updates, then either use the :latest tag, use apt/yum/... packages with unattended upgrades or something like Snaps for Ubuntu. However, in my experience, updates should be done manually and only when you're ready to roll them back (unless there are non-breaking security updates which are only available for OSes most of the time).
As for spam, if you can't moderate your Discord or Slack Space, then the same will apply here, of course.
As for getting owned: if your passwords are simple enough to be guessed or you don't follow other best practices, then the same will apply both to SaaS offerings and the software you're hosting yourself. Basic common sense like not exposing DBs to the Internet and using your firewall to only expose the ports you want was assumed, but not explicitly pointed out in my post.
On one hand, feeding a YAML file into a container orchestration solution takes care of some of those concerns, as does enabling VPS backups and using something like KeePass to generate passwords (which can also be used for everything else, should you so desire).
On the other hand, not everyone necessarily knows how to do that, or wants to do that. To that, i'll indeed concede.
It's just that claiming that these things are too hard for the average technically inclined person to do (regardless of whether they have 2 or 10 years of experience) leads to a mindset in which people rely on SaaSS for everything and never even learn how to run their own software, thus either paying too much for it (relative to the worth it provides them with), or just locking themselves into a particular vendor.
Lastly, by hosting your own software, you are a smaller target than the larger and more centralized SaaS platforms. If a large SaaS gets hacked, although unlikely, it will affect a large amount of people. If your own instance gets hacked, even if more likely (less visible to hackers, almost no gain to be had for hacking John Doe's Nextcloud instance, yet probably also easier to do), it will only affect the few people using it.