Some thoughts on the roles and responsibilities of developers and project maintainers in the OpenStreetMap community


OpenStreetMap is often described as a do-ocracy. When it comes to mapping and tagging decisions – the core activities within the project – this description is fairly accurate and for the most part this is working quite well. The approach that those who do the work decide on how it is done is, when paired with the core principle that local knowledge rules, a pretty good insurance against a small number of people with their subjective preferences and cultural background dominating the project and decisions made.

The most serious attack against this principle came with the rise of organized mapping activities. When writing the first English language draft for a regulation of organized mapping in OpenStreetMap i explained this as follows:

OpenStreetMap is an international project where thousands of volunteers together produce open geodata during their free time. As a community OpenStreetMap works through checks and balances that rely on every mapper deciding on what to map and how to map individually and being responsible for her or his activities. Because each mapper can only add or edit a relatively small volume of data every day errors can be recognized and corrected by the community through communication and open processes before larger damage is done to the database. For automated edits and imports this does not work the same way so we have documentation requirements and review processes designed to prevent bigger problems with such activities and to avoid disruptive and time consuming repairs of the data.

Organized mapping activities by groups of people who act under instructions of an organization often come with similar problems. Errors and deficits in the instructions given or in the way they are communicated to the mappers of the group can result in large scale damage to the data and can be disruptive to normal mapping activity. And although we in principle welcome such organized activity we have put up this policy to regulate organized mapping activities in the interest of the individual mappers and a functioning mapping community.

How much the actual regulation of organized activity will prevent the problematic influences of organized activities still remains to be seen.

Apart from organized mapping activities there are other influences and constraints that can endanger the egalitarian and freely cooperative nature of mapping in OpenStreetMap. One of these is the political domain, in particular through regulating activities and policy decisions of the OSMF. The best example here is the Crimea decision of the OSMF board. So far – in particular because the OSMF board depends on volunteers from the community to implement and enforce their decisions – the ability of it to substantially make and enforce political decisions against the values and interests of the local mapper communities world wide is rather limited. And to be fair so far most of the board members at least have the intention to make decisions in the interest of the hobby mappers. This could however change in the future if the balance of power shifts and the OSMF moves to rely more on paid staff for central tasks and this way becomes more independent of the OSM community.

The biggest and also the oldest influence on the mapper community however are the tools used by the community in their mapping work. More recently there has been extensive critique of the developers of iD, the most widely used data editor of OpenStreetMap. What is criticized specifically is that editor developers abuse their power to cater to specific interests by designing the editor’s user interface, tagging presets and validation rules in a way that leads mappers to map things in certain ways.

I wanted to add a few thoughts to this discussion from the perspective of one of the maintainers of the other project that is highly influential on mappers apart from the editors, the map style for the standard map on The influence of the standard style on mappers is not as direct as that of editors and it is therefore not as simple to use for specific purposes but it is pretty significant. And in contrast to editors where the main potential for developers steering the mappers is regarding how to map something mappers have decided to map on their own, the standard map style can incentivize mappers also quite significantly in what they map.

My approach to this matter has been – from the beginning of my contributions to OSM-Carto – to regard the role and task of the project as mapper support without active steering. This in essence means only to render things in the map which are mapped consistently by mappers in a certain way to support them in doing so and give clarity to mappers in what is the correct and established way to map certain things. This on the other hand means not to start rendering something because you – or someone else – thinks it would be a good idea to map things this way, because that kind of thought is inherently influenced by subjective interests and by specific cultural preferences and biases.

I should note these principles are not shared by all of the OSM-Carto maintainers. I am probably the most vocal adherent to this idea of self limitation but quite a few of the other maintainers share the same basic sentiment. Because of that most of the non-constructive rendering decisions in OSM-Carto are the result of either accidental or negligent changes. These resulted either from not giving enough thought on their effects or stemming from the time span from mid 2017 to end 2018 when we had relaxed the consensus principle and changes could be merged without consensus among maintainers.

It should however be clear that if the team of OSM-Carto maintainers was smaller or had relatively uniform common interests (as it is the case with the iD project) the incentive to use the influence we have in support of these interests would be tremendous. In case of the iD developers, who are both employed by corporate OSM data users, the practical influence of such interests is clearly quite significant and it is openly admitted by the developers that their main concern is the usefulness of the OpenStreetMap data for certain applications. At the same time transferring decisions or oversight over decisions into the hands of a number of random mappers would not necessarily work much better. When making decisions in OSM-Carto under the premise of mapper support only the most frequent critique came from mappers who wanted their favorite tagging idea to be supported against competing tags. Hobby mappers are not immune to catering to special interests.

The best and the only solution in my opinion is to have true and fair competition for providing the best tools to mappers. Having a real choice and being able to try and evaluate different options practically will allow mappers to vote with their feet and collectively support the best solutions. It prevents the dominance of a single project due to the lack of other options and thereby reduces the possibility to push for specific interests. I am convinced that both editors and map styles which make decisions based on the principle of restrained mapper support without active steering will in the long term get most appreciation from the world wide mapper community.

Long story short:

  • The option of using your power to cater to specific interests will always be very significant incentive for developers of mapping tools – either due to your own preferences or due to external interests influencing them.
  • Expecting a company employee to make decisions as a project maintainer against the interests of their employer is unrealistic. At the same time the interests of the OSM community and the project are in parts fundamentally different from those of specific current data users.
  • The best way to mitigate the problem is and will always be to have real choice and fair competition between different tools (editors, map styles) for the same task.

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.