The diversity of OpenStreetMap tools and how they help create a commons
This blog post was originally published on my blog on August 11, 2025, under a CC BY-SA license.
Last weekend was the 21st birthday of OpenStreetMap (OSM), and with some friends we celebrated the occasion with a little mapping party. Our plan was to combine flying drones to collect aerial imagery and collecting street-level imagery with more traditional field mapping. Due to high winds, we mostly ended up with street-level imagery and doing field mapping though, using a variety of tools.
On the way home, I was reflecting on how amazing this richness and diversity of tools for contributing to OSM is. Not just in terms of methods (like collecting imagery, sharing GPS tracks, arm-chair mapping or surveying). But even just within each of these realms: Yesterday we surveyed using Every Door, StreetComplete, MapComplete, and ChatMap, while recording GPS tracks with CoMaps. Before then sitting down with our computers, to make larger edits with iD and JOSM.
This wide spectrum of used tools is not (just1) because each of us had different preferences for tools. But also because different tools fill different niches. Even individually, I end up using virtually all of those mentioned tools every single day that I contribute to OSM.2 Why? Because each of them excels at particular and different use cases.
Every Door is great for surveying when it comes to adding more complex points to the map, things like amenities or shops.3 For these objects one realistically wants to add a wide range of information in one go (opening hours, websites, phone numbers, …). StreetComplete is perfect to quickly add missing data to existing objects, at least in part because it tries to gamify OSM contributions. By highlighting different types of "missing" information around one's current location, it's easy to find things that are both simple to verify as simple to add by the click of a button/answering a multiple-choice question (e.g. adding in the type of road surface).4 MapComplete is great for adding objects to which one might want to add photos, for example art works or wayside shrines, as long as the objects are already supported.5 And CoMaps works great if find yourself without any reception (which would be needed to download the live map) but you found a place where you want to make an edit, as you can look at the offline map and still queue up an edit/note. Similarly, less surveying-based editors like iD and JOSM have their own niches they work well for.
The answer to "what is the best editor" thus comes back to the common "it depends on your use case". While at times I've seen people complain about the complexity that comes with a large number of tools, I'd argue that this big diversity in tools is in reality a big asset to enabling contributions to OSM. Not only does it allow people to find a tool that works best for them and their contributing-style, it also facilitates having the right tool for the job.
If you think of everything apps or super apps that try combining a lot of software features, their alleged appeal is to have all the functionality you could ever need in one place, but the reality is more often that those tools become bloated, hard to navigate, and calcify as any changes to the structure are infinitely harder given the size and complexity. I often compare this to the Swiss Army Knife: In a pinch, its little screwdrivers, saws, etc. will do their job to fix stuff around the house. But for any larger building project you definitely would like a toolbox with some real screwdrivers and saws.6 This is because these individual tools can focus efforts on supporting and implementing comparatively narrow use cases, without having to make extra trade-offs.
Of course, the idea of having tools that "do one thing well" isn't new. It's part of the Unix philosophy, alongside the idea that all of these tools should work together with each other. Similarly, how different types of contributions require different tooling reminds the biologist in me of JBS Haldane's On Being the Right Size, which neatly outlines why the shape of organisms plays a big role in the niche they fill. And more recently, there's been a call for malleable software. That is software that can adapt to user needs. And while the authors are skeptical of too specialized software, they highlight interoperability between tools as a big factor, similar to the Unix philosophy.7
So why does this approach of having a large diversity of tools work well for OSM, when otherwise we might see trends that go counter to this? I think there's different aspects to it: First of all, there's a clear "interoperable target" - that is a place where people send contributions to: the OSM database. Ultimately it doesn't matter which tooling someone used, the changesets end up in the same place, contributing to the larger project and shared goal. Then there's two other key aspects of peer-produced systems, having a wide range of tasks that are granular and modular.8 In other words: There's lots of different types of contributions that one can make to OSM, ranging from very small (e.g. Verifying that a business still exists) to very large (e.g. Adding a whole new neighborhood with streets, buildings etc. to the database). But no matter the size, all of these contributions are valid and help improve the overall database and map.
And lastly, there is the elephant in the room: There is no incentive to build a "super/everything app". In the commercial space, the main incentive for building these tools is to keep "your" customers locked up in a closed, proprietary ecosystem. With that, the cost of switching becomes so high that you can maintain a 'captive audience'. But in a digital commons, that is built on cooperation rather than competition, such an approach makes little sense. Especially for tools that are open source for contributing into the commons for the community benefit.
It seems that under those combined circumstances, maintaining a diversity of tools works quite well. It provides a pathway for making lots of different contributions by lots of different contributors. And just like it takes a village to raise a child, it takes a global village – with many diverse contributions – to create a map as a by-product of understanding the world. And that's a reason to not only celebrate the birthday of OpenStreetMap, but also the huge diversity of contributors, the ways in which they contribute and the tools they use for that.
Footnotes
Of course that also plays a role, people do realistically have different preferences or are willing to make different trade-offs with respect to usability.
If you look at my contribution history, you can actually see some of that diversity, but as different editors handle how changesets are pushed differently, the raw numbers can be a bit misleading.
And of course it works equally well to "fully" annotate buildings (addresses, number of floors, color, roof styles, …), as the name suggests.
It also works great for adding in simple objects, like all the play objects on a playground!
If an object isn't supported yet, one can write a custom layer like I did for the wayside shrines, but that's slightly more advanced. Either way, images uploaded through MapComplete are automatically linked as an OSM tag and available via their own Panoramax instance.
In the OSM universe, the OsmAnd map/navigation/editing app is maybe an example of such a Swiss Army Knife: Stuffed with features, it is very powerful and can do a lot of things, but comes close to requiring an advanced degree to really use all of those possibilities. As a result, for many/most use cases (think of doing a simple hike) there will be other, simpler, more specialized tools that will get the job done in a simpler/better way.
Thanks to Helge Rausch, who had pointed me towards the article initially and also highlighted the similarity to the Unix philosophy!
If you look at page 5 of the preprint you'll find a longer list of characteristics that are found in peer-production. The examples given are from Wikipedia, but are easily translatable to OSM