Hacker News Reader

Comment by piquadrat | Hacker News Reader

Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like).

And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?

View on HN

On one large free software project, we adopted Mattermost (an open source / self-hosted equivalent of Slack). We went from ~12 active users and ~50 lesser active users, to ~ 100 active and ~ 500 lesser active users. I agree that more folks should consider moving away from IRC.

The sign-up process for Mattermost is easy. It's intuitive, cross-platform, mobile-friendly, etc. While we geeks are used to IRC, onboarding people to IRC is no different than any other product: the smallest glitch, weird UI, confusing elements will make people drop off pretty quickly. I have always had to sit down with someone to show them how to connect to IRC. We would waste time at code sprints showing people how to connect.

With Mattermost, we have unlimited logs (so we can cross-ref/permalink conversations in the issue trackers), threaded conversations (great for when the channel is noizy), emoji reactions (friendlier atmosphere), etc.

However, I agree with the article: Slack is inappropriate for open source communities. Mattermost and Rocket Chat are good alternatives. Between my IRC habits and what I can do with Mattermost, I find Slack very frustrating (and I don't use it anymore). Then again, as much as I like IRC, it's not an alternative either.

Thanks for the mention on Mattermost!

For anyone who'd like to try an open source Slack-alternative, you can start in less than a minute with auto-deploy via Bitnami: https://www.youtube.com/watch?v=AKqHWqrAgpk&t=9s

Goes to AWS, Azure, GCP, Oracle Cloud, all data under your control, Mattermost Team Edition runs under MIT license.

Also, check out our new React Native mobile apps: https://github.com/mattermost/mattermost-mobile

We migrated from IRC to Mattermost and haven't looked back. It integrates so well with our Gitlab/Jenkins flow, too. It's been great.

The biggest benefits for us:

  - Easy to use web push endpoints w/ API keys (great for scripting with curl)

  - Integration with Gitlab / Jenkins

  - Chat Logs (see what happened while you were away)

  - Public listing of channels (no more "oh you have to join #whatever to see that")

  - Mobile Web App (I can't get the Android app to work with our self signed cert, but that's OK).

Fantastic! Thanks for the mention! Yeah, scripting integrations with curl is super useful.

For others, here's another article of replacing IRC with Mattermost in education: https://opensource.com/education/16/3/mattermost-open-source...

Why do you want a chat client to integrate with gitlab or jenkins?

Oftentimes the 'sync' conversations are either triggered or resolved by commit/build events.

Do you mind expanding on this and showing a full flow? That sounds a little wonky to me but I could be missing something.

Our flow is like this:

1) Person pushes to dev branch

2) Chat log shows the feature pushed

3) Chat log shows Jenkins received push and is downloading

4) Chat log shows whether tests were successful (yay) or not (boo).

^^ that's the basis. It helps keep everyone up to speed on what's going on, especially for testing.

One more example: Notifications when merge requests are made / merged in the chat.

How do you like mattermost compared to rocket.chat? My group switched from flowdock to rocket.chat to save money and we've definitely seen a dip in participation. Rocket.chat's mobile app constantly seems to have issues with remembering what server you were logged into between updates and the desktop version doesn't recognize when you're caught up with a channels messages leaving it marked unread unless you go out of your way to manually tell it. Plus I really miss threads...

I was at a dev meetup for Python: I really thought he was joking when he said, what is IRC? And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it. Amazing the amount of knowledge and experience lost between a single generation.

I don't think it's necessarily a generational thing. I know people in their 30s who don't know what IRC is (or who at least haven't used it), and I know people in their 20s who DO use it (or at least know what it is). And it's not as though the knowledge is lost; IRC still exists and there exists plenty of information about it. It's just not carried around in people's heads as much. None of this is good or bad; it just is.

I don't think it's a generational thing either. I know how to use IRC and how to connect with it. The problem is the difference in the amount of energy demanded by the set-up process. Connecting to Slack is extremely simple and I don't have to fiddle with the settings in order to get a decent experience.

Compared to IRC, I have to:

  - Figure out how to configure my client.
  - Figure out how to interact with the user account and moderation bots on Freenode or $other_server.
  - Figure out how to set up something like ZNC in order to federate the client on my phone with the client on my laptop so I don't miss messages.
  - ...

It's an epic yak shave that sucks massive amounts of time and energy a from the thing I joined the community to do: improve a piece of software that isn't IRC.

The benefit, though, is once you are set up with IRC, joining new channels is a breeze, especially since most open source software uses a single network (Freenode). All I have to do is type something like

  /join #rust-lang

and I'm in the new channel. Compare this with Slack, where, no matter how many teams you've joined in the past, you have to go through the exact same rigamarole to join a new Slack team.

Discord avoids that issue by having a global identifier, similar to your connection to an IRC network.

However, having that global identifier / IRC network connection is a tradeoff - it forces you to use a single consistent identity for every single interaction on that network. For some people this is a plus; for others it is a negative. Slack's teams option allows people to use different identities for different instances.

> I know how to use IRC and how to connect with it.

> [...]

> - Figure out how to configure my client.

> - Figure out how to interact with the user account and moderation bots

I disagree with your initial claim. :P

Those are irc basics, things you only have to learn once, and there is documentation online and on the web. It's worth it to spend the time to learn a tool that you can use throughout your profession, even as the proprietary flavor-of-the-month services come and go.

That still ignores the existence of a huge usability problem. The investment of time may pay off in the long run, but IRC is large enough investment (and ongoing maintenance, ZNC doesn't just take care of its self forever) that people will take a route of less resistance when presented.

This all reminds of a few years ago when folks were banging on about how we needed to use Gitorious instead of GitHub for Open Source hosting. Gitorious is dead now and it wasn't until GitLab came along and recognized the usability problem that we got a viable Open Source alternative.

Same thing has happened in gaming with the introduction of Discord. No one wants to bother with mumble, team speak, or vent.

Trying to get everyone in our group setup with mumble was a pain for the people who only use their computer to game. When we switched to Discord it took maybe 10 minutes to get our group of ten all in one chat.

I've tried to give IRC a chance a few times, but it always felt like there were a few too many odd little things to learn before I could be productive and comfortable. I didn't get used to it and dropped it. It never felt inviting.

I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in dealing with IRC.

I probably wouldnt hire a developer that didn't use IRC

Because in the skillset of developers, IRC is such a difficult one to acquire?

Grep isn't a difficult skill to acquire but I wouldn't hire someone that didn't know it. Some skills can be good proxies for a range of other skills an experience and a lot of developers are in that "don't know what they don't know" range.

Sure, I just have to disagree on IRC being a good indicator for that.

Also, fwiw, most of my colleagues use IDE "search project for string" in places where I use grep. Also, if I'm being honest, you should hire nearly all of them before you hire me.

I think you've picked two false flags.

I've been IRCing for 24 years. I know about bouncers, different clients, etc., and I still prefer Slack to IRC.

I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading.

I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It's nice not having to think about that stuff at all. I've got a lot on my plate, keeping a bouncer up and running somewhere (just so I don't lose history!) doesn't need to be another thing I do.

I like the plugins, the integrations with various other services. I like the convenience and polish. No IRC client compares to Slack for integrations and polish. It takes friction out of my daily chat experience.

I've even moved some private irc channel chats to Slack channels, because it's just a more pleasant experience in 2017. No regrets about any of that.

I think these are all key points. The user experience in Slack is so easy, convenient and polished. It takes friction away from communication, allowing effort to be focused on the tasks at hand.

I used IRC a lot as a teen back in the late 80s early-to-mid 90s. This was back when to make a private channel you would have to join a channel that was a negative number and hope nobody else wandered in on a guess (which was unlikely to happen since the number of users was literally under 200 at peak times). Pre-Eris, Pre-EFNet, etc.

Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.

I used IRC a bit in the mid 90s when I first encountered this whole internet thingy. Even though I was young and dumb, it struck me as a bit lame: nerd bullshit with fiddly setup. The async aspects of usenet and email struck me as more scalable, and the web had, you know... graphics.

I had to use IRC again in 2015, and pretty much nothing had changed, except now I was 20 years older.

Most of the criticisms of Slack seem to boil down to: this (whatever it is) is something IRC could do. But it (whatever it is) is virtually always something IRC doesn't do, something it does in some half-arsed fashion (that requires a huge amount of fiddly setup), or something that's supported by only a few clients. How is this not obvious? I'm perpetually mystified that anybody would admit in public to not understanding why Slack is taking a massive dump on IRC.

(Criticisms of Slack's closed nature are valid. It's also worth asking why it has to take up 2GBytes of RAM just to show a tree view, an HTML view and a text box! But don't tell me that you can't understand why Slack is winning anyway.)

I don't even know how to shoe a horse.

"And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it."

It's not a generational thing - it's a "lifer" vs. "non-lifer" thing.

Some people are coding with computers because it's an exciting, lucrative career with great benefits!

Other people are coding with computers because they can't imagine doing anything else, and would do it for free if IT wasn't central to business in the 21st century.

Slack chat provides a number of nice features that IRC (at least out of the box... I know there have been attempts) does not.

IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.

So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).

A better IRC client isn't going to provide chat history.

An IRC bouncer (e.g. znc) can do this, but it's far from seamless.

Just run your IRC client in screen/tmux like we've done for a quarter century.

The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...

Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it generally works.

> The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...

Which can also be done with IRC clients.

This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4

Quassel is a distributed system, so you have a bouncer and client which integrate tightly, with clients for Linux, Windows, Mac, Web, Android, iOS, which stores backlog in a database.

This search system is a very simple one, and simply uses postgres’ fulltext word vector search.

This is the first I've heard of an IRC bouncer. That's a great idea. It still seems like it's and extra step you have to add though, when really it'd be nice to see some work on IRCv3 so you could have multiple clients connect to one IRC server with the same username and sync without the need of a proxy.

The current answer to that is basically "Use IRCCloud", and that's what I link people who don't already know IRC to.

It's a web/android/iphone client only, but it's IRC. The moment someone grows tired of the client, they can get their own.

When I was a wee lad I was always envious of people on IRC who had these things called "shell accounts" that let them stay connected to IRC 24/7.

They could schedule downloads to their remote boxes and wouldn't have to tie up the home phone line for three days downloading the latest warez from that guy who had an ISDN line and let 10 people(!) simultaneously download from his bot at a screaming 5k/s.

Now I can have all those things (including the equivalent of 1000 ISDNs), and I don't really use IRC anymore, young me would be so jealous.

Encapsulates this era as the battleground of silo'd "as a service" vs "can be done"

For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam.

In IRC I could do it... google implies there's a ZenIRCBot project on github and probably many others. Probably there are bots and tools that google didn't immediately find.

Its not rocket surgery to use fetchmail and some kind of Perl IRC library to simply POP everything out of a mailbox into a directory /tmp/wtf and probably about 3 lines of perl to read all the files in /tmp/wtf, connect to irc on some channel, output what it found, and if successful delete the emails from /tmp/wtf. Then put fetchmail and the 3 line perl script into cron and away we go.

Looks like Zapier is kinda in between "I could do it" and "AAS"

Jenkins has a IRC plugin, already in the stock distribution. Jenkins bot idles in channel, and logs all sorts of failures or successes, or whatever. With the irc server + channels setup, this also takes less than 2 minutes.

You can have Jenkins send IRC messages using a single invocation of netcat. This should take less than two minutes.

"log in to slack" vs. "deploy 3 services in the cloud by yourself and force everyone to use a specific irc client (good luck)"

There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.

> There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.

So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.

How is that better again?

That said, IRCCloud already does it for free, in the cloud, just works™, and the Quassel people are also working on improving ease of use and deployment.

> So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.

You aren't paying "someone" you're paying an entire company that is dedicated to making the application highly available, with all the bells and whistles, with zero hassle.

Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.

> Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.

If HN has higher discussion quality than reddit, why are not all devs on HN instead? If Linux is better for servers, why are people still starting projects on Windows? etc...

The power of marketing, directly or word-of-mouth, is important. And a decentral community can never do as perfect marketing as a company can do.

There are IRC clients and apps, and third party integrations as powerful as Slack, and as easy to use. But you have to find them, install them separately – there’s no single combined effort to market a single "just works" solution, yet ;)

How many people maintain their own email servers vs. use gmail?

Slack doesn't prevent you from accessing your data, in fact they explicitly built exporting features.

We're talking about open source, so reading your stuff shouldn't be a problem. For proprietary, maybe, but even then, reading someone's private slack info would be highly damaging to their brand, and to what benefit?

You can get upset over this and argue with people, but that's not going to make anyone choose IRC over Slack.

Slack, Hipchat, Campfire, etc. are all just IRC for normal people. There is without a doubt a barrier to entry to IRC that actually requires a bit of understanding of how the protocol works. "I'm in #this-channel-you-told-me-about, but no one else is in here, wtf?". "Oh, you're on the wrong network - it's EFNet, not Freenode".

There is no such barrier for the current set of chat apps. Download > Login with google, start chatting with the person who invited you. Search history? File sharing? No need to remember anything about dcc/xdcc, no need to manage servers running bots, no need to manage anything, really; it's all taken care of by the nerds that run the service.

I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).

I think, however, that IRC will remain in some ways as a small haven from eternal September (haha, yeah, I know). The barrier to entry is a feature, not a bug.

> I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).

Someone did, it's called IRCCloud.

That's the entire problem I've been talking about above: Anything you can imagine regarding IRC already exists. The only issue is that you don't know about it yet, and have to find it. And without marketing, or any lists of what is good and not, this is hard.

Then start actual marketing. And make sure that I can switch from Slack to your product without any hangups, and have exactly the same feature parity, especially for non-technical users.

"prevents you from accessing it"

with respect to something like e-discovery its all a matter of perspective. If this were true, which it isn't, I wouldn't necessarily mind, as the financial worth of combined ancient IRC logs is unquestionably a net negative value.

> Just run your IRC client in screen/tmux like we've done for a quarter century.

Wait... did you just tell me to go fuck myself?

I believe they did, Bob.

Or you can use a web based interface like the lounge.

Yes it is. This is exactly what Quassel and IRCCloud do.

A few people have replied, saying how to get chat history with IRC, but as far as I can tell, none of them work like Slack. With Slack, you can see history from before the first time you connect. It looks like none of the IRC solutions enable that; the IRC protocol doesn't make it possible, without the server (or a channel member) keeping logs.

(I haven't used either very much, so please correct me if I'm wrong.)

IRCCloud can, they're a client too :) I highly recommend them if you are serious about IRC.

But yes you're right, nothing in the IRC protocol for it. There is something in IRCv3 to provide chat history but I don't know if it's even in the current version of the spec.

https://www.irccloud.com/

How does it do this? When you use IRCCloud to go to a channel for the first time, where does IRCCloud get the history for that channel from?

(You say "they're a client too" - I confess, I don't know what they are apart from a client.)

Like I was saying, IRCv3 has support for replaying the channel's history, as long as it's stored serverside. But I don't know if anything actually implements it, even IRCCloud which is v3-compatible.

At the moment if you join a channel you can't read its backlog, no. They could implement it though if they used logs from their users... kinda wish they would. But hey.

> At the moment if you join a channel you can't read its backlog, no.

Then I'm not entirely sure what you were referring to, when you said "IRCCloud can". Backlog from before you joined the channel is the specific feature that I was saying couldn't be done.

It's interesting to know that IRCv3 does have that support, so I was wrong about it not being possible. But if nothing implements it, it's not very helpful.

We are talking Open Source Project Communication not small group communication.

IRC and FreeNode channels have been the standard for communication and not for archival purposes. I use an IRC bouncer with my home server and I never look back through the thousands of communications except to see a reply to my question.

Why does a Open Source Community channel need archived communication unless it is just a few developers only chat?

"A better IRC client isn't going to provide chat history."

That's not even wrong.

IRC as a protocol is very outdated. If I log in at home and forgot out log out at work, I need another username.

IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support.

We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS community needs, but it's also very difficult to contribute to projects when you're already doing 40 hours a week at a day job.

Today I feel like most of the OSS projects that are getting support are ones that are corporately supported:

http://penguindreams.org/blog/the-philosophy-of-open-source-...

> but there's not a whole lot of movement on it. I think FreeNode has some v3 support.

That’s as wrong as you can get.

Networks with support, ranked by amount of supported features, are: InspIRCd Testnet, EsperNet, IRCCloud Teams, Snoonet, Rizon, IRCHighWay, freenode: http://ircv3.net/support/networks.html

Clients with support, ranked alphabetically, are:

Desktop: AdilIRC, BitchX, ChatZilla, Colloquy, Conspire, Hexchat, IceChat, Instantbird, Irssi, Konversation, KVIrc, LimeChat, mIRC, Mozilla Thunderbird, Quassel, Textual, WeeChat.

Web: IRCCLoud, Iris, Kiwi IRC, The Lounge, Mibbit, Quassel-Webserver

Mobile: AndChat, IRC for Android, AndroIRC, Colloquy, IRC7, IRCCloud, LimeChat, Palaver, Quasseldroid, YAAIC

Bouncers: Quassel, ZNC

Bots: Limnoria, Sopel, Moon Moon

http://ircv3.net/software/clients.html

And libraries are: cinch, Communi, irc-framework, Kitteh IRC Client Library, Net::Async::IRC, pydle, Rust irc, Warren, zIRC

That’s quite a whole lot of movement. That’s every project related to IRC

"If I log in at home and forgot out log out at work, I need another username."

You don't log into irc from your work or your home or your anything.

You run screen in your shell account and log into irc once and never log in again.

Christ - do we need a refresher course here in how to use the Internet for the incoming freshman class of 1994 ?

Kids these days use tmux.

Not everyone is going to use the same client.

The problem is that you might be running a nicer IRC setup, but almost nobody else is. Doesn't do you much good if everyone else logs off the second they close their laptop lid, or can't scroll back up to see what you just said because they had to relaunch their client.

Chatting is interesting because of other people. That's why I'm chatting.

In Slack, I can ping people that are offline. And all they have to do is open Slack again or reconnect to the internet and they get notified. I don't need to count on them being an IRC veteran.

All these people pointing out ways to enhance your personal IRC experience are missing the point.

Oh yeah, and I can post code in Slack.

Slack only provides a bit of history unless it's a paid account. What open source community could support that many paid users on Slack?

That "bit of history" goes a long way, though. In particular, it means you don't lose context when you disconnect temporarily, which makes a huge difference for both mobile and laptop use cases. (Obviously, this is also one of the reasons why bouncers were invented for IRC - and why they're popular. But Slack having it out-of-the-box is a huge yak saver.)

There's also TheLounge and ircanywhere which try to be FOSS IRCCloud

Eh, no, if you want to get a FLOSS product comparable to IRCCloud, Quassel + Quassel-Webserver are more appropriate comparisons.

TheLounge and ircanywhere are missing a lot in comparison.

What is Lounge missing compared to IRCCloud?

Mobile.

And other projects, including the GPL project Quassel, do have mobile clients (although Quasseldroid, which I maintain, isn’t exactly the best client in the world).

Lounge has a responsive view you can save to home screen on iOS and android. Looks like this: http://i.imgur.com/MmajSU1.jpg

I've seen it, but it's nothing like even Quasseldroid. And quasseldroid is already a horrible codebase (mostly because I took over maintenance when I knew nothing about code quality).

Yet even Quasseldroid manages to be better.

That said, there is truly a need for a really good, FLOSS irc client ob mobile.

You're saying they're nothing like each other but are providing no examples. Besides one being an app and one being a website, what are the differences? Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.

EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of transition from ES5 -> ES6)

> Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.

Quassel actually has both of those, but they’re still in separate projects atm: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4, and will only be integrated into the main codebase in the next version.

That said, the performance of Quasseldroid, due to the nature of the thing, is a lot better.

Quassel has them, doesn't mean Quasseldroid does :P

And I don't think you can say due to it's nature it's faster... I run Lounge in 20+ active channels on my iPhone SE and it runs perfectly. Native != more performant (and if the code base is as bad as you say I wouldn't expect it to be).

The bad part of the codebase is bugginess, and RAM usage. Especially because it always keeps all messages in RAM.

But what I consider a bug is already the best case scenario for the web client.

And 20+ active channels is nothing.

I'm in 460 active channels, with combined 40'000 users, and I get about a hundred to 200 messages a minute, while using the app on 64kbps connection.

(That's my test case for what should usable)

And quasseldroid already has code for those two, and a rewrite is almost done, I'm just waiting for the core changes to happen, and then release version 2.0

IRCCloud's chat history is quite bad. I still find myself leaving bots in all chats to be able to grep logs.

If not primary, at what percentage is it a core form of collaboration?

WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.

The OP does make a fantastic argument on the open/public point, but synchronize communication is also a necessity for collaboration.

> WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.

The WordPress community Slack forced Slack to implement some server-side changes when it hit ~5,000 people though (I don't remember the exact number, but I remember when things started to not work), and I suspect it's the largest resource-consuming instance in my Slack client.

Slack is successful because IRC web clients are so cumbersome and annoying. Most of the things Slack provides easily could've been provided in a web-based IRC client, but where's the upside for Slack in that?

By adopting an incompatible web model, they lock people and their messages in, and can charge per user in the room. As a good IRC client, the most they could get away with is a subscription charge per client, which has the downside of creating a barrier to entry that limits adoption (requires everyone who wants to use it to pay, v. a central employer or organization that can compel people onto a chat platform).

Users like web-based because it means that they just click a button and the thing they want magically appears with no install process. Companies like web-based because it allows them to box all the secret sauce behind a server that can't be introspected. There's no risk of someone cracking their program and distributing it for free, and they get to keep complete control over the crown jewels, which are now and always have been the data that the program purports to manage.

"What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel"

Just keep your hands off my mailman ...

Reply on news.ycombinator.com