La méthode de capture des codes sources en accès libre se base à peu près sur le même principe que nous avons étudié dans les C”X”AN. En effet, un module de la bibliothèque a été conçue pour aller balayer l’ensemble des répertoires des plateformes de développement, dont le code source est en libre accès. De cette façon cela permet à la SHW de récupérer les nouveaux projets, mais aussi potentiellement de mettre à jour les projets déjà archivés, mais qui auraient évolués entre deux balayages. L’Archive se met ainsi à jour régulièrement et permet d’assurer la “fraîcheur” des données qui sont susceptibles d’être conservées et exploitées sur la plateforme.
Par cette méthode, ce sont actuellement tous les dépôts publics de GitHub qui sont régulièrement balayés et récupérés. Une synchronisation est également effectuée avec les paquets source de la distribution Debian, ainsi que les distributions du projet GNU88.
Les graphiques des données déjà archivées dans la solution affichent des chiffres rocambolesques : près de 4,7 milliards de fichiers sources, un peu plus d’un milliard de
commits et 84 millions de projets sont présentes sur l’Archive89. Les graphiques affichent des courbes à la hausse, et étant donné que l’initiative s’apprête à élargir son périmètre de balayage à d’autres plateformes de développement, ce sont quelques milliards d’autres données qui viendront s’ajouter.
Cette bibliothèque titanesque est ainsi entièrement consultable via une API (cf source) qui permet d’explorer les différents projets susceptibles de contenir les caractères que nous avons entrés dans la barre de recherche. En venant cliquer sur un des liens listés, nous sommes redirigés vers un snapshot90 de l’entièreté du projet, nous
permettant d’aller dans chacun des répertoires de celui-ci et d’inspecter le moindre recoin de l’archive. Il est également possible de télécharger l’entièreté du projet, comme sur une forge de développement.
Intéressons-nous désormais aux typologies de données contenues par la SHW, qui permettent justement d’exploiter dans le détail les différents projets.
2.6.6 Le contenu
Le balayage automatique des plateformes récupère concrètement la totalité du code source ainsi que tous les fichiers versionnés du projet depuis sa création jusqu’au moment du balayage. Nous détaillerons nos propos plus précisément en troisième partie.
88 Ibid. 89 Ibid. 90 Voir glossaire
Dans tous les cas, en fonction du logiciel de versionning qui est exploité, c’est tout un éventail de type de fichiers qui sont récupérés et qui forment la ressource principale de la SHW. En voici la liste exhaustive (liste consultable ici91):
• file contents - le code source, sans les métadonnées
• Directories - les différents répertoires qui permettent de rediriger vers les fichiers relatifs au code source qui peuvent être à l'intérieur de sous- dossiers
• revisions (“commits”) - une liste des différentes modifications effectuées durant le développement du logiciel
• releases (“tags”) - une version du logiciel exploitable
2.7 C
ONCLUSION DELAPARTIE2
L’archivage, à strictement parler, peut très difficilement être appliqué au logiciel. Cependant, les cas que nous venons d’étudier sont représentatifs de la diversité des méthodes de conservation à long terme du code source.
La clôture des plateformes Google Code et Gitorious a permis aux plateformes modernes de prospérer et de palier aux défauts de leurs prédécesseurs. Cette popularité est notamment identifiable par l’identification d’institutions scientifiques et d’entreprises spécialisées dans des domaines variés au sein des forges.
Un logiciel fédérateur et exploité par une très grande diversité d’utilisateurs (chercheurs, professeurs, auteurs, etc.) permet de valider le caractère collaboratif et étendu très marqué des communautés du Libre et de l’Open Source. Les C”X”AN en sont par ailleurs de parfaits exemples.
Ils proposent entre autres une méthode d’archivage “hybride”, à mi-chemin entre l’archivage électronique classique et la sauvegarde simple. La centralisation des informations (issue par ailleurs d’un éclatement des lieux de sauvegarde) en un seul et même point via un site internet permet de proposer une documentation très riche, fournie par les utilisateurs, pour les utilisateurs.
91 DI COSMO Roberto, ZACCHIROLI Stefano, Software Heritage : Why and How to Preserve Software Source Code, iPRES 2017 – 14th International Conference on Digital Preservation, Kyoto, Japan, 2017. 11p. [en ligne]
Cette idée de bibliothèque universelle est par ailleurs adoptée par le projet de la Software Heritage. Cette initiative a su identifier et capturer les composantes essentielles qui définissent un projet de développement d’un logiciel, pour mettre à disposition de tous, les codes source de millions de logiciels, partiellement ou pleinement exploitables en fonction de la complétude des données récupérées.
La Software Heritage a permis, entre autres, de mettre en application un ensemble d’études sur la conservation, l’identification et la restructuration des données relatives au code source. Nous nous baserons donc sur les composantes techniques de l’initiative de la Software Heritage pour développer la troisième et dernière partie de ce mémoire, tout en y ajoutant un ensemble de recommandations que nous déduirons des pratiques communautaires étudiées, ainsi que sur la nécessité de proposer un environnement performant mais évolutif pour répondre aux attentes de chacun.
3 RECOMMANDATIONS
L’initiative de la Software Heritage a permis d’identifier les différentes contraintes à prendre en compte dans la conservation du code source sur le très long terme. Les caractéristiques techniques de l’Archive permettent en effet la récupération, la conservation et l’identification de chacun des fichiers susceptibles d’être sauvegardé dans la bibliothèque.
3.1 U
N VERSIONNING,
UNE MÉTHODE DE RÉCOLTE SPÉCIFIQUEGit, Mercurial, Subversion, Bazar, CVS sont différents exemples de logiciel de gestion de version parmi les plus populaires, mais il en existe bien d’autres. Nous l’avons vu, chacun propose en fonctionnalité principale de générer plusieurs versions des fichiers créés dans le cadre d’un projet, et donc de garantir un historique complet retraçant l’évolution du code source. Ces données peuvent, entre autres, être exportées des espaces de stockage où elles sont conservées. S’il existe bien une grande diversité de logiciels de gestion de version, ce sont principalement les gestion de version centralisées et distribuées qui sont le plus utilisées, donnant ainsi le choix aux équipes de développement, en fonction des besoins du projet.
Un logiciel de gestion de version centralisée est bien plus adapté à l’exploitation de données volumineuses, la concentration de celles-ci sur un seul et même serveur évitant d’avoir à les répliquer plusieurs fois, comme dans le cas de gestion de version distribuée. Cela provoquerait notamment des ralentissements conséquents. Néanmoins, la gestion d’un projet impliquant le traitement de fichiers moins volumineux, mais nécessitant tout de même un développement souple, privilégiera un logiciel comme Git ou Mercurial.
Chacune des solutions de versionning propose également des fonctionnalités spécifiques propres, dont l’intérêt dépend ici de la préférence des développeurs exploitant le logiciel en question. Le choix étant ainsi suffisamment vaste, chacun peut y trouver son compte. Les environnements collaboratifs de développement, dont font partie les forges, sont ainsi construites sur la base des solutions de contrôle de version. GitLab, fonctionnant sous Git, affichera quelques différences avec la plateforme supportée par la GNU Savannah92 fonctionnant sous Mercurial,
92 Free Software Foundation, Savannah, Site savannah.gnu.org [en ligne] Disponible sur:
bien que les deux solutions soient très proches93. Ces différences seront ainsi d’autant plus marquées entre GitLab et les initiatives de la C”X”AN, dont le logiciel employé est Subversion. Différents outils existent néanmoins pour permettre la mutation du corps d’un projet entre deux logiciels de gestion de version, git-svn étant l’un d’eux.