With all your experience and opinions, you seem like the best guy for the job!

Congrats, from now on you're in charge of and responsible for making a non-android open-source phone (plus eco-system!) that's actually usable.

I think your criteria for "best guy for the job" is pretty lax.

Personally, I think the main criteria for that position is capital, which OP's comment doesn't even broach.

While you're not wrong, the evidence you laid out proves that such an endeavor is not so simple or easy.

My experience with open source linux phones is that they can never make basic decisions like which package manager or ui framework to target, so you end up with five completely distinct base operating systems. Some can make calls, some can receive sms and some can suspend resume. None can do all three. If they’d picked one standard approach they could have all those things with 10% the effort I’ve seen go into those ecosystems.

I don’t think there’s anything particularly hard about producing an open source linux phone with modern hardware and a supported base operating system that is competitive with a typical dumb phone.

However, none of the companies that have tried to make an open source phone are product focused enough to build such a thing.

> I really really really just want

The word just is doing a lot of work here.

E.g., you want graphics acceleration.

That means you want work done in Mesa so that the GPU in question is better supported than it currently is.

But you also want Firefox's Webrender changed to allow using the GPU in question under Linux, by default. Otherwise the browsing experience is laggy as hell for everything other than HN. That means lots of testing in Firefox, and somehow convincing them not to blacklist your GPU under Linux. (Which I'm guessing takes time since changes in Mesa don't hit every major distro all at once.)

And you also need video acceleration to work out of the box. Otherwise you're going to be trying various flag combos just to get your phone from getting hot while watching a video. And then your browsing experience probably gets laggy again.

And then you're going to need to rinse and repeat that entire process to get the baseband to work with nearly any carrier, at least in the U.S. They probably aren't going to support using that baseband on something that isn't an android phone. You'll need some reliable way around that. Is this an open research question? I don't know.

Once you have those done, try to figure out why playing music to a bluetooth speaker over this device sometimes changes the pitch of the audio! Oops, another unexpected rabbit hole.

I declare by fiat all of the above problems have been solved.

Oh no, I forgot about battery life.

Now I've got a summer project to figure out why suspend sometimes-- but not always-- freezes my phone.

After that I need to figure out the signal path between baseband and Linux to figure out why getting a call sometimes-- but not always-- wakes the phone so it rings reliably.

These are all hard things. The idea that motivated rando open source devs can roll up their sleeves and solve phone usability is laughable.

> The word just is doing a lot of work here.

I find it always does, especially when people are talking about software.

A lot of these kinds of problems go away with vertical integration and limited scope. E.g. if you only want to make phone calls and send SMS (or the internet application of your choice) so you can call it a phone, it's not terrible. You can write that. When you want to run a massive black box like Firefox on top of another massive black box like a proprietary GPU, it is terrible.

> E.g. if you only want to make phone calls and send SMS

What Linux device works with a modern baseband OS out-of-the-box with, say, Verizon or AT&T?

I think it's just as terrible as Firefox/Mesa/Proprietary GPU-- e.g., jumping on forums, pentesting magic messages to the Baseband OS, etc.

None, but the point is that trying to make a dumbphone, using Linux as an ingredient, allows each part of the product to be very specific about the other parts, whereas trying to add general phone support to Linux (say, if you plug in a USB modem) will require either a lowest common denominator or an inconsistent experience, and will have abstraction layers in the middle making the software much harder to develop. Consider that the SMS app for My Linux Dumbphone can open /dev/ttyUSB5 and send AT commands, and the experience as a whole is tested and edited by one person until it works well, while the one for KDE has to use some KDE API which either adapts to KDE Connect (which has to follow an already-designed protocol) or to a Linux kernel API which is implemented by a lowest-effort driver.

Be the change you wish to see.

How does Precursor suit you? It's an open core CPU implemented on fpga, no modem included tho (feature not a bug etc), not android but from the ground up rust os "xous"

https://www.crowdsupply.com/sutajio-kosagi/precursor

https://xous.dev/

Wow, that looks really cool actually. Still a lot of work to turn it into a usable phone but what an amazing foundation.

Problem with a non-android thing is that you lose the software platform it gives, as well as the ecosystem of apps. To do a new thing looks time consuming - the hardware and firmware has to be solid, the UI can't just be a desktop Linux in fancy dress, and then you need to write apps for stuff.

I sometimes think through doing a garmin-type thing with an e-ink display and the features I want - it works out to need way too much time: well-integrated hardware, decent low-power firmware, then the interface and custom map software is just a bit much for a spare-time thing for me (a pick one or two sort of deal). Android solves at least the ui and app problem in that case.