4. Autour de Firefox et de ses dérivés

IDN : En parlant de MacOS X, ce système dispose déjà de Camino (supporté par la fondation Mozilla) et on raconte que Firefox y est moins performant que sous Windows. Que compte faire la fondation à ce propos ?

T.N. : C’est une très bonne question ! Moi, je suis utilisateur de Mac pour ma machine principale. C’est peut être parce que je suis habitué, mais je trouve qu’il fonctionne très bien. Il est vrai qu’il y a une difficulté dans Firefox pour Mac, c’est le fait que Firefox est essentiellement un programme multiplateformes, ce qui signifie que l’interface est quasiment la même sur les trois plateformes. Les interfaces de Windows et Linux se ressemblent un peu, alors que sur un Mac, il y a un menu avec le nom de l’application contenant certaines options contenues normalement dans le menu « fichier » sous Windows, par exemple. Nous sommes donc obligés de faire de choses spéciales pour le Mac. Mais c’est en train de s’améliorer, puisqu’il y a une personne, qui s’appelle Josh Aas, et qui s’occupe à temps plein de l’adaptation de Firefox pour Mac. A l’inverse, on ne fait rien pour Camino, mis à part qu’on lui donne du code, qui doit représenter 95 % du code de Camino, ce qui signifie que sans le vouloir, on fait malgré tout énormément pour ce logiciel. Camino est géré uniquement par des bénévoles, mais quand on fait une amélioration sur Firefox, il y a de très grandes chances qu’elle profite également à Camino. Eux, tout ce qu’ils ont à faire, c’est intégrer ces modifications et tester que ces modification n’abîment pas Camino. L’approche de Camino, elle est de faire un navigateur qui est vraiment fait pour le Mac à la base, alors que Firefox est un navigateur multiplateformes qu’on va ensuite adapter au Mac. Mais ce n’est pas un produit Mozilla, c’est un projet Mozilla. Un produit est quelque chose derrière lequel il y a du marketing et autre, alors qu’un projet est quelque chose mené par des bénévoles sur la base de nos technologies.

IDN : Et pour Flock ?

T.N. : C’est pareil. Je crois qu’environ 90 % du code de Flock vient de chez nous... mais c’est très bien, on fait du logiciel libre, le principe est donc que ce qu’on fait est réutilisable, que ce soit par des gens très proches de nous, comme ceux de Camino (souvent d’anciens contributeurs Mozilla), ou encore par des entreprises qui vont en faire leur navigateur, comme Flock. Mais je connais très bien le CEO de Flock, qui est un ancien de Mozilla, il y a un employé de Flock qui est un responsable de Mozilla Europe... Tout ce qu’on veut, c’est qu’il y ait du choix sur Internet, et que du coup il y ait de l’innovation. Que l’innovation viennent de Camino, de Flock ou de Firefox, peu importe, il y a des gens qui inventent des choses, et ensuite on s’améliore, on partage des choses et des idées, et voilà. On n’est pas du tout dans une optique d’entreprise dans laquelle on va conserver jalousement nos secrets, au contraire, on est dans une optique de partage. Plus il y a de navigateur utilisant le moteur Gecko sur le marché, plus le public que nous touchons est large. Sur Mac, si vous voulez un navigateur tout simple et très orienté Mac, vous pouvez prendre Camino ou Safari, et si vous voulez un navigateur avec des extensions et une énorme communauté derrière qui va créer ces extensions, vous utilisez Firefox.

IDN : Certaines fonctions se seraient vues retirées de Firefox 2.0 pour n’être disponibles que plus tard, qu’en est-il à l’heure actuelle ?

T.N. : Ce n’est pas facile... On pourrait voir la chose comme vous le dites, mais quand on se décide à faire une nouvelle version, on reçoit énormément d’idées pour des changements, qu’ils soient très visibles sur l’interface ou à l’intérieur du moteur. Chacun vient avec ses idées et une estimation du temps de réalisation, et on décide à partir de cela de la date de sortie approximative de la nouvelle version. Mais il arrive parfois que la mise en place de certaines fonctions prenne plus de temps que prévu. À ce moment là, on se dit que ce n’est pas grave et que la fonction ne sera pas prête dans les temps, mais sera là dans la version suivante. On ne va pas retarder la sortie du logiciel uniquement pour rajouter quelque chose, puisque ça voudrait dire qu’au final on peut encore se permettre de rajouter encore d’autres choses, pour prendre le risque de retarder à nouveau... et au final on ne sort jamais rien ! Si vraiment on attend d’avoir exactement ce qu’on avait au plan de départ, il y a toujours un paramètre qui saute, et dans ce cas là, ça va être la date, c’est à dire qu’on va livrer avec deux ans de retard. Il vaut donc mieux rester raisonnablement dans les temps, sachant qu’on n’est jamais vraiment dans les temps : regardez Vista, au tout début, il devait sortir en 2003 (rires). Mais pour leur défense, c’est quand même un très gros projet, et eux aussi ont été obligés de se séparer de beaucoup de fonctionnalités (dont WinFS, ndr), donc c’est une loi universelle dans le monde du logiciel. Donc ici, la fonction est juste écartée du projet pour ne pas le retarder, et elle prendra le prochain train.

IDN : En effet, il vaut mieux sortir une fonction quand elle est prête plutôt que de faire les choses trop vite pour réparer après...

T.N. : Oui, j’ai connu les derniers jours de Netscape quand j’y étais, j’ai vu ce que c’était que de sortir du code pas fini et de le jeter en pâture aux utilisateurs alors que les développeurs ne le voulaient pas, et c’est très douloureux... quand vous voyez votre code, que vous savez qu’il n’est pas fini, et que le patron veut le sortir quand même, ça ennuie tout le monde et personne n’est content, ce n’est pas la solution.