I think this is a really important point. What Slack solves -- speaking in the general case, not specifically for FOSS projects -- is that it's an essentially out-of-the-box solution. Not just for non-technical users, although that's very important, but for all users.

Both the linked article and the various suggestions in comments give all sorts of IRC-based alternatives to what Slack does, but they're all things that, let's be honest, require a lot more work to set up and are often far more fiddly to use. "Oh, this is easy, just run daemon X for this functionality and daemon Y for this functionality, and set them all up using stuff you can get here, here and here. Wait, that last one is out of date. Try using this gist instead. Okay, now, you can get that client-side feature you want if you switch to a different IRC client, use the following .config file, and look for the following plugins, although you'll probably want to change the defaults..."

Compare this to Slack, which for most users is: sign up, click here, and in Jeff Goldblum's words, "There is no step 3." From a practical standpoint you have to install zero new pieces of software (assuming you already have a browser), you have to edit zero fiddly text files, you need to install zero Perl scripts. Once your IRC is set up it seems "easy," but it's possible to spend an inordinate amount of time finding the answers not to questions like "how do I get snippet previews of links to show up in the client like it automatically does in Slack" (the answer is probably that you do not), but questions like "how do I get all the nicknames to show up in different colors?"

For certain FOSS projects, this may be less of an issue because the team may be more experienced in setting up frankly fiddly Unix software, and I think having an IRC channel is a good idea. It may be all you need; what Slack gives you above IRC is generally "nice to haves" rather than "must haves." But the FOSS crowd, to make a very rough generalization, often tends to deprioritize "nice to haves" to a point where they miss, well, just how nice it really is to have some of them.

You're absolutely right. But it's sad that comments like this even need to be made. Like people constantly forget that usability is a thing and not everyone has infinite free time to burn on setting things up.

As someone with no ops experience, can't most of this automation be done with Puppet or Chef? If so, is there anyone with public github share of those files?

As far as I know, most of this complexity surrounds setting up the _client_ software, not the server bits (though that, considering availability and so on, is its own bucket of worms) -- you just don't get Any Random User to install Puppet or Chef and pull in a cookbook or recipe or I don't know what they're called and ... well, I guess you get the point.

That's funny, the lack of any good clients is why I dislike Slack and prefer IRC. And while Slack does offer an IRC bridge, it's not very good either.

I sort of get why people like Slack. It's very low effort. But that's the only advantage I see.

I think it's that it never gained a groundswell in the US. In Europe, and I can think of sweden and norway in particular, there were all sorts of completely technically illiterate people on IRC. Their friends just showed them how to download the client and connect.

I remember using IRC in the early 90s here in Norway, there was basically a channel for every municipal, school, social group etc. Even my mother used it.

That anyone find it hard to use is flabbergasting to me as it is a matter of opening a client, entering a nick and selecting server. With the web IRC clients it's even easier I guess.

I still hang out in several of the channels from my early days :)

Yeah, nothing about IRC is intrinsically difficult. There's some things that are much easier on Slack, like archive search, but how many people actually use that?

If you tell people something is hard to use, they'll believe you. If you tell them how to use something, they'll use it...

The really big thing for me is persistence. If you want your client to stay online when you are not, things get very painful. Bouncers are a pain to setup, command-line IRC clients are awful, and I've seen countless people horribly confused by screen and tmux.

With slack, persistence comes for free. The only thing I've seen that comes close is irccloud, which is in my opinion an excellent competitor to slack. In the end my organisation went with slack because it's nice to have everything grouped and billed to the organisation, as well as being even simpler for end users to join.

Bouncers are a pain to setup? You can literally order pre-setup bouncers with web interfaces... it really doesn't get much easier.

As opposed to IRC's NickServ, ChanServ, and their variants depending on the server? Expired nick, exposed passwords due to insecure authentication mechanism, no standard client, and so many more I can cite.

I love IRC and grew up with it. But don't compare it to Slack for technical knowledge requirement.

> exposed passwords due to insecure authentication mechanism

Use SSL + SASL auth and it's not any less secure than logging in to most websites.

I know people who don't understand what a Server is and even they can use IRC. Not saying that it's as simple and convenient as Slack, but making it out to be this huge complex thing is being disingenuous.

My PM was able to set up Slack integration with Trello and Github in a few moments, and found that connection incredibly useful. She didn't have to KNOW that she wanted it, she just saw it on the list of possibilities. She didn't have to go looking for instructions, she just hit connect. She didn't have to ask me or one of the other consultants to stop billing project time to set up some tech for the office, she could do it herself.

In my firm at least, Slack is an incredible tool for our PMs and owner, and it also works well and covers all use cases for the consultants.

I thought SASL integration was pretty secure!