Real-Time Chat Systems

Many projects offer real-time chat rooms in which developers can have fast-turnaround conversations with each other and with users. Such conversations often precede a bug report or some other kind of more formal, tracked contribution.

For decades, the standard real-time chat system for open source projects was Internet Relay Chat (IRC), which predates the World Wide Web and uses a text-based interface and command language. Starting around 2014-2015, a number of open source projects began trying out newer, web-browser-friendly chat systems, in particular the open source platforms,,, and the Matrix[51] protocol. (A few projects also experimented with the proprietary online chat service Slack when it was new, but Slack hasn't been widely adopted open source projects and I wouldn't recommend it for them. In a post written when that early experimentation was still under way, Drew DeVault lists some of the reasons why Slack isn't suitable:

I don't know whether any of these new systems will emerge as the long-term default choice for open source projects. Try looking at the open source chat systems used by similar projects and use that as guidance in choosing yours. Matrix compatibility (sometimes referred to as Matrix "bridging" or having a "Matrix bridge") is a good property to keep in mind, and if possible IRC bridging too, since some developers still like to use their IRC clients with non-IRC server applications.

Chat Rooms and Growth

A chat server is usually divided into virtual chat rooms. The chat application may call these "channels", or "streams", or something else, but the concept is generally the same: a chat room is a shared space in which everyone who is in that room can see every message posted to the room. Every project maintains a certain set of advertised, topic-specific public rooms; these are the entry points into chat for new participants.[52] Some projects maintain a "welcome" or "general" room specifically for newcomers to start out in, with current project members watching that room in order to greet new arrivals, but it's also fine to just have new people come directly into the regular rooms to ask their questions too.

Exactly how many rooms to have, and for what topics, will depend on your project, but it's best to start out with a small number of rooms — even just one — and only add more when it becomes clearly necessary. Much of the value of real-time chat comes from people being together in the same rooms and serendipitously seeing conversations between others. the section called “Handling Growth” discusses when and how to divide into more rooms.

Nick-Flagging and Notifications

Users who are new to such chat systems usually need some time to learn the conventions of real-time written communications. While each project has its own local customs, there is at least one convention that seems to be common in almost all projects: nick-flagging for notification.

A user's nick is their nickname, their handle in the chat system. It might or might not be some form of their real name, but in any case it is how they are identified in chat. When you want to speak to that person, you prefix your message with her handle (perhaps followed by a separator character such as a colon). Her chat client, upon seeing her handle used in a message, notifies her by whatever means she has configured — perhaps by flashing a notification popup on her screen (even when she does not have the chat window in front of her right then), or perhaps via an audible signal.

This notification only happens for messages that contain her handle, not for other messages. She may still see those other messages go by if she happens to be in that chat room right then — developers often "lurk" in a chat room just to see what's going on — but thanks to nick-flagging she can easily tell the difference between messages addressed to her and other messages. A message can contain multiple nicks, of course, in which case each of the corresponding people would be notified.

The ability for users to separate the conversations they are involved in from other conversations is key to successful use of real-time chat in open source projects. It is how a large number of developers can be in a "room" and all talk "together" without getting their different streams of conversation entangled. Each developer can tell which messages are specifically requesting her attention and which ones are not. It is analogous to an observation Deaf people sometimes make about the advantage of communicating with sign language instead of spoken language in a crowded room: as long as you have a clear line of sight to your interlocutor, the "noisiness" of the room (whether with signed or spoken language) does not interfere much with your ability to maintain the conversation. Similarly, a chat room can be very busy, but as long as everyone follows the convention of nick-flagging, people can simultaneously participate in their own chats and keep an eye on whatever else they're interested in, at least to the limit of their attentional capacity.[53]

Chat Bots

Chat rooms can have non-human members too, so-called bots, that provide automated services such as answering frequently-asked questions. Typically, a bot is addressed just like any other member of the channel, that is, commands are delivered by "speaking to" the bot. No special server privileges are required to run a bot. A bot is just like any other user joining a channel.

People who spend enough time in chat learn how to manipulate these bots and use them to help others. For example, when one user comes into a room and asks a common question, another more experienced user may issue a terse command to the local bot telling it to provide that user with a specific detailed answer that the bot has been previously told to remember.

If your chat rooms tend to get the same questions over and over, I highly recommend setting up a bot. Only a small percentage of channel users will acquire the expertise needed to manipulate the bot, but those users will answer a disproportionately high percentage of questions, because the bot enables them to respond so much more efficiently. The exact command set and behaviors will differ among bot implementations; unfortunately, the diversity of bot command languages seems to be rivaled only by the diversity of wiki syntaxes.

Commit Notifications in Chat

One particular kind of bot (also known as an "integration") watches the project's version control repository and broadcasts commit activity to the relevant chat rooms as it happens. While this offers less technical utility than subscription-based commit notifications (see the section called “Commit Notifications / Commit Emails”), since interested observers might or might not be around when a particular commit pops up in the room, it is of immense social utility. It gives people the sense of being part of something alive and active — they see progress happening right before their eyes. Because the notifications appear in a shared space, people in the chat room will often react in real time, congratulating the committer, or asking a question related to the commit, or even reviewing the commit and commenting on it on the spot.

The technical details up of setting this up are beyond the scope of this book, but I recommend learning how to enable it in your project's chat platform. It's worth the effort. Most of the major hosting sites make this integration fairly easy to set up. In addition to "integration", some key words to try in a search are "hook", "trigger", and "extension".

[51] Matrix is actually a protocol and an open source reference implementation. The protocol is supported by an increasing number of chat applications, including IRC as well as more modern systems. In the words of Julian Foad in, "Matrix is a 'spiritual successor' to IRC, and truly Open, federated, and standardized. ... In my opinion Matrix is very much the Right Way forward for all sorts of reasons." For more information, see and

[52] When two or a few users wish to chat privately, it is sometimes said that they create a "private room". Such rooms are usually temporary.

[53] See for a more detailed examination of nick-flagging and some examples.

[54] Every message posted in an online chat has its own unique URL permalink, just as every comment in, say, a bug ticket does. See the section called “Treat All Resources Like Archives” for more about this principle and its implications.