new Blog( perso );

Dans l'épisode précédent, Sonatype s'était allié à Oracle pour supporter Hudson, tandis que la rébellion s'organisait pour développer Jenkins avec le succès qu'on a pu constater.

Aujourd'hui, Oracle annonce vouloir donner Hudson à la fondation Eclipse (avec le soutien de Sonatype et VMWare), acceptant ainsi au final les conditions qui étaient réclamées par la communauté lors de la "crise" :

• disposer d'un modèle de gouvernance sans prédominance d'une société
• libérer le nom "hudson" de toute emprise en le léguant à un organisme indépendant

Ces conditions, à l'époque, se sont heurtées à un "non" sans appel de la part d'Oracle. Aujourd'hui, sans doute calmé par le succès de Jenkins fàce à un Hudson qui a du mal à exister autre part que sur le blog de Sonatype qui met en avant sa version "pro", Oracle change son fusil d'épaule.

On pourrait presque imaginer les deux branches fusionner à nouveau dans un grand moment de réconciliation, mais c'est assez peu probable.

D'une part, cette décision arrive bien tard. Jenkins a évolué depuis la scission, la communauté a pris ses aises et choisi son modèle de gouvernance. Il n'est pas du tout évident que celui de la fondation Eclipse soit aussi souple :P

D'autre part, la querelle avec Oracle a laissé des cicatrices; s'il ne s'agit pas de régler ses comptes, les principaux acteurs se voient mal travailler main dans la main comme si de rien n'était.

Enfin, passer le code de Hudson dans la fondation Eclipse ne se fera pas en deux minutes. Le processus d'incubation de la fondation est très strict (pour ne pas dire lourdingue), en particulier sur les aspects propriété du code et compatibilité des licences. C'est pour cela d'ailleurs que l'IDE Eclipse n'a pas de support SVN natif, l'implémentation Java SvnKit étant sous licence LGPL. Sans parler d'ailleurs du code pour lequel Oracle n'a pas a priori la propriété intellectuelle (pensez aux contributions de Kohsuke après qu'il ai quitté Oracle).

L'idée de voir Jenkins hébergé par la fondation Apache a été évoqué à un moment pour donner plus de visibilité au projet et lui assurer un cadre juridique solide. De la même façon, Jenkins devrait passer par l'incubateur Apache et résoudre les mêmes soucis de propriété intellectuelle et de licences.

Au final, cette contre-attaque est délicate à pronostiquer. Avec les moyens de Oracle + Sonatype + VMWare et la force de communication liée à l'aura de la fondation, Hudson peut rester sur les rails et progresser de manière intéressante. Dans le même temps, Jenkins démontre sa capacité à avancer vite et bien, avec :

• un nouveau processus de release à deux vitesses, avec une version "stabilisé" par tranche de 3 mois n'incluant que les corrections majeures
• plus de soin dans la gestion de la compatibilité, avec un mécanisme de test des plugins sur la version N+1 (action menée par notre compatriote Frédéric Camblor)

Il nous reste à attendre le prochain épisode. Je ne pense pas que le Jedi veuille bien revenir pour détruire l'étoile noire, et les deux outils continueront probablement à vivre côte à côte pendant longtemps. En tout cas, nous aurons assisté à un formidable gâchis depuis l'intervention de l'empire et de son allié dark vador (je vous laisse mettre des noms en fàce par vous même).

C'est chose faite, la communauté des développeurs Hudson a choisi de quitter définitivement Oracle et de forker / renommer (tout dépend du point de vue) le projet en Jenkins (http://www.jenkins-ci.org).



Les choses sont déjà suffisamment compliquées, voici que Sonatype prend position et apporte son soutien ... à Oracle Hudson :
"


"

Jason met le doigt sur un élément clé : la stabilité et l'architecture de Hudson. C'est un critère important pour son utilisation en entreprise sur des projets stratégiques. Il faut reconnaitre que le modèle de développement de Hudson est particulièrement ouvert et manque parfois d'un cadre strict. Cela n'a pas empêché le projet de progresser très vite et de s'enrichir de fonctionnalités avancées, et ça a toujours été une volonté affichée pour réduire au minimum la barrière de contribution. Par contre, ça peut ne pas rassurer un DSI (vous me direz, c'est le même qui a commandé des licences Websphere 7, mais bon ...).

L'offre Sonatype Profesionnal intègre un Hudson validé et supporté ("Matrix"), il ne fait donc aucun doute que Sonatype a des évolutions techniques à proposer pour stabiliser et améliorer le projet. Devant le vide laissé par le départ de la communauté des développeurs pour Jenkins, ils vont ainsi se retrouver premier contributeur au côté d'Oracle, une place de project-lead inespérée.

Evidemment, rien n'est gagné : la communication autour du changement de nom a été large et Jenkins va continuer d'avancer au rythme qu'on lui connait. D'un autre côté, les clients d'Oracle ou de Sonatype seront sensibles à l'argumentaire de qualité technique et de stabilité d'un élément clé de leur forge logicielle. Sonatype va donc devoir mettre les bouchées doubles pour démontrer une plus-value et sa capacité à améliorer Hudson. Jenkins étant contraint de conserver les APIs existantes, les nombreux plugins ne sont pas remis en cause (dans l'immédiat), aussi Sonatype va pouvoir se focaliser sur le coeur Hudson et sur une intégration Maven 2/3 particulièrement poussée. Le niveau technique des développeurs ne fait aucun doute, tout va donc se jouer dans le timing et l'art de communiquer auprès de la communauté d'utilisateurs.

Pas facile de prédire ce que cela va donner... en espérant que ça ne va pas tourner au troll "audit de code" ou que sais-je pour démontrer qu'un projet est techniquement supérieur à l'autre.

On vit une époque formidable.

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

Le départ de SUN/Oracle de Kohsuke Kawaguchi a laissé planner quelques interrogations sur l'avenir de Hudson.

SUN finançait les travaux de Kohsuke sur ce qui était initialement un outil interne du projet Glassfish, et n'a jamais remis en question son orientation opensource. Le passage chez Oracle a fait peur mais n'a eu aucun effet notable sur le projet. Par contre, le départ de Kohsuke pour monter sa propre société autour d'Hudson pose de nombreuses questions.

Que va devenir le projet Hudson sur java.net ? Sans que personne ne soit indispensable, il reste très lié à Kohsuke et donc à sa bonne volonté / son temps pour soutenir le projet en opensource. Quel modèle pour sa toute jeune société InfraDNA ? Le lancement d'un Hudson "certifié" donne des éléments de réponse :

ICHCI (c'est son petit nom) répond à une préoccupation légitime de tout gestionnaire de forge logicielle : quelle version de Hudson installer, sachant qu'on a une release chaque semaine. Le temps de qualifier une version, la suivante est dans les bacs ! Une fois la version choisie, quels plugins activer ? Il y en a pour à peu près tout et n'importe quoi dans des états variables, du early-draft au plugin parfaitement stabilisé. L'idée d'IHCI est donc de ralentir la vitesse extravagante de développement d'Hudson pour en fournir une version "stabilisée" - comprendre testée en profondeur - accompagnée d'une sélection soigneuses de plugins, et bénéficiant d'un support dédié.

Selon un modèle assez classique opensource/pro, ICHCI se base sur la forte pénétration de Hudson et de l'intégration continue en général pour monnayer ce service. Ceux qui veulent/peuvent construire leur forge avec leur petite main le feront en opensource, ceux qui préfèrent ne pas dépenser des jours sur ce qui devient un élément courant de l'infrastructure projet feront un chèque.

Des plugins spécifiques propriétaires accompagnent cette version professionnalisée d'Hudson. Ils sont la valeur ajoutée qui permet d'afficher une plus value autre que le seul support (et s'adresse donc au techos que je suis, le DSI ayant été convaincu par l'offre de support :P). La communauté Hudson étant très, très active, ces plugins pourraient à terme avoir des équivalents opensource, ou bien InfraDNA pourrait ouvrir ses plugins en fonction de l'avance qu'il arrive à maintenir - comme Sonatype l'a fait avec le plugin LDAP pour Nexus.

Bref, ça bouge, c'est bien. Hudson a de l'avenir, aussi bien en opensource qu'en outil pro. Vous pouvez ranger votre CruiseControl.

Après des années à trainer sur la mailing list de Maven, j'ai été invité dans la communauté Mojo qui héberge une large panoplie de plugins Maven "non stratégiques" - comprendre non supportés par le projet Maven lui-même. J'y ai lancé les javascript-maven-tools (à l'état dormant depuis) et repris le flambeau sur le plugin GWT. Ce projet, relativement ouvert aux nouveaux contributeurs, fonctionne sur ce modèle : proposer, supporter, passer la main. Un plugin n'y vit que si des développeurs sont là pour le soutenir, développeurs qui sont souvent ses premiers utilisateurs.

Je suis ensuite passé dans le code d'Archiva pour des besoins internes. Ayant du temps plus ou moins officiellement dégagé sur cette tâche j'ai pu m'investir et faire des évolutions intéressantes, créer des liens forts avec les développeurs, qui m'on finalement invités à rejoindre le projet Maven - à l'époque non différenciée d'Archiva. Nous sommes fin 2007.

Depuis cette date, j'ai continué à oeuvrer sur le plugin Mojo GWT et j'ai quelquefois apporté ma pierre à l'édifice Maven, via quelques contributions mineures (release:stage, c'est moi). Mes tentatives pour rentrer dans le "core" se sont soldées par un échec : soit j'ai clairement fait des boulettes et j'ai été vite renvoyé dans les cordes [svn rollback], soit mes propositions sont restées sur le pavé. En 30 mois je n'ai donc rien committé de concret dans le svn Maven.

Par contre, j'ai activement participé à la com' sur Maven, à travers les JUGs et ce fameux bouquin dans lequel j'ai réussi à embarquer Arnaud. Tout ça c'est du temps libre, ça ne rapporte rien en dehors de l'estime de la communauté - ce qui est déjà beaucoup.

Mon activité pro ne consiste pas à développer Maven, déjà que contribuer à corriger des bugs ou à améliorer quelques plugins ne soit pas une tâche tout à fait officielle. Mon temps libre est déjà largement amputé par l'organisation du BreizhJug. Je n'ai plus le temps pour élaborer des idées, développer un POC et le faire challenger par ceux qui passent leurs journées sur le projet. Même si cela parait nécessaire le coût est trop important pour un simple contributeur comme moi.

J'ai donc fait le choix symbolique de me retirer de la liste des développeurs Maven. Cela ne me retire pas le droit de commit, rassurez-vous, je pourrais donc encore venir appliquer quelques patchs intéressants pour corriger un bug que je rencontre dans mon boulot de tous les jours. Par contre je ne compte plus m'impliquer dans le développement de Maven.

Hudson utilise un modèle assez étrange au premier abord : pour devenir committer, il suffit de montrer patte blanche. "Bonjour, j'ai écrit un patch pour l'ano ###" (et/ou) "J'ai écrit un plugin rigolo boite-à-meuh-hudson-plugin". La réponse ne tarde pas : "Quel est ton ID java.net, comme ça tu pourras le committer toi même". Hudson fonctionne sur la confiance : ceux qui participent sont déjà une toute petite sous-catégorie de gens motivés, il ne faut surtout pas les freiner. Un plugin hudson ne vit que parce qu'un ou deux développeurs le supportent, et le projet a besoin de sang neuf pour vivre et s'épanouir.
C'est vrai que lorsqu'on regarde sous SVN, Hudson paraît particulièrement bordélique. C'est un effet de bord totalement assumé ! Obliger les développeurs à suivre des conventions trop rigides c'est créer une barrière aux contributeurs. Si un plugin est proposé, même dans un état discutable, mais avec de la motivation et du temps pour s'en occuper, alors feu vert. S'il devient vraiment utile et attire d'autres développeurs il sera toujours temps pour le "nettoyer". Jusqu'ici, le projet n'a pas eu à souffrir de ce qui ressemble a priori à un manque de rigueur. Les versions se succèdent à un bon rythme, avec des corrections rapides et de nouvelles idées.

Deux approches opposées,

• le modèle Apache Maven : les règles et les consensus à la Apache, et un pilotage "business-driven", 
• le modèle Hudson : "open-bar" ouvert à toutes les bonnes volontés. 

Les deux outils ont fait leurs preuves et sont devenus l'un comme l'autre des incontournables, avec un excellent niveau de stabilité. Comme quoi tout n'est pas gravé dans le marbre

Koshuke Kawaguchi, développeur de génie a qui on doit (entre autre) le célèbre serveur d'intégration continue Hudson, annonce son départ de SUN/Oracle. Mauvaise nouvelle pour SNORCL, mais les utilisateurs d'Hudson n'ont pas de soucis à se faire car Koshuke se lance dans un nouveau projet visant à propulser son bébé à un autre niveau.

L'idée ne semble pas nouvelle, reste à savoir si ce pas aurait été franchi aussi rapidement sans le rachat de SUN... Il va y avoir quelques cadavres dans cette fusion.

Comment sensibiliser l'équipe au bonnes pratiques de l'intégration continue ?