When I founded Zulip, one of my stated goals was to change how the world communicates to be more efficient, just as my goal in founding Ksplice was to make rebootless updates ubiquitous.
So if Slack and all of its clones copy Zulip's model, I'd call that a success for us having changed the way people work. That said, Zulip is 100% open source under the Apache license (very rare these days), and that will remain a differentiator, as you can't self-host Slack, nor can you audit its source code or fork it to solve a problem specific to your use case. (We also have a lot of other innovative features, like native LaTeX support, customizable linkifers, etc.).
That said, topics are not something one can just copy in an existing chat app -- there's a lot more to Zulip's topic-based threading model than "a feature".
* Being able improve organization by renaming and splitting topics, move topics between streams, etc., is critical to the reading and conversation experience. This requires lot of thought about subtle technical and user experience details. (E.g. if someone renames a topic, and you were in the process of composing a reply, your compose box updates to the the new topic).
* Tracking unread counts on a per-message basis, rather than a "pointer within a channel", which is required for splitting topics to do something sane. This, in turn, requires clever data structures so that the moment the browser loads, you can see where all 35000 unread messages are. (Folks routinely have that when they come back to a busy open community after months away).
* All sort of clever performance and client-side caching things to make it feel like the browser has all your data so that clicking around feels instant.
* Dozens more things along these lines.
And those are just the engineering details. The bigger part of topics that it requires an overhaul of the whole UI. At least for us, a huge fraction of features are different than they would otherwise be because of topics (E.g. Zulip's compose box supporting sending to a different place than what you're looking at, and fading messages that weren't sent to that place to help users avoid mistakes). This sort of overhaul is hard to do, and even harder to do with a large existing userbase.
As a result, if Zulip fails, I'd be very surprised if it's because other companies copied Zulip's model so well that there was no reason to prefer Zulip's topics implementation.
Far more likely is some combination of our competition having infinite marketing dollars, inertia in organizations that don't realize how much better their working experience could be, and Microsoft's campaign to make everyone unwilling use anything other than Teams, because "we already bought Teams with our Office 365 subscription".
I work at a tech company of about 500. We've used zulip for a few years now and are looking to switch to teams/o365. The reason is to have more integration between email, documents, chat, video meetings, and calendar. Zulip has been good to us but as we grow it's increasingly burdensome to manage a bunch of disparate open source collaboration tools.
So if Slack and all of its clones copy Zulip's model, I'd call that a success for us having changed the way people work. That said, Zulip is 100% open source under the Apache license (very rare these days), and that will remain a differentiator, as you can't self-host Slack, nor can you audit its source code or fork it to solve a problem specific to your use case. (We also have a lot of other innovative features, like native LaTeX support, customizable linkifers, etc.).
That said, topics are not something one can just copy in an existing chat app -- there's a lot more to Zulip's topic-based threading model than "a feature".
* Being able improve organization by renaming and splitting topics, move topics between streams, etc., is critical to the reading and conversation experience. This requires lot of thought about subtle technical and user experience details. (E.g. if someone renames a topic, and you were in the process of composing a reply, your compose box updates to the the new topic).
* Tracking unread counts on a per-message basis, rather than a "pointer within a channel", which is required for splitting topics to do something sane. This, in turn, requires clever data structures so that the moment the browser loads, you can see where all 35000 unread messages are. (Folks routinely have that when they come back to a busy open community after months away).
* All sort of clever performance and client-side caching things to make it feel like the browser has all your data so that clicking around feels instant.
* Dozens more things along these lines.
And those are just the engineering details. The bigger part of topics that it requires an overhaul of the whole UI. At least for us, a huge fraction of features are different than they would otherwise be because of topics (E.g. Zulip's compose box supporting sending to a different place than what you're looking at, and fading messages that weren't sent to that place to help users avoid mistakes). This sort of overhaul is hard to do, and even harder to do with a large existing userbase.
As a result, if Zulip fails, I'd be very surprised if it's because other companies copied Zulip's model so well that there was no reason to prefer Zulip's topics implementation.
Far more likely is some combination of our competition having infinite marketing dollars, inertia in organizations that don't realize how much better their working experience could be, and Microsoft's campaign to make everyone unwilling use anything other than Teams, because "we already bought Teams with our Office 365 subscription".