Flathub no permitirá envíos basados en LLM

• En la revisión de envíos de Flathub han aumentado los envíos de baja calidad basados en LLM, lo que ha incrementado la carga para los revisores voluntarios y motivó a aclarar la política
• Es probable que las excepciones se apliquen a proyectos con participación de la comunidad, ciclo de lanzamientos, CI y señales de que no son resultados de bajo esfuerzo hechos en poco tiempo
• Los criterios existentes de historial de desarrollo y salud del proyecto no redujeron la carga de revisión; solo aumentaron las disputas sobre cómo interpretar las reglas
• La nueva política no busca prohibir por completo aplicaciones FOSS maduras que hayan usado LLM en parte ni aplicaciones privativas ya existentes, sino frenar los envíos de bajo esfuerzo
• Algunas personas temen un regreso de la fragmentación de distribución en el ecosistema Flatpak y que las empresas eviten Flathub, y proponen cobrar una tarifa en lugar de una prohibición total

---

Cambio de política de Flathub sobre envíos con LLM

• El motivo central del cambio es el aumento de envíos de baja calidad basados en LLM en la revisión de envíos de Flathub, que ha incrementado la carga de los revisores voluntarios
• Sjoerd Stendahl comentó que había muchos envíos de “AI-slop” en la lista de PR de Flathub y que, por su volumen, esta medida podría ser la mejor opción
• Bart Piotrowski señaló que probablemente se harán excepciones si el proyecto muestra participación de la comunidad, ciclo de lanzamientos, CI y señales de no ser un resultado de baja calidad hecho en poco tiempo
• Ya se intentaba frenar los envíos de baja calidad usando como base un historial de desarrollo suficiente y la salud general del proyecto, pero eso no redujo la carga de revisión y solo generó disputas sobre la interpretación de las reglas

Excepciones y criterios de madurez

• Nexi considera que el problema de los envíos de bajo esfuerzo a Flathub es real, pero que prohibir de forma general todo el código generado o asistido por IA sería excesivo
• Propuso que, si incluso proyectos existentes como Firefox, VSCode o Chromium pudieran quedar sujetos a eliminación sin excepción, sería más adecuado usar métricas objetivas de madurez del proyecto para filtrar envíos de baja calidad
• Bart Piotrowski respondió que esos criterios de madurez ya existían de hecho, pero que al final no lograron reducir la carga de revisión
• Nexi cree que los criterios de excepción deberían reflejarse con claridad en la política, junto con una cláusula que permita rechazar código de calidad demasiado baja sin necesidad de explicación adicional
• Sjoerd Stendahl considera que la nueva política deja excepciones para proyectos maduros y bien mantenidos, y que no pretende prohibir por completo aplicaciones FOSS verificadas que hayan usado LLM en parte ni aplicaciones privativas ya existentes

Impacto en el ecosistema y preocupación por las vías de distribución

• Dmitry Mantis expresó preocupación de que esta política vuelva a crear la fragmentación de distribución de Linux que Flatpak busca resolver
• Señaló que es una ventaja que aplicaciones privativas como Slack y Spotify estén disponibles en Flathub en forma de sandbox, y cuestionó si el código cerrado podría incluso salir beneficiado al no saberse cómo fue desarrollado
• También surgió la postura de que, aun sin esta política, sería mejor no publicar de inmediato en Flathub aplicaciones privativas de desarrolladores nuevos y desconocidos
• Se valora positivamente que algunas aplicaciones que antes solo usaban AppImage hayan comenzado a ofrecer soporte oficial para Flatpak, pero existe preocupación de que, con políticas como esta, las empresas eviten entrar a Flathub
• También se propuso que cobrar una tarifa para cubrir el costo de revisar envíos basados en IA sería mejor que una prohibición total
• Esto podría interpretarse como una señal de que primero se distribuya en otros lugares hasta alcanzar cierto nivel de usuarios, y si aplicaciones bien mantenidas que usan LLM en pruebas o automatización de documentación se consolidan en otras vías de distribución, podría disminuir su incentivo para migrar a Flathub

Evaluaciones contrapuestas sobre las herramientas LLM

• Thomas Fuchs considera que el problema de los LLM se relaciona más con las personas y el marketing que con la tecnología en sí
• Critica que las empresas de LLM los vendan como si fueran magia o esclavos personales para el trabajo, y que los usuarios crean esas afirmaciones tal cual
• Dice que, si una persona con experiencia conoce sus fortalezas y debilidades y los usa para tareas limitadas, pueden ser una gran herramienta, pero que la industria los promociona agresivamente como si “repartiera gratis motosierras encendidas para hacer malabares”
• Wolkensteine no cree que los LLM sean completamente inútiles, pero sí que en la mayoría de los casos no resultan útiles y que todavía no existe un modelo útil creado de una forma que quiera apoyar éticamente
• Considera que los modelos on-device podrían ayudar en la corrección ortográfica o la predicción de palabras del autocorrector del teclado del teléfono, pero que las tareas que pueden hacer sin errores suelen ser también cosas que una persona puede hacer fácilmente mientras aprende
• Ember opina que incluso esos posibles usos ya eran viables con herramientas anteriores a la IA generativa y que, en casos raros, un ML especializado entrenado con datos específicos puede ser mejor
• Kroc Camen sostiene que los LLM no tienen ningún uso válido en ningún contexto por el plagio de código, los sesgos incorporados y el impacto ambiental

Cultura comunitaria y polarización del debate

• trisweb considera que la cultura alrededor del código generado por LLM y de quienes lo usan a menudo no encaja con el enfoque amable y colaborativo necesario para sostener la comunidad de código abierto
• ragectl cree que las apps nuevas podrían necesitar una filosofía parecida a un período de enfriamiento, ya que antes de varias versiones y de tener un segundo colaborador humano es más probable que impliquen riesgo
• Sjoerd Stendahl advierte que hay que cuidarse de una cacería de brujas, pero considera que el impulso agresivo de los LLM por parte de las grandes tecnológicas está alimentando el rechazo de la gente
• Señala que algunos empleadores exigen el uso de LLM en el trabajo bajo amenaza de despido, que incluso funciones simples como la búsqueda se han deteriorado, y que el “Agentic future” responde a una demanda muy limitada, aunque muchos productos se estén volviendo como residuos que imitan el trabajo humano
• razze opina que el problema de usar LLM en búsqueda o chatbots es distinto al de usarlos en código, y que el código puede demostrarse y sus trade-offs son claros, por lo que debería evaluarse por separado
• Zeeshan Ali Khan señaló la agresividad del campo anti-LLM, y Bart Piotrowski respondió que la polarización es fuerte tanto entre pro-LLM como anti-LLM, y que los “vibecoders” también se comportan como víctimas cuando reciben críticas

[GN⁺]

Comentarios en Lobste.rs

• Que "no se permiten aplicaciones que incluyan código, documentación u otro contenido generado o asistido por IA" suena bastante tajante
  Flathub es un lugar muy popular donde los usuarios de escritorio Linux obtienen apps, se describe a sí mismo como una "tienda de aplicaciones para Linux" y tiene más de 1000 apps
  ¿De verdad significa que ninguna de esas apps puede usar código asistido por IA? ¿Es realista? ¿No es ya demasiado tarde?

  • Al ver la frase "se pueden permitir excepciones para proyectos maduros y bien mantenidos", parece más bien que la intención es impedir que se suban proyectos hechos totalmente con vibe coding y luego se abandonen
  • Nunca es demasiado tarde
    Incluso los proyectos ya publicados en FlatHub pueden eliminarse si se descubre que fueron hechos con vibe coding, y también se puede enviar un mensaje claro
  • Parece que esta regla se aplicará con discreción
    Es posible que algunas aplicaciones importantes ya existentes se consideren excepciones, y aun en esos casos la restricción probablemente se aplique más al empaquetado de flatpak independiente que al código de la app en sí

• Puede que este enfoque tan duro no sea 100% aplicable, pero en una situación donde las empresas están empujando la adopción de LLM, hace falta una postura así de fuerte como mínima forma de resistencia que la comunidad puede ofrecer

• Pensando en los incidentes recientes relacionados con la cadena de suministro, suena como una decisión bastante razonable

• Si un proyecto quiere prohibir los LLM, o a las personas con canas, o a las personas que miden exactamente 160 cm, apoyo al 100% su libertad de decidirlo
  No estoy diciendo que esa libertad deba limitarse, pero el mantenimiento de paquetes es el tipo de trabajo repetitivo donde la ayuda de un LLM puede ser muy útil
  También entiendo hasta cierto punto a quienes creen que su código es producto de las bellas artes o de la artesanía, pero ¿qué razón hay para no dejar que se automaticen las tareas más aburridas?

  Recuerdo que cuando el AUR de Arch Linux acababa de empezar, había personas que mantenían con éxito cientos de paquetes
  Siempre estaban actualizados y casi nunca se rompían, así que obviamente debían estarse actualizando de forma automática
  Si hoy se hiciera lo mismo con ayuda de LLM, casi con seguridad podría volverse aún más robusto

  Tal vez habría que prohibir a los humanos en el proceso
  Aparte de los ataques a la cadena de suministro, ¿qué pueden aportar los humanos? Algún día debería crear una distribución de LLM para demostrar si mi postura es correcta o no
  Pero antes tengo que terminar este lenguaje de programación jaja