Résumé

  • La participation à l'IETF est individuelle et le consensus approximatif n'est pas un vote. Compter les employeurs dans une salle peut révéler un déséquilibre d'accès, mais ne peut établir qui a contrôlé la spécification résultante ni si les objections ont changé la conception.
  • Une évaluation sérieuse de la capture compare quatre concentrations liées dans le temps: les auteurs et l'autorité éditoriale; les brevets et l'effet de levier des licences; le code indépendant et l'ascendance des bibliothèques de protocoles; et le déploiement activé à travers les produits, les réseaux et les valeurs par défaut. Chaque registre répond à une question différente et aucun ne prouve la capture à lui seul.
  • Le remède doit correspondre au mécanisme. Une concentration de l'auteur appelle un examen indépendant et un équilibre des éditeurs; une concentration des droits appelle une analyse précoce des licences et des alternatives; une ascendance de code partagée appelle une autre racine d'implémentation; la dépendance au déploiement appelle une migration, des suites de tests ouvertes et une portabilité des fournisseurs. L'objectif est une implémentation contestable, pas un quota de microphones dans une réunion.

La salle est là où l'influence est visible, pas là où le contrôle réside nécessairement

Les observateurs des normes commencent souvent par une photographie de la réunion: combien de personnes ont assisté, quels employeurs apparaissent sur les badges, qui a pris le micro, et quel côté a produit le bourdonnement le plus fort. Ces faits sont faciles à compter. Ils peuvent révéler une inégalité de voyage, un parrainage d'employeur, une exclusion régionale, ou un afflux coordonné. Il vaut la peine de les conserver.

Ils ne sont pas la même chose que le contrôle d'un résultat. Un entité d'une petite entreprise peut éditer le texte central utilisé par chaque implémentation. Dix entités d'un même fournisseur peuvent parler de détails sans rapport tandis qu'une conception indépendante prévaut. Une entreprise absente de la réunion peut posséder le seul code mature, détenir des brevets pertinents, définir la valeur par défaut du produit dominant, ou contrôler un service dont chaque implémentation dépend. Une grande communauté open-source peut apparaître sous des dizaines de noms individuels tout en héritant d'une seule racine de code.

La capture est donc une question longitudinale. Un intérêt aligné a-t-il acquis une capacité durable à définir les choix disponibles, à rendre les alternatives coûteuses, et à imposer son comportement préféré dans l'implémentation et le déploiement? La réponse ne peut pas être lue sur une liste d'inscription. Elle émerge sur la durée de vie de la spécification.

Cette distinction protège à la fois la critique et la légitimité. Elle empêche un fournisseur de pointer une salle diversifiée comme preuve concluante qu'aucune capture n'a eu lieu. Elle empêche aussi les critiques de traiter le nombre d'employeurs comme une preuve que les ingénieurs ont agi sous instructions ou que le protocole résultant manque de soutien indépendant. Les preuves doivent suivre le résultat.

La maxime de 1992 concernait l'autorité d'ingénierie, pas un recensement

La période débutant au début des années 1990 est souvent résumée par la formulation de 1992 reprise plus tard dans laRFC 7282: "consensus approximatif et code qui fonctionne". Cette phrase rejette la décision par un dirigeant, un vote formel, ou une théorie détachée de la pratique. Elle ne dit pas que le code gagne parce qu'une entreprise peut financer le plus de développeurs, ni que le consensus existe parce que le plus grand groupe d'employeurs remplit la salle.

LaRFC 3935, la déclaration de mission de l'IETF, identifie les individus comme l'unité fondamentale de participation et dit que le processus fonctionne mieux lorsqu'il est centré sur les personnes plutôt que sur les organisations, les entreprises, les gouvernements ou les groupes d'intérêt. Elle situe également la valeur d'une norme dans l'interopérabilité entre plusieurs produits qui offrent des fonctions utiles aux utilisateurs d'Internet.

Ces principes créent une tension productive. Les individus parlent et raisonnent pour eux-mêmes, mais les organisations fournissent les salaires, les voyages, les brevets, le code, l'équipement, la capacité cloud, la distribution des produits et l'autorité de déploiement. Ignorer les organisations rendrait le pouvoir économique invisible. Traiter chaque entité comme un vote d'entreprise détruirait le caractère individuel et technique du processus.

Un test de capture centré sur l'implémentation résout la tension. Il ne présume pas que la contribution d'un employé appartient politiquement à son employeur. Il pose des questions observables sur les extrants: qui a écrit et pouvait fusionner le texte, qui contrôlait les droits, quel code développé indépendamment a réalisé la conception, et qui pouvait activer le support pour les utilisateurs. Le pouvoir organisationnel est mesuré là où il devient techniquement conséquent.

Les règles des groupes de travail reconnaissent déjà le risque d'un seul fournisseur

LaRFC 2418, les directives des groupes de travail publiées en 1998, demande aux directeurs de domaine et à l'IESG d'examiner si l'intérêt est suffisamment large pour qu'un groupe proposé ne soit pas vu comme simplement l'activité d'un seul fournisseur. Elle demande s'il existe une base d'utilisateurs finaux intéressés, si les problèmes de propriété intellectuelle connus sont compris, et si l'effort est vraiment ouvert plutôt qu'une tentative d'obtenir l'approbation de l'IETF pour une technologie sur laquelle l'apport de l'IETF peut avoir peu d'effet.

Ces questions sont plus sophistiquées qu'un quota de présence. Un groupe peut avoir assez de noms pour satisfaire un seuil numérique tandis qu'un seul fournisseur fournit l'énoncé du problème, le projet, les rédacteurs, l'implémentation, l'environnement de test et la base de clients attendue. Inversement, un domaine spécialisé restreint peut commencer avec peu d'implémenteurs parce que l'expertise est rare. La question pertinente est de savoir si le travail peut devenir contestable et si l'apport peut encore le modifier.

La RFC 2418 exige également que les décisions prises lors d'une réunion sur des questions non suffisamment examinées sur la liste de diffusion soient révisées sur cette liste. Le courrier électronique a été reconnu comme permettant une participation plus large que les déplacements. Le principe a survécu à des outils plus récents: la population d'un seul lieu ne définit pas l'ensemble du groupe.

La question du fournisseur unique doit donc être posée à plusieurs reprises, pas seulement lors de la charte. Lors de l'adoption, du dernier appel, de la révision de l'implémentation et du déploiement majeur, le groupe doit examiner si l'indépendance a augmenté ou diminué. Un groupe qui a commencé autour d'une contribution peut se diversifier. Un effort nominalement large peut converger vers le code et le modèle opérationnel d'un seul fournisseur.

Le consensus approximatif refuse délibérément de compter les blocs d'entreprises

La RFC 2418 dit que la dominance n'est pas établie par le volume ou la persistance, et que le nombre de messages n'est pas à lui seul un indicateur fiable de consensus. LaRFC 7282développe ce point: le consensus approximatif dépend de la question de savoir si les objections techniques ont été examinées et prises en compte, pas de savoir si une majorité préfère une option. Le bourdonnement (humming) est destiné à révéler où le désaccord persiste, pas à organiser une élection.

Cela importe lorsqu'une entreprise recrute de nombreux employés pour exprimer la même position. La RFC 7282 utilise un exemple extrême impliquant le personnel de vente et de marketing pour montrer que des objections répétées sans engagement technique ne doivent pas nécessairement contrôler la décision. Le président doit demander quel problème subsiste et si la réponse est adéquate. Un nouvel ingénieur avec des preuves d'implémentation directes peut soulever une question décisive; cinquante déclarations identiques peuvent n'apporter aucune nouvelle information.

Les mesures de présence peuvent encore révéler un risque procédural. Si chaque rédacteur actif et la plupart des orateurs partagent un employeur, un président devrait chercher un examen indépendant. Si une classe d'opérateurs affectée est absente, le groupe peut ne pas entendre un coût. Si de nouveaux arrivants n'apparaissent que pour un appel controversé, la coordination mérite d'être examinée. Mais le test de légitimité reste le traitement raisonné des preuves et des objections.

Une évaluation de la capture qui réintroduit simplement le vote par employeur contredirait cette conception. Elle serait aussi facile à manipuler par le biais de filiales, de sous-traitants, d'entreprises acquises, d'universités financées par un fournisseur, ou de contributeurs non affiliés dépendant du même code. Le contrôle doit être tracé fonctionnellement, pas deviné à partir du plan de salle.

La capture est le rétrécissement durable du choix contestable

L'influence des fournisseurs est normale et souvent indispensable. Les entreprises apportent des problèmes difficiles, des ingénieurs expérimentés, des produits interopérables, des installations de test et une échelle de déploiement. Une spécification peut être écrite en grande partie par un seul fournisseur et devenir néanmoins ouverte, indépendamment implémentée, sans restriction et largement utile. La concentration n'est pas une faute en soi.

La capture commence lorsque la concentration se durcit en un contrôle que le processus nominalement ouvert ne peut pas contester efficacement. Un intérêt peut définir quel problème compte, garder la seule implémentation utilisable, rendre les alternatives incompatibles avec les systèmes installés, attacher des droits qui augmentent le coût d'entrée, contrôler les dépendances opérationnelles clés, ou déployer une valeur par défaut si largement que le consensus ultérieur a peu d'effet pratique.

Le cœur n'est pas l'intention. Un fournisseur peut atteindre cette position par l'excellence technique, l'avantage du premier entrant, la demande des clients, ou l'incapacité des autres à financer le travail. La conséquence de gouvernance peut être la même: l'organisme de normalisation ratifie les choix après que l'ensemble d'options pratiques s'est rétréci. Le motif compte pour la responsabilité, mais la dépendance structurelle compte pour la conception.

La capture est aussi spécifique à une fonctionnalité. Un protocole peut avoir cinq implémentations indépendantes mais une extension optionnelle contrôlée par un seul fournisseur. Le protocole de base peut être contestable tandis que l'extension devient la passerelle vers le marché dominant. Une bibliothèque open-source commune peut diversifier les applications mais concentrer le comportement du parseur. La mesure doit être suffisamment granulaire pour trouver la surface de contrôle sans stigmatiser un protocole entier.

Le premier registre est l'auteur et l'autorité éditoriale

Les métadonnées RFC nomment les auteurs et les rédacteurs. Les historiques des projets, les enregistrements des problèmes et le contrôle de version peuvent montrer qui a fourni le texte et examiné les modifications. Ce sont des points de départ utiles car le contrôle du document détermine comment le consensus abstrait devient un langage normatif. Un président peut déclarer une décision, mais les rédacteurs choisissent le libellé que les implémenteurs rencontrent.

Les simples décomptes d'auteurs sont faibles. Un nom sur la première page peut refléter des années de conception, une aide éditoriale tardive, un crédit historique, ou une limite formelle au nombre d'auteurs listés. Une entreprise peut employer un rédacteur tandis que de nombreux contributeurs indépendants façonnent le texte. Plusieurs auteurs listés peuvent tous partager une seule lignée de conception. Les affiliations peuvent changer entre le projet initial et la publication.

Les mesures les plus fortes suivent l'autorité substantielle. Qui a écrit l'architecture initiale? Qui a servi de rédacteur lors de l'adoption, du dernier appel et de la résolution finale? Qui pouvait fusionner les modifications? Quelles personnes ont proposé du texte pour le comportement obligatoire, les valeurs par défaut, les points d'extensibilité et la gestion des erreurs? Combien de problèmes de conception ont été résolus avec un examen indépendant? Les alternatives ont-elles été documentées et comparées, ou le groupe a-t-il affiné une implémentation héritée?

Un registre d'auteur devrait conserver le temps et le rôle. L'affiliation de l'employeur appartient à la date de la contribution, avec les changements ultérieurs enregistrés plutôt que réécrits. Les sous-traitants, les entités acquises et les doubles rôles nécessitent des notes limitées. Le but n'est pas d'attribuer chaque phrase à un mandant d'entreprise. Il est de voir si le noyau normatif pouvait être révisé sans qu'un groupe aligné fasse toute la traduction du consensus au texte.

L'historique Git améliore la visibilité mais ne définit pas le consensus

LaRFC 8874explique comment les groupes de travail peuvent utiliser GitHub pour l'édition de documents, les problèmes, les demandes de tirage et les décisions traçables. Elle exige des politiques, distingue les problèmes éditoriaux des problèmes de conception, et précise que le travail sur GitHub n'a pas de statut spécial. Les décisions controversées et le consensus nécessitent toujours le processus plus large du groupe de travail, y compris la liste de diffusion.

Cette distinction devrait façonner les mesures de capture. Le nombre de validations mesure l'activité, pas l'autorité. Un contributeur peut faire des centaines de modifications de formatage tandis qu'un autre décide d'une seule valeur par défaut obligatoire. Un propriétaire de dépôt peut détenir des autorisations techniques qui sont contraintes par les présidents et le consensus public. Une demande de tirage fusionnée peut refléter une décision prise ailleurs. Une proposition non fusionnée peut avoir transformé la conception finale indirectement.

Les mesures utiles du dépôt pondèrent donc le type de problème et l'effet de la décision. Qui a ouvert et résolu les problèmes de conception? Qui a examiné les modifications venant de l'extérieur du groupe de rédacteurs? Combien de temps les objections indépendantes sont-elles restées ouvertes? Une alternative proposée a-t-elle reçu un projet stable et des tests? Les modifications substantielles tardives ont-elles été exposées sur la liste de diffusion? Une organisation détenait-elle à la fois les rôles de rédacteur et d'administrateur du dépôt sans supervision indépendante du président?

Le choix de l'outil crée son propre biais d'échantillonnage. Les entités qui suivent la liste de diffusion peuvent ne pas surveiller chaque problème, tandis que les développeurs de logiciels peuvent préférer la discussion dans le dépôt. La RFC 8874 avertit que GitHub seul ne peut pas être supposé atteindre tous les entités intéressés. Un examen de capture devrait comparer les lieux et demander si le raisonnement décisif est resté visible à travers eux.

Le second registre est les brevets, les licences et la technologie contrôlée

Le code peut être public tandis que les droits d'implémentation restent concentrés. LaRFC 8179relie la participation à l'IETF aux droits raisonnablement et personnellement connus des contributeurs, employeurs et sponsors. Son but est de donner aux groupes de travail suffisamment d'informations sur les contraintes potentielles de propriété intellectuelle pour comparer les choix techniques. Elle ne demande pas à l'IETF de décider de la validité ou de la contrefaçon.

Pour l'analyse de la capture, les mesures pertinentes sont la concentration et le moment. Combien de divulgations matérielles sont attachées au noyau obligatoire? Sont-elles contrôlées par un seul détenteur de droits ou un groupe aligné? Les conditions de licence étaient-elles claires alors que les alternatives étaient encore possibles? Deux implémenteurs sans lien peuvent-ils utiliser la voie de licence à des conditions acceptables? Une implémentation open-source fait-elle face à une condition que les fournisseurs de produits peuvent absorber mais que les projets communautaires ne peuvent pas?

Un simple décompte de brevets peut induire en erreur. Une revendication large peut être plus importante qu'un large portefeuille défensif. Une divulgation peut identifier des droits possibles sans prouver qu'une licence est nécessaire. Des conditions libres de redevance peuvent réduire l'effet de levier; un langage vague de conditions raisonnables peut laisser les petits implémenteurs dans l'incertitude. Un détenteur de droits peut soutenir une large implémentation, tandis qu'un tiers extérieur au groupe crée la contrainte.

Le registre devrait donc relier chaque position divulguée à la fonctionnalité affectée, au statut d'exigence, au détenteur de droits, à la date de divulgation, à la posture de licence et à la preuve d'une utilisation réussie distincte. Il devrait préserver l'incertitude. La conclusion n'est pas "le fournisseur possède des brevets, donc capture". Elle est de savoir si les droits rétrécissent matériellement qui peut implémenter ou donnent à un intérêt un levier après que le groupe et le marché se sont engagés.

Le troisième registre est l'ascendance du code, pas le nombre de produits

LaRFC 7942permet aux Internet-Drafts de décrire les implémentations connues, y compris l'organisation responsable, la maturité, la couverture, la compatibilité des versions, les licences, l'expérience d'implémentation et les tests d'interopérabilité. La section est volontaire et normalement retirée avant la publication, bien que des enregistrements séparés maintenus puissent être utilisés.

Cette directive reconnaît que le code qui fonctionne améliore la maturité de la spécification, mais elle ne fait pas de chaque implémentation une implémentation indépendante. Dix produits peuvent intégrer la même bibliothèque de protocole. Un fournisseur peut publier des variantes client et serveur à partir d'un seul dépôt. Deux équipes peuvent utiliser un parseur partagé, un oracle de test, une bibliothèque cryptographique ou une machine d'état de référence qui porte la même interprétation et le même défaut. Un fork peut avoir un nom différent tout en recevant presque tous les changements en amont.

LaRFC 5657fournit le test le plus précis. Ses directives sur les rapports d'implémentation disent que les implémentations indépendantes devraient normalement provenir de personnes, organisations, codes et bibliothèques de protocoles différents. Lorsqu'il n'existe que deux implémentations, leur généalogie devrait être identifiée. Le but est de montrer que l'interopérabilité découle de la spécification plutôt que d'une compréhension privée ou d'un code commun.

Cette généalogie est l'unité correcte pour la mesure de la capture. La question n'est pas de savoir combien de paquets annoncent un support. Elle est de savoir combien de racines de code raisonnées indépendamment implémentent le comportement normatif, peuvent interopérer sans une hypothèse cachée partagée, et peuvent continuer si un mainteneur ou un fournisseur se retire.

Une carte des racines de code devrait mesurer le contrôle à plusieurs niveaux

L'ascendance de l'implémentation n'est pas binaire. Deux produits peuvent avoir un code d'application indépendant mais partager une bibliothèque de transport. Des piles de protocoles séparées peuvent reposer sur un seul fournisseur cryptographique. Des projets open-source indépendants peuvent utiliser une suite de tests de conformité unique maintenue par le fournisseur d'origine. Un service cloud peut exposer un protocole via de nombreux clients tout en gardant le comportement décisif du serveur propriétaire.

Une carte utile commence par le parseur et la machine d'état: les formats de paquets, les transitions, les erreurs et la négociation sont-ils implémentés indépendamment? Elle suit ensuite les bibliothèques critiques pour la sécurité, le code généré, les générateurs de code, les algorithmes de référence et les vecteurs de test. Elle enregistre les relations de fork et la part des modifications reçues en amont. Elle identifie qui peut approuver les versions et les correctifs de sécurité.

La carte devrait aussi distinguer l'influence de référence du contrôle. Une implémentation de référence de haute qualité peut réduire l'ambiguïté et accélérer l'adoption. C'est bénéfique. La dépendance devient risquée lorsque la spécification écrite ne peut pas soutenir une autre implémentation sans copier la référence, lorsque les tests encodent un comportement non documenté, ou lorsque chaque produit déployé attend la version d'un seul mainteneur.

Les mesures peuvent inclure le nombre de racines indépendantes, la concentration des dépendances, la concentration des mainteneurs, la diversité des relecteurs, l'indépendance de la suite de tests et le temps de substitution. Aucune ne devrait devenir un score de passage mécanique. Une petite bibliothèque cryptographique soigneusement examinée peut être plus sûre que de nombreuses mauvaises réinventions. La question de gouvernance est de savoir si la norme reste implémentable et maintenable sans permission ni connaissance unique détenue par un intérêt aligné.

L'interopérabilité doit tester le désaccord, pas seulement les démos réussies

Deux implémentations peuvent communiquer parce que leurs auteurs ont coordonné en privé, copié le même exemple, ou évité les fonctionnalités difficiles. Une démonstration publique prouve que quelque chose a fonctionné dans une configuration. Elle ne prouve pas que la spécification est complète, que les implémentations sont indépendantes, ou que les branches optionnelles interopèrent.

La RFC 5657 recommande suffisamment de détails sur les fonctionnalités pour établir une couverture significative sans noyer le rapport dans chaque énoncé normatif. Elle valorise les preuves de déploiement et encourage les rapports à identifier les fonctionnalités non implémentées ou problématiques. Cette franchise est importante pour l'analyse de la capture: une fonctionnalité supportée uniquement par le fournisseur proposant peut rester dans la norme malgré l'absence de demande indépendante.

Les tests devraient cibler les endroits où les interprétations pourraient diverger: entrée invalide, négociation de version, repli, ordre des extensions, gestion des erreurs, limites de sécurité, épuisement des ressources et combinaisons optionnelles. Des équipes indépendantes devraient dériver les attentes de la spécification avant de comparer le comportement. Lorsque l'implémentation de référence et la suite de tests ne sont pas d'accord avec le texte, la résolution devrait être publique.

L'échec peut être une preuve d'indépendance. Deux implémentations véritablement séparées révèlent souvent des ambiguïtés qu'une racine de code partagée cache. Un processus qui ne récompense que les démonstrations soignées peut pousser les équipes vers des bibliothèques communes et supprimer les résultats négatifs. La meilleure mesure est de savoir si le désaccord indépendant a amélioré le texte et si le comportement résultant est devenu reproductible.

Le quatrième registre est le déploiement, l'activation et le pouvoir par défaut

L'implémentation n'est qu'une étape. LaRFC 5218distingue l'implémentation, le déploiement et l'utilisation lors de l'évaluation du succès d'un protocole. Le code peut exister sans être installé; le support installé peut rester désactivé; le support activé peut ne porter aucun trafic significatif. Une analyse de la capture des normes doit faire les mêmes distinctions.

Le pouvoir de déploiement est la capacité de transformer une conception en l'environnement par défaut rencontré par les autres. Un navigateur, un système d'exploitation, une plateforme de routeur, un edge cloud, un réseau mobile ou une bibliothèque largement intégrée peut établir un comportement à une échelle énorme. Cela peut produire des avantages rapides en matière de sécurité et d'interopérabilité. Cela peut aussi rendre les alternatives ultérieures techniquement conformes mais commercialement sans importance.

Les mesures devraient identifier les points d'extrémité activés, la part de trafic lorsque c'est mesurable, les classes de produits, les domaines administratifs et le statut par défaut. Elles devraient séparer un service centralisé contrôlé par une seule entité de nombreux opérateurs indépendants. Un million d'instances sous une seule autorité de version sont une échelle, pas une diversité de gouvernance. Un protocole utilisé par de nombreux réseaux via un intermédiaire hébergé peut avoir une large utilisation et un contrôle opérationnel étroit.

Le registre a aussi besoin de la direction de la dépendance. Un petit implémenteur peut-il interopérer directement, ou doit-il passer par un service dominant? Les opérateurs peuvent-ils changer de fournisseur sans changer l'identité du protocole, les informations d'identification ou le format des données? Les points d'extension sont-ils utilisables ouvertement, ou le déploiement dominant décide-t-il quelles extensions deviennent viables? La capture réside souvent dans ces coûts de changement plutôt que dans le format de base du paquet.

Les valeurs par défaut sont un pouvoir de normalisation même lorsque le texte dit PEUT

Les niveaux d'exigence normatifs ne décrivent pas entièrement le déploiement. Une fonctionnalité optionnelle activée par l'implémentation dominante peut devenir de facto obligatoire pour les services cherchant à être atteints. Une fonctionnalité obligatoire désactivée par la plupart des produits peut avoir peu d'effet. Une extension spécifique à un fournisseur peut façonner le trafic avant que le groupe de travail ne décide de la normaliser.

L'évaluation de la capture devrait donc comparer le texte et la valeur par défaut. Qui a sélectionné le comportement livré? A-t-il été discuté comme un problème de conception? Les opérateurs peuvent-ils le changer en toute sécurité? La négociation favorise-t-elle le mode du fournisseur? Les tests et la documentation rendent-ils l'alternative également viable? Un service refuse-t-il les clients qui choisissent une autre option conforme?

Les valeurs par défaut peuvent créer une coordination bénéfique. Les utilisateurs gagnent en protection lorsqu'un comportement sécurisé est activé sans configuration. Les améliorations de performance se propagent rapidement. La préoccupation n'est pas qu'une implémentation populaire doive éviter le leadership. Elle est de savoir si le processus de normalisation peut encore évaluer et modifier le comportement après que le déploiement a créé une dépendance.

Un registre des valeurs par défaut transparent enregistre la version, la date, la classe de produit, la configurabilité par l'opérateur, le repli et la relation avec le texte normatif. Il enregistre également quand une valeur par défaut propriétaire entre plus tard dans la norme. Cette histoire aide à distinguer le consensus indépendant de la reconnaissance d'un fait accompli.

Quatre concentrations doivent être combinées, pas moyennées

L'auteur, les droits, le code et le déploiement révèlent chacun une forme différente de contrôle. Un large groupe d'auteurs ne peut pas annuler un goulot d'étranglement de brevet. De multiples détenteurs de brevets ne peuvent pas compenser une seule racine de code. Plusieurs racines de code n'empêchent pas une plateforme de déploiement de définir la valeur par défaut effective. Un marché diversifié ne guérit pas une spécification dont le texte normatif ne peut être modifié que par un seul groupe de rédacteurs.

La plus forte préoccupation de capture apparaît lorsque les concentrations s'alignent. Le même fournisseur ou intérêt coordonné écrit le noyau obligatoire, détient les droits matériels, maintient le code de référence et de test, et opère le déploiement dominant. Chaque position renforce les autres. La base installée valide la conception, la conception favorise le code, le code incarne un comportement non documenté, et les droits ou les coûts de changement dissuadent les alternatives.

Le schéma opposé soutient la légitimité. Une concentration initiale de l'auteur est suivie par un examen éditorial indépendant. Les droits sont absents ou disponibles à des conditions utilisées par des implémenteurs sans lien. Plusieurs généalogies de code interopèrent. Le déploiement couvre des opérateurs et produits indépendants. Aucune couche unique n'a besoin d'une égalité parfaite si le système combiné reste contestable.

Pour cette raison, un examen de capture devrait utiliser une matrice plutôt qu'un seul score composite. Les moyennes cachent les points de veto. Le rapport peut évaluer la concentration de chaque couche, la qualité des preuves, la tendance et la conséquence, puis identifier les alignements entre couches. Une cellule rouge de brevet n'est pas guérie par une cellule verte de présence.

... (le reste de l'article traduit)...