Every Door: a focused OpenStreetMap editor for shops and amenities

An app scoped to one job

Every Door describes itself as the best mobile editor for adding shops and amenities to OpenStreetMap, and the description in the repository is blunter still: a dedicated app for collecting thousands of POI for OpenStreetMap.

That scoping is the whole design idea, and it is worth taking at face value rather than reading it as marketing. The general OpenStreetMap editors, the two big desktop ones and the many mobile ones, are built around the idea that any feature of the map might need editing. A road, a building footprint, a cycleway tag, a river polygon, a name, a boundary relation, and thousands more tag combinations all live in one app, which makes them powerful and slow.

An app that only adds amenities has one job, and it can be fast at it. If you are walking down a street photographing shopfronts and noting whether each has a name, whether it is a pharmacy, whether there is a wheelchair accessible entrance, and whether the opening hours look right, that is a data entry task with a narrow vocabulary. A dedicated editor can make that specific task fast, and fast matters, because the volume of data is the problem.

The description's phrase about collecting thousands of POI is the scale being targeted. Mapping is an effort problem as much as a technical one, and an application that halves the time per shop unlocks a different amount of mapping than one that does not.

The application is written in Dart with Flutter, the primary language of the repository, and the project is licensed under the GNU General Public License version 3 or, at your option, any later version. The author is Ilya Zverev, and the copyright line in the readme runs from 2022 to 2025.

Three modes, and what each is for

The readme leads with three screenshots, and each one is captioned with a mode name, which tells you the application has distinct working modes rather than one linear workflow.

The first is amenity mode. That is the primary mode and the one the name of the app suggests: adding an individual point of interest, a shop, a cafe, a pharmacy, a bench, a bin, whatever it is, at the location you are standing, with the tags and the attributes that go with it.

The second is editing a library. This is the feature that makes the app different from a normal editor, and it addresses the point about collecting thousands of POI. A library is a collection of predefined objects, with their tag sets and their display properties, that you can apply quickly rather than typing tags for each shop one at a time. If the same kind of thing appears repeatedly on a street, a library lets you pick it from a list and confirm it, and the alternative is re-entering the same tag combination dozens of times.

The third is micromapping mode. Micromapping in OpenStreetMap means describing small features at a level of detail that most mappers never bother with: the individual doorways of a building, the individual trees in a row, the individual bollards along a pavement. It is the kind of detail that adds real value to a map for anyone using it for routing or accessibility, and it is also the kind of detail that takes forever to enter one item at a time. A dedicated mode with tools aimed at it is a reasonable bet that people will do more of it.

So the three modes map onto three different rates and rhythms of work: one object entered carefully, one object entered quickly from a prepared library, and many tiny objects entered with a helper. More screenshots are collected on the OpenStreetMap wiki page for the project, which is where the visual detail lives.

Where it runs and where to get it

The distribution story is spelled out at the top of the readme, and it is more interesting than the usual single download link.

For iOS there is a link to the App Store. For Android there are four separate links: F-Droid, Google Play, GitHub releases, and the Huawei AppGallery. That list covers the three practical Android routes a project like this has to think about, and each one has a reason to exist.

F-Droid is the free software distribution channel, and its presence is a statement about what the project values, particularly for a GPL application that most other OpenStreetMap editors are not distributed through it. Google Play is where the volume is. GitHub releases is the direct route, and it is the one that gets the newest builds first, given the release pattern below. AppGallery is the Chinese market, and being listed there is what lets the project reach users on devices that do not carry Google services.

The application identifier is info.zverev.ilya.every_door, and the F-Droid package path uses the same string, which is the naming a Flutter project gets from its organisation and author.

The readme also points at the contributor's guide, hosted on the project's own site, for three things: how to report bugs, how to translate the app, and how to submit improvements. That is a short list and it is a useful one, because for a project that depends on a large volunteer translation effort, the translation workflow being documented is what keeps it from stalling.

The roadmap lives in a GitHub projects board belonging to the author's account rather than in the repository, and the more screenshots live on the OpenStreetMap wiki. That is a deliberate pattern: the code is on GitHub, the task list is on GitHub, and the user-facing documentation about the mapping workflow is on the OpenStreetMap wiki, where the contributors who use it already are.

Funding that shapes who it is for

The sponsorship section of the readme is short and says something real about the project's economics.

The author is sponsored by many individual contributors through GitHub Sponsors and Liberapay, and the readme thanks everybody. Then there is a second line: the NLNet Foundation is sponsoring the development in 2025 through the NGI Commons Fund with funds from the European Commission.

That combination is worth pausing on, because it describes two funding streams pulling in different directions in a useful way. Individual sponsorship through GitHub and Liberapay means the project is directly funded by the people who use it, which is a form of accountability that does not depend on a roadmap being negotiated with an institutional funder. The NLNet grant, whose name in the field is the NGI Zero fund, funds work on publicly funded open source infrastructure, and it comes with the kind of process that produces a documented project page, which the readme links.

The practical effect on the project is that it can take on work that pure donation funding rarely covers, because the grant pays for the development time rather than the running costs. A mapping application has real running costs: the developer account fees for the app stores, the domain, the build infrastructure, and the translation and community work.

The readme closes with an offer to contact Ilya directly or through his company, avatudkaart.ee. That is a professional arrangement, which is unusual to see stated in a readme and suggests the project has moved beyond being a purely volunteer effort, while the GPL licence and the open source distribution through F-Droid keep the code itself free for anyone to use and modify.

The repository layout and the release pattern

The top level of the repository confirms what kind of project this is and how it is built.

The directories android/ and ios/ are the standard Flutter platform wrappers, and lib/ holds the Dart application code. There is a test/ directory, an assets/ directory for bundled resources, an icon/ directory, and a tools/ directory. Two entries stand out as telling.

The first is l10n.yaml. That is the configuration file for Flutter's internationalization tooling, and its presence tells you the app is set up for translation rather than being English only. It sits alongside the assets directory, which is where the translated strings and any bundled imagery would live, and it pairs with the contributor's guide section on translating the app. A mapping app used by contributors across dozens of countries is very unlikely to be usable in one language only, and the tooling is there for exactly that.

The second is vendor/, together with a .gitmodules file. That combination means there are git submodules vendored into the tree, which is how some Flutter projects pull in a shared Dart package that is developed separately. Keeping it as a submodule rather than copying it means the dependency has a single upstream history.

The rest is ordinary Flutter project furniture. analysis_options.yaml configures the Dart analyzer, which is how a project enforces its linting rules, and the presence of a committed pubspec.lock is the right choice for an application rather than a library, since an application should be reproducible.

The release pattern is the other thing to note. The recent releases are v8.0-alpha2 from 2026-01-27, v8.0-alpha1 from 2025-12-18, and v7.1 from 2025-10-23. So the stable line is 7.1 from October 2025 and the 8.0 alphas have been arriving since December, with the last push on 2026-04-19. There is a CHANGELOG.md in the repository, which for an app with a public user base matters more than it does for a library, because it is how a user finds out what changed before they update from the store.

Editorial conclusion

Adopt Every Door if you contribute to OpenStreetMap and your work is mostly points of interest rather than streets and buildings, because the whole interface is shaped around that narrower task. Do not adopt it as a general purpose OpenStreetMap editor, since a dedicated app for amenities is a deliberate limitation rather than a simplified version of the general editors. Before you commit, read the contributor's guide, because it covers how to report bugs, how to translate the app and how to submit improvements, and check the release channel you want, since the newest builds are alpha while version 7.1 is the last stable one.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Zverik/every_door on GitHub