Définir de nouvelles attentes pour les mainteneurs open source

Pendant longtemps, il y a eu deux tests de base pour sortir l’open source : “Est-ce qu’il fait ce que j’ai besoin qu’il fasse ?” et “Est-ce qu’il compile ?”

Bien sûr, c’était bien si cela faisait des choses pour les autres, mais plus que toute autre chose, cela devait au moins être amusant pour le développeur et fonctionner pour les autres. Puis avec la montée en puissance de la gestion des packages, les choses se sont un peu améliorées : « Est-ce emballé ? » Peu de temps après, la popularité croissante du développement piloté par les tests a ajouté une autre exigence : « les tests réussissent-ils ? »

Chacune de ces nouvelles exigences a fait plus de travail pour les mainteneurs open source, mais (dans l’ensemble) les mainteneurs ne se sont pas trop plaints à leur sujet. Je pense que cela s’est produit pour deux raisons : premièrement, le travail était souvent aligné sur les compétences que les développeurs devaient acquérir pour leur travail, et deuxièmement, ils étaient largement perçus comme bénéfiques pour tous les utilisateurs du logiciel, pas seulement pour les développeurs d’entreprise.

Mais cela est en train de changer, et d’une manière qui ne fonctionnera peut-être pas aussi bien pour l’open source et les entreprises.

Les nouvelles charges de l’entreprise

Ici, en 2021, il est clair qu’un nouvel ensemble de normes pour l’open source est en train de fusionner. Ceux-ci apportent un nouveau travail à faire, soit par des développeurs open source, soit dans le cadre d’une superposition de métadonnées. Ces nouvelles normes comprennent :

• Informations de sécurité et audit: Les évaluations de sécurité des packages open source sont traditionnellement effectuées par des tiers, soit par l’intermédiaire d’équipes de sécurité internes, soit par le processus distribué coordonné par le MITRE Vulnérabilités et expositions courantes base de données. Avec de nouvelles formations en sécurité comme les badges CII de la Linux Foundation et des projets comme OpenSSF et le SLSA de Google, le nouveau mot à la mode est « de bout en bout », ce qui signifie que les responsables et les projets doivent devenir des experts en sécurité et créer des contrôles de sécurité. Bien que ce soit presque certainement une bonne idée pour l’ensemble de l’industrie, il s’agit encore d’attentes professionnelles sans perspective immédiate de compensation.
• Métadonnées légales: Traditionnellement, les communautés open source comme GNU, Debian et Fedora pensaient (avec raison) que le niveau par défaut des métadonnées de licence obligatoires était au niveau du paquet, avec des informations de licence par fichier souvent défavorisées au mieux et au pire non représentables. SPDX, suivi plus récemment de cleardefined.io, a décidé que les informations de licence doivent être complètes, lisibles par machine et précises dans chaque fichier. C’est clairement correct pour tous les utilisateurs, mais la grande majorité des avantages profite aux entreprises les plus riches en pratique. En attendant, si nous voulons une couverture mondiale précise, la grande majorité du fardeau incombera aux mainteneurs et nécessitera une évaluation juridique complexe. (En les ajoutant au noyau Linux a pris littéralement des années.)
• Informations sur les achats: La demande la plus récente de l’industrie est de fournir des nomenclatures logicielles (SBOM) dans l’ensemble de la pile logicielle, ce qui inclut inévitablement de grandes quantités d’open source. Encore une fois, ce n’est pas tout à fait déraisonnable, et en effet l’open source a longtemps ouvert la voie ici via les techniques de gestion de paquets que les communautés de langage open source ont lancées. Mais l’exhaustivité de la couverture et la profondeur des informations demandées (y compris, dans certaines propositions, informations sur l’identité des développeurs) est un changement radical dans ce qui est requis, principalement au profit des gouvernements et des grandes entreprises qui peuvent se permettre de faire l’analyse détaillée, paquet par paquet, de la provenance des logiciels.

Ce nouveau travail peut être assez différent des vagues précédentes de nouvelles obligations pour les développeurs open source – et nous devrions réfléchir à la raison et à ce que nous pourrions faire à ce sujet.

Ce travail va-t-il fonctionner ?

Comme je l’ai suggéré dans l’ouverture de cet article, la maturation continue de l’open source a régulièrement placé de nouveaux fardeaux sur les mainteneurs. (Chez Mozilla, nous appelions ces “enjeux de table” – un terme de poker, indiquant les choses que vous deviez faire pour même vous asseoir à la table de poker, ou en termes techniques, pour être pris en compte pour une utilisation en entreprise.) Donc, dans un certain sens. , cette nouvelle vague d’obligations n’a rien de nouveau. Mais je veux suggérer que de deux manières importantes, ces nouveaux mandats sont problématiques.

Premièrement, ce travail est de plus en plus hautement spécialisé et donc moins utile pour les mainteneurs individuels à apprendre. Les développeurs open source les plus forts ont toujours eu des compétences diverses (pas seulement en codage, mais aussi en marketing, en gestion des personnes, etc.). Cela fait partie de l’attrait de l’open source : vous apprenez ces choses en cours de route, ce qui fait de vous un meilleur développeur. Mais lorsque nous commençons à ajouter de plus en plus d’exigences que des spécialistes (par exemple, une équipe juridique ou une équipe de sécurité) couvriraient dans un environnement d’entreprise, nous réduisons la valeur supplémentaire pour les développeurs de participer à l’open source.

En d’autres termes : les développeurs servent clairement leurs propres intérêts en apprenant des compétences de base en programmation et en relations humaines. Il est moins clair qu’ils servent leurs propres intérêts en devenant des experts sur des questions qui, dans leur travail quotidien, sont probablement déléguées à des experts, comme les achats, le droit et la sécurité. Cela fonctionne bien dans les projets open source suffisamment grands pour avoir des équipes importantes et sophistiquées, mais ceux-ci sont rares (même s’ils recueillent la part du lion de la presse et de l’attention).

Deuxièmement, ces nouvelles exigences de plus en plus spécialisées profitent principalement à une catégorie spécifique d’utilisateurs open source : les grandes entreprises. Ce n’est pas nécessairement une mauvaise chose – les grandes entreprises sont essentielles à bien des égards, et en effet, les risques pour elles méritent d’être pris au sérieux.

Mais dans un monde où des centaines de milliards de dollars de valeur d’entreprise ont été créés par l’open source, et où les petits projets éducatifs/de loisirs (et même de nombreuses petites entreprises) ne bénéficient pas vraiment de ces nouveaux mandats non financés, les développeurs se concentreront probablement sur d’autres choses, puisque peu d’entre eux se sont tournés vers l’open source principalement au profit du Fortune 500.

En d’autres termes, de nombreux développeurs open source aiment créer des choses qui profitent à eux-mêmes et à leurs amis et sont même prêts à abandonner des nuits et des week-ends pour cela. Si répondre à ces nouvelles exigences profite principalement aux entreprises anonymes, nous devrons peut-être trouver d’autres carottes pour encourager les développeurs à créer et à maintenir de nouveaux projets open source.

Pourquoi « mandat non financé ? »

Dans la politique américaine, un « mandat non financé » se produit lorsqu’un gouvernement demande à quelqu’un d’autre (généralement un gouvernement de niveau inférieur) de faire un nouveau travail sans financer le nouveau travail. Bradley M. Kuhn m’a donné l’inspiration d’utiliser le terme « mandat non financé » dans une publication récente sur Twitter.

Parfois, les mandats non financés peuvent être utiles – souvent, ils sont utilisés pour créer des programmes d’équité et de justice, par exemple, que les gouvernements locaux devraient vraiment mettre en œuvre de manière naturelle. On peut soutenir que de nombreuses initiatives de sécurité entrent dans cette catégorie – lourdes, oui, mais nécessaires pour que nous puissions tous utiliser Internet efficacement.

Mais d’autres fois, ils ne font que créer du travail pour de petites entités qui sont déjà débordées jonglant avec les responsabilités de la gouvernance moderne. Si cela semble familier aux développeurs open source, pas de surprise—ils sont déjà grillés, et cela crée plus de travail sans créer plus de temps ou d’argent.

Aligner les incitations — en rémunérant les responsables

Nous avons été ravis de voir que Google a signalé ce problème dans un dépôt récent sur les SBOM avec l’Administration nationale des télécommunications et de l’information (NTIA).

“Malheureusement, une grande partie du fardeau de la maintenance de notre infrastructure numérique repose sur le dos de contributeurs bénévoles non rémunérés. La NTIA devrait soigneusement évaluer les moyens de financer et d’aider ces communautés alors qu’elles travaillent avec l’industrie pour se conformer aux nouvelles réglementations.”

Le remplissage de Tidelift au même appel à commentaires de la NTIA a fait des remarques similaires sur l’argent, l’échelle et la fiabilité. En réponse, en son propre résumé, la NTIA a reconnu que les « sources de financement » sont un défi et a également déclaré :

“Des recherches supplémentaires sont nécessaires pour comprendre les incitations optimales pour le partage, la protection et l’utilisation des données SBOM.”

Compte tenu de la dynamique de professionnalisation croissante – ou pour le dire plus franchement, d’augmentation du travail – que j’ai décrite ci-dessus, il est rafraîchissant de voir des acteurs importants de l’industrie reconnaître que les incitations pour les développeurs devraient être envisagées alors que nous entrons dans la prochaine ère d’open la source. Nous, en tant qu’industrie, devons trouver comment résoudre ce problème ensemble, ou nous échouerons tous les deux à atteindre nos objectifs et épuiserons les développeurs – le pire de tous les mondes.