Reminds me of the first company I worked for out of school.
We had a big drive with the source of truth image used to boot all our machines on it, and we added rsync to the init image. When each machine booted init would rsync everything from the storage box to the local machine. We'd keep the storage machine up to date and when we wanted to update other machines in the fleet we'd just do a reboot and it would sync up the latest files (provisioning for whatever each machine was supposed to do happened later, can't remember how that was handled now). The storage machine was running ZFS so we also took a snapshot before doing any rolling reboots, so if anything did go wrong you could just revert to the previous snapshot and reboot again as long as you didn't break the init image.
Sounds jank saying it out loud, but I don't remember it ever causing us any problems.
I haven't looked into what their schema is like, but if it's anything like Musicbrainz it will be pretty comprehensive and easy to pull the data you want out of!
Doesn't help fix your problem, but I have a similar issue with Google Cloud Platform. Years ago I had a free workplace account that I had some small company emails and what not on, and apparently at some point over the years I setup a GCP project or two. Fast forward to the modern day and I haven't used the account in years so I decide to delete it. As the admin I hit the delete account button and it complains that I have services still active, so I go disable all the services which includes removing the workplace subsccription with all my billing info. I then hit delete again, at which point it complains that I have a project on GCP (not active, just created). So I go to delete it... which requires having a (paid) workspace account. So I can't delete the unused project without paying to re-activate the workspaces account I deleted, and I can't delete the whole account without deleting the GCP project. And of course Google has literally no support, so I just have a Google account hanging out there somewhere, probably with vaguely sensitive information from years ago on it, waiting for someone to guess the password or otherwise get into it.
Don't do all the businesses in Paris, just do the ones you frequent the most. Google doesn't have all the businesses in Paris either (or at least, in Atlanta I run into ones that they don't have too or that they have but it's completely wrong, at an old location, etc. fairly frequently).
Interestingly, in Atlanta I've had the opposite experience. In town OSM always seems to be better (Google has a lot of outdated open hours and the like). Outside of town in the cheaper burbs which is the only place I can afford to live though few people are editing OSM and it's pretty out of date.
That being said, I switched to Organic maps years ago. For 90% of places I go, it turns out I go to them repeatedly day-to-day, so I added them to the map the first time and update them when I go there and the hours have changed. Then they're on the map the rest of the time when I need to look up hours or what not so I rarely have anywhere around here that I go to that's not on the map anymore. When I do, I add it and next time it's on there and it works well enough 99% of the time.
I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks.
It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.
I use Innoreader for feeds and a lot of email newsletters. If you don't like things in multiple places, Innoreader can also generate feeds from websites (with mixed results depending on the structure of the website) and can give you temporary emails that you can subscribe to newsletters in so that they'll show up in the same interface.
Not to mention that I used to be able to get my own metrics (eg. by tailing access logs on the vanity import path server, or checking stats on my version control service or server, etc.) now only Google has that information and module owners are left in the dark about how many times their code is being hit.
They also aren't being very forward thinking. The Go team keeps saying "we promise no Google exec is doing anything nefarious with that" but we don't know who will be the execs next year, or 10 years from now or what they'll do with the power the Go team just gave them by being so short sighted.
We had a big drive with the source of truth image used to boot all our machines on it, and we added rsync to the init image. When each machine booted init would rsync everything from the storage box to the local machine. We'd keep the storage machine up to date and when we wanted to update other machines in the fleet we'd just do a reboot and it would sync up the latest files (provisioning for whatever each machine was supposed to do happened later, can't remember how that was handled now). The storage machine was running ZFS so we also took a snapshot before doing any rolling reboots, so if anything did go wrong you could just revert to the previous snapshot and reboot again as long as you didn't break the init image.
Sounds jank saying it out loud, but I don't remember it ever causing us any problems.