Por qué ownCloud está lanzando una Oficina de Programas de Código Abierto y eliminando el CLA

Hoy, desde Ratisbona, Kiteworks lanza formalmente una Oficina de Programas de Código Abierto (OSPO) con una Carta de Gobernanza v0.1 publicada, retira el Acuerdo de Licencia de Colaborador, introduce un modelo de contribución mediante Certificado de Origen del Desarrollador, una Política formal de Contribuciones Asistidas por IA y mucho más. La OSPO funciona como órgano de gobernanza junto a una línea de producción activa que actualmente incluye: ownCloud Infinite Scale con lanzamientos trimestrales, ownCloud Classic con una próxima actualización a PHP 8.3, iOS y Android en desarrollo, el MCP Server en versión beta y más novedades. Esta publicación repasa lo que se entrega hoy, lo que está en marcha y qué pueden esperar próximamente los colaboradores, clientes y partners.

Aspectos clave

• La OSPO es un compromiso estructural, no una acción de marketing. La Carta de Gobernanza define roles, toma de decisiones y compromisos de transparencia, con una hoja de ruta hacia la v1.0 tras la aportación del Community Advisory Board.
• El antiguo CLA será retirado. Los colaboradores utilizarán el firmado DCO (git commit -s) y conservarán la propiedad de su trabajo. Ya no habrá cesión de derechos de autor a ownCloud GmbH.
• Las contribuciones asistidas por IA son bienvenidas. La política establece cuatro requisitos: divulgación, comprensión, pruebas y cumplimiento de licencias, y aplica el mismo estándar de revisión que cualquier otro PR. Entendemos la inclusión más allá de las capacidades de desarrollo.
• El programa de seguridad está operativo. El VDP en security.owncloud.com, el programa de recompensas YesWeHack con premios escalonados de hasta 5.000 dólares para hallazgos críticos.
• Dos plataformas, un solo compromiso. ownCloud Classic funciona con PHP 8.3 y se mantiene activamente; oCIS es la arquitectura moderna, sin base de datos y nativa en Go. Un migrador soportado de ownCloud Classic a Infinite Scale estará disponible muy pronto en https://github.com/owncloud/migrate_to_ocis y en el Marketplace de ownCloud 10.
• La creación de un Community Advisory Board, la hoja de ruta pública del producto y el informe anual de la OSPO son hitos con ventanas objetivo comprometidas, no logros ya alcanzados.

ownCloud ha pasado por dos forks — Nextcloud en 2016 y OpenCloud en 2025. Hemos reflexionado sobre ambos. En resumen, los proyectos open source gestionados comercialmente necesitan una gobernanza inclusiva y comunicación pública coherente por escrito, no solo en la intención. La OSPO es la respuesta operativa a ello.

La OSPO depende de Kiteworks y está financiada por Kiteworks. No somos un proyecto gobernado por una fundación ni pretendemos serlo. Nuestro compromiso es que la dirección se tome en público, que cada motivo quede documentado, que la comunidad tenga canales reales para influir en la dirección y que cada artefacto de gobernanza esté abierto a comentarios y revisiones. La palabra que elegimos para esta relación es stewardship: Kiteworks como el responsable corporativo de la inversión sostenida en ingeniería, seguridad y gobernanza, con límites claros y escritos entre los proyectos open source y las capas empresariales comerciales para la gobernanza, control y cumplimiento de datos humanos e IA.

El lanzamiento incluye un conjunto de manifiestos multidocumento: Visión y Misión, el Manifiesto, un Prólogo del CSO de Kiteworks Tim Freestone, una Visión de Producto para oCIS, la Carta de Gobernanza, un Código de Conducta, una Guía de Contribución, la Política de Contribuciones Asistidas por IA, la Política de Divulgación de Seguridad y documentos de Empoderamiento y Participación. Todos están disponibles hoy y todos están sujetos al periodo de comentarios públicos de 30 días que exige la carta para cualquier cambio futuro.

Retiro del CLA: Qué cambia realmente el DCO para los colaboradores

El antiguo Acuerdo de Licencia de Colaborador exigía a los colaboradores ceder los derechos de autor a ownCloud GmbH. Funcionaba en un sentido legal estricto, pero generaba fricción tanto para los equipos de compras empresariales como para los colaboradores independientes, y no era coherente con el modelo de gobernanza que queremos mantener.

Las contribuciones ahora utilizan el Certificado de Origen del Desarrollador: una declaración por commit de que tienes derecho a enviar el trabajo bajo la licencia del repositorio. Se ve así:

git commit -s -m "Add this awesome implementation to ownCloud Infinite Scale"

La bandera -s añade una línea Signed-off-by: con tu nombre y correo electrónico. Eso es todo. Conservas los derechos de autor. Atestiguas la procedencia. Los revisores pueden verificar el firmado en CI. Es el mismo modelo que el kernel de Linux ha usado durante dos décadas. Las contribuciones previas bajo el antiguo CLA permanecen bajo sus términos originales; todo lo nuevo será DCO.

Los nuevos repositorios tendrán por defecto la Licencia Apache 2.0. Los repositorios existentes se relicenciarán próximamente a Apache 2.0. Dicho esto, llevará tiempo, ya que requiere revisar individualmente todos los commits previos y los CLA firmados, licencias, licencias de terceros usadas y orígenes.

La carta de gobernanza define cuatro roles: Colaborador, Revisor (puede aprobar PRs), Mantenedor (autoridad de merge y decisiones arquitectónicas dentro del alcance) y OSPO (política de gobernanza, resolución de disputas en un plazo de 10 días laborables). Si no estás de acuerdo con la decisión de un mantenedor, puedes escalar; la OSPO revisará, consultará y emitirá una decisión vinculante dentro del plazo. Una gobernanza que tarda 90 días en resolver un conflicto de contribución no es gobernanza: es desgaste.

Política de Contribuciones Asistidas por IA: Bienvenida a la herramienta, subiendo el estándar

También publicamos algo que la mayoría de los proyectos open source gestionados comercialmente han evitado hasta ahora: una postura formal a favor de las contribuciones asistidas por IA. La nuestra es directa. Las contribuciones asistidas por IA son bienvenidas y se someten al mismo estándar de calidad que cualquier otra contribución. El proceso de revisión no se fija en cómo se escribió el código. Importa que el código funcione, esté probado, documentado y sea mantenible.

La política establece cuatro requisitos para cualquier pull request aumentado por IA:

1. Divulgación. Indica en la descripción del PR que se usaron herramientas de IA y nombra la herramienta: Claude Code, GitHub Copilot, Cursor u otra. No es un estigma; es transparencia y nos ayuda a mejorar nuestros procesos de revisión.
2. Comprensión. Debes entender qué hace el código. Si un revisor pregunta por qué una función gestiona un error de cierta manera y la respuesta es «lo escribió la IA», el PR no está listo.
3. Pruebas. El código generado por IA necesita pruebas: unitarias para la lógica, exploratorias para la UI. El CI detectará lo que se te escape, pero no sustituye pensar en lo que realmente debe hacer el código.
4. Cumplimiento de licencias. Eres responsable de la procedencia de cada línea de tu PR. Verifica que tu herramienta de IA no haya introducido código copiado de una licencia incompatible.

oCIS ya ha sido fusionado mediante este flujo de trabajo, y la metodología completa para desarrolladores está publicada en owncloud.dev. Nuestros equipos internos de ingeniería también usan estas herramientas y se exigen los mismos estándares: divulgación cuando corresponde, comprensión total del código generado y responsabilidad humana en cada merge.

El trasfondo importa. Existe un riesgo real de que el desarrollo asistido por IA se convierta en una excusa para rechazar contribuciones de quienes tienen menos experiencia. Nosotros elegimos lo contrario. Si tienes una visión para mejorar ownCloud y la IA te ayuda a convertir esa visión en código funcional, queremos tu contribución. Lo que no aceptamos son colaboradores que desaparecen durante la revisión. La responsabilidad humana es la esencia de toda la política. Pero la capacidad de programar a nivel senior no debe convertirse en una herramienta de exclusión. El open source fue, y sigue siendo, sobre inclusión.

Dos plataformas, un solo compromiso: Construyendo el futuro con oCIS, manteniendo la confianza con Classic

El lanzamiento de la OSPO también es el momento adecuado para precisar el portafolio. ownCloud Infinite Scale (oCIS) es la plataforma actual: escrita en Go, Apache 2.0, con una arquitectura sin base de datos y nativa en Go que almacena metadatos en archivos message pack en el propio nodo mediante la abstracción DecomposedFS. No hay una base de datos SQL central que almacene el estado de la plataforma, lo que elimina una clase de problemas operativos relacionados con bases de datos: sin migración de esquemas al actualizar, sin cuellos de botella SQL bajo carga, sin ruta de escalada de privilegios a nivel de base de datos y metadatos que viajan con el archivo bajo operaciones estándar de sistema de archivos.

El mismo binario compilado escala desde un solo proceso en un servidor pequeño hasta microservicios distribuidos en Kubernetes. Los backends de almacenamiento en producción incluyen POSIX/NFS y almacenamiento de objetos compatible con S3 (AWS, MinIO, Ceph). CERN EOS está disponible como backend Tech Preview, no para producción. La autenticación es exclusivamente OIDC. La política es programable vía OPA/Rego a través del File Firewall. La federación utiliza Open Cloud Mesh. La integración con Office se realiza mediante WOPI reforzado con Collabora y ONLYOFFICE. Los registros de auditoría se entregan como JSON estructurado diseñado para ingestión en SIEM. Todas las interfaces expuestas por la plataforma — WebDAV, OIDC, OCM, CS3APIs, LibreGraph, OPA/Rego — son estándares abiertos o especificaciones publicadas. La plataforma está en producción a escala de computación científica, incluyendo CERN con más de mil millones de archivos y escala multipetabyte, y en implementaciones del sector público como la nube escolar de Baviera (ByCS).

ownCloud Classic — la plataforma Linux, Apache, SQL y PHP — se actualiza a PHP 8.3 y se mantiene activamente, recibiendo actualizaciones de seguridad y mantenimiento. Un migrador soportado de Classic a oCIS está a punto de ver la luz. Los clientes (Community y Enterprise) migrarán a su propio ritmo cuando el migrador esté disponible de forma general.

Cómo participar

Los mecanismos que aún no existen son los que te necesitan cuando estén listos. Algunos próximos pasos concretos:

• Sigue los repositorios de GitHub en github.com/owncloud: oCIS, Classic, los clientes, las extensiones web. Los issues etiquetados como good-first-issue y help-wanted son solicitudes genuinas.
• Lee las políticas publicadas. La Carta de Gobernanza, la Política de Contribuciones Asistidas por IA, la Política de Divulgación de Seguridad y la Guía de Contribución.
• Envía un reporte de vulnerabilidad al VDP o al programa de recompensas YesWeHack si encuentras algo.
• Aplica para la formación del Community Advisory Board para el Q4 de 2026 — de cinco a nueve miembros externos con periodos renovables de 12 meses; las nominaciones se abrirán públicamente.
• Contacta con la OSPO en ospo@kiteworks.com. Para temas de Código de Conducta, usa coc@owncloud.com. Las organizaciones que evalúan una suscripción empresarial pueden usar la página de contacto — pero eso es solo una nota al pie, no la petición principal.