https://matrix.org is an open standard defining a communication protocol. The goal is to have an open ecosystem where any app can talk to any other app. You can talk to Matrix either natively - or via a bridge. We already have written bridges to IRC, Slack, XMPP and libpurple - if you visit #matrix on freenode you are also talking in the #matrix:matrix.org (https://vector.im/beta/#/room/#matrix:matrix.org) room in Matrix (and vice versa).
You can even connect to Matrix via your IRC client via http://pto.im/
Matrix is decentralised, you can run your own server (clone our server or write your own) and servers will create federated networks on a need-to-know per-room basis (see http://matrix.org/#about).
Matrix is free software, all our code is Apache2 licensed, you can clone it (https://github.com/matrix-org) and use as-it, modify it - or write your own client client and/or server (http://matrix.org/docs/spec/r0.0.1/)!
disclaimer: I work for Matrix.org!
I'd suggest making it clear that Vector is by far the most user-friendly way to use Matrix if you want to attract non-technical users to the service, but otherwise, well done.
Now, they mention that it can be used for decentralized machine communication too. I wonder if there any projects taking advantage of that.
EDIT: clicking on https://vector.im/beta/#/room/!cURbafjkfsMDVwdRDQ:matrix.org takes a long time to load. is this a consequence of the server ..or is the protocol slower ?
A lot of the features you mention are better served by email, and I am completely opposed to editing messages after they are sent (chat is append only!) There are IRC bots for ticketing/build integration, and they were around long before anyone used Slack!
But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom. Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects. The ethical replacements (not alternatives, because Slack cannot be considered as an option) aren't going to get better if people aren't using them!
It seems incredibly reductive to state that using proprietary software, in any way, somehow makes a FOSS project send an implicit message that it... I don't know what you meant, but, disrespects its users?
Did I disrespect the users of FOSS projects I worked on by using Windows / Visual Studio?
You can try to bludgeon and guilt people into using open source tools, but the problem is fundamentally that the tools that are Open Source are /failing/ a set of users. If you fixed the tools and ran HipChat and Slack out of business with Open Source competition, we wouldn't even be having this discussion. Lecturing people about Freedom(tm) and "Devsplaining" to users why they don't want the features they tell you they want isn't going to work.
If you want people to get off of Slack write an Open Source alternative that Slack users will freely choose to use instead. Compete in the market and win -- or else you're just pissing into the wind.
That makes no sense at all. Firstly, most people working on free software don't make assertions like, "My free software is good enough for you." Most of us are much more realistic and assert something more like "My free software might be good enough for you, here's why you should consider it."
Secondly, even if one were making that assertion that one's free software is good enough for others, why would that mean they should believe all free software is good enough for everyone? It just doesn't follow.
I am completely opposed to editing messages after they are sent (chat is append only!)
This isn't relevant. Your personal communication preferences are not universal. Slack's popularity shows people don't care about this.
But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom
Most developers aren't as dogmatic as this. You're in an extreme minority. Which is totally fine, and you should try to convince others if you feel they should be convinced, as long as you recognize most of us aren't in your "we". It's not true that I must reject Slack.
There is no reason that an open source project shouldn't use proprietary software. This isn't a religion.
So like IRC? Telling everyone to "use Freenode" is no better than Slack, both are centralised. You might have more client choice, but you're still logging into someone else's server.
That's the crux of it. Some people just don't care and want to communicate. What is easiest to use is the only valid metric for the majority.
Then maybe those other free software projects should get good.
No you don't. You send the message that you're using what you believe are the best tools for your team.
IRC is open (VERY open), easy to use, and less centralized than Slack. The only real benefit of Slack is easier file transfers; but even then you could probably just set up an IRC macro to send someone a link to the file on Dropbox.
Now, the Slack client is much, much more slick than any IRC client I've seen. But if someone writes a great IRC client that looks like Slack (and has things like URL previews, etc), I doubt you'd have as many detractors.
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.
IRC has rock solid file transfer. Depending on your IRC clients, it's easy to use as well.
However, to be honest, for open source projects, 'chat' of any kind should be for quick and unimportant discussions, or help. Important decisions should be hashed out on mailing lists so that people in other time zones can participate, so they get archived, and so people can take their time to write something that is well-reasoned.
What happens when a topic of discussion is debated intensely on a different timezone and you wake up to more than 500 messages to read? Do you read them all?
I think this is a reason for people who really don't engage on IRC for anything other than "Hi, I have a problem, can anyone help me?".
If you do anything meaningful and engage on different channels you know there is no keep up with everything being said or discussed.
Sorry if I sound harsh but I keep hearing the same tiring argument and keep pointing people to the same thing over and over and over. If you want IRC and history, please use an IRC bouncer. With Docker and cheap hosting solutions it's almost a no brainer. Do one better, add SSL to your bouncer and connect to, at least on Freenode, using SSL as well. Win-win.
And don't suddenly bite you at 10,000 messages. ;-)
What about all the integrations with other services?
It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?
Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source.
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.
``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? :)
Surely this suggestion can only seriously be made for projects that are also not hosted on GitHub.
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?
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?
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.
That way the slack-only features could be offloaded to another open source service or protocol.
By the time that protocol mercifully died the thought of implementing a client would rightly give programmers nightmares.
The argument I see in this thread (not yours necessarily) seems to suggest that in order to implement modern features demanded by users we ought to favor grafting plugins and protocol extensions on top of IRC rather than use something that actually supports said features out of the box.
Why not just use Matrix.org?
Having a standard and a committee usually means that something has stagnated, not that it is alive and improving.
Matrix (as someone with the project has already replied to your comment)
Zulip
Mattermost
LetsChat
RocketChat
(I realize that it has other features, like automatic logging. But, on the one hand, to suggest that people making meaningful and useful patches to open source projects would be incapable of figuring out IRC is absurd, and on the other hand, to suggest that putting a typical IRC client in a web browser with few other UI changes is some kind of major ease of use shift is equally absurd.)
For any wide-usage FOSS project, that'll describe quite a lot of their users.
> Gitter is bad for many of the same reasons Slack is. Please don’t use it over IRC.
- User experience. In 2016, I'm not using the hacker's AIM to collaborate. I know many people love it, but there are seriously better options. Syntax highlighting inline and file attachments that Just Work are fantastic.
- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don't want to fix it because I'm not here to build a chat program or manage one.
Things I don't care about:
- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.
- A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.
There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people's needs, they would use it. It doesn't.
> - A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.
Give it time. You'll come to realize that there are some good reasons - many of them quite grounded in practicality - why those of us who have been around for a while place some value on these things.
I realize this sounds caustic, but to say "Well, you're wrong" without giving adequate reasoning beyond "I've been around a while, so I know better" contributes nothing to the discussion.
One might be "what if a product shuts down?" This has happened before with chat (Campfire being spun out of 37Signals) and wasn't catastrophic.
In fact, this could be a long-term positive (but short-term pain in the ass) since it forces stagnating teams to update.
Can we please put this ridiculous circular argument to rest already? You can say that about ANYTHING, it's a vacuous fallacy.
The real circular argument is "if only people used XXX they would love it!" That's not what I'm saying. People are choosing a new alternative to IRC because of the feature set.
Early on in the smartphone wars, the best argument from the Android side was "well just look at the adoption."
That isn't circular. Adoption is an important measure of "does this solve a problem people have?"
And almost all do. Even newer ones like Elixir that started with Slack have now a mailing list and an IRC channel.
Ideally those can be the same thing; see the current Mailman interface, or Discourse, both of which can provide a forum-like interface to a mailing list.
In that case, we are talking about the freedom of the user to use software as they wish, to study it and modify it to suit their needs, and to share it with others. We're not talking about the freedom to go about their lives as they wish---that's a separate fundamental freedom, although it can certainly be restricted by nonfree software. Ideally, that software would also be Free, but that's their own choice.
But we should never encourage the use of proprietary software.
If you're talking about the "open source" development methodology, though, then the argument ceases to exist, because freedom is not important enough to discuss, and so those who adopt that perspective won't understand why it's bad to recommend Slack to someone, or even require it.
So perhaps I'm hoding it wrong, but I've been using ZNC for a couple of years and every time I forget to close Xchat at work and people keep talking, I can't see what they said on my phone or at home. Also I can't scroll up nor search for stuff which were said in the past.
For me that is the biggest drawback with IRC.
A sensible alternative, which I also was able to push at work, is Mattermost http://www.mattermost.org/
Although I would love to see us using http://matrix.org/ but I don't expect our customers to install their own instance so we could federate any time soon.
Ever heard of Quassel?
An IRC bouncer where the client integrates with the bouncer – just scroll up to load more backlog.
Disclaimer: Am working on Quassel.
KeepBuffer = true
Buffer = 5000- Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end.
- Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.
- In hindsight, a lot of the FOSS-friendly alternatives (Matrix, Gitter, etc) are quite good and I should have put more effort into researching them and discussing them in my article.
It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, not in general.
I'm curious and need help finding a link to this source.
https://facebook.github.io/react/blog/2015/10/19/reactiflux-...
http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
Don't get me wrong, I love a great many FOSS projects; but my entire life does not need to be constructed of such. Posts like this smack of dogma and fanaticism to me, and engender mistrust of whatever projects the person in question is a part of. After all, if they're that dogmatic about one thing, then what's to say they aren't dogmatic about other things?
Today, you can look and see "Hey, Slack is a cool company. They get it. This isn't Microsoft of the 90's. They aren't going to abuse this power, they just want to make an amazing chat tool that improves all of our lives." (This is probably true) So it seems like it's ok to use Slack. The idea is that maybe this power corrupts eventually. Or maybe Slack as an entity may not always be run by people who get it. Maybe it's broken up into parts, or becomes a hollow shell as a holding company (cough Yahoo). Without an open platform and free source code, users are unable to move away.
The dogma is a rule that brings the potential long-term consequences to you when you're deciding what to do now. It gives you a twinge "Hmm, that feels dirty because it's proprietary. I'll keep looking". That way you don't have to imagine how Slack gets from Cool Company to Abusive Monopoly, you can just make an easy choice based on how you feel.
The choice I ultimately make is not always, or even often, open source. There is no blanket "always choose this" guiding rule for me.
Example: It's closed source.
Apparently that in itself is intrinsically "bad", and obviously so, because I've yet to see any explanation attached to that argument.
Using a closed source messaging system you never know, if 5 years down the line the company who owns you, and who is in control of your communication, decides that they would like to monetize your "contributions" to their system to synergize shareholder smileability, by adding ads to your projects channel.
Or they might want to change their pricing structure so suddenly the barrier to entry to your project is suddenly higher.
Or they get bought by google for their engineering talent and the whole thing ceases to exist.
Or they exclude the bot that you write and depend on a little bit from their network with no explanation given.
Or any other further or not so far fetched scenario in which the owners of the software can do whatever they want without consulting with you, leaving you with little alternatives.
Using a free protocol with free software, if these things happen wrt to the entity writing the code that you rely on or the the hosting of services you rely on, you're still inconvenienced, but these things do not impact you as much, because you're free to continue to use the code without the new sucky modifications, fork if if your able (or rely on some other entity taking over the code) and run the damn service yourself.
Forking and self-hosting aren't always the best solutions, but the more invested you are in a service the better they start to look.
They can sign up with IRCCloud (or any quassel-as-a-service provider), and instantly be online.
Webinterfaces, clients for all platforms, and bouncer is integrated.
Seriously, there are modern solutions for IRC, use them.
IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you're catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.
Namely, is it still intended primarily for intra-team collaboration, or can it handle communication with the public as well?
It actually is included with the gitlab omnibus installation package now, and then it uses gitlab's LDAP for logins. I just had to set a few options in gitlab.rb because I wanted to use SSL and to set the external hostname.
It is mostly used for gaming, but coding with it is just as great. There are a lot of public servers also for all sorts of things. (http://discord.me/servers).
The voice is what we love it for, chat is awesome during the day when some of us are not able to talk over voice.
If your biggest concern with Slack is the invite-by-email hack, try Discord.
This is much ado about nothing.
Everything else is politics and philosophy. Some people really get into the very specific politics and the very specific philosophies of the FSF. What they don't seem to get is that the FSF merely has one out of infinitely many perspectives on why open source is important and what people should do about it.
It's fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don't meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group's philosophy has some sort of primacy over the entirety of the FOSS world. It gets especially dicey when that group claims moral superiority over everyone else.
Instead of complaining about this or that FOSS project not being "true FOSS", the FSF should define a set of standards and practices that go beyond mere software licensing that DO meet their standards for ideological purity. Then a project that wants to comply with the FSF have an easy way to state up front that they are politically aligned with the FSF in every respect. Those who care about such things can use that information to set their expectations about how the project is run outside of the software licensing aspect. Maybe it draws them to the project, maybe it drives them away, but at least no one gets surprised and no mailing lists devolve into pointless political flamewars.
That way no one gets disappointed (for example) when a project wants to use Slack for communication, assuming that that project has not stated up front that FSF-compliant ideological purity is a goal. Alternatively, if a contributor to a self-declared FSF-compliant ideologically pure project wants to use Slack, the other contributors to that project have grounds for denying that on a purely philosophical basis. They can focus on maintaining their standards for ideological purity rather than continually arguing over whether or not FSF-compliant ideological purity itself is valid goal.
But maybe you don't care about freedom. I'm not sure why, but you probably have some shallow justification why "it doesn't matter for you".
Open is more than one form of software licensing, each license modified by the different idiosyncrasies and values of different people that develop software.
> Everything else is politics and philosophy
Open source IS politics as well. The origin of the term itself is a way to subvert Free Software
- doubling as an IRC client
- providing open source projects pro level services similar to github.
“these communities are not something we have the capacity to support given the growth in our existing business.”
Though I do think they realize that getting these communities on there spreads the word about Slack and that is a good thing.
As a reverse on your first point, and something I didn't know, it looks like those folks who don't want to get rid of their IRC clients can connect to Slack:
https://get.slack.help/hc/en-us/articles/201727913-Connectin...
What kind? A well organized, approachable irc client with an updated feature set to help share the things we do today. Slack has made channel based chat relevant again to a new, much wider audience. But it's not all new.
There was a time, however, where IRC made chat available to a much wider audience when it was much harder to connect.
Slack has done a nice job of positioning themselves near creating beginners and deserve the success from doing so.
I'm not sure how much more overhead open source communities would be over the free plans that already exist. Interesting to see that you can use an irc client to connect to slack.. just not sure why I couldn't use slack to do even more of my communicating in one place to be an irc client.
So if part of your team wants to stay on IRC and part wants to use Mattermost with file sharing and messaging across PC and phone, and integrate with Mattermost apps (http://www.mattermost.org/community-applications/) all that is available.
Well, I must admit, XMPP isn't the nicest protocol out there, and it has some issues (esp. with older software that implements it). One can't talk it with telnet client, and this is a downside. We've discussed it the other day: https://news.ycombinator.com/item?id=10900859
But it has advantages over IRC. To name a few:
- Universal federation. Private systems (that don't have S2S enabled) aside, any public XMPP server can talk to any public XMPP server. You don't need to have a separate account here, there and everywhere. Not that IRC really needs accounts (one can surely use it without signing up with NickServ etc), but sometimes it does.
- History access. Well, it requires server to have MAM (XEP-0313) support, but if it does, then everything is there.
- File transfers. Unlike Slack, it may not work for absolutely everyone but I think Jingle had gone through a lot of work and is quite capable of piercing quite draconian NATs. I'm not sure IRC's DCC is anywhere near. Well, and there's also in-band file transfers (XEP-0047) that's awful and sucks but still works for tiny content (short code snippets). And XEP-0363, although not many servers support it. XMPP's messiness has both down- and upsides.
- Integrations. I think there are as many XMPP bots as there are IRC ones. Either way, there are ton of libraries for most languages so one can hack their own simple XMPP bot literally in just a few of hours.
- Extensibility. XMPP can attach virtually arbitrary metadata to messages, or send extra information like typing notifications or delivery receipts. Well, it all depends on client support, but you don't need a committee to think of your own standard and make a ejabberd/Pidgin/Gajim/etc plugin or patch. And, possibly, think of compatibility approach for non-supporting clients. That's it. I don't think IRC has anything like this.
- OMEMO (of Axolotl/TextSecure/Signal fame). It's not mature, but one can already have multi-point end-to-end encryption for personal conversations. Sadly, not for chatrooms yet (MUC doesn't support PubSub, MUC2 aka MIX isn't yet here), but I'm sure it will work in the future.
Is IRCCloud not closed source also?
[1] Quassel is an IRC bouncer/client combination which handles things like backlog archiving and so on properly – you can connect with multiple clients at once, just scroll up to load more backlog, use web clients, windows/mac/linux/Android/iOS clients, etc.
(The backlog lives in an SQL database, so tools like Quassel-Suche can easily query it, and you can easily export it. I personally stopped using bookmarks, and just search for links through Quassel-Suche instead)
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) 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) 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) 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.
A huge part of users uses now IRCCloud, or their own ZNC or Quassel setup.
And creating multiple channels is never an issue to separate topics.
I'm not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) & Slack seems to solve most of the issues, but it not wanting to support large open source communities is an issue as well. There is a hole in tools available.
If you're doing FOSS projects, you can probably get your way around a command line enough to install and run both of these in a $3 VPS or even an AWS instance.
https://wiki.debian.org/UnifiedCommunications/DebianDevelope...
I'm not a DD, so can't comment on how well it works - but I've had it on my todo-list s while to look at their real-world setup as inspiration.
[1] https://lists.debian.org/debian-devel-announce/2015/11/msg00...
Previously submitted to hn, but didn't gain any traction: https://news.ycombinator.com/item?id=10531061
Ok perhaps that is a bit too harsh, but it is the essence of the argument. Its easy to get an open source tool that replaces IRC and works like Slack, you take $5M and you hire a half dozen engineers and a couple of designers and you build a set of tools and then you give it away for free and never see your $5M ever again. Welcome to the prisoner's dilemma, FOSS edition.
I've used it for a small team before but we quickly finished what we were doing and now it's dissolved. So I've been hearing awesome things about it and how people are using it and I haven't really had a chance to try it out. I've applied to join a few communities but I've never received a reply.
That process should be so much easier.
For open source projects or communities I think Discord fits the bill much better. It allows you to take part in multiple communities in one interface and you can use it without an official account.
My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.
If there was a client + bot setup that would offer the same functionality out of the box over IRC I'm sure we would have picked it up just as quickly. And I would have liked to be on the irc channel for a few of my favorite OS projects as well. But as far as I know, without there is no such setup?
Please don't repeat slack to IRC.
This is a solved problem - get it together slack!
I'm on 3 slack teams, one with some former co-workers, one for a non-profit that teaches coding and one for a side project.
If any of them suggested IRC I probably wouldn't have bothered.
As it is, I have the desktop client on my Mac Mini, MacBook Pro and my Windows laptop and the app on my iPhone.
It's great. IRC is not. That's my opinion. You don't even give any good reasons why it doesn't work for open source projects.
I also like how the "IRC is better for your company" section doesn't actually give reasons as to why it's better. It instead lists multiple services you can employ to achieve the features Slack provides out the gate.
So many things are better than IRC. Even Jabbr.net is better.
Developers need to get their heads out of their rear-ends. If IRC is so great, why doesn't everyone use it?
This endless argument has been fought in multiple other products and fields as well.