J'ai trouvé le texte intéressant, bien qu'il y ai à répondre et trouve donc bête de ne parler que des accents. Donc, hop, 5 minutes et voici une version accentuée, cédillée et typographiée à peu-près correctement :
Ce journal a vocation à être le premier d'une série ou j'essaierai de faire partager ce que j'ai appris, en particulier mais pas seulement depuis que je travaille chez Mozilla, sur ce qui fait le succès ou l’échec d'un logiciel libre en particulier, ou du logiciel libre en général dans un domaine donné.
Le sujet du jour est la tendance qu'ont beaucoup de libristes à sous-estimer leur compétition propriétaire sur le plan technique. Je veux vous convaincre de deux choses: que c'est une erreur souvent commise dans les cercles libristes, et que c'est une erreur grave, qui peut priver un projet de ce qui lui permettrait de rester ou de devenir compétitif.
C'est une erreur souvent commise, mais le plus souvent dissimulée sous différentes formes. La plus courante consiste à vouloir trouver des raisons non-techniques à la supériorité d'un compétiteur, alors que cette supériorité s'explique très bien par des raisons simplement techniques. Ici, on retrouve le schéma du rasoir d'Ockham : les hypothèses les plus simples sont les plus vraisemblables.
Quelques exemples :
- Si un périphérique ne fonctionne pas sous Linux, on va naturellement accuser le manque d'effort du fabriquant concernant Linux, alors que ça peut très bien être un vrai bug du noyau. Ça m'est arrivé il y a quelques années avec un DAC USB qui ne marchait pas a cause d'un bug dans l'ordonnanceur par défaut.
- Si LibreOffice peine a obtenir des parts de marche face à MS Office, on va trop vite accuser la position dominante de Microsoft en oubliant que LibreOffice n'est pas uniformément meilleure que MS Office à tous points de vue, même en excluant les filtres d'import/export MS Office.
- Si une page Web ne marche pas aussi bien sous Linux que sous Windows, on va immédiatement accuser le Webmestre de ne pas avoir testé alors que dans bien des cas, cela reflète simplement la meilleure qualité des navigateurs sous Windows ; et pour expliquer ça, on va immédiatement accuser les fabricants de navigateurs de trop privilégier Windows ou Mac OSX et de négliger Linux, ce qui contient parfois une dose de vérité, mais dans la plupart des cas la meilleure explication est à chercher dans la qualité et l’uniformité de la pile logicielle sous Windows et Mac OSX. Un exemple: pour faire du rendu 2D rapide utilisant le GPU, on peut utiliser Direct2D sous Windows et CoreGraphics sous Mac OSX, mais sous Linux, on a le choix entre un grand nombre de solutions toutes inférieures : XRender, OpenVG, Cairo/GL, Qt/GL… seul le nouveau Skia/GL offre une lueur d'espoir mais n'est pas encore aussi rapide que Direct2D.
Avant de rejoindre Mozilla, j'avais tous ces réflexes de mépris pour la compétition propriétaire. Je me suis fait reprendre tout de suite. Quand on tourne moins bien que la compétition, il n'y a pas de « mais eux ils sont préinstallés sur l'OS » qui tienne. Il faut comprendre d’où viennent nos problèmes et comment fait la compétition propriétaire, quitte à utiliser des outils d’ingénierie inversé. Sur un certain OS propriétaire ou seul le navigateur préinstallé donnait une bonne durée de batterie, on a utilise des outils de traçage d’entrées/sorties pour comprendre ce qu'ils faisaient. Il n'y a pas de magie, tout peut être compris. Il peut arriver qu'un logiciel propriétaire tire une supériorité de facteurs non-techniques, mais avant de le prétendre, il faut le prouver.
Une variante de ce conseil est de dire : écoutez vos utilisateurs, ils ne se plaignent pas pour rien, toutes leurs récriminations ne peuvent pas forcement se ramener à la différence avec Windows auquel ils seraient habitues. Par exemple, si les utilisateurs se plaignent de la mauvaise qualité des fontes dans un PDF, peut-être que c'est un simple bug dans FreeType, ou dans la gestion de l'Unicode, ou dans l'afficheur de PDFs, ou dans la fonte elle-même, et non pas le résultat d'un complot anti-libre a base de brevets.
En résumé :
- à chaque fois qu'un compétiteur marche mieux, la première hypothèse de travail doit être que c'est un bug chez nous.
- il est presque toujours possible de comprendre le bug, de comprendre ce que le compétiteur fait différemment, et de corriger le problème.
# Un bon texte, c'est bien, avec accent, c'est mieux !
Posté par Gabbro . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à 10.
J'ai trouvé le texte intéressant, bien qu'il y ai à répondre et trouve donc bête de ne parler que des accents. Donc, hop, 5 minutes et voici une version accentuée, cédillée et typographiée à peu-près correctement :
Ce journal a vocation à être le premier d'une série ou j'essaierai de faire partager ce que j'ai appris, en particulier mais pas seulement depuis que je travaille chez Mozilla, sur ce qui fait le succès ou l’échec d'un logiciel libre en particulier, ou du logiciel libre en général dans un domaine donné.
Le sujet du jour est la tendance qu'ont beaucoup de libristes à sous-estimer leur compétition propriétaire sur le plan technique. Je veux vous convaincre de deux choses: que c'est une erreur souvent commise dans les cercles libristes, et que c'est une erreur grave, qui peut priver un projet de ce qui lui permettrait de rester ou de devenir compétitif.
C'est une erreur souvent commise, mais le plus souvent dissimulée sous différentes formes. La plus courante consiste à vouloir trouver des raisons non-techniques à la supériorité d'un compétiteur, alors que cette supériorité s'explique très bien par des raisons simplement techniques. Ici, on retrouve le schéma du rasoir d'Ockham : les hypothèses les plus simples sont les plus vraisemblables.
Quelques exemples :
- Si un périphérique ne fonctionne pas sous Linux, on va naturellement accuser le manque d'effort du fabriquant concernant Linux, alors que ça peut très bien être un vrai bug du noyau. Ça m'est arrivé il y a quelques années avec un DAC USB qui ne marchait pas a cause d'un bug dans l'ordonnanceur par défaut.
- Si LibreOffice peine a obtenir des parts de marche face à MS Office, on va trop vite accuser la position dominante de Microsoft en oubliant que LibreOffice n'est pas uniformément meilleure que MS Office à tous points de vue, même en excluant les filtres d'import/export MS Office.
- Si une page Web ne marche pas aussi bien sous Linux que sous Windows, on va immédiatement accuser le Webmestre de ne pas avoir testé alors que dans bien des cas, cela reflète simplement la meilleure qualité des navigateurs sous Windows ; et pour expliquer ça, on va immédiatement accuser les fabricants de navigateurs de trop privilégier Windows ou Mac OSX et de négliger Linux, ce qui contient parfois une dose de vérité, mais dans la plupart des cas la meilleure explication est à chercher dans la qualité et l’uniformité de la pile logicielle sous Windows et Mac OSX. Un exemple: pour faire du rendu 2D rapide utilisant le GPU, on peut utiliser Direct2D sous Windows et CoreGraphics sous Mac OSX, mais sous Linux, on a le choix entre un grand nombre de solutions toutes inférieures : XRender, OpenVG, Cairo/GL, Qt/GL… seul le nouveau Skia/GL offre une lueur d'espoir mais n'est pas encore aussi rapide que Direct2D.
Avant de rejoindre Mozilla, j'avais tous ces réflexes de mépris pour la compétition propriétaire. Je me suis fait reprendre tout de suite. Quand on tourne moins bien que la compétition, il n'y a pas de « mais eux ils sont préinstallés sur l'OS » qui tienne. Il faut comprendre d’où viennent nos problèmes et comment fait la compétition propriétaire, quitte à utiliser des outils d’ingénierie inversé. Sur un certain OS propriétaire ou seul le navigateur préinstallé donnait une bonne durée de batterie, on a utilise des outils de traçage d’entrées/sorties pour comprendre ce qu'ils faisaient. Il n'y a pas de magie, tout peut être compris. Il peut arriver qu'un logiciel propriétaire tire une supériorité de facteurs non-techniques, mais avant de le prétendre, il faut le prouver.
Une variante de ce conseil est de dire : écoutez vos utilisateurs, ils ne se plaignent pas pour rien, toutes leurs récriminations ne peuvent pas forcement se ramener à la différence avec Windows auquel ils seraient habitues. Par exemple, si les utilisateurs se plaignent de la mauvaise qualité des fontes dans un PDF, peut-être que c'est un simple bug dans FreeType, ou dans la gestion de l'Unicode, ou dans l'afficheur de PDFs, ou dans la fonte elle-même, et non pas le résultat d'un complot anti-libre a base de brevets.
En résumé :
- à chaque fois qu'un compétiteur marche mieux, la première hypothèse de travail doit être que c'est un bug chez nous.
- il est presque toujours possible de comprendre le bug, de comprendre ce que le compétiteur fait différemment, et de corriger le problème.