5 ms·

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

by ourcat 6y ago

ekianjo 6y ago
Indeed, if you champion FOSS, why would you recommend a proprietary piece of software as fallback?
- ourcat 6y ago
  My point was really that it's GitLab's own product. "GitLab Mattermost" [https://docs.gitlab.com/omnibus/gitlab-mattermost/ https://docs.gitlab.com/omnibus/gitlab-mattermost/] I'm amazed they use Slack at all. Let alone as a fallback.
  - OJFord 6y ago
    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-mattermost/ 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.
    - ourcat 6y ago
      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.)
      - sytse 6y ago
        I agree it can be improved and created https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4877 https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_request... to do so.
  - tempest_ 6y ago
    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.
    - sytse 6y ago
      Here is the list of services that we use https://about.gitlab.com/handbook/business-ops/tech-stack/ 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.
  - dvdbloc 6y ago
    Or use mattermost with Slack as the fallback
- daniellarusso 6y ago
  Maybe my DevOps folks should not be privy to all internal communications? That is one reason we did not go with Mattermost.
  - arpa 6y ago
    If you do not trust your own devops, why are you trusting someone elses devops?
    - toomuchtodo 6y ago
      Low maturity risk management functions.
    - lostcolony 6y ago
      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.
    - ericbarrett 6y ago
      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.
    - Spivak 6y ago
      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.
  - Jolter 6y ago
    Devops should have nothing to do with your chat server. It should be your IT department, just as with the email server.
- res0nat0r 6y ago
  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.
- deleted 6y ago
  [deleted]
  - deleted 6y ago
    [deleted]

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

by ourcat 6y ago

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

ekianjo 6y ago

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

ourcat 6y ago
My point was really that it's GitLab's own product. "GitLab Mattermost" [https://docs.gitlab.com/omnibus/gitlab-mattermost/ https://docs.gitlab.com/omnibus/gitlab-mattermost/] I'm amazed they use Slack at all. Let alone as a fallback.
- OJFord 6y ago
  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-mattermost/ 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.
  - ourcat 6y ago
    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.)
    - sytse 6y ago
      I agree it can be improved and created https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4877 https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_request... to do so.
- tempest_ 6y ago
  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.
  - sytse 6y ago
    Here is the list of services that we use https://about.gitlab.com/handbook/business-ops/tech-stack/ 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.
- dvdbloc 6y ago
  Or use mattermost with Slack as the fallback
daniellarusso 6y ago
Maybe my DevOps folks should not be privy to all internal communications? That is one reason we did not go with Mattermost.
- arpa 6y ago
  If you do not trust your own devops, why are you trusting someone elses devops?
  - toomuchtodo 6y ago
    Low maturity risk management functions.
  - lostcolony 6y ago
    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.
  - ericbarrett 6y ago
    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.
  - Spivak 6y ago
    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.
- Jolter 6y ago
  Devops should have nothing to do with your chat server. It should be your IT department, just as with the email server.
res0nat0r 6y ago
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.
deleted 6y ago
[deleted]
- deleted 6y ago
  [deleted]