I'm not sure if "click" is intentional wordplay or not, but if it isn't, the word is "clique" FYI.
I'm also strongly of the opinion that tying core business functionality and information transfer to a third-party chat application is a massive footgun, and other than the fact that I use it out of business needs and not just for voice, I think s/Discord/Slack/g applies. I've both heard Discord described as "Slack for hobbies" and Slack as "Discord for the employed" (although obviously it's not a perfect distinction and I've seen e.g. Netrunner groups on Slack and e.g. some startups communicating through Discord).
That said, the number of teams and departments I have either encountered or heard about from engineering friends elsewhere whose primary - and sometimes only maintained - deployment interface is a Slack command clearly means that I'm the dumb one for trying to work the UNIX philosophy into most of my life's tools and nobody else is blinking twice about vendor lockin and memoizing solutions in a chat application. I just try and take any question/answer that was sufficiently obscure or anything asked more than once and shove it in an "OAQs" ("occasionally asked questions") on Confluence or whatever the knowledgebase application du jour is, but it still feels like teardrops against the ocean sometimes.
I use Discord a lot and I agree that it's bad to use it for anything that you can't afford to suddenly lose (though people still use Google and Paypal too).
I do think a modern chat app is a value-add for fast moving (tech) companies. It is a nice hybrid between sending an email or knocking on someones door for a chat.
And as for the 'chat commands', they're usually just thin wrappers around the UNIX style tool. It's maybe not the most reliable way, but it does have a low barrier and there's not much lock-in. I used to have my server email myself whenever something needed my attention, but now it'd probably use a Discord bot for that.
However, I still wouldn't use it professionaly. the lack of self-hosting (privacy) and archival(bots can solve this pretty easilly) and restricting DMs (see slacks previous issues) makes Discord unsuitable.
> However, I still wouldn't use it professionaly. the lack of self-hosting (privacy) and archival(bots can solve this pretty easilly) and restricting DMs (see slacks previous issues) makes Discord unsuitable.
Slack doesn’t have a self hosted option either. This doesn’t stop literally every company on it from using it. This argument is a purist mentality. At some point you have to use someone else’s servers, or invent everything yourself.
Self hosting doesn’t even give you control, the app owner can easily put command and control software in the server image and still do whatever they want. Don’t pay your license fee? Good luck getting the keys to your encrypted data store.
I'm also strongly of the opinion that tying core business functionality and information transfer to a third-party chat application is a massive footgun, and other than the fact that I use it out of business needs and not just for voice, I think s/Discord/Slack/g applies. I've both heard Discord described as "Slack for hobbies" and Slack as "Discord for the employed" (although obviously it's not a perfect distinction and I've seen e.g. Netrunner groups on Slack and e.g. some startups communicating through Discord).
That said, the number of teams and departments I have either encountered or heard about from engineering friends elsewhere whose primary - and sometimes only maintained - deployment interface is a Slack command clearly means that I'm the dumb one for trying to work the UNIX philosophy into most of my life's tools and nobody else is blinking twice about vendor lockin and memoizing solutions in a chat application. I just try and take any question/answer that was sufficiently obscure or anything asked more than once and shove it in an "OAQs" ("occasionally asked questions") on Confluence or whatever the knowledgebase application du jour is, but it still feels like teardrops against the ocean sometimes.