QGIS prohíbe las contribuciones asistidas por IA y cierra la puerta tras fracasar su primera política
QGIS prohíbe las contribuciones asistidas por IA mediante una política estricta aprobada el 7 de octubre de 2026, pese a haber permitido anteriormente la participación de IA etiquetada. El proyecto de cartografía de código abierto ahora prohíbe el código creado con un LLM, un sistema de IA o un flujo de trabajo basado en agentes. Las infracciones pueden provocar la reversión del código y sanciones contra los derechos de un contribuidor.
La decisión es más que otra norma contra los parches automatizados de baja calidad. QGIS probó primero un enfoque más permisivo, basado en la divulgación y la responsabilidad humana. Los participantes del proyecto concluyeron que ese enfoque no protegía a los mantenedores de un trabajo de revisión excesivo ni preservaba la confianza que sustenta el desarrollo comunitario.
Esa experiencia sitúa a QGIS en un lado de una creciente división en el código abierto. QEMU también rechaza las contribuciones generadas por IA, mientras que el kernel de Linux permite asistencia divulgada bajo responsabilidad humana. La disyuntiva está entre la restricción en el límite del proyecto y la rendición de cuentas durante la revisión.
QGIS prohíbe las contribuciones asistidas por IA tras fracasar su primera política
El cambio decisivo es que la divulgación ya no hace que el código asistido por IA sea apto para su inclusión.
La política de herramientas de IA aprobada establece que no se permiten contribuciones de código asistidas por LLM, IA o agentes en el repositorio principal de QGIS. También advierte de que su descubrimiento posterior puede llevar a una reversión y a sanciones para el contribuidor.
QGIS adoptó el texto revisado mediante una QGIS Enhancement Proposal, o QEP. Una QEP es el proceso del proyecto para debatir y registrar cambios técnicos o de gobernanza significativos. El contribuidor Nyall Dawson abrió la propuesta el 24 de septiembre y la describió como un cambio formal a “NOT ALLOWED.”
La propuesta pasó a votación el 5 de octubre. Se declaró aprobada con votos de apoyo de cuatro participantes del proyecto identificados el 7 de octubre. Dawson integró ese día el cambio en el repositorio de propuestas de mejora del proyecto.
La redacción importa porque QGIS operaba anteriormente con una política más permisiva. La participación de IA podía divulgarse, etiquetarse y revisarse mediante un enfoque con intervención humana. El contribuidor seguía siendo responsable, mientras que la etiqueta ofrecía a los revisores información sobre cómo se produjo el parche.
Ese compromiso fracasó en la práctica, según participantes del debate sobre la política. Un revisor estimó que unas 50 solicitudes de extracción habían recibido una etiqueta “AI Assisted”. Aproximadamente 40 de ellas se cerraron sin integrarse, aunque las cifras se presentaron en la discusión y no en una auditoría formal.
El proceso anterior también contemplaba una etiqueta “extractive” para contribuciones que consumían un esfuerzo comunitario excesivo. Un participante afirmó que esa etiqueta nunca se creó. Esa brecha dejó a los mantenedores con un concepto de política que no se reflejaba de forma coherente en el trabajo diario del repositorio.
Durante el debate se citaron cuatro solicitudes de extracción asistidas por IA y cerradas el 2 de octubre. Abarcaban lógica de clasificación, un listener de PostgreSQL, conjuntos de datos geoespaciales compartidos y creación paralela de proveedores. El alcance muestra que el conflicto no se limitaba a cambios cosméticos.
La política se aplica específicamente a las contribuciones de código en el repositorio principal de QGIS. El texto adoptado no prohíbe explícitamente todos los cambios asistidos por IA en incidencias, comentarios, traducciones o documentación en todos los canales de QGIS.
Varios contribuidores querían una norma más amplia que cubriera las interacciones escritas. Otros buscaban un texto más acotado que distinguiera el código generado de la investigación, el autocompletado, la traducción o la revisión privada. El texto final mantuvo la expresión más amplia “AI or agent assisted code contributions.”
Ese límite no resuelto importará durante la aplicación de la norma. Un agente de programación autónomo entra claramente dentro de la prohibición. Un contribuidor que copie código generado por un modelo en un parche también parece estar cubierto.
El estatus del autocompletado mediante aprendizaje automático, la depuración asistida por IA o la lluvia de ideas de diseño es menos explícito. Esas actividades pueden influir en el código sin aportar un bloque identificable de texto generado.
Por ahora, QGIS ha elegido un límite cerrado. Los contribuidores no pueden hacer aceptable código prohibido simplemente etiquetándolo, revisándolo o asumiendo responsabilidad personal por él.
El tiempo de los mantenedores se convirtió en el recurso escaso
QGIS considera la atención de revisión como un activo comunitario limitado, no como un servicio gratuito asociado a cada parche enviado.
Los sistemas de programación con IA pueden producir un cambio plausible mucho más rápido de lo que un mantenedor experimentado puede evaluarlo. Los revisores aún deben comprender el subsistema afectado, probar supuestos, examinar casos límite y considerar el mantenimiento futuro.
Esa asimetría cambia la economía de la participación en el código abierto. Generar un parche puede llevar minutos. Determinar si pertenece a una aplicación geoespacial madura puede requerir horas o días.
QGIS no es un pequeño repositorio de demostración. Su visión general del proyecto describe usos de escritorio, servidor, web y móviles para cartografía y análisis geoespacial. La comunidad también mantiene más de 2.000 complementos.
Los cambios en ese entorno pueden afectar formatos de datos, sistemas de coordenadas, renderizado, bases de datos espaciales y flujos de trabajo automatizados. Un parche que parece correcto de forma local puede introducir consecuencias más allá del caso de prueba inmediato del contribuidor.
Por tanto, la revisión depende de más que superar comprobaciones automatizadas. Los mantenedores necesitan confiar en que un contribuidor comprende el código circundante y puede responder preguntas después del envío.
Un participante ofreció una explicación inusualmente directa de ese problema de confianza. El contribuidor había enviado dos correcciones de regresiones asistidas por IA después de utilizar un LLM para investigar errores, sugerir cambios y revisar código.
Los parches creaban una ilusión de competencia, escribió el contribuidor. La herramienta hacía parecer posible reparar una base de código compleja sin haber desarrollado los conocimientos suficientes para respaldar el trabajo de forma independiente.
Esa admisión recoge la preocupación central detrás de la política de contribuciones de IA de QGIS. Un parche no llega solo. Crea una relación entre su autor, su revisor y quien mantenga posteriormente el código afectado.
Un contribuidor con conocimientos puede explicar por qué un cambio es seguro, revisarlo tras recibir comentarios y reconocer fallos relacionados. Alguien que reenvía la salida de un modelo podría no ser capaz de hacer ninguna de esas cosas.
El revisor se convierte entonces en el verdadero autor del razonamiento. Debe reconstruir el problema, verificar la solución propuesta y enseñar al remitente lo que el parche ya afirma comprender.
Esa carga de trabajo se vuelve extractiva cuando consume repetidamente más conocimiento del proyecto del que crea. El repositorio obtiene un cambio propuesto, pero la comunidad pierde tiempo que podría destinarse a lanzamientos, contribuidores existentes o correcciones cuidadosamente preparadas.
El peligro no es simplemente que el código generado por IA contenga errores. Los parches escritos por humanos también fracasan en revisión, pasan por alto casos límite e introducen regresiones.
La diferencia es la capacidad de envío. Los agentes de programación reducen el coste de producir otro parche plausible sin reducir el coste de demostrar que ese parche merece confianza.
Los contribuidores de QGIS también vincularon esa presión con la continuidad de la comunidad. Los proyectos de código abierto necesitan recién llegados que se conviertan gradualmente en revisores, mantenedores, formadores o proveedores de soporte.
Si la IA permite que las personas se salten el proceso de aprendizaje, esos contribuidores podrían no adquirir nunca los conocimientos necesarios para revisar el trabajo de otra persona. El proyecto recibe más envíos sin desarrollar más mantenedores.
Eso crea un embudo poco saludable. El extremo más amplio se expande porque más personas pueden generar código. El extremo más estrecho permanece fijo porque los humanos experimentados siguen tomando las decisiones de aceptación.
Una base de conocimientos de ingeniería bien mantenida puede reducir el tiempo dedicado a redescubrir la arquitectura y las decisiones anteriores. No puede transferir la responsabilidad de un parche desconocido de su autor a un revisor voluntario.
QGIS ha respondido limitando lo que entra en el embudo. La política sacrifica cambios potencialmente útiles asistidos por IA para proteger a las personas responsables de decidir qué se publica.
La verdadera división es entre restricción y responsabilidad humana
Los proyectos de código abierto coinciden en que los humanos siguen siendo responsables, pero discrepan sobre si la responsabilidad por sí sola puede controlar el volumen generado por IA.
QGIS utiliza ahora un modelo restrictivo. El proyecto excluye el código asistido por IA antes de que los mantenedores evalúen si la divulgación, las pruebas y la revisión humana hacen aceptable un parche concreto.
QEMU ha adoptado un límite similar. Su política de procedencia del código rechaza contribuciones que se considere que incluyen o derivan de contenido generado por herramientas como ChatGPT, Claude, Copilot y Llama.
QEMU fundamenta su norma en parte en la procedencia. Los contribuidores certifican su derecho a enviar parches mediante el Developer Certificate of Origin, comúnmente llamado DCO. El DCO es una certificación legal humana relativa al origen de una contribución y a los derechos para enviarla.
QEMU sostiene que los generadores actuales hacen difícil establecer el estado de los derechos de autor y las licencias. El material de entrenamiento puede incluir código con términos incompatibles, mientras que el tratamiento legal de la salida generada sigue sin resolverse.
Su política es más limitada en un aspecto importante. QEMU permite el uso de IA para actividades como investigar interfaces de aplicaciones, análisis estático o depuración cuando la salida generada no entra en la contribución.
QGIS no ofrece una lista equivalente de actividades de apoyo aceptadas. Su política concisa favorece una prohibición clara frente a excepciones detalladas.
El kernel de Linux ha elegido otro camino. Sus directrices para asistentes permiten la participación de IA, al tiempo que atribuyen las obligaciones de certificación y revisión a un remitente humano.
Un agente de IA no puede añadir una etiqueta Signed-off-by bajo ese proceso. Un humano debe revisar el código generado, confirmar el cumplimiento de las licencias, añadir la certificación y asumir la responsabilidad de la contribución.
El kernel también exige una etiqueta Assisted-by. Su flujo de trabajo requiere errores reproducibles, correcciones probadas, divulgación clara de verificaciones ausentes y un envío controlado por humanos.
Ese modelo intenta preservar la automatización útil sin tratar a un agente como participante legal o social. La máquina puede ayudar a producir trabajo, pero una persona debe asumir el resultado.
QGIS consideró una versión de ese principio antes de alejarse de él. Su experiencia sugiere que la responsabilidad humana se debilita cuando la persona responsable no puede explicar ni mantener de forma independiente el parche generado.
Ambas estrategias reconocen el mismo problema subyacente. La salida de un modelo no se valida por sí sola, y un repositorio no puede asignar responsabilidad a un servicio de software.
Su desacuerdo se refiere a dónde debe absorber el proyecto la incertidumbre. Linux permite que el parche entre en el proceso normal y exige una responsabilidad humana más fuerte. QGIS bloquea la categoría de parche antes de que pueda reclamar la atención de los revisores.
El enfoque restrictivo ofrece a los mantenedores una base sencilla para el rechazo. No necesitan debatir qué proporción de un parche provino de un modelo o si las ediciones humanas lo transformaron lo suficiente.
Sin embargo, la aplicación de la norma sigue dependiendo en gran medida de la honestidad de los contribuidores. El código generado no lleva una marca fiable, y los detectores automatizados de IA no pueden establecer la autoría con la confianza necesaria para imponer sanciones.
El enfoque de responsabilidad evita una prueba de pureza imposible de verificar. Evalúa las pruebas, la procedencia, la explicación y la responsabilidad, en lugar de intentar reconstruir cada herramienta utilizada durante el desarrollo.
Sin embargo, ese proceso aún puede fallar ante un gran volumen. Una divulgación bien redactada no acorta una revisión compleja, y una firma humana no crea experiencia inexistente.
Por tanto, ambos modelos optimizan riesgos distintos. Linux protege el acceso al desarrollo asistido por IA al tiempo que preserva la responsabilidad humana. QGIS protege una capacidad de revisión escasa al excluir un método de producción amplio.
Ninguna de las dos políticas resuelve la cuestión del código abierto en general. Cada proyecto debe ajustar sus límites a su gobernanza, disponibilidad de mantenedores, tolerancia legal y cultura de contribución.
Una prohibición clara sigue creando un perímetro ambiguo
La regla de QGIS es sencilla en su núcleo, pero incierta en los márgenes, donde las herramientas modernas de desarrollo mezclan asistencia y autoría.
Pocos colaboradores malinterpretarán una prohibición de pedir a un agente de programación que implemente una función y enviar el resultado. Los casos difíciles comienzan cuando la IA cambia la forma en que una persona llega a código escrito de manera independiente.
Durante el debate sobre la propuesta, los colaboradores plantearon ejemplos relacionados con autocompletado, revisión de código, traducción, investigación y depuración. Los entornos de desarrollo modernos pueden utilizar aprendizaje automático incluso cuando los usuarios nunca abren un chatbot.
Un editor podría clasificar opciones de completado con un modelo. Un motor de búsqueda podría mostrar una respuesta generada por IA antes que los resultados habituales. Un servicio de traducción podría ayudar a un colaborador a escribir un identificador o comentario en inglés.
Un desarrollador podría pedir a un LLM que explique un subsistema desconocido, cerrar el chat y escribir un parche manualmente. Otro podría usar un modelo como revisor privado, aceptar una advertencia y descartar varias sugerencias incorrectas.
Esos casos no encajan limpiamente en la distinción entre código generado y código de autoría humana. Implican que información y juicio pasan entre una persona y un sistema en distintas etapas.
Un participante propuso limitar la prohibición al código “escrito por” LLMs o agentes de IA. Esa redacción dejaría espacio para la lluvia de ideas, la búsqueda o el análisis sin admitir implementaciones generadas.
Los líderes del proyecto se negaron a acotar la regla antes de su aprobación. Dawson presentó la prohibición como una puerta cerrada que futuras propuestas podrán reabrir selectivamente tras debatir adecuadamente usos concretos.
Otro colaborador calificó la política de medida provisional. Un líder del proyecto también afirmó que la restricción no era necesariamente permanente ni universal.
Esa secuencia revela una concesión deliberada. QGIS aceptó la ambigüedad en los casos marginales para eliminarla respecto a su criterio predeterminado actual.
El enfoque ofrece un alivio inmediato, pero plantea cuestiones de debido proceso. La política permite sanciones sobre los derechos de los colaboradores cuando se descubre posteriormente asistencia prohibida. Sin embargo, no define un procedimiento de investigación, un estándar probatorio ni una vía de apelación.
Tampoco especifica cuánta influencia de la IA hace que el código sea “asistido”. Una función copiada es un caso sencillo. Una explicación arquitectónica que cambia el pensamiento de un desarrollador es más difícil.
Los líderes del proyecto reconocieron que no pueden inspeccionar los ordenadores de los colaboradores. Uno sugirió una prueba de buena fe centrada en si fue la propia mente del colaborador la que escribió el código.
Ese estándar refleja más la confianza comunitaria que la detección técnica. Pide a los colaboradores que respeten la política incluso cuando ocultarlo sería fácil.
La aplicación basada en la confianza es común en el código abierto. Los mantenedores ya dependen de que los colaboradores informen sobre procedencia, límites de las pruebas, conflictos y código de terceros.
Lo que está en juego aumenta cuando una política incluye sanciones. Una acusación errónea puede desalentar a un colaborador legítimo, especialmente cuando el estilo de programación parece genérico o inusualmente pulido.
Una restricción general también puede excluir apoyos útiles para la accesibilidad. La traducción, la explicación de código y la asistencia personalizada pueden ayudar a colaboradores que trabajan entre idiomas o con barreras cognitivas.
Esos costes no invalidan la política. Muestran por qué la restricción debe entenderse como una moratoria, no como una teoría acabada del desarrollo asistido por IA.
La versión más sólida del argumento de QGIS es operativa. Su primera política no redujo suficientemente la carga, por lo que el proyecto eligió una regla que los mantenedores pueden aplicar rápidamente.
La versión más débil sostendría que todo código influido por IA es inherentemente defectuoso. El propio debate del proyecto no establece esa conclusión.
Algunos participantes describieron revisiones privadas y exploración de código realmente útiles. Incluso quienes apoyaban la prohibición reconocieron que podría descartar usos beneficiosos junto con los perjudiciales.
QGIS está optando por una gobernanza predecible en lugar de una optimización caso por caso. Eso es defendible bajo presión, pero su legitimidad dependerá de una aplicación coherente y proporcionada.
La prohibición protege una cantera de colaboradores humanos
En última instancia, la política busca preservar una comunidad que forme mantenedores, no limitarse a filtrar código que supere las pruebas.
QGIS presta servicio a organizaciones que utilizan software geoespacial para trabajos que van mucho más allá del repositorio. Sus usuarios crean mapas, analizan datos espaciales, publican servicios y conectan numerosos formatos y bases de datos.
Las organizaciones también pueden contratar a personas de la comunidad de QGIS para desarrollo, formación y soporte. Esa relación da a los usuarios acceso a experiencia especializada, al tiempo que ayuda a los colaboradores experimentados a mantener una participación sostenida a largo plazo.
El desarrollo de código abierto asistido por IA puede alterar ese ciclo cuando separa la producción de código de la experiencia. Un parche generado podría resolver un problema inmediato sin formar a una persona que luego comprenda el subsistema.
La pérdida se hace visible durante regresiones posteriores. Los mantenedores necesitan a alguien que recuerde las restricciones originales, pueda investigar nuevos síntomas y juzgar si una revisión preserva el comportamiento previsto.
Una sesión con un modelo no tiene una obligación social continuada. La persona que envía su resultado también podría desaparecer una vez aceptado el parche inmediato.
El código abierto siempre ha recibido contribuciones ocasionales y puntuales. La preocupación es la escala. Los agentes de programación pueden convertir un patrón ocasional en un flujo continuo de cambios sustanciales.
Ese flujo presiona tanto la revisión técnica como el juicio comunitario. Los mantenedores deben decidir si un recién llegado busca aprender o simplemente quiere que el proyecto valide trabajo generado.
La distinción afecta a cuánto sentido tiene enseñar. La revisión es en parte control de calidad, pero también es la forma en que los proyectos desarrollan futuros colaboradores.
El tiempo dedicado a ayudar a un colaborador comprometido a comprender un subsistema puede convertirse en una inversión. El tiempo empleado en reparar envíos de alguien incapaz de comentarlos rara vez produce ese retorno.
Por eso la decisión de QGIS no puede reducirse al miedo a la automatización. El proyecto está defendiendo un intercambio concreto: los colaboradores aportan esfuerzo y comprensión creciente, mientras los mantenedores ofrecen revisión y orientación.
La programación con IA cambia el equilibrio aparente. Permite a los colaboradores presentar trabajo con un aspecto más acabado antes de adquirir el conocimiento normalmente asociado a ese trabajo.
El parche puede compilar y abordar un síntoma visible. Aun así, puede depender de supuestos inventados, pruebas incompletas o comportamientos accidentales que solo detecta un revisor experimentado.
En el software geoespacial, los supuestos ocultos pueden resultar especialmente costosos. Los sistemas de referencia de coordenadas, la validez geométrica, el comportamiento de los proveedores y la semántica de las bases de datos pueden convertir un pequeño cambio en un problema amplio de compatibilidad.
Las pruebas automatizadas ayudan, pero codifican expectativas conocidas. No garantizan que una corrección generada respete cada flujo de trabajo, plataforma, fuente de datos o restricción de rendimiento.
La prohibición obliga a los colaboradores a superar esa brecha de conocimiento antes de enviar una contribución. Aún pueden estudiar el código, consultar documentación, debatir diseños y preparar cambios de autoría humana.
Ese requisito eleva la barrera de entrada. Puede frustrar a desarrolladores competentes que utilizan la IA con cuidado y entienden cada línea enviada.
QGIS acepta esa exclusión porque los mantenedores ya han vivido la alternativa. El proyecto prioriza la sostenibilidad de los revisores frente a maximizar el número de parches candidatos.
Esta postura también envía una señal a las organizaciones que adoptan agentes de programación internamente. Los repositorios públicos no son servicios ilimitados de validación posterior para trabajo generado de forma privada.
Una empresa puede generar un cambio para QGIS destinado a su propia implantación y probarlo en su propio entorno. Enviarlo al proyecto compartido transfiere nuevas obligaciones a voluntarios y mantenedores financiados por la comunidad.
Las organizaciones que busquen aceptación aguas arriba tendrán que aportar experiencia humana responsable. Eso podría significar una revisión interna más profunda, financiar a un colaborador consolidado o formar empleados que comprendan la arquitectura de QGIS.
El resultado es una frontera más nítida entre usar software de código abierto y participar en su producción. La IA reduce el coste de intentar lo segundo, pero QGIS insiste en que no reduce el nivel de comprensión requerido.
Tres señales mostrarán si la política funciona
La próxima prueba no consiste en si desaparecen las solicitudes de extracción asistidas por IA, sino en si QGIS gana capacidad de revisión sin debilitar la participación legítima.
La primera señal es la acumulación de solicitudes de extracción del proyecto durante los próximos meses. Los mantenedores adoptaron la prohibición en parte porque los envíos generados podían llegar más rápido de lo que los humanos podían revisarlos.
Una cola más pequeña, decisiones más rápidas o menos parches extensos respaldarían el argumento operativo de la política. Una sobrecarga continuada mostraría que las contribuciones asistidas por IA eran solo una fuente de presión sobre la revisión.
Esta medida necesita contexto. El volumen de desarrollo de QGIS puede cambiar con los calendarios de lanzamiento, la disponibilidad de colaboradores y el trabajo en funciones importantes.
Por tanto, los mantenedores deberían comparar períodos similares y distinguir entre envíos rechazados y trabajo aceptado. Los recuentos brutos de solicitudes de extracción por sí solos no mostrarán si mejoró la calidad de la revisión.
La segunda señal es una QEP posterior que defina los usos permitidos. Los líderes del proyecto describieron repetidamente la restricción como un punto de partida que futuras propuestas podrían relajar selectivamente.
Una excepción limitada para revisión privada, traducción, investigación o autocompletado demostraría que QGIS puede separar patrones de envío perjudiciales de asistencia de menor riesgo. También aclararía qué significa “asistido” en la práctica.
La ausencia de una propuesta posterior indicaría que el límite temporal se está convirtiendo en una norma duradera. Ese resultado aún podría reducir la carga de trabajo, pero dejaría los casos límite gobernados principalmente por juicios informales.
La tercera señal es la retención de colaboradores. QGIS debería observar si los mantenedores experimentados siguen activos y si nuevos colaboradores humanos avanzan hacia responsabilidades más profundas.
La política parecerá exitosa si protege a los revisores establecidos y preserva una vía para que los recién llegados aprendan. Parecerá más débil si participan menos personas sin una mejora correspondiente en la capacidad de los mantenedores.
Los casos de aplicación aportarán otro detalle importante dentro de esa señal. Una respuesta transparente a una infracción admitida difiere de sanciones basadas en sospechas sobre el estilo de programación.
La coherencia determinará si los colaboradores ven la regla como un límite comunitario claro o como una prueba de autoría impredecible. Las explicaciones públicas pueden ayudar a definir precedentes sin exponer información privada.
La comparación con Linux y QEMU también seguirá siendo útil. Linux está probando si la divulgación, la reproducibilidad y la certificación humana pueden contener los costes relacionados con la IA. QEMU está probando una prohibición de alcance más preciso basada en la procedencia.
Si los proyectos permisivos mantienen la calidad sin agotar a los revisores, aumentará la presión para que QGIS reabra su puerta. Si sufren oleadas recurrentes de parches imposibles de verificar, la restricción temprana de QGIS parecerá más convincente.
Los desarrolladores no deberían interpretar la política como un veredicto universal sobre la programación con IA. Deberían entenderla como una respuesta específica del repositorio a un experimento de gobernanza fallido.
Antes de contribuir, los desarrolladores ahora deben determinar si su flujo de trabajo puede cumplir la norma de buena fe. Si no puede, la divulgación no salvará la contribución.
Las organizaciones que desarrollan sobre QGIS también deberían examinar quién puede respaldar cualquier cambio propuesto para incorporar aguas arriba. Una implementación generada sin una responsabilidad humana duradera conlleva ahora un riesgo directo de rechazo.
QGIS prohíbe las contribuciones asistidas por IA porque el proyecto concluyó que el acceso a la generación de código superaba con creces el acceso a una revisión responsable. Los próximos meses mostrarán si cerrar esa brecha protege a la comunidad o simplemente traslada la ambigüedad a otro lugar.
Siga de cerca el trabajo pendiente, la próxima propuesta de política y el flujo de colaboradores. En conjunto, esas señales revelarán si QGIS encontró un límite sostenible o si solo ganó tiempo para un debate más difícil.
