{"id":572,"date":"2015-10-12T15:02:04","date_gmt":"2015-10-12T13:02:04","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/standardizzazione-e-open-web\/"},"modified":"2015-10-12T15:02:04","modified_gmt":"2015-10-12T13:02:04","slug":"standardizzazione-e-open-web","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/standardizzazione-e-open-web\/","title":{"rendered":"Standardizzazione e Open Web"},"content":{"rendered":"

Abbiamo smesso di litigare sull’importanza degli standard web. Accessibilit\u00e0, stabilit\u00e0, controllo della qualit\u00e0 e facilit\u00e0 d’uso hanno tutti contribuito a sedare il dibattito molto tempo fa. I siti web di \u201cadvocacy\u201d creati per promuovere gli standard web, come Web Standards for Business<\/a> di Chris Heilmann e The Web Standards Project<\/a> non hanno dovuto cambiare pi\u00f9 a partire dalla met\u00e0 degli anni 2000.<\/p>\n

Quello che \u00e8<\/em> cambiato, tuttavia, \u00e8 il modo in cui gli standard si sono sviluppati, una questione probabilmente tanto importante quanto gli standard stessi. Quindi, il prossimo dibattito della community non \u00e8 sugli standard web, ma sul modo in cui dovrebbero essere standardizzati gli standard web.<\/p>\n

\n

Cos’\u00e8 uno standard?<\/h2>\n

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<\/a> dichiara che \u00e8 uno \u201cStandard per creare API in JSON\u201d. La pagina FAQ descrive JSON API come una specifica<\/a> e gli sviluppatori parlano dei suoi utilizzi in termini di compliance<\/a>. Un progetto concorrente, HAL<\/a>, 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<\/a>.<\/p>\n

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<\/em>, un’idea per un approccio \u201cbest practice\u201d a un problema di uso comune che si sta diffondendo organicamente all’interno della community dei developer.<\/p>\n

Le specifiche a cui tendiamo a pensare pi\u00f9 comunemente, come quelle per HTML e JavaScript, sono standard a consenso volontario<\/em>, 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\u00e0 due specifiche a consenso volontario in competizione tra loro: una con il gruppo di standard Ecma<\/a>, l’altra con IETF.<\/p>\n

Sebbene qui stiamo usando il termine \u201cstandard\u201d 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\u00e9 si tratta di idee teoriche per il modo in cui qualcosa potrebbe<\/em> funzionare, quindi, tutti gli standard hanno una specifica ma non tutte le specifiche sono standard.<\/p>\n<\/div>\n

\n

Creare gli standard<\/h2>\n

Gli standard \u201cufficiali\u201d sono specifiche che sono passate attraverso un processo di consenso volontario. C’\u00e8 potenzialmente un percorso chiaro per i progetti perch\u00e9 evolvano da una specifica de facto ad una che sia standardizzata attraverso consenso volontario:<\/p>\n

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

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

    \u00c8 esaltante pensare che il prossimo standard web ufficiale potrebbe venire dalla comunit\u00e0 dei developer, ma in pratica questo percorso verso la standardizzazione ufficiale \u00e8 stato offuscato. Il Responsive Images Community Group<\/a> l’ha vissuto in prima persona quando ha proposto una specifica per l’elemento picture<\/code>: 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<\/a>, maintainer del \u201cliving\u201d HTML standard. In una serie di eventi ben documentati<\/a> 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.<\/p>\n

    La specifica del RICG \u00e8 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 \u201cun processo che crea tecnologia\u201d ma come \u201cun processo che mette d’accordo sulla tecnologia\u201d?<\/p>\n

    In realt\u00e0, la open standardization<\/a> \u00e8 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<\/a>, abbiamo creato tecnologie web nello stile da bazar dell’ethos dello sviluppo open source, ma standardizzare queste tecnologie \u00e8 un’attivit\u00e0 simile alla costruzione di cattedrali.<\/p>\n

    Cercando di standardizzare la tecnologia, dobbiamo riconoscere la tensione proprio dalle costruzione di cattedrali che poi diventeranno autorit\u00e0 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\u00e0. 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.<\/p>\n<\/div>\n

    \n

    Vecchi modelli per standard moderni<\/h2>\n

    Le comunit\u00e0 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\u00e0 strutture organizzative simili, ma \u00e8 utile comprendere l’arte precedente su cui abbiamo eretto le fondamenta dei nostri community standards. Dopo tutto, la mentalit\u00e0 \u201ctieni quello che funziona\u201d funziona sul lungo termine solo se si comprende in primo luogo perch\u00e9 funziona.<\/p>\n

    \n

    I bravi programmatori sanno cosa scrivere. Quelli eccellenti sanno cosa riscrivere (e riutilizzare).<\/p>\n

    Eric Raymond<\/p>\n<\/blockquote>\n

    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<\/a>, l’American Society of Mechanical Engineers<\/a> e l’American Institute of Electrical Engineers<\/a>. Molti facevano \u201ccongressi\u201d regolari, i precursori vittoriani delle odierne conferenze sullo sviluppo del web, che contribuivano alla creazione di standard e a definire ulteriormente l’identit\u00e0 degli ingegneri professionisti.<\/p>\n

    Man mano che le discipline ingegneristiche cominciavano a sovrapporsi, risult\u00f2 evidente che fosse necessaria la cooperazione tra queste societ\u00e0 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’\u201corganizzazione delle organizzazioni\u201d, che facilit\u00f2 la creazione di consensi tra pi\u00f9 organizzazioni ingegneristiche, ciascuna formata da un diverso gruppo di ingegneri provenienti da diversi insiemi di aziende.<\/p>\n

    Oggi, l’AESC \u00e8 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 \u201ccultura da laboratorio\u201d e gli accademici con la loro \u201ccultura scolastica\u201d. Una certa quantit\u00e0 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 \u00e8 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.<\/p>\n<\/div>\n

    \n

    Quando gli ideali sono in competizione<\/h2>\n

    \u201cOpenness\u201d \u00e8 un ideale centrale nella community dell’Open Web, ma \u00e8 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<\/a><\/cite>, il professor Andrew Russell fa notare che \u201cper i singoli individui, \u2018open\u2019 \u00e8 l’abbreviazione di trasparente, accogliente, partecipativo e imprenditoriale; per la societ\u00e0 nel suo insieme, open significa un grande aumento nel flusso di merci e informazioni attraverso un sistema di scambio globale e orientato al mercato\u201d. In assenza di una singola definizione che soddisfi tutte le parti, tendiamo a dare a \u201copen\u201d il significato di \u201ctutto compreso\u201d.<\/p>\n

    D’altro canto, la standardizzazione \u00e8 spesso un processo che definisce cosa \u00e8<\/em> qualcosa in termini di cosa non \u00e8<\/em>. Russell fa notare che l’obiettivo pi\u00f9 grande della societ\u00e0 per la standardizzazione della tecnologia \u00e8 la creazione di una \u201crete coesa e flessibile\u201d che sostenga un’attivit\u00e0 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.<\/p>\n

    Nella creazione del sottocomitato ISO per lo sviluppo degli standard open funzionanti nel 1977, Charles Bachmann not\u00f2 che \u201cl’aggettivo \u2018open\u2019 voleva implicare l’idea che tutti i partecipanti facessero parte del sistema come partner paritari.\u201d. In realt\u00e0, i partecipanti spesso non giungono al tavolo come partner paritari: il progresso dell’OSI \u00e8 stato ostacolato da trame di potere delle organizzazioni e dalla crescita di una tecnologia in concorrenza: TCP\/IP. Ma \u00e8 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 \u201caperto\u201d.<\/p>\n

    Se gli standard sono davvero accordi tra parti uguali, allora l’accordo \u00e8 l’autorit\u00e0 di controllo. E se l’impostazione degli standard \u00e8 un rifiuto del controllo centralizzato, allora il processo di standardizzazione diventa un processo di distruzione creativa<\/a>. \u00c8 il cerchio ideologico della vita della realizzazione di un open standard: un gruppo crea uno standard tecnologico su cui c’\u00e8 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.<\/p>\n<\/div>\n

    \n

    \u00c8 complicato<\/h2>\n

    \u00c8 un web intricato quello che tessiamo standardizzando l’Open Web: \u00e8 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\u00f9 attenta, si pu\u00f2 vedere che queste organizzazioni e comunit\u00e0 sono sistemi complessi che formano un network complesso, cos\u00ec complesso che sono stata costretta a creare questo grafico interattivo del network degli Open Standards<\/a> per aiutarmi ad avere le idee chiare mentre facevo le ricerche.<\/p>\n

    Prima di correre a creare una rete complessa e decentralizzata dei gruppi degli open source standard, \u00e8 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\u00e0 del sistema \u00e8 fallire in maniera intelligente e, se la ricerca mi ha insegnato qualcosa, \u00e8 che la standardizzazione fallisce sull’elemento umano, non su quello tecnologico. Nel bene o nel male, la complessit\u00e0 non \u00e8 virale, quindi, per mitigare questo, dobbiamo rendere consumabile la complessit\u00e0 del sistema di standardizzazione senza astrarre dalle parti significative del processo.<\/p>\n

    In assenza di una coordinazione da parte della comunit\u00e0, seguir\u00e0 un entusiasmo senza metodo e la comunit\u00e0 degli sviluppatori si perder\u00e0 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\u00ec come capire le specifiche tecniche delle nostre tecnologie.<\/p>\n

    Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    In che modo gli standard web diventano, ehm, standard? Sebbene siano spesso formalizzati dalle organizzazioni ufficiali che si occupano di creare standard, possono anche emergere attraverso pratiche popolari all’interno della comunit\u00e0 degli sviluppatori. Se entrambe le parti non lavorano insieme, si rischia di rallentarne l’implementazione, di soffocare la creativit\u00e0 e di perdere terreno per colpa della politica e di una certa paralisi. Jory Burson fa luce su cosa storicamente ha sostenuto i processi di standardizzazione del web e cosa questo significhi per il futuro dell’open web.<\/p>\n","protected":false},"author":818,"featured_media":7000776,"comment_status":"open","ping_status":"open","template":"","categories":[252,247,135,257],"tags":[],"coauthors":[459],"class_list":["post-572","article","type-article","status-publish","has-post-thumbnail","hentry","category-community","category-html","category-numero-118-12-ottobre-2015","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000776"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=572"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}