Voyage entre l’open source et le propriétaire : Erwan Loisant, ingénieur logiciel

Erwan fut LE premier à laisser un commentaire sur ce site. j’en profite pour le remercier à nouveau. Cela remonte maintenant à quelques mois. Depuis nous avons continué de nous croiser de temps à autre sur Facebook ou encore son site personnel. Lors de nos premiers échanges Erwan travaillait encore sur le projet Flock, un navigateur social open source basé sur le moteur de Mozilla. Depuis il est rentré en France et a intégré l’équipe de développement de Yonoo une service web dont il nous parle également.

Ayant moi-même fait du développement de logiciels propriétaires pendant pas mal d’année  (Horreur ! crie la foule), je l’ai questionné sur son activité pour en savoir un peu plus sur la vie d’un projet open source comme Flock vu de l’intérieur et connaître ses premières impressions sur Yonoo.

Erwan LoisantErwan, peux-tu nous dire quelle est ta formation ?
Erwan Loisant : Je suis diplômé d’une école d’ingénieur française, assorti d’un doctorat en co-tutelle entre la France et le Japon. J’ai fait mon doctorat principalement à Tokyo.

Avant même cette formation académique, comme beaucoup de développeurs j’ai commencé la programmation sur mon temps libre depuis mon plus jeune age. Lorsque j’étais lycéen, j’ai découvert Linux et à travers cela les logiciels libres. J’ai tout de suite accroché à l’esprit de partage, d’apprentissage continuel et de quête d’excellence technique.

Comment as-tu intégré l’équipe de développement de Flock ?
E.L. : Après mon doctorat, j’étais un peu frustré d’avoir dû me contenter de prototypes pendant ma thèse. J’avais développé une extension Firefox intégrant un dictionnaire de Japonais pour étrangers débutants, qui a eu un petit succès parmi les japonophones. Rien n’était plus satisfaisant que les remerciements d’utilisateurs, j’ai donc eu envie de laisser de côté ma carrière académique pour un temps et rejoindre une entreprise ou je pouvais développer un vrai produit, pour des utilisateurs finaux.

Flock était une jeune startup (environ 6 mois d’existence), qui a sorti sa première version publique (la 0.4) juste au moment ou je terminais ma thèse. Ils avaient levés des fonds à ce moment là et recrutaient activement des ingénieurs. Pour moi (encore au Japon) c’était vraiment une entreprise intéressante : le produit est un logiciel libre, basé sur les technologies Mozilla qui me plaisent beaucoup, et l’occasion de découvrir la Silicon Valley… Après un entretien par téléphone on s’est mis d’accord, on a commencé le processus de visa, et quelques mois plus tard j’atterrissais en Californie.

Quel était ton rôle ?
FlockE.L. : Mon titre était “Ingénieur Logiciel Senior”. Flock a toujours eu une structure assez plate, ce qui signifie que les ingénieurs sont très autonomes. On est amenés à discuter des fonctionnalités qu’on veut mettre dans la version suivante, se faire aider des collègues de marketing ou graphistes pour finalement implémenter ces fonctionnalités. En ce qui me concerne, j’avais la charge du module de blog, du web clipboard et du système de favoris.

J’ai aussi été en charge de la communauté des développeurs, d’un côté pour m’assurer que Flock est facile à étendre, et d’un autre côté pour répondre aux questions techniques qu’ils peuvent avoir. Par exemple j’ai ajouté le support des flux Media RSS à la barre multimédia pour qu’il soit plus facile à un webmestre de rendre son site compatible avec celle-ci.

Entre la version 0.7 et la version 0.9 (la version 0.8 était particulière), j’ai été parmi ceux qui, avec Jesse Andrews et Chris Campbell, ont redéfini l’architecture de Flock qui est restée la même jusqu’à ce jour.

Comment est organisé le développement de Flock ?
E.L. : Il a évolué au cours des années, pour devenir plus structuré qu’il ne l’était au départ, et aujourd’hui il est assez proche de celui de Mozilla Firefox.

Il y a d’abord une phase ou on décide des fonctionnalités à ajouter, puis le développement lui-même est basé sur Bugzilla. Chaque patch doit être attaché à un bug sur bugzilla, être revu par un ingénieur qui connaît bien le module en question puis approuvé par un ingénieur en charge de la version en question. C’est un processus assez lourd mais qui permet d’avoir du code de bonne qualité, et très peu de régressions. Quand une nouvelle version approche, les ingénieurs de QA font subir des tests pour s’assurer que tout fonctionne bien, et c’est à la fin de ce cycle de régression que la nouvelle version est considérée prête.

“Un autre facteur de qualité pour les logiciels Open Source, qui cette fois-ci leur est réservé, c’est la modularité qui permet de faire jouer la concurrence entre plusieurs groupes à un niveau plus fin que le niveau “application”.”

Avais-tu participé à des développements de logiciels “classiques”, as-tu vu une différence ?
E.L. : J’ai participé à des développements de logiciels propriétaires, ainsi qu’à d’autres projets Open Source. Il y avait de grandes différences dans les modes de développement, mais pas forcément divisé entre projets Open Source et projets propriétaires. Certains projets Open Source peuvent avoir un modèle de développement traditionnel, avec une équipe restreinte et un planning strict, tandis que des projets propriétaires peuvent avoir un modèle de développement agile, avec des cycles très courts.

Penses-tu que le développement open source permette d’obtenir des logiciels de meilleures qualité ? Si oui peux- tu nous donner les principales raisons ?
E.L. : Je pense qu’il faut garder à l’esprit que le terme Open Source s’applique avant tout à une licence, c’est-à-dire les termes selon lesquels un logiciel est distribué. Le modèle de développement n’est pas forcément lié à la licence. Cependant, il est vrai que les logiciels Open Source ont apporté des idées qui peuvent beaucoup contribuer à la qualité d’un logiciel. Des idées telles qu’être à l’écoute de sa communauté, communiquer, sortir des versions bêta souvent, d’avoir un gestionnaire de bug publique… Cependant, ces concepts ne sont pas réservés aux logiciels libres. Même Microsoft est descendu de sa tour d’ivoire et applique ces principes pour Internet Explorer par exemple. Certains logiciels Open Source peuvent au contraire avoir un développement fermé et secret jusqu’à la date de sortie, et au final ressembler à un projet propriétaire malgré leur licence.

Un autre facteur de qualité pour les logiciels Open Source, qui cette fois-ci leur est réservé, c’est la modularité qui permet de faire jouer la concurrence entre plusieurs groupes à un niveau plus fin que le niveau “application”. C’est quelque chose qu’on peut voir très clairement pour le noyau Linux par exemple : plusieurs groupes ont développé des schedulers, chaque distribution Linux peut choisir le scheduler qu’elle préfère et au final celui qui est techniquement supérieur gagne, les autres ayant tendance à disparaître par désintérêt des acteurs impliqués. Le gagnant devient inclut par défaut dans le noyau de Linus Torvalds. On peut voir ça aussi dans le projet Firefox : les meilleures extensions peuvent être amenées à être incluses dans le navigateur lui-même, comme ça a été le cas pour le correcteur d’orthographe Spellbound. Un logiciel propriétaire peut être modulaire, mais les licences impliquées ne permettent généralement pas à l’éditeur d’adopter une extension pour l’intégrer au core du produit.

yoonoTu reviens en France et tu vas travailler pour Yoono, un extension “sociale” de Firefox. Tu peux nous en dire un peu plus sur ce projet ?
E.L. : En effet, après 3 ans aux États-Unis et un total de 7 ans à habiter hors de France, j’ai décidé pour des raisons principalement familiales de retourner dans mon pays natal ! Je dois dire que j’aime beaucoup la Californie du Nord. C’est en quelques sorte un paradis pour les geeks, où le ciel est toujours bleu et la nourriture mexicaine toujours à portée de main. Je suis très content d’avoir trouvé Yoono, qui est une startup parisienne avec une antenne à San Francisco. Rester dans le monde du web 2.0 avec des collègues en Californie va probablement adoucir le choc culturel qui touche beaucoup d’expatriés de retour au pays :) .

Yoono est effectivement une extension Firefox, mais il existe une version pour IE. C’est une barre latérale qui comporte plusieurs widgets, dont un widget social qui se connecte aux sites comme Facebook et Twitter, et un widget de “découverte” qui propose des contenus similaires au site visité. C’est téléchargeable gratuitement sur yoono.com.

Les buts des projets Yoono et Flock semblent similaires, disposez en seul lieu de l’ensemble de ces comptes. L’approche de ces deux projets est différentes. L’une visant à créer un “navigateur social”, l’autre à ajouter ces fonctions à Firefox sous la forme d’un extension couplée au site web de Yoono. Deux stratégies bien différentes. Une de ces deux stratégies te semblent-elles plus pertinente sur le plan technique ?
E.L. : Bien que les approches semblent très différentes, sur le plan technique c’est en fin de compte assez similaire. Flock est développé quasiment comme un ensemble d’extensions Firefox, mais est distribué sous forme de navigateur web. Il y a quelques modifications au code de Firefox mais on a toujours cherché à minimiser cela pour s’assurer qu’on peut facilement mettre à jour la version de Firefox incluse. C’est pour cela que d’un point de vue technique, Flock comme Yoono sont développés en Javascript, en étendant les fonctionnalités de Firefox en y ajoutant des boutons supplémentaires permettant d’accéder à des barre latérales ou autres fenêtres. Toujours d’un point de vue technique, l’approche de Flock apporte des avantages mais cela a un coût.

Erwan @ workParmi les avantages, Flock a la possibilité d’intégrer des patchs ou modifications que Mozilla peut mettre plus longtemps à intégrer à Firefox. Inversement, Flock peut renverser des changements qui posent problème. Tout cela n’est pas possible avec une extension. Pour finir, Flock n’a pas à supporter de multiples versions du navigateur puisqu’on sait sur quelle version de Firefox une version de Flock est basée. Ces avantages ont un coût technique : Flock doit avoir ses propres serveurs de mise à jour, et suivre l’actualité de Mozilla pour s’assurer que les utilisateurs de Flock ont toujours les derniers patchs de sécurité. De plus, la compilation de Flock inclut la compilation de Firefox, et Flock doit avoir ses serveurs de compilation pour cela. Cela engendre des coûts financiers (louer des machines) et des coûts humain (les administrer).

Cependant, je pense que les avantages comme les coûts sont négligeables par rapport à l’aspect marketing : pour les utilisateurs un navigateur complet ou une extension sont des produits très différents. C’est donc avant tout sur des critères marketing et non techniques que doit se faire un tel choix.

Ensuite, ta question évoque le service web de Yoono. C’est quelque chose d’indépendant de la question navigateur/extension mais c’est intéressant que tu en parles : Il y a souvent eu à Flock des discussions sur l’intérêt d’avoir un service web, mais au moment où j’ai quitté Flock il n’y avait pas de projet concret sur la question.

Avoir un service web apporte beaucoup, il y a de nombreuses fonctionnalités qui impossibles à implémenter sans : par exemple la synchronisation des données entre plusieurs machines. De plus, un service web permet de créer un effet de réseau ainsi qu’une présence vivante sur la toile pour les non-utilisateurs du service, qui peut beaucoup aider pour l’adoption. C’est cette viralité qui a permis à des services comme Facebook ou Twitter de voir leur base d’utilisateurs augmenter de façon exponentielle, et pour ce dernier atteindre une masse critique en seulement quelques mois.

Par contre, ici encore il y a un coût qu’il ne faut pas perdre de vue. Dans le cas d’une solution purement client comme Flock, le nombre d’utilisateur n’augmente pas les dépenses. Plus il y a d’utilisateurs plus les revenus augmentent, tandis que les dépenses restent relativement constantes : l’équation est simple. Avec un service web on introduit un coût par utilisateur. Plus il y a d’utilisateurs, plus on va avoir besoin de serveurs. De plus, il faut s’assurer que le système est architecturé pour tenir la montée en charge. Ce sont bien entendu des problèmes que l’on peut résoudre (et je pense personnellement que le jeu en vaut la chandelle), mais il faut savoir à quoi s’attendre.

Merci Erwan pour le temps consacré à répondre à ces questions :) .

Billets similaires :


Article original écrit par Philippe Scoffoni le 26/02/2009. | Lien direct vers cet article | © Philippe.Scoffoni.Net - 2009

Cet article est mise à disposition sous un contrat Creative Commons.
Creative Commons License HADOPI - Le Net en France : black-out

Feed enhanced by Better Feed from Ozh

Vus : 284
Publié par Philippe Scoffoni : 544