what Secureblue is to you
It’s my daily driver 
Aside from that, you’ll have to be more specific
including not very technical users in some cases
This is a rather strange question. I wouldn’t consider desktop linux in general to be recommendable to non-technical users, regardless of distro/image/etc. So again you’ll have to be more specific.
On top of that, the reason secureblue (and any other hardened version of an existing desktop linux system) would need to exist in the first place, is because the changes made will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. 
Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so for security reasons, by default, with mechanisms for reenabling broken use cases.
So, asking about “non technical users” in the context of a hardened system is a bit of an oxymoron, definitionally. The only reason a hardened version of an existing desktop linux system would need to exist is if the hardening wasn’t upstreamable for usability reasons. When I hear “not very technical users”, I think users who wouldn’t be using desktop linux to begin with, let alone fixing their specific use cases that are deliberately broken ootb by following docs and flipping toggles.
(
ujust --choose TUI, showing the available toggles and commands)
feel committed to
yes
short term passion project or uni project
no, secureblue was initially created because I wanted a hardened daily driver built with Fedora Atomic’s bootable OCI container image tooling. Expanding the project and bringing in new contributors has gotten it to a place I wouldn’t have been able to on my own, so it’s a win-win. I still need a hardened daily driver and don’t see any reason why that would change, so I still need secureblue
at the same time still quite new
secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages (hardened-chromium, hardened_malloc, etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: Blue-Build), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on the hardening, and not waste time doing manual maintenance.
We’ve heavily put effort towards automation. Like I mentioned earlier, Rootkit404 built out a multi-step automation pipeline for hardened-chromium, caching the cleaned chromium sources in an rpm that’s then ingested by the primary builder. All of this can be triggered via webhooks on a schedule from github actions. We even automatically pull the chromium version from google during the build so we don’t need to bump it manually. And of course, secureblue builds daily, automatically. My point being that when it comes to “doing work on the project”, that largely means making the images even more hardened than they already are. Our maintenance is largely automated with low manual overhead. Our automation is almost thorough enough that if every secureblue contributor took a three month haitus from secureblue, builds would keep flowing and users wouldn’t even notice. Not that I’m planning on doing that, I’m just emphasizing that given how automated the project is, long-term maintenance for the project is actually not a significant commitment, and I see no reason why I wouldn’t be doing that long term. Same goes for long term development (working on improving the hardening), but of course that’s a more significant commitment and so my time invested into it will wax and wane month to month, as it has been already.
currently rests solidly on your shoulders
This is largely no longer accurate. Look at the pull request history for secureblue and hardened-chromium We have a half dozen or more regular contributors. There’s also another contributor who is working on building us a website forked from GrapheneOS’s, and I’m not even involved in that work. Don’t mistake the BDFL model for a one man show
, which renders them unacceptable for recommendation.