* 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.
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.
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 ?
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.
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/
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.
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.
When did this madness start?
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.
30 years ago, efnet was (apparently) 35k users.
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.
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.
Do you stop trusting them then?
Yes. Someone above have mentioned ibm using slack though. I think that's huge enough for the argument.
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.
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?
[1] - https://thelounge.chat/
[2] - https://thelounge.chat/docs/configuration#ldap-support
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 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.
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.
- 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.
The features you're listing is server/client dependent.
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.
There is of course several other server implementations in progress but none are fully ready yet.
Edit: clarifying that I'm talking about my workplace, not a company I run.
"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."
/shrug
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)
- 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.