We have updated Flathub's LLM policy to explicitly disallow AI usage for both the submission process and applications being submitted.
https://github.com/flathub-infra/documentation/commit/992f57b30de98ddbd5e80959e9672998c83c8c97
I've had some reservations about it, so the wording before that commit was relatively milder. I know it's an unpopular opinion on the Fediverse, but I do think LLMs are inevitable, and the reality is that you can expect less organically grown code as time goes on. I believe it can be a useful tool in and outside FOSS; I hoped we will see a larger number of apps where authors made some effort beyond prompting an agent. Meanwhile, the number of unpleasant interactions I've had with entitled submitters acting as if they were bestowing their brilliant software upon us idiots who are rejecting it went through the roof in the last month. I'm tired.
As always, we are not applying this retroactively, so any vibecoded apps which were already published will remain available.
Existing apps are grandfathered in and there are other exceptions, but in general LLM generated code is not permitted on the Linux app store anymore.
The rule change doesn’t target vibe coded apps. It targets anything that has AI assisted code, documentation or otherwise. Essentially anyone using a jet brains or microsoft development environment is using text completion which is ml based.
Let’s not even talk about one of the few things llms are actually good at, keeping documentation up to date. The one thing developers and engineers have always been terrible at and always will be terrible at.
Does AI assisted also mean that anything where AI has viewed the code and provided feedback is also banned such as AI code review? Which is another area where models provide good value, while increasing the quality of software.
Does AI assisted also mean using monitoring environments that use models for bug diagnosis? Such as Sentry and many others?
That’s a lot of engineers, and projects, some of which have been around for a long time that are rejected from now on. If they stick to the letter of the rule.
If flat hub can enforce that and I don’t know how then they’re essentially dead. Without actually making a difference in regards to rejecting vibe coded applications.
This is not longer about whether they’re capable of not, they’re just a mere tool, it’s about supporting an unsustainable industry that’s destroying the environment, economy, society and already working technologies for… well, nothing, it’s not even profitable yet, they’re slowly getting into the find out stage.
Not to say that, even if they are capable of “keeping documentation up to date”, they’re unable to do software engineering, most software projects fail because bad design decisions. And btw, documentation is not limited to code comments, API endpoints or whatever a JavaDoc is in your target programming language (methods and attributes comments, if OO, on how they work / what they do / how to use them).
Professional grade documentation goes beyond that, begins with the problem you’re trying to solve and goes all the way to the end of life of your system. Yes, it’s hard to maintain it up to date and will slowly become outdated, but it’s bound to happen, it’s almost as if you wanted to have 100% of testing coverage, it’s economically impossible.
The rule change doesn’t target vibe coded apps. It targets anything that has AI assisted code, documentation or otherwise. Essentially anyone using a jet brains or microsoft development environment is using text completion which is ml based.
Let’s not even talk about one of the few things llms are actually good at, keeping documentation up to date. The one thing developers and engineers have always been terrible at and always will be terrible at.
Does AI assisted also mean that anything where AI has viewed the code and provided feedback is also banned such as AI code review? Which is another area where models provide good value, while increasing the quality of software.
Does AI assisted also mean using monitoring environments that use models for bug diagnosis? Such as Sentry and many others?
That’s a lot of engineers, and projects, some of which have been around for a long time that are rejected from now on. If they stick to the letter of the rule.
If flat hub can enforce that and I don’t know how then they’re essentially dead. Without actually making a difference in regards to rejecting vibe coded applications.
Ok, I’ll take the bait.
This is not longer about whether they’re capable of not, they’re just a mere tool, it’s about supporting an unsustainable industry that’s destroying the environment, economy, society and already working technologies for… well, nothing, it’s not even profitable yet, they’re slowly getting into the find out stage.
Not to say that, even if they are capable of “keeping documentation up to date”, they’re unable to do software engineering, most software projects fail because bad design decisions. And btw, documentation is not limited to code comments, API endpoints or whatever a JavaDoc is in your target programming language (methods and attributes comments, if OO, on how they work / what they do / how to use them).
Professional grade documentation goes beyond that, begins with the problem you’re trying to solve and goes all the way to the end of life of your system. Yes, it’s hard to maintain it up to date and will slowly become outdated, but it’s bound to happen, it’s almost as if you wanted to have 100% of testing coverage, it’s economically impossible.