Organic Maps, CoMaps and the trust problem behind open-source navigation

A user looking for a private offline map app now sees a choice that did not exist a year ago. Organic Maps is still the familiar, polished, OpenStreetMap-powered navigation app with millions of users and a strong privacy pitch. CoMaps is the community fork that says the same category needs a different trust model: open governance, open finances and a not-for-profit posture. The split is worth watching because it is not only a mobile-app quarrel. It is a live test of what “open source” means when the product depends on generated map files, download infrastructure, trademarks, store distribution and money.

For Open Source Radar, this is a better story than a simple “which app is better?” comparison. The practical answer may differ for a hiker, an Android privacy user, an iPhone user, a mapper or a maintainer. But the deeper lesson is broader: in mature free-software products, the repository license is only one piece of the trust chain. Users need the source code, but they also need to know who controls the map builds, whether the data files can be redistributed, how servers are run, how donations are handled and how decisions are made when contributors disagree.

The current facts support a balanced view. Organic Maps describes itself as a privacy-first offline maps and GPS app for hiking, cycling, biking and driving, powered by OpenStreetMap data, with no ads, no tracking and no data collection. Its GitHub README says the app is installed by more than six million users. The GitHub repository remains public, active and substantial: the API reported about 1,484 forks, 3,373 open issues and an update on July 6, 2026. The same README also now says that the code is under Apache License 2.0 while binary data files, including .mwm map files, are provided under a separate DATA_LICENSE.txt.

That separation is where the argument becomes concrete. The Organic Maps Binary Data License says the project provides compiled binary data files, including .mwm maps, packed_polygons.bin and other .bin files, under a separate license from the source code. It requires visible attribution to OpenStreetMap and Organic Maps and says white-labeling or rebranding use requires explicit written permission from the Organic Maps team. In other words, the app source may be open, but the ready-made map data that makes the app useful is not being offered under the same open-source terms.

This matters because navigation apps are not ordinary source packages. A developer can fork a library and run its tests locally. A map app needs a map-generation pipeline, fresh extracts, routing data, search indexes, CDN mirrors, app-store release work and a way to pay for bandwidth. When the data license, build pipeline or server layer sits outside the ordinary open-source story, a fork can compile code and still struggle to offer a comparable product. That is why the dispute has moved beyond legal labels into operational trust.

The “is it really FOSS?” discussion sharpened the question. The site’s review of Organic Maps says the project has FOSS code but licensing, marketing or transparency issues, and it points specifically to the separate binary data license and to past debates about infrastructure such as the metaserver used to direct map downloads. That review should not be treated as a court ruling. It is an advocacy/audit perspective, not the project’s own position. But it is useful because it names the exact parts of the product that a normal user does not see: binary map files, server components and build-time dependencies.

Organic Maps has its own governance document. It describes a Governing Board as the final authority for the project, responsible for roadmap guidance, community health, relationships with contributors and protection of the project’s goals, brands and marks. That language is not unusual for a project with a recognizable product and trademark. The problem is that some contributors and users wanted more than a board page. They wanted a governance model that made power, finances and operational control visible enough to survive conflict.

The most visible result is CoMaps. Its Codeberg repository describes the project as a community-led free and open source maps app based on OpenStreetMap, built for transparency, privacy and not-for-profit values, and as a fork of Organic Maps and Maps.ME. Its website emphasizes offline search and routing, no data collection, efficient battery use and community participation. The repository is no longer a paper fork: Codeberg reported 1,838 stars, 159 forks, 1,267 open issues and an update on July 6, 2026. The project has packages or download paths through mainstream and FOSS-friendly channels including Google Play, the App Store, F-Droid, Flathub, IzzyOnDroid, Obtainium and Codeberg releases.

The fork also has a maintenance cost. Codeberg pull request #1303, merged in August 2025, cherry-picked and refactored Android changes from Organic Maps. It touched dozens of files and shows the unglamorous work behind a real fork: porting changes, adjusting user-interface assets, reviewing compatibility and deciding which upstream work fits the fork’s own direction. Codeberg issue #1338, with 25 comments before it closed, shows the social side of the same problem: users and contributors debating new Organic Maps features, whether they are fully open, and whether F-Droid should be notified. A fork that promises transparency still has to ship, review and argue in public.

F-Droid gives another useful signal. Its package API still lists Organic Maps builds, with a suggested version 2026.06.24-16-FDroid, and CoMaps builds, with a suggested version 2026.06.05-11-FDroid. That does not settle the governance dispute, but it tells privacy-conscious Android users that both projects are visible in the ecosystem where these questions matter most. The right question for F-Droid users is therefore not “which name is present?” but “which package matches my trust requirements today, and which trade-offs am I accepting?”

For ordinary users, the answer can be pragmatic. If Organic Maps works well for your region, your device and your travel habits, there is no technical reason to panic-delete it because a fork exists. It remains a capable offline navigation app with a strong privacy promise and an active codebase. But if your reason for choosing it was not only privacy from ad networks, but also a strict preference for community governance, transparent finances and reusable open data artifacts, CoMaps is now the obvious project to test. OsmAnd remains another mature alternative, especially for users who want a more configurable, feature-heavy OpenStreetMap client and are willing to live with a busier interface.

For maintainers, the lesson is less comfortable. “No ads, no tracking” is a powerful promise, but it is not a complete open-source governance model. A project can be privacy-respecting and still lose contributor trust if critical infrastructure is unclear, if money is hard to audit, if trademarks and data licenses are introduced late, or if decision-making feels private while the product is marketed as community-built. The earlier those boundaries are written down, the less likely a dispute becomes a fork.

Data licensing deserves special care. Many open-source projects depend on generated artifacts: model weights, map tiles, indexes, test corpora, firmware blobs, prebuilt SDKs or vulnerability feeds. If those artifacts are necessary to produce the user experience, they should not be hidden in a footnote. Projects need to say what is source, what is generated, what can be redistributed, what requires attribution, what is restricted by trademark and what a fork can realistically reproduce. A separate license can be legitimate, but it changes the trust contract and should be explained before users discover it through controversy.

CoMaps is not automatically the winner just because it is a fork. New governance can also be messy. Horizontal communities still need release managers, designers, infrastructure operators, security responders and people willing to make unpopular decisions. A fork can promise openness and still fail if it cannot keep maps fresh, triage issues, ship app-store updates or protect contributors from burnout. The interesting thing about CoMaps is not that it solved governance forever; it is that it made governance part of the product proposition.

The useful way to read the Organic Maps and CoMaps split is therefore not as a morality play. Organic Maps is not reduced to a bad actor by having a separate binary data license, and CoMaps is not guaranteed to be the better app for every user by calling itself community-led. The split is a warning that successful open-source applications become institutions. Once millions of people rely on them, trust depends on more than a GitHub badge.

If you are choosing an app this week, test both with your own routes, offline regions and device constraints. Check map freshness, search quality, battery use, Android Auto or CarPlay needs, F-Droid availability, privacy audits and export/import workflows. If you are maintaining an open-source product, study the dispute before you need it. Open the financial picture early, document who can make decisions, publish infrastructure plans, separate trademark policy from data licensing, and make it clear what a downstream fork can and cannot reuse.

That is why this story belongs in Open Source Radar. It is about a navigation app, but the real subject is the expanding surface area of open source. In 2026, a user-facing FOSS product is rarely just code. It is code plus data, servers, build systems, distribution channels, governance and money. The projects that treat all of those as part of the commons will earn a different kind of trust from the projects that ask users to infer it.