On group communication channels


What i want to discuss here a bit is channels and platforms for group communication (that is communication between more than two people) in the context of an open social project like OpenStreetMap. For many years every now and then people turn up on OSM communication channels and express dissatisfaction with either the particular channel or with communication in the OSM community in general – often connected with the suggestion that everyone should move to [fill in your favorite hype of the day platform]. I want to explain here my personal criteria what aspects qualify a communication channel or platform for productive, constructive and inclusive group communication in context of a global multicultural social project like OpenStreetMap.

A few preliminary remarks: First i want to clarify that this analysis concerns group communication in the sense of symmetric communication between more than two participants on equal levels. For one-to-one communication or asymmetric communication (one-to-many with no symmetric back-channel) different criteria apply. Second, a diverse global community like OpenStreetMap depends on there being diverse communication channels used for communication. Concentrating everything on a few channels and platforms would be an issue on its own. OpenStreetMap can only work in a sustainable way if communication and social interaction within the community does not depend on there being a central communication channel everyone engages on. The very idea of OpenStreetMap is that the main database is the element that holds the project together socially and trying to substitute that with some other means would fundamentally weaken the project.

The criteria

  1. Asynchronous communication: In a global, multilingual community like OSM there is inevitably a significant variation in how fluent people are in the language of a specific communication channel. Asynchronous communication (that is communication where there is no expectation, technical need or social pressure for a close timing between a message and reply to that message) can enormously help to level the field in that regard. Not to mention different time zones. Asynchronous communication also helps accommodating participants with intermittent internet access.
  2. Text based communication: For similar reasons text based communication is generally preferably to audio or video communication. Audio or video group communication is of course also almost universally synchronous anyway. In addition text based communication reduces the bandwidth requirements for the participants, makes any kind of filtering massively easier and especially it reduces the participation barrier because it gives participants better control over the content of their communication and the disclosure of private information.
  3. Structured communication: One fairly essential component of group communication with a larger number of participants is transparent visibility of who communicates in reply to whom. The classic way to visualize that is threaded communication. opinions on this differ a lot – some despise the threaded display of communication while others think it is essential for communication in larger groups to work properly. This has a lot to do with digital socialization of people. Those who have become familiar with digital communication without being exposed to the concept of threading often adopt a dislike of this. And with widespread tools and platform (Microsoft, Google) of email communication over the last decade or more by default hiding threading this applies to quite a lot of people. What is fairly clear however is that if a larger number of people participate actively on a communication channel without the communication being structured into threads it will often turn more and more into a synchronous communication channel because asynchronous replies to older communication is perceived to be disruptive by the most active participants of the channel. And this comes with the issues i mentioned above for the asynchronous communication.
  4. Availability of a linkable and immutable permanent public record of past communication: This is one of the most important points. For group communication to be practically meaningful for a larger community it is absolutely essential that you can refer to past communication in conversation in a way anyone can follow and that you can resolve disagreements on the exact nature of past communication transparently. This is easiest through a complete, reliable, immutable, searchable and linkable record of the full history of communication.
  5. Open platforms and communication protocols: For long term sustainability and to avoid dependency on proprietary technology providers. That means in particular the technical interfaces to participate in the communication should be documented and both legally and technically open to be used by everyone without being tied to using specific software.
  6. Practical diversity in communication clients or interfaces: Connected to the previous point – it is of high value if communication protocols are not only open in principle but if there are also different clients and interfaces available that users can choose between according to their individual needs and preferences. Apart from personal preferences and convenience this is also a matter of accessibility – in particular for people with disabilities.
  7. Practically usable flexible and robust ways of filtering communication by the individual user: This is connected to the previous two points. In case of open communication protocols and a variety of communication clients available, one of the most important features those clients tend to distinguish themselves with is filtering options for the communication. And that is of significance on two levels. First it allows people to focus their attention of what they consider important and of interest for them rather than what others consider important. And as a secondary effect it tends to have an immensely civilizing effect on the participants of a channel. If people know everyone else on a channel has the ability to choose ignoring their messages they tend to weigh more carefully what they write and take more into consideration if what they write is likely to be perceived to be of value by others. To put it bluntly: Never underestimate the pacifying effect of a killfile.
  8. Channel is open to everyone and does not require explicit invitation or other access control or discouragement from active participation. Like the required agreement to terms and rules decided on by others than by those who are actually communicating on the channel. This is again essential for diversity in participation. For many people the psychological barrier to actively contribute in a public group communication channel is quite significant so it is important not to create additional hurdles to that. Of course ultimately most, even non-commercial, operators of communication infrastructure ultimately reserve the right to control access to their infrastructure when they consider it necessary but the key here is if that is a possibility that is practically used or not.
  9. Decentralized protocols. This is the ideal solution for the previous issue but practically there are only very few group communication channels that work in a fully decentralized fashion. Historically Usenet was the iconic example of decentralized group communication and since the demise of Usenet there has so far never been any decentralized protocol for group communication that has gained an in any way comparable significance.

And how do different channels compare?

Here is how the various communication channels commonly used in the OSM community fare regarding the criteria mentioned above. I included Usenet/NNTP although his is not practically relevant both in the OSM community and outside of it because is has historically been very important in forming digital group communication culture on the internet and as you can see it also is outstandingly good at meeting my list of criteria. The reasons for the decline of Usenet and NNTP is a whole different story of course (quite an interesting one though – and one that many people have already written on so there is not that much point in touching that here).

The information on Facebook, Telegram and Whatsapp is based on hearsay and therefore not that reliable – i have never used these platforms so i can’t really provide first hand experience.

OpenStreetMap communication channels and platforms

OpenStreetMap communication channels and platforms

Footnotes from the table:

  1. has limited support for structured communication.
  2. The OSM wiki in principle allows structured communication and on talk pages it is established practice to thread messages. But you have to do this fully by hand and it only works if everyone does so diligently. No builtin support for that.
  3. On Usenet server operators used to expire messages so there was practically no permanent public record in the system itself. However everyone running a Usenet server could maintain a record and in the late days of Usenet Google practically served as a reference record.
  4. The forum indicates when a post has been modified after initial posting but no record of the original message is retained. Also admins on the forum can (and do) remove messages from the record (with varying frequency, depending on the channel).
  5. The diaries themselves can be edited without the history being visible but the diary comments cannot.
  6. On the wiki the edit history is openly accessible so it serves as an immutable record (though it can be difficult to use as such practically).
  7. Github has a fairly clever system of allowing edits of communication but still allowing users to transparently see if there have been changes and what has been changed. Github however also allows completely removing messages from the public record in some cases (but it is indicated at least that a message has been removed i think).
  8. While there is no alternative interface to posting changeset comments for reading there is the popular tool by Pascal Neis.
  9. Openness in participation applies to most OSM related mailing lists and forums. There are a few exceptions – specifically osmf-talk is only open for posting to OSMF members. There are thematic and regional lists and forums with culture specific rulesets you need to accept for active participation which are usually developed through consensus of those active on the individual channel (like diversity-talk, regional forums).


The bottom line is: Mailing lists still rule by a huge margin compared to everything else that is used today in the OSM community. But of course the criteria i used are my personal preferences and although i have explained why i see it this way there are others who view what i see as advantages as major disadvantages. And that is fine – as i pointed out in the beginning diversity in communication is essential for a diverse global community like OpenStreetMap. There are some in OpenStreetMap who dislike that and who would want to culturally homogenize the OSM community and would like to nudge everyone to adopt the same communication platforms. That is not going to work of course. If there is one field where you can be absolutely certain that people will always vote with their feet it is group communication channels.


What is interesting is of course to look at what the future might bring. Will there be platforms and channels that can compete with the old school techniques (NNTP and mailing lists) that came out as winners in my analysis regarding the criteria i looked at? At the moment nothing is visible in that direction i think. Focus in development in group communication technology has for quite a few years been in the real time synchronous domain but as i tried to explain above this is of relatively little importance for highly multicultural use cases like we have them in OpenStreetMap. The trend in asynchronous communication has for quite some time been towards monolithic platforms where the client and its user interface are tightly interwoven with the underlying communication protocols (or in other words: Stuff developed around some fancy web interface meant to serve the fashion of the day in UI design). That is unfortunate because it tends to take many years for a highly non-homogeneous community like OpenStreetMap to truly adopt new communication channels en large. And by the time that happens such fashion of the day frameworks have often already reached the end of their short life and are out of fashion and not maintained any more.


  1. Does the immutable permanent public record have to be part of the channel ? In most cases, external archiving will offer it – many IRC channels are recorded that way, as are the Openstreetmap mailing lists. Same as NNTP and applies to Matrix as well (with editing requiring history and thus making it a little more complicated).

    • I am a huge fan of the Unix philosophy so modularizing tools and separating technically the communication from the archive in principle is fine. There are a number of hurdles with that of course in practical application. Technically for example in particular with synchronous communication channels a loss of the connection of the archive provider to the channel often means an interruption of the record. For maintaining a public archive independently of the channel operator there are also the matters of copyright and privacy to consider – both the channel operator and communication participants could in such cases have a legal basis for shutting down the archive (or enforce censoring it). Channel operators can of course safeguard this possibility by specifying upfront in their terms of use that the communication content is made available under an open content license.

      In concrete terms – I know of no OSM related communication channels other than mailing lists or ones with a builtin public archive functionality where there is currently a full immutable permanent public record provided by a third party – but i would be very interested in links to examples of such.

Leave a Reply

Required fields are marked *.

By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.