May 8, 2015 Tags: irc, programming, rant
Note: Apologies for the late posting on this one. It’s been ready for a while, but the combination of finals and the death of my SSD delayed it slightly.
It should come as no surprise to anybody that IRC is on the decline.
After a brief peak in the early and mid-2000s coinciding with the peak of the Warez groups, IRC has become virtually forgotten outside of the programming and piracy communities. Even the Big Four (Freenode, IRCNet, QuakeNet, and EFNet), which hosted millions of connections just a decade ago, now host just over 200,000 combined at peak hours.
There are some good reasons for some of this. IRC is an extremely basic protocol, and provides nothing directly analagous to the multimedia features found in Facebook’s (XMPP based) Messenger, Microsoft’s Skype, Google Chat, or even older competitors like AIM. The world of IRC clients and servers is the wild west compared to these services, with auxiliary and occasionally contradictory protocols like CTCP, (X)DCC, and IRC-over-SSL making the process of setting up clients too technical for the average user.
And yet, IRC has been a mainstay in the programming community since the day of its creation. The simplicity of its protocol makes extension and bot-writing easy, resulting in thousands of bots, hundreds of clients and servers, and dozens of informal standards shared between channels and communities. Combined with the low bandwidth required for messages and the high reliability of the major networks, IRC is about as good as it gets when it comes to widely used and open real-time chatting protocols.
So why, then, are so many programming communities and groups shying away from IRC?
Services like Slack and Gitter have become increasingly popular, with open source groups like WordPress officially switching away from IRC in favor of more tightly integrated chatting systems.
These services provide things that IRC doesn’t, at least not out of the box:
I can understand these reasons, as well as how intimidating and inscrutable IRC can appear to newcomers. I don’t even dispute their importance to general-purpose chatting (Snapchat’s model singlehandedly demonstrates the value of multimedia). The problem, I believe, is shortsightedness:
Slack and its ilk are entirely closed-source, or largely closed with specks of open source projects sprinkled in (a la GitHub). I don’t have any problem with closed-source software, but I do have a problem with open source communities relying on services that can disappear overnight. When both client and protocol are opaque, there’s no clear recourse for the community.
This isn’t a huge problem with respect to services like GitHub, because A.
GitHub is massive and B. GitHub’s service is a convenient superset of that
provided for free by git and any software that accompanies it. However, when
the service is entirely homegrown and closed, nothing insures its users. If
communities transition to independent and for-profit services for their chatting
needs, they will find themselves vested in the success of an unrelated company
- a dangerous position for groups that often lack the resources to host their
own projects.
Just as closed source software is not just a problem from a reliability perspective - it’s also a problem from the perspective of advanced users. One of IRC’s biggest attractions is the dead simplicity of its protocol - no more than 512 bytes of well-documented plain text at a time. As a result, IRC is an great way to introduce novice programmers to topics ranging from string manipulation to network programming to multithreading, all while providing the instant gratification of messages popping up in the channel. I’ve written before on the educational value of IRC bots, and I maintain that a large part of that value comes from directly interacting with the network with no APIs or abstraction layers to guide you. That’s not to say that APIs or abstraction are bad, because they aren’t - it’s to say that the best driver is the one who built the car.*
Chatting services may provide APIs that allow for some automation of actions on their networks, but that’s all it is - a veneer over the actual interactions between clients and the server. As clients on a closed network, access to that API is wholly dependent on the whims of the company. Nothing stops the provider of a closed service from changing their API, blacklisting your program, or (worst of all) extorting money from its users by holding API access hostage. Terms of service and promises of stability mean little - terms change every day, and can be applied as loosely or tightly as suits the business. Even if your community’s needs stop at the integrations provided by the service, remember that nothing obliges the two services to cooperate, or even to inform each other of changes to their own APIs. As an individual user of a chatting system, your power is greatest when both services have to negotiate for your usage, not for each others’ through you.
I didn’t intend this post to be an attack on any service in particular, but as a warning against relying on private, closed services to provide something that public, open services have done for 20 years.
IRC isn’t a perfect protocol and it’s certainly antiquated in usage, but that doesn’t stop it from satisfying every single one of the features I listed above. Thanks to its open nature it has been supplanted by auxiliary protocols whenever a new need has arisen, whether that need be client metadata (CTCP), direct communication and filesharing (DCC), or automated services (NickServ, ChanServ).
These points aren’t only relevant to IRC - every open communications protocol is capable of these things. IRC is particularly dear to me, but XMPP is just as (or more) capable of filling such a role.
At the end of the day, IRC’s “decline” should not be used an excuse to move to sleeker and “simpler” closed services. Instead, communities should be looking at how they approach chatting in general and proposing extensions to the open tools already at their disposal. Via this, it’s possible to all those modern chatting niceties we demand to the open platform we deserve.
- William
* I’m taking license here - I have absolutely no idea whether or not auto mechanics are usually good drivers. Common sense and lived experience may diverge here.