Story of Mattermost: Open-Sourced Competitor to Slack | Hacker News Reader

Story of Mattermost: Open-Sourced Competitor to Slack

breakoutstartups.substack.com

395 pointsankitkumar98241 comments

The open-source Mattermost intentionally lacks a couple of pieces of basic functionality to push you to pay, like the ability to stop regular users from deleting channels, and no way to set a reasonable password policy that requires more than 5 characters.

Mattermost (and specifically their CEO, who is vigorously replying to messages on this thread, but probably won’t engage with this one) haven’t responded positively to requests to include these basic features:

https://github.com/mattermost/mattermost-server/issues/6320

https://github.com/mattermost/mattermost-server/issues/5935

As far as I’m concerned, Mattermost isn’t any kind of a competitor to free-tier Slack until these issues are resolved. This exact thing has turned more than one team I’m on away from Mattermost.

This is, fundamentally, the Open Core business plan, which Mattermost is executing quite successfully. You get all the marketing benefits of being "open source", but few IT departments will use your software in production without buying the enterprise license, so you get most of the revenue you'd have had if you were closed source.

Folks have different perspectives on Open Core. It's definitely a lot better from a freedom perspective than proprietary software, so I don't want to be too down on it. But it isn't really FOSS, and I think the difference is important, which is why Zulip is following the commercially more difficult path of 100% FOSS. Even obviously enterprise features developed entirely by our paid team, like SAML authentication are FOSS, and our plan is for it to remain that way forever.

It's commercially more difficult because it means right now we have users at governments and Fortune 500 companies and whatnot who've reached out to tell us they how much they love Zulip, but nonetheless aren't paying us anything. On the flipside, Zulip has been very successful in building a large community of volunteer major contributors (some handy stats are in our release blog posts, e.g. last week's https://blog.zulip.org/2019/12/13/zulip-2-1-released/). I don't think that would have happened had we taken Mattermost's aggressively Open Core approach..

(I lead the Zulip project and company)

I really hope this model works out for you, I absolutely adore Zulip. At my company, we have the option of self-hosting, since you've made it so easy, but I intentionally keep us on the free plan so we can start paying when we can afford it, to support you.

Zulip is one of the few pieces of software that I think are unquestionably worth their price (some others being Gitlab and some sort of SIP provider, e.g. OnSIP).

Mattermost CEO here,

Thanks for the feedback, replies on both issues posted:

https://github.com/mattermost/mattermost-server/issues/6320

https://github.com/mattermost/mattermost-server/issues/5935

Please let us know what y'all think?

The password policy was added to Team Edition back in June, 2018.

>Mattermost isn’t any kind of a competitor to free-tier Slack

Mattermost isn't intended to compete with Slack's free tier.

The open source version of Mattermost is focused on software builders and operators who want a flexible, open, collaboration platform that works with their tools and workflows. Here's more on Mattermost Chatops as an example: https://mattermost.com/blog/introducing-mattermost-chatops/

Very often we're deployed in high security environments and private clouds where internet-based services can't easily go.

I can't really tell for the github issues you posted what was done about these two issues.

I don't really feel like reading all that just to figure it out.

Did you resolve both of the issues brought up by OP or not?

(Answering: "The password policy was added to Team Edition back in June, 2018.", isn't the same as answering, "the free tier allows passwords of length >5 characters.")

Sorry about that. Thanks for the feedback. It is very helpful. Trying again:

1) Enforcing password requirements for end users was put in free tier last year - Here's why, with a link on how to use it: https://github.com/mattermost/mattermost-server/issues/5935#...

2) Non-admins are still able to archive channels they belong to but did not create - Here's why: https://github.com/mattermost/mattermost-server/issues/6320#...

3) I need to work on speaking more concisely, here is another version of #2 from an HN user who puts things more simply: https://news.ycombinator.com/item?id=21824219

Does this help?

Sure, thanks! I'm not panning you or your product.

I'd love for there to be a viable alternative to slack that is more (if not entirely) open.

As I’m reading it, Mattermost (as source) is released under the AGPL, which makes it both legal and ethical (indeed, they have explicitly consented to allow you to distribute modifications) to stub out all the license checking and enable all of the enterprise functionality without any payments, tracking, or phone-home.

It seems to me this is the point of free/open source software: anyone can improve it and make it more functional and distribute those improvements. The first logical improvement, to me, is removing the unnecessary license checks that disable useful features of the software.

https://github.com/mattermost/mattermost-server/blob/master/...

Yep, and this is why the AGPL is not for protecting your IP, only for ensuring that the code remains open forever.

I believe they store the enterprise specific code in another git repo that has to be checked out, for one (from reading their Makefile).

The binaries they release (including that code) are MIT licensed according to their readme, which means that modifying those should also be no problem.

This is true, you could probably edit out the publickey and then generate your own license pretty easily.

It is legal and ethical to remove the parts you don’t like, but that doesn’t mean you shouldn’t pay for it. You’re not required to, but if you find it useful you could consider it a donation.

Regular users cannot delete other people's posts and channels, but they can indeed archive any public channel.

I run a mattermost server for a Free Software project. We have over 2000 users, but around 300 monthly active users, 100 daily. I worry about it sometimes, but trolling in our community is pretty rare.

> Mattermost (and specifically their CEO, who is vigorously replying to messages on this thread, but probably won’t engage with this one) [emphasis mine]

Aside from being wrong, this seems needlessly argumentative and rude.

Now that I read my comment again, it is clear that I was being more inflammatory than was necessary.

Thank you for calling me on it.

(As an aside, this is one of my highest upvoted comments ever, which perhaps says something about what gets internet points on HN.)

In my experience, the competition is pidgin slash outlook communicator slash whatever brain dead enterprise messaging app. Not slack (or hipchat or...). Mattermost has seen a lot of adoption atthe Big Dumb Corps I’ve seen.

That’s my take on the market at least. I’d buy stock in it if I could.

The open-source version also lack any data retention option, meaning that your only option is to let the database grow indefinitely; you can manually delete stuff from the db, but last time I've checked that was not recommended.

Deploying Mattermost is not ideal, as the server requires write access to its JSON configuration file and will overwrite it from time to time, which makes using any configuration manager pointless: after upgrading mattermost you have to fetch the "updated" configuration file from your server and import it back into your configuration manager (and since it's JSON you might get different key sorting and indentation offset).

Despite the above I like Mattermost and I've been regularly using it for more than 1 year, basically for free.

In 5.10 Mattermost added the ability to move the configuration to the database, which solves the issue of having a config.json file. This also has the advantage of versioning your configuration in the database which makes rolling back changes very easy.

FWIW, Restya seems to be coming up with another Jira & Slack alternative https://restya.com/core-jira-slack-alternative Looks like it will also be an open source

If there is enough interest, we at polyglot.network can add those missing functionalities and maintain that fork. We have already done the same for certain other OSS software as enhancing open-source software for paying corporate clients IS our business model.

I know of a place that tried Mattermost, realized it was crappy demoware (their words, not mine), and dumped it for another solution.

It doesn't really have a place even doing open source works (no real controls), nor in the corporate world... unless you pay.

I have to agree with their assessment of demoware.

Another one, if you want your free local instalation to be able to push notifications to your mobile app it needs to go through their http (non-https) proxy. At this point this might be more damaging than not providing the option at all.

You can set it to push only that a message was sent, redacting the user/channel and content.

Well, then there is even more open sourced alternative than Mattermost: https://github.com/tinode/chat

It looks like somebody has engaged in those issues over there. Probably because of this comment.

disable the endpoint in your reverse proxy

use sso/ldap/ad (paid?) etc

Yeah. But. https://github.com/mattermost/mattermost-server/issues/6320 Non-admins can delete/archive any channel #6320

What's more disturbing than the bug itself is the Mattermost team's response that this behavior is intentional for the free "team edition" of their software, and that "actually, I think the bug is that we should not be showing Channel Admin as a role in Team Edition" (i.e, users of the free edition don't get any kind of access controls, making it impractical to use outside a small group of trusted users).

Potentially controversial opinion: This isn't really open source. When major features like permissions and access controls are stripped from the "community" version of a software package, it starts looking more like a feature-limited demo.

I think "all team members are admins" is more usable than you think it is; I generally do this for many cloud services on most of my teams even at my day job; it's just not worth spending time dealing with access control, setting it up, and then someone who can't do what they need to do for their job cause you didn't give them enough access, or the only person who can do what needs done is on vacation, etc.

I often say "We don't have (or use the) locks on our doors at our physical individual offices, but that doesn't mean any of us would go into someone elses office when they aren't there and trash everything on their desk. And it's not a problem. What makes electronic resources different?" [I know HN audience will now give me an exhaustive list of what makes electronic resources different; please don't bother; I know this approach doesn't always work. With physical offices either].

But I agree with you that that level of feature-crippling makes me want to all it more like demoware than open source.

"Everyone is an admin" might be usable for some small teams, but it makes the software absolutely unusable for any sort of public project -- like open-source developers, or public communities. It really makes it clear that the primary purpose of the "team edition" is to drive sales of the commercial product, not to be usable in its own right.

Yeah, that seems right.

It works well for companies where there’s typically recourse in company policy to deal politics and bullying.

For communities, especially those that are open, this model often fails as soon as one bad actor comes along because there’s often no recourse against bad behaviour.

Unfortunately for Mattermost, it’s communities that are less likely to be able to pay, and more likely to be affected by this policy. That just feels like poor policy making.

> it's just not worth spending time dealing with access control

Until one day, when you have some sort of incident, and it will have become very worth your while to "deal with" access control.

So, at your workplace, do you put unpickable locks on everyone's individual office door and enforce a policy that all doors are locked when not occupied (or heck even when occupied), so you won't have to "deal with" some insane coworker trashing someone elses office? How about tracking of who is in the bathroom when, with camera monitoring, so you can deal with it in case someone smears their poop on the walls?

You are joking, right?

Laptops and physical property are one thing. But your digital empire of customer data is another. Encryption, MFA, inactivity based locking, access controls, and the principle of least privilege helps ensure that when something inevitably does happen, the blast radius is contained.

I don't really care if someone were to smash the hell out of the office. Laptops are locked. Data is encrypted. That's why in fact we have insurance.

But a disgruntled or even careless employee could irreversibly damage an enterprise by letting happen (or deliberately causing) a data breach. All because the org didn't want to bother "dealing with" access controls.

Way more likely that someone presses that delete button in a temporary tantrum or by mistake than a coworker randomly trashing someone else's office (there are telling signs after all).

It's also way easier, cheaper and practical to prevent the first example than the second one.

Your employees may not be the problem. But their accounts with brute-forced passwords or shared credentials will be a problem once a 3rd party finds out.

Of course it's more useful, it's more useful to team members and to malicious users alike, but it's not useful for passing security audits and certifications.

It’s entirely broken for any open source community, which is pretty telling.

> Potentially controversial opinion: This isn't really open source.

I know you were looking for this but I don't agree. Let's remind that Open Source fundamentally means _no expectations_. No expectations of support, no expectations of features, not even expectations of goodwill. Whenever a company complains that this or that open-source software doesn't work as expected and should do this, we all shout in chorus "this is open source, take it or leave it". This is exactly the same case here. I know it's frustrating because the feature exists in a fork that happens to be run by the same people, but that is exactly what is permitted by this license.

Does anyone here complain that SQLite isn't _exactly_ open source because they don't ship their full test suite in the open source package (https://www.sqlite.org/th3.html), even though each release passes it ?

> Let's remind that Open Source fundamentally means _no expectations_.

No. Open Source, as defined, is about what the end user is allowed to do with the code they have. That’s it. What you describe is common, but not inherent. There are plenty of exceptions, like if you get Red Hat, you’ll get to have plenty of expectations, and Red Hat is still Open Source.

Please stop the ancient FUD about Open Source means having no support.

When I say open source means no expectations of support I obviously talk about the license the software comes with, not the overall idea and goals that are common in the open source world.

You want support! Great, it exists and can even provided by multiple different actors, with or without expected quality of service, and that's great! But that is not included in the license, you have to find another arrangement on the side. Maybe you can ask nicely and they will do it for free, maybe they'll ask you to pay them in beers, maybe they'll ask for a specific contract detailing everything. Same goes with features, you can ask for new ones but that is not part of the license. That's it, that's all my message was about.

> But that is not included in the license

No license includes anything like that. That’s not what a software license is.

Right, open source, like all software, has a variety of vectors of usability and suitability. Purposefully leaving out features weakens it along some vectors - especially the "I want to modify software I run in production" vector.

I think you'll find all you need to do is compile with `BUILD_TYPE_NAME=enterprise make`, and suddenly all features appear. Whats peoples moral position on opensourcing the features but not including them in pre-built images unless you pay?

Moral? I'm not seeing one.

I think it's a clever way to support free and open source projects. Free edition is for everyone, trials, demos, etc. Paid enterprise version is for companies that are happy to pay to get some extra value. Build it yourself enterprise version is for people who don't want to pay, people that get less value from the product than the price, hobbyists, etc.

Caddy (a web server) used to do something similar.

> This isn't really open source.

The usual term for it is “Open Core”, and is a legitimate, if frowned upon by many, practice:

https://en.wikipedia.org/wiki/Open-core_model

AFAIK, even the enterprise features of Mattermost are f/oss (agpl) and the license checks can simply be stubbed out if you don’t like them.

They're doing it wrong. There are many successful, profitable companies making open source products with a subset of the features that their commercial offerings have. These guys are intentionally crippling the open source offering. It's practically a bait and switch.

The right way is to release an open source product that is full-featured and robust, and upsell things like support, managed hosting, and the kind of plugins and addons that primarily appeal to enterprise customers (although increasingly the latter are indistinguishable from advanced small users).

What you're describing sounds similar to crippleware.

https://en.m.wikipedia.org/wiki/Crippleware

not sure that's pc buddy

I am sure that it's a fine piece of language to use, particularly in this context.

Fair point, thanks

> more like a feature-limited demo.

demoware

Shareware is making a comeback?

It's worse than that, expectation are different and actually doing disservice to the whole open source ethos. I recently heard a couple of regular users talking and equating Free Software//Open Source with Freeware, I didn't bother correcting them because from their perspective the difference is meaningless. Only us geeks care enough, but not enough to go and fork it.

Mattermost CEO here,

Thanks for highlighting this. It's a ticket from two years ago and this thread is a good opportunity to share more of the context and intention of how we think about Team Edition vs Enterprise Edition.

I've shared a reply on the ticket here: https://github.com/mattermost/mattermost-server/issues/6320#...

Also, I don't know if the ticket title is highly accurate--a non-admin can't delete any channel:

1) There is no "Delete Channel" in the UI only "Archive Channel"

2) A non-admin cannot archive any channel, only channels of which they are a member.

3) A non-admin archiving a channel they created is not really an issue, so this ticket is really about a "Non-admin can archive a channel which they are a member of but didn't create" which we've seen can be more helpful than harmful--when someone leaves a team and their out-of-date channels remains anyone can go and archive them without having to find an admin and make a request.

The current wording sounds like non-admins can delete private channels, channels on different teams, channels they're not part of, etc. and in my mind it's not the case. But perhaps other people have a different read?

I think the concern here is a pre-emptive rage-quit of channels. A team member is aware they are about to be let go, and decide to archive every channel they are a part of on the way out.

What controls are in place to prevent this from happening in the Team Edition?

Archiving a channel in Mattermost just sets a flag in the database. Once the bad actor is removed a simple query can restore the channels they archived. Something like: `UPDATE Channels SET DeleteAt = 0 WHERE DeleteAt > [some timestamp]`

There's also a CLI command to restore the channels. While this won't keep it from happening it should get things back to normal fairly quickly.

Wow this is crazy. So the free edition of Mattermost has even less access control functionality than Facebook Messenger? Disappointing.

It seems to me that "open source" is now being used as a marketing label for what used to be known as "shareware" or "trial". You get a trial version of the software (but where you can see the code) and the big essential features you need to pay for.

Open source no longer means what it used to mean.

And for the CEO to join in that ticket discussion and say "yeah it's a bug - there shouldn't be channel admins at all in the free version" basically confirms this.

Don't complain it's missing features! Make them yourself ... but we'll just steal them if they're better than the paid version because hey, open source!

there is a good comment/response by the co-founder of mattermost at https://rolfje.wordpress.com/2017/10/26/mattermost-delete-ch... (scroll to the end of post for the comments)

Not a great comment, in my opinion. He does nothing to address the artificial neutering of the community edition, especially when compared to all the open source products that Mattermost uses - as the blog post author's response sets out.

Why is artificial neutering unethical? What’s wrong with it? Change the code yourself or pay the guy. 99% of software only gives you the second option.

The best comment was the guy who said he fixed all these issues by installing matrix/riot :)

When I checked mattermost a year ago, the mattermost opensource edition had no basic permissions/access control. Any user could archive any channel. I have seen many teams fall into this "trap" only to find this basic restriction later. We since moved to Rocket.Chat. Is this still the case?

That restriction aside, how do you compare rocket chat to mattermost? Is it better?

You can create private channels in MatterMost for as long as I can remember.

But are there access controls other than private channels?

I'm trying to push the agenda to switch our comms between developers fully to Keybase, but it will be probably rejected.

Keybase is.. not ready for prime time. It's pretty janky, channel discovery is a pain as is spam, and it's still got that weird crypto half-baked nonsense.

Team discovery could be a pain, but channel discovery within a team is pretty much everything I would expect it to be.

Be the change! https://github.com/mattermost/mattermost-server

Access control is intentionally missing from the open source "team" version:

> Team Edition is "virtual office" where a team works together as trusted colleagues. It means people can walk anywhere they want, and move the furniture if they choose.

> I need to ask this ticket be closed since it's not a bug

> You're of course more than welcome to fork as well.

https://github.com/mattermost/mattermost-server/issues/6320

But would Mattermost accept a PR that cuts into the differentiation on "advanced access control" of their enterprise product? https://mattermost.com/pricing/

Open source is only as powerful as the community's willingness to maintain a fork.

I have a small team, but about a year ago, we deployed Mattermost on our K8s cluster using their Helm chart and I have been very pleased with the performance and stability. We never looked back at slack. I have not had to fiddle with the configuration at all since deploying it. It just works. And that is also considering that to save costs, I launched it on preemptible instances which go down usually once every 24 hours. Mattermost recovers and reboots flawlessly every time.

I had similar needs. I don't like that telemetry is on by default and you can only disable it by manually editing the config JSON (whilst service's stopped). I have encountered bugs in past versions but nothing recent stands out. Having full control of our data, unlimited history, slack-compatible integrations with 3rd party notification services and our own, easy upgrades, and no downtime when Internet's out (in-office server) has been great. Overall a positive experience.

Did you do any integrations for voice chat?

Mattermost CEO here, Zoom plug-in is built in so one click for starting a Zoom meeting. There is also some voice features in our latest hackathon: https://mattermost.com/blog/mattermost-hackathon-2019-highli... (see mobile apps section).

Where either of these what you were interested in?

Hi, Mattermost PM here. We also have other voice, video and screenshare integrations, including self-hosted on-prem and private cloud options. Zoom, Webex, BigBlueButton, WebRTC and more: https://docs.mattermost.com/deployment/video-and-audio-calli...

Cool, thank you both. I think WebRTC or Jitsi are closest to what I would be looking for, as I want to keep it open source, but I appreciate the Zoom and other integrations for how they could be useful to business.

You guys might consider Mumble/Murmur integration, I think it could be a great addition, as it was my favorite voice app before Discord took over everything (still is).

Jitsi is WebRTC as well :)

Mattermost CEO here,

Fantastic! Thanks for sharing back--comments like this are super motivating for everyone working on the project,

Good to hear!

I'll add that the only issues I came across were from a few users who didn't like the mobile client as well as Slack. I would chalk most of that up to them simply being used to Slack.

But I think Mattermost could still use a little bit more polish (as pretty much all software could) when it comes to the clients. I hope you guys don't lose focus on that. I would much rather have a progressively better user experience than one more widget integration that most won't use anyway.

The biggest problem with Mattermost is that the mobile client cannot connect to multiple teams. You can add the beta client and connect to a second team, but more than two teams is impossible. This may be a function of living in the Bay Area but I'm on 4 or 5 different Slack groups for various communities.

All but my employer would be in great shape to switch to Mattermost but it's just not possible. Some have switched to Discourse but it's not great for real-time communication and people have a hard time with the UI.

Thanks sjburt, Mattermost CEO here. We have 800+ upvotes that agree with you, here a link to the feature proposal forum post and open tickets on this: https://mattermost.uservoice.com/forums/306457-general/sugge...

Anyone interested in contributing to the work, we’d welcome your help

The ticket you linked to said the feature is “planned”, so I’m not sure what you mean when you say you’d welcome help. Are you working on this internally (and as such this is essentially a “we’re looking for mobile engineers”) or are you soliciting contributions from the open source community to work on this?

Ticket is unscheduled, work is open source, if you're interested in contributing please comment on the ticket and the team can discuss: https://mattermost.atlassian.net/browse/MM-11067

On hiring, yes, we're hiring too, that's perhaps the most committed route to take: https://mattermost.com/careers/

What about zulip? They seem to fare well in terms of features against slack and mattermost.

After trying all, I prefer zulip over all (including slack).

It is very polished, functional and easy to write extensions for! It is slightly annoying that I feel like none of these will last a decade and wonder why we couldn't have stuck with XMPP or an extended standard and figure out federation, privacy and enterprise.

Unfortunately, outside of tech, everyone is moving to Teams!

> Unfortunately, outside of tech, everyone is moving to Teams!

Alternate perspective: they never left Lync/Communicator - it's just been rebranded.

The Rust core dev teams are using Zulip extensively. It must be going well enough or they'd have moved onto something else. Instead, adoption has grown.

I absolutely love Zulip. I use it for a company team and it's been amazing. The stream model where you can zoom in is extremely convenient for catching up with messages and we love how well everything works.

I do miss GIFs, but eh.

We weren't too happy with Mattermost and moved to Zulip after a while at my place.. it's a bit nicer, but I'd still pick IRC if given the choice.

I love Zulip but the concept of topics is repelant for (lazy?) users.

When you chat on a channel (Slack, Mattermost) and people start fragmenting the discussion into several topics that interlace... Ugh! I yet have to meet people that would at last utilize Threads.

> When you chat on a channel (Slack, Mattermost) and people start fragmenting the discussion into several topics that interlace... Ugh! I yet have to meet people that would at last utilize Threads.

Slack threads are an utter abomination. I'd rather they removed the feature entirely; they're harder to keep track of than the linear stream of a channel (which is saying something, because the chronological, linear stream is already pretty bad for ongoing discussions)

I've tried both and imo mattermost has the edge when it comes to hooks and integrations. It's also insanely flexible with the configuration options it gives. The one thing I don't like about zulip topics... Not really my thing...

Zulip topics are the best implementation of chat threads that I've seen yet. You can view all of them simultaneously like a regular chat room, or focus down on one. You can mute either a single chat topic or an entire stream (channel). In most chat systems, if I don't read the messages within a day, I'll never bother reading the chat history because I have no idea whether there's anything relevant in it. In contrast, I can open the Rust Zulip once every few weeks and see if there were any interesting topics.

And if you're really sure you don't want to use topics, you can always just make a single "general" topic in your stream.

We went Skype => Slack => MS Teams => Mattermost for our developers. If Teams wasn't such garbage at basic things like markup and pasting screenshots, we might still be using it for everything.

I had no real concerns with Slack from a development perspective. We simply wanted to try a unified messaging platform for the whole enterprise (our non-developers much prefer Teams/Skype for some reason). That experiment failed for our developers, so we now maintain 2 stacks - Teams for company-wide communications, and Mattermost for developer-intensive communications (or anyone else willing to teach themselves how to use a new thing).

Mattermost has proven to be an incredible solution for our development duties. I just installed it directly on a EC2 t3.small instance and we've been using it for about 9 months now without any pain points to speak of. I literally haven't touched that machine since I turned it on day 1. To be fair, we are <10 developers, but we get pretty heavy with the screenshots and json/code dumps throughout the day. We did make some compromises with authentication in favor of expediency of deployment, but it's really not a big deal for our developers to keep track of their LDAP vs their mattermost credentials. If someone complains enough I'll spend a few hours to hook up LDAP too.

So - non-developers resisted Slack or Slack-like things?

That's interesting. I'm a developer but I find it easy to empathize with non-developers because I hate any tech orthogonal to the actual task at hand that requires a learning curve. I usually find that other things have pushed that thing out of my brain by the time I have to use it again.

Unlike most developers I'm no fan of Markdown (I can manage links and list formatting in a WYSIWIG editor without needing to reach for the docs. I hate reading docs).

I've got the hang of Slack but I tire of teaching new adopters the correct etiquette and usage that means they don't overly interrupt those of us that have tuned their notifications. Or teaching people how to ensure their messages aren't missed entirely.

I share some of your resentment for having to learn new things to engage in what is arguably a trivial activity at this point in time - sharing (formatted) text or other media with your teammates. This is probably a factor in why many of our users prefer "simpler" approaches... At least from their perspective. One would argue markdown is simpler and faster than using any MS Word-style interface if you are experienced in its syntax and rules.

Learning markdown is pretty easy for many developers, and for some it becomes 2nd nature when typing into things that support it on a regular basis: Git[Hub/Lab], Slack, Mattermost, WhatsApp (partial support), etc. The value-add as you put additional markdown-enabled platforms into your workflow is pretty substantial. I don't have to do a mental context switch every time I go between editing a GitHub issue comment and typing some code block to another developer in Mattermost.

You can create some really nice looking README.md files if you spend a little extra time with things like headings and quote/code blocks. I believe there are several options (one hosted in GitHub's API if you prefer GFM) for taking MD files and generating high-quality HTML or PDF output.

I'd conclude by saying that markdown documents are much easier to source control. Taking a diff of a docx or a pdf is going to get you nowhere. A diff of a markdown file might as well just be a diff of any arbitrary plain text document. The syntax itself has a very small footprint, so you are looking at mostly just plain text minus 5-10% overhead on the markdown.

Slack doesn’t actually do Markdown; it’s just a little bit ahead of what Hacker News offers. And diffing PDFs and Word Documents is possible, but annoying: you need a custom diff tool for it that you integrate with Git.

In our company we are the test team for MS TEAMS. Short but honest. MS TEAMS is a real mess. I have no idea why MS let this software going public like this. Does anybody think that's a good piece of software?

> Does anybody think that's a good piece of software?

only if you haven't tried slack.

What's the reasoning behind no updates?

Love the fact people are adopting Opensource solutions but corporates won’t budge. I think the hardest penetration for anyone right now is Microsoft Teams. Since they started bundling teams with Office they have been able to boast about numbers and actually hurt Slack. I wonder what is roadmap for Mattermost. Shameless plug I myself did an opensource version of a chat server called raspchat https://github.com/maxpert/raspchat which was able to handle almost 5K very active chatters on a Raspberry Pi Model B (Just 512 MB of RAM). My original dream was to build a drop and run server on cheap raspberry pi for local areas but man has to feed his family and I had to make a tough choice. It’s harsh IMHO out there to get attention and then convince folks to develop integrations for you. I hope this space doesn’t endup with duopoly and products like Mattermost take off.

Mattermost CEO here,

Awesome work on raspchat! And thanks for the kind words.

Often we see users and customers have both Microsoft Teams for Office365 users and Mattermost as the "developer's choice" given the open source code base and flexibility in high security environments.

Per the article, the market is very large, and there's many different user segments to serve. Therefore there should be multiple winners here, in my mind. I think this category is only just starting.

In my org we have Teams and Slack (and Skype for Business!). Corporate (and our one token diehard Microsoft fanboy) gave a weak effort at pushing Teams, but everyone was already on one of the other two so for us Teams is just sitting on our computers like an appendix that's useless but also just enough effort to cut out that it stays in.

I have the inverse. The only thing _everyone_ is on is teams. Slack is too expensive and introducing yet another chat program is not going to be met with anything other than resistance.

I really dislike teams.

My response to someone insisting on using only Microsoft Teams is: What if Teams goes down? How is the IT team going to coordinate bringing it back up? Email? SMS?

Uber currently uses Mattermost but will most likely move to Slack. During my 2 years at Amazon, the SFO based Prime Now team used Mattermost but we were eventually forced to move to Chime a pitiful example of a chat client.

Mattermost CEO here, if Amazon is open to it, I’d love to see if there is a “Better together” story across AWS, Chime (meetings, voice, video, screen sharing) and Mattermost (developer, Ops and SRE workflows and integrations). We’ve heard the same from different Amazon teams looking to accelerate developer productivity

don't waste ur time they're pushing chime hard at Amazon lol

True, but everywhere else they are pushing Teams hard for general users.

Mattermost is already certified on Aurora, we work with S3, it's available in AWS Marketplace--if there's a dev team at Amazon interested in an open source alternative to Slack that runs natively on AWS infra--potentially connects with Chime for voice/video/meetings/screenshare it's potentially a healthy thing for everyone.

This space is downright awful.

20+ years ago corporate IT was concerned about the phone on my desk (how quaint).

They put one there on the back of a PBX.

They put in a system that was LOCAL for local needs and accessed the public network when it needed to.

It worked because it was built on the back of a proven standard (telephone).

We don't have a working chat standard, and it shows and we need to fix it.

> We don't have a working chat standard, and it shows and we need to fix it.

IRC works pretty well.

The only thing I sometimes miss is history, but... in some ways that's not a bad thing, and could be added without too much trouble.

Slack has history because Slack wants you to live in it. No history emphasizes that chat is ephemeral and something to tune in and out. Use email or something else for more permanent discussions.

> Use email or something else for more permanent discussions.

I don't actually agree with this. Email has hefty overhead per message. Chat allows for faster and easier communications, which does NOT mean you can't have a history. Indeed, history and search is the real selling point of Slack for me. Everything else Slack has over IRC is trivial and not worth abandoning the standards.

I didn't really feel the overhead of email until Gmail switched to their current theme. Now everything feels so sluggish and unwieldy that it really does constitute overhead, in real time seconds.

Whenever I used a native desktop software, like Thunderbird or Opera Mail, I was able to have conversations with people as quickly as in a chat client (and faster than texting, because of a real keyboard)

> Email has hefty overhead per message. Chat allows for faster and easier communications

I'm not sure I understand. Are you talking about the SMTP/LMTP format, or clients or what? If anything email lacks overhead - a proper thread meta data field that actually works across implantations (in-reply-to is a start, but not enough).

It's not like "xmpp overhead" made gräll unusable, is it?

> Email has hefty overhead per message.

I don't think that poster was talking about protocol innards, although kudos for you for having that knowledge, but perhaps they were, but in terms of user experience, slack/group chat is very low cost in terms of requiring any sort of mental pause before sending the message, specifically as a cost for the message itself. So much so, that a type of usage of verbal diarrhea can occur, so as to caution oneself against such usage, a little bit of thought before sending messages is always advised.

Specifically, if I can echo the primary differentiation, all you need to initiate a chat communication is a name and a message, that simplicity works a lot for people. I've used both e-mail and Slack, and a combination of both is great in my opinion, but the comparison can seen by an example message in my workflows (I don't use Slack anymore though):

Slack: 1) Find user/group by name lookup 2) Hi X, QUESTION_TEXT. 3) When done conversation, write outro

E-mail 1) Find user/group by name lookup, if user is not encoded in e-mail alias, query relevant databases 2) Write subject 3) Write intro, message, and outro

From my experience the reply from Slack 2) vs. E-mail 3) is much faster in the former case.

Interesting points. I suspect this is why chat is such a crap, low-throughput form communication; it's trivial for the sender to ship of a half-assed message - and very hard for the receiver to handle low-hundred conversations in a work-day - precisely because few(er) senders take the time to write a short, but dense message - and expect a reply-response dialogue "to quickly sort things out".

Which is much harder to both do in parallell and concurrently when busy with more than one snowflake problem at a time.

I'm sometimes shocked at how slowly things get done now, compared to when I worked a support desk in the early 2000s. But mostly I'm just a little sad at the overhead generated by chat.

> I suspect this is why chat is such a crap, low-throughput form communication; it's trivial for the sender to ship of a half-assed message

I think the crap is related to the amount of effort put into the message vs the medium. Making it easier/harder to send a message MIGHT change the quality, but I'd argue the decay of email over time was due to people failing to put in any effort DESPITE the minimum required.

I recall a coworker back in the late 90s talking about their usenet program, that made them click through a "Warning: What you are about to send will be read by thousands of people. Are you sure you want to send it?" message (paraphrased from memory). He found it daunting and therefore bad, I thought it was properly daunting.

I'd be interested to see the effects of using a retention policy[0] to discourage the use of chat as a be-all and end-all. IIRC some companies actually do this.

[0] https://slack.com/help/articles/203457187-Customize-message-...

When I worked as a stock trader, all of our chats were logged as a matter of legality.

I didn't mean technical overhead, I meant presentational overhead.

Email was fine, nay, great, for people to have extended group discussions in, so long as everyone was willing to follow some rules. Then Outlook plus the Eternal September came along and now everyone is reinventing quoting repeatedly (and poorly). Branching is a whole thing (or mostly, not a thing when it needs to be a thing). And we don't even need to discuss what happens to HTML in emails.

Chat allows for fast questions, fast responses. This makes it harder to have lengthy or broader discussions in. Neither of those, however, says that chat has to ephemeral while email is lasting, which was the point I was responding to. If you want chat+history, you can't swap out chat with email and say "there, now you can have a history" - you just changed a LOT of things.

Right, real-world email certainly has a lot of problems - mostly between keyboard and screen - and another large portion in boardrooms.

* made gtalk unusable.. (auto-correct on the other hand..)

You can front-end IRC with TheLounge [1] to get history and make some folks happy that prefer using a http client.

[1] - https://github.com/thelounge/thelounge

>Use email or something else for more permanent discussions.

That assumes that every discussion which eventually is important enough to be made permanent starts out that way. One of the nice things about a history-keeping chat is that the barrier to starting conversation is low, and the barrier for preserving that conversation is also low (i.e. nil).

That has a double benefit - anything that becomes important is automatically preserved, so you could have tuned it out at the time and later be able to come back to it. There's no need to always focus on a chat if it's guaranteed to saved for later, unlike with IRC, which you can't always risk tuning out.

Nearly every client I work with these days expires their email after N days, where N ranges from 90 days to a year. Even corporate email pretty much has little history any longer, and it won't be long before the chat systems also come under the same policies across most corporates.

I don't quite understand why history is such a big deal for US-based enterprise chat, when the consistent US trend has been to nerf internal communications history.

Not that I agree with this nerfing. It just causes people in my observations to inefficiently store and retrieve items of interest to them elsewhere, mostly into files.

email is just untenable for collaboration / discussion

That's not true though.

The Linux Kernel was built via email.

You can say you don't prefer it, but plenty of people have built some very big, complex projects via email.

We have XMPP for 1 to 1 messaging, IRC for group messaging and SMTP for store and forward messaging.

All are way easier to set up local instances of than setting up a PBX. The difference is that there was a whole lot of money to be made by installing and maintaining PBXes.There was no good way to monetize phone services by advertising or privacy violation. The equipment and trunk lines simply cost too much. Every PBX had proprietary phone sets, but the companies that made them could not get around the fact that the phone trunks were standardized by what was in the end a government enforced standard. So it was an example of forced federation of proprietary systems. It is interesting how well that worked.

We have a weird situation right now where the cheapness of communication is inhibiting standardization. Everyone can afford to do their own thing and fund it using super marginal revenue streams.

Funnily (or not) XMPP was designed to replace them all, at least functionally. Too bad there wasn't an XMPP champion pushing the development early on.

Well, IRC sorta as it does group chats. But email? Is there an XEP for that? XMPP can probably gateway to/from email, but XMPP can gateway to pretty much everything in the known universe...

An Email is a message with a subject line and potentially attachments. XMPP has the former in the core, can do the latter with XEP-231 (https://xmpp.org/extensions/xep-0231.html). A message can have one or multiple recipients, just like an XMPP message.

Email is really a simple form of messaging, where you put some content and expect the chain to route it to your destination; pretty much any IM system can emulate it, and XMPP goes a little bit beyond in providing the bits that different an email message from an IM message.

I like that Mattermost is written in Go and can deploy on-prem with Docker. Those are two huge points for MM over Slack IMO.

For anyone looking to give it a try, here is a Dockerized version of Mattermost: https://github.com/mattermost/mattermost-docker

Very straightforward and easy to set up.

This is one of the reasons I love docker, for personal use it makes experimenting with new projects soooo easy.

Plus I have a simple traefik + compose setup so I can easily have it all automatically routed with a subdomain and https.

I might recommend something more robust for businesses in production but man is it easy. Want to try node-red? Done. Want to destroy - and it's gone, no need to futz around with dependencies.

Why does what language it's written in matter? I like Go too but I'm genuinely curious

Mattermost CEO here for a biased opinion. In my mind, the properties of a language can shape the outcome of an open source project.

As an example, when we were starting the Mattermost open source project we were considering a few options for different reasons:

1) Erlang - Real time properties made it nice for a high scale collaboration platform. The trade-off was that it's a really specialized language and there aren't that many people excited to learn Erlang.

2) C/C++ - Really powerful language and can compile to binary format, making install and upgrade easier for admins who don't want to be managing interpreted languages. Trade-off was it was an older language and there's fewer people excited about writing for it, and there can be a fair bit of nuance.

3) Python - Really popular, easy-to-read. Trade-off is things could get tricky as performance and scale needs increase. Also, doesn't support binary format, so more complex install and maintenance options would need to be used.

In the end we used Golang because it had many of the positive properties of Erlang, Python and C/C++ (compiles to binary, easy-to-read with gofmt, real-time support, etc.) and the trade-offs were fewer.

I am guilty of favoriting both go and rust for production deployments for the simplicity (usually a single binary, not a million files of some framework’s and dependencies files). Also it’s my hope that the modern libraries and language safety features and smaller size might be helpful in efficiency and security.

I'm probably going to sound old and grumpy but I've been using Slack for work for 5 years now, plus I've briefly checked out Mattermost and Riot/Matrix, and I've yet to be convinced that they couldn't just be replaced by a fancy IRC client that supports markdown, autoloads images n' stuff.

While they may offer some higher-ups some benefits I don't see anything I'd miss if we moved to IRC, quite the contrary — I could maybe even reclaim some of my RAM and get to choose a client to my preference (which is not an Electron app).

The only reason I haven't advocated replacing Slack with IRC is it lacks a sensible way of keeping history. Everyone either has to keep their client running and connected all the time (usually this is only feasible with tmux/screen on a server), rely on bouncer hacks, or something like IRCCloud which maintains the connection for you but is proprietary and not self-hostable.

I use https://riot.im for IRC for some channels. It stays connected, keeps archives, etc.

For small communities, I recommend Mattermost or Rocket Chat. I used to be a die-hard fan of irssi inside tmux, but seeing how tiny usability issues can really cause adoption issues, I wouldn't even recommend riot.im to less technical people.

This is the big thing that IRC would need to have to make it on parity with Slack. A bit more involved than a trivial change.

>I've yet to be convinced that they couldn't just be replaced by a fancy IRC client that supports markdown, autoloads images n' stuff.

I've heard this so many times I'm surprised nobody has done it yet.

You'd need a client-proxy, or server extension to detect idle desktop clients so you can route messages to a mobile device, for maximum "life work balance."

Riot seems like a good option these days.

Riot / Matrix is also open source, has integration with Slack, Gitter, & IRC out of the box, and is self-hostable entirely for free.

Isn't just matrix with all it's bridges and clients the one ring to rule them all?

One more differentiating factor for Mattermost is its extra special focus security. The product offers the industry’s most flexible and secure instant messaging capabilities across all devices.

Isn't Mattermost fundamentally the same thing, architecturally, as Slack? Slack has one of the industry's stronger security teams. I don't see the differentiator here.

I'm a big fan of Mattermost but industry’s most flexible and secure instant messaging capabilities might be a tad exaggerated.

By way of comparison, I will indulge in a shameless plug for Webex Teams: our customers have the option of hosting their own key server, on-premise, under their control. We have no ways of seeing any content in messages: payload and title are encrypted and participants are IDs that are usually federated with their own identity provider.

Decryption happens locally in the desktop/mobile client, after obtaining the right keys. Yes that's more computationally expensive and carries some complexity. But it's a very different model than just building a single big vault of data. And it also works when users in 2 different companies talk to each other, both with their own key servers.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCol...

Used Mattermost for a year, and I can attest to it's shittiness. There is a bug during switching channels that pins your view to some random location weeks before the latest post. The result is that switching channel in Mattermost has a 60% chance of requiring you to spend the next 30 seconds scrolling the window to the bottommost-recent-message. Horrible.

Mattermost PM here, I agree that this is not a good experience, thank you for sharing @jetru.

There is development in progress to let you jump directly to new messages when you land on the oldest unread message in a channel. This lets you get directly to the latest message.

I'm not entirely sure if this is the same use case you have, but if you're open to testing the new development and share feedback, we'd love to hear!

Pull request with an open test server is available here: https://github.com/mattermost/mattermost-webapp/pull/4132#is...

Mattermost CEO here. That is a terrible experience. Could I ask your help go to "About Mattermost" and let us know the version where you saw the bug?

Opened a ticket here: https://github.com/mattermost/mattermost-server/issues/13422

That's no good, but wouldn't hitting/holding your `End` key be faster?

My Fortune 500 healthcare company successfully uses Mattermost because the lawyers aren't comfortable with us using slack. It's been great. Thank you @it33 and team.

p.s. we haven't run into the issue 6320 (users archiving channels), for exactly the reasons @it33 described in the issue report. He didn't explain it well, but permissions is a complex rathole, un-archive is a simple workflow for admins and if there's continued abuse, just ban the user.

Thanks for wording it so much more concisely and clearly! Love your post, sharing it here: https://github.com/mattermost/mattermost-server/issues/6320#...

Rocket.chat is also a very nice alternative and supports more use cases. We use it internally and also as part of our product.

I completely concur. We used Rocket.Chat (running containerized on OpenShift, our Kubernetes distro) for a time at Red Hat to support the bulk of Red Hat Consulting. Many thousands of messages per minute sustained throughput. All of Red Hat has "restandardized" in the last year but I personally miss Rocket.Chat.

> The company was founded in 2011 as “SpinPunch, Inc”, an HTML5 game engine developer.

Neat that both Mattermost and Slack have the same origin story of game developers building an internal chat app and then pivoting to that.

I been a mattermost user for two years, can't say enough good things about it. Love that it's written in go. We run ours with very little resources and it still chugs along.

Why does it matter what it’s written in?

Go will often be faster than NodeJS. It can also be deployed as a binary rather than a blob of Node modules.

Why does any of that truly matter? What matters most is if it meets the needs of people using the product, not what language it is written in nor how it is deployed.

Usually easier to administrate & upgrade than a mess of script files & packages. Especially if you're not in whatever "scene" that junk's from (e.g. you're an iOS developer, mostly, not a Javascript person used to dealing with npm crap, or a Python person used to PIP crap, or a Ruby person used to gem crap, or whatever crap it may be). Download file for correct arch, run file. You can confidently use it even if you're not familiar with Go at all. Even if you hack on it and make your own builds, the deployment story's nice & simple because deployment target images or VMs or devices usually don't need anything but the binary and maybe a service definition file or startup script of some kind (which everything else also needs anyway, so not like that's any worse). No having to make sure npm's installed, then use it to install some native package that needs to build some C deps for the given environment, set the right Python environment, check the Ruby version, none of that junk.

[EDIT] In short, I guess, the nice thing about running services written in go is that, unlike a lot of other popular ecosystems, you actually can forget about what it's written in, more often than not.

Cost matters too. If one solution needs more hardware or is a pain to deploy then these are additional costs that need to be taken into account.

If it's used in a small company, one of the users will also be deploying and administering it and integrating it with whatever else the company has. So things like what it's written in, matter.

I guess it matters to people who deploy the app and not the users as such.

Fairly anecdotal but feature breakages usually more common in Node apps than Go, it does "matter:most" for end users. It's not because of Node itself but the sheer amount of npm packages what's responsible for those.

It really doesn't, but was helpful for me when I had to patch a few issues.

Mattermost CEO here, thanks gregf!!!

As with mastodon and similar projects - having to deploy, secure and maintain a db server is a big friction point, I wish projects aiming at self-hosting would internalize that and use something like sqlite for small to moderate deployments and would even as go as far as suggesting that it is unlikely to ever be deployed at a scale that a single-writer-multi-reader sqlite service on a decent machine can't handle.

For $20/m ($5 for a droplet and $15 for a managed DB instance) you can have that peace of mind on DO.

Paying $15/month for a managed database is not self-hosting.

One would still have the fun of maintaining the application server updated.

There's much more to hosting a service than standing it up on the modern equivalent of an VM and assuming it'll never need to be touched again.

Sure, but the parent was talking about the difficulties of handling a DB server.

We've been using Hipchat for years at $work. There's very little is say is "good" about it, it was just the best option at the time as it needed to be self-hosted.

Mattermost is being trialled now, pasting code doesn't seem a lot better, but the overall experience is.

As a place that likes Go/Docker it has potential for us.

What issues did you have with pasting code in it? It supports Markdown so it supports whatever a typical README.md would.

It just didn't always behave and syntax highlighting didn't work at all sometimes; but it may have been that the system as a whole was misconfigured.

Mattermost CEO here, thanks for trying us out!

Would love to squash the bug for you, open to filing an issue?> https://github.com/mattermost/mattermost-server/issues/new

We used to send bug coins just for release candidates, but if you find a bug in production you get one too now: https://www.youtube.com/watch?v=7D6FJsdE_aY

Thanks for the response, we'll be sure to post anything that looks like a bug! At this point it's likely our operations team simply hadn't configured it correctly (it is a trial and not a production deployment).

Best regards to the team.

The "$work" notation could be mistaken for the Slack stock ticker. The "$" is how you commonly denote stocks, and "WORK" is the ticker for Slack.

The $ dates back to either shell scripting or perl (and applies to PHP as well), and this is a reasonably common usage in tech/programming circles. See also $dayjob.

It's unfortunate that there's a specific terminology conflict in this case.

Apologies, I had no idea. I was simply placing a variable for "insert workplace here".

The article talks about Hipchat as a competitor but HipChat was shut down by Atlassian and HipChat users were strongly encouraged to adopt Slack: https://www.atlassian.com/partnerships/slack

Just for clarity, Hipchat users were strongly encouraged to move to Slack because slack purchased Hipchat from Atlassian.

Only because Atlassian abandoned HipChat after trying to replace it.

> HipChat was shut down by Atlassian

Not entirely accurate. It's was bought by Slack, and then shut down.

Didn't they just buy the userbase? I don't think they bought the technology - they also made a lot of devs redundant after the purchase?

I'm not sure the exact details of the purchase, I just know that a deadline was placed on our HipChat installation at work (it would not be renewed, and only supported until date X).

It seems their ultimate goal was to shut down a competitor, so, with the result being the same, I suppose the specifics matter very little.

They bought the IP, not the product.

Another thing that happened is GitHub acquired both Gitter and Spectrum. Gitter deprecated its mobile app. Spectrum's founder has been working on other stuff at GitHub. Microsoft has Teams so that might have something to do with it.

Gitter was acquired by Gitlab, not Github.

My team uses it since a year, it works flawlessly for what we need.

Mattermost CEO here, thanks yulaow!! Our contributors love comments like this, hugely appreciated,

Does anyone have legal experience and know what the restrictions are to forking of the Mattermost project?

I'm a programmer with experience in backend development and security and would be willing to donate some time to work on developing a stronger community implementation of Mattermost - only I'm not sure what the legally correct way is to go about it. What I'm hoping to find is a FOSS sherpa to help me navigate setting up a new project.

The Mattermost source code is AGPL. Fork away!

I like Mattermost. My only gripe with it is that it's a bit of a pain to upgrade. Would be nice if they were to automate the upgrade procedure.

Check out the Kubernetes operator, which handles zero-downtime upgrades as well as blue/green deployments and canary builds: https://github.com/mattermost/mattermost-operator

We support Mattermost on Cloudron which automates app updates.

disclaimer: co-founder of cloudron.io

For a while we used Mattermost at my office. At the time we had a handful of startups in our incubator. Eventually we ended up switching to Slack. I don't think it had to do with anything other than momentum and popularity of Slack, in spite of Mattermost accomplishing the same thing with virtually the same interface, people just liked and wanted to be on Slack...

Slack is using cloud/external storage. Many companies have policies against that,making MM is surprisingly popular in banks and such. Personally, can't tell the difference between two

I'm a big Mattermost fan but it really needs end to ends encryption. Also the Android mobile app is pretty weak.

Standard tls between server and client helps against any outside threat. The only threat from which e2ee helps better than tls comes from the server admin.

Now, do you REALLY need end to end encryption to protect yourself from a person running your team chat server?

Not for business, but if you want to get your friends on a chat server it would be easier if they knew you couldn't see everything they said.

Well I mean Matrix/Riot.im has that function.

As some commenters pointed out, the name "MatterMost" might be a crucial thing holding this from reaching the development mainstream as an alternative to slack/teams, which aren't very dev friendly

Could anyone elaborate as to how Microsoft Teams overtook Slack so quickly?

They put it in Office 365, migrated over Skype For Business users, and made the starting price $0.

> Could anyone elaborate as to how Microsoft Teams overtook Slack so quickly?

easy. they didn't:

https://twitter.com/msquinn/status/1179874609899827200

https://venturebeat.com/2019/11/21/microsoft-teams-giddy-gro...

MSFT decided that one clear way to increase their share price is for their new product to run at all times for everyone.

It is free (bundled with office 365). Lots of places prefer to save a few dollars per person and loose hundreds in productivity.

Well, it's not free (or gratis) is it? It just happens to be included in the azure ad/o365/exchange plans? So, if you're on gsuite, for example - ms teams isn't "free"?

This. At work we use it because it is already included in our Office365 subscription, but it is so painfully slow. Really, unbelievably slow.

Same is true for Google Hangouts Chat and you don't see anyone using that...

Last I checked, Jabber could completely replace all of these things except there were no good iPhone clients. Anyone know of an even remotely usable iPhone Jabber client?

Last time I checked, you had to have a very specific server/client combo for very basic features like mobile app, offline messages, and multi-device message history. Grabbing a random server or client may result in some (or all) features missing.

That’s why we recommended Slack for the next workplace. No chance to get anything wrong, and no need for backups either.

Does Mattermost still have LDAP issues? The company I work for was looking for a Slack alternative but in the end decided to stick with Slack because of this.

Thanks moedersmooiste, Mattermost PM here. Would be curious to hear more about your LDAP issues. We have many organizations who have deployed with LDAP, including with group sync to teams and channels.

Those eligible for a nonprofit license can also get the benefits of E10 offering (including LDAP) with special pricing https://mattermost.com/nonprofit/

What do you mean by LDAP issues? You don't get ldap with a free license, but there are still ways to get ldap auth despite that. (For instance, https://medium.com/p/mattermost-teams-edition-replacing-gitl...)

That’s the problem with Slack — too easy to switch to equivalent or superior alternatives. I suspect this issue will continue to weigh on their stock price.

It's not using Matrix? What's the point in making an open source however non federated IM service?

Many companies using such a system wouldn't even want federation, and it adds a bunch of complexity.

That might be true for many companies, but I think also that many companies could benefit from federation -- they just don't know it.

It has been standard practise everywhere I've worked that in business-to-business relations, people have to create accounts for each other's Slack networks.

That is ridiculous. Imagine having to sign up for separate email accounts on the email servers of all of your customers. It just wouldn't be acceptable other than in extreme circumstances; you already have an email account -- why shouldn't you be able to email with your customers/suppliers/vendors from that?

But we accept it with IM because we're so jaded by now. Though if federation was a more well understood concept, I'm sure multiple of the companies I've worked at would jump at the chance of not putting its business relations through the pain of registering dozens of accounts to IM with different people.

So run a local server and turn federation off. Like you can run a private e-mail server. Why not use and contribute to the common protocol that does allow federation? I see no point for a FOSS project in proliferating non federated IM protocols, and wasting resources on that, while federated ones still didn't even reach wide adoption.

Because then you're bound to the common protocol and it's development process, which is a waste if you have no intention of using federation.

I view it the opposite way. It's waste of time to reinvent the wheel and not concentrate resources. Federated protocol can be used without federation fine, but not the other way around. For FOSS projects, not doing it is strange, especially when lack of adoption for federated options is still a major global problem.

So I'd question the intent behind this particular project. For those who don't care about openness (like Slack), I'd expect such behavior. But for open projects - not really.

The days of free as in sabotage are over. Linux broke it.

Not a single comment here mention Google's Hangouts Chat

I'm not surprised, it's a garbage product.

We use it at work since it's bundled for free with GSuite

But - The name is just awful, you can't even find it in Google's search since the previous (still live) Hangout chat app overshadows all search results - Integrations and ecosystem around it is non existent - App doesn't see any meaningful updates - The Android app is so crappy I don't even know when to begin. Try initiating a conversation with some person by searching them. Or try sharing something from Android to a channel only to realize you cannot search for the channel in the list - Api to write bots is pretty badly designed - When you edit your message you cannot mention people anymore - Deleted GSuite users just keep floating around as ghosts

I give this product a year top before it is canned

It's amazing just how bad Google's UIs are, across all their products. There are two different versions of "archived" in Gmail. Maps hides options for types of routes under a settings menu under a screen fold (rather than toggles when you ask for alternate routes). Basic Android features like "stop a process" moves location seemingly every year. I was so confused by GCP that I just went with Azure and got on with life.

I find Apple's interfaces confusing because I've been a Windows developer for 20 years, but at least they seem to stay consistent. Microsoft is in the middle of completely revamping their settings UI, but I agree with the forgot they are going on and they at least didn't delete the old UIs. WTF is wrong with Google?

RIP Inbox. Still a drastically better UI for a lot of users than Gmail is.

It was terribly slow/heavy though. Although the Gmail hi isn't much faster either. I think outlook/office365 email has a much faster and better ui.

I stopped using it about a year ago and was quite dissatisfied as well. Kinda thought they’d put a bit more effort to create a good product afterwards but somehow it looks like a low priority thing for Google. I don’t know why, they could be a very solid competitor and maybe even have an excuse to raise GSuite prices.

Google products experience a self-fullfilling prophecy of not getting serious effort put into them because everyone expects Google to kill it in 16 months, so it never takes off with users, so Google cuts the project.

The really goats part is that the engagement levels that Google considers to be "crap" would make any SV startup a darling Unicorn in their next funding round. But compared to making money hand over fist on click-fraud-plagued ads, it just can't compete.

> since the previous (still live) Hangout chat app overshadows all search results

Not for long, as it's been killed and is now moribund.

Reply on news.ycombinator.com