Charte de gouvernance ownCloud : principes et rôles

Charte de gouvernance communautaire ownCloud

ownCloud — une société Kiteworks

Statut : Objectif à atteindre (v0.1) — Cette charte présente notre modèle de gouvernance envisagé. Nous la mettons en œuvre par étapes. Les éléments assortis d’une date cible reflètent notre plan actuel, sans engagement ferme.

Principes

Transparence. Les décisions qui concernent la communauté sont prises publiquement. Les priorités de la feuille de route, les choix d’architecture et les évolutions des règles sont discutés sur des canaux ouverts. Lorsque certaines décisions doivent être prises en interne (par exemple, pour des raisons de sécurité ou commerciales), nous expliquons le résultat et les raisons dès que possible.
Gestion responsable, pas propriété. Kiteworks agit comme gestionnaire du projet ownCloud. Gérer, c’est investir dans la pérennité du projet — financer le développement, maintenir l’infrastructure, garantir la sécurité — tout en respectant la voix de la communauté dans l’orientation du projet. Gérer ne signifie pas exercer un contrôle unilatéral.
Autorité acquise. Le statut de mainteneur, les droits de relecteur et les rôles de gouvernance s’obtiennent par une contribution régulière et de qualité. Ils ne sont pas accordés uniquement en raison du titre, du poste ou de l’ancienneté.

Rôles

Contributeurs

Les contributeurs sont toutes les personnes qui participent au projet : code, documentation, tests, design, promotion ou support communautaire. Tous les contributeurs doivent respecter le Code de conduite et le processus de validation DCO.

Relecteurs

Les relecteurs sont des contributeurs expérimentés qui ont démontré une qualité constante et une bonne connaissance d’une partie spécifique du code. Ils peuvent approuver les pull requests mais ne peuvent pas fusionner sans validation d’un mainteneur. Les mainteneurs accordent le statut de relecteur en fonction de l’historique de contribution.

Mainteneurs

Les mainteneurs sont responsables de la sécurité, de la qualité, de la santé et de l’orientation d’un ou plusieurs dépôts ou composants. Ils peuvent fusionner des pull requests, approuver des versions et prendre des décisions d’architecture dans leur périmètre. Le statut de mainteneur est accordé par l’OSPO en concertation avec les mainteneurs existants, sur la base d’une contribution significative et régulière.

OSPO (Open Source Program Office)

L’OSPO est l’entité de Kiteworks chargée de la stratégie open source, de la gouvernance, des licences, de la santé de la communauté et de l’engagement de l’écosystème pour ownCloud. L’OSPO définit les règles, tranche les litiges non résolus au niveau des mainteneurs et fait le lien entre la communauté et la direction de Kiteworks.

Prise de décision

Décisions techniques

L’architecture, la conception des API et les choix d’implémentation relèvent des mainteneurs dans leur périmètre, avec l’avis des relecteurs et des contributeurs via les issues et PR GitHub. Les désaccords se règlent par la discussion. Si aucun consensus n’est trouvé, le ou les mainteneurs concernés tranchent. Les décisions peuvent être remontées à l’OSPO.

Décisions de politique

Les licences, les règles de contribution, les changements de gouvernance et l’application du Code de conduite sont décidés par l’OSPO avec l’avis du Community Advisory Board et du groupe des mainteneurs.

Décisions sur la feuille de route

Les décisions concernant la feuille de route sont prises par la gestion produit de Kiteworks, en concertation avec l’OSPO et le Community Advisory Board. Kiteworks définit l’orientation stratégique. La communauté influence les priorités via le CAB, l’engagement sur GitHub (votes, commentaires, RFC) et la contribution directe.

Nous sommes transparents à ce sujet : Kiteworks pilote la feuille de route. Il s’agit d’un projet open source soutenu commercialement, et non d’une fondation. Ce que nous garantissons, c’est que la feuille de route est publique, que les raisons sont expliquées et que la communauté dispose de canaux d’influence réels. Si vous développez une fonctionnalité de qualité, elle pourra être intégrée — même si elle n’était pas prévue initialement.

Organes de gouvernance

Groupe des mainteneurs

Le groupe des mainteneurs réunit tous les mainteneurs actifs des dépôts ownCloud. Il se réunit régulièrement (chaque mois ou selon les besoins) pour discuter des questions techniques transverses et tient à jour une liste publique des mainteneurs par dépôt.

Objectif : publier la première liste de mainteneurs d’ici T3 2026.

Community Advisory Board

Le CAB compte 5 à 9 membres issus des contributeurs externes, des utilisateurs institutionnels et des partenaires technologiques. Les membres sont nommés pour 12 mois, renouvelables une fois. Le CAB se réunit chaque trimestre avec l’OSPO pour examiner la feuille de route, la gouvernance et la santé de la communauté. Les comptes rendus des réunions sont publiés publiquement.

Objectif : constituer le premier CAB d’ici T4 2026.

Open Source Program Office

L’OSPO est dirigé par le Vice President, Open Source Program Office chez Kiteworks. Il est responsable de la politique de gouvernance, des licences, des indicateurs de santé de la communauté, de l’engagement de l’écosystème et de la stratégie de contribution upstream. L’OSPO publie un rapport annuel couvrant les statistiques de contribution, les évolutions de la gouvernance, la santé de la communauté et l’orientation stratégique.

Contact : ospo@kiteworks.com

Objectif : premier rapport annuel OSPO d’ici T2 2027.

Gestion des conflits

Les désaccords font partie intégrante de l’open source. Notre approche :

Discussion. La plupart des désaccords se résolvent par une discussion respectueuse sur l’issue ou la PR GitHub concernée. Partons du principe que chacun agit de bonne foi.
Décision du mainteneur. Si la discussion ne suffit pas, le ou les mainteneurs concernés tranchent et expliquent leur décision.
Remontée à l’OSPO. Si un contributeur n’est pas d’accord avec la décision d’un mainteneur, il peut saisir l’OSPO. L’OSPO examine le dossier, consulte les parties concernées et rend une décision contraignante sous 10 jours ouvrés.
Les violations du Code de conduite sont traitées séparément via le processus d’application du CoC. Les signalements sont à adresser à coc@owncloud.com.

Engagements de transparence

Feuille de route publique. Mise à jour au moins chaque trimestre. (Objectif : T3 2026)
Liste publique des mainteneurs. Par dépôt, tenue à jour. (Objectif : T3 2026)
Architecture Decision Records (ADR). Les décisions d’architecture importantes sont documentées sous forme d’ADR dans le dépôt (déjà en place pour oCIS).
Journal des évolutions de la gouvernance. Toute modification de cette charte, des licences ou des règles de contribution est annoncée publiquement avec un délai minimum de 30 jours pour commentaires avant application.
Rapport annuel OSPO. Publié publiquement. (Objectif : T2 2027)

Gouvernance des licences

Les nouveaux dépôts sont placés par défaut sous licence Apache 2.0. Toute modification de licence sur un dépôt existant nécessite l’accord de l’OSPO, une RFC publique avec 30 jours de commentaires et la consultation du Community Advisory Board.

ownCloud n’utilise pas l’ambiguïté des licences comme levier commercial. Les choix de licences sont publics, réfléchis et appliqués de façon cohérente.

Évolution de cette charte

Voici la version 0.1 de la charte de gouvernance. Elle évoluera au fil de la croissance et de la maturité de la communauté. Les changements suivent le processus du journal des évolutions de la gouvernance :

Annonce publique
Période de commentaires de 30 jours
Décision de l’OSPO

Nous savons que cette charte comporte une part d’objectifs à atteindre.

Certains dispositifs —

le CAB
le rapport annuel
la liste des mainteneurs

— n’existent pas encore. Nous publions la charte dès maintenant, sans attendre que tout soit en place, car nous pensons qu’il vaut mieux être transparents sur la direction que nous prenons plutôt que de rester silencieux.

Calendrier de mise en œuvre

Étape	Date cible	Statut
Publication de la Charte de gouvernance v0.1	T2 2026	En cours
Retrait de l’ancien CLA, mise en place du DCO	T2 2026	En cours
Publication de la politique de contribution assistée par IA	T2 2026	En cours
Publication de la politique de divulgation de sécurité	T2 2026	En cours
Publication de la première liste de mainteneurs par dépôt	T3 2026	Prévu
Publication de la feuille de route publique	T3 2026	Prévu
Création du Community Advisory Board	T4 2026	Prévu
Première réunion du CAB	T4 2026	Prévu
Premier rapport annuel OSPO	T2 2027	Prévu
Charte de gouvernance v1.0 (après retour du CAB)	T2 2027	Prévu

Foire aux questions

Kiteworks agit en tant que garant du projet ownCloud, en investissant dans sa pérennité via le financement du développement, la maintenance de l’infrastructure et la sécurité. Toutefois, ce rôle de garant n’implique pas un contrôle unilatéral : Kiteworks respecte la voix de la communauté dans l’orientation du projet.

Le statut de mainteneur est accordé par l’Open Source Program Office (OSPO) en concertation avec les mainteneurs existants. Il repose sur un historique de contributions importantes et régulières au projet, reflétant une autorité acquise et non un titre ou un emploi.

Le Community Advisory Board (CAB) compte de 5 à 9 membres issus de contributeurs externes, d’utilisateurs institutionnels et de partenaires technologiques. Il se réunit chaque trimestre avec l’OSPO pour examiner la feuille de route, la gouvernance et la santé de la communauté, offrant ainsi un canal d’expression à la communauté. Les comptes rendus des réunions sont publiés publiquement.

Les conflits se règlent via un processus structuré : on commence par une discussion respectueuse sur les issues ou PR GitHub, puis, en cas de désaccord persistant, le mainteneur concerné prend une décision. Si un contributeur n’est pas d’accord, il peut saisir l’OSPO, qui rend une décision contraignante sous 10 jours ouvrés. Les violations du code de conduite sont traitées séparément via une procédure dédiée.