>Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties.
So run a private IRC server? This is a weird caveat, like complaining that angelfire is an insufficient web platform and you have to run your own http server to do well. There are a billion IRC clients, libraries, and bots out there. There are IRC servers in most distros. There are JS servers in NPM. Why not use them?
Companies are using Slack because they explicitly don't want to have to deal with this and would rather someone else take care of their chat infrastructure, and with more features.
If it's just infra management you want, then use Hipchat. It does the same things Slack does, at $2/user/mo instead of $8. Slack is ridiculously expensive.
It's only expensive compared to HipChat which is a subsidised gateway service that leads to Jira. Our company used HipChat for about a year before moving to Slack. Honestly, the differences are not many and any reasonable team could choose either.
I think we migrated to Slack for connectivity reasons, fonts and general user interface, and the bigger list of integrations. Are these worth $6 per user per month? If you've got the money then maybe. But it's by no means a given.
As needs grew beyond just putting out fires, we looked at Hipchat, Flowdock, and Slack.
We probably would have gone with Hipchat (because of the price), if they had SSO, or better JIRA integration. Slack had both.
I highly doubt that slack has more features than IRC, which has thirty years of history in dozens of code bases. I agree that taking a canned solution is easier, and easier is often best. But I think this is the main reason slack is popular; its less to think about. There are many dimensions in which it will be worse.
Your company puts private information on a server that has a 6667/tcp sitting out on the Internet?
I'm guessing it does not, and setting this server up was considerably more irritating than just spawning off another t1.micro and apt installing IRC onto it.
We have all our instances in a VPC so nothing is available without a VPN. (Openvpn, on phone, laptop, built into the wifi router for everyone else). Once any service for our firm onlt is set up it is effectively private it we manage our keys. Private IRC is a one line apt get on a server. Close to zero cost from there.
In AWS t1.micros don't really exist anymore (they do, but you have to use oooolldd images), and except for legacy accounts, a default install puts you into a VPC where the instances are never going to have 6667 open to the internet unless you specifically open it (well, that's more of a Security Group thing) and possibly don't even have a public IP address. :)
True, but for this case it's more than adequate. An attacker would need to be able to tunnel through your companies network, and then what? Assuming they're that far, who cares if they can read what you talk about on IRC?
And even then, they'd further need to exploit some vulnerability in your IRC server to do it unnoticed.
I hope you have a repeatable provision, AMI, static IP linked to a tcp loadbalancer and autoscaling group in the event AWS rotates out your instance.
And of course, the same goes for your logging and search and file sharing infrastructure. And of course, similar caveats exist for the database said features use.
If your file sharing infrastructure is limited to what Slack provides, then your file sharing infrastructure sucks. Slack is good for quick "check this outs", but it's not a file sharing system.
Well, you add the google docs integration, or the dropbox integration, or the box integration, or use the Zapier integration to tie things together.
Slack isn't a file sharing platform, it's a communication platform. As such, they try to make communicating about, discovery and grouping of files in dedicated file sharing platforms easier.
That's a terrible solution for anyone handling data that has to remain on-prem, which is the case for a lot of large corporations that deal with financial data, personal id data, etc.
Of course it's a bad solution in that case. You've picked a case where a specific business requirement precludes using an external service. In which case, why would you use slack anyway, since it would then necessitate a chunk of your communication be external as well?
So run a private IRC server? This is a weird caveat, like complaining that angelfire is an insufficient web platform and you have to run your own http server to do well. There are a billion IRC clients, libraries, and bots out there. There are IRC servers in most distros. There are JS servers in NPM. Why not use them?