La Fondation Eclipse ajuste sa gouvernance pour Jakarta et la définition de spécifications

La fondation open source publie un premier jet de son processus pour encadrer la définition de spécifications, qui sera utilisé pour JakartaEE. Les accords de contributions sont également revus.

La Fondation Eclipse a débuté un ajustement de son modèle de gouvernance pour intégrer en bonne place JakartaEE, le nouveau de nom de baptême de Java Enterprise Edition désormais dans le giron de l’institution open source.

Ancien projet d’IBM, la fondation Eclipse fédère depuis presque 15 ans la communauté des développeurs Java en hébergeant des projets open source centrés sur les outils de développement. Connue historiquement par son IDE (Integrated Development Environment), la fondation a fait évoluer sa portée vers des projets clés, tous encadrés par une gouvernance open source, favorisant la collaboration avec les sociétés utilisatrices – l’un des points clé de la fondation.

Mais depuis 2017, elle doit composer avec une nouvelle activité : la création de spécifications et de standards. A cette date, Oracle  a décidé d’ouvrir à l’open source l’ensemble des composants de la plateforme et, accompagné de Red Hat et d’IBM, de placer la gouvernance de Java EE (à partir de la version 8) entre les mains d’Eclipse. Pour des raisons de marque, le projet est devenu Jakarta EE au sein de la fondation et les projets qui le composent sont transférés progressivement vers le nouveau modèle de gouvernance. A la rédaction de cet article, la majorité des projets avaient parcouru 80 % de leur parcours, comme l’indique un tableau de bord publié sur le site du projet.

Avec l’arrivée de JavaEE, la fondation Eclipse a également hérité de la mécanique de création des très précieuses spécifications de la plateforme. A l’origine, ces spécifications étaient régies par le JCP (Java Community Process), et étaient contrôlées par des processus spécifiques. Processus que la fondation doit désormais digérer, mais sans déshabiller pour autant son modèle open source.

A la mi-octobre, l’organisme open source a donc posé les jalons du remplaçant du JCP qui définira le processus de création des spécifications utilisés pour JakartaEE. Cela devient le Eclipse Foundation Spécification Process et complète ainsi l’Eclipse Development Process. Comme le précise Mike Milinkovich, le directeur exécutif de la fondation Eclipse, dans un billet de blog, ce processus, décliné d’abord pour Jakarta EE, a aussi vocation à être utilisé pour d’autres projets de la fondation.

Selon lui, ce modèle a été conçu pour être le plus léger possible, mais aussi pour être au plus près de la mécanique du développement open source. Ce qui n’est pas « trivial, car par nature, créer des spécifications suit quelque peu un processus différent ». Pourtant, la fondation souhaite conserver son ADN et « ré-utiliser l’Eclipse Development Process chaque fois que possible », précise-t-il.

Resserrer les contrôles

L’autre ajustement porte sur le contrôle de la propriété intellectuelle. La fondation a créé pour cela un profil « Participants » parmi les committers, pour représenter les sociétés membres de la fondation et contribuant à un projet de spécifications (Spec Project). « Cela est nécessaire pour s’assurer que les contributions d’entreprises en termes d’IP [Intellectual Property] (surtout les brevets) sont bien intégrées au processus », explique le patron d’Eclipse. Dans cette même logique, un comité dédié (Specification Committe) devra désormais approuver les releases venant des projets (Spec Projects), en plus de la validation du Project Management Committee (PMC).

Enfin, la fondation a également renouvelé les accords qui encadrent les contributions et les contributeurs. A travers ces nouvelles règles, la fondation souhaite clarifier le fait que « les contributions à nos projets open source peuvent un jour être utilisées pour créer une spécification, parce que nous croyons à l'innovation par le code. Nous croyons également que si vous contribuez à l'open source, vous souhaitez également que vos contributions soient utilisées de façon ouverte, y compris les spécifications », explique Mike Milinkovich dans un autre billet de blog.

Pour approfondir sur Open Source

Close