Standblog

Voici un billet que je n'ai pas le temps de faire, mais mon précedent billet sur la résolution d'une régression CSS dans le prochain Firefox m'y oblige. Dont acte.

Laurent, qui est un homme qui sait appuyer où ça fait mal^[1], balance tout de go :

S'il y a des bugs de rendu CSS dans la version 1.5 qui n'étaient pas dans la 1.0x, cela justifie pleinement la suspension immédiate de tout calendrier justifié par le marketing, non ?

En tant qu'homme de marketing, il va me falloir énoncer des vérités (et dans le marketing, on n'a pas toujours l'habitude

Que les choses soient claires : ça n'est pas le marketing qui détermine le planning de sortie des versions de Firefox (et je sais de quoi je parle, sinon ma vie serait bien plus simple).

Si vous le permettez, je vais d'abord enfoncer quelques portes ouvertes :

De l'infaillibilité du genre humain

Je me permets humblement de rappeler qu'aucun programme, un tant soit peu compliqué, du moins plus que le trivial "Hello World", n'est exempt de bug. D'ailleurs, "Hello World", c'est bugué, puisque ça n'est pas localisable, car pas en UTF-8

Blague à part, Firefox, Opera, Safari, KHTML et les autres, (et même IE7) tendent à respecter le mieux possible les specs, dont le CSS. Tendent. Comme aucun logiciel n'est parfait, on n'arrive jamais à respecter parfaitement la spec. Ceux qui vous disent le contraire sont des menteurs ou des imbéciles, voire tout simplement mal informés (mais ils feraient mieux de pas l'ouvrir, alors ;-).

Par contre, si tous tendent au respect de la norme CSS, certains sont plus en avance que d'autres. Opera et Firefox en font partie. Opera est meilleur que Firefox dans certains domaines, et dans d'autres domaines c'est Firefox qui l'emporte. Pour ce qui est du test Acid 2 (orthogonal à CSS), Safari l'emporte. En 2005, on peut raisonnablement dire qu'IE 6 est une catastrophe en terme de support des standards. En 2001, c'était un vrai progrès. IE7 sera probablement moins mauvais qu'IE6, mais toujours dernier, si j'en crois les infos distillés par l'IEblog et Molly.

Cochonneries de régressions

Enfin, il arrive qu'en corrigeant des bugs, en voulant améliorer la conformité, on provoque involontairement des régressions mineures, dans des cas rares. C'était le cas des marges négatives flottantes utilisées par One True Layout. Dans ce cas précis, c'était génant, car même si c'est très peu utilisé, ça devrait le devenir, si One True Layout tient ses promesses. C'est bien le message qu'on a fait parvenir aux développeurs, et mon billet précédent n'a d'autre objectif de me réjouir qu'avec l'aide de Pascal et d'Eric Meyer, on ait pu influencer les choses dans le bon sens.

Il ne faut toutefois pas voir dans cet épisode une preuve que le logiciel Libre est le meilleur du monde ou autre. Chez Opera, chez Apple, Chez Konqueror, (et même depuis peu chez Microsoft), il y a des gens qui testent les régressions et d'autres qui écoutent les développeurs Web. Mais tous, nous avons à faire à une équipe chargée de livrer le produit.

Y-a-t-il un Driver dans l'avion ?

Chez Mozilla, c'est l'équipe Drivers, qui passe à la loupe tous les rapports des bogues qu'on aimerait voir résolus dans la prochaine version. Et plus la date de sortie désirée approche, plus stricts sont les Drivers dans leurs décisions d'accepter ou refuser un bogue. Parmi leurs critères, on trouve la taille du patch, son impact sur les différents utilisateurs et développeurs, le risque qu'il comporte en terme de stabilité et de performance. Etre Driver, c'est plutôt ingrat. C'est prendre des décisions difficiles qui ne seront pas toutes populaires. Mais c'est un mal nécessaire, sinon le produit ne sort pas tant qu'il n'est pas parfait, et comme il est impossible qu'il le soit, il ne sortira jamais.

Un vieux proverbe Libriste

Il y a un adage très intéressant dans le logiciel Libre : "Release soon, release often". Sortir une version tôt et souvent. Car cela permet de valider la qualité du travail sur des exemples très concrets, d'obtenir du feedback et mieux comprendre ce sur quoi il faut travailler car souvent, la réalité est différente de ce qu'à imaginé le développeur dans son coin. (Par ailleurs, nous sommes conscient que Firefox doit une bonne partie de son succès à sa grande qualité, donc on ne sort pas un produit pourri

Un des intérêts du logiciel Libre, c'est qu'on dispose d'une base de testeurs qui est très vaste, ce qui augmente les chances de trouver un problème *avant* la version finale. Et l'épisode actuel le démontre.

Voici une autre raison pour laquelle on ne peut pas retarder indéfiniment la sortie du produit : on a un planning. Il est certes flexible, mais il faut s'y tenir autant que possible, de façon à ce que chacun puisse planifier son propre travail, insérer des gros changements (gros donc potentiellement dangereux pour la stabilité du produit) au moment où c'est approprié^[2].

Et si on implémentait la spec, rien que la spec, mais toute la spec ?

Mais prenons le cas utopique où aucune date de sortie du logiciel n'est planifiée, où l'efficacité du processus de développement est ignorée car on dispose de ressources infinies (et infiniment patientes) et où seul l'objectif est un respect à 100% de la spécification. Le logiciel ne sortirait jamais. Jamais. Pourquoi ? Pour deux raisons :

1. Parce que tout n'est pas nécessairement implémentable dans la specification, qui est elle aussi une vue de l'esprit abstraction au moment où elle est écrite ;
2. parce que la spécification comprend des zones d'ombres, des points sujets à interprétation.

Conclusion

Viser le respect à 100% des standards est une vue de l'esprit. Il faut indéniablement tendre vers cet objectif. Mais attendre de l'avoir atteint pour sortir le produit est un non-sens.

Il faut donc composer avec la réalité, et ce que fait Drivers, et par la même tout le projet Mozilla. De ce point de vue là, tous les projets de navigateurs sont logés à la même enseigne et tendent vers le respect des standards, avec certes plus ou moins de ferveur^[3].