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.
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.
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:
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...
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.
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. :-)
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.
@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.
@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)
"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 ;-)
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
Et ça continue avec Redmine qui est forké par la communauté de contributeurs : ChiliProject
https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork
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 ?
Enregistrer un commentaire