[yeukhon]

IRC is my favorite, but IRC is bad for company, because you have to manage your own IRC server (you don't want to host your company stuff on freenode, do you). Also, IRC doesn't come with any integration with third party tools. Unless you have a very willing hacker willing to build the integration from scratch, IRC is bad. Not that you would never find a use case to write custom bot on Slack for your need, but I imagine tools like Jira, Jenkins are already created and are well maintained.

[nrjames]

In an enterprise environment, Slack is sometimes considered bad because all of the company data is not under the company's control. I seriously doubt that the company I work for ever would go all in on Slack, precisely for that reason.

[yeukhon]

A lot of enterprise claim to run their own services, but in reality, they outsource to third party to host them, for example, centurylink for active directory or some vendor for managed exchange servers. Heck, a lot of companies bought 365 and Box. People use Skype for communication, passwords are being thrown all over emails and chats. Code are on GitHub. While there is auditing in place, the reality is, a lot of enterprise data aren't really controlled and stored on-premise servers, and auditor cares mostly whether access are limited, logs are available for tractability, and whether there is enough risk assessment done prior to signing the contract.

[nrjames]

Yep, I'm well aware of all of that because I sit on our "Cloud Technology Advisory Committee," which feels like a scene from Brazil. However, many here work with sensitive PHI and various types of classified data, so the concerns are bound to contractual agreements with clients and our ability to win work is contingent upon standing up to audits that verify our claims regarding data ownership, security, etc. I wouldn't argue that makes it more secure, but it's the reality of the business.

[yeukhon]

Certainly. Another option is HipChat, which you can host on-premise. I actually prefer HipChat because of the simplistic UI. Now both Slack and HipChat support video call is a great plus because I don't have to switch between tools. Slack UI is noisy to me, but the growing ecosystem is fantastic. Ugh.

[gregmac]

IRC is also bad because it is too client-side. There is no history: if you're not connected or not in the room, you miss all the messages there. IRC Cloud and similar things half-solve this problem in the ideal situation (eg: nothing fails, such as IRC Cloud connecting to the IRC server), but they are a kludge on top of what is really an inadequate protocol if you want to compare to Slack/Hipchat/etc.

Frequently we will @mention someone in a room that the are not currently in, saying something like "Hm, maybe @person can help with this?" and then they'll get the notification, join the room, read the last bit of conversation, and often provide a solution or something useful. That workflow simply doesn't exist on IRC.

There are a handful of other features that range from really-freaking-nice-to-have to essential, such as user avatars, away status, formatted code blocks, inline image display (upon seeing url), @mentions, @mentions that go to e-mail when you're away, synchronized notifications across multiple platforms, file/image upload (via copy/paste).. Some of these CAN be done with the right IRC client, but they're not universal or standardized.

[pmlnr]

ZNC. I was seriously thinking of setting up ZNC as service.

[cpeterso]

IRC Cloud can host private IRC servers for companies. IRC Cloud also has hooks into third-party services like GitHub and Dropbox.

[thwarted]

Unless you have a very willing hacker willing to build the integration from scratch, IRC is bad.

There is a hurdle here, but it's not so bad if you're already willing to run your own IRC server. I wrote nodebot[0] to allow machines and scripts to send messages to IRC, it would be a day or so to put an HTTP request handler (apache with a CGI even) in front of this, slap some TLS and http auth on that URL, and expose a webhook that these external services could hit.

One of the great things about slack is that many integrations already exist, so it's often just a matter of sharing an API key or some other credentials between the services, and anyone can do that. I do, however, run into issues with things like github which has many outgoing integrations with services that also use github's incoming API. It can quickly become a mess -- where should the authority lie for doing integrations: with the chat app or with the individual services?

[0] https://github.com/thwarted/nodebot

[lmm]

Established OSS tools like Jenkins already have IRC integration.