Well for one thing, there's the hassle of maintaining it. Don't get me wrong, I maintain lots of things. It's my full-time job. I count it as a victory every

Well for one thing, there's the hassle of maintaining it. Don't get me wrong, I maintain lots of things. It's my full-time job. I count it as a victory every time I can gain some capability without adding some additional thing to maintain. Double victory even better every time I can take something I thought I needed to maintain and throw it on the scrap heap, eg because its functionality was subsumed by something else I need more. Then there is security. If I take this open-source app and deploy it on my servers, and there is a vulnerability that results in privilege escalation, I have just opened up my network. Skilled admins will balk, but if I chat over Slack and there is a security vulnerability in Slack, even something related to my own (or my users' own) incompetence, I've just exposed... worst case is Slack, and Slack's network, and whatever my users already saw fit to expose to Slack. It should already be eminently clear to my users that data in Slack's hands has left the garden of our own control, and is not to be trusted. I am a proponent of other and opener Slack alternatives (to put it mildly), but I prefer things that come in a bigger stack, so when I waste my time setting them up, I get something back better than... my own watered-down version of Slack that I need to add to the maintenance charts. (Insert small, shameless plug for Urbit, which has a centralized talk server and stores backlogs)