They’re not wrong.
Of course you can fork and have full control over your fork, but Graphene and company want to be able to keep merging AOSP’s code to keep up with features and improvements.
Merging code from a divergent codebase is harder the more divergence there is, and with big codebases it can easily overwhelm small and medium-sized teams.
It’s the same reason there aren’t lots of chromium forks with manifest v2 support, while it is technically feasible, it requires a bigger effort than most projects can afford.
Keeping an open AOSP fork is not a bad idea, but it’s not clear whether GrapheneOS or any other project will be able to keep up with that workload.
Of course Linux phones require a lot of work too, but it’s work oriented towards making it work instead of towards undoing whatever sabotage google ads to AOSP, so it might motivate more people or be easier to do.
Also, both approaches are compatible.
Linux phones can use waydroid, which depends on AOSP, to run Android apps.
They’re not wrong.
Of course you can fork and have full control over your fork, but Graphene and company want to be able to keep merging AOSP’s code to keep up with features and improvements.
Merging code from a divergent codebase is harder the more divergence there is, and with big codebases it can easily overwhelm small and medium-sized teams.
It’s the same reason there aren’t lots of chromium forks with manifest v2 support, while it is technically feasible, it requires a bigger effort than most projects can afford.
Keeping an open AOSP fork is not a bad idea, but it’s not clear whether GrapheneOS or any other project will be able to keep up with that workload.
Of course Linux phones require a lot of work too, but it’s work oriented towards making it work instead of towards undoing whatever sabotage google ads to AOSP, so it might motivate more people or be easier to do.
Also, both approaches are compatible.
Linux phones can use waydroid, which depends on AOSP, to run Android apps.