Tristan : Bonjour Fabien, tu peux te présenter rapidement ?

Fabien Cazenave : Bonjour Tristan. Je travaille comme développeur depuis 15 ans, j’ai commencé dans l’instrumentation virtuelle avant de plonger dans les joies des technologies Mozilla en 2005. Kompozer représente l’essentiel de ma contribution au projet Mozilla.

Tristan : Parle-nous de Kompozer : dans un récent entretien, Daniel Glazman le définit comme étant une version de maintenance du projet NVU dont il est l'initiateur mais qu'il a abandonné il y a 5 ans, faute de financement. J'ai bien conscience que c'est bien plus que ça... Tu peux nous en dire plus ?

Fabien Cazenave : Kompozer 0.7 était effectivement une version de maintenance de Nvu 1.0. À l’époque j’étais modérateur sur le forum de support Nvu de Geckozone, et j’ai fini par me dire que ça serait plus simple de corriger les bugs les plus souvent rapportés plutôt que de répondre encore et toujours les mêmes choses. Malheureusement, et à ma grande surprise, cette proposition de bugfix n’a pas été reprise par Linspire et/ou Daniel.

De ce constat, on en a conclu qu’il ne suffisait pas de proposer des patches, mais qu’il fallait animer un projet complet… chose qu’on a commencé à faire à la suite de l’EuMozCamp de Barcelone. On est donc repartis d’un noyau Gecko « propre », et on a cherché à ré-implémenter les fonctionnalités de Nvu en XUL/JavaScript plutôt qu’en maltraitant le noyau Gecko…

L’expérience sur les forums de support nous a conduits à implémenter des nouvelles fonctionnalités qui sont intéressantes pour la productivité mais qui ont un but essentiellement didactique : là où Nvu cherchait à masquer la complexité du HTML / CSS à l’utilisateur, Kompozer 0.8 *propose* en plus à l’utilisateur des outils pour comprendre la syntaxe HTML, l’arbre DOM, les sélecteurs CSS, etc.

Tristan : donc il n'est pas exact de dire que Kompozer, c'est NVU à 99% ?

Fabien Cazenave : C’est effectivement inexact et un poil agaçant. ;-)

Les utilisateurs peuvent s’en rendre compte avec les fonctionnalités et l’interface utilisateur. Les développeurs remarqueront que sous le capot, Kompozer 0.8 est plus proche de SeaMonkey Composer que de Nvu. Quant à la version 0.9 qui est en gestation, elle est développée en collaboration directe avec l’équipe SeaMonkey et il n’y a plus que quelques rares traces de code Nvu.

Tristan : Daniel Glazman affirme "Il faut refondre totalement l'architecture du produit, pour utiliser des modules JSM augmentant drastiquement l'extensibilité du produit." Finalement, tu est en train de me dire qu'elle a déjà eu lieu, sur la base de SeaMonkey Composer ?

Fabien Cazenave : Oui et non. Kompozer 0.9 utilise une base SeaMonkey Composer « pure » afin de factoriser les efforts de développement entre les deux projets. On a donc d’ores et déjà tous les bénéfices du noyau Gecko 1.9.3 : HTML5, CSS3, performances JS, etc. Pour améliorer l’extensibilité, on réfléchit essentiellement à nous rapprocher techniquement des extensions Firefox. Ça passera par une barre latérale type "xSidebar" et quelques ajustements internes. Vu le nombre d’extensions Firefox qui sont orientées développement web, c’est clairement la priorité pour avoir rapidement des extensions intéressantes.

Par contre, il n’est pas question pour nous de ré-écrire le code d’une interface dont le fonctionnement a été débuggé au fur et à mesure de l’évolution de SeaMonkey et Thunderbird. Je reconnais que ça peut être tentant intellectuellement, que le code serait bien plus agréable à lire, mais notre opinion sur la question est qu’il nous faut avant tout de la stabilité et de la pérennité sur l’ensemble du projet si on veut attirer les développements d’extensions. A l'inverse, BlueGriffon s'oriente vers la ré-écriture du code de l'interface utilisateur.

Tristan : Donc tu t'orientes vers une approche où tu suis Firefox et SeaMonkey, de façon à bénéficier au maximum du travail déjà effectué sur ces projets qui sont bien staffés. C'est ça ?

Fabien Cazenave : Exactement. Dans un premier temps ça profitera avant tout à SeaMonkey Composer, mais à moyen terme ça donnera à Kompozer une bien meilleure stabilité que ce qu’une équipe isolée peut faire seule.

Tristan : Alors avec BlueGriffon qui arrive avec un développeur payé à temps plein, comment vois-tu l'avenir de Kompozer ?

Fabien Cazenave : Si le développement de BlueGriffon était articulé autour de la base de code Mozilla existante, je serais ravi d’abandonner Kompozer et de contribuer à BlueGriffon. Si, par contre, BlueGriffon est un nouveau fork du code Composer, fatalement ça va complètement à l’encontre de ce que j’essaye de faire avec Kompozer 0.8 et 0.9, à savoir centraliser le développement de l’éditeur sur comm-central[1].

Tristan : NVU a fini par s'arrêter tout seul une fois la version 1.0 achevée. Tu ne penses pas qu'il pourrait arriver la même chose à BlueGriffon ?

Fabien Cazenave : C’est effectivement ce qu’il faut craindre. Tout dépendra de l’activité économique que Daniel arrivera à générer avec les extensions.

Tristan : Finalement, ce sont deux modèles qui s'affrontent : d'un coté une communauté qui développe du logiciel Libre de façon bénévole, de l'autre une entreprise qui développe un modèle "freemium” avec du propriétaire sur une base Libre, pour rassurer ses investisseurs. Ne pourrait-on pas envisager une solution hybride, avec un appui aussi large que possible sur une communauté ? En effet, il existe déjà une communauté Kompozer...

Fabien Cazenave : les deux modèles ont leurs avantages et sont complémentaires. Eclipse fait un heureux mélange de libre et de proprio dont personne ne se plaint, parce qu’il y a une grosse communauté derrière et que le noyau a démontré sa longévité. La communauté Kompozer n’est certes pas comparable à celle d’Eclipse mais elle a l’avantage d’exister depuis 2006, avec les forums de support, les testeurs, les équipes de loca (Kompozer a deux fois plus de locales que Nvu), les développeurs. J’ai longtemps cru qu’aucun contributeur Mozilla ne voulait bosser sur l’éditeur, et je me rends compte en ce moment que la fusion de Kompozer et de SeaMonkey suscite pas mal d’enthousiasme. Jamais je n’aurais tant d’aide si le code n’était pas destiné à finir dans le tronc Mozilla !

Pour le développement d’extensions aussi, la plate-forme est gratifiante : tout ou presque a déjà été fait en matière d’extensions Firefox, alors que pour Kompozer on peut encore proposer des extensions innovantes. Pour le projet CoMETE (formation Mozilla à Évry), on m’avait demandé de proposer un sujet de travail : j’en ai proposé cinq, et les cinq ont été retenus. Les étudiants qui ont bossé sur ces projets étaient ravis de voir que leurs extensions Kompozer fonctionnaient « out of the box » sur SeaMonkey.

Tristan : Tu crois qu'on pourrait avoir le meilleur des deux mondes ?

Fabien Cazenave : Oui. Le risque d'avoir deux projets d'éditeurs WYSIWYG basés sur Gecko, c'est de diviser les efforts et donc limiter les chances de succès. Si Daniel voulait accepter un compromis et faire du code qui pourrait finir dans comm-central, il gagnerait une communauté motivée (et bénévole), mais en plus l’essentiel de la maintenance de l’application serait effectuée par les contributeurs. Et ça ne remettrait pas en cause son modèle d’extensions payantes, bien au contraire !

Notes

[1] Comm-central est le référentiel Mercurial de code pour les projets Thunderbird 3.0 et SeaMonkey 2.0.