Hacker News new | past | comments | ask | show | jobs | submit login

We're definitely planning to provide a slick explanation on zulipchat.com. Using chat.zulip.org is helpful, especially if you visit a day later and read the message history; since you really only experience Zulip's magic properly when catching up on a bunch of unread messages (the `n` hotkey in particular is super great).

That said, https://zulipchat.com/features has a screenshot; and https://twitter.com/b0rk/status/986447131421609985 does a pretty good job of explaining the concept. And https://www.recurse.com/blog/112-how-rc-uses-zulip explains some of how Zulip's model can make a big difference in how an organization communicates.

(I'm the Zulip project leader and wrote the blog post)




Given that it's free software, it might be worth making the install instructions a little bit more visible. At least then people can whip up a VM and try it on their own. The instructions[0] look straight forward, though I haven't tried it.

Just a quick question... How difficult is it to build, install and run from source? I guess I'm slightly concerned about the "it expects to have the whole machine" in the requirements section. Is that just for your installation scripts, or are there assumptions baked into the server? (Apologies for asking without looking myself!)

Making that build process super easy (if it isn't already) might lower some barriers for the technical crowd (personally I don't like setting up VMs... maybe it's just because I'm old :-) ). Possibly you can leverage more from your free software angle.

[0] - https://zulip.readthedocs.io/en/1.7.1/prod.html


Building one's own release is easy. Before I get into how, you should be linking to https://zulip.readthedocs.io/en/1.8.0/prod.html for installation instructions -- that's the much simplified install instructions for the latest release.

In the Zulip development environment, you can build your own release tarball with `tools/build-release-tarball`. Or you can just clone the Git repo and run `scripts/setup/install` directly (similarly, you can use `scripts/upgrade-zulip-from-git` to upgrade to any Git ref, which is great for running a pre-release version or a small fork).

The "expects to have the whole machine" story is just that we need to configure third-party services like nginx, postgres, redis, and memcached, and it's very hard to write configuration for all of those to support Zulip that doesn't carry some risk of breaking an arbitrary third-party app that might have been installed first.


That one single screenshot shows... a chat I presume? Which looks marginally worse than Slack.

I couldn't care less for any other links, because they: are on some other sites that you assume are discoverable by magic.

Now imagine a person who has used Slack, and has never seen your app in their life. They arrive at your landing page. What are the incentives for such a person to download the app? Generic marketing-speak?


One stripped down screenshot is not enough. I need to see at least one image of your application in all of it's glory from the moment I hit the page. More is better. You can describe it all you want but if I can't actually see an image of it in action, I'm not going to be interested enough to go through the (poorly documented) install process.


That screenshot shows nothing about the threading model! If you're going to toot your horn about the fantastic, revolutionary, "world's most productive" threading model all day long, for goodness' sake show us what the threading model is, front and center.

The "world's most productive" phrase is doing you no favours, by the way; it's substance-free marketing hype. It gave a slimy first impression that I had to fight past to try to find out what Zulip was really about. Show, don't tell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: