I plan to write a blog post on this at some point, but as a tentative short and rough draft: IRC's biggest problem is what I would loosely term 'Grunginess'. E

I plan to write a blog post on this at some point, but as a tentative short and rough draft: IRC's biggest problem is what I would loosely term 'Grunginess'. Every single thing I've seen associated with IRC has this kind of Unix/Linux-y grunginess to it where nothing is easy and everybody rolls their own solution. If you would like to experience this first hand, try setting up eir (https://freenode.net/eir.shtml https://freenode.net/eir.shtml) which is written in an unholy mixture of C++ and Perl. (The moment I see this combination I usually know I'm in for a ride.) Or try the python IRC library (https://pypi.python.org/pypi/irc https://pypi.python.org/pypi/irc) which has almost no documentation besides docstrings and needs to be puzzled out and examined and source-read before you can use it. You want to be able to see messages in an IRC channel when you're not on? Don't worry, ZNC (http://wiki.znc.in/ZNC http://wiki.znc.in/ZNC) is here to help, with powerful command line configuration action! Honestly IRC bouncers are kind of a red herring. Even if you can see what is typed in a room when you're not on using a bouncer, the real benefit of slack's message history is being able to see what's typed in a room before you joined, and being able to assume that this is a feature which is available to every slack user. Slack's multithreading is beautiful. One of the biggest problems with running an IRC channel is that IRC is fundamentally broken. And when I say that I don't mean it in the shallow way most people do, I mean actually literally fundamentally broken. Here's why: The average human reads somewhere between 150-300wpm. A decent typist types at 60wpm. If we take 300wpm as an optimistic estimate of average reading speed, the moment you're having a lively discussion the channel is swamped at seven participants or so. Slack makes multithreading easy by associating multiple topic 'channels' together for a single group so that you can talk about one topic in this channel and another topic in that channel and it's not confusing or unwieldy, people who want to hear about certain topics can subscribe to a channel and people who don't can just not subscribe or leave. You don't have this 'stepping on each others toes' problem where three people want to talk about this and three people want to talk about that and they all use the same channel to do it. Avatars, emoticons, that stuff is all a bit tacky but the core fundamentals of the design are a sound improvement over IRC, and IRC needs to respond to that.