The Freenode Situation Has a Larger Lesson - the Importance of Open Protocols

Tags:tech

(warning: this page is kinda venty!)

I'm assuming anybody reading this is probably familiar with, and is also probably caught in, the freenode situation which (at the time of writing) started a few days ago and is still ongoing. But for those who don't know or are reading in the future, here's the short version: the freenode IRC network, home to many opensource projects, has been taken over, and all the staff have left to form their own, seperate network, with many other projects joining them in an exodus of freenode. It's been a chaotic scenario for many communities, but it easily could have been far, far worse. A large factor in the damage control? IRC being an open protocol.

More details on the freenode situation

Let's look at a rough timeline of a community during the freenode exodus. This is obviously simplified, but this is how it went in multiple communities I'm a member of:

1. Admins and users decide that they need to move away from freenode

2. Discussion over where best to move to. Factors in consideration: server-wide policies, moderation

3. Admins register a room on another IRC network

4. Users, bots, etc. are registered on new network

5. As new users move over, the community gets re-established. Links are updated on websites. Life continues as normal.

I am not saying that this is in any way a trivial process. Registering on a new network kinda sucks, and stage 2, like any debate within a community, will likely have multiple disagreeing parties. The freenode situation has been a problem and there has been fragmentaton because of it and I'm not trying to deny that. From a layperson's perspective though, it's as simple as pointing their client at a new server, and things work exactly how they used to, because IRC is IRC no matter who's hosting it. In some communities I am part of, this entire transition happened in an afternoon.

Now, let's imagine what would happen if a similar event were to happen to a proprietary chat service, rather than an open protocol like IRC. Let's take a hypothetical proprietary chat network. I'm going to call it Cacophony. Cacophony gets taken over by a shady actor. Community members decide that it is no longer fit for use, and they need to move somewhere else. The community is well established, and has been using Cacophony's API, bot ecosystem etc for various purposes. Here's what the process might look like (and has looked like in other communities I have been part of):

1. Admins and users decide they need to move away from Cacophony

2. Discussion over where best to move to. Factors in consideration: server-wide policies, moderation, client app support, bot API support, corporate sleaze, features, what account people will need to sign up, "oh god not /that/ app! I hate /that/ app!"

3. Admins go create a room on the new chat service

4. some people can't sign up, the app doesn't run on other people's machines, some admin isn't happy with the tools they have, complaints about the UI, bots have to be entierly rewritten

5. Many users are used to Cacophony and don't want to switch to a new app, so stick around on Cacophony. A chat bridging setup is created that doesn't exactly work the way it should

6. The community tries to get re-established, but it's difficult. Nobody's really happy.

I understand that this sounds like a worst case scenario. But this is an /unavoidable/ scenario if you are using a proprietary service. As you are not on something that can be disconnected from the people running the server, if there is corporate or political drama, you are stuck, or you have to change your entire setup and workflow. With an open standard, you don't have to. Use your old client, use your old integrations, change a few domain names in the settings. And it stays working. This is why open standards are important.

go home