H'Burg Locomotive ⓒ dsb nola Creative Common Attribution 2.0 Generic
Alias a un billet de blog intéressant sur pourquoi il n’utilise pas Open Office, ce billet étant une réponse à un autre billet intitulé Pourquoi j’utilise les logiciels Open-Source. Les arguments en faveur de l’open source, sont les habituels : gratuité, portabilité, accès au code, les arguments d’Alias concernent surtout l’ergonomie.
Il faut noter que tous les programmes open-source ne sont pas toujours gratuits. Par exemple, j’utilise le système de notification Growl, qui est à présent payant sur l’App Store d’Apple. Ce même système n’a d’ailleurs longtemps pas été portable, n’existant que sous OS X, puis sous Windows. La portabilité est une vertu très relative, quand les gens parlent de logiciel portable, ils veulent généralement dire sur les plateformes majeures, ayant longtemps travaillé avec des stations Suns, je sais que beaucoup de code portable ne l’est pas toujours.
What kind of music do you usually have here?
Oh, we got both kinds. We got country and western.
Un problème avec les logiciels portables qui se comportent de la même manière sur toutes les plateformes, c’est qu’ils n’utilisent en général pas l’idiome de la plateforme où ils s’exécutent, mais leur petit espéranto, généralement le plus petit commun dénominateur de toutes les plateformes cibles, avec en général un délai réactivité rallongé par le niveau d’abstraction indirect additionnel. Je soupçonne que c’est cela qu’Alias appelle la maniabilité soviétique. Je préfère largement les systèmes qui utilisent une infrastructure commune, et une interface réellement native. Adium est un bon exemple de ce genre d’application.
Dans le faits, j’utilise un mélange de logiciels open-source et propriétaires, et ce qui est beaucoup plus important pour moi, c’est la portabilité des données, c’est à dire le fait de pouvoir utiliser mes données à travers différents logiciels, mais aussi à travers le temps. Cette dernière dimension est importante pour moi, j’ai des données sur mon disque dur qui datent littéralement d’il y a 20 ans.
Seb le sauvage affirme Je n’ai aucune inquiétude sur le fait que je puisse relire mes documents ODT (OpenOffice) ou SVG dans 10 ans. J’aurais tendance à être plus méfiant, je sais par expérience que certaines applications commencent à avoir de la peine à ouvrir mes fichiers TIFF vieux de 20 ans, dans mon expérience surtout les open-source qui utilisent les librairie libtiff, Photoshop et Preview.app s’en sortent bien mieux. Il est clair qu’il est difficile d’ouvrir de nos jours un fichier Clarisworks, mais soyons honnête, je ne suis pas sûr de pouvoir compiler à nouveau ma thèse d’il y a un 9 ans. Elle est écrite en Laτεχ qui est complètement ouvert et open-source. Heureusement que j’ai le fichier PDF. En fin de compte, le format texte qui a le mieux survécu au temps, c’est le RTF.
Est-ce que des programmes pourront ouvrir le format ODF dans dix ans, probablement, mais quel sera le résultat ? Est-ce que je pourrais extraire les éléments de base, le texte brut, les images ? Probablement. Est-ce que je pourrais obtenir le même résultat à l’impression ? Peut-être. Est-ce que je pourrais travailler comme si ces dix années ne s’étaient pas passées ? Probablement pas. Pour moi le problème d’ODF n’est pas qu’il est soit-ouvert, ou fermé, standard ou non, mais qu’il s’agit surtout d’une usine à gaz qui cherche à en émuler une plus ancienne.
La grande valeur de l’open-source, c’est qu’on a accès au code source, le problème c’est que le code source est aussi un format de données, et qu’il n’est pas aussi portable qu’on voudrait bien vouloir le faire croire.
Rares sont les projets open-source d’outils graphiques dont on peut prendre une archive datant de 10 ans et compiler le code source sans encombres, que ce soit sur Linux ou un autre OS.
Une personne qui a une spécification de standard et une seule implémentation ne pourra jamais dire que faire en cas de contradiction, tant qu’il n’y a qu’une seule implémentation, la réaction des gens est de considérer qu’elle est correcte et de corriger la spécification. Un vrai standard implique plusieurs implémentations différentes, qui interagissent.
Or les deux standards mentionnés par Seb le sauvage sont très complexes. SVG est aussi un standard très complexe, qui souffre en plus d’une bonne dose de NIH, il s’agit fondamentalement d’une réinvention de PDF, en ignorant comment marche le graphisme sur ordinateur. Résultat, c’est un standard qui n’est pas bien supporté par les browser web (le monde pour lequel il a été conçu), et, à ma connaissance, supporté par aucune imprimante…
Pour moi la question pour chaque format, c’est de savoir si dans 20 ans ce sera plutôt quelque chose comme le TIFF, ou quelque chose comme le DVI. Combien d’outils peuvent encore ouvrir des images au format IFF, au format Targa ? Est-ce que vous voyez la seconde locomotive sur cette page ? Avoir dans vingt ans accès à un code obsolète dans un langage ésotérique ne m’aidera pas tant qu’une spécification claire. La preuve, le code de gestion de Quickdraw, le format graphique des premiers Macs est à présent open-source, le code originel en assembleur 68K est à présent en libre accès, ça n’a pas aidé grand monde…
Juste en passant, SVG est comme ça aussi pour éviter de se prendre les patentes de PDF dans les dents, et essaie de corriger les aberrations les plus flagrantes de la structure de PDF. Ok, c’est raté, on peut toujours exécuter du programme malveillant à travers SVG, même si c’est moins facile qu’à travers PDF.
Perso, si j’insiste sur la portabilité, c’est essentiellement au niveau horizontal. Je suis bien conscient que rien ne garanti que l’ODT d’aujourd’hui soit 100% compris par le parseur de demain, mais je peux raisonnablement penser que j’arriverai à travailler sur des plateformes différentes sans niquer complètement le formatage du document ou simplement son contenu. Word, OpenOffice, c’est du même, plus bling-bling dans un cas, plus rétro-futuriste dans l’autre, mais les fonctions essentielles se valent. Pourquoi donc m’emmerderais-je avec un programme que je dois acheter pour chaque machine/système que j’utilise, et dont chacun de mes collaborateurs utilisera une version légèrement différentes, garantissant plaisanteries informatiques et bricolages annexes et finalement “tout le monde me rend du .txt, point.” Open- ou LibreOffice me proposant un outil raisonnablement cohérent, et gratuit, et existant sur les plateformes auxquelles j’ai affaire, je dirais que le choix est vite fait.
Ensuite il y a la question de l’ergonomie, de l’intégration à la plateforme, et tout le tralala sur lequel Alias et toi insistez. Ok, OpenOffice n’a pas réellement montré son adaptabilité à ce niveau. Mais je pense que l’avenir n’est pas noir et d’esthétique totalement brutaliste, LibreOffice montre une volonté réelle d’améliorer les choses, et on peut imaginer que Apache OpenOffice soit aussi un bon élève dans ces matières là. On verra bien. Je conteste toutefois la légende qui place MS Word en champion de l’ergonomie. Et d’abord, quelle version de MS Word ?
Mon point n’était pas tellement de dire qu’Office est mieux, simplement qu’à mon avis le fait qu’un projet soit open-source ne garantit pas la lisibilité des données plus tard dans le temps. Open-Office et SVG sont particulièrement vulnérables car ce sont des usines à gaz, et les geeks ont tendance à déclarer que les usines à gaz le sont, et à les remplacer par des nouvelles usines à gaz incompatibles (Javascript Canvas pour SVG, par exemple).
Le format open-office souffre en plus du problème conceptuel qu’il est largement basé sur les concepts de Microsoft Office surtout conçu pour un modèle papier (Word), et non collaboratif et une plateforme desktop.
Autant d’hypothèses qui vont être chamboulées ces prochains temps, et autant d’excuses pour décréter le modèle obsolète et coder des trucs plus excitants, comme par exemple un nouveau format de fichier bitmap http://googlecode.blogspot.com/2011/11/lossless-and-transparency-encoding-in.html
Donc tu suggère de remplacer quelque chose qui existe par quelque chose qui n’existe pas encore pour expliquer pourquoi ni Word ni OpenOffice ne sont des solutions idéales, c’est bien ça ? Et donc, le problème conceptuel que tu signale est que des gens qui sont à l’aise avec une analogie papier-crayon devraient se faire à l’idée que dans un proche futur, ils pourront être plusieurs à écrire en même temps sur le même papier, sans avoir à se trouver dans la même pièce. Quelque part, je trouve ça invendable.
J’exagère, mais sans vouloir chambouler les habitudes rédactionnelles du monde entier, est-ce qu’on ne pourrait pas déjà simplement se focaliser sur l’essentiel ? A savoir, écrire, activité hautement solitaire par défaut. Le collaboratif, ça vient après ou avant.
Bref, discussion conceptuelle sans objectif que prouver une fois de plus que nous pouvons être tout à la fois très d’accord et complètement en opposition.
Tu confonds ce que je veux avec ce que je pense va arriver…
C’est pas faux.
Bon, c’est de ta faute aussi, si tu surlignais par exemple en jaune les choses que tu veux et en lilas les choses que tu pense qui vont arriver, ça n’arriverait pas.
Ce qui va arriver, selon moi, c’est qu’une nouvelle catégorie de programme va faire son nid, permettant effectivement de collaborer plus efficacement sur des documents (Google Doc est un exemple) Mais malheureusement ils nécessiteront dans leur majorité d’avoir une connexion active ce qui ne sera pas forcément ni souhaitable, ni possible. Donc, la collab’ sera limitée aux gens qui pourront se permettre de travailler en ligne. Ce que je voudrais, c’est un système qui permette d’intégrer les déconnectés à la collaboration, sans avoir à utiliser les services d’un marabout ou d’une maîtresse de cuir. Ca, ça n’existe pas : on a des documents lourds, des chapelles, des systèmes de versionnage incohérents, des interfaces aussi contre-intuitives qu’on peut les faire, etc.
Quoiqu’il en soit, l’analogie papier-crayon a encore de beaux jours devant elle : elle est simple à expliquer, elle est reproductible physiquement, et elle est “nodale” (il n’y a pas de confusion entre le document et son environnement)