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.

Absolutely. My company uses it (among other things) for handling production issues.

We'd rather not manage that ourselves. It's just one more thing we can screw up.

This is different than the FOSS subject of the article, but it true that convenience is compelling.

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.

And that's what I meant by "among other things".

Originally, we were using Campfire.

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.

So use grove.io

My company runs our own private IRC server on an EC2 instance and once it was set up I don't believe we've needed to touch it since.

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.

Explain why that's any worse than putting private information on a server on with port 80 open. Go!

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. :)

So put in an iptables rule that restricts it to their network and make people remote in to use their client. Done and done.

iptables rules are not magic security talismans.

Oh yes they are you just need to add the --rabbit-foot switch.

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.

How very lucky of you.

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?

how very sarcastic of you.

This is the realm of systems administrators, if you can't read a 20 line config file then sure, run slack..

but for a biggish company that values security and publishes NDA's like mine, an IRC server is a better solution.

however, Project Managers fucking -love- emoji and sending word documents across the planet.

How very decisive of you.

And you'd take on the burden of constellation of comparable services as opposed to a white label hipchat because....?