Hacker News Reader

Comment by ourcat | Hacker News Reader

I'm quite surprised that you don't use Mattermost as a 'Slack fallback' at GitLab.

Indeed, if you champion FOSS, why would you recommend a proprietary piece of software as fallback?

My point was really that it's GitLab's own product. "GitLab Mattermost" [https://docs.gitlab.com/omnibus/gitlab-mattermost/]

I'm amazed they use Slack at all. Let alone as a fallback.

No I'm pretty sure that's just a sort of 'integration', Mattermost shipped with GitLab?

https://about.gitlab.com/blog/2015/08/18/gitlab-loves-matter...

> Like many companies in the last year we've switched to using Slack to improve internal communication. [...] Since Slack doesn't offer an on-premises version, we searched for other options. We found Mattermost to be the leading open source Slack-alternative and suggested a collaboration to the Mattermost team.

I'm not really sure why it's 'GitLab Mattermost' and not (at your link) 'GitLab Nginx' et al. though.

Ah I see now, having read more of the history. Calling it that seems pretty misleading/odd.

(We use GitLab and Mattermost (integration) where I work. I've been 'remote / WFH' for the past 7 years.)

I agree it can be improved and created https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_request... to do so.

They posted a giant list of the services they use recently.

They use a ton of services.

Likely you don't want your backup to be one of your systems and another part of the company probably uses Zoom already so it is probably easy to fail over to that.

Here is the list of services that we use https://about.gitlab.com/handbook/business-ops/tech-stack/

This includes many proprietary ones, we generally choose the product that will work best for us, considering the benefits of open source, but not excluding proprietary software.

Mattermost is not part of the single application that GitLab is. There is a good integration between with GitLab and our Omnibus installer allows you to easily install it. But it is a separate application from a separate company.

Or use mattermost with Slack as the fallback

Maybe my DevOps folks should not be privy to all internal communications?

That is one reason we did not go with Mattermost.

If you do not trust your own devops, why are you trusting someone elses devops?

Low maturity risk management functions.

Because someone else's devops can't use it against you institutionally. Nor is going to insist on having an opinion on things that they're unaffected by.

This isn't a slam at devops, it's about the need for institutional information hiding; not everyone needs to know about and weigh in on every decision being made.

It's just due diligence. Think of what you have access to if you have "god mode" on corporate chat: HR, the CFO's DMs, private messages between other coworkers, and so on. Most won't fall for this temptation, but even those with strong anti-spying morals can be weakened by circumstances. Best to remove the temptation by design.

We structure our company similarly. With effort DevOps is god on everything except HR, Sales, Finance, Chat, and C-level management which are operated with 3rd party services controlled by the individual departments and "owned/managed" by the C-suite.

Devops should have nothing to do with your chat server. It should be your IT department, just as with the email server.

DevOps at a lot of small companies also manage the internal IT stack and sometimes even take on most of the IT duties. Once you get larger you start having "IT" as something separate from DevOps but with the actual infrastructure managed by operations. Once you're really big the teams are truly separate and IT owns their own infra.

Slack won’t protect you from this as it’s possible for admins to export even private DMs.

https://www.nbcnews.com/better/business/slack-updates-privac...

Only Slack Workspace Owners can export, not Slack Admins.

You also have to be on the ‘Plus’ plan, otherwise it is a roach motel.

I'm guessing because they don't want the support burden on a rarely used but necessary fallback solution vs. something plug and play.

This is the reason these "closed" ecosystem apps like Slack/Zoom are multi billion dollar companies and have massive uptake. Simple and easy to user.

Reply on news.ycombinator.com