Hacker News new | ask | show | jobs
by temp 1462 days ago
They decided to up their price per user by a significant amount not too long ago... our self-hosted instance suddenly became more expensive than Slack but with an obviously not nearly as polished product as Slack. So we moved over to Zulip because at least they do their own thing, we haven't had any regrets over the switch to Zulip.
10 comments

Zulip is really underrated.

It's a chat app that doesn't eat your life, but just provides the service of helping you to communicate. It doesn't want to interrupt your workflow. It doesn't try to connect to everything. It makes it easy to organize work conversations and doesn't wish to be the remote work coffee machine.

It seems unreal that nowadays, I find solace in a software for finally trying to help me instead of extracting value or stealing attention from me. It should be the default.

Zulip is just that: the vlc of team chat.

My former company adopted Zulip because we were in the cybersecurity space and needed an on-prem solution. When I first saw it I thought "oh god this is going to be awful" - very ugly UI compared to Slack and others. But after getting used to it, I found that the UX is excellent.

For anyone searching around, don't be put off by the lack of "polish" - Zulip has a really good fundamental design.

When everyone on the team learn to use Topics, it's life changer.
And not only that, Zulip is 100% FOSS, wherea Mattermost is Open Core, so the Open Source portion is missing key features.
We tried Zulip about a year ago. There were loads of things we loved about it - the threading model in particular - but the learning curve was steep for non-technical members and the mobile app lacked a couple of key features (share sheet integration was the big one, from memory). We also looked at Quill, which had a similar threading model but … was bought and then sank without a trace. We ended up on Slack, which is a total car crash. Can’t find anything.

It was frustrating because Zulip felt like it was so close to being a great - and unique - product. Might be time to take another look and see if it’s there yet. It’s a really great community, friendly and very responsive on GH issues.

Head of Product for Zulip here. I'd love to dig in deeper to understand what's confusing to non-technical folks as they are starting out, so that we can keep working to improve the product and documentation to address it. If anyone is up for a chat, please reach out by email at support@zulip.com, or in the #feedback stream in the Zulip development community (https://zulip.com/development-community/)!
Hello there, thanks for the offer, very much appreciated and characteristic of the Zulip community as a whole.

I actually did open and/or add to issues on GH, and actively participated in the development Zulip instance on the issues that came up for us as a team. I found the community to be very receptive.

I just want to reiterate, for anyone coming across this thread now or later, that Zulip really is a fantastic product and open source project. The main uphill battle for us was getting non-technical people to buy in to a paradigm of effectively “filing” their messages up front. That’s not some kind of problem with, or criticism of, Zulip as a product. For messages to be in correct context, the sender needs to _put_ them there. To want to do that, it helps if they buy in to the paradigm in the first place.

“Why do I have to do this?”

“Because it makes it possible for anyone to come along later and get the whole picture.”

“Okay, that’s worth a bit of friction up-front.”

It’s really a people thing - not a Zulip thing.

Just 2c from our little team.

Best of luck and thanks for all your great work. We’ll definitely be checking it out again soon.

Thank you for elaborating and for the kind words!
My view is that there is a UI issue here, but I can't come up with a suggestion of how to improve it.

People get their head around MS Teams very easily and fundamentally the only difference between Zulip and Teams is that you are required to put a title/subject on your thread in Zulip as supposed to Teams where it's optional.

In Teams the value of this is clear whereas in Zulip you need to understand the goal. I've always thought that with a bit of a step back UI adjustment to Zulip things could be clearer.

What made the learning curve higher for non-technical members on Zulip than it was on Slack? It’s been a few years since I used Zulip, but I don’t feel like it had a particularly different level of complexity.
I think the fact that you must give a thread topic to send a message.

It's not particularly difficult concept, but different from every other chat app. And for a large user base being confronted with this demand "when they just want to send a message" is frustrating.

Yeah that’s consistent with what we found. The threading model is so powerful, because even large teams that are mainly async can actually find stuff they need, _in context_. That’s really difficult or impossible in something like Slack, Discord, etc, and the value of that can’t really be overstated.

On the other hand, you’re asking people to buy into what is essentially a completely different paradigm than what they’re used to. Maybe it’s more like a loosely-structured wiki than a chat app.

I really like it, though. I feel like it deserves a lot more attention than it seems to get.

Zoho Cliq solves this by using ML to parse the message and give a suitable name. It's suitable 7/10 times, and the remaining 3 - it either doesn't matter that much or is trivial to rename.

Zulip should try that if they haven't already.

I hadn’t heard of Cliq. Do you have lots of experience with it? What do you think of it?
Disclaimer: I work for Zoho, but in a different team.

I find that I really like it for work. But for informal interactions (gaming etc) I like Discord better because of the voice channels. In Cliq they're "calls" and feel much more formal.

> And for a large user base being confronted with this demand "when they just want to send a message" is frustrating.

Isn't it a conceptual framework thing, though?

People have no problem putting a topic when sending emails, and they are perfectly capable of following grouped conversations, as for example in Outlook.

Maybe it would be enough to present it as "a mail application where you can also do chat on a reply thread", to create the right expectations?

You self host their enterprise solution? I think you're missing the point, migrate to the community edition. We pay 0 (but contribute with donations).
I don't think we are missing the point, we were looking for a Slack alternative and found one. They charged a bit to give you push notifications, now they charge more of it. If not having push notifications were an option for us, we'd have simply downgraded.
We've been using the free (Team plan) self hosted edition with push notification for free. Am I missing something?

https://docs.mattermost.com/deploy/mobile-hpns.html

you can also just host your own push proxy service using their open source code...

https://docs.mattermost.com/deploy/mobile-hpns.html#host-you...

Then you also need to build and distribute Android and iOS apps for your employees. Congrats, you now have a significantly larger project than "put Mattermost on a server and update it occasionally".
I am using it on both cloud-hosted (work) and self-hosted (friends chat) servers.

Push notifications work fine, the mattermost app that's already on the android and iOS stores work fine, they have done for the 3-4 years I've been using it.

Self hosting Mattermost community edition with the Mattermost apps in Google play and apple app store works fine.
> self-hosted instance suddenly became more expensive than Slack

??? How were you getting priced per user on a self-hosted instance?

[EDIT] Ah, you had their enterprise edition on-prem.

We tried Zulip a couple times and ended up setting up a Matrix server when Slack became unbearable. The advantages of being able to federate with other channels is high, like almost everyone I have severe channel overload and I want an application which will be open all the time to reach as many people as possible.

It's almost coincidence, though, both Zulip and Matrix became 'good enough' around the same time, and we actually tried to move to Zulip at one point, which I think hardened opinions. I do like the semi-threaded approach Zulip takes, just not as much as I like even the possibility of a future where I can use Matrix for as much as possible.

> I do like the semi-threaded approach Zulip takes

Interestingly I think of Zulip as the fully threaded approach, and Slack/Discord etc. as the semi-threaded approach (because it's optional). The only other "fully" threaded approach I know of is MS Teams (in the Team) - each conversation is a thread (and the fact that people don't realise this is an indication of how good the UX is).

I don't have a better link/reference, but the following shows that threading is a desired feature within the Matrix network and ecosystem: https://matrix.org/blog/posts#a-thread-for-next-time

So, who knows, maybe you'll get the best of both worlds eventually. :-)

https://element.io/blog/introducing-threads-in-beta (not as good as zulip’s threads yet tho)
Ah-ha! I knew that i was not crazy! And, the link is from a pretty reliable source! ;-) Thanks @Arathorn!
and Zulip has a "public access" view, which I wish more open source projects would adopt (:eyes: kubernetes.slack.com) since it allows search engines to index into the threads: https://zulip.com/help/public-access-option
To clarify here, from https://zulip.com/help/public-access-option#caveats:

> Web-public streams do not yet support search engine indexing. You can use zulip-archive to create an archive of a Zulip organization that can be indexed by search engines.

https://github.com/zulip/zulip/issues/21881 is the issue to track for the native search indexing feature.

Ah, thank you for pointing that out and sorry that I didn't notice that caveat. I somehow thought Google's indexer was "hash url" aware but I can totally appreciate that the devil is in the details about that stuff
We're on a freemium plan for slack. Works fine and doesn't cost us a thing. We don't care about having an archive of chats. That's not what it is for.

Self hosted would cost us more in devops money than we'd end up paying even for a premium SAAS contract for whatever you would use for this. People think devops is free, it rarely is and usually is the most expensive thing in terms of cost. Especially doing it properly can eat into development time quickly. Which unless you are bored and have nothing better to do is even more costly. Somebody costing 1000/day spending even half a day on this adds up quickly. And it's never just half a day. The point of hosted SAAS software is getting people like that out of the equation.

You can pretty much run a small startup on freemium accounts for a lot of things. Our biggest IT cost is google docs and google cloud for our actual infrastructure. These days we are also paying for a few additional things (Asana, Figma) but we started out with freemium accounts for that as well.

> Self hosted would cost us more in devops money than we'd end up paying even for a premium SAAS contract for whatever you would use for this. People think devops is free, it rarely is and usually is the most expensive thing in terms of cost. Especially doing it properly can eat into development time quickly.

Perhaps you have no idea how to manage servers but launching an instance and a docker container isn't magic which requires a single weekend of learning and it costs that one time operation and $10/mo for the server. (What the hell is a premium SaaS contract? Are you being oversold by some salesperson?)

Certainly not knowing how things work is rather expensive thinking it is expensive.

I'm an engineer and CTO and well aware of how a "why don't you just ..." can escalate into a significant side project. The thing is I know how these things work and I've seen them escalate repeatedly. We used to run things like jenkins and gitlab self hosted. And we had to deal with outages, backups, things running out of disk, etc. It was doable but definitely a bit of a time-sink.

If you don't care about devops, monitoring, uptime, and all the rest, then yes, you can run the entire company off a few beautiful snowflakes on some VM. If it goes down, you just do it again. Been there done that. But doing it properly requires a bit more effort. I shut down my last self hosted Jenkins about five years ago. Not doing that again. Just not needed anymore.

Anyway, for things like slack (which, again, we run for free), I don't see the value of self hosted.

We just launched a free forever SaaS offering that is competitive to Slack and includes kanban boards for project and task management and a few other bells and whistles for software developers. You should give us another look!
A link would help for that ...
It's called the Starter plan and here's the feature comparison matrix: https://mattermost.com/pricing/#compare-features. :)
We've been using Zulip at our startup for 2.5 years now and still generally love it.

We self host and haven't had any issues with that (pretty much zero maintenance so far). The Android app is awesome.

Searching messages sucks, and I don't know if Slack bots and apps are compatible.

Pretty much everything else is great, and we greatly prefer it to Slack and Mattermost (both of which we used before for years).

I thought Self-Hosted was free to you? What does self-hosted even mean otherwise
Self-hosted is entirely orthogonal to price. Microsoft Exchange and Oracle 21c are both self-hosted, for instance.
For further elaboration, self-hosted just means that you get a license to install the code on a server you control - whether that license is FL/OSS, something proprietary, or some middle ground (open core etc).
If you want SAML support you need to pay (or hack out the licence checks from the open source edition, but they're sprinkled everywhere)