The Quest for a Common Chat/IM Solution
A Free/ Open Source Software community usually uses several means of communication: Among them are email, forums, code review and bug tracking systems, nowadays also video chat systems, but one of the central communication channels is usually real-time text communication, also known as instant messaging or chat.
Traditionally, IRC has been the cornerstone of chat in the FOSS world, as it is open, easy for everyone to join (no account needed) and not in control of any single organization. IRC still does what it was designed for perfectly well, but while it is still basically the same as it was 20 years ago, the world of chat and instant messaging around it has evolved significantly in the meantime: Instant messaging services such as WhatsApp or Telegram (or KakaoTalk, WeChat or Line in Asia) are used by pretty much everyone (and their parents, literally) and systems such as Slack are dominating company communication, and those systems have shaped how people expect a chat system to look and behave.
While this does not really bother long-term members of FOSS communities such as KDE, who know IRC inside and out and feel perfectly comfortable with it, we have noticed that for many new and young potential contributors, IRC feels like a “relic of the past”, due to how it is presented and the features it offers.
Therefore, Telegram has become the standard communication tool for the designers in the VDG, and WikiToLearn uses rocket.chat and Telegram as well. This works okay for the time being, as users in Telegram groups can communicate with users in corresponding IRC channels via bridges. However, it still feels disconnected, because the bridges limit functionalities like mentioning users or sharing images, and setting up a bridge requires manual effort for each group/channel, while people often create ad hoc Telegram groups for specific topics. It’s also difficult for people to find relevant Telegram groups unless a link to them is put manually on the community wiki.
The biggest problem with Telegram is, however, that while its client code is open-source and they offer an API for developing additional clients, the server side is fully controlled by a single company, which means our communication on Telegram is fully dependent on whatever that company decides to do.
To fix this situation, three weeks ago Jonathan Riddel proposed on the KDE Community mailing list that we switch from our mix of solutions to rocket.chat for all of KDE. This proposal sparked a very long and occasionally heated debate with each side arguing why their solution is better. At some point I realized that we’ll hardly ever reach a conclusion if we don’t even know what exactly our requirements are for a common chat solution. To fix this, I started an Etherpad to collect requirements.
While doing that, we realized that there was quite some disagreement about which features or properties were “must-haves” and which were “nice-to-haves”. That’s when Heiko Tietze suggested that it could make sense to use the Kano model to figure out which features are indeed must-have for the majority of our community, which are not needed but would make people want to use a solution, which ones the majority doesn’t actually care about and which might even annoy people. He also suggested a tool called Kano survey which allows to capture this information easily in an online survey.
So I set up a survey about “Requirements for a primary Chat/IM solution for KDE” to prioritize our identified requirements. Now if you would like to contribute your opinion on the importance of the different requirements because you regularly communicate with KDE on our current IRC, Telegram or rocket.chat channels, please fill in the survey here until Thursday, August 31st.