26 janvier 2011

2011, l'année du fork

2011 pourrait bien être l'année du fork.


Non, je ne parle pas du nouvel an chinois, mais de la scission d'une communauté open-source (fork).

Le premier va se dérouler du côté du serveur d'intégration continue Hudson.
Après avoir géle puis migré le projet (sans prévenir) de l'infrastructure java.net vers kenai, Oracle réclame aujourd'hui le pilotage du projet, ou en tout cas l'application de règles strictes de pilotage et de cession des droits sur les contributions. La communauté ne suit pas, prise depuis le début à rebrousse-poil, et a déjà migré sur gitHub et google-groups.

Les dernières tentatives d'accord pour trouver un arrangement acceptable, légitimant une communauté indépendante sans couper les ponts avec Oracle, ne progressent pas. On s'oriente donc à grand pas vers un changement de nom pour Hudson (la seule chose qu'Oracle possède encore c'est ... ce nom "hudson ®") qui deviendra Jenkins.

La communauté Hudson - légitime en terme de lignes de code - se retrouve donc face à Oracle qui ne lâche pas grand chose, fort de sa légitimité sur le nom "hudson" et l'historique du projet.

Le second pourrait se dérouler du côté de Maven. 
Critiqué pour son pilotage unilatéral du projet au travers de sa société Sonatype, Jason Van Zyl a claqué la porte du Project Management Committee Maven. Fondateur du projet, il ne participe donc plus à ces discussions (qui a dit "disputes" ?) et continue à bosser avec ses collègues sur l'outil qui fait vivre sa boite, mais sur gitHub plutôt que dans le SVN Apache. Le code reste opensource, accessible à tous, mais ne suit plus les règles de bonne conduite communautaire édictées par la fondation. Sans a priori sur les personnalités en présence, ce n'est pas la première fois qu'un leader se plaint du modèle Apache et finit par aller voir ailleurs [1].

Les raisons de la crise : une partie non négligeable de Maven (Aether) est désormais hébergée chez Sonatype, et bien que toujours opensource, est vécue par certains contributeurs Maven comme une perte de contrôle (nécessité de signer une CLA pour contribuer). Comme pour ajouter à la sauce, Modello et Plexus, deux projets "socle" de Maven, ont été déplacés sur le gitHub Sonatype puis fermés sur codehaus.

Jusqu'ici les échanges liés à ces frictions sont restés discrets, la fondation Apache ayant pour règle de gérer ce genre de conflit en privé. Avec la contribution de Sonatype dans la fondation Eclipse via le projet m2eclipse, un changement de license [2] sur un composant a ébruité publiquement la situation.

Il ne s'agit pas (encore) d'un fork, mais rien n'interdit à Sonatype de publier ses propres releases de Maven (mais pas Apache Maven) dans le cade de son offre Sonatype Professional, le nom n'étant pas déposé par la fondation. Le PMC doit donc trouver un compromis, définir des règles sur l'utilisation de ces composants "externes" qui constituent pourtant une part importante de Maven 3 (core), et voir comment intégrer les développements de Sonatype tout en conservant un pilotage à la Apache du projet et en continuant à assurer la maintenance des nombreux plugins qui - eux - restent un terrain de jeu équitable pour tous les contributeurs (les moins doués se contentant d'écrire des bouquins sur le sujet).

La communauté Apache Maven - légitime en terme de contribution historique et de support - se retrouve donc face à Sonatype, fort de sa légitimité sur la quasi-totalité du travail de développement de Maven 3.

Inutile de vous dire à quel point ces querelles de légitimité, de licence, de règles de pilotage sont à la fois passionnantes et barbantes pour les contributeurs qui passent un temps fou à éplucher les mailing-list abreuvées de messages enflammés. 2011 risque de ne pas être une année reposante.




[1] le développement de log4j 1.3 est quasi abandonné, englué dans des discussions sur le maintien de la compatibilité. Ceki Güclü a préféré reprendre à 0 avec l'excellent slf4j.
[2] https://github.com/sonatype/sisu, notez les deux fichiers LICENCE.txt. Sous licence EPL, le code associé n'a plus aucune chance de revenir à la fondation

10 commentaires:

Emmanuel Lécharny a dit…

Quelques précisions :
- Ceki a envisagé l'année dernière de repasser en license ASL 2.0 ses développements;
- L'ASF ne dépose pas de marque, c'est non seulement inutile, mais en plus coûteux. Mzven en tant que marque appartient à l'ASF, puisque l'ASF a utilisé ce nom en premier. Il n'est pas possible qu'il y ait un "Sonatype Maven".

Après, l'ASF est ouverte, chacun est libre d'y entrer et d'en sortir. La license le permet, et c'est tat mieux...

Henri a dit…

Nous sommes dans 2 cas bien différents.

Hudson c'est un projet sur lequel Oracle ne souhaite pas perdre le contrôle mais qui est très largement dans les mains de Kohuse et de la communauté des contributeurs.

Bref si les contributeurs le suivent sur Jenkins et qu'il change un temps soit peu les API, ex: org.jenkins.*, Hudson risque de mourir très rapidement par obsolescence et manque de plugins.

Maven, c'est autre chose, c'est déjà un projet de l'ASF avec un cadre plus protecteur pour la communauté.

Pour ce projet, comme beaucoup d'autres à l'ASF, rien n'empêche pas d'avoir des sociétés qui contribuent plus largement et plus activement que des individus bénévoles qui ne peuvent y participer à plein temps.

Maven c'est un noyau qui évolue énormément grâce à Sonatype dont l'éco systeme Maven est l'activité principale et qui a les ressources pour enrichir et développer le produit.

C'est aussi une richesse infinie de plugins qui sont le plus souvent réalisés et maintenus par des contributeurs personnels.

Et ce sont ces plugins qui donnent toute la richesse de la pile Maven car ce sont eux qui sont vu par les utilisateurs.

Un équilibre des pouvoirs un peu différent donc et comme souvent sur des projets majeurs de l'ASF, une certaine tension ne peut qu'exister entre une entreprise contributrice par son activité professionnelle avec sa roadmap et des individuels qui craignent (à juste titre ou non) de perdre le contrôle.

De là à parler d'un fork, c'est peut être un peu tôt d'autant plus que le nom Maven est et reste ASF, tout le monde aurait donc à y perdre.

Unknown a dit…

Alors cette année l'année chinoise sera l'année du Chat.

Ensuite, j'aurais plutôt vu une fourchette (fork) à la place d'un bébé phoque en illustration. :-)

Anonyme a dit…

Je ne pense pas que la fondation Apache "ait pour règle de régler les conflits en privé" comme tu le dis.

L'habitude est effectivement de discuter les problèmes concernant des personnes sur nos listes privées pour éviter de lyncher les gens en public quand c'est possible.

Quand aux problèmes de la communauté Apache Maven et de ses projets satellites, il serait probablement bénéfique de les exposer au public de la liste dev plus tôt - porter ce genre de problèmes sur la place publique aide souvent à mettre les choses à plat, en exposant les faits à un cercle plus large.

En fait, la règle de la fondation Apache qui s'applique le mieux dans ce cas est que "tout ce qui ne doit pas absolument être privé doit être public". J'encourage les membres du PMC Maven à rediriger sur la liste publique tout ce qui peut l'être. Ca fera un peu plus de bruit sur la liste dev, mais c'est pour le bien du projet.

Nicolas De Loof a dit…

@bdelacretaz Je suis tout à fait d'accord sur le rôle de la "place publique" pour clarifier les conflits d'intérêt et trouver des compromis. Je trouve d'autant plus dommage que les choses restent aujourd'hui aussi cachées du commun des contributeurs, alors que le départ de Jason du PMC est tout de même un événement - d'où ce billet.

Comme tu as pu le constater sur le commit de sisu, les discussions publiques tournent malheureusement rapidement aux attaques personnelles.

Unknown a dit…

@henri Je suis bien d'accord pour l'aspect très différent de ces 2 projets.

La vision des choses est même complètement antagoniste si l'on applique le principe de méritocracie.

Un détail cependant à propos du renommage en org.jenkins.* : ce type de renommage risque d'engendrer une non compatibilité ascendante des plugins vis à vis du core (sauf si un artifice du type renommage des packages à la volée est mis en place, ce que je ne souhaite pas spécialement pour mon débugger perso...).

Mes échanges avec Kohsuke me montraient qu'il souhaitait avant tout éviter ce type de clash pour les plugins (avoir des "plugins compatibles hudson only / jenkins only" serait très dommage !)

Enfin, un dernier aspect : je pense que la galaxie de plugins hudson est au moins aussi développée que celle des plugins maven. Et en effet, cela représente une très forte richesse !
Mais cela représente également une limite du modèle puisque cela complexifie énormément le licensing du "tout packagés". L'avantage pour maven, c'est que généralement, c'est -pour résumer- soit celle d'apache, soit celle de codehaus. Dans le cas d'Hudson, c'est beaucoup plus compliqué (si les contributeurs ne touchent à rien, c'est la MIT qui est utilisée par défaut dans les POM)
L'autre inconvénient de cette richesse de plugins, c'est qu'à tout pluginifier, on en arrive au projet maven qui, finalement, ne devient qu'un ordonnanceurs de plugins/librairies .. ce qui peut amener à des problèmes là encore, en terme de licences (le noyau se vidant au fur et à mesure, et les lib "importantes" sortant de plus en plus de l'ASF)

Anonyme a dit…

"les discussions publiques tournent malheureusement rapidement aux attaques personnelles." c'est malheureusement une tendance, qu'il faut combattre à chaque fois...un peu pénible mais les trolls finissent souvent par se fatiguer (bon, je suis un optimiste ;-)

Batmat a dit…

D'accord avec tout ça, particulièrement sur la grande différence entre l'écosystème Hudson et Maven.

Juste une petite remarque Nicolas : la correspondance, c'est plutôt log4j->logback,commons-logging->slf4j.

Baptiste

Nicolas De Loof a dit…

Et ça continue avec Redmine qui est forké par la communauté de contributeurs : ChiliProject

https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork

Unknown a dit…

Nicolas, où as-tu eu l'info quand au départ de Jason du PMC ?

Je n'ai pas vu passer d'annonce, les membres de maven souhaitent-ils éviter les vagues ?