We used Zulip (then a commercial product) at FoundationDB, and really liked it. We had teams in two cities.
The threading, which they sell as the core feature, is nice, and does make it more usable for "important" conversations than purely chronological chat. It also makes it easier to screen out conversations you don't care about.
But IMO the killer feature is the "all messages" view that merges chosen streams in more or less chronological order. It makes it much easier to keep up with what you care about asynchronously without throwing everything into a single stream. And therefore it is easier to put down, and to use notifications very selectively, which mitigates some of the major downsides of company chat.
I haven't used Slack recently either, but as I understand it its "all unreads" feature is much clunkier.
I haven't used a recent version, but I would definitely consider using it again.
Same here. We're a company with about 50 people and deal with a lot of operational chatter. The threading model of Zulip works really great for us.
Before Zulip we used XMPP for a long time, then Mattermost for a short time (the threading model in mattermost didnt work at all for us), then moved to Zulip and never looked back. I definitely recommend Zulip.
> The threading, which they sell as the core feature, is nice, and does make it more usable for "important" conversations than purely chronological chat. It also makes it easier to screen out conversations you don't care about.
Does anyone have experience how this compares to the threading in Flowdock? I like their threading the best between the ones I've tried, but it doesn't allow you to skip or hide threads that aren't useful to you.
I'm still somewhat baffled by Slack's popularity as it's almost as bad as IRC on larger groups.
As news about Slack becomes fewer and farther in-between, reminders of how much more usable Flowdock was also fade from view. I'm left with a dead emptiness in my heart and a general pessimism about corporate communications.
Is there _any_ service with Flowdock style threading now? XMPP clients? Game chats?
Unfortunately they've taken a left turn on the quality front, at least for the iOS app. It was unmaintained and slightly buggy, but then it became maintained and slow, power-hungry, and extra-buggy, and new versions usually don't make it better. At least the macOS desktop app is still based on WebKit rather than Electron, so it doesn't guzzle battery.
They've added some handy features, and there are more in the pipeline, but the current mobile experience is so bad that I'm having trouble not looking at alternatives. This despite the threading and content model (inbox divorced from chat is amazing) that has kept me very loyal for a very long time.
Back on topic, I really enjoyed Zulip as well. It wasn't perfect, but it very much did feel like they were actually getting the marriage of email and chat closer to right. Slack just feels like a shitty chat client that uses all of my RAM.
It's really hard to get a sense of how Zulip works without any screenshots or videos anywhere on zulip.org, just general descriptions like "the world's most productive group chat" and "email threading model."
The fastest way to find out how it works is to go to https://chat.zulip.org/accounts/login/ and click "Log in with GitHub". They really need to make that path easier to find.
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).
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.
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.
I don't understand why so many applications do this. "Try our service! But we won't show you what it looks like or give you any details at all!" No, I'm not even going to consider your software if there aren't at least a few screenshots on the frontpage. It gets especially annoying when they use stylized wireframes in place of screenshots.
Why is it so difficult to take some screenshots and put on them on the homepage and/or features page?
Do companies actually pay for software they can't justify ahead of time? It took me months to justify the costs of a damn password manager and explaining why sending passwords over email and our XMPP was a bad idea
That is actually what I had to justify the first time (about 4 years ago), which was the more difficult one. We had a giant spreadsheet in Google Sheets with all of our logins and everyone seemed okay with it. Convincing them it was insecure and needed to be moved to Keepass was a nightmare. This took a good half year to do.
The second time (about 3 years ago), I had to convince them that team management and selective sharing were necessary and that we should upgrade to a paid software. This took several months to get approval on, even though it's only like $400 a year for us; thankfully management seems to agree that it is worth the costs now.
To be fair, I don't consider myself very persuasive so it's entirely possible that I just did a really poor job of it.
So I had something similar happen to me. I started out at the _ sign in _ page, I attempted to sign in with google, it remarked that I don't have an account and sent me to the _ sign up _ page that looked very similar to the sign in page, and from there, I was able to create an account via my google account.
1. https://chat.zulip.org/register/
2. "Sign up with GitHub"
3. "Authorize zulip"
4. Got redirected to "Sign up for Zulip" (https://chat.zulip.org/complete/github/?redirect_state=...)
5. Went to https://chat.zulip.org/ and
6. got redirected to https://chat.zulip.org/login/
7. "Login with GitHub"
8. "Zulip account not found."
Can you open an issue on http://github.com/zulip/zulip/issues/new? We haven't heard similar reports in the year since the GitHub auth backend was added, so I'm guessing there's something special about your account (or maybe a problematic browser extension); I'd love to debug this with you.
Another threaded slack alternative I've found enjoyable is Spectrum. (https://spectrum.chat) They've recently open sourced as well, (https://github.com/withspectrum/spectrum). Their design is appealing, and I can see a lot of work being done on the platform. Not affiliated or anything, just a fan.
P.S: I'm trying to create a community for "Bored Hackers", and you can check it out here and say hi! (https://spectrum.chat/boredhackers)
I love Zulip. I really wish other IM clients implemented functionality similar to Zulip's threading. It allows for easily filtering converstations and makes reading history that much easier.
That said, what Zulip lacks right now is polish. Server installation for example is a mess. You basically need a dedicated Debian machine to install it. There is a docker image that I'm using, but it's rather unstable (if I will have to make changes to the configuration, I fear I will have to spend hours trying to fix it). You also NEED to have a SSL certificate which means that testing in a local network isn't as painless as simply installing the server. There's also problems with the search function (it barely works), lacks things like archiving topics (or hiding them), enabling app notifications using their Google Play App requires you to send them an email and a few other things. Their apps also feel sluggish. They have an old Cordova app that is slowly losing compatibility with the server and a new app that is fairly slow. The desktop app is an electron app and it also has some issues.
Thanks for the feedback! I agree with some of these complaints (e.g. I very much wanted to fix the push notification registration process in this release), but I'd like to clarify a few things:
* Needing an SSL certificate should not really be a barrier. We now have an installer option to use Certbot which works great if you're on the public Internet, and if you're not, we have simple instructions for creating a self-signed certificate.
* I'm surprised by your comment about search; we often hear from users that they love Zulip's search. Can you open an issue with more details about what you're seeing? I'm wondering if e.g. search is broken in the Docker image.
As a sidenote, for the Electron desktop app in particular, all the performance issues that we could reproduce went away with the latest update (not because we changed something in our code, but because we upgraded Electron which had upgraded Chromium to a newer version with fewer performance bugs). If you're still seeing issues with app version 1.9.0, I'd love to see a profile captured from the app's developer tools.
Oh my bad then. I don't know why I though it was a Cordova app. Might have been because our last chat provider had one and I was mixing them up.
My problem with search is that it doesn't find URLs. I think it was reported already, but I will check anyway.
I feel like a little background would help this thread. I vaguely know/knew some of the founders, but am not really in touch anymore
Zulip was started as, and basically still was last I used it, a modernization/web-ification of the BarnOwl[1] curses/terminal client for, mostly, MIT's (and CMU's, inter alia [2]) legacy Zephyr[3] IM protocol. (though BarnOwl also has support for XMPP, IRC, AIM, and Twitter). MIT students who were into the zephyr community also tended to like the interleaved-thread with option to narrow to specific filters view. The Subject part of threading comes as largely an accident of Zephyr's implementation[4]
and subsequently open sourced in 2015. Zulipchat.com is a second company formed around Zulip by (OP) one of the original founding members of the pre-acquisition company to (I'm speculating) keep the project healthy and active and give people a hosted option. It is not primarily aggressively pursuing market share, capitalization, etc. That is why it doesn't like price aggressively to compete with Slack, etc. as someone EIT was confused about
I took the time to spin this out from memory, etc. but then I found it was mostly covered (or if you prefer corroborated) here: https://zulipchat.com/history/
Anyway its a good model for organized communications once you get used to it and I'd recommend it if you are in a small enough company/team with enough latitude to experiment with such. It would also be cool to see a decent large public instance as an alternative to ~Mastadon
When viewing the page on a Japanese Mac, the letter sequence "am" within "Open source team chat" is incorrectly displayed as a single-character "A.M." symbol. It appears the CSS is specifying "'dlig' 1" for the H tags - 'dlig' stands for Discretionary Ligatures, which triggers all sorts of weird inadvertent ligatures and should be used, as its name shows, with discretion.
https://www.dropbox.com/s/1j6vywsfycm6r4m/dlig.png?dl=0
They offer free hosting for open source projects. It has been really great for Mixxx (floss DJ software), allowing our ~10 person distributed dev team to work together much more effectively.
We're coming from Freenode as our only real-time communication so the difference is night and day. Slack is a no-go for many due to not being FLOSS and I'm concerned about vendor lock-in if they were to stop being so generous or run out money and shut down.
Slack's threading model is much worse than Zephyr/Zulip's IMO. Especially on mobile. The streams/topics flow in the "all conversations" view is an incredibly intuitive way to keep track of everything that is going on.
If someone tried to do it how easy is it to add to Zulip login with 3rd-party SSO server like Discourse?
Want to find alternative to Slack for open source project since restricting they apply getting annoying and it's would be nice to have single point of registration after all.
Zulip uses python-social-auth for some other backends, so for the more general version of your question about doing some other third-party auth, the answer is not super hard. That said, it looks like python-social-auth doesn't have a backend for Discourse: https://python-social-auth.readthedocs.io/en/latest/backends....
It's also probably not super hard to just add a direct authentication backend for Discourse.
Thanks for information. Seems like I should be able to do it.
Though if we want to have little customization like that does it mean we'll absolutely need to host it on our servers or something like that possible on hosted plan?
PS: Obviously I get that If I manage to push code upstream hosted option will support it, but I suppose it's might take a while.
Once something is merged to master in zulip.git, it's usually on zulipchat.com production within a few days.
So if you do it in a way that gets merged (which requires, e.g., automated tests appropriate for an authentication backend) and is configurable for just one organization in a multi-organization server, you would not need to host your own servers.
The first intriguing thing I found was this product is owned by Dropbox.
Slack eating into Dropbox's territory with (decent) file sharing / searching and Dropbox countering with a alternative chat/ threading app is a nice battle.
Yeah, well, even if it is an open source project, what about git? You can't remove an arbitrary commit in the tree. I'd argue discussions about code follow under the same umbrella.
I really thing people are taking this GDPR thing WAY too seriously. They are really only going after the obvious abusers, IMO.
I doubt it. I've read the 66 page standard and I remember something about "records required for business", ie transactions, tax info, etc. I'd argue employee conversations would fall under the same umbrella.
These are the things I need in a chat replacement.
I've discussed possibly funding these things for riot / matrix not sure I can afford it, but I know I can't afford not to have these kinds of options in a public chat system.
looking at the features, I'd need a way to have the server download any images / attachments, check for viruses, strip any exif data, before showing preview to the room.
(evil actors host an image on their server, post it to the room, and bam they have everyone in the room's ip addy, at that point everyone's router had better be updated.
Looks interesting, and I am looking to replace a java / flash chat system from a decade ago that is yet to be beat sadly.
This is designed to be run inside an organisation with some degree more trust than what you have in your situation. You should submit some feature requests (https://github.com/zulip/zulip/issues) for these things because they do come up in some business scenarios (e.g. a way to plug-in virus scanning.)
In Slack threads are an annoyance. They lead to missed answers and discussions, because they are rarely used in average user groups. When they are they default to private only for the writer and appear out of the natural flow for the reader.
In zulip every message belongs to a topic. (Well there is the "no topic" topic, but it shouldn't be used and even if it is it appears exactly like every other topic). So no surprises.
I have used slack (and irc and xmpp) for a long time, and Zulip for 2 months. Zulip is certainly much better for the geek.
Slack user experience is somewhat more straight forward for the naive user not caring about things done "right".
For hacker news readers zulip is likely to be the preferred choice. Expect resistence from your non hacker news colleagues / managers / team members.
In busy channels in medium-sized companies, lack of threading is a huge pain: person A says "Hi, I'm trying to do X, how do I do this," person B says "Hi, I'm getting error message Y" 2 minutes later, someone shows up 5 minutes later and says "Have you tried installing this thing" and they were talking to B about solving Y but A tries to install it and use it for X and then everyone is confused and wastes time.
Slack is positioning itself as an email replacement, and to some extent all of these tools are replacing at least some email. Imagine taking 20% of your email and not having subject lines, just authors. What's the "LGTM" for? (Or worse, the sender anticipates that and says "Re @pm at 00:10, agreed" and then you get to track that down.) Or imagine taking your in-person conversations, the ones that you'd eventually want to move to IM to support distributed or remote teammates, and having a rule that you couldn't go up to someone's desk, instead every in-person conversation had to take place at this one water cooler. If multiple people wanted to talk, well, either they can have multiple conversations in front of each other, or they can wait until one conversation is done.
(Slack's implementation of threading, meanwhile, doesn't actually solve the problem that well because of the way it pushes threaded conversations to a side. Imagine email without a reply-all button - it solves some problems and creates so many others. You can and should live without Slack threading.)
... also, another argument that threading matters: you're using a threaded forum right now. Remember phpBB? Would HN be improved by switching to a phpBB-style UI? If you unindented all the comments on this page and sorted them by time, would it be a workable experience?
Why not to use direct messages for the example you gave ? Or even better reply to the message itself which creates semi topic under it ?
Also if you have some specific topic you would like to discuss like k8s or linux there should be specific channels for that in a company.
You can reply to exact message in slack. Ive been using it for over a year in a company hiring few thousend people and we had no issues you describe here...
> Why not to use direct messages for the example you gave ?
Slack sells itself as a searchable archive. Ideally if someone asks the question a second time, they (or someone else) can look up the answer. Direct messages mean conversations don't get publicly logged, which is a serious negative for the company.
> Also if you have some specific topic you would like to discuss like k8s or linux there should be specific channels for that in a company.
My company has three channels for GitLab, Git, and software development / build infrastructure, which sort of seem like overlapping topics already. But even with this split, we regularly have multiple conversations attempting to happen.
Think of, say, JIRA queues vs. tickets. We also have three separate JIRA queues for GitLab, source control, and development tooling, but we still use separate tickets in each queue, not one general-purpose ticket for all GitLab discussions.
It's hard to describe the benefits of this system to someone who's only ever used linear chat (or linear chat with weird thorns sticking out periodically, like Slack). On Zephyr, which is what Zulip was modeled after, I was in chat rooms that created a separate topic for each development issue and each customer support ticket, which made it easy for different groups of people to work on different things and still stay in the public chat room, and also extremely easy to go look up history later. Searching for things related to a ticket or a pull request in Slack is basically impossible.
These problems aren't obvious because people learn to work around them, mostly by avoiding public channels and IMing their friend, talking in person, keeping things in email or an equally high-latency system like JIRA, etc. But they're still problems that a good tool could solve. (Plenty of companies would say, we don't have group chat at all, we're working fine with email and person-to-person IM; probably you'd tell them that having something like Slack would be worth trying.)
"Reply to the message itself" is what Zulip does best, and where Slack is lacking. I have to zoom in to a thread to see what's going on with it, I can't just follow the main room and see the tag for a sub-thread interleaved.
It's a filtered event stream, where you have 2 tags, "chat room" and "topic". You can see the full firehose with both tags, or zoom in to a room and see topic tags, or filter to just the topic if needed. Slack won't give you the first option, and does the second poorly since you can't see the topic responses inline.
It's one of those things that I didn't realized was a big deal until I experienced the alternative -- I just signed up, tried it for less than five minutes, and I'm already sold on this over Slack.
(I'll also add that I recently spent over a year working from home where most of my interactions with other team members was through slack, so I'm fairly experienced there.)
Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP)
Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words.
In this way threading is tacked on to Slack whereas it is as at the heart of Zulip
Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading". The searched messages are sorted by
In other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.
You could alternatively OAuth sign up for the chat.zulip.org server used for project development and see the feature in action there (https://zulip.readthedocs.io/en/latest/contributing/chat-zul... ) so long as you kept testing traffic to the `#test here` stream :-)
We used to do that, but it turns out that having the Internet visit your chat community without any briefing isn't the best plan. Linking to the ReadTheDocs page has helped a lot in making sure people joining the community have some sense as to what to expect (e.g. that it's at times running a super beta version of Zulip, or that people are doing actual work, that we have a code of conduct, and you should send your test messages to #test here).
just use a fake email (it's unused) and try it out. every time there's an announcement in this space i go to the landing page and am disappointed that trying out the product appears to be semi painful
Problem with Discord is that unlike project targeted to corporate customers it's might break APIs hard or change UI without notice or enforce whatever weird rule they desire.
Also they burning VC money and don't yet have proven business model so investing time in adopting it for non-gaming seems like strange decision.
Agree, they are throwing piles and piles of money into their cloud costs, and now they have implemented screen sharing too... a much requested feature to put them in a Skype-kill positon. The free money is going to dry up eventually, and how they lock it down and pivot to start making money is still unknown.
Having your team's core communication tool go down and be hard to bring back up can be quite painful. So as a project, we put a lot of effort into release management to minimize the risk of that happening. I personally postmortem every report of an error when upgrading.
As a result, for most folks, installing a security/bugfix release Just Works with a few seconds of downtime. For a release like this one with 3000+ commits, dozens of database migrations, and tons of new features, our largest sites found it Just Worked with about a minute of downtime while the database migrations were running.
If you really care about availability like we do with zulipchat.com, it's possible to have downtime be seconds even with the database migrations, but that requires a bit more expertise on how Zulip works than we think it's fair to expect server administrators to learn, so we don't recommend that to most folks.
So the main downside in this space of self-hosting is that zulipchat.com runs very close to master, which in practice means you'll get new features on zulipchat.com first (though folks running their own server can always upgrade; you just end up on the hook for the work). On the flipside, self-hosting is better for i18n (since our volunteer translators generally make sure languages get to 100% around a release, but new strings may not get translated for weeks after the code gets into production on zulipchat.com).
What is stopping you from running it in k8s? Don't you just need to create a docker file based on the Ubuntu docker image, plus whatever installation steps zulip requires?
EDIT: There seem to be some folks who have done that already:
It has @mentions, notifications, and the ability to have some Google-Docs style inline comment threads, so depending on the use case I'm not sure you'd totally miss it
Otherwise perhaps phacility-hosted (so cloud) Phabricator, wherein it is mostly (a less unified UI) project management system but has the realtime chat component available in https://www.phacility.com/phabricator/conpherence/
Threading done right or wrong in in slack doesn’t really matter. What matters is if your point gets across. Sometimes that’s fine via threads. Sometimes threads get in the way.
> You’ll need an Ubuntu system that satisfies the installation requirements.
So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages.
There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what other software is required, e.g. for the database, how Zulip uses it, what libraries or other kind of dependencies it has, etc.
(and get a lot more detail if you browse around the rest of our 120K words of developer documentation).
I have a great deal of Debian packaging experience (I used to maintain over 100 Debian packages for MIT's Debathena project, mostly powered by the config-package-dev project that I'm a co-author of; and then later 20+ in Debian itself as part of getting Sagemath into Debian; and I maintain the handful of Zulip dependencies that we ship versions of in our Ubuntu PPA), and so I have a pretty good sense of what does and doesn't work well with the Debian (and RHEL) style packaging models.
I'd love to support native packages for every platform, but it's a huge amount of work (especially on the maintenance side, since one needs to do QA for each platform's upgrade process) that comes out of the time we can spend on making Zulip a better product. And the result is likely to be less good error-handling; I'd rather have an installation/upgrade process that just works (and if it can't because of some problem beyond our control, like the server not having enough RAM or disk, gives a clear error message that explains the problem to the user) but is limited to one platform (which anyone can easily get; virtualization is 20 years old at this point!), than support lots of platforms but be constantly fixing little issues with the other ones.
Which isn't to say that we won't support e.g. RHEL in the future (we probably will), just that it's costly to do so, and the "Use an Ubuntu VM or container" solution works pretty well for most folks.
That said, we're open source (and an open community!) and anyone who's worked with Zulip knows that I'm very happy to provide detailed technical advice and do code review to help things like this happen.
That and this page [1] mentioned by zerkten, are what I wanted. Too bad I didn't find them in the first place. Maybe they should be mentioned in the page I've complained about.
I'm familiar with RPM packaging, so I feel you pain.
I understand that you don't have native support for every platform, after all you probably don't support Windows :-) What puzzled me was the lack of instructions, so that others could at least try making Zulip work on their system.
Those instructions are for the development environment which is simpler in a few key ways (e.g. one doesn't need to deal with SSL certificates). But yes, that'd be the starting point for a production installer for other platforms.
I see Docker / your container tech of choice as a solution to this. Your server can still run whatever distro, and a specific app can run a different one.
This can be annoying from the sysadmin perspective, since there are now multiple operating systems to take care of, but at the same time, the developer may not be able to produce builds for all distros their users would like.
Ubuntu is a fine choice IMHO, given the above. But yeah, some debs / ppa would be nice.
One day libfoo announces a must-fix RCE bug, which started in 1.74 and is fixed in 2.11.
Quick, which containers have libfoo in them? What version? Do you have a complete build process for them, or did you download the container from somebody else? Is it a clean libfoo, or did somebody clone it into their own tree and has later made modifications to it?
And that's really quite "annoying" from the sysadmin perspective, which makes it annoying from the devops perspective, which should make it annoying from your whole IT infrastructure perspective.
This strikes me as ironic, because Zulip started as a SaaS project. Much of the current cruftiness perceived in the install process is likely because earlier generations of the Zulip codebase were written with the presumption of developers in the same team being the ones deploying it.
SaaS itself is the cancer killing usable software installations, not the other way around, IMO.
The install was a breeze. Even with very little experience with Docker it took me a matter of minutes to fire up a Digital Ocean droplet, paste in a few commands and have a fully working install.
Every open source web app should have some equivalent that is as simple as this.
The install was a breeze because you practically installed a self contained black box. What if you wanted to use Apache instead of nginx or a custom compiled Python interpreter or PyPy?
How often do the majority of people need to make these changes? With a well designed "self-contained black box" it should be possible to make the changes you suggested (web server and Python interpreter) pluggable, to some degree. There is always going to be a trade-off which has an impact on those with more specialized requirements.
Companies and investors prefer SaaS because it solves their requirements, including: cheap support with no legacy installations, and the ability to move the product in new directions very quickly. This often doesn't overlap with what all customers of a piece of software want.
SaaS software often hits a sweet spot for one set of customers and then it is updated to match the needs of a new set of customers. Conflict can arise and the first set of customers abandon the product or are unhappy. When customers can deploy the software themselves they can decide to stay on the old version.
Of course this is often a terrible decision because customers get stuck on the really old version, experience security issues etc., but when it is managed appropriately (i.e. just strategic software for a business) it can work out. Managing lots of individual packages is a cottage industry for IT teams in big companies so they often undermine efforts to do this right.
I think that people who want software as a service, are probably happy with running the install script on Ubuntu and just treating everything as a black box.
It is not "Free", it is freemium. Zulip On Cloud is the exact same freemium model and pricing of Slack. Zulip On-Premise also is freemium (Enterprise plan do not show the price).
You can download Zulip and host for free on your own server. That's what the blog post is mostly about. Zulip cloud is also Free with no limits for open source projects.
Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users.
I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything.
Does anyone know about any hard limits with either Zulip or Rocket.Chat?
We tried RocketChat for about a day before switching to Mattermost. It wasn't great, but worked okay for a team of 20-30.
After a month or so of mumbling and grumbling on MM we went to Zulip, and brought on another dozen or so designers and PMs. Zulip lasted about 6 months before management implemented Slack company-wide and rolled out for the other 100 sales and support teams.
Zulip was the best for engineering, by far, but it was doomed from the start because the UX wasn't as simplified and polished as Slack. It didn't Just Work, you had to think and use it properly to see the benefits.
Back to your question: no limits I know of, and a t2.medium was 90% idle for an active team up to ~50 without a hitch. I think the docs (or launch announcement?) mentioned a large deployment around 1k, but I can't remember the details. You'll definitely want to test your expected configs and hardware to be confident.
We've been extremely happy with the Python 3 (with mypy static types) and Postgres stack. Like with any app, you need to take some care to design the database model right and avoid database queries in loops. But with our design, all the expensive operations are done in the database and cache, so Python is just as fast as anything else. And because our data model design and indexes are correct and Postgres is awesome, the database queries are all fast. We use Postgres' built-in full-text search, and people frequently praise Zulip's search as being unusually good for finding past conversations.
PostgreSQL is really really good, for any normal amount of data, or any normal number of users. If you can make Postgre do most of the work, it doesn't hugely matter what you build on it.
If you're Facebook or Google scale, you may need something with a different performance characteristics, but 99.9% of the world doesn't. Except that even Facebook doesn't: as I understand it they still use carefully sharded MySQL.
Yes I guess with the right hardware everything is possible. The question is if you can get away with smaller hardware when using non-relational databases. Well one would have to test this.
Python fits very well this use-case. If you design a chat app properly you should be doing very little computation. With Python's async you can scale up to large number of sessions / users / channels without issues.
I said concurrent users as in users that are online at the same time, each of them probably connected via WebSocket streaming and sending messages.... Thanks for the downvote...
Regarding Postgresql, are you denying that relational DBs are less suited for write intensive tasks than say a NoSQL DB like MongoDB is? And couldn't a chat with thousands of users be a more than average write intensive scenario?
> The project survived my becoming a parent in December and taking 2 months off to bond with my baby daughter Lily. For me, it was a great stress test of Zulip’s catch-up experience; I was able to catch up on over 20,000 messages of chat history when I returned, following up on more than 100 conversations that needed my attention.
So is that what you've supposed to do when you become a parent? Stop doing everything else for two months, than never look at your child again? (Not saying the person did this.)
Explaining my downvote here: this doesn't add anything valuable to the conversation. Either you have a defensible point or you don't; this sort of behavior suggests that you are more interested in having an argument than a discussion.
On what basis do you even suggest that that's what happened? They say that they took 2 months off after the birth of their child (which seems reasonable) and then had to catch up on their messaging when they got back.
The threading, which they sell as the core feature, is nice, and does make it more usable for "important" conversations than purely chronological chat. It also makes it easier to screen out conversations you don't care about.
But IMO the killer feature is the "all messages" view that merges chosen streams in more or less chronological order. It makes it much easier to keep up with what you care about asynchronously without throwing everything into a single stream. And therefore it is easier to put down, and to use notifications very selectively, which mitigates some of the major downsides of company chat.
I haven't used Slack recently either, but as I understand it its "all unreads" feature is much clunkier.
I haven't used a recent version, but I would definitely consider using it again.