The author did a really good job of articulating why I've spent the last several years working on Zulip despite there being a thousand Slack clones to choose fr

The author did a really good job of articulating why I've spent the last several years working on Zulip despite there being a thousand Slack clones to choose from. Asynchronous communication is essential to being able to focus, at least if you do enough communication that it matters how you communicate. And it's very inefficient to do asynchronous communication at scale in Slack or any of its copycats. This leads to the Slack cultural issues detailed in the post; they're the result of people working around the bad core workflow of a beautiful, masterfully marketed tool. Consider "Everybody expects an immediate response" culture. In my view, that is people adapting to it being unpleasant to be a busy person waiting for a reply in a Slack channel. (Which is because it's miserable to make sure you don't miss things in busy slack channel, so everyone does, so anyone who wants to be sure of a response spams PMs and mentions and otherwise applies pressure to get a reply now now now so that they can mentally move on to their next task). Zulip aims to make asynchronous communication so efficient that such adaptations are unnecessary. The core innovation is that all messages in channels are organized within "topics", which work exactly like the Subject field in email. This model works great for enabling asynchronous communication in email, and it works even better in Zulip (mainly because of topic editing and linking features). The main goal of Zulip's interaction design is to make skimming hundreds or thousands of Zulip messages (and replying thoughtfully to the ones where you can add something!) pleasant. This enables a better way of working. Personally, I read and respond to 500-1000 Zulip messages sent by dozens of people across 50+ topics every single day, and I get compliments on how responsive I am, despite the fact that I do focus work in multi-hour blocks most days, Zulip's development community is all over the world, and I lose hours of productive time every day due to a chronic illness. This wouldn't be possible with Slack. And this isn't just my experience; I've heard from so many people in organizations that switched to Zulip that they love how Zulip makes better use of the limited time they have (whether busy managers at companies or participants in part-time communities). > "You'll lose your history" This is the other major bundle of problems that Zulip's topics solve. Zulip can be a valuable knowledge store because of the organization provided by topics (combined with features like permanent links and topic-powered search workflows). Zulip is 100% open source software (Not open core! We're intentionally not VC-backed so that we can prioritize our values; see https://news.ycombinator.com/item?id=23102430 https://news.ycombinator.com/item?id=23102430). And we sponsor free hosting on zulip.com for open source projects, academic research, and other non-commercial organizations.