Firstly, you're relying on a downstream kernel which is impossible to maintain beyond LTS (Some of the smartest folks in the community tried HARD and failed to actually forward-port Android kernels). This exposes you to a whole host of poorly tested codepaths and non-standard drivers which require a whole host of userspace workarounds.

AOSP itself is so vast and complicated that it's just never gonna be possible to escape the grip of Google.
2/8

To even build your own Android image you need to jump through a bunch of hoops, download hundreds of GB of source code and take >1 hour on even a beefy build machine with ~100GB of binary artifacts. There ARE benefits to having the entire OS source code locally IF you're building an OS the way Google do with many separate teams who work independently.

But this is never how healthy FOSS projects work, they rely on individuals showing up and working in harmony together, something which is just plain annoying to do with AOSP.
3/8

Showing my obvious bias here, but let's compare this to postmarketOS. The requirements for space, performance, and network bandwidth are an order of magnitude smaller... The biggest thing you have to compile is the Linux kernel.

The "onboarding" process for postmarketOS developers often starts with a downstream port, where you boot using the original Android kernel. This often gets you just far enough to have ssh working but not a lot more. But importantly it gets your in touch with other developers in the community and it gets your familiar with our tooling.
6/8

After this, if you want to go further then you basically have to learn kernel development. This can be a huge challenge, but it's something our community encourage and write plenty of guides and documentation to help.

The fundamental approach is different: you don't have to be running a specific distro or install a bunch of tools, you just run pmbootstrap and it does everything for you. It creates template packages for you and guides you through every step of the process. Compare this to having to manually edit XML files, get acquainted with the repo tool, and wait potentially hours to clone all the git repos.
7/8

When it comes to creating a truly emancipatory mobile OS, it is beyond absurd to consider AOSP as the basis. I truly believe that Linux Mobile and decentralised development built on top of FOSS is the only way. The same goes for making it as simple as possible to onboard and teach new developers, the more knowledge is shared and the more people are skilled up the more resilient we become.

TL;DR: FSF please reach out and let us help you actually bring freedom to people! I can be reached at [email protected]
8/8

oh and when it comes to kernel development, that is (imo) a much more transferable and useful skill than being able to hack on AOSP. I know several people at this point (including myself!) who's entire career was only possible because of the postmarketOS community.

In the long run, the more independent developers we get contributing to upstream Linux the more we will be able to bring maintainable and resilient software to all the billions of smartphones out in the world, further reducing our dependence on big tech.

@cas I do wonder about everything that gets lost tho. In order to be emancipatory and empowering (and as a direct consequence of easing individual development) you have to increase choice, and thus complexity. For instance, the unified ecosystem, with a single stack, package manager, design language, API set, etc. is gone. Instead, you got community Linux (and ngl, not just Linux!) where, besides the glibc API, Systemd, Wayland and FreeDesktop (somewhat), there’s not much of a consensus, for better or worse.

This is, indeed, culture and politics, and they’re all directly tangible not just by devs and contributors, but also by users. Everyone needs to know where to get started and how. I wonder if we could do better than the status quo, instead of translating our fights into user liability. Perhaps e.g. by creating some sort of federation that makes getting started easy, via consensus mechanisms, websites and documentation?

It also makes me wonder about efforts like Tow-Boot, which seem completely stagnant, as well as the possibility to take ideas away from e.g. GKI and GSI. Standardizing everything into well-abstracted layers would most definitely bridge the gap between the expectations of a PC and the diversity of the mobile world, and hopefully ease development. But again: culture and politics.

@xerz Thanks for raising these points! This is definitely an interesting topic.

I don't agree with the implication that increasing choice and thus complexity is inherently negative:

Just considering the mobile ecosystem (since it has a more tangible scope for me at least), postmarketOS was the first major effort here. If we had tried to discourage folks from creating Mobian, Kupfer, nixOS-mobile, etc. The end result would likely be less communication between these projects... It simply isn't possible to create a unified ecosystem this way.

And fwiw we aren't even unified on glibc, since pmOS is built on Alpine, we had to put a lot of work into getting systemd and musl to somewhat work together.

But consider even just at the tiny scale of postmarketOS, we are able to offer a huge range of interfaces on top of a massive list of device exactly because we encourage choice, does this increase complexity somewhat? YES, but the end result unifies our community around the core goal of building a mobile operating system. We are able to focus on things like UI and apps as well as deeper UX like the initramfs/recovery environment, installation process, and immutable effort as a single community.

In my opinion postmarketOS is working towards creating a "federation" of sorts exactly as you describe. Heck maybe that becomes a more formal effort in the future...

We previously have discussed making a "linux mobile" website which covers the major distros, interfaces, and describes the overall goal as a way to introduce people to the movement, I think this is absolutely something we should revisit.

At the end of the day though I think it's very important to have *opinionated defaults* that offer the best possible experience for the average user, and I do think that's something we should come to agreement on.

Regarding GKI/GSI, I would actually consider these efforts to hugely raise the level of complexity. Consider what they are trying to solve (vendors not updating their drivers...) and why (money, mostly). In practise many vendors don't follow these abstractions properly, so things break... These kinds of technical efforts are only required when most of the development is done by people who have no ideological interest and are just getting paid to do their work (which i have no problems with fwiw, that's capitalism...)

When it comes to software created by people with a greater goal and a deep care for users, that's when people build things like postmarketOS which are tooling-first, well documented and easy to get involved in. We have to have this care because we want to attract new developers and new users, it's an earnest effort to improve peoples lives. As long as everyone works towards that fundamental goal I think the rest will fall into place over time.

Regarding tow-boot specifically, it's a shame that it went the way it did, i think the scope was too big from the get go. We are starting a new similar effort over at https://tauchgang.dev with muuuch stricter requirements, instead requiring device maintainers to step up if they want their device to be supported and ensuring they stick around to maintain it.