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.
References
- Greshake Tzovaras, B. (2025, July 24). Making a Panoramax Mastodon Bot. Bastian Greshake Tzovaras. https://doi.org/10.59350/ad1s9-yzs02
- Greshake Tzovaras, B. (2025, March 17). Adding wayside shrines to OSM with MapComplete. Bastian Greshake Tzovaras. https://doi.org/10.59350/tehs2-enz94
- Kloppenborg, K., Ball, M. P., & Greshake Tzovaras, B. (2021, May 23). A peer production model for citizen science: comparative analysis of three online platforms. https://doi.org/10.31235/osf.io/rw58y
- Litt G, Horowitz J, van Hardenberg P, and Matthews T. (2025). Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/.
Footnotes
Generally, things are better if you put open* in front of them.
Thanks to Rogue Scholar, you can cite this blog post using the DOI https://doi.org/10.59350/b6hse-mv263.
This page was last built on 2025-08-11 @ 13:33:28 -0300,
from git commit
0bb5e4e.