Software Heritage : Inria veut archiver tout le code source disponible

Software Heritage : Inria veut archiver tout le code source disponible

Bibliothèque d'Alexandrie 2.0

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

01/07/2016 5 minutes
26

Software Heritage : Inria veut archiver tout le code source disponible

Inria a officialisé hier son initiative Software Heritage. L’objectif est très ambitieux : réunir, stocker et sauvegarder tout le code source qui peut l’être. Une sortie de bibliothèque d’Alexandrie du logiciel, qui devra faire face à de nombreux défis.

Software Heritage est un vaste projet que Inria a présenté officiellement hier. Dans son communiqué, l’institut brosse le portrait du logiciel en général : une composante essentielle de la vie quotidienne. Les logiciels sont partout, « pour échanger des messages, payer des factures, accéder au divertissement, chercher des informations, ou planifier des voyages ».

Inria considère la masse globale du code source utilisé comme un véritable patrimoine culturel et technologique. Objectif : créer un « référentiel unique du code source et un grand instrument de recherche pour l’Informatique », afin de « préserver et diffuser la connaissance aujourd'hui encodée dans le logiciel ». Partant de ce constat, il est « légitime pour Inria de se soucier de la préservation de toute la connaissance liée au logiciel et de la mettre au service de la société, de l’industrie, de la science et de l’éducation » indique ainsi Antoine Petit, son PDG.

Les encyclopédistes du code source

Contacté par nos soins, Roberto di Cosmo, directeur du projet, nous a donné les raisons principales qui ont poussé à cette réflexion : « Aujourd’hui, si vous voulez la traçabilité du code, faire de la recherche ou de la sécurité, il faut aller voir un peu partout : sur le site du projet, GitHub, etc. Nous voulions un endroit unique dans lequel on pourrait retrouver n’importe quel code source ». 

Tous les codes sources ? « Tous ceux des projets libres, l’open source en général » indique di Cosmo, avant de préciser qu’un document sera bientôt publié pour indiquer clairement ce qui est accepté : « Mais on acceptera de nombreuses formes de licences. Académiques par exemple, qui permettent de faire ce que l’on veut du code, sauf de l’utiliser à des fins commerciales. Même les licences qui ne permettent que de lire le code seront acceptées, parce que cette lecture peut être source de connaissances ».

software heritage

Une architecture distribuée pour éviter les faiblesses

Cette immense bibliothèque compte pour l’instant 22 millions de projets environ, pour 2,6 milliards de fichiers uniques (chaque fichier n’est stocké qu’une fois), représentant un poids total de 200 To. Une sorte d'Archive.org, en nettement plus vaste. La question du stockage et de la préservation vient immanquablement. Le directeur du projet nous explique : « Notre stratégie est de devenir rapidement une structure internationale distribuée, de manière à s’assurer que si un partenaire est défaillant, les autres prendront le relai. Plutôt que de prétendre qu’on est les meilleurs, construisons un système qui survivra, parce qu’on peut avoir des failles et des échecs ».

Puisque l’on parle de partenaires, Microsoft est le premier à être monté à bord du navire. Pendant trois ans, l’éditeur fournira à titre gracieux un miroir des données sur son architecture de cloud Azure, avant renégociation. Le DANS, de la Royal Academy des Pays-Bas, a également signé pour stocker des données. Un nombre indéterminé d’autres partenaires devraient également signer dans les prochains mois, mais Roberto di Cosmo n’a pas souhaité s’avancer sur ce point.

La priorité : stocker avant que les codes ne disparaissent

Le projet ne fait que débuter, et les codes sources ne sont pas encore disponibles. Il faudra encore plusieurs mois, le temps que l’architecture mise en place puisse supporter les connexions et les téléchargements provenant du monde entier. Actuellement, quatre employés travaillent sur Software Heritage à temps plein, ainsi que deux stagiaires. De nombreuses autres personnes participent à temps partiel, notamment Jean-François Abramatic, ancien président du W3C, qui a par exemple accompagné Roberto di Cosmo dans les négociations avec Microsoft.

Pour l’instant, le site officiel du projet ne permet aux développeurs que de vérifier si leur code source est déjà sauvegardé dans Software Heritage. Roberto di Cosmo nous indique à ce sujet que la priorité est d’en engranger un maximum. Inria a par exemple pu récupérer l’intégralité de ce qui était stocké dans Google Code après sa fermeture, avec l’accord de la firme américaine. Pour le reste, il faudra attendre l’automne pour plonger dans les archives, di Cosmo nous précisant qu’un important – et mystérieux – évènement se tiendra en septembre. 

Signalons enfin que lundi aura lieu la conférence Debian. A cette occasion, l'équipe de Software Heritage publiera le code source des outils utilisés par le projet.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les encyclopédistes du code source

Une architecture distribuée pour éviter les faiblesses

La priorité : stocker avant que les codes ne disparaissent

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (26)


Et ils comptent tracer le code du projet aussi ?


Je me pose aussi la question du versioning, c’est pas vraiment precisé, ils convertissent tout en hg/git ? Avoir un gros tas de code sans les commits+ coms ça sert à rien donc je me doute bien que qqc est prévu ..


C’est intéressant mais je crains que ça ne se limite aux sources facilement accessibles comme ce qu’on a sur GitHub, ou aux gros projets.

De très nombreux codes sources sont distribués dans des archives compressées, alors je me demande s’ils comptent fouiller ça aussi.








vampire7 a écrit :



De très nombreux codes sources sont distribués dans des archives compressées, alors je me demande s’ils comptent fouiller ça aussi.








Yep, j'ai d'ailleurs un peu de mal à comprendre comment ça peut-être encore le cas aujourd'hui...


Ah ben moi j’ai du mal à comprendre comment on peut faire autrement sans passer par GitHub ou équivalent.








vampire7 a écrit :



Ah ben moi j’ai du mal à comprendre comment on peut faire autrement sans passer par GitHub ou équivalent. 





 Justement, quelle peut-être la raison de ne pas passer par un service web de gestion de développement de logiciels si tu distribues déjà ton code source ?









vampire7 a écrit :



Ah ben moi j’ai du mal à comprendre comment on peut faire autrement sans passer par GitHub ou équivalent.



bande de jeunes :clope:

Initiative intéressante, on verra à leur présentation comment ils gèrent les évolutions









elldekaa a écrit :



Justement, quelle peut-être la raison de ne pas passer par un service web de gestion de développement de logiciels si tu distribues déjà ton code source ?





Mes 2 principaux projets sont liés à ceux d’un gars qui avait déjà un forum ailleurs.

Et puis je développe seul mes logiciels. Je n’ai donc pas besoin d’un truc collaboratif lourdissime.



NXI, premier média en 5 ans a enfin accepter la comm’ pour arrêter de dire “l’Inria”, mais “Inria” ? .. Ouarf.








elldekaa a écrit :



Justement, quelle peut-être la raison de ne pas passer par un service web de gestion de développement de logiciels si tu distribues déjà ton code source ?







Donne moi le nom d’un site web de source-management qui sera encore opérationnel dans 30 ans… sourceforge , codeproject, github ?



les fichiers Tar+Compress (tgz) existent depuis les années 80 et peuvent toujours être créés, copiés et décompressés aujourd’hui.



ma contribution :

echo “hello world”


ma contribution

puts shutdown

<img data-src=" />








127.0.0.1 a écrit :



Donne moi le nom d’un site web de source-management qui sera encore opérationnel dans 30 ans… sourceforge , codeproject, github ?



les fichiers Tar+Compress (tgz) existent depuis les années 80 et peuvent toujours être créés, copiés et décompressés aujourd’hui.







Quel est le rapport?

La gestion de source est independante du site web. J ai tous mes repo gits en local en + de les avoir sur github (et idem pour un projet que j avais heberge sur souceforge).

L interet de la gestion de source c est de naviguer dans l historique du projet alors que tar et consort ne sont que des moyens de creer un snapshot



Ils vont donc mettre mes projets dans leur backup? Mais aucun n’est fini!








quicky_2000 a écrit :



L interet de la gestion de source c est de naviguer dans l historique du projet alors que tar et consort ne sont que des moyens de creer un snapshot







Tu le dis toi même: tu cherches à archiver l’historique du projet (qui, quand, quoi, pourquoi)



Ici on parle d’archiver le code source (le “quoi”)… peu importe l’historique du projet qui a permis d’arriver à générer ce code source.



C’est un repos git géant ? Parce que si c’est juste des snapshots, c’est moins intéressant, surtout sur les projets vivants.


Le code source c’est bien, mais quid des builds ? Sans les outils pour construire ni les systèmes ciblés c’est quand beaucoup moins utile. Je me demande si l’Inria s’en préocuppe et compte fournir des VM ou un autre moyen de pallier à cela.


Un projet n’est jamais fini.








fred42 a écrit :



Un projet n’est jamais fini.





Si seulement mes employeurs pouvaient comprendre ça.



ça m’a “choqué” également


On ne peut pas être contre mais si il y a bien le versionning (et donc les commentaires des commits), sans les infos des bugtrackers à-côté ça risque de laisser un goût d’inachevé aux futurs explorateurs.



Parce qu’il doit y an avoir un certain nombre, des “Correction du bug à la con (voir #2133 pour plus d’infos)”, où le ticket lié peut être beaucoup plus intéressant que le diff en lui-même.



Avec leur moyenne actuelle de 26 commits et 117 fichiers par projet on peut se demander si ça reprend bien tous les historiques, même si il doit y avoir pas mal de projets comme des librairies mineures ou des projets perso qui ne doivent pas beaucoup bouger et qui tirent la moyenne vers le bas.



Et puis 200 To… en prenant en compte une hypothétique compression sur partition ou pas ?

Et en incluant la base de données pour rechercher dans les projets en full-text ?








zébulon a écrit :



ça m’a “choqué” également





+1 je me suis demandé si c’était pas la même chose !









127.0.0.1 a écrit :



Tu le dis toi même: tu cherches à archiver l’historique du projet (qui, quand, quoi, pourquoi)







Non je n utilise pas un gestionnaire de version pour archiver.je m en sers pour developper,par exemple revenir en arriere en cas d erreur,retrouver la source d un bug etc.



Et d apres la description de leur mission je comprends qu ils veulent archiver le projet depuis son origine,c est a dire historique inclus









Ruzgfpegk a écrit :



On ne peut pas être contre mais si il y a bien le versionning (et donc les commentaires des commits), sans les infos des bugtrackers à-côté ça risque de laisser un goût d’inachevé aux futurs explorateurs.



Parce qu’il doit y an avoir un certain nombre, des “Correction du bug à la con (voir #2133 pour plus d’infos)”, où le ticket lié peut être beaucoup plus intéressant que le diff en lui-même.







Tout a fait daccord. Je crois bien que github permet d exporter tout ce qui est metadonne mais je suis pas sur a 100%

Se serait bien qu ils donnent plus de details sur ce qu ils sauvegardent vraiment



Pour l’instant, on n’y a pas accès, donc on ne peut pas vraiment savoir.



Puis pour certains logiciels, on est déjà bien content de retrouver les sources (même sans versionnage ou quoi que ce soit, juste les sources).








gokudomatic a écrit :



Si seulement mes employeurs pouvaient comprendre ça.





Certains de tes employeurs sont peut être des projets eux aussi&nbsp;<img data-src=" />