* search engine that just work

* push-notifications that just work

* client available for enough people

* copy / pasting images that just work (the'll never admit it, but animated gif is their killer feature)

* stable-enough infrastructure for something that costs you 15€/month/user not taken from your "salary" budget (often a different and substantially less taxed part)

* and their outages are funny (receiving messages twice is arguably better than not receiving message)

Yes, it's because it "just kinda works for what it costs, and you can forget about it most of the time and do your job."

This seems to be characterized as "laziness" by some people, a point I honestly don't understand (I though lazyness was a virtue in our circles.)

That being said, there are legitimate reasons to not use it:

* software licence

* data property

* technical implementation of the native clients

* general distrust of centralized solutions

* cost of having IM at all (see Newport's whole publishing career)

At least, it means there's an opportunity to create a company that handles decentralized user-friendly open-source standard-based data-respectful attention-preserving uber-reliable chat system. HN users would be a market.

> search engine that just work

For some definitions of "just" and "working". Even ignoring the business limitation, the UX of Slack search is meh. That said, I'm yet to see any of the modern web&mobile-oriented IMs that would have a decent search UX.

But yeah, your list is solid. They offer plenty of value, just mixed with plenty of negatives.

A big source of the complaints against Slack is usually the network effect - in context of both work and OSS communities, it's usually somebody else that makes the decision and imposes it on you, forcing you to run face-first into all the "legitimate reasons to not use it" you listed. Half of the pain would be gone if they opened up their service to third-party clients; I'd say the reason they didn't have as much opposition from people initially is because they run the bait-and-switch with IRC gateway.

Interesting point about : work environment vs communities.

For work, the decision of which IM tool is most likely going to be a corporate one, without much choice of solution. I guess the problem here is the same as for other corporate tools. (And people have strong feelings about corporate tools, but it seems there are less strong feelings about "using jira vs bugzilla" as there are "using slack vs irc". Or maybe there are as much strong feelings.)

On the other end, I get the troubles with the "network" effect for out-of-work communities (open source projects, clubs, etc...) Such communities can at least have "some" level of debate about which solution to use, and balance the pros and cons as they see fit. It's completely acceptable for an OSS community to discourage using such platforms - as any other non-free, centralized platforms. We're still not forced to use anything.

Then, there is the "club of non-power user" situation. I would be hard pressed to ask someone from my drama club to setup and maintain an IRC server (neither do I want to do it.)

Thanks for adding this dimension.

Follow-up: is there a "nice" provider of some slack-like solution (mattermost, etc...) that hosts servers for communities of non-techies for not too much money ?

"just running an IRC server" is... a lot. Or can be. Who is running it? Does it scale well? How is login synced with corporate logins? What about mobile devices?

It's not "better" than email, it's different. Real time. It has a million and one service integrations, which IRC doesn't.

Point is, it's really not all that crazy to just pay a third party to manage all this stuff for you. You might imagine the alternative is a perfect IRC server with 100% uptime, but I doubt that would be the reality. If you're saying a service like this is too important to be run by a third party then you're going to have to invest a lot internally to come up with an alternative that's more reliable.

> Does it scale well?

It's IRC. On modern hardware. It's practically infinite.

> it has a million and one service integrations, which IRC doesn't.

There and were are things way before Slack, eg https://loqi.me/

Obviously you can create IRC integrations for anything. But how many are installable with one click, like Slack integrations are? Having to write custom implementations is yet another extra task and point of failure compared to just paying someone to manage it all for you.

another "but".

First "but it doesn't scale". Now "but integrations".

There will always be another "but", and there will always be a link on the internet showing that it's been done already.

"but shiny web gui" - https://thelounge.chat/

"but mobile app" - https://github.com/MCMrARM/revolution-irc

"but it's complicated" - https://www.mirc.com/ since 1995

IRC does have limits. Some. One is that to make it "modern" it needs a bouncer - that said znc is spectacularly simple to set up with it's web interface.

Integrations were never one of those limits. Just google IRC bots.

> another "but"

That's my entire point. It's death by a thousand cuts. Now I'm responsible for an IRC server, a web frontend, a mobile app and a bouncer.

The OP said "just run an IRC server". There is no "Slack or just an IRC server". There's "Slack or a number of connected, interdependent services you need to maintain". I'm not saying it can't be done, or that it isn't the right answer for some people, but it's also a lot more work (and thus, expense) than just paying for Slack. It absolutely makes sense that people do it.

Why is paying another company better than getting employees and paying them the same or even less money?!

When did this madness start?

In what world is it going to be "the same or even less money" to hire one or two sysadmins on a full-time basis than paying for a Slack subscription?

Tbh., if you need two full-time sysadmins to run your IRC server + bouncer + log backup + web frontend, you're doing something really wrong. It's more like an after-school job for a bored CS student.

I don't know how large your company is, but with 10k+ employees, it's suddenly a reasonable option.

With that many employees you're signing up for Slack's enterprise tier, and you can bet they price it so that they come out the right side of this cost/benefit calculation for a lot of companies.

I have seen those numbers. You could easily afford paying sysadmins with those numbers.

But managing an IRC server cluster for 10.000+ users is no simple task.

Paying experts in their field (chat tools in this case) is most of the time the most reliable and cheapest variant. You must also include that Slack has plenty of features that are not available in IRC and mean the productivity is not as good.

Since when is running any service for a number of people something people compare with running google?

30 years ago, efnet was (apparently) 35k users.

How do you make it possible for people to view the IRC channel history when they were disconnected? I know you can have a bot that saves a log, but can it be made seamless?

I think it's really sad how the world has migrated away from an open protocol to a closed one, but I remember IRC having some very real annoyances, well beyond stuff like integrations.

The answer is in at the bottom of my previous entry. It's called an IRC bouncer.

bouncer, or web client that persists chats, like TheLounge or Convos.

Features is not the only thing, does it have well funded sales team and strong corporate support ? Slack itself did support IRC till recently, the product is not just a sum of its features

> does it have well funded sales team and strong corporate support

Get 2 sysadmins. 2 because of redundancy. Pay them to maintain your service.

"well funded sales team and corporate support". F that. Trust your employees.

What happens when your sysadmins say "Maintaining IRC is a waste of time and gets us 1% of the features Slack does, let's just get Slack?" (At my last company, it was the sysadmin team, including myself, who decided to switch to Slack and killed our IRC server.)

Do you stop trusting them then?

2 sysadmins will cost considerably more than a few slack accounts. Unless your company is huge.

> Unless your company is huge.

Yes. Someone above have mentioned ibm using slack though. I think that's huge enough for the argument.

Yes at that scale it may be useful to roll out a custom system. However I'd count into account that large customers probably have different pricing and that maintaining custom systems is always bothersome because you are always the largest customer.

"Well funded sales team" is unfortunately what makes closed products win over open ones.

Come on, in the 90s and early 00s, volunteers ran and managed IRC networks scaling up to hundreds of thousands of users. This was back when hardware and bandwidth were much weaker and 100x more expensive. It's really not that hard.

Yes, volunteers ran these things. How many? Because you're going to need to have paid employees rather than volunteers running your servers. Is it going to be more reliable and cost effective than just paying a third party to run a service for you?

If you're a big enough company (more than 60 people if computer are your means of production, around a thousand if not), you should have your own server and a fallback on a CSP. Just pay some guy in India/South Africa to manage all your internal services and architecture. If they are sensible and you need to trust the guy, just pay him well and hire locally.

I can set you up a resillient architecture and 3 services (communication, documentation, filesharing) in less than two weeks (let's say two weeks and a half because security concerns/limitations and all that stuff). Add one week and you will have mail server, VOIP communication, log conservation and monitoring, backup images on CEPH, vnc service for "easy" maintainance and a small documentation explaining the few action needed to maintain the monster for two years. Initial cost for a company: 15 to 25k$, + 1 hour and ~100$ a month.

For something like IRC? Yes. The service is dead simple and one server can handle thousands of users with modest hardware and without breaking a sweat. A completely unfamiliar sysadmin could set it up in an hour or less. Since it's probably internal, there's little need for public services (nick/channel registration, etc).

So what about the mobile device issue? Corporate logins?

If you want to match what Slack offers you aren't just running an IRC server, you're going to have a small fleet of dependent services that, added up, just about match what Slack does.

Is it really that surprising that people just opt to pay for someone to deal with all of this for them?

Put TheLounge [1] in front of it for people that want a web interface. Perhaps use ldap for corp users. [2]

[1] - https://thelounge.chat/

[2] - https://thelounge.chat/docs/configuration#ldap-support

At which point you're not looking at IRC as a service anymore. There are different niches served - but the question was about the reasonableness of setting up IRC alone, which is still dead easy.

Most of how I use Slack, and how everyone I know uses Slack, involves 1. sending messages to people who are “away” to get their attention/loop them into a conversation; and 2. people reading back up in history for context when they come online.

Now, modern IRCds might have features I’ve never experienced on raw IRC... but if they don’t, I don’t suppose you’re suggesting that this server also run thousands of bouncer bots in order to provide this contextual history feature?

(Also, whence push notifications?)

It's a reasonably nice client, and available on every platform.

It has easy integrations with basically everything, and non-developers can set them up on their own.

It has bouncer functionality built in - You don't miss messages. It can also archive them, and handle them in a corporate-compliant way without needing to speed a bunch of time setting that up manually.

Because it's a central company and not IRC push-notifications are easy.

Emoji are shared corporate wide, anyone can add them.

It's a really nice out of the box experience.

You can absolutely replicate it with enough setup and tweaking, but the free version of Slack will go a long way.

They somehow got Clevels on the bandwagon. Those who actually understand the implications don't have a word.

Truth is I see many capable people buying into these as well because of the convenience - read: lazyness - factor. The "ain' nobody got time for that" effects everyone and the willingness to pay for services had skyrocketed in the past decade. This applies to blogging, to home servers, backup, anything. We're all guilty at some level.

IRC is pretty much useless since you don't have history. Comparing Slack and IRC are like comparing TCP and HTML5. Why IRC is pretty bad in enterprise:

- no audio / video

- no history

- no SSO / AD integration

- no rich features like links, pictures, upload docs ect ...

- easy bot integration with APIs, I can have Datadog pushing things to Slack ( alerts, graph... )

- no archiving channels on the go, Slack is very useful when you have an incident and you create a temp channel and then archive it when the incident is closed.

IRC is a protocol.

The features you're listing is server/client dependent.

> no audio / video

There are products that are far better for audio and video communication than Slack. At my company, we use Zoom.

> no history

Can be done with a bouncer if you need it.

> no rich features like links, pictures, upload docs ect

Is there a reason why an external service can't be used? I can't upload a image here on Hacker News, but I can always include a link to it.

> easy bot integration with APIs

So I have to use the HTTP protocol to manage a bot rather than checking for certain key words in the message itself.

> no archiving channels on the go, Slack is very useful when you have an incident and you create a temp channel and then archive it when the incident is closed.

That depends on the settings. One thing that happens every so often at work is that people get trapped as the last remaining person in a channel because only an administrator can archive a channel. In IRC, that's not an issue.

matrix does all that and can be self hosted - ours is.

Does the opensource matrix server scale? I may be wrong but I got the impression it was more an example implementation and was not used by Matrix in production?

There is no closed source Matrix server implementation that I'm aware of. Synapse is the server used in production for matrix.org, the French government deployments, and tons of other servers including my own. It is somewhat resource intensive but it can scale using workers.

There is of course several other server implementations in progress but none are fully ready yet.

We used to run an IRC server at work, and it was pretty exclusionary to non-engineers; setting up something that'd log backscroll required maintaining a vm somewhere, searching through history required another service, etc. If all slack does is chat (and video communication by way of an acquisiton), I'm happy letting them be 5 years old. I'd scrutinize a company that: 1. has no fallback mechanism of Slack is mission-critical and goes offline 2. isn't careful about including non-technical stakeholders in communications.

Edit: clarifying that I'm talking about my workplace, not a company I run.

Ive always said Slack is IRC for millennials.

"The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again."

I certainly prefer it, but I've both heard many other millennials strongly oppose slack, and Gen X:ers talk highly about other "no-setup" systems. I don't think not a generational thing.

Plenty of millennials grew up with IRC.

Because they don’t trust their IT or operations groups to manage IRC or any other open source communication system; even as they trust those same people to run the software that makes them money.

/shrug

IRC is just a protocol, neither the server nor the client do have to be open source.

Aside from features:

I have seen enough corporate mail servers going down, irc and jabber servers breaking etc.

Using those won't magically give you 24/7 with more than five nines uptime.

Key difference is: If slack goes down many companies are affected and it goes on the internet. If a company's mail setup goes down employees are a bit annoyed, but after a while it works again and nobody outside notices and it's no news on HN (unless it's a real major thing bringing a notable company completely down)

- Mobile client, including mobile push

- Search

- Scrollback/history available in the main client interface people who newly join a channel (extraordinarily important during incident response)

- Ability to link to a message in history

- Ability to handle multi-line messages in a vaguely competent matter

- Image uploads, snippets, etc.

- Users of a GUI tool / web interface are first-class, users of a command-line client are second-class; this is unlike IRC, and important when the goal is a single chat system for the entire company, not just engineering (and usually a subset of engineering at that)

- Client/UI expectation that you do not catch up on every message unless you want to (like IRC, but unlike email)

- Quality integrations that have already been written with the third-party apps that you're already using

IRC and email have both been time-tested, and have failed the test.

Our company switched from self-hosted RocketChat to Slack just this week. Personally I didn't agree with it, but it's not my call. The reason was mostly that Op guys were too busy with other things and didn't want to care about yet another critical company-wide service. They though outsourcing it would solve the downtimes and bugs. This outage couldn't come at a better time.

It has emojis and is the Next Best Thing (tm)

no, it's not. It's just a company based whatsapp group chat you can use while looking busy

I’ve heard from countless of friends how many times Outlook goes down for their company, whether it’s a midsize company or a large company. I don’t think this is unique to Slack or company age.

What does years have to do with it? Look how many engineers have to sit on their hands when github goes down?

Not necessarily better than IRC, but email is a pain.