How does Zulip compare to Campfire and Stoat (and other FOSS) efforts? How is onboarding for non-tech people?

Onboarding has a thread going here: https://news.ycombinator.com/item?id=46951401.

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!).

	▲	al_borland 4 hours ago \| parent \| next [-]
		> 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.
	▲	Lerc 4 hours ago \| parent \| prev [-]
		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.