My understanding is that Campfire hasn't been actively developed for ~10 years (https://once.com/campfire/changelog shows some minor fixes after the OSS launch; their GitHub has no 2026 commits). There are no mobile apps. It is not an actively maintained Discord alternative.
https://www.rocket.chat/ and https://mattermost.com/ are open-core military contractors these days. You'll see what I mean if you visit their websites. But like Zulip, they are full-featured team chat systems, and if the parts of their system that are OSS work for your organization, they're certainly valid options.
Finally there is Matrix/Element. They have an inspiring vision and similar values to mine, and I'd recommend checking it out. Element/Matrix is built on an ambitious distributed consensus protocol with an E2EE option, which provides capabilities Zulip don't have but also adds complexity. Zulip is focused on just doing team chat really well, and does not support more than ~100K users in an instance. Hopefully will have a lot more resources now, thanks to Current Events. I wish the Element team the very best of luck!
----------------------------------------
Overall, Zulip's focus has always been on making a delightful chat experience, especially when you have multiple conversations happening at the same time. We aren't trying to build a clone, but instead the best possible experience for having lots of possibly complex conversations. So there will be some differences from what you're used to.
But critically, we spend a very large amount of our time relentlessly fixing micro-interactions that annoy us or are reported to us. If you read #design, #issues, and #feedback in https://zulip.com/development-community/, you'll get an idea of how we work.
So while there's some features we don't have that are present in other products, and we don't have dozens of designers on staff to do cool end-of-year animated reports like Discord does, you can expect few bugs and a lot of interaction design polish.
-----------------------------------------
The one mistake that I think a lot of folks make in evaluating options is focusing on buzzwords like E2EE without thinking through their threat model. E2EE doesn't add much practical security over self-hosting for many threat models, and it comes with significant usability trade-offs. And some current E2EE systems don't actually protect against a malicious server, say because they only protect message content, not metadata like who has access to what... just against raiding the server's disk.
(For example, WhatsApp has E2EE for message content, but I expect Meta's databases know everyone who's had a conversation with me on WhatsApp and the precise timestamps and approximate lengths of every message I've sent or received on the platform. And apparently some keyboard apps send what you're typing to remote servers!).
I think the single most convincing feature that I would like in a conversation app is for there to essentially be two companies with a public benefit charter that said that they cannot have common ownership or management, yet provided the same paid service, developed a common product though open source and had an etremely easy migration between them.
Ideally migration should be easy enough that it would be easy enough to automate a mobious strip subscription where it seamlessly alternated between providers.
If that structure existed it would be nearly impossible for a single provider to enshittify. The sad fact is that no matter how many assurances (often sincerely delivered) have been made, we have all seen instances where buyouts, management changes, or just someone in control going nuts, have turned platforms sour.
Open source is great but as this thread shows, just being open source does not mean functional or maintained.
Nothing is certain in this world, but I don't think that means one should give up and just use megacorp software.
And Zulip is specifically designed by some very capable people to be resilient. While we can mess up future versions, but you can always run (forks of) the older version. And as discussed on our values page, we've worked very hard to make the code readable and maintainable. (Various professors use Zulip as a teaching codebase).
We've made a lot of investments in the goal of having keeping-the-lights-on work for Zulip to be doable with a couple excellent people working part-time. It's good for our ability to spend our limited time on improving the product. But it also means that it doesn't require a lot of people to care in order for Zulip to remain functional and maintained. And I certainly care quite a bit.
So while I'd certainly expect other maintainers to introduce a lot more regressions, especially if doing significant changes... If you like the product today, probably the option will exist to continue using roughly that for a long time.
> Campfire hasn't been actively developed for ~10 years
For people looking for a simple chat that stays simple, is this a bad thing? When do we call something feature complete? If a product is free, they no longer need to manufacture new features to justify continued payments. It does look like there were updates 2 months ago. Based on the few number of open issues, and a PR closed last week, it feels like it’s being maintained, even if it’s not getting major new features.
I’m not a Campfire user, so can’t speak to the UX, but I feel like there is a market for actively maintained projects, that are considered feature completely, which aren’t searching for new features to shoehorn in. In the long-term, this need to constantly add features generally gets interpreted as enshitification by users. Avoiding falling victim to this relentless push for “more” can be seen as a feature in itself.
>For people looking for a simple chat that stays simple, is this a bad thing?
If the application does everything you want it to do, then no, it's fine. How much new development does grep get these days?
However, it was mentioned that it has no mobile apps, and that's a deal-breaker for probably most organizations and teams. If you can't access your team's communications channel when you're away from your desk, that probably isn't acceptable to many. And of course, developing and supporting mobile apps (on at least 2 platforms these days) is a large effort, and also requires constant maintenance since the two dominant platforms are continually evolving and changing their APIs.
No mobile app sounds like a feature in my book. Few things are so urgent that people should be expected to be reading and replying to chats while away from their desk.
My understanding is that Campfire hasn't been actively developed for ~10 years (https://once.com/campfire/changelog shows some minor fixes after the OSS launch; their GitHub has no 2026 commits). There are no mobile apps. It is not an actively maintained Discord alternative.
Stoat is early in development. For example, https://github.com/stoatchat/stoatchat has 1421 commits, compared with 68K for https://github.com/zulip/zulip/. I wish them luck! It's really important that we have multiple independent efforts.
https://www.rocket.chat/ and https://mattermost.com/ are open-core military contractors these days. You'll see what I mean if you visit their websites. But like Zulip, they are full-featured team chat systems, and if the parts of their system that are OSS work for your organization, they're certainly valid options.
Finally there is Matrix/Element. They have an inspiring vision and similar values to mine, and I'd recommend checking it out. Element/Matrix is built on an ambitious distributed consensus protocol with an E2EE option, which provides capabilities Zulip don't have but also adds complexity. Zulip is focused on just doing team chat really well, and does not support more than ~100K users in an instance. Hopefully will have a lot more resources now, thanks to Current Events. I wish the Element team the very best of luck!
----------------------------------------
Overall, Zulip's focus has always been on making a delightful chat experience, especially when you have multiple conversations happening at the same time. We aren't trying to build a clone, but instead the best possible experience for having lots of possibly complex conversations. So there will be some differences from what you're used to.
But critically, we spend a very large amount of our time relentlessly fixing micro-interactions that annoy us or are reported to us. If you read #design, #issues, and #feedback in https://zulip.com/development-community/, you'll get an idea of how we work.
So while there's some features we don't have that are present in other products, and we don't have dozens of designers on staff to do cool end-of-year animated reports like Discord does, you can expect few bugs and a lot of interaction design polish.
-----------------------------------------
The one mistake that I think a lot of folks make in evaluating options is focusing on buzzwords like E2EE without thinking through their threat model. E2EE doesn't add much practical security over self-hosting for many threat models, and it comes with significant usability trade-offs. And some current E2EE systems don't actually protect against a malicious server, say because they only protect message content, not metadata like who has access to what... just against raiding the server's disk.
(For example, WhatsApp has E2EE for message content, but I expect Meta's databases know everyone who's had a conversation with me on WhatsApp and the precise timestamps and approximate lengths of every message I've sent or received on the platform. And apparently some keyboard apps send what you're typing to remote servers!).