Also a good notification system, multiple session support, native mobile clients, easy third party integrations, baked in searchable history, team support, and easy enough for the non-techies to use.
> multiple session support
There are web-based IRC clients that support this. In fact, I would not be surprised if under the hood Slack started out life as a web-based IRC client - it's a very similar (though much more polished) experience.
> native mobile clients
There are native mobile IRC clients; and Slack's mobile client is nothing to brag about - I've seen it take 10-15 minutes for messages to propagate to the mobile app. It also tends to hang frequently when using it.
> easy third party integrations
I don't know that it gets any easier than IRC - it's a plaintext protocol that's open and well-documented, and even easier to use than HTTP. As a kid over 25 years ago, I wrote an IRC bot in Perl - and the protocol hasn't changed a lot since then. There are mature IRC libraries for nearly every programming language / stack.
> baked in searchable history
Granted - this doesn't exist by default in the client - but an Open Source project could easily set up an IRC log bot (of which there are many, and they provide interface / search / etc). And then you can just search the history via private message with the log bot.
> team support
This is a management feature; you can also easily just create password-protected channels (yes, this is a feature of the IRC protocol and not any particular client).
> easy enough for the non-techies to use
IRC is a little more difficult than Slack, but then again I don't know that most open source projects have much reason to interact with people who are not technical enough to connect an IRC client (at least in the scope of the project).
That misses the point entirely.
Sure I'm a technical guy, I could spend time figuring out how to make an IRC chat robot that would maybe offer a third the features Slack ships with out of the box. But why should I have to? I certainly don't enjoy it.
If I'm working on an open source project, would you rather me spend hours configuring IRC, or working on the open source project?
I benefit just as much, or possibly more, from improved usability as your non-technical grandma. And as long as attitudes like yours are prevalent, IRC ain't never gonna beat Slack.
You shouldn't have to; but Open Source projects tend to be (with good reason) wary of using closed-source products like Slack. You can't foresee what the needs of an open source project will be in 10 years, or whether Slack will still be around then. Should something happen to Slack (they go under / get purchased / decide to terminate non-paid accounts / whatever), you'll be relying on their APIs and service to recover your data and maybe migrate it to a new platform. They can make all the promises they want today, but who knows what their business looks like in a decade.
Anyone remember SourceForge? GitHub is at least just a set of management tools / interfaces on top of a relatively vanilla Git repository (and Git is open source). Ideally, someone would build a web-based IRC client with all this functionality integrated and call it a day - though I suspect that's how Slack got started, and the restrictions they have are just so they can make some money from selling their product.
I mean, you need 4 pieces of information to connect to an IRC server: Server name, port, a username, and the #channel name you want to join (most IRC networks provide user and channel registration services via "admin" bots).
And that attitude is why most people won't take open source seriously.
(And my current rewrite of QuasselDroid will do so, too)
