They decided to up their price per user by a significant amount not too long ago... our self-hosted instance suddenly became more expensive than Slack but with an obviously not nearly as polished product as Slack. So we moved over to Zulip because at least they do their own thing, we haven't had any regrets over the switch to Zulip.
It's a chat app that doesn't eat your life, but just provides the service of helping you to communicate. It doesn't want to interrupt your workflow. It doesn't try to connect to everything. It makes it easy to organize work conversations and doesn't wish to be the remote work coffee machine.
It seems unreal that nowadays, I find solace in a software for finally trying to help me instead of extracting value or stealing attention from me. It should be the default.
My former company adopted Zulip because we were in the cybersecurity space and needed an on-prem solution. When I first saw it I thought "oh god this is going to be awful" - very ugly UI compared to Slack and others. But after getting used to it, I found that the UX is excellent.
For anyone searching around, don't be put off by the lack of "polish" - Zulip has a really good fundamental design.
We tried Zulip about a year ago. There were loads of things we loved about it - the threading model in particular - but the learning curve was steep for non-technical members and the mobile app lacked a couple of key features (share sheet integration was the big one, from memory). We also looked at Quill, which had a similar threading model but … was bought and then sank without a trace. We ended up on Slack, which is a total car crash. Can’t find anything.
It was frustrating because Zulip felt like it was so close to being a great - and unique - product. Might be time to take another look and see if it’s there yet. It’s a really great community, friendly and very responsive on GH issues.
Head of Product for Zulip here. I'd love to dig in deeper to understand what's confusing to non-technical folks as they are starting out, so that we can keep working to improve the product and documentation to address it. If anyone is up for a chat, please reach out by email at support@zulip.com, or in the #feedback stream in the Zulip development community (https://zulip.com/development-community/)!
Hello there, thanks for the offer, very much appreciated and characteristic of the Zulip community as a whole.
I actually did open and/or add to issues on GH, and actively participated in the development Zulip instance on the issues that came up for us as a team. I found the community to be very receptive.
I just want to reiterate, for anyone coming across this thread now or later, that Zulip really is a fantastic product and open source project. The main uphill battle for us was getting non-technical people to buy in to a paradigm of effectively “filing” their messages up front. That’s not some kind of problem with, or criticism of, Zulip as a product. For messages to be in correct context, the sender needs to _put_ them there. To want to do that, it helps if they buy in to the paradigm in the first place.
“Why do I have to do this?”
“Because it makes it possible for anyone to come along later and get the whole picture.”
“Okay, that’s worth a bit of friction up-front.”
It’s really a people thing - not a Zulip thing.
Just 2c from our little team.
Best of luck and thanks for all your great work. We’ll definitely be checking it out again soon.
My view is that there is a UI issue here, but I can't come up with a suggestion of how to improve it.
People get their head around MS Teams very easily and fundamentally the only difference between Zulip and Teams is that you are required to put a title/subject on your thread in Zulip as supposed to Teams where it's optional.
In Teams the value of this is clear whereas in Zulip you need to understand the goal. I've always thought that with a bit of a step back UI adjustment to Zulip things could be clearer.
What made the learning curve higher for non-technical members on Zulip than it was on Slack? It’s been a few years since I used Zulip, but I don’t feel like it had a particularly different level of complexity.
I think the fact that you must give a thread topic to send a message.
It's not particularly difficult concept, but different from every other chat app. And for a large user base being confronted with this demand "when they just want to send a message" is frustrating.
Yeah that’s consistent with what we found. The threading model is so powerful, because even large teams that are mainly async can actually find stuff they need, _in context_. That’s really difficult or impossible in something like Slack, Discord, etc, and the value of that can’t really be overstated.
On the other hand, you’re asking people to buy into what is essentially a completely different paradigm than what they’re used to. Maybe it’s more like a loosely-structured wiki than a chat app.
I really like it, though. I feel like it deserves a lot more attention than it seems to get.
Zoho Cliq solves this by using ML to parse the message and give a suitable name.
It's suitable 7/10 times, and the remaining 3 - it either doesn't matter that much or is trivial to rename.
Disclaimer: I work for Zoho, but in a different team.
I find that I really like it for work.
But for informal interactions (gaming etc) I like Discord better because of the voice channels. In Cliq they're "calls" and feel much more formal.
> And for a large user base being confronted with this demand "when they just want to send a message" is frustrating.
Isn't it a conceptual framework thing, though?
People have no problem putting a topic when sending emails, and they are perfectly capable of following grouped conversations, as for example in Outlook.
Maybe it would be enough to present it as "a mail application where you can also do chat on a reply thread", to create the right expectations?
I don't think we are missing the point, we were looking for a Slack alternative and found one. They charged a bit to give you push notifications, now they charge more of it. If not having push notifications were an option for us, we'd have simply downgraded.
Then you also need to build and distribute Android and iOS apps for your employees. Congrats, you now have a significantly larger project than "put Mattermost on a server and update it occasionally".
I am using it on both cloud-hosted (work) and self-hosted (friends chat) servers.
Push notifications work fine, the mattermost app that's already on the android and iOS stores work fine, they have done for the 3-4 years I've been using it.
We tried Zulip a couple times and ended up setting up a Matrix server when Slack became unbearable. The advantages of being able to federate with other channels is high, like almost everyone I have severe channel overload and I want an application which will be open all the time to reach as many people as possible.
It's almost coincidence, though, both Zulip and Matrix became 'good enough' around the same time, and we actually tried to move to Zulip at one point, which I think hardened opinions. I do like the semi-threaded approach Zulip takes, just not as much as I like even the possibility of a future where I can use Matrix for as much as possible.
> I do like the semi-threaded approach Zulip takes
Interestingly I think of Zulip as the fully threaded approach, and Slack/Discord etc. as the semi-threaded approach (because it's optional). The only other "fully" threaded approach I know of is MS Teams (in the Team) - each conversation is a thread (and the fact that people don't realise this is an indication of how good the UX is).
and Zulip has a "public access" view, which I wish more open source projects would adopt (:eyes: kubernetes.slack.com) since it allows search engines to index into the threads: https://zulip.com/help/public-access-option
> Web-public streams do not yet support search engine indexing. You can use zulip-archive to create an archive of a Zulip organization that can be indexed by search engines.
Ah, thank you for pointing that out and sorry that I didn't notice that caveat. I somehow thought Google's indexer was "hash url" aware but I can totally appreciate that the devil is in the details about that stuff
We're on a freemium plan for slack. Works fine and doesn't cost us a thing. We don't care about having an archive of chats. That's not what it is for.
Self hosted would cost us more in devops money than we'd end up paying even for a premium SAAS contract for whatever you would use for this. People think devops is free, it rarely is and usually is the most expensive thing in terms of cost. Especially doing it properly can eat into development time quickly. Which unless you are bored and have nothing better to do is even more costly. Somebody costing 1000/day spending even half a day on this adds up quickly. And it's never just half a day. The point of hosted SAAS software is getting people like that out of the equation.
You can pretty much run a small startup on freemium accounts for a lot of things. Our biggest IT cost is google docs and google cloud for our actual infrastructure. These days we are also paying for a few additional things (Asana, Figma) but we started out with freemium accounts for that as well.
> Self hosted would cost us more in devops money than we'd end up paying even for a premium SAAS contract for whatever you would use for this. People think devops is free, it rarely is and usually is the most expensive thing in terms of cost. Especially doing it properly can eat into development time quickly.
Perhaps you have no idea how to manage servers but launching an instance and a docker container isn't magic which requires a single weekend of learning and it costs that one time operation and $10/mo for the server. (What the hell is a premium SaaS contract? Are you being oversold by some salesperson?)
Certainly not knowing how things work is rather expensive thinking it is expensive.
I'm an engineer and CTO and well aware of how a "why don't you just ..." can escalate into a significant side project. The thing is I know how these things work and I've seen them escalate repeatedly. We used to run things like jenkins and gitlab self hosted. And we had to deal with outages, backups, things running out of disk, etc. It was doable but definitely a bit of a time-sink.
If you don't care about devops, monitoring, uptime, and all the rest, then yes, you can run the entire company off a few beautiful snowflakes on some VM. If it goes down, you just do it again. Been there done that. But doing it properly requires a bit more effort. I shut down my last self hosted Jenkins about five years ago. Not doing that again. Just not needed anymore.
Anyway, for things like slack (which, again, we run for free), I don't see the value of self hosted.
We just launched a free forever SaaS offering that is competitive to Slack and includes kanban boards for project and task management and a few other bells and whistles for software developers. You should give us another look!
For further elaboration, self-hosted just means that you get a license to install the code on a server you control - whether that license is FL/OSS, something proprietary, or some middle ground (open core etc).
We now have multiple Mattermost server support in the mobile apps in Beta! If you're interested to try it out, here's how you can join the Mattermost Mobile app beta program.
The community feedback on the Beta version has thus far being excellent, and helps us improve the user experience before we ship multi-server support as a stable release to everyone :)
> We now have multiple Mattermost server support in the mobile apps in Beta! If you're interested to try it out, here's how you can join the Mattermost Mobile app beta program.
This is fantastic news!
It is/was a problem having to choose which server to connect to, when I had multiple Mattermost servers.
This new feature will fix that quandary
Different Question: can I point `mmctl` to your managed cloud instance (are the "free tiers" exempt from this ability but paid tiers allow this?), have it create a backup and restore that backup to a local Mattermost team (the OSS) instance? This is just to be able to migrate old team chats off the Mattermost cloud instance but retain the ability to quickly read them now and then if needed
Thank you for the feedback but I’m going to wait until it’s published in the respective App Stores.
One piece of feedback for you and your org: the whole mobile v2 process was not very transparent from the outside. I tracked the ticket from time to time but gave up after a year as no visible progress was being made. Maybe that happened in some Atlassian forum, which to be blunt I’m not going to create an account for simply to read a thread.
I wished my Organization would adopt Mattermost. Using it for years as a Chat to stay in touch with my friends.
My Org uses MS Teams (because it is already bundled with MS 365). What Mattermost is missing is a Videochat / Videoconferencing option - there is a plugin but I didn´t tried it yet: https://mattermost.com/marketplace/microsoft-teams-meetings/
When I was on a project that used Mattermost we had BigBlueButton integrated. It worked adequate. As a user, at first I didn’t even realize that BBB was a separate thing.
I like that Mattermost treads Channels as Groupchats, and you can reply to a Chatmessage or just add to the Conversation where in Teams you have Conversations where you can reply to or start a new one, this leads to people replying via new conversation or replying while it's a new conversation.
I also dislike the notion of Teams with Subchannels in Teams and the hard cut between Chat and Teams - I like the way Mattermost does it more: a <hr> Element between Channels and Chats.
I think it's widely hated because its absolute hot garbage from a UI/UX. Slack is bad enough from a UX perspective (not necessarily Slack itself, since the UI is nice, but from an overall experience of "interrupt anyone anytime"), but Teams took the concept of direct messaging and instantaneous communication and then arguably made it more frustrating.
Mattermost is amazing! We used it with multiple teams over a period of a few years. Self hosted. Cheap of resources. All of the necessary features are there and very well thought out.
Thanks for doing a great job. I really hate most of the software I have to use these days, but Mattermost is one of the few exceptions. It is fast, it isn't intrusive, it respects me and my time, all while doing what it promises.
To me it is better than the competition, since their products affect my computer speed, even though I just got an update. I'd much rather have the productivity not taken away by Mattermost than features (although Mattermost has 100% I need).
The only thing that prevented us from using MatterMost when switching away from Rocket.Chat was video/voice calls that would actually ring the mobile/desktop devices on the call. We had to settle with MS Teams and eventually got the MS365 bundle only because of the reliable calls in Ms Teams. Although chat is a pita in teams after using Rocket.Chat for years, we’re making more calls and writing fewer chat messages.
This would be interesting if E2EE was officially supported. I could run a server for a group instead of using a hosted service, but it would never fly if the administrator (me) could read their messages.
I see there is a plugin for it¹, but not having something so core in the main product makes me sure there will be friction and user support issues.
Matrix and XMPP are excellent options worth considering for your use case. XMPP is more mature but modern clients implementing all the right RFCs are a bit scarce, Matrix clients are coming along relatively quickly but there's the occasional quirk.
Both have optional support for features like federation and bridging other chat clients as well, though the results are often not exactly perfect.
Personally, I'm quite happy using Matrix+Element/Cinny/Fluffychat to gather several chat services into one place. Experiments with native group chats have also gone down as of a year or so ago when encryption finally got most of its quirks worked out.
> This would be interesting if E2EE was officially supported
The reality is people claim to need E2EE but it's not worth paying extra for it.
It's kind of like how people nod when you ask them if they hate companies like FB/GOOG stealing their personal information and then you offer them a dollar to give your their DOB, Address and SSN and they happily take the dollar and share all of that info.
… and those really serious about E2EE are using their custom stack anyways.
It's good that this exists, but Mattermost's threads are very suboptimal.
If Alice posts a message and Bob replies, then _that is_ the thread.
If that thread goes into a certain path you can't branch off of it, you can't reply to Alice's original message if you're talking about a different thing.
I don't know if this makes sense, but hopefully you got my point.
-- FWIW: Interviewed here about a year ago - interview process was by far one of the better ones - their community guy Jason was super super kind & their CEO seems to also be a really good human --
I've been using the self hosted version with a 10-person team for a year now and so far we like it. It's not as good as Slack (yet), but if you need to self-host, I can absolutely recommend it.
Slack was fine for our team of ~10, but frequently blocked by Chinese great firewall, and overall experience was slow. We moved to a free self-hosted Mattermost instance and been using it for a better part of a year. Conversations are fast, we own our data, and there is no looming 10000 messages limit all the time. Bleve search is working just fine for us as well. Win!
Mattermost is an amazing product with a few quirks:
* it is hard to set up any kind of integration with a TUI: `matterircd` is quite buggy and also eats the CPU like there is no tomorrow, `matterbridge` doesn't sync correctly, or at least we couldn't make it work, and `matterhorn` is a standalone product (which would be much nicer as an e.g. weechat module) trying too hard to look like a web UI;
* web UI is still being polished, e.g. if you connection is unstable, web UI websocket is going to behave badly, requiring frequent refreshes to not miss any messages, or it still doesn't scroll to bottom sometimes on new messages, this has been the case since v.4.x and we're now on v.7;
* what I think is different from Slack is that threaded responses are shown in the main channel as well, and if there are many threads it is the same mess as if there were no threads at all :D
* somewhere around v.6 update the Focalboard push was a bit jarring, thankfully after disabling the plugin it disappeared for good.
Keep up the good work! Once our org is larger and requires Enterprise features, I'm pretty sure we stick with Mattermost.
> web UI websocket is going to behave badly, requiring frequent refreshes to not miss any messages, or it still doesn't scroll to bottom sometimes on new messages, this has been the case since v.4.x and we're now on v.7;
That shouldn't be the case with 7.0. We recently released a feature called "reliable websockets" that makes a connection reliable across websocket disconnects. If you have any repro steps, please feel free to create an issue and we will take a look.
> what I think is different from Slack is that threaded responses are shown in the main channel as well, and if there are many threads it is the same mess as if there were no threads at all :D
It does work, but doesn't shine in any aspect. Android app can't keep a connection alive, media embeds are wonky, unicode filename support is wonky, it stutters in many places.
Element and Matrix are better, no joke. Plus you get E2E and federation.
I've run a Mattermost installation off the cheapest Digital Ocean droplet for about 4 years. Moved away from Slack due to the 10k message limit and the fact that I could self-host it.
Unfortunately, while it does keep your history, the search is pretty lousy (there is a better search available for paying customers) and you can't export private conversations (unless you pay them).
They gotta make money, and I'm not paying them, so I understand withholding features. That said, I keep looking at the Matrix ecosystem, and I think the only thing keeping me at MM is the switching cost at this point (not being able to export messages is an effective lock-in feature, though rather user-unfriendly if you ask me).
That document shows how you can export private channels, but not private conversations. For example, if you and a friend have a DM conversation with each other, that is not exportable using that tool.
Search in SQL databases is a tough beast to get it right. And given that we support MySQL and Postgres both, it gets even harder to support quirks of both of them.
In enterprise editions, the only addition is Elasticsearch. But in our open-source version, we do have support for https://github.com/blevesearch/bleve. Although, it's in beta, we have a lot of customers using it.
I am wondering if you have tried using it and didn't like it?
Reminder that Mattermost's f/oss self-hosted version embeds segment.io phone-home spyware on by default which must be disabled with a barely-documented env var (called "diagnostics").
Every config setting has an equivalent env var option.
You can either use an env var,
or change the setting via system console,
or directly change your config.json file - LogSettings.EnableDiagnostics = false.
Yep, our self hosted Focalboard server works with multiple users. I had a bit of trouble figuring out that the share link is used to trigger the set up of additional users. I was initially looking for a link labeled "create account" or similar. I've been really happy with it and love its simplicity.
> The first user registration will always be permitted, but subsequent registrations will require an invite link which includes a code. You can invite additional users by clicking on your username in the top left, then selecting “Invite users”.
Our FOSS community uses it, and we're quite happy. We were on IRC before, maybe 20 users, and now we have hundreds of active users on Mattermost.
Our biggest struggle is with support within our community. Helping someone is nice, but odds are that someone else has the same question and losing their mind with Google. Mattermost does not provide a good way to archive topics. We push people to use our Gitlab or Stack Exchange for support, but both are hostile in their own way (not newbie-frienfly). Anyways, something there might do wonders. Maybe some kind of tool that lists popular threads on a public page?
Another wishlist would be to be able to hide or block people. While we do our best to be friendly, there are just some people that I get really annoyed when they PM me, and some others that I just don't want to see their comments in public channels (kind of like hidden tweets that you have to click to show them).
My team piloted using Mattermost for a bit. It was great. People were always quick to respond. Lots of fun was mixed in with work topics. Then my company went MS Teams everywhere. And it's just not as fun or useful. Something about the UI just makes people interact less.
We've been testing out both Mattermost and Zulip over the past few months at work, and we recently decided to go with Zulip.
Mattermost is nice in that communication and project management is all in one tool, but doing anything within Mattermost is very sluggish (even on a very overspecced server with only 1 Mattermost user online). Using their Focalboard plugin resulted in multiple seconds of wait time between various actions like modifying a task. On the other hand, Zulip has been consistently snappy even as we've onboarded users onto our instance. Seeing it in use at large organizations such as Rust's Zulip instance instilled confidence that it'll continue to perform well even well beyond our scale.
Also Zulip's threading model is really nice to use once you and your team gets the hang of topic separation. We've managed to completely eliminate 'talking over one another' as we would in Slack/Discord style text channels, and it's much easier to keep track of various conversations. While Zulip's UI and UX isn't as polished and certainly has areas for improvement, the threading model alone makes it worthwhile to use.
On top of that, Mattermost's pricing doesn't work well for small businesses, especially when you factor in that something 'simple' like Elasticsearch support, or, performance monitoring tools to figure out why your 1 user installation on a 88 thread server with hundreds of GBs of memory is sluggish, or even just creating a second admin user is locked behind their enterprise plan.
I get that money needs to be made, but blocking some features behind an enterprise plan (that asks you to contact them for pricing, no less - their $10/user for the Professional plan is not only steep, but still doesn't include these features) doesn't feel great. Zulip is completely free, and offers Zulip Cloud alongside a support plan, but does not block any features behind a paywall. There's no limitations on what Zulip will let you do either - no 10,000 message history limit, no file storage limit, user role restrictions, or anything of that nature.
Oh, and Zulip is 100% open source software. In my eyes, it's hard to compete with that when it comes to communication tools.
Yeah, thanks for nailing it to me that I picked Mattermost as our chat-server 3 years ago, now we have to migrate away from it since it's way too expensive. They also do some seriosuly dubious decisions when it comes to the gimped opensource-variant, so. Thanks, but no thanks.
I run a personal Mattermost server for family communication; its been great. If there was one complaint, and this is a nitpick, it is that the notification icon in Windows does not have enough contrast with the icon when no new messages are available.
Security isn't the same as privacy. Using Facebook you don't have privacy, but the platform containing your data isn't likely to be compromised (your account's password being guessed is the most likely method of compromise, and that's in your own hands).
Though I wonder if this distinction will go the way of the dodo / hacker / crypto, since a lot of people seem to not understand this in recent years (mostly since privacy became a bigger topic, first with Snowden but even more since GDPR enforced it). If the words privacy and security are both used to mean privacy in common language then we need a new word to communicate the previous meaning of "security". Kind of annoying when a language changes and existing words are redefined, but it's not as if an evolving language a new phenomenon.
> To answer some of the other questions on this thread, no customer logs nor PII get submitted to the 3rd party service that we use, which is called Descartes [...] We pass name and billing address only.
It was a problem sending the email to wrong accounts. The CEO states later in the thread that they don't track that kind of info from selfhosted instances.
It will happen a few days after somebody invents "the" programming language to use, "the" hiring process to use, "the" IDE to use, "the" development process to use, etc.
There are a variety of needs and use-cases, so "the" doesn't make sense. Look at what your situation needs and see which tool is the best for you. You don't need to use a certain brand of tool just because everybody else is.
"There are a variety of needs and use-cases, so "the" doesn't make sense."
That's very true, however i view those services the same way i view communication services like Slack. Eventually most users are just going to flock to what everyone uses by default and that's it. But i sure do wait for the day that special somebody makes "the IDE" to use!
