How does the open-sourcing of Zulip affect ambitions for Mattermost?

Troubleshooting
1

I’ve been evaluating Mattermost for several teams and playing around with it on some some devel environments. I haven’t pushed heavily for adoption yet but was leaning that direction. I have some teams that are just starting that I don’t want to get stuck inside Slack or another proprietary system and a few others already there that may migrate someday. The rapid development as well as clear coding practices and workflow have suggested to me that Mattermost is the most promising open-source team chat system out there.

That idea was recently shaken by the unexpected open-sourcing of Zulip. I had seen that system before but wrote it off as just another walled garden. Now they have open sourced the entire stack including front end, back end, native mobile apps, etc. This is significant stuff.

Now my question is where does this put Mattermost? No longer at the top of the maturity stack as far as open source options are concerned…Zulip has been around a bit longer and is built out a lot further as far as features go. Native mobile apps and working integrations are really attractive to me right now.

Has the Mattermost crew evaluated tha source code base? Is there anything useful there to jump start Mattermost efforts? Is there any adjustment to the vision as far as what audience is going to be most targeted? Have feature priorities changed with a new player in the space? Has anybody else evaluated the pros and cons of Zulip, how hackable the code is going to be, how likely it is to see organized advancement from this point on, etc.?

2

Hi @alerque,

Thanks for the question,

Our focus for Mattermost is being a “self-hosted Slack-alternative”, which we think is different than other approaches we’ve seen,

Self-hosted means making it easy for IT admins to deploy and manage Mattermost in a data center. So features like having a compiled binary to drop in and run, a System Console UI to administer the system from the web after the initial install–changing config settings, bringing up logs, moving across multiple teams to manage user roles, reset passwords, setup SSO, etc.

Slack-alternative is about helping users migrating from a proprietary SaaS service to an open source, on-prem solution. There are a few parts here:

  1. The first is supporting import from Slack to Mattermost, which is about moving Slack accounts, theme colors, and public channel history to Mattermost, so there’s a clear starting point.

  2. The second is offering parity with key Slack features–such as adding native clients for mobile and desktop in upcoming Mattermost releases. Parity is the antidote to lock-in.

  3. The third is being “Slack compatible, not Slack-limited”, which is about Mattermost supporting what Slack users expect, but then offering more than Slack is willing to provide (via features driven by community feedback).

For example, in the Mattermost webhooks functionality that’s shipping in v1.1 auto-translates webhook requests in Slack’s proprietary format over to markdown (Slack-compatible), but then supports tables, inline images and other advanced formatting features via webhooks that Slack doesn’t (not Slack-limited). Other features coming will expand on this.

Some screenshots from recent Mattermost v1.0 release as examples of what’s mentioned above:

Regarding Zulip, we looked into it briefly when it was announced, but that review didn’t really change our existing roadmap or thinking.

We’re much more focused on hearing what users are asking for across the Mattermost community.

Speaking of which, if you’d like to discuss further, we’ve got a test instance setup to run Mattermost v1.1 RC2 next week, so please considering joining and continuing the discussion there?

Test instance is on v1.0 right now, but we’ll push RC2 some time on Tuesday to get feedback.

1 Like
3

Looking at Tulip, to me, for now, the only advantage it has over Mattermost is the Apps already available. Also I think that the integration with GitLab (opening room for tickets, reporting actions to channels, etc) would make it more useful.

4

From what I say is that the GitLab dependency is really a setback. It is a dependency that must be managed. GitLab has more dependencies on its own. One is Go, another is Ruby - and yes, this is irritating.

So, from a real use case, Zulip and Let’s Chat start to look better alternatives as they do not have a BIG dependency just to have an OAuth feature for example.

This is a little sad, hope that this will change in near future.

5

There’s absolutely no dependency in Mattermost on GitLab. It can be used through the GitLab omnibus install, but there’s no requirement for this.

Here’s the installation guide for a Mattermost-only deployment - as you can see there’s no mention of Ruby or Go - so your irritations should be gone! :smile:

6

we test first zulip, and was and a pain in the ass the instalation … at the end we using mattermost!