4 ms·
Some other open Slack alternatives I know about include: Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementation
by qaute 7y ago
Some other open Slack alternatives I know about include:
Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta.
Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support.
Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess.
Apologies for any inaccuracies or omissions; I'm not an expert in the space.
[1] https://matrix.org/ https://matrix.org/
[2] https://zulipchat.com/ https://zulipchat.com/
[3] https://rocket.chat/ https://rocket.chat/
[4] https://mattermost.com/ https://mattermost.com/
- graphememes 7y agoNone of these will: - "replace email" - "increase productivity" - "centralize communication" None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time. But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise. Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare. Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
- wtetzner 7y agoHonestly, chat at an organization only seems to replace phone calls, and only partially. Which is not a bad thing, but I'm not sure it's even a good idea to try to replace email.
- buboard 7y agoQuestion about the requirements of those alternatives (and slack i suppose). Zulip for example says if you have > 100 users you need a machine with 4GB RAM and 2 CPUs. Why does a chat app need a lot of processing power? I guess most of the messages are simple text, and IRC could handle thousands of users ages ago. What is the processing used for ?
- price 7y agoThe Zulip server uses very little CPU, but the RAM is important. (I work on Zulip.) Here's what the docs say, for reference (excerpt of https://zulip.readthedocs.io/en/latest/production/maintain-secure-upgrade.html#scalability https://zulip.readthedocs.io/en/latest/production/maintain-s... ): > For an organization with 100+ users, it’s important to have more than 4GB of RAM on the system. Zulip will install on a system with 2GB of RAM, but with less than 3.5GB of RAM, it will run its queue processors multithreaded to conserve memory; this creates a significant performance bottleneck. > chat.zulip.org, with thousands of user accounts and thousands of messages sent every week, has 8GB of RAM, 4 cores, and 80GB of disk. The CPUs are essentially always idle, but the 8GB of RAM is important. As a practical matter, I think 4GB of RAM is not a lot to ask for a service that 100+ users are actually concurrently using all day. That's a small fraction of the RAM the clients are consuming; and you can get a suitable cloud machine from Digital Ocean (simpler pricing than AWS, so good for a quick price check) for $20 USD/mo. On the implementation side, it turns out that a lot of moving parts go into a full-featured chat app. Here's a partial architecture diagram, plus detailed exposition: https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html https://zulip.readthedocs.io/en/latest/overview/architecture... Database, plus caches, plus code for lots of features x running in a number of processes, adds up to a few gigs of memory.
- buboard 7y agoWell my question is why they consume so much memory/CPU? What makes these services so different from earlier chat systems? Are these users continuously doing video chat with each other or keep sockets open? For simple text chat, 4GB of RAM seems absurdly high, considering how irc was able to handle thousands of users 3 decades ago.