La politica degli standard

Gli standard sono documenti tecnici redatti dagli ingegneri e discussi nei comitati prima di essere implementati nel codice. Tuttavia, parlarne solo in termini tecnici significherebbe trascurare un aspetto essenziale della loro natura e funzione.
Infatti, gli standard sono anche – e soprattutto – strumenti politici, perché definiscono gli attori del mercato, determinano la direzione dello sviluppo e stabiliscono gli interessi serviti dall’ecosistema. In altre parole, sono alla base dei rapporti di potere del mercato.
Cosa fa uno standard
Uno standard è un meccanismo di coordinamento che consente a più attori indipendenti, come sviluppatori di software, produttori di hardware, creatori di contenuti, governi e imprese, di collaborare senza dover negoziare ogni volta i termini della loro interazione.
Come una lingua, uno standard consente la comunicazione con chiunque lo parli. È una promessa di comunicazione universale di immenso valore, ed è il motivo per cui gli standard sono così importanti nell’informatica, dove gli effetti di rete della compatibilità si moltiplicano rapidamente.
Tuttavia, uno standard definisce anche le condizioni di partecipazione.
Uno standard semplice e trasparente, basato su conoscenze ampiamente disponibili, può essere implementato da più attori senza creare disuguaglianze.
Al contrario, uno standard complesso e volutamente oscuro, che richiede competenze specifiche, può essere implementato correttamente solo da chi lo ha definito, creando così disuguaglianza.
Pertanto, la complessità di uno standard funge da barriera, determinando sia chi può accedere al mercato sia gli equilibri di potere al suo interno.
Gli ecosistemi aperti
Un ecosistema aperto non dipende da un documento che contiene le specifiche dello standard, ma piuttosto dalla capacità di qualsiasi soggetto interessato di implementare lo standard in modo completo e corretto secondo le specifiche, senza ricorrere a comportamenti non documentati o al reverse engineering.
Questo richiede che le specifiche siano chiare e lascino spazio a una sola interpretazione, e che lo standard non dipenda da comportamenti definiti da una sola implementazione, perché questo la renderebbe una dipendenza obbligatoria. Inoltre, richiede coerenza, per impedire che le implementazioni conformi diventino obsolete a causa di revisioni silenziose.
Quando tutte queste condizioni sono soddisfatte, lo standard può essere implementato da chiunque, anche da chi non ha avuto alcun ruolo nella sua creazione. Università, piccole imprese, comunità open source, agenzie governative e singoli sviluppatori possono tutti produrre software conforme.
La concorrenza è possibile sulla base della qualità dell’implementazione, e non sulla vicinanza agli autori dello standard o sul reverse engineering. Lo standard fornisce una base su cui chiunque può costruire.
Gli ecosistemi chiusi
La chiusura di un ecosistema attraverso uno standard può essere casuale, ma nella maggior parte dei casi è intenzionale e si basa su dei meccanismi abbastanza facili da elencare.
Il primo meccanismo è l’inutile complessità. Quando uno standard definisce le proprie soluzioni a problemi che hanno già soluzioni valide e ampiamente implementate, costringe gli altri attori a reinventare la classica ruota. Ogni sottosistema proprietario è un nuovo elemento che aumenta i costi e spesso limita artificialmente la compatibilità.
Il secondo meccanismo è la sottodeterminazione. Quando le specifiche sono ambigue o limitate, ogni implementazione produce un risultato diverso. Quando un documento viene visualizzato in modo leggermente diverso, gli utenti danno sempre la colpa alla seconda applicazione piuttosto che al formato. Si tratta di una forma estremamente insidiosa di lock-in.
Il terzo meccanismo è l’estensibilità. Se le specifiche consentono l’aggiunta di estensioni proprietarie, il documento può essere tecnicamente conforme allo standard, ma solo un programma è in grado di visualizzarlo correttamente. In questo caso, lo standard nasconde un sistema proprietario.
Oltre a questi tre meccanismi, esiste un’influenza diretta o indiretta sugli organismi di standardizzazione.
L’influenza diretta si verifica quando il fornitore può influenzare il processo di standardizzazione stesso, modellando i requisiti di conformità in modo che corrispondano al comportamento della propria applicazione.
L’influenza indiretta si verifica quando il fornitore può influenzare altri membri attraverso fattori esterni al processo di standardizzazione.
La posta in gioco va oltre il software
Le conseguenze degli standard aperti e chiusi non riguardano solo gli sviluppatori di software.
Per esempio, un governo che archivia i propri documenti in un formato che viene gestito correttamente solo da un software dipende, di fatto, dal vendor che lo ha sviluppato. Questo significa che la conservazione a lungo termine dei documenti pubblici è soggetta alle decisioni commerciali di un’azienda privata.
Le istituzioni culturali, come biblioteche, archivi e musei, affrontano lo stesso problema su scale temporali molto più estese. Un formato aperto e standardizzato ha maggiori probabilità di rimanere leggibile nel tempo rispetto a un formato proprietario, il cui supporto continuativo dipende dalle priorità strategiche di un unico vendor.
Per le economie in via di sviluppo e le organizzazioni di interesse pubblico con risorse limitate, gli standard aperti forniscono un’infrastruttura vitale che garantisce pari accesso.
Leggere l’aspetto tecnico in chiave politica
Quando si valuta uno standard, i dettagli tecnici assumono una dimensione politica.
L’uso di #RRGGBB per i colori anziché di un sistema proprietario non è una scelta estetica, perché influisce su chi può implementare il formato e su chi beneficia dell’ecosistema che esso crea.
Adottare lo standard ISO 8601 per le date anziché un sistema seriale ereditato da un singolo software proprietario basato su un bug vecchio di cinquant’anni significa scegliere l’interoperabilità piuttosto che la continuità con un passato proprietario.
Queste scelte si sommano.
Uno standard costantemente allineato a pratiche aperte e consolidate, anziché a reinvenzioni proprietarie, è diverso da un formato proprietario che fa costantemente il contrario, anche se entrambi producono documenti che appaiono identici sullo schermo e recano l’etichetta di “standard aperto”. Un’etichetta che significa ben poco.
Quello che conta è se gli sviluppatori indipendenti possano realizzare software pienamente conforme e se l’ecosistema è realmente accessibile a tutti coloro che desiderano partecipare. Infatti, lo standard deve servire gli interessi degli utenti e non quelli dell’azienda che lo ha definito.
Si tratta di questioni politiche che meritano una maggiore atteGli standard sono documenti tecnici redatti dagli ingegneri e discussi nei comitati prima di essere implementati nel codice. Tuttavia, parlarne solo in termini tecnici significherebbe trascurare un aspetto essenziale della loro natura e funzione. Infatti, gli standard sono anche – e soprattutto – strumenti politici, perché definiscono gli attori del mercato, determinano la direzione dello sviluppo e stabiliscono gli interessi serviti dall’ecosistema. In altre parole, sono alla base dei rapporti di potere del mercato. Cosa fa uno standard Uno standard è un meccanismo di coordinamento che consente a più attori indipendenti, come sviluppatori di software, produttori di hardware, creatori di contenuti, governi e imprese, di collaborare senza dover negoziare ogni volta i termini della loro interazione. Come una lingua, uno standard consente la comunicazione con chiunque lo parli. È una promessa di comunicazione universale di immenso valore, ed è il motivo per cui gli standard sono così importanti nell’informatica, dove gli effetti di rete della compatibilità si moltiplicano rapidamente. Tuttavia, uno standard definisce anche le condizioni di partecipazione. Uno standard semplice e trasparente, basato su conoscenze ampiamente disponibili, può essere implementato da più attori senza creare disuguaglianze. Al contrario, uno standard complesso e volutamente oscuro, che richiede competenze specifiche, può essere implementato correttamente solo da chi lo ha definito, creando così disuguaglianza. Pertanto, la complessità di uno standard funge da barriera, determinando sia chi può accedere al mercato sia gli equilibri di potere al suo interno. Gli ecosistemi aperti Un ecosistema aperto non dipende da un documento che contiene le specifiche dello standard, ma piuttosto dalla capacità di qualsiasi soggetto interessato di implementare lo standard in modo completo e corretto secondo le specifiche, senza ricorrere a comportamenti non documentati o al reverse engineering. Questo richiede che le specifiche siano chiare e lascino spazio a una sola interpretazione, e che lo standard non dipenda da comportamenti definiti da una sola implementazione, perché questo la renderebbe una dipendenza obbligatoria. Inoltre, richiede coerenza, per impedire che le implementazioni conformi diventino obsolete a causa di revisioni silenziose. Quando tutte queste condizioni sono soddisfatte, lo standard può essere implementato da chiunque, anche da chi non ha avuto alcun ruolo nella sua creazione. Università, piccole imprese, comunità open source, agenzie governative e singoli sviluppatori possono tutti produrre software conforme. La concorrenza è possibile sulla base della qualità dell’implementazione, e non sulla vicinanza agli autori dello standard o sul reverse engineering. Lo standard fornisce una base su cui chiunque può costruire. Gli ecosistemi chiusi La chiusura di un ecosistema attraverso uno standard può essere casuale, ma nella maggior parte dei casi è intenzionale e si basa su dei meccanismi abbastanza facili da elencare. Il primo meccanismo è l’inutile complessità. Quando uno standard definisce le proprie soluzioni a problemi che hanno già soluzioni valide e ampiamente implementate, costringe gli altri attori a reinventare la classica ruota. Ogni sottosistema proprietario è un nuovo elemento che aumenta i costi e spesso limita artificialmente la compatibilità. Il secondo meccanismo è la sottodeterminazione. Quando le specifiche sono ambigue o limitate, ogni implementazione produce un risultato diverso. Quando un documento viene visualizzato in modo leggermente diverso, gli utenti danno sempre la colpa alla seconda applicazione piuttosto che al formato. Si tratta di una forma estremamente insidiosa di lock-in. Se le specifiche consentono l’aggiunta di estensioni proprietarie, il documento può essere tecnicamente conforme allo standard, ma solo un programma è in grado di visualizzarlo correttamente. In questo caso, lo standard nasconde un sistema proprietario. Oltre a questi tre meccanismi, esiste un’influenza diretta o indiretta sugli organismi di standardizzazione. L’influenza diretta si verifica quando il fornitore può influenzare il processo di standardizzazione stesso, modellando i requisiti di conformità in modo che corrispondano al comportamento della propria applicazione. L’influenza indiretta si verifica quando il fornitore può influenzare altri membri attraverso fattori esterni al processo di standardizzazione. La posta in gioco va oltre il software Le conseguenze degli standard aperti e chiusi non riguardano solo gli sviluppatori di software. Per esempio, un governo che archivia i propri documenti in un formato che viene gestito correttamente solo da un software dipende, di fatto, dal vendor che lo ha sviluppato. Questo significa che la conservazione a lungo termine dei documenti pubblici è soggetta alle decisioni commerciali di un’azienda privata. Le istituzioni culturali, come biblioteche, archivi e musei, affrontano lo stesso problema su scale temporali molto più estese. Un formato aperto e standardizzato ha maggiori probabilità di rimanere leggibile nel tempo rispetto a un formato proprietario, il cui supporto continuativo dipende dalle priorità strategiche di un unico vendor. Per le economie in via di sviluppo e le organizzazioni di interesse pubblico con risorse limitate, gli standard aperti forniscono un’infrastruttura vitale che garantisce pari accesso. Leggere l’aspetto tecnico in chiave politica Quando si valuta uno standard, i dettagli tecnici assumono una dimensione politica. L’uso di #RRGGBB per i colori anziché di un sistema proprietario non è una scelta estetica, perché influisce su chi può implementare il formato e su chi beneficia dell’ecosistema che esso crea. Adottare lo standard ISO 8601 per le date anziché un sistema seriale ereditato da un singolo software proprietario basato su un bug vecchio di cinquant’anni significa scegliere l’interoperabilità piuttosto che la continuità con un passato proprietario. Queste scelte si sommano. Uno standard costantemente allineato a pratiche aperte e consolidate, anziché a reinvenzioni proprietarie, è diverso da un formato proprietario che fa costantemente il contrario, anche se entrambi producono documenti che appaiono identici sullo schermo e recano l’etichetta di “standard aperto”. Un’etichetta che significa ben poco. Quello che conta è se gli sviluppatori indipendenti possano realizzare software pienamente conforme e se l’ecosistema è realmente accessibile a tutti coloro che desiderano partecipare. Infatti, lo standard deve servire gli interessi degli utenti e non quelli dell’azienda che lo ha definito. Si tratta di questioni politiche che meritano una maggiore attenzione, e che andrebbero discusse in quanto tali, da quella classe politica che utilizza la scusa della scarsa competenza tecnica per lasciarle nelle mani delle Big Tech.nzione, e che andrebbero discusse in quanto tali, da quella classe politica che utilizza la scusa della scarsa competenza tecnica per lasciarle nelle mani delle Big Tech.