Why Zulip will stand the test of time | Hacker News Reader

Why Zulip will stand the test of time

blog.zulip.com

166 pointswilliamstein80 comments

Love Zulip! Simple architecture, amazing packaging release/upgrade process and very developer friendly at all levels! I actually pulled away from Facebook, invited everyone to a Zulip server, hacked on it to provide changes people wanted, and we're loving it. Login-with-Google was trivial to setup. Some users prefer to email the server and the gateway was so easy to setup. Search Just Worked(tm). It's fast. It's easy to admin. and and and...

I have only one complaint... but it's a biggie: the UI/UX.

I don't normally care, but literally every one of my users has commented that it's an ugly duckling - both the mobile app and website. We'd gladly pay for something prettier:

- UI is inconsistent: layouts/fonts/icons vary by screen and surface

- UX buries common features (e.g. reply, reaction) and promotes uncommon features (e.g. invite new user). UX is rough, e.g. click-targets are tiny and not always obvious, and features are hidden behind mouseover.

- promotes the name "Zulip" all over, which is a problem for users who don't know what a Zulip is or why they'd want one, e.g. emails from "Zulip" and not the name of the community.

- needs a way to "nudge" conversations into a smaller set of topics/threads, e.g. suggestions.

- conversation UI still suffers from scaling issues and needs some reddit-like way to display larger conversations...

- no way to control which previews are shown/hidden

Seriously, pls hire a no-nonsense designer and stop trying to be clever! UI/UX is too important in this category of product, and the current design holds back adoption.

Head of Product for Zulip here. We appreciate the feedback! We are actively recruiting for a designer role (https://zulip.com/jobs/#designer), and making these types of improvements will be a major priority in the coming year.

I agree with the OP, but I have to say that your keyboard navigation is second to none. Also, please keep Zulip fast, it's the biggest reason why it's so great to use.

+1 to this!

I saw that! in the commit stream during today's upgrade. I'll riffle my network - design is always tough, and designing for Zulip is esp tricky given its extensibility.

Very much agree: Zulip is fantastic, except for the UI (mostly the look & feel) which makes difficult to convince non-tech users to adopt Zulip instead of Slack.

I as a coder love zulip[1]. I don't really understand why non-coders have problems, but obviously they have them. I fear when they get a "professional" UI designer things might not improve from my perspective, very much the opposite.

[1] With one exception. The search is too fuzzy. We have 3 years of technical disscussions in zulip. Finding code snippets you exist is often impossible. A real grep interface would be great. Optional of course for thos who know regexps. Yeah, I can harvest my own copy of the chat history using the REST API and grep there. My code to do so has fallen into disuse...

I got off it, even though it's second to none in it's niche.

It turns out I just don't have the time/patience for online software. It didn't do a good job offline, they have no native client for OSX, I just don't have the learned tolerance for all this. Even though it's good.

Still sucks to use, if you use it a lot.

My main problem with Zulip is that it seems like a bunch of vi/emac users got together and developed a GUI chat app. It’s impossible to use for new uswrs. But once you become a power user and learn all the keyboard shortcuts it’s great.

Maybe a better title would be "Why your Zulip data will stand the test of time". I think that's really the point he's making: the company will be fine, but even if something bad does happen, you won't be left hanging.

With respect to Zulip the company, I think they have a great product, but they need to market themselves as being something differen from chat/Slack. Zulip is built from the ground up to support a very different workflow. I guess most people try Zulip because they're looking for a Slack competitor and they get the wrong product. If I were Richard Stallman, I would suggest ZINC (Zulip is not chat) as an alias, and everyone would adopt it because Slack is not a recursive acronym.[0]

[0] YMMV

Although this bug report [0] states the difficulties facing them, zulip doesn't do e2e, which is a deal breaker for many communities. So, a title as you suggest should be "Why your Zulip data will stand the test of time, provided no one steals it".

Aren't we a long way down the road of understanding that all server systems should be regarded as an "untrust" environment? I feel this way about my own self hosted systems. If your critical data leaks, you're hosed.

If corporate needs to have audit trails then there needs to be a system that deliberately breaks e2e, something that all clients posting on that system know about and display messages about, rather than the current implementation.

About server side search... that's a different issue, but couldn't it be done with hashing keywords on the client and a disclaimer on how this may reduce security?

So, all in all, I get why e2e is hard for zulip, but standing the test of time without it could be difficult.

[0] https://github.com/zulip/zulip/issues/6096

I don't think Slack offers e2e. If they do, it's a recent development.

I don't see any value for e2e on a team chat. With e2e you lose not only server-side search but also message archives for new users (and new clients for old users too, if you use something with forward secrecy).

In exchange, it makes hacking the server prevent leakage. Meanwhile if even a single client gets hacked, all of your group-chats are still compromised.

A big part of the value of something like Zulip versus e-mail is you can link to historical threads, and know that everyone can read them. E2E is purposefully hostile towards "everyone reading them" so it's a major tradeoff.

Do you want E2E on your bugtracker? CI logs? Doing so for Zulip makes about as much sense IMO.

Note that if GH used E2E for issues (which is arguably a form of group chat), the link you posted to the discussion would not be readable by me.

There are other teams than corporate IT teams. There are other non technical groups that would greatly benefit from e2e groups like Signal has, that would love the added luxury of self hosting/non centralised hosting. I can easily envisage different groups wanting these things.

Some do not want the 'historical' chats to be kept, & server side search is not really relevant in those cases. Of course, some will.

If we think of more than tech teams, it's easy to see these features as being vitally important. So while bugtracking, CI, bots, etc, etc is important for you and I, there are groups and communities where such things would be met with bafflement as to their purpose.

We are on HN so I used bug tracking and CI as examples of things people want a history of. NNTP is another example that was not limited to technical topics.

If you really need e2e chats, then xmpp and matrix can self host. I do think this is niche though. Every client logs history, so compromising one client completely defeats e2e.

Zulip is the only thing I've seen recently that does better group conversations around particular topics better than NNTP and e-mail did 30 years ago. I've only used it for a few things since there are network effects around any communications technology but unlike slack or discord, I'm actually pleased when it's the communication medium of choice for a project.

Slack’s threads suck compared to Zulip’s. In Slack, threads only notify thread participants unless you choose to send it to the channel too, which defeats the purpose of threads by interrupting other conversations. In Zulip, everything in the channel/stream must be a thread, kinda like email.

Zulip does most things better than Slack. I can't stand Slack, it's slow, bloated, and the UX is bad. Zulip's UX is a breath of fresh air. It's just so quick to catch up on old messages, mute irrelevant threads, see everything in chronological order, zoom in or out... I just love it.

I've been using Zulip daily for over a month now and I love it! As do my colleagues who are now very happy users.

Looking forward to whenever Zulip implements /digress. That's something I realized was missing right from the start - how to "branch out" from a topic into a new one, creating some sort of sign/breadcrumb indicating that the message got a reply in a new topic.

Currently you can quote reply and change the topic for the new message, but there's no indication in the original topic that there was a digression, so discovery is a bit clunky.

Original issue: https://github.com/zulip/zulip/issues/14522

Some work done and demos: https://github.com/zulip/zulip/pull/16589

Discussion: https://chat.zulip.org/#narrow/stream/101-design/topic/.2Fdi...

I have no idea how Slack threads are intended to be used. Their own examples are very trivial and the implementation feels like like a first pass that they never did any usability testing with.

Slack threads seem designed to ensure you can't follow a conversation without branching off into numerous sidetracks, which are hard to find when you're directly addressed.

At my last company we had an open rebellion against using Zulip for at least two years, before the product team budgeted for slack enterprise and the engineering team switched to that for DMs, although formal communication still happened through zulip to appease our VP.

The mac client was never fast, search was neigh impossible to use across 7 years of messages and there were frequent issues with client stability and drop outs. More than once I've seen someone "mark all messages as read" and cause the service to crash. "Is zulip down?" was a sort of running joke among the engineers.

I wouldn't turn down a job solely based upon their reliance on a tool like Zulip, but it would definitely be a factor in my decision.

I used it for chat and automated notifications related to a git workflow, both the repos and chat were self-hosted. It was far less polished than Slack (and Slack was not that polished back then). But fine for that purpose. In less tech centric environments the rough edges are more bothersome.

> I wouldn't turn down a job solely based upon their reliance on a tool like Zulip, but it would definitely be a factor in my decision.

This resonated with me, at my current company hundreds (maybe thousands, I don't know) of employees' daily chat goes through a self hosted RocketChat instance.

For all I know, based on the performance, that server is running on the cheapest Raspberry Pi.

Everyone on the team just kind of accepted that sometimes, you can't connect for minutes (sometimes hours), the search is slow and not very powerful, the features and integrations are lacking.

It's so frustrating when you want to contact someone, you can't, because it won't load, if you want to add an integration (that you are used to from your last company and would make things much easier for everyone), you can't, because there are no good integrations for RocketChat.

In my opinion, terrible internal chat and penny pinching is a good sign of a dysfunctional organization.

Ten dollars per employee per month sounds expensive, until you realize that your employees wait an hour a week for the self hosted tool to load and are now blocked because of that.

You can pay for hosted Zulip, so if “paying for it” is a distinguishing factor that’s not a point against it.

I’ve also seen orgs that used on-prem solutions for compliance reasons and had an actual working service - it’s just not significantly cheaper when done right.

> I wouldn't turn down a job solely based upon their reliance on a tool like Zulip, but it would definitely be a factor in my decision.

I feel the same way about slack, so it's funny that we have different experiences. Granted I don't use Macs, so I can't have had a bad experience with the Zulip mac client.

I have barely used it but that's not for trying. I have no idea why (possibly my subtype of dyslexia?), but I have severe problems parsing the layout of the Zulip message history/chat. It's a pretty bizarre sensation that I've experienced nowhere else.

> The mac client was never fast, search was neigh impossible to use across 7 years of messages and there were frequent issues with client stability and drop outs.

I'm mentally comparing this with Slack, where no client is fast, search is nigh impossible to use across 7 days of messages and there are constant issues with usability.

Seriously, why can I out-type my chat client? It's twenty fucking twenty-one, we had faster IM clients in the nineties.

Hooray for Zulip! It is a ready great example of the amazing things that can be accomplished by an open source community (and founder's like Tim Abbott who understand how to prioritize that community and its users). Thank you for your work!

Zulip is implementing the same bad architecture as google/ms/apple/fb's messengers (custom protocol, no federation), but at least it does it well (open source, usable, do-one-thing-well, no dark patterns, powerful and stable API).

How is it "bad" if it's the standard used by the most successful messenger platforms

Because there isn't a standard. The point is each one implements their own protocol instead of adapting a standard such as Matrix or XMPP. (Whether any suitable standard exists (much less existed in 2012!) is another issue, but regardless it's fair to say that the current state of things is not ideal.)

I don't think "whether any suitable standard exists" is another issue, it's the exact one. If you're building a product and there is no standard to cover core technology, you roll your own because it's faster than waiting for someone else to invent one.

But that said I don't think "using a standard protocol" is a value in and of itself.

> But that said I don't think "using a standard protocol" is a value in and of itself.

Standard protocols are very valuable if you care about reach while avoiding vendor-lock-in. I want to be able to self-host my server (or pay someone to host it for me), but I also want to be able to communicate with people on other servers. It is that balance of control and networking that is really powerful. Someone else mentioned here about how FHIR uses Zulip as the group chat for their community. That is great! But, to participate, you need an account on their instance and then if you want to participate in multiple Zulip instances you either need multiple clients or some kind of multi-instance support in your client. And then you still have to manage separate profiles for each instance, etc, etc...

OTOH, a bunch of open source projects use Matrix instances for their community chat rooms. One of the huge benefits I see from that is that I can use my single Matrix account (on the server that I host) to join all the different communities that I am interested in. (And now with the new Spaces feature in Element, there is even better controls over being able to still retain a separation of concerns between all the different conversations I am a part of...)

> If you're building a product and there is no standard to cover core technology

That's what the X in XMPP is for.

It is certainly bad in terms of longevity. Google Wave was temporary; email is forever. Of course, the downside of federation is complexity.

Matrix.org is a great choice for an open federated messaging protocol, but the challenges of operating in that kind of ecosystem have certainly stunted their ability to add features and polish when compared to a closed system such as Zulip.

Is "custom protocol" really that bad if the existing ones were insufficient?

Is this question just opening myself up to a cacophony of "what was wrong with IRC / XMPP?"

XMPP supports extensions.

Generally speaking, use the standard until you can't. Then just extend it and write up a proposal for your extension to make it into the next version of the official protocol.

It is. So what was insufficient about XMPP?

They told that they are working om Matrix integration. I have no idea whether that work is still on track or already abandoned.

The client is a piece of shit tho.

Posted to the wrong channel/topic more than once now..

A native mac app would be a game changer. Would pay for it.

Zulip is used for the FHIR community (chat.fhir.org) and it manages to deliver a much more "email thread"/async communication stream. It's almost closer to a Hacker News than one of the dozens/hundreds of forgettable Slack/Discords for other communities.

Switched to Zulip from Slack and then Teams and LOVE it.

We did a ton of research into what team messenger we could use and, frankly, I have no idea what could be a better alternative to Zulip.

Discord forces to use one account everywhere, Slack sucks for search and threads and causes too much noise and clutter, Teams , well we are still recovering from the emotional and productivity damaged it caused. What else is there?

Twist

> Twist

Hmm, I assume you are talking about https://twist.com/

This is the first time looking at that service and I find it equally intriguing and confusing. It seems like a cross between Slack and Notion (ideally capturing the best of both worlds). But I would love to hear from someone who has actually used it regarding its benefits vs other chat systems...

How many employees? What is the company doing? Is it mainly tech? Asking because people in my group were a bit disappointed by Zulip UI.

10, all tech plus designers.

The UI is minimal but it also doesn’t get in the way and the topics really help keep things in check

In a context similar to yours, I'd definitely use Zulip.

UI is not "pretty" but the UX is great once you get used to the new model of messaging.

I've looked at Zulip for a local group and there a couple big problems that prevented me from considering it as a Slack replacement:

1. The UI is unattractive and over-crowded. Introducing non-techies to it would require saying at least "it looks bad at first, but you'll learn to like it."

2. It's complicated to deploy. Not just a simple docker container or anything.

> complicated to deploy. Not just a simple docker container or anything.

Huh? https://github.com/zulip/docker-zulip

> Project status: Alpha. While this project works and is used by many sites in production, configuring is substantially more error-prone than the normal Zulip installer (which Just Works).

There is a docker container but as Zulip themselves say, it is not simple to deploy.

Yes, and when you update docker container 4.8-0 to 4.8-1, it crashes on startup complaining about missing columns.

As the sibling commenter said, it is alpha.

2. also literally one click here https://marketplace.digitalocean.com/apps/zulip

Initial launch is easy, but try to update from one release to another. You will have to, when the security releases will be out.

Solving issues like why it doesn't connect to it's own redis instance anymore, when only its own script touch the config. Not very funny times.

The UI is functional and easy to learn. Everyone in my company is using it, which vastly exceeds the uptake for our previous systems - IRC and XMPP.

It was about 30 min to deploy to AWS including the documentation

It's not too bad to deploy, I have an install up and wrote a guide here: https://socialism.tools/zero-to-zulip/ compared to alternatives like Mattermost or Rocket Chat it's quite easy.

Love Zulip. Structured conversations are possible, which is what i want for a business setting. Topics are a great implementation.

Code syntax highlighting and code playgrounds are nifty

Exactltly, they are technically possible.

However, you always have the non-technical people who create complete nonsense topics instead of using a matching existing one. And also some disorganized engineers who continue off-topic discussions for dozens of messages.

Switching to a suitable topic when the discussion gets carried away could probably get more user-friendly support. You can edit the topic of existing messages, but there is no completion for existing topics and there is no clear indication of what got moved from where by whom and no simple undo if things go wrong.

At start I was a bit afraid of Zulip but after a while I get used to it. It works pretty good and fast. I hope someday it would be possible to easily extract topics or messages into some knowledge base

probably pretty easy using the API. https://zulip.com/api/

And on the pedestal these words appear: 'My name is Ozymandias, king of kings: Look on my works, ye Mighty, and despair!' Nothing beside remains. Round the decay Of that colossal wreck, boundless and bare The lone and level sands stretch far away.

Though under the earth and throneless now I be Yet, while I lived, all the earth was under me.

If you cross any bridges watchout for Liam Neeson.

I heard Richard Attenborough's voice in my head as I read this[1].

[1] https://www.youtube.com/watch?v=gX0oubhFydc

I heard it in Leonard Nemoy's voice, discovering the Contstruction technology in Civilization 4.

> "Will this product still exist and be responsibly maintained in a few years?" / This question is harder to answer than it might seem. A publicly-traded company may be unlikely to go out of business, but large companies (e.g., Google, Microsoft, Atlassian) routinely abandon products. A startup that has raised a flashy round of VC funding may soon (like Quill) be acquired with the intent to shut down its product, or go out of business altogether. The safest products on this front are likely large open-source projects with a broad community, like Python, Linux, or PostgreSQL.

Enterprise software companies also generally provide long-term support and backward compatibility. Look at Microsoft and Windows. OS/2 by IBM, first released 1987, flopped in the marketplace. IBM supported it for ~20 years, then licensed others to support it.

People often reject the added expense of enterprise software, but you get what you pay for.

> Enterprise software companies also generally provide long-term support and backward compatibility

Honest question for anyone familiar with enterprise SAAS contracts: does the same apply?

I mean sure, I have seem MS/Oracle provide crazy-long support for some of their software offerings, but if MS decided one day to pivot away from Teams, is there any clauses in the 365 contracts that prevent them from just shutting down the servers?

> is there any clauses in the 365 contracts that prevent them from just shutting down the servers?

The clause is in their reputation: If they did that, they would lose a lot of corporate business for all their products.

> SAAS

However, could they raise prices substantially ...?

So he sold the original company/product, then got it released as open source, and built another company based on it? Nice...

I'm surprised more SaaS offerings don't have clauses setting out generous migration times in the event of acquisition or bankruptcy and funds set aside to keep the service up during this time. I'd also like to see terms that limit data use so that these companies can't just be bought for their data.

Where is Matrix support for zulip-style threads? It's been a while.

My understanding is that it exists already in the spec (and I think Synapse might even support it??). It is just that no clients have implemented it yet...

IIRC, the Element team has been working on it, but they seem very hesitant to release anything around threads that is half-baked. They really want to get them right the first time!

One critical element in the article that is brushed aside too fast is that the founders did cash out by selling it to Dropbox first. It is easy to say: "build an open source, slow growing business it is way better" when you have a fat bank account...

The reality for most people is that even if you want to build a sustainable business founders also need to pay their bills and the VC route right now fills that need. Is it ideal? No. But until we have another model I won't judge founders for taking VC money.

Meh. Open source isn't magic. It can still fail just like anything else.

I see people downvoting this, but while it may not be artfully phrased it's absolutely true. There are countless small projects which fell by the wayside because they didn't get enough users to build a true community (e.g., "Ted," a "Rich Text Processor" that was, about 20 years ago, my favorite WYSIWYG-ish open source word processor) -- and even some relatively big name ones that were created by one company that just didn't get traction when the company stopped supporting them. Google Wave was already mentioned in the comments on this artlce and it counts; another one was the company I was at in the mid-2010s: RethinkDB. AFAIK, there's only been one minor release since the company folded and I think that release was the one that was "in progress" when the doors shut.

Zulip seems like it's in a much better place to survive, taking the word of the article, with an active development community around it. (I don't think I've actually heard of Zulip after the original company was bought by Dropbox, although "whether chipotle_coyote has heard of this" is admittedly not a leading indicator of success.)

The "why" in the article doesn't rest on open source being magic:

- building company without VC

- 100% open source, easy to self-host, high quality import/export

- building software so that it is easy to maintain and operate

- substantial community of developers (100+ commits) beyond those employed by company

Open source as magic seems like at most 25% of the argument, more charitably 10%.

I think a good point of comparison would be phabricator. It meets much of the same criteria (although much is subjective of course). Look where phabricator is now.

I don't know either very well (and guess you know phabricator very well) but it seems to me the criterion that there's a big difference between the two on is the last -- significant developer community not employed by the leading entity, though it isn't _that_ strong of a point for Zulip; it isn't say PostgreSQL. That also may be the best case for the "will" in the title, though it'd of course be better to say "Why it's relatively likely Zulip will stand the test of time" or "How we've tried to build Zulip to stand the test of time" rather than "Why Zulip will stand the test of time".

Reply on news.ycombinator.com