[HN Gopher] Why Zulip will stand the test of time
___________________________________________________________________
Why Zulip will stand the test of time
Author : williamstein
Score : 129 points
Date : 2021-12-17 18:13 UTC (4 hours ago)
(HTM) web link (blog.zulip.com)
(TXT) w3m dump (blog.zulip.com)
| nousermane wrote:
| 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).
| kevinmgranger wrote:
| 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?"
| nerdponx wrote:
| It is. So what _was_ insufficient about XMPP?
| cracell wrote:
| 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.
| duped wrote:
| How is it "bad" if it's the standard used by the most
| successful messenger platforms
| rcthompson wrote:
| 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.)
| duped wrote:
| 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.
| jlkuester7 wrote:
| > _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...)
| jlkuester7 wrote:
| 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.
| akvadrako wrote:
| 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.
| agentdrtran wrote:
| 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.
| wellthisisgreat wrote:
| It was about 30 min to deploy to AWS including the
| documentation
| nousermane wrote:
| > complicated to deploy. Not just a simple docker container or
| anything.
|
| Huh? https://github.com/zulip/docker-zulip
| azundo wrote:
| > 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.
| vetinari wrote:
| 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.
| mushufasa wrote:
| 2. also literally one click here
| https://marketplace.digitalocean.com/apps/zulip
| vetinari wrote:
| 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.
| dsr_ wrote:
| 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.
| hadlock wrote:
| 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.
| Zigurd wrote:
| 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.
| aidenn0 wrote:
| > 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.
| serial_dev wrote:
| > 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.
| Xylakant wrote:
| 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.
| zamalek wrote:
| 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.
| wellthisisgreat wrote:
| 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?
| bachmeier wrote:
| Twist
| jlkuester7 wrote:
| > _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...
| ngrilly wrote:
| 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.
| wolverine876 wrote:
| > "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.
| jlkuester7 wrote:
| > 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?
| wolverine876 wrote:
| > 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 ...?
| MiyamotoAkira wrote:
| 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
| brunoqc wrote:
| Where is Matrix support for zulip-style threads? It's been a
| while.
| jlkuester7 wrote:
| 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!
| aidenn0 wrote:
| 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.
| postpawl wrote:
| 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.
| stavros wrote:
| 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.
| spurgu wrote:
| 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-desig
| n/topic/.2Fdi...
| cracell wrote:
| 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.
| warmfuzzykitten wrote:
| 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.
| bawolff wrote:
| Meh. Open source isn't magic. It can still fail just like
| anything else.
| chipotle_coyote wrote:
| 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.)
| mlinksva wrote:
| 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%.
| zwkrt wrote:
| 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.
| svieira wrote:
| Though under the earth and throneless now I be Yet, while I
| lived, all the earth was under me.
| easton_s wrote:
| If you cross any bridges watchout for Liam Neeson.
| circularfoyers wrote:
| I heard Richard Attenborough's voice in my head as I read
| this[1].
|
| [1] https://www.youtube.com/watch?v=gX0oubhFydc
| vinaypai wrote:
| I heard it in Leonard Nemoy's voice, discovering the
| Contstruction technology in Civilization 4.
| [deleted]
| worker767424 wrote:
| 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.
| joshuakelly wrote:
| 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.
| stagger87 wrote:
| So he sold the original company/product, then got it released as
| open source, and built another company based on it? Nice...
| romwell wrote:
| _Saving this post for after the test comes_
| bachmeier wrote:
| 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
| cmroanirgo wrote:
| 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
| bachmeier wrote:
| I don't think Slack offers e2e. If they do, it's a recent
| development.
| JaggerJo wrote:
| 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.
| jlkuester7 wrote:
| 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!
| asah wrote:
| 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.
| alya wrote:
| 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.
| ngrilly wrote:
| 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.
| terpimost wrote:
| 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
| strifel wrote:
| probably pretty easy using the API. https://zulip.com/api/
___________________________________________________________________
(page generated 2021-12-17 23:01 UTC)