24 juin 2010

Deux ans de Maven - le bilan


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

5 commentaires:

Widge a dit…
Ce commentaire a été supprimé par l'auteur.
Widge a dit…

La Cathédrale et le Bazar?

belaran a dit…

En fait, c'est amusant de constater que le modèle Apache est "business" oriented alors que celui de Hudson, produit Sun devenu Oracle, ne l'oublions pas, est complètement ouvert.

En tout cas ton post confirme largement les soupçons que j'avais - et déjà évoqué par Vincent Massol dans un épisode des Cast Codeurs : si Open Source soit il, Maven est quelques part un produit "éditeur" (ie Sonatype), et tout comme JBoss, si l'accessibilité de son code en améliore la qualité et la fiabilité, l'impact de la communauté, hors des plugins et des bugfixes est vraisemblablement faible...

nicolas deloof a dit…

Maintenant que "Maven" est devenu une marque à lui tout seul sans bénéficier d'un atout supplémentaire quand on lui associe le préfixe "Apache", je ne comprend pas pourquoi Sonatype ne récupère pas officiellement le dev de Maven3, qu'ils portent déjà à 99%. Les gars d'iBatis ont claqué la porte de la fondation dans de bien moins bonnes conditions et ça n'a pas fait plus de vagues. Alors qu'est ce qui les retient de faire de Maven un projet opensource professionnel (i.e. piloté par une société qu'il fait vivre) ?

grozeille.com a dit…

Salut,

Je comprend exactement ce que tu dis.
Je suis d'ailleurs très content d'avoir pu enrichir le plugin "violation" pour qu'il supporte les rapports "mono gendarme" (oui, je suis en .Net moi). Si j'ai plus de temps libre, et plus de motivation, je corrigerai bien les divers bugs qui m'ennuient... en tout cas, c'est ouvert donc ça me freine beaucoup moins :)

Par contre, je trouve super étrange qu'Hudson n'ai pas un Hudson pour lui même. Si une intégration continue affiche les rapports d'analyse de code, ça montrera bien si le code est propre, suffisamment testé, etc. Les développeurs se corrigerons eux même, juste par fierté d'être en dessous du seuil maxi de connerie autorisé ;)

En tout cas, quand on regarde le code, on voit qu'il y a eu du monde qui lui est passé dessus... dans le même plugin Violation j'ai trouvé diverses implémentations de la même chose pour les différents rapports. Mais le plus important c'est que ça marche: le refactoring peut se faire dans un second temps.