> improving OpenStreetMap

Sure, but in order to actually make apps work (without forking every map project out there) you'd need to fake the Google APIs anyway...

> GNU/Linux-style package manager for Android.

That's basically what f-droid is.

Google Location Services API is required for OSM to work properly.

So you put location services on the list of things to replace.

...and, that's what this project is doing.

It's doing both things.

When you're trying to compete with a huge incumbent you always have the Wine vs. Qt/GTK question, where you have to choose between compatibility and design freedom.

But even when you choose compatibility and reimplement the incumbent's API, you don't want to do it using their servers. What happens when they suddenly change the protocol they never promised not to change?

Their clients would have to be updated as well, so there would be an indefinite period of time where the unchanged protocol still works giving microG a chance to upgrade as well.

Google has all the data that makes it work + you would need to analyze all that data to end up with server that can take radio levels and output location. It's not as easy saying lets use our own servers.

If google were nefarious, they can secretly ship a new version that supports both versions of the protocol, wait weeks, months, or even years for it to become installed almost everywhere, and then silently remove support for the old version from their servers.

That would give microG zero time to prevent their software from working uninterrupted.

That sort of thing can happen for all sorts of legitimate reasons, it's not necessarily nefarious. For instance if the client side of the project is running ahead of the server side, rollout may begin with usage controlled by server-side variables. Once the servers are ready to go, usage may be ramped up much faster than software rollouts themselves happen.

Also IIRC the Google services are updated automatically in the background anyway by the Play Store app. So I guess rollouts can happen quite quick regardless.

OsmAnd appears to work fine on my phone, which as far as I know does not have any of Google's proprietary components currently installed (by way of a vanilla CopperheadOS install).

You need a location service provider for OsmAnd to work. Not sure what CopperheadOS pre-installs, but it could well be microG.

You need a location service provider, which can be fulfilled by GPS or network location. You don't need the fusion location provider, which is the proprietary one.

I think you're underestimating the number of 3rd-party apps that use the Google APIs. This dependency is in no way restricted to Google-branded clients like Maps and Play - the APIs are required for the majority of behind-the-scene things, not least anything involving location (including in most OSM clients).

GNU/Linux-style package manager for Android is F-Droid, which bans apps that depend on Google's APIs. The effect of this policy can be clearly seen in the dearth of apps on F-Droid.

No. 99% of users are not going to want a Linux style package manager. That's not a solution that will work in any way for normal people.

The main difference between a package manager and an app store is that a package manager can allow you to install apps from more than one source and can do proper dependency management. What part of that is supposed to frighten the townsfolk?

Why not? I'm personally aware of plenty of normal people for whom that works perfectly well.