Banning one-shot vibecoded apps from submitters who don't understand them is one thing, but "no part of that process can be automated using AI tools or agents, including the manifest, metadata,...
Banning one-shot vibecoded apps from submitters who don't understand them is one thing, but "no part of that process can be automated using AI tools or agents, including the manifest, metadata, patches, build scripts and the PR itself" seems like it would include an enormous swath of modern software projects, if what I've seen about agentic coding in the industry is remotely accurate. It also seems difficult-to-impossible to police.
I'm sure the policy's harshness is more about making it easier to shut down submissions than having to justify each rejection on a case by case basis. After all. They've said they will allow it...
I'm sure the policy's harshness is more about making it easier to shut down submissions than having to justify each rejection on a case by case basis. After all. They've said they will allow it for more mature apps.
According to this blog post, there were only around three volunteer reviewers, and they were getting overwhelmed because people were using AI to automatize the whole process, including replying to the reviewers feedback. In other words If you are asking for human attention, demonstrate human effort
Flathub only has so many resources to allocate to verifying whether a package is vibe coded. Code is actually not the best indicator and it takes too long to audit, so banning anything that looks...
Flathub only has so many resources to allocate to verifying whether a package is vibe coded. Code is actually not the best indicator and it takes too long to audit, so banning anything that looks like it might have used AI in some part of the process, like the very visible README that can often more clearly be discerned as AI-written, is efficient, and generally correct.
It's a good thing. The software could work perfectly and I still wouldn't trust it to keep doing so if the author can't be arsed to do small things that matter themselves. Especially docs! So far, I haven't heard of a single thing suffering from banning AI use and I don't see why Flathub would.
Yeah I don't know what the issue with labeling apps that have used AI is, and allowing people to filter out results based on that. Unfortunately I do think this spells the beginning of the end of...
Yeah I don't know what the issue with labeling apps that have used AI is, and allowing people to filter out results based on that.
Unfortunately I do think this spells the beginning of the end of Flathub, because I have heard from so many developers even before AI that the process of getting their flatpak was already notoriously difficult and a pain in their ass, that this is just going to make them not want to support flatpak at all.
And because the bar is low as ever it will be because of AI, this hurdle creates a newd for an unrestricted community run FlatHub alternative with less restrictions. Which probably won't be good for anybody.
Off the top of my head here are some solutions: CLI problem: Create an "AI Warning" flag or env var that warns if a flatpak used AI through metadata. Allow the user to make it default or not....
Off the top of my head here are some solutions:
CLI problem: Create an "AI Warning" flag or env var that warns if a flatpak used AI through metadata. Allow the user to make it default or not.
Verification problem: Initial verification is self reported, but outsource later verification to the community. Have "verified" and "unverified" tags in Flathub, allow users to opt in into seeing "unverified" apps with a disclaimer understanding the risks. Also you can use non-AI algorithms to score and fingerprint code that take into account a multitude of factors like the format of the comments, amount and type of typos/mistakes/bugs, the order of blocks, etc.
My app was already rejected under these rules just because one moderator thought that AI might have been used to write the README file for the repository. It seems that the team behind Flathub...
My app was already rejected under these rules just because one moderator thought that AI might have been used to write the README file for the repository.
It seems that the team behind Flathub wasn't prepared to scale to the current level of demand and modern development practices. Otherwise, they would have invested more in the moderation process or automated quality assurance instead of relying on just two guys to manually review every application and assume that AI is behind every pull request.
Banning one-shot vibecoded apps from submitters who don't understand them is one thing, but "no part of that process can be automated using AI tools or agents, including the manifest, metadata, patches, build scripts and the PR itself" seems like it would include an enormous swath of modern software projects, if what I've seen about agentic coding in the industry is remotely accurate. It also seems difficult-to-impossible to police.
I'm sure the policy's harshness is more about making it easier to shut down submissions than having to justify each rejection on a case by case basis. After all. They've said they will allow it for more mature apps.
According to this blog post, there were only around three volunteer reviewers, and they were getting overwhelmed because people were using AI to automatize the whole process, including replying to the reviewers feedback. In other words If you are asking for human attention, demonstrate human effort
Flathub only has so many resources to allocate to verifying whether a package is vibe coded. Code is actually not the best indicator and it takes too long to audit, so banning anything that looks like it might have used AI in some part of the process, like the very visible README that can often more clearly be discerned as AI-written, is efficient, and generally correct.
It's a good thing. The software could work perfectly and I still wouldn't trust it to keep doing so if the author can't be arsed to do small things that matter themselves. Especially docs! So far, I haven't heard of a single thing suffering from banning AI use and I don't see why Flathub would.
Yeah I don't know what the issue with labeling apps that have used AI is, and allowing people to filter out results based on that.
Unfortunately I do think this spells the beginning of the end of Flathub, because I have heard from so many developers even before AI that the process of getting their flatpak was already notoriously difficult and a pain in their ass, that this is just going to make them not want to support flatpak at all.
And because the bar is low as ever it will be because of AI, this hurdle creates a newd for an unrestricted community run FlatHub alternative with less restrictions. Which probably won't be good for anybody.
Everyone gets their packages through the CLI. That would be annoying. Besides, the issue is with verification.
Off the top of my head here are some solutions:
CLI problem: Create an "AI Warning" flag or env var that warns if a flatpak used AI through metadata. Allow the user to make it default or not.
Verification problem: Initial verification is self reported, but outsource later verification to the community. Have "verified" and "unverified" tags in Flathub, allow users to opt in into seeing "unverified" apps with a disclaimer understanding the risks. Also you can use non-AI algorithms to score and fingerprint code that take into account a multitude of factors like the format of the comments, amount and type of typos/mistakes/bugs, the order of blocks, etc.
My app was already rejected under these rules just because one moderator thought that AI might have been used to write the README file for the repository.
It seems that the team behind Flathub wasn't prepared to scale to the current level of demand and modern development practices. Otherwise, they would have invested more in the moderation process or automated quality assurance instead of relying on just two guys to manually review every application and assume that AI is behind every pull request.
So as always in libre world, we need more volunteers.