Zulip

Slack 和一般群聊有个共同的结构问题：所有话题挤在一条时间线上。 你早上开会两小时回来，频道里 200 条消息交错着三四个不同的讨论， 想找出和自己有关的那部分，只能一条条往上翻。 时区不同的团队尤其痛苦。

Zulip 的解法是加一层：频道（channel）下面还有话题（topic）。 发消息时必须选一个话题（或新建一个），于是同一个频道里 "发布计划""线上故障""周会安排"是三条独立的线索。 回来之后你可以只看"线上故障"这一条，从头读到尾， 像读一封邮件线程一样连贯。

25,708 颗星，Apache-2.0，Python 后端。

这套结构带来的实际差别：

• 异步协作真的可行。不在线的时候错过的内容按话题归类， 补起来是"读三个话题"而不是"翻 200 条消息"。 远程和跨时区团队对这一点感受最深。
• 讨论不会被打断。有人在聊 A 的时候你可以开一个话题聊 B， 两条线互不干扰，不用说"先等一下我插一句"。
• 搜索和回溯准确。按话题搜比按关键词在时间线里捞有效得多。
• 支持 Markdown、代码块（带语法高亮）、LaTeX 公式、 消息编辑、表情回应、串外引用，以及和 GitHub、Jira 等的集成。

关于免费要说清楚：

软件是 Apache-2.0 开源的，自己部署完全免费、功能不设限、人数不限。 官方另有一个云托管服务，有免费档但对消息历史等有限制， 正式团队用是付费的。我们标为「有免费版」指的是云服务这条线—— 自建那条路是完全免费的，这是我们推荐的用法。 另外官方对开源项目、教育和非营利组织的云服务通常有免费或优惠政策。

要说清楚的：

• 需要适应期。"每条消息都要选话题"这个习惯， 从 Slack 迁移过来的人前两周会觉得麻烦， 但这正是它价值的来源。团队要统一约定怎么起话题名，否则会乱。
• 自建有运维成本。它是相对重的应用（Python + PostgreSQL + Redis 等）， 官方提供安装脚本和 Docker 方案，但比跑一个静态站复杂。
• 小团队可能用不上。三五个人的团队，消息量不大， 话题分流的收益不明显，用 Element 或直接一个群更简单。 它的价值随团队规模和消息量增长。

适合谁：远程或跨时区团队、开源项目社区、 消息量大到 Slack 已经开始失控的组织。