The Quest for a Common Chat/IM Solution

Konqi between chat solutions

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 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 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 channels, please fill in the survey here until Thursday, August 31st.


Comments: 17

    • We’re not at the point of considering specific solutions yet,but we will certainly consider XMPP as well when that point comes. I doubt that it will be the best fit for our requirements, but would not dismiss it yet.

  1. Most annoying survey site ever, who designed that usability? Sorry I got fatigued by question 5. exists
    Collecting a list of requirements is useful and probably necessary but a list won’t cover everything, it needs people with a bit of knowledge and ability to explain these things to review the options and make a recommendation then commit and have some push to actually discourage hangers on to stay on IRC.
    Matrix seems perfectly good as long as it’s not a licence for some communities to stay on IRC forever.

    • I know that we have our own survey site and I have already used it in the past and will use it again for other surveys.
      It’s just that kanosurvey offers a very easy way to conduct and analyse a survey according to the Kano model. I could have recreated the whole thing on, but that would have been considerably more effort, especially on the analysis side (and I’d first have had to figure out how to even get from the answers to the categorization in the Kano model).
      Finding out which solution best fits our requirement profile and then making a recommendation is the next step. This survey only answers the question of what is a must-be / attractive / one-dimensional / indifferent / reverse quality for people who would then use the solution.
      If we just gave the raw list to some people to use, they’d just apply their own personal priorities to them, which might not match with the majority of people who are then going to use the selected solution.

  2. Maverick says:

    Can’t wait to see the result of this survey!
    Has anyone considered qTox?

    • We’re not at the point of considering specific solutions yet, and I must admit that I had not heard of qTox before, but from a first glance it looks like something worth checking whether it meets our requirements.
      Thank you for the tip!

  3. The best solution would be to use Brooklyn.
    Enforcing a single solution, while we have multi protocol clients, like Telepathy KDE or Kopete and have a shiny new protocol bridge seems contradictory to me.
    Feature wise, the results of the survey can be useful to future Brooklyn development.

    • The problem is that bridges never really give the same experience as being on the same protocol / product. They may come close, but it’s not he same.
      We most likely won’t force a single solution on anybody, though, but if we can find a solution that fits the needs of most, chances are that the majority of us will use one solution instead of being spread over several of them.

  4. matrix! decentralised end to end encryption designed with bridging in mind and being considered for librem purisms phone….. but i havnt used them all… cant wait for the considered and wise kde opinion

    • Matrix is definitely a hot candidate, but we don’t want to jump to selecting a solution before having defined what it is that we need from them.

    • Maverick says:

      Never heard of matrix! I’m going to check it out.
      in the meanwhile:
      Beside Encryption, Tox is also Distributed
      “Tox has no central servers that can be raided, shut down, or forced to turn over data — the network is made up of its users.”

    • May I add that Tox has quite high requirements when it comes to battery and traffic (mostly relevant for mobile use). I also tried it for some time; but by just running in the background it was one of the main traffic users on my mobile phone.
      Disclaimer: this was two or three years ago. Perhaps things have changed? But a fully distributed architecture probably will always suffer from these things.

    • Maverick says:

      That may also result from a bad client design. Since Tox is the protocol and that it has a few clients (Antox, qTox, uTox, and so on) maybe a KDE designed client could be lite…
      Then again, i’m no specialist, so i might be wrong here 🙂

    • Maverick says:

      Just an update i think is worth mentioning (taken from: )
      What is the difference between Matrix and Tox? looks to be a very cool clone of Skype – a fully decentralised peer-to-peer network. Matrix is deliberately not a ‘pure’ peer-to-peer system; instead each user has a well-defined homeserver which stores his data and that he can depend upon. Matrix provides HTTP APIs; provides C APIs. As of October 2015 Tox doesn’t seem to have an answer yet for decentralised conversation history storage.

  5. […] week ago, I wrote my previous blog post about a survey I had set up, to figure out how important each of the requirements we had collected […]

Add your comment