Pour la documentation, si ce sont des formats ouverts, au pire il y a
possibilité de réécrire un outil pour les lire et les convertir en un autre
format. A ce niveau, je pense qu'il faut privilégier qqch basé sur du
texte (style XML).
Pour tout ce qui est code, c'est sûr, il ne compilera/tournera sûrement
pas sur une plateforme future. Par contre, il y aura la possibiité de
faire un portage, ou de comprendre ce que le code fait. Avec du
propriétaire, il n'y a pas de marge.
Pour les outils comme tar, gzip et compagnie, le format est ouvert,
le code aussi donc on peut au pire réécrire les outils, ce n'est pas
quelquechose d'insurmontable. Et on peut supposer que comme ce
sont des outils libres, il y aura toujours quelqu'un pour effectuer des
portages sur de nouvelles plate-formes au fur et à mesure de leurs
apparitions. Avec des outils style Winzip, Word ou autre, si leur éditeur
disparait ou n'a pas envie de faire le portage, c'est foutu pour de bon.
[^] # Re: Dans certaines entreprises
Posté par galactikboulay . En réponse au journal Le comble du development en code fermé?. Évalué à 2.
possibilité de réécrire un outil pour les lire et les convertir en un autre
format. A ce niveau, je pense qu'il faut privilégier qqch basé sur du
texte (style XML).
Pour tout ce qui est code, c'est sûr, il ne compilera/tournera sûrement
pas sur une plateforme future. Par contre, il y aura la possibiité de
faire un portage, ou de comprendre ce que le code fait. Avec du
propriétaire, il n'y a pas de marge.
Pour les outils comme tar, gzip et compagnie, le format est ouvert,
le code aussi donc on peut au pire réécrire les outils, ce n'est pas
quelquechose d'insurmontable. Et on peut supposer que comme ce
sont des outils libres, il y aura toujours quelqu'un pour effectuer des
portages sur de nouvelles plate-formes au fur et à mesure de leurs
apparitions. Avec des outils style Winzip, Word ou autre, si leur éditeur
disparait ou n'a pas envie de faire le portage, c'est foutu pour de bon.