Named threads is a cool idea, but if it makes a big difference I expect we will see it in Slack soon enough... If you build a challenger SaaS based on minor feature tweaks, you risk just doing product research for the better staffed incumbent.
Zulip is older than Slack, and it's been owned by Dropbox for years, so it's not accurate to think of them as a startup challenging Slack.
I wouldn't call it a "minor feature tweak" either...it's pretty easy to implement, but it's a design choice that Slack has decided against.
> it's been owned by Dropbox for years
I want to correct this here, precisely because we haven't yet done a good job of making it clear on the web: this statement is actually a couple of years out of date.
Dropbox was very graciously helpful for the Zulip project in 2015-2016 (after acquiring the original startup in 2014). Major things include open-sourcing the code, obviously -- but then also helping those early users who'd been that startup's private beta users, who'd determinedly hung on to it for that couple of years despite the minimal support and uncertain future, migrate their data seamlessly to the hosting company set up by tabbott, one of the original startup's founders. (See https://news.ycombinator.com/item?id=17623701 today for one such user's telling.)
Digression: That is a far nicer experience than what usually happens when a startup you like using is acquired by a company that has no interest in the product! I think they deserve a lot of credit for deciding to do that.
And then since 2016, Dropbox hasn't been involved. I actually used to work there myself -- I left in order to start working on Zulip. The core team is employed by that new company (Kandra Labs): https://zulipchat.com/team/
PS: > it's pretty easy to implement
I think making a threading experience like Zulip's really work well is harder than you think. ;-) The original startup's team was stacked with engineers with systems-heavy backgrounds -- most of them colleagues of mine from Ksplice (rebootless kernel updates) and/or MIT -- and they put quite a bit of careful engineering into the architecture.
But as you say, it's also a design choice, and moving from Slack's current UX to a fully threaded one would be a radical product pivot (lots and lots of details are shaped by that choice) that it's hard to see them making.
This is the first I've heard of it, guess there's a lot of outdated information floating around.
> I think making a threading experience like Zulip's really work well is harder than you think.
Well this is HN, where you can build Dropbox yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.
My main issue is that HN loves to compare products based on UI features that stand out to front line users, especially dev, and underestimate other aspects (admin features, sales strategy, community development) that drive value for users and success for products. Without attention to these things, you can do good design and difficult engineering without the impact you're looking for.