Since then the problem has always been the same, rebooting the DE experience for the sake of it, desktop environment wars, rebooting the development stack from GNOME and KDE, and the problem that despite all OEMs have Linux running on their data centers, the community has to reverse engineer the hardware from the same OEMs.
But yeah, then there was the constant forking, preferring rebooting development over iterative improvement (e.g. GNOME 2 -> 3 was really a hard cut for a lot of people, resulting in forks that exist till this day), hostility towards closed-source applications (you can hate them as much as you want, but people are not abandoning Photoshop/Illustrator for GIMP/Inkscape on a whim), etc.
Hopefully something changes with all the government-driven sovereignty desktops that are popping up, the resulting influx of money, and KDE EV et al. becoming very mature organizations.
The most effective path would be for the FLOSS ecosystem to pour their resources into making AOSP independent from Google. But instead people will just fork N half- or non-working solutions for reasons.
But you have no guarantee what happens tomorrow with it, depending on what Google feels like. You just have to eat whatever Google decides.
With Linux there's no such centralized control. So the time and effort will pay out later on down the road. Let Google have its AOSP.
Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.
To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.
Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.
This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.
In any case, were google turn malicious, it wouldn't only be in the interest of individuals to maintain a fork, plenty of companies are invested in the health of the platform that will help out.
Also, it's a false equivalence - it's also easier to buy a walkie talkie, but that's also not replacing Android smartphones. "Gnu/Linux" userspace is simply not even close.
The financial interest that is based on advertisements?
At worst you take the last available version that is half a years old and do a hard fork and start worrying about the issue then.
Define standards beneficial to them like hardware attestation, passkeys. Like they do with Chrome and Manifest-v3.
> do a hard fork
> https://news.ycombinator.com/item?id=50061384
How does citing your own prior comment, one which itself offered no justification for its claim, add value of any kind to your response?
"I am become, Source? I Made It Up, destroyer of discourse."
In your own words, "please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize."