The difference is that there is already a great open source smartphone OS that works today, it’s AOSP.

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.

▲

Quartzium 3 hours ago | parent [-]

>OS that works today, it’s AOSP.

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.

▲

microtonal 2 hours ago | parent [-]

This comes up every time, I just don't understand the argument. You can fork AOSP when that happens. It will still be far less work than bootstrapping a viable open source alternative from scratch. Also maintaining a forked AOSP would be less work than getting the Linux desktop stack on the same level as 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.

	▲	neobrain 38 minutes ago \| parent [-]
		> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens 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.