I think that's the problem with IRC. The idea of decentralized IRC networks means that channels are scattered amongst multiple IRC networks. IRC is already not as usable as Slack, and to have multiple networks decreases usability even further. I love IRC, but I see why Slack is full of win.
EFnet is a single entity in the exact same way that Slack is. All channels belong to only their service. Introducing yet another chat service only adds another place to the list. https://xkcd.com/927
It's also nice that I don't have to signup anywhere to use most IRC servers.
Don't get me wrong—Slack is the perfect tool for businesses, but not for much else.
I hate that argument. If decentralized was so great, then it'd be more popular, but it's not. More and more centralized stuff is exploding in popularity.
But that brings us back to mbillie and "if <x> were so great, everyone would already use/do <x>". Does popularity necessarily imply superiority? Adoption just means it's easy for anyone to get aboard. But that doesn't mean it's implicitly good, in any other way. Worse is better works, for example, if one option is more approachable than the other. Decentralization is good, as a rule of the thumb. Not having everyone on the same network, but having the ability to set up your own network or service based on the technology, is a good thing. Why would you want to have everyone on the same network? Networks are often topic-related. For example Freenode for programming-related topics. Minecraft is pretty focused on EsperNet. Quakenet used to be the place to online gaming. This is usefull and good, since communities sort themselves by interest, views, tools or what have you, by default. So why not encourage self-sustainability through means of decentralization?
Centralization is being driven by a lot of things, not least of which is that decentralization is really really hard. But a lot of it comes from mobile -- the idea behind decentralized apps before mobile came along was that bandwidth was not very dear -- oh, sure, it was limited in the days when IRC first became popular, but there was no reason to leave any of it unused. Local compute power was the same -- you may not have had a lot of it, but there was no reason to leave what you had sitting idle. Mobile is different. Idle CPU power can mean the CPU is throttled down to save on power and heat dissipation. Instead of staying connected to a server at all times, use "push" notifications so the server can let you know when it's worth using battery power and metered data to talk to the server.
Decentralized systems, and peer-to-peer systems, and even centralized systems designed around computers designed to sit next to a wall outlet and draw power from a practically unlimited source are all being replaced by systems that are more centralized and better equipped to talk to mobile. AOL Instant Messenger is dying because it was built around an older paradigm and, at least last time I bothered to try it, is an incredible battery drain on Android devices. Newer messenger apps that are built mobile first or at least make mobile an equal partner to PCs are winning instead. And it's the same for group chat -- IRC is built for old-fashioned PCs, Slack is built with mobile in mind.
It's also worth noting that it's not clear what decentralization brings to the table from the perspective any single organization. Most organizations will want a central authority for the history of their group communications.
Such facilities are bolted onto IRC, but never truly integrate with it the way other solutions have offered.
It's also harder to base a business atop decentralized network, and when building a new network there is less of a business case in spending the extra time, stress and expertise to make it decentralized (vs. centralized).
Let's state explicitly why it's harder to base a business atop a decentralized network - because a business makes money by creating friction in the service, and in a decentralized model a friction too strong will be routed around.
Well, I think it depends on whether you are talking about decentralized networks, as I read the parent to your comment to mean, or decentralized ownership/administration of networks, as I read your comment to mean.
That is, the network can be decentralized but still administered by a single business entity, in which case you theoretically get a network more robust to outages, or the network can be composed of many separate entities, in which case you are theoretically protected from the bad behavior of any one administering entity, since there are many others (as in your example).
The other reason it may be harder to build a business atop a decentralized network is that the costs associated extra hardware, software, and locations and troubleshooting required to achieve the gains of a decentralized network may outweigh the gains achieved by doing so.
