Hi everyone,
I maintain three small open source Linux configurators for hardware that only ships Windows software:
They’re Python + Tk, talk to the device directly over /dev/hidraw, have a CLI and a GUI, and are MIT licensed.
Before I spend time on a submission I want to be upfront: most of the code (reverse engineering of the official apps, the protocol, the GUI, the tests) and the packaging was generated with Claude. My part was testing every feature on the real hardware, the design decisions and reviewing the changes. I read the Generative AI policy, so I would write the Flathub manifest and the PR myself and disclose all of this in the form.
A few questions:
- With that much AI-generated code, is a submission worth it, or would it most likely be closed?
- The apps need --device=all (raw HID, no portal covers it) and a udev rule installed once on the host. Is that acceptable for this kind of tool?
- The projects are only a few days old. Should I wait for more history and real-world use before submitting?
For now they’re available as Flatpaks from my own signed repo: Miguel Sanz Flatpak repository
Thanks! (sorry my bad english)
No, these applications would not be accepted. Not only are they too young, but the AI usage is too high.
Even ignoring the dubious copyright situation and the massive environmental impact of AI, there is an quality issue with AI code.
Many who try to submit today on our platform only have vibe-coded AI code made in a few days. This poses many issues:
- AI generation isn’t perfect. It’s code will include bad practices (as we often see with AI-generated manifests)
- Many vibe-coder don’t have the necessary experience in understanding their own code. And probably never will, since using AI takes away the important process that allows you to build a skill in the first place.
- Since the barrier to creating an application is very low, there’s often no investment in the software to maintain it. So we would just end with abandonware.
So we have to be very picky about allowing AI code if we want some amount of quality on Flathub. Your applications don’t hold the threshold now, and probably not later as well.
Apart from that:
Why are you creating separate applications for different devices? For mouses and keyboards, there has been an project to provide a unified method for configuring it with libratbag, with Piper as an frontend.
Vibe-coding an application isn’t the best solution. Contributing to existing projects can often be better.
Installing on or relying on anything from the host is also a big no-no.
Even if this was purged from any AI code, we cannot accept an application that is not keeping to its sandbox.
Is that so? I myself have an application published on Flathub that instructs users to install additional Udev rules on first launch. Unfortunately, the only viable alternative is submitting these to systemd as hwdb entries, which takes time from submission to release to adoption and is completely out of flatpak’s control. Restricting submissions due to having to deal with existence of unfortunate system-level sandboxing that flatpak itself doesn’t help with seems pointlessly limiting to me and efffectively prevents any applications that need to talk to devices from getting distributed.
Maybe udev rules should be exportable like desktop entries?
Is that so? I myself have an application published on Flathub that instructs users to install additional Udev rules on first launch.
you can, especially if it is for some optional feature. But by design, the idea is for each sandboxed app to be its own thing, and to deal through portals and static permissions
the policy is no host-dependant application. We reject anything that requires the host to have a daemon or some random app or DE for a flatpak to function normally by default.
Basic functionality should come out of the box. Else people just reinvent the nineties with the app who just shows a “error: libkbfh-3w-76t3.476t-3887 not found please frobinate the zobinate before trying again” at launch before immediately exiting.
though we are moving to being wildly out of topic now. The question is answered lets move on
