How Can I Contribute OR Why YOU Will Drop Ubuntu Touch Entirely

grenudi

read md files attached. dont read. whatever.

ps

number of rewrites.png
pss
if you have seen movie "Unhinged", that's how ppl get unhinged. If you are the person who takes part of making such systems that does not even tell me where I'm being wrong, just straight up shut me up, don't wonder when you will become 'next' for such "Unhinged" person.

factcheck_v3_upstream_audit.md.txt

post_clean_hyperlinks.md.txt

grenudi

For @charly —my only contact here.

Keli

@grenudi thanks for the detailed writeup. I like your honest critique and insight on the situation.

projectmoon

What even is this?

I agree with certain points, especially about the display stack and, to some extent, the browser. Moving to QT6 is good, but moving to a normal Wayland compositor with a set of small patches to Firefox/Chromium would be better in the long run. I'm not exactly sure what "necessary functionality" from Mir would be lost, but I can't think of anything (but, I am not well-versed in the magic of Mir). I will withhold final judgment of the compositor situation until Mir 2.x is out.

The rest of it, the stuff about "pet project" and blah blah seems like unnecessary complaining. Ubuntu Touch is not a "pet project," even if one tries to stuff the definition into a specific hole. It is a volunteer-run open source project with some commercial backing. Volla is supporting Ubuntu Touch with commercial resources. They have at least one employee working on UT to make sure it runs properly on their devices, which is probably why the Volla devices (at least newer ones) have the smoothest experience. There is also apparently a commercial agreement with FairPhone for the FP4.

alan_g

Interesting perspective. I am the team lead on Mir and recognise some of the history you report on. But I don't interpret them all as you do:

Mir (display server): Canonical's alternative to Wayland. Pivoted to IoT. Wayland won.

This conflates the Mir display server and the mirclient API. mirclient was used before Mir switched to Wayland. Support for Wayland was introduced in 2017 and mirclient was dropped in 2021. Wayland did win, but Mir didn't lose.

C-02 | UBports Perpetuating the Pattern

UBports did not create the architectural problems. They inherited them.
But after 8 years, they have not resolved any of the fundamental ones:

Halium: still on vendor EOL kernels

Mir: still not standard Wayland-native

Mir is Wayland-native (for at least 5 years) and the basis of several popular desktop Wayland compositors:

Lomiri
Miracle-WM
Miriway

Mir 2.x IS a Wayland compositor. Standard Wayland client apps DO run via XWayland.

That misunderstands Xwayland - that allows X11 applications to run on a Wayland compositor,

The mirclient protocol — the native app protocol for UT Click apps — is not standard
Wayland. It is a Mir-specific extension. Miroil preserves it as a compatibility shim
over Mir2. The Mir team lead proposed Miroil in 2021 as a low-priority project.
In 2026 it is still not complete.

Miroil is complete and has been in maintenance mode since 2021, It provides API compatibility for Lomiri to make migration from Mir 1.x to Mir 2.x easier. It is not related to mirclient in any way.

Phosh's phoc uses wlroots. wlroots speaks native Wayland. GTK/Qt apps run natively.
No containers. No compatibility shims. No mirclient. One protocol. Standard.

To paraphrase: UBports Lomiri, Canonical's Ubuntu Frame, Matt's Miracle-WM, my Miriway and Budgie's Mirpie use Mir. Mir speaks native Wayland. GTK/Qt apps run natively. No compatibility shims. No mirclient. One protocol. Standard.

Using containers is a OS choice, not a compositor choice.

libremax

@grenudi

UT, on the best-supported and highest-performing devices, offers a level of functionality that isn't available in the competing projects you mention (for which I have deep respect).
For example, the fact that a system works partially on over 700 devices is of no interest to the average UT user whose device runs the system fully.
As long as UT offers competitive advantages over other systems, it will continue to attract users, developers, and partnerships.
Your beliefs about Mir are incorrect, which means your reasoning regarding UT’s architectural “problems” is flawed.
Ubuntu Touch has advantages and disadvantages (as other concurrents projects).
Your tendency toward an ideal world where all contributions could (or should) be available upstream clashes with a simple reality: many users prefer a non-mainline device that works to a mainline device that doesn’t work fully or is too slow.
And that’s why Halium is useful (currently) and why some people support and use UT (or Droidian or FuriOS).
Endlessly repeating all the "negative" things you think about certain compromises UT makes or about certain architectural choices that have been inherited and retained for lack of a realistic alternative does not seem to me to be effective in this context.

Mario.CH

Hi grenudi,

As a user—and therefore not a programmer—when I read your post and try to understand what you’re aiming to achieve, I’m actually confused.

You write the following at the end:

So: Should You Use Ubuntu Touch?

Yes, if: you enjoy the experience for its own sake, a Volla or Fairphone works for
you, you want to be part of a warm and close-knit community, you enjoy maintaining
interesting software history. You want to run model trains, not build railways.

No, if: you want your contributions to move the needle on Linux mobile broadly, you
want to upstream kernel support for new hardware, improve Wayland for all phone users,
ship apps that work everywhere, or be part of something that compounds at the ecosystem
level.

This gives me the impression that you’ve actually already made up your mind, which is why I have a serious question for you:

Why this post, since, as you yourself write, there are alternative mobile OSes where excellent programmers like yourself can contribute their best.
Actually, you should create such an OS yourself and thereby draw all the people who seem to be on the wrong track here over to it.

Because people like me don’t choose UT as a mobile OS that’s better than Android, iOS, or the other Linux-based OSes you mentioned, but rather as an alternative mobile OS that can make calls, play music, take and store photos, use GPS and other sensors, and browse the internet a bit.
And thus, views the other high-tech stuff as little more than a bonus.

Of course, there are also people who want more, but I can't speak for them.

Greetings
Mario

Translated with DeepL.com (free version)

pparent

@grenudi

Would you like to share more about your own mobile experience? I.e what mobile OS are you currently daily-driving and have you been using those last 8 years? Would you recommend using it? It might allow to understand more your stance! Thank you!

grenudi

@mario.ch yes. That is why I made the post. There are ppl who want to contribute to the Linux mobile ecosystem, and Ubuntu Touch misleads them, like I was misled here, and bought a phone to run mobile Linux to contribute upstream. and got a pet project instead of it. If a detailed explanation such as the one I provided existed on some UBports disclaimer, I would have never gone with Ubuntu Touch, and this whole mess of discussions would have never bothered this community in its cozy echo chamber of a successful alternative OS. It is a successful alternative mobile OS, but not what I had in mind as a vision of mobile Linux and not what the whole Linux mobile community has in mind (except maybe Droidian).
All the points are there: zero upstream contributions and architectural inability to contribute to any upstream. Yes, Ubuntu Touch runs better for now because it leaches off vendor infrastructure and lives on EOL kernels, where the rest of the Linux mobile community goes not for immediate results, but persistent integrated effort that goes upstream and does not leach off it. In a few years, those dozens of devices will surely run the mainline kernel and have the daily driver base needed, but any supported Ubuntu Touch devices in a few years will become offline toys because there is a need for constant effort in downstreaming security patches, and the kernels are EOL already.

Moem

@grenudi said:

this whole mess of discussions would have never bothered this community in its cozy echo chamber of a successful alternative OS.

You may have noticed that we are not suppressing your opinion, even though some parts of it may be uncomfortable to some. That alone should indicate that we are open to discussion.

grenudi

@Moem Im glad, and thankful for it. which is why I still post here. Thank you

grenudi

@projectmoon on the pet project, its not just a figure of speach. Ubuntu touch is textbook definition of a pet project:

While "pet project" is a colloquial term rather than a formal technical specification, in the context of software development and community wikis, it carries a specific weight.
Definition: The "Pet Project" in Software
A pet project is a venture maintained by an individual or a small group primarily out of personal interest, sentimental attachment, or a niche vision, rather than commercial viability, industry-standard practices, or broad ecosystem integration. Key characteristics include:

Architectural Isolation: Relying on bespoke tools that the rest of the industry has moved away from.
Maintenance over Growth: Spending the majority of resources keeping old systems alive (downstreaming) rather than building for the future (upstreaming).
Community Insularity: Existing within an "echo chamber" where personal devotion to the project outweighs its objective utility or external adoption.
How Ubuntu Touch Fits the Definition
Based on the provided research, Ubuntu Touch aligns with this definition through its structural isolation and its role as a "custodian" of abandoned corporate technology.

It is a "Rescue" of Abandoned Tech
A classic pet project hallmark is picking up what a major entity discarded. Canonical abandoned Ubuntu Touch and the Unity 8 (Lomiri) vision in 2017. The UBports community took it over not because it was the industry standard, but because they wanted to keep that specific vision alive.
Architectural Isolation
While the rest of the Linux mobile world (postmarketOS, Mobian, Fedora) converged on Wayland, mainline kernels, and shared components like Phosh or Plasma Mobile, Ubuntu Touch stayed with Mir and Lomiri.

Industry Rejection: Major players like Intel and Red Hat explicitly rejected Mir in 2013.
"Going it Alone": UBports contributes ~95% of Halium, a project other major OSs like KDE Plasma Mobile dropped years ago because it was an "uphill battle" against EOL kernels.

Maintenance of the Obsolete (EOL Kernels)
Instead of contributing to the mainline Linux kernel—which benefits all users permanently—UBports focuses on the "tedious process" of backporting patches into vendor-specific Android kernels that are already End-of-Life.

The flagship Fairphone 5 runs on Linux 5.4, which reached EOL in 2022.
This creates "offline toys" that require constant downstream effort just to stay secure, rather than integrated effort that moves the needle for the whole Linux community.

Stagnation of Core Code
A pet project often struggles to innovate beyond its original creator's input. Audit data shows that Lomiri is still 93% Canonical’s abandoned codebase, with only about 1,400 commits made between 2018 and 2025—many of which were just translations.
Draft Message: Ubuntu Touch as a Pet Project

"Ubuntu Touch has become the ultimate 'pet project' of the Linux mobile world. While the UBports Foundation deserves credit for keeping the lights on for eight years, the project is architecturally trapped in 2017. By clinging to Mir—a display server the industry rejected over a decade ago—and focusing on 'downstreaming' security patches into EOL vendor kernels, it has isolated itself from the broader ecosystem.
Unlike postmarketOS or Mobian, which contribute to mainline kernels and shared tools like ModemManager, Ubuntu Touch’s efforts benefit only Ubuntu Touch. It is a labor of love, but it is effectively a 'cul-de-sac' for developers. You spend years backporting CVEs for a Fairphone 5 kernel that died in 2022, only to realize your work doesn't move the Linux mobile needle forward by a single inch. It’s a successful alternative OS for its own small community, but it’s a preservation society, not a path to the future."

pparent

@grenudi said:

In a few years, those dozens of devices will surely run the mainline kernel and have the daily driver base needed,

I would like to add the following about the mainstream vs. halium topic:

We have to work with an industry that produces devices and chipsets that are not standardised as would be a PC, that are made for Android with closed-source drivers, and are made to be obsolete after only a few years (at least are for sell only for a few years). I really hope this logic can change.

But until then we have to work with it and it requires a lot of effort to port a new device to the point where it is fully usable, while the device has only a short period of availability. Given that it takes a lot of time to port the devices the interval between the time when the devices is ported and the time it's removed from market may be short.

Then in this context the practical difference is that porting a device to mainstream Linux takes a lot more time and effort to achieve the same level of functionalities as porting it with Halium.

I think what would really be good is that the manufacturers start to make things meant to work with mainline linux in the first place: devices and CPUs adapted to phones. And this would certainly happen if we started to have a decent adoption of Mobile Linux and some traction.

But other than that, I wonder whether porting mainline Linux to a constantly evolving hardware base, is not just too much work for the community, that has to be endlessly renewed like the myth of sisyphus.

Therefore I think a strategy can be: first attract a decent userbase with Halium, then use it as a leverage to have manufacturer produce hardware really designed for Linux on smartphone.