Project direction (don't miss this one, it has a new mid-term vision)
Wall Of Text Incoming
Dear postmarketOS hackers,
I've been thinking about the direction to take with this project. I mean we have the long term goal of the so often cited "daily driver", making postmarketOS usable for daily usage. And depending on how you look at it, we're getting pretty close to that. With the "one year" blog post we showed that phone calls are around the corner, right now only on very few devices, in the terminal and without audio. But once that is solved, calls are there and that's more or less what you need for a daily driver, right?
At least that seems to be the general reaction I seem to get when talking with people about the project. But there is much more to it and I would argue we are stuck in a proof of concept stage which we won't magically get out by continuing our current development workflows. So I would like to discuss a new mid-term vision here, that should get us to the long term (daily driver) one. But first let's take a look at where we're at.
Where we are now
1. What Is Really Missing For Daily Driver
Build Infrastructure That Scales
TL;DR: I'm maintaining software and hardware for the build repository on my own, as only user, on a PC with an i3 CPU in my home. This needs to be scaled up (and the feedback already looks very promising \o/)!
Our current approach is: everyone can contribute and work on what they like, we try to support everything and everyone. And this was a great concept for the proof of concept stage, it got us to where we are now, we had some fun stuff to present and to get new developers on board, together with serious progress that improves pmbootstrap and the OS as a whole.
But the downside is, that people only maintain software when they feel like it. Oftentimes, something gets ported and then it breaks, so we don't have ressources anymore to fix stuff. LuneOS and wireguard come to mind for example. Don't get me wrong, it's amazing that we have these ports and this is a great way to make progress and try out new stuff at all. But it's not the greatest user experience if people try these out and they are just broken.
How about we clearly split stable software from experimental software?
Stable software must have maintainers that dedicate to updating them,
like @PureTryOut does it for Plasma Mobile right now. Follow upstream
releases, and for each release, update the packages, test them, make a
merge request. I (and hopefully others
The rest of the software is experimental, and clearly marked as such I think it makes sense to ask the users to enable that experimental software explicitly. Maybe think about it like Arch Linux' AUR.
Regarding technical implementation, we could either use different folders (testing folder) or branches.
A big stability improvement would also be basing on Alpine stable instead of Alpine edge (pmaports#5). From where we are now, I would even prefer if we only offer builds on top of Alpine stable, never on edge. Because then we should have next to zero breakage with Alpine's packages, only when we are switching to the next stable version (and we can do that on an extra branch so users won't have the breakage when they stay on the old branch - as soon as the build infra is scaling this shouldn't be a problem). Building on top of Alpine edge seems to be additional effort with no benefit to me, so it would fall into the "unsupported" category for me if someone's really interested in doing that.
Always Updated Software Packages
We need to keep our software up to date. For security reasons and to minimize technical debt. Kernel releases on kernel.org happen every few days, and all other software we are packaging, all the UIs for example, and all the components they build upon also have frequent releases.
When I did initial research for postmarketOS before starting the project, I saw that Void Linux was storing a website url together with a regex in their package build scripts. That information is able to find out the latest upstream version (download the web page from the url, then run the regular expression on it). As soon as they had it, from what I understand, they would automatically increase the package version and trigger a build. So they instantly see if the build passes through, and they can notify the maintainers either way, who can then fix up the packages as necessary, and test them. And then push the update to the package repository. I like this workflow a lot, I think this makes updating software as efficient as it gets from a maintainers point of view, and I think we should implement something like that. Automatically checking for updates also allows us to build a page where you can see instantly what is out of that and what is not.
When maintenance becomes low effort like that, then it becomes realistic to go actually through with properly providing the updates.
From the client side, we would need a good mobile friendly app that
allows making updates with
apk, and searching for or installing new
software. Maybe we can use KDE's "discovery" for that (correct me if
that is not the name of the program), we would need to provide an apk
backend for it though. Adélie's also interested in that.
Working Phone Calls
This is still important of course. But when put into perspective with the other two points, I would give this the least priority and mark it as unsupported until it is much more streamlined. At least in terms of what I should be working on myself until we have that rock solid base system.
2. What postmarketOS Is Good At
We have achieved more than I ever thought we could pull of with the proof of concept we have today. Honestly, I can't thank every single contributor enough for what they have done. And here are the points where postmarketOS shines the most in my opinion:
- We have the biggest booting devices number (~100) for any non-Android Linux project on phones
- No proprietary userspace blobs necessary
- Porting new devices is pretty much streamlined with pmbootstrap
- Packaging software is easy and works on pretty much every Linux distro (with pmbootstrap)
- Huge documentation resources in the wiki
- Many mobile UIs packaged, at least partially working
- We have a big community to reach, almost 2K Reddit subscribers to our subreddit for example. If we announced tomorrow that there's a stable version of postmarketOS to test for daily usage, I bet we would get a lot of people to test it.
- As we are a downstream distro, we can provide applications for UIs that were not initially intended for them.
- Good relations to mobile UI communities such as Plasma Mobile, ubports, Maemo Leste and to Alpine and Adélie
- Quite a few developers with different expertises (kernel hacking, packaging, coding, debugging weird problems, low level hacking, artwork, ...)
Brand New Mid-Term Vision
So let's take a step back from all that and conclude what we should put our mid-term fous on. My conclusion is:
Let's become a rock stable testbed for Plasma Mobile, ubports, Phosh on roughly 100 phones. With experimental features on top (clearly marked as such) and possibly other UIs if we find maintainers (Maemo Leste, LuneOS UI?).
If we could do that, the UIs would get bigger userbases, leading to more testing, probably more developers, more stability in general and especially on postmarketOS. More popularity to our upstream friends' projects due to people being able to easily hold it in their hands. Accellerating everything non-Android Linux related that is happening on mobile phones!
Is this doable?
The biggest problem with that idea is, that basically all mobile UIs need graphical acceleration to work properly. And we don't have this on most phones, which are using downstream kernels. I'm wondering if we can use a faster software renderer and tune down the effects to make this feasible.
So we should better make a proof of concept, before deciding that this mid-term vision is where we want to go. I would highly appreciate if someone could do that, and consider doing it not on postmarketOS if it's easier. Just disable hardware accelleration on your phone where one of the mobile interfaces runs, and try to make it run as fast as you can (maybe Debian has packaged other software renderers, or there are PPAs for ubuntu or something? please fill in the research folks).
@bshah: any pointers or patches for tuning down all effects in plamo?
How About Some Dogfooding?
I think it developers should ideally use postmarketOS on a real device on a daily basis. Personally, I'm only running postmarketOS on a phone every two weeks or so, briefly, when testing a merge request. This needs to change, and I've been thinking about which tasks I could do on postmarketOS if I can't use it to make phone calls and if I can't replace my main phone with it yet.
I came up with using it as (encrypted) music player or (even better) podcast player. So I will work towards that as soon as I can fit it in with the rest I'm doing and I'm sure there are other use cases where people could already (try to) use postmarketOS today. There's also a nice YouTube video about using postmarketOS as their portable emacs machine for quickly writing notes, this would be another good use case. It would be nice if people could joint me with that, so we have a better feeling of what needs to be improved for end users.
Since last months I'm working less hours per day in my (all new) day job, and I've set three hours per workday aside for exclusively developing postmarketOS. When that is done, plus the work from my day job, then I still have free time left at the end of the day and on the weekends, so I don't burn out. So I have 15 hours per week that I can consistently work on postmarketOS (plus the extra time I put in when I feel like it, like today when I'm writing this huge post). I don't expect this from anyone else, because I know that this is a big commitment.
Besides the burn out protection, the good news is, that this makes it possible to do some more detailed planning of at least what I will be working on, and I would like to do that in the near future. Then it's clearer where the project is heading and when it's expected to be there. And with an outline like that, it should be easier for other people to help out, and if they feel like it, get integrated into that planning as well.
Alright, this has been a huge post. I'm curious about what you all think about this. When we have discussed this a bit, and some results in these new directions, this would also make a good base for a blog post to let people know what we're up to.
Thanks for reading!