La Maison-Blanche et le gouvernement fédéral des États-Unis semblent prendre un nouvel engagement en faveur des logiciels libres. Alors que le gouvernement américain utilise les solutions open source depuis longtemps, une nouvelle proposition issue de la maison blanche il y a quelques jours suggère que les logiciels écrits ou commandés par le gouvernement US devraient être publiés gratuitement avec des licences ouvertes dès cet été.
Un document titré « Federal Source Code Policy — Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software » appelle spécifiquement les agences gouvernementales à commencer le partage des codes en open source dès le mois de juillet. Ce document relève que « même lorsque les agences sont en position de rendre leurs codes disponibles à l’échelle du gouvernement, elles ne rendent pas systématiquement leurs codes disponibles et utilisables pour les autres agences de façon cohérente. Ces lacunes aboutissent à la duplication des acquisitions pour un même code et une inefficace dépense pour le contribuable. Cette nouvelle politique vise à relever ce défi en aménageant des étapes pour s’assurer que tout nouveau code fédéral personnalisé sera largement disponible pour une réutilisation par le gouvernement fédéral. »
Dans les 90 jours suivants la publication de ce document, l’administration devra lancer un projet open source sous la forme d’un dépôt d’outils, des meilleures pratiques et de schémas permettant aux agences d’implémenter cette directive. Ce projet open source sera accessible à l’adresse https://project-open-source.cio.gov.
Ce projet ne concerne pas uniquement la livraison des codes source au public. Il vise aussi à mettre de l’ordre dans les répertoires gouvernementaux et permettre la contribution des communautés open source existantes : « les répertoires accessibles pour le stockage, la discussion, et les modifications des codes personnalisés sont la partie critique d’une réutilisation gouvernementale et de la politique de pilotage des logiciels open source. [...] Les agences concernées devraient nécessairement utiliser les répertoires de code existant et les plateformes de tierce partie pour remplir les objectifs de cette politique ». Cette nouvelle politique ne concerne pas l’intégralité des codes sources. En effet, il y a un nombre important d’exceptions écartant les logiciels considérés comme sensibles du domaine public. Malgré cela, le document stipule que les agences participantes devront publier au moins 20 % de leurs codes personnalisés chaque année.
Le programme est lancé initialement pour trois ans et sera évalué au bout de la deuxième année pour décider de son prolongement. L’évaluation sera fondée sur des métriques qui seront établies au cours de cet été.
Au sein de l’administration générale des services des États-Unis, le groupe 18F est un groupe de techniciens, designers et chercheurs issu de tout le pays qui s’engage à rendre les services plus simples et faciles d’utilisation. Ce groupe, que l’on pourrait comparer à Etalab en France, est en pleine croissance. Il a créé de nombreuses applications au niveau fédéral, comme les fiches d’évaluation, un site Web et une interface de programmation pour permettre aux collèges gérés par l’état fédéral de communiquer des informations jusque là indisponibles pour la plupart des familles. Britta Gustafson, membre du groupe 18F a commenté la nouvelle politique de la maison blanche sur la page GitHub du groupe notamment la section appelant à ce que chaque code soit accompagné d’un fichier texte permettant une meilleure description des buts, statuts, licences et niveaux d’engagement attendus pour les contributions au développement, ainsi que des détails techniques pour le déploiement. Elle met en garde les administrations devant la charge de travail que représente ces contraintes et ajoute, non sans une pointe d’ironie : « quand cette politique sera finalisée et que les agences commenceront à l’implémenter…, les agences auront appris beaucoup sur la gestion de projet efficace de l’open source avec une expérience de la vraie vie et il sera alors utile d’itérer rapidement sur les contraintes de cette documentation. La liste détaillée des contraintes de cette politique représente un risque si elle ne répond pas à la flexibilité et l’agilité nécessaire à l’expérimentation du monde réel. Écrire une bonne documentation nécessite de nombreuses itérations fondées sur les besoins et tests réalisés par les utilisateurs. »