Talend – Cédric Carbone (co2)

Un article de co2    Pas de commentaires

J’ai présenté ce soir, dans le cadre du SparklingPoint, rendez-vous mensuel de networking, ma vision sur les outils ou procédures à mettre en place dans les projets Open Source. Dans ce billet, voici quelques idées que j’ai eu l’occasion de développer.

Depuis 2003, il y a une professionnalisation des projets Open Source. Des sociétés proposent des services (MySQL, JBoss, SugarCRM, RedHat, Alfresco, Talend…) afin que les entreprises utilisateurs puissent bénéficier du même niveau de services (voir même plus) qu’avec les produits propriétaires. Par exemple, les éditeurs de solution open source peuvent proposer de la formation, de l’expertise pointue, la souscription de support… Ces éditeurs peuvent également publier des versions certifiées (stables, testées, assurant une compatibilité ascendante…) Bien entendu, ces versions certifiées seront souvent un peu en retard par rapport aux versions contenues dans le gestionnaire de sources car elles seront passées par une période de qualifications.

Il faut avant tout diffuser une roadmap et choisir un dictateur bienveillant qui aura pour mission de fédérer le projet, l’animer et des fois mettre fin à des discussions interminables avec la meilleur (ou la moins mauvaise dans certains cas) solution. Il faut savoir se tenir à la roadmap et que les fonctionnalités ajoutées aillent vraiment dans le bon sens. De même, il faut savoir refuser certaines contributions qui ne sont pas assez testées, assez stables, assez optimisées. Cependant, il faut faire attention à aller dans le sens de la communauté afin de pas subir un fork (duplication du projet sous un nouveau nom avec d’autres idées -> division des contributeurs et des utilisateurs…)
Donc, il faut être très transparents, mettre à disposition un certains nombres d’outils et être vraiment assez ouvert tout en tapant du point sur la table quand il y a besoin.

Une grande différence entre les éditeurs open source et les éditeurs professionnels se situe au niveau de la force de vente. En fait, les éditeurs traditionnels disposent d’une armée de commerciaux qui vont chasser les prospects. De ce fait, les éditeurs propriétaires connaissent bien leurs futurs clients à qui ils donnent des versions d’évaluation de leur produit, ils font des POC…
Pour les éditeurs Open Source c’est une tout autre histoire. Un grand nombre d’utilisateur sont inconnu par l’éditeur. Le marketing viral permet de diffuser vite à très grande échelle les différents logiciels. Internet n’a pas de frontière géographique. Il faut donc mettre en place un certain nombre d’outils pour connaître les utilisateurs afin de leur proposer des services à valeurs ajoutées. Par les statistiques de download, on peut par exemple détecter dans quels principaux pays et même quelles principales régions sont téléchargés nos produits. Par exemple, pour Talend Open Studio, 60% des téléchargements proviennent des états unis ce qui nous a poussés à ouvrir plus rapidement que prévue un bureau là bas. Connaître le pays où se situe nos principaux prospects c’est bien. Disposer de leur email, du téléphone, du nom de leur société… c’est mieux! Pour recueillir des informations essentielles sur nos prospects, on peut leur demander au download ou au lancement de l’application de remplir un formulaire (veuillez à le simplifier au maximum si vous voulez avoir une chance qu’ils soient correctement rempli). On va également tirer profits des différents outils communautaires où les utilisateurs devront enregistrer certaines informations (email, société…)

Justement, voici une petite liste de quelques outils communautaires à mettre en place :

• Forum : Question/Réponse, support à l’installation ou à l’utilisation, discutions sur les futures fonctionnalités… Le forum est dans un format libre non structuré facilitant les échanges. Pensez à opter pour une solution (ou installer le plugin correspondant) permettant de publier des images (une image vaut mieux qu’un long discours)
• Bugtracker : permet de suivre les features et les bugs. Chaque issue est structurée et va suivre un workflow défini (par défaut dans Mantis , le schéma classique est new -> feedback -> confirmed -> ressolved -> closed). Via le bugtracker, on peut savoir quel développeur travail sur le bug, avoir une estimation de livraisojn (ETA – Estimate Time Arrival) connaître dans quelle version la correction a été intégré…
• Wiki : permet de gérer facilement le site web, les docs… L’avantage c’est qu’on peut facilement donner des droits à un contributeur pour gérer certaines parties du wiki (guide d’install, guide utilisateur, traduction de certains docs…) Un flux RSS est souvent associé aux solutions de wiki permettant de suivre toutes les modifications
• Gestionnaire de sources avec un compte anonymous permettant à quiquonque de télécharger les sources
• Mailling list de commit : envoi d’un email avec le détail du commit, le log…)
• Mailling list de news associé à un flux RSS
• Nightly Build et Build Stable (industrialisation des build)
• Outils d’instrumentation de code et de vérifications automatiques de la qualité (chez Talend on a choisi JUnit pour les tests unitaires, CPD pour détecter les portions de codes dupliqués, CheckStyle pour le respect des guidelines, JDepend afin d’avoir des pourcentages d’instabilité, d’abstraction, couplage, JavaNCSS pour des metrics…)
• Outils de communication : l’email mais aussi l’Instant Messaging, les Videoconférences…)

Pour Talend Open Studio on a fait les choix de PunBB (Forum), Mantis (Bugtracker), DokuWiki (Wiki), Subversion (gestionnaire de source), MailMan via sourceforge(gestionnaire de mailing list), Ant (outils d’industrialisation)…

Il faut savoir que la plupart de ces outils sont préinstallés et utilisables gratuitement par de nombreuses plateformes en mode ASP (SaaS) : Sourceforge, Javaforge, Eclipse, OW2…

Je terminerai ce billet par un aspect important à mettre en place dans le cadre des outils Open Source. Il est parfois difficile d’intégrer différents outils open source ensemble et il faut donc veiller à faire des alliances avec différentes sociétés afin de proposer des plateformes intégrés complètes. Par exemple, Talend (intégration de données) s’est rapproché de JasperSoft (solution de reporting) pour bâtir une plateforme BI complète.
Idem, rapprochement de Talend avec eXo (portail) et SpagoBI (solution de reporting) au sein de la Business Intiative OW2 (successeur du consortium ObjectWeb) pour difuser une suite BI open source.
On peut également noter qu’autour de ces problématiques sur l’interopérabilité entre les applications OSS, un consortium nommée l’Open Source Alliance a été constitué le mois dernier (membres fondateurs Talend, JasperSoft, OpenBravo, SourceForge.net, SpikeSource, Adaptive Planning, EnterpriseDB, Centric CRM, CollabNet et Hyperic)

PS : Un projet open source est avant tout un projet et beaucoup d’outils énoncés sont également utilisables dans des projets closed source.