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.
14 réactions
1 De glandium - 08/04/2010, 10:47
> Comm-central est le référentiel Mercurial de code pour les projets Thunderbird 3.0 et SeaMonkey 2.0.
3.1 et 2.1, en fait.
2 De BlinkT - 08/04/2010, 11:15
grâce à cette interview, j'ai appris beaucoup de choses sur le fonctionnement de Mozilla et du logiciel libre et c'est ça que j'aime avec le standblog
j'espère que les deux projets pourront fusionner mais je n'y crois pas du tout au vu du passé
3 De Sebastien - 08/04/2010, 13:09
J'ai utilisé NVU puis Kompozer dont je suis très content.
Je n'ai jamais aimé l'attitude de Daniel Glazman qui dénigrait Kompozer :
http://www.glazman.org/weblog/dotcl...
http://www.glazman.org/weblog/dotcl...
Et je suis content que ton travail soit reconnu.
4 De gaara - 08/04/2010, 13:44
Fabien Cazenave, il a un lien de parenté avec la permanente de l'April Alix Cazenave ??
5 De Fakir Séditieux - 08/04/2010, 16:06
> Si Daniel voulait...
>
Après avoir lancé le débat Blue Griffon/Kompozer par Stanblog interposéTristan n'a plus qu'à inviter au resto Daniel Glazman et Fabien Cazenave pour lancer la discution
6 De cameleon - 08/04/2010, 16:43
C'est clair que les 2 projets sont très complémentaires, avec d'un coté une forte communauté et de l'autre un projet dynamique animé par un (des?) développeurs payés. Il serait dommage que les 2 s'affrontent stérilement, il y a tout a gagner à un rapprochement. Cela n'a pas pu être fait dans le passé, espéreront que cela marchera mieux cette fois-ci!
7 De Kazé (Fabien Cazenave) - 08/04/2010, 17:11
@BlinkT: le passé je m’en bats les noix. On n’est pas si nombreux que ça à pouvoir contribuer à cet éditeur, j’espère donc pouvoir trouver un modus operandi avec Daniel qui permettrait de faire progresser l’éditeur Mozilla (= celui du dépôt comm-central) en factorisant un maximum de code entre les différents projets qui l’utilisent. Le reste m’importe peu.
@gaara: Alix est ma sœur. La nerditude est une affaire de famille.
8 De Pascal Chevrel - 08/04/2010, 17:30
@gaara
>Fabien Cazenave, il a un lien de parenté avec la permanente de l'April Alix Cazenave ??
C'est sa petite sœur et pour la petite histoire, c'est Fabien qui lui a fait découvrir le logiciel libre
9 De Daniel Glazman - 08/04/2010, 19:20
Entre le commentaire de Tristan sur le blog de Kazé, cet article et la réponse de Kazé à mon commentaire, je me demande si je ne suis pas tombé dans une faille spatio-temporelle ou quoi...
Eh oh les gars... On parle bien de Thunderbird le client de messagerie là ? Donc un outil dans lequel on fait rarement du dynamisme parce que pour des raisons de sécurité on coupe le JavaScript dans les messages ? Où on va éviter de faire des petits miquets qui dansent en CSS 3 Animations parce que les autres agents de messagerie sont TRES loin derrière les navigateurs en termes de support des standards (j'ai géré un workshop W3C sur HTML in Email, merci) et que faire du mail tout seul n'est pas très utile ? Bref, où toutes les choses cools de BlueGriffon n'auront aucun intérêt ?
On parle bien de Seamonkey, la suite successeur de la Netscape Suite, un modèle unifié dont TOUS les retours usagers nous parlaient de la lourdeur en mémoire et en download, les problèmes de crash unifié, et tant d'autres choses que Hyatt et Blake ont fini par imaginer m/b devenu Firefox ? On parle bien d'une suite Web qui reste quasiment inconnue du grand public et n'est utilisée que par des initiés (sans préjuger de leur nombre) et quelques rares entreprises souhaitant conserver une Suite unique ? Et je dis ça sans dénigrer le superbe et colossal boulot de KaiRo qui est un vieux collègue qui a réussi l'exploit de non seulement faire revivre Seamonkey pour ses aficionados mais même en vivre financièrement. Chapeau très bas et je suis très sérieux. Mais il reste que Seamonkey est une petite niche. Ce n'est ni insultant, ni dénigrant, c'est factuel.
Pour finir, "bugfix" ça n'est pas péjoratif en tous cas pas mon métier. Un bugfix ça peut être un travail ENORME et ça peut être fondamental pour qu'un produit soit utilisable. Quand Pierre Saslawsky a bossé six mois sur le style engine touchant presque tout pour grapiller des pourcents de performance, c'était du bugfix ; et c'était pourtant colossal et nécessaire. Un bugfix, c'est une stabilisation qui peut impliquer un revamp complet de code mais n'implique pas de grand changement fonctionnel du point de vue de l'usager. Le "support" CSS 3 ou HTML5 de Kompozer vient directement de la mise à jour du runtime de Gecko, pas du code de l'outil lui-même, nous sommes bien d'accord je suppose. La principale fonctionnalité nouvelle de Kompozer est la vue dite mixte.
Le code ? Il se décompose en deux parties : ce qui est l'appli elle-même et ce qui relève du noyau et de la toolkit. Le code de l'appli, il est là. Et il est tellement peu éloigné de mon code d'origine ou même des noms de fichiers d'origine que je m'y suis retrouvé en 3 secondes. Le diff sur un des plus gros fichiers, editor.js, fait 1820 lignes. Soit donc environ 700 lignes touchées. Sur ces 700, et en lisant TRES attentivement ligne par ligne le diff -u, il y a au plus 300 lignes de véritable debug. Sur 4150 lignes pour editor.js. Voila. Je peux faire la même chose avec la plupart du code sauf bien sûr le gestionnaire FTP dont la couche réseau a été revampée et quelques autres bouts de code.
Pour le reste, Kazé et moi-même allons en dicuster plus directement que par blogs interposés.
10 De Jmini - 08/04/2010, 20:56
Au début de l'interview je me disais que le meilleur gagne... Et puis c'est vrai que dans le monde du libre, il vaut mieux ne pas diviser les forces...
En même temps quand je l'avais testé NVU (ou Kompozer 0.7), je me suis rendu compte que ce n'était pas un outil pour moi. Je tape mon HTML a la main (dans un bon éditeur comme TextMate, propriétaire certes mais génial) ou je converti du Markdown en HTML... Pour le CSS, j'adore CSSEdit (propriétaire aussi)...
Mais il faut quelque chose de plus simple pour monsieur tout le monde.
- -
Au delà de l'affrontement de ces deux logiciels, ce qui est certain, c'est que l'avenir de l'HTML 5 passe par un éditeur puissant, capable de faire des présentations évoluée (diaporamas, présentations interactives, graphiques dynamique...). Je ne sais pas dans quel mesure Kompozer ou BlueGriffon sont/seront capable de faire des choses comme cela (peut être à travers des plugins ? parce qu'il me semble que Kompozer est particulièrement destiné à du texte). En tout cas un tel outil manque.
Source qui m'a donné l'idée : l'abandon de Flash ne va pas de soi
11 De pirlouy - 08/04/2010, 22:42
Ouais, et les 2 sont aussi irrécupérables l'un que l'autre. :-P
12 De Kazé (Fabien Cazenave) - 09/04/2010, 14:16
@Daniel
Aucune importance si Thunderbird n’utilise pas de CSS3, ou si SeaMonkey n’est plus très utilisé ; ce qui compte, c’est qu’il y a déjà sur comm-central un code pour l’éditeur HTML qui est maintenu par la communauté Mozilla.
Si Nvu avait été sur comm-central, il serait actuellement en version 2.x, il supporterait HTML5 et CSS3 et Kompozer n’aurait jamais existé. On peut même raisonnablement supposer que Nvu disposerait aujoud’hui d’un bon catalogue d’extensions.
13 De Kazé - 09/04/2010, 14:42
@Jmini
Je te rejoins à 100% sur le fait qu’en 2010, un éditeur HTML wysiwyg est bien plus utile pour l’édition de contenu (présentation, documentation, etc.) qu’au développement web. J’utilise Composer depuis 2000 pour mes besoins de documentation (avec des moulinettes html2pdf), et la plupart des contributeurs réguliers de Kompozer l’utilisent en ce sens. Je suis convaincu du fait que c’est là l’avenir des éditeurs HTML.
Pour éditer un site web, sorti de la phase d’apprentissage un éditeur HTML wysiwyg ne sert pas à grand-chose, d’autant que la plupart des utilisateurs trouveront plus simple de publier leur contenu sur MySpace, FaceBook ou un CMS. Évidemment, il m’arrive de faire des maquettes de sites web en wysiwyg (surtout pour profiter de l’éditeur CSS en fait), mais dès qu’il faut rentrer dans les détails je passe à Vim.
Pour moi, la seule voie intéressante pour un éditeur HTML wysiwyg orienté développement web serait de le baser sur Komodo, qui est de très loin le meilleur éditeur de code basé sur des technos Mozilla, et qui dispose déjà d’une bonne communauté. J’en avais parlé à ActiveState avant de commencer le développement de la branche 0.8 de Kompozer, ils étaient intéressés mais n’avaient pas de budget à mettre en face de mon travail…
14 De Fakir Séditieux - 10/04/2010, 00:56
Au delà de la technique c'est une des discussions les plus intéressantes que j'ai jamais suivi sur un blog.
Je suis sérieux : les échanges entre Kazé et Daniel sont, a mes yeux, des plus passionnants. Chacun expose sa façon de concevoir, produire et améliorer un logiciel. Il ne s'agit pas d'un simple débat sur les différentes approches du libre comme on le voit/lit souvent, ou l'approche entre 2 modèles de production qui rend cet article interressant, mais c'est leur façon d'aborder les problèmes et les solutions qui vont avec afin que l'Internet de demain soit encore plus accessible.
@daniel Glazman
On s'est essuyé les pieds sur Netscape et Mozilla Suite avec grande jubilation par le passé. Mais était-ce bien justifié ? Certes le passage d'une suite à un simple navigateur, Firefox, a non seulement sauvé Mozilla mais aussi remis en avant la notion de standards libres et ouverts conditions indispensables pour avoir un Internet libre de tout monopole 'privatif'.
Cela étant je me demande si Firefox au vu de la listes des plug-ins ne redevient pas d'une façon déguisée une suite logicielle internet ?
De simples navigateurs il y en a un certains nombre tel Galeon, Epiphany ou Midori. Et certains sont même plus rapides que les plus rapides
Firefox et Opera ne jouent plus dans cette seule catégorie. Ils se positionnent quelque part entre les simples navigateurs et les suites comme Seamonkey. Le génial coup de marketing de la MoFo a ringardisé les suites sans nul doute. Si Netscape Suite et son évolution chez Mozilla étaient lourdingues, buggés à mort - mais pas plus que le IE de l'époque - est ce une raison suffisante pour leur dénier une utilité dans le futur ? Un Seamonkey basé sur Firefox + ThunderBird + Sunbird + un éditeur ++ est il réellement un contresens ? Je n'en suis pas convaincu surtout quand je vois des Gmail qui font du Buzz ou des interfaces comme Google Wave. Vois pas pourquoi ce qui bon pour l'un - la multiplication des fonctionnalités et des protocoles - ne l'est pas pour les autres...