Pourquoi ownCloud lance un Open Source Program Office — et met fin au CLA

Aujourd’hui, depuis Ratisbonne, Kiteworks lance officiellement un Open Source Program Office (OSPO) avec la publication de la Charte de gouvernance v0.1, la suppression de l’Accord de licence du contributeur (CLA), l’introduction d’un modèle de contribution basé sur le Developer Certificate of Origin, une politique formelle sur les contributions assistées par IA, et bien d’autres nouveautés. L’OSPO agit comme organe de gouvernance aux côtés d’une ligne de production active comprenant actuellement : ownCloud Infinite Scale avec des versions trimestrielles, ownCloud Classic qui bénéficiera prochainement d’une mise à niveau vers PHP 8.3, des versions iOS et Android en préparation, le serveur MCP en version bêta, et bien plus encore. Cet article détaille ce qui est livré aujourd’hui, ce qui est en cours, et ce que les contributeurs, clients et partenaires peuvent attendre pour la suite.

Points clés à retenir

• L’OSPO est un engagement structurel, pas une opération marketing. La Charte de gouvernance définit les rôles, la prise de décision et les engagements de transparence, avec une feuille de route vers la version 1.0 après consultation du Community Advisory Board.
• Le CLA historique va être supprimé. Les contributeurs utiliseront le DCO (git commit -s) et conserveront la propriété de leur travail. Plus aucune cession de droits d’auteur à ownCloud GmbH.
• Les contributions assistées par IA sont les bienvenues. La politique impose quatre exigences : transparence, compréhension, tests et conformité des licences, et applique le même niveau d’exigence qu’à toute autre Pull Request. Nous comprenons l’inclusion au-delà des seules compétences techniques.
• Le programme de sécurité est opérationnel. Le VDP sur security.owncloud.com, le bug bounty YesWeHack avec des récompenses par paliers allant jusqu’à 5 000 $ pour les failles critiques.
• Deux plateformes, un seul engagement. ownCloud Classic fonctionne sous PHP 8.3 et bénéficie d’une maintenance active ; oCIS repose sur une architecture moderne, sans base de données, native Go. Un outil de migration de ownCloud Classic vers Infinite Scale sera très bientôt disponible sur https://github.com/owncloud/migrate_to_ocis et dans la Marketplace ownCloud 10.
• La création d’un Community Advisory Board, la publication de la roadmap produit et du rapport annuel de l’OSPO sont des étapes planifiées avec des échéances précises, et non des succès déjà revendiqués.

ownCloud a connu deux forks — Nextcloud en 2016 et OpenCloud en 2025. Nous avons tiré des enseignements de ces deux expériences. En résumé, les projets open source à gouvernance commerciale ont besoin d’une gouvernance inclusive et d’une communication publique écrite, et pas seulement d’intentions. L’OSPO répond concrètement à ce besoin.

L’OSPO est rattaché à Kiteworks et financé par Kiteworks. Nous ne sommes pas un projet géré par une fondation et nous ne prétendons pas l’être. Notre engagement : piloter en toute transparence, documenter chaque décision, offrir à la communauté des canaux d’influence concrets, et ouvrir chaque document de gouvernance aux commentaires et révisions. Le terme que nous avons choisi pour cette relation est stewardship : Kiteworks agit comme le garant corporate des investissements en ingénierie, sécurité et gouvernance, avec des frontières écrites claires entre les projets open source et les couches commerciales pour la gouvernance, le contrôle et la conformité des données humaines et IA.

Le lancement s’accompagne d’un ensemble de documents fondateurs : Vision & Mission, Manifesto, préface du CSO de Kiteworks Tim Freestone, vision produit pour oCIS, Charte de gouvernance, Code de conduite, Guide du contributeur, Politique de contribution assistée par IA, Politique de divulgation de sécurité, et documents Empowerment et Engagement. Tous sont disponibles dès aujourd’hui et soumis à la période de commentaires publics de 30 jours exigée par la charte pour toute modification future.

Suppression du CLA : ce que le DCO change concrètement pour les contributeurs

L’ancien Accord de licence du contributeur imposait aux contributeurs de céder leurs droits d’auteur à ownCloud GmbH. Cela fonctionnait d’un point de vue strictement juridique, mais posait problème tant pour les équipes achats des entreprises que pour les contributeurs indépendants, et n’était pas cohérent avec la gouvernance que nous souhaitons instaurer.

Désormais, les contributions utilisent le Developer Certificate of Origin — une attestation par commit que vous avez le droit de soumettre ce travail sous la licence du dépôt. Cela ressemble à ceci :

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

Le flag -s ajoute une ligne Signed-off-by: avec votre nom et votre adresse e-mail. C’est tout. Vous conservez vos droits d’auteur. Vous attestez de la provenance. Les reviewers peuvent vérifier la signature dans l’intégration continue. C’est le même modèle que le noyau Linux utilise depuis vingt ans. Les contributions antérieures faites sous l’ancien CLA restent régies par leurs conditions d’origine ; tout ce qui suit passe sous DCO.

Les nouveaux dépôts utilisent par défaut la licence Apache 2.0. Les dépôts existants seront progressivement migrés vers Apache 2.0. Cela prendra du temps, car il faut examiner chaque commit antérieur, chaque CLA signé, les licences tierces utilisées et les origines.

La charte de gouvernance définit quatre rôles : Contributor, Reviewer (peut approuver les PR), Maintainer (autorité de fusion et décisions architecturales dans le périmètre), et OSPO (politique de gouvernance, résolution des litiges sous 10 jours ouvrés). En cas de désaccord avec un maintainer, vous pouvez faire appel ; l’OSPO examinera, consultera et rendra une décision contraignante dans les délais. Une gouvernance qui met 90 jours à trancher un conflit de contribution n’est pas une gouvernance : c’est de l’attrition.

Politique de contribution assistée par IA : accueillir l’outil, élever le niveau

Nous publions également ce que la plupart des projets open source à gouvernance commerciale ont jusqu’ici évité : une position officielle en faveur des contributions assistées par IA. La nôtre est simple. Les contributions assistées par IA sont les bienvenues, et nous leur appliquons le même niveau d’exigence qu’à toute autre contribution. Le processus de revue ne s’intéresse pas à la façon dont le code a été écrit, mais à son bon fonctionnement, sa documentation, ses tests et sa maintenabilité.

La politique impose quatre exigences pour toute Pull Request enrichie par l’IA :

1. Transparence. Indiquez dans la description de la PR que des outils IA ont été utilisés, et précisez lesquels : Claude Code, GitHub Copilot, Cursor, ou autre. Ce n’est pas une stigmatisation, c’est de la transparence, et cela nous aide à améliorer nos processus de revue.
2. Compréhension. Vous devez comprendre ce que fait le code. Si un reviewer demande pourquoi une fonction gère une erreur d’une certaine façon et que la réponse est « c’est l’IA qui l’a écrit », la PR n’est pas prête.
3. Tests. Le code généré par IA doit être testé — tests unitaires pour la logique, tests exploratoires pour l’interface. L’intégration continue détectera ce que vous oubliez, mais elle ne remplace pas la réflexion sur le comportement attendu du code.
4. Conformité des licences. Vous êtes responsable de la provenance de chaque ligne de votre PR. Vérifiez que votre outil IA n’a pas introduit de code issu d’une licence incompatible.

oCIS a déjà été enrichi via ce workflow, et la méthodologie complète de développement est publiée sur owncloud.dev. Nos équipes d’ingénierie internes utilisent également ces outils et s’imposent les mêmes règles : transparence quand c’est pertinent, compréhension totale du code généré, et responsabilité humaine pour chaque fusion.

Le sous-texte est important. Il existe un vrai risque que le développement assisté par IA serve d’argument pour écarter discrètement les contributions IA, et donc les contributeurs moins expérimentés. Nous faisons le choix inverse. Si vous avez une vision pour améliorer ownCloud et que l’IA vous aide à la concrétiser, nous voulons votre contribution. Ce que nous ne pouvons pas accepter, ce sont les contributeurs qui disparaissent pendant la revue. La responsabilité humaine est au cœur de la politique. Mais l’exigence d’un niveau senior en code ne doit pas devenir un outil d’exclusion. L’open source a toujours été, et reste, un espace d’inclusion.

Deux plateformes, un seul engagement : construire l’avenir avec oCIS, préserver la confiance avec Classic

Le lancement de l’OSPO est aussi l’occasion de clarifier le portefeuille. ownCloud Infinite Scale (oCIS) est la plateforme actuelle : écrite en Go, sous licence Apache 2.0, avec une architecture native Go sans base de données qui stocke les métadonnées dans des fichiers message pack sur le nœud lui-même via l’abstraction DecomposedFS. Il n’y a pas de base SQL centrale pour l’état de la plateforme, ce qui élimine toute une catégorie de problèmes opérationnels liés aux bases de données : pas de migration de schéma lors des mises à jour, pas de goulet d’étranglement SQL sous charge, pas de risque d’élévation de privilèges au niveau base de données, et des métadonnées qui suivent le fichier lors des opérations classiques sur le système de fichiers.

Le même binaire compilé s’adapte d’un simple processus sur un petit serveur à des microservices distribués sur Kubernetes. Les stockages de production incluent POSIX/NFS et le stockage objet compatible S3 (AWS, MinIO, Ceph). CERN EOS est disponible en Tech Preview, mais pas encore pour la production. L’authentification est exclusivement OIDC. La politique est programmable via OPA/Rego grâce au File Firewall. La fédération utilise Open Cloud Mesh. L’intégration bureautique passe par un WOPI durci avec Collabora et ONLYOFFICE. Les journaux d’audit sont fournis au format JSON structuré, prêt pour ingestion SIEM. Toutes les interfaces exposées par la plateforme — WebDAV, OIDC, OCM, CS3APIs, LibreGraph, OPA/Rego — sont des standards ouverts ou des spécifications publiées. La plateforme est déjà utilisée en production à l’échelle du calcul scientifique, notamment au CERN avec plus d’un milliard de fichiers et plusieurs pétaoctets, ainsi que dans le secteur public, comme le cloud scolaire bavarois (ByCS).

ownCloud Classic — la plateforme Linux, Apache, SQL et PHP — passe à PHP 8.3 et bénéficie d’une maintenance active, avec des mises à jour de sécurité et de maintenance régulières. Un outil de migration Classic-vers-oCIS sera bientôt disponible. Les clients (communauté et entreprise) migreront à leur rythme lorsque l’outil sera accessible à tous.

Comment participer

Les mécanismes qui n’existent pas encore sont justement ceux qui ont besoin de vous dès qu’ils seront en place. Quelques prochaines étapes concrètes :

• Surveillez les dépôts GitHub sur github.com/owncloud : oCIS, Classic, les clients, les extensions web. Les issues marquées good-first-issue et help-wanted sont de vraies demandes.
• Lisez les politiques publiées. La Charte de gouvernance, la politique de contribution assistée par IA, la politique de divulgation de sécurité et le guide du contributeur.
• Signalez une vulnérabilité via le VDP ou le bug bounty YesWeHack si vous en découvrez une.
• Candidatez pour la formation du Community Advisory Board prévue pour le 4e trimestre 2026 — cinq à neuf membres externes pour des mandats renouvelables de 12 mois ; les nominations seront ouvertes publiquement.
• Contactez l’OSPO à ospo@kiteworks.com. Pour les questions liées au Code de conduite, utilisez coc@owncloud.com. Les organisations qui souhaitent évaluer un abonnement entreprise peuvent passer par la page contactez-nous — mais ce n’est qu’une note de bas de page, pas la demande principale.