"Just build a bot" is such a cop-out. With the right "bots", you could make Unix talk(1) competitive.

The things that Slack does better than IRC are integrated into Slack. They just work, and the whole system is designed to make them work smoothly.

"Don't use Slack for FOSS projects because it's not FOSS" is an intellectually coherent argument. But "don't use Slack for FOSS projects because IRC is just as good" is not.

So IRC can do all this stuff, but nobody has done the work to do it. That is another way of saying IRC doesn't do this stuff. That might be why people like Slack rather than IRC.

``It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?''

Yes. It sounds... very much like this? :)

Actually, people have. They just haven't packaged it all up into a happy-clicky single click deployment. There is a little bit of configuration involved, but I have confidence that a majority of folks here could do it in two cups of coffee or less.

For me, it is Convos (web front end that uses redis for state tracking) + UnrealIRCD (IRC daemon) + Anope Services (channels, users, permissions, etc). It isn't as pretty as the Slack UI, but it could be.

I suppose I'm just perplexed at this persistent view that one can just handwave away the fact that IRC doesn't do everything Slack does simply by saying that it could.

Again, IRC != slack, they're not the same type of thing. IRC is a protocol, slack is a product built upon a (proprietary?) protocol that slack built to do pretty much the same thing IRC does (with arguably more features built in).

Also, no one is arguing whether people like slack more than IRC -- the point I'm trying to get across is that IRC is capable, but only lacks the development of a client, and forging of standards that would allow features that slack has.

All the bot stuff is copyable pretty much 1:1, the great design, and built in features of slack require a much better IRC client to be built. But that's the only thing standing in the way.

Taking the walled garden over developing an open source solution is widely accepted in the world at large, but it should not be the defacto solution for the FOSS community.

> Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source.

Surely this suggestion can only seriously be made for projects that are also not hosted on GitHub.

This is a good point, and the case can certainly be made that source code hosting should be done on sites that are powered completely by FOSS.

Neither Github nor Bitbucket (I use bitbucket more than github) are open source.

The shining hope is the darkness is Gitlab (https://about.gitlab.com/) though, which is a wonderful tool. That, and someone with deep enough pockets to start a publicly hosted gitlab that everyone in FOSS can use.

Not that I know much about Slack, but by using GitHub you don't give up control over your repository, or its history. Every single project member has a fully working copy that can be used if GitHub for some reason decides to go rogue, and it's accessible through open source software.

How about your communication in Slack? Can it be withheld or otherwise become inaccessible, or is it completely accessible through open source tools and possible to export continuously to a useful format? If not, then there's quite a difference.

That's true that many of the things I mentioned (not all) are possible through clients building in the functionality on their end, but that leads to another problem that slack can avoid, which is a unified interface for all users. While file transfers may be made easier on one IRC client that some users are using, it has to be completely compatible with the user who is connected through Irssi or another less capable client. This limits the possibilities of a client (which, mind you, is actually a big selling point for a lot of IRC users including myself). And I agreed on the fact that it's closed source and that can be an issue. But like I said above, that means that there is room for FOSS solutions, not that IRC is the answer.

@tptacek:

Slacks growing usefulness is predicated on the fact that people build bots for it.

It's not that IRC can be as good as slack -- IRC is NOT the same kind of thing as slack, they are different. IRC is a protocol, slack is not, slack is a product. My point is that the right product needs to be build AROUND IRC to make it viable/interesting.

From the previous comment, it seems like the features people are loving slack for are:

- Well designed interface

- File sharing

- Inviting/sharing channels with people

- Functionality provided by bots

Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?

Please reply to posts directly for the sake of keeping the thread tidy. If you don't see a reply link for a post, click the timestamp (e.g. "17 minutes ago") to go to the permalink view for a given comment, where a reply box will be available.

Thanks -- reply button didn't show up, wasn't sure why, didn't know about this trick to leave comments.

No worries... I'm not sure exactly why the reply button is hidden when this "trick" allows you to reply regardless. HN mods might be able to shed more light on this.

That's a neat trick, and not one that I knew about. I would also like to know why the reply button doesn't appear at times -- I presumed some kind of rate-limiting.

Is there a reason why the replay button doesn't appear sometimes? I always wondered about that.

To you and the others curious about why the reply button doesn't show up, there is a buffer period after a reply appears before you can reply to it, to mitigate flame wars and such. It's usually a few minutes.

Uhhh does that mean we just found a bug?

If you mean the fact that you can circumvent this, then I'm not sure. It's possibly intentionally left in so that more experienced users have a way around that limitation.

- offline mode integrated - search - usable mobile clients - inline images - notification control - usable interface for private and group chats - access control and authentication integrated

Probably more too.

But do any of those features feel like they couldn't be built into a good product built around IRC?

Anything can be built but irc has huge fragmentation of clients, so dev focus is thinly spread, developers have not apparently been interested in changing the ux for decades, and most of the (small number, despite what this article says) users like it how it is.

@tptacek:

Slacks growing usefulness is predicated on the fact that you people build bots for it.

It's not that IRC can be as good as slack -- IRC is NOT the same kind of thing as slack, they are different. IRC is a protocol, slack is not, slack is a product. My point is that the right product needs to be build AROUND IRC to make it viable/interesting.

From the previous comment, it seems like the features people are loving slack for are:

- Well designed interface

- File sharing

- Inviting/sharing channels with people

- Functionality provided by bots

Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?

@publicfig:

Not all? Which aren't possible?

And yes, it is true that slack avoids this problem -- the same way apple avoids having to deal with disparate use models for their hardware and software. You are arguing for a walled garden right now. That is the antithesis of what FOSS should be built on.

So this is the place where standards come into play -- by finding reasonable ways to implement these features ON TOP of a protocol, people can implement them (or NOT implement them) consistently across clients. As long as the feature standards were written to degrade gracefully (as in they would still work reasonably well if your client didn't support any advanced features), there would be little problem with clients that didn't implement certain features.

If you're using a client that doesn't support certain features, the beauty of FOSS is that you can actually change that client. You can make your tool better. That, or switch to a better tool?

That no one has built the interfaces for doing so?

There are interfaces and solutions for everything suggested.

Use quassel or irccloud as frontend and bouncer (on Windows, Linux, Mac, Android, iOS and the web), use the standard bots, etc.