Standardizzazione e Open Web

Cos’è uno standard?#section1

L’idea che la standardizzazione sia importante si riflette nel linguaggio che usiamo per descrivere i nostri progetti e le nostre community. Per esempio, l’homepage della JSON API dichiara che è uno “Standard per creare API in JSON”. La pagina FAQ descrive JSON API come una specifica e gli sviluppatori parlano dei suoi utilizzi in termini di compliance. Un progetto concorrente, HAL, fa riferimento al linguaggio visuale della standardizzazione sul suo sito web, con il flusso della pagina che ricorda una Request For Comment formale, prima di indirizzarvi alla vera Internet Engineering Task Force RFC.

Questi progetti illustrano una fusione di idee sugli standard, che, se lasciate irrisolte, possono portare alla confusione. Sia la JSON API specification sia la HAL specification sono standard de facto, un’idea per un approccio “best practice” a un problema di uso comune che si sta diffondendo organicamente all’interno della community dei developer.

Le specifiche a cui tendiamo a pensare più comunemente, come quelle per HTML e JavaScript, sono standard a consenso volontario, il che significa che gli enti e i consorzi industriali che realizzano gli standard internazionali sono concordi sull’adozione di queste specifiche e creano incentivi per la loro implementazione. Ma anche in un ambiente a consenso volontario, le differenze di opinione possono dividere una tecnologia: JSON (da non confondersi con la JSON API) ha in realtà due specifiche a consenso volontario in competizione tra loro: una con il gruppo di standard Ecma, l’altra con IETF.

Sebbene qui stiamo usando il termine “standard” in tutti i casi, non tutte le specifiche sono uguali. A volte vediamo addirittura delle RFC per specifiche tecniche che non diventeranno mai standard, perché si tratta di idee teoriche per il modo in cui qualcosa potrebbe funzionare, quindi, tutti gli standard hanno una specifica ma non tutte le specifiche sono standard.

Creare gli standard#section2

Gli standard “ufficiali” sono specifiche che sono passate attraverso un processo di consenso volontario. C’è potenzialmente un percorso chiaro per i progetti perché evolvano da una specifica de facto ad una che sia standardizzata attraverso consenso volontario:

1. Lo sviluppatore identifica un problema e propone una soluzione ai suoi pari.
2. La comunità dei sui pari (peers) fornisce un feedback e propone soluzioni alternative potenziali su canali pubblici come GitHub o Google Groups.
3. La comunità dei pari raggiunge un consenso di massa e dà la specifica all’ente che si occupa della standardizzazione.
4. Gli sviluppatori implementano una soluzione mentre l’ente degli standard formalizza e legalizza lo standard.

La maggior parte dei developer che conosco sono intelligenti, pieni di risorse e preferiscono la via più facile: grazie alla mentalità tutti i bug vengono a galla della comunità degli OSS, sono inclini a lavorare insieme per risolvere questioni di interesse comune. È un’idea piuttosto semplice e per nulla nuova, e The Extensible Web Manifesto è sostanzialmente una call to action ad implementare più feedback da parte degli sviluppatori in questo stesso processo.

È esaltante pensare che il prossimo standard web ufficiale potrebbe venire dalla comunità dei developer, ma in pratica questo percorso verso la standardizzazione ufficiale è stato offuscato. Il Responsive Images Community Group l’ha vissuto in prima persona quando ha proposto una specifica per l’elemento picture: notando un problema nel modo in cui HTML gestiva le immagini responsive, il RICG ha proposto una soluzione de facto creata da uno sviluppatore al Web Hypertext Application Technology Working Group, maintainer del “living” HTML standard. In una serie di eventi ben documentati il WHATWG ha praticamente respinto la soluzione degli sviluppatori a favore di una soluzione vagamente specificata che avevano creato in alcuni giorni. Se non fosse stato per la passione e la persistenza della community e della leadership del RICG, la soluzione degli sviluppatori sarebbe stata sconfitta.

La specifica del RICG è stata alla fine accettata dal WHATWG e dal W3C, ma l’esperienza del processo di standardizzazione ha sicuramente lasciato l’amaro in bocca agli sviluppatori. Sarebbe sufficientemente facile focalizzare la nostra attenzione sul migliorare questo processo per i community group come il RICG e il web sarebbe sicuramente un posto migliore per gli sviluppatori se lo facessimo, ma non sarebbe bello se potessimo definire la standardizzazione non come “un processo che crea tecnologia” ma come “un processo che mette d’accordo sulla tecnologia”?

In realtà, la open standardization è un processo fondamentalmente schiacciato dal potere e dalla politica e sta prendendo piede nel nostro modo di pensare al progetto dell’Open Source e alla community governance. Esprimendoci con le parole del fondamentale saggio di Eric Raymond, abbiamo creato tecnologie web nello stile da bazar dell’ethos dello sviluppo open source, ma standardizzare queste tecnologie è un’attività simile alla costruzione di cattedrali.

Cercando di standardizzare la tecnologia, dobbiamo riconoscere la tensione proprio dalle costruzione di cattedrali che poi diventeranno autorità centrali che rifiuteremo. La nostra sfida consiste nel trovare un equilibrio tra il capitalizzare sui vantaggi dei processi di standardizzazione senza erodere gli ideali della nostra comunità. Fortunatamente, ci sono lunghe storie di sforzi di standardizzazione negli altri settori e in altre community che possono fornirci delle idee per standardizzare il web.

Vecchi modelli per standard moderni#section3

Le comunità dell’open source possono imparare molto dalle storie e dai modelli di governance delle varie organizzazioni degli standard: sicuramente, i consorzi per gli standard come Ecma International e il W3C hanno già strutture organizzative simili, ma è utile comprendere l’arte precedente su cui abbiamo eretto le fondamenta dei nostri community standards. Dopo tutto, la mentalità “tieni quello che funziona” funziona sul lungo termine solo se si comprende in primo luogo perché funziona.

I bravi programmatori sanno cosa scrivere. Quelli eccellenti sanno cosa riscrivere (e riutilizzare).

Eric Raymond

Le origini ideologiche degli organismi degli standard web derivano dagli sforzi iniziali per standardizzare la telegrafia e l’ingegneria nel XIX secolo, attraverso comitati come l’American Society of Civil Engineers, l’American Society of Mechanical Engineers e l’American Institute of Electrical Engineers. Molti facevano “congressi” regolari, i precursori vittoriani delle odierne conferenze sullo sviluppo del web, che contribuivano alla creazione di standard e a definire ulteriormente l’identità degli ingegneri professionisti.

Man mano che le discipline ingegneristiche cominciavano a sovrapporsi, risultò evidente che fosse necessaria la cooperazione tra queste società industriali, quindi nel 1918 fu creato l’American Engineering Standards Committee per incoraggiare la cooperazione e la coordinazione degli standard fra i vari gruppi. La struttura risultante fu un’“organizzazione delle organizzazioni”, che facilitò la creazione di consensi tra più organizzazioni ingegneristiche, ciascuna formata da un diverso gruppo di ingegneri provenienti da diversi insiemi di aziende.

Oggi, l’AESC è noto come l’American National Standards Institute, ma il suo modello di governance centenario, pieno di crisi e ideali comunitari, si riflette nei gruppi degli standard web. Allora come oggi, si ergono spesso dispute organizzative tra i practictioner con la loro “cultura da laboratorio” e gli accademici con la loro “cultura scolastica”. Una certa quantità di tensione tra i gruppi giova all’avanzamento delle idee e questi gruppi iniziali si sono evoluti in mezzi organizzativi per creare e rilasciare tensione al bisogno. L’odierna risposta di default alle dispute sul software open-source è di fare una fork della specifica in questione, producendo una rete di campi rivali che sono incentivati a enfatizzare le differenze invece che le aree di accordo.

Quando gli ideali sono in competizione#section4

“Openness” è un ideale centrale nella community dell’Open Web, ma è anche una sorta di parola inquinata. La retorica dell’apertura aveva come scopo la comunicazione di un insieme di valori positivi e questi valori spesso dipendono da chi parla e da chi ascolta. Nel suo libro Open Standards and the Digital Age, il professor Andrew Russell fa notare che “per i singoli individui, ‘open’ è l’abbreviazione di trasparente, accogliente, partecipativo e imprenditoriale; per la società nel suo insieme, open significa un grande aumento nel flusso di merci e informazioni attraverso un sistema di scambio globale e orientato al mercato”. In assenza di una singola definizione che soddisfi tutte le parti, tendiamo a dare a “open” il significato di “tutto compreso”.

D’altro canto, la standardizzazione è spesso un processo che definisce cosa è qualcosa in termini di cosa non è. Russell fa notare che l’obiettivo più grande della società per la standardizzazione della tecnologia è la creazione di una “rete coesa e flessibile” che sostenga un’attività sociale ed economica complessa. Pertanto, il processo di creazione degli standard consiste nell’incorporare un gran range di pratiche e di idee con dimensioni politiche, economiche e culturali che potrebbero essere di importanza strategica per i creatori, per gli implementatori, per gli utenti finali e per il pubblico generale. Messi in questo modo, gli standard sono istanze technically-oriented della diplomazia.

Nella creazione del sottocomitato ISO per lo sviluppo degli standard open funzionanti nel 1977, Charles Bachmann notò che “l’aggettivo ‘open’ voleva implicare l’idea che tutti i partecipanti facessero parte del sistema come partner paritari.”. In realtà, i partecipanti spesso non giungono al tavolo come partner paritari: il progresso dell’OSI è stato ostacolato da trame di potere delle organizzazioni e dalla crescita di una tecnologia in concorrenza: TCP/IP. Ma è rimasto l’ideale di eguaglianza della creazione degli open standard. Questo ideale ha le sue radici in una forte opposizione al potere centralizzato, che, secondo Russell, si riflette nelle storie di molte organizzazioni che decidono gli standard. Sostenere questa visione di eguaglianza e ottenere un’implementazione di successo, a volte ha significato nascondere i conflitti e le problematiche dalle persone al di fuori delle riunioni: non esattamente quel comportamento trasparente che ci si aspetterebbe da un sistema “aperto”.

Se gli standard sono davvero accordi tra parti uguali, allora l’accordo è l’autorità di controllo. E se l’impostazione degli standard è un rifiuto del controllo centralizzato, allora il processo di standardizzazione diventa un processo di distruzione creativa. È il cerchio ideologico della vita della realizzazione di un open standard: un gruppo crea uno standard tecnologico su cui c’è consenso; man mano che lo standard va in giro, si solleva una nuova fazione per segnalare una pecca o uno use case che non era stato preso in considerazione per lo standard esistente. Il gruppo originale deve quindi fare spazio per la nuova fazione e per modificare lo standard, altrimenti va incontro al rifiuto del gruppo e dello standard. Respingendo il gruppo originale, la parte offesa forma un gruppo e uno standard in competizione e il ciclo comincia da capo.

È complicato#section5

È un web intricato quello che tessiamo standardizzando l’Open Web: è difficile verificare a prima vista le relazioni politiche, economiche e sociali tra le persone, le tecnologie, le aziende e i gruppi di settore. Ad un’ispezione più attenta, si può vedere che queste organizzazioni e comunità sono sistemi complessi che formano un network complesso, così complesso che sono stata costretta a creare questo grafico interattivo del network degli Open Standards per aiutarmi ad avere le idee chiare mentre facevo le ricerche.

Prima di correre a creare una rete complessa e decentralizzata dei gruppi degli open source standard, è probabilmente meglio citare che i sistemi complessi falliscono il 100% delle volte. Una rete decentralizzata potrebbe, nella maggior parte dei casi, permetterci di commettere meno errori, ma la chiave per la longevità del sistema è fallire in maniera intelligente e, se la ricerca mi ha insegnato qualcosa, è che la standardizzazione fallisce sull’elemento umano, non su quello tecnologico. Nel bene o nel male, la complessità non è virale, quindi, per mitigare questo, dobbiamo rendere consumabile la complessità del sistema di standardizzazione senza astrarre dalle parti significative del processo.

In assenza di una coordinazione da parte della comunità, seguirà un entusiasmo senza metodo e la comunità degli sviluppatori si perderà nel Triangolo delle Bermuda degli enti di standardizzazione, degli implementatori e dei maintainers di OSS in competizione tra loro. Se vogliamo che i nostri progetti community-driven diventino standard ufficiali, riconosciuti internazionalmente, dobbiamo comprendere l’impatto dei nostri processi di governance così come capire le specifiche tecniche delle nostre tecnologie.

Illustrazioni: {carlok}