Indice dei contenuti
Visto l’enorme successo (davvero, è stato apprezzatissimo e ne siamo molto felici) dell’articolo WhatsApp e l’addomesticamento degli utenti, abbiamo deciso di tradurre la seconda parte di quell’articolo. Gli articoli originali sono stati originariamente scritti da Rohan Kumar, fortunatamente in licenza Creative Commons. Grazie a questa licenza, infatti, ci è stato possibile tradurli liberamente senza incappare in problemi di copyright. Ci avete chiesto la traduzione della seconda parte dell’articolo, anch’essa in Creative Commons. Ecco quindi che vi lasciamo subito con Keeping platforms open, che abbiamo voluto tradurre in Proteggere le piattaforme aperte.
Da qui inizia l’articolo originariamente scritto da Rohan Kumar e sotto licenza CC BY-SA 4.0 ed è stato scritto il 23 febbraio 2021 e aggiornato il 3 marzo 2021.
Proteggere le piattaforme aperte
Questo è il secondo articolo di una serie di post che identificano situazioni in cui floss (il software libero) da solo non è sufficiente per garantire la libertà dell’utente.
Il mio precedente articolo, Whatsapp e l’addomesticamento degli utenti, ha ricevuto più attenzione di quanta me ne aspettassi. Alcune risposte mi hanno dato molto a cui pensare 1 soprattutto per quel che riguarda le azioni che possiamo intraprendere. Il mio suggerimento è quello di leggere prima quell’articolo; viene spiegato cos’è l’addomesticamento dell’utente e perché è un problema. Ho elencato tre contromisure: floss, semplicità e piattaforme aperte.
I problemi complessi, per definizione, mancano di soluzioni facili. La semplice scelta (o creazione) di una piattaforma che eviti l’addomesticamento dell’utente non è sufficiente se quella piattaforma può cambiare. Il prezzo della libertà è l’eterna vigilanza; oltre a stabilirsi sulla piattaforma giusta, dobbiamo assicurarci che questa abbia cura dei suoi utenti sia nel presente che nel futuro. Mantenere una piattaforma floss facile da mantenere è più semplice 2 che proteggere una piattaforma aperta.
Come possiamo evitare che una piattaforma aperta diventi una piattaforma chiusa in futuro?
Come può una piattaforma aperta diventare chiusa?
Esistono tre modi per far sì che una piattaforma aperta diventi chiusa:
- una migrazione forzata su una piattaforma differente;
- una singola implementazione diventa dominante, a cavallo tra specifica e implementazione;
- implementazioni dominanti che adottano troppe funzionalità e comportamenti non standard.
Questi tre approcci si possono sovrapporre: spesso presentano la monocultura della piattaforma e un unico fornitore che controlla sia il client che i server.
Migrazione forzata
Quando un fornitore controlla tutte le parti di un servizio (ad esempio, sia un client che un server), ha i mezzi per creare quella che io chiamo una piattaforma in scatola: un sottoinsieme di una piattaforma aperta più grande che può evolversi indipendentemente, senza preoccuparsi della compatibilità o dell’interoperabilità.
Il controllo sia del server che del client consente a un fornitore di aggiornare il client e il server senza preoccuparsi di interrompere la compatibilità con altri client/server. Potrebbe aggiornare il client per indirizzare gli utenti a un server che utilizza un protocollo chiuso completamente diverso. Questo è quello che successe a molti utenti XMPP nei primi anni 2000.
Caso di studio: l’inscatolamento di XMPP
XMPP (precedentemente noto come Jabber) è un protocollo di messaggistica istantanea aperto e federato; chiunque può configurare il proprio server XMPP e parlare con gli utenti su diversi server XMPP, impedendo a un’organizzazione di possedere la piattaforma. Tra il 2005 e il 2014, molte piattaforme di chat proprietarie lo hanno supportato: Google Talk, AOL Instant Messenger (AIM), Facebook Chat (in seguito noto come Facebook Messenger) e Skype sono solo alcuni esempi ben noti. Alcune di queste piattaforme avevano persino abilitato la federazione da server a server.
Sfortunatamente, gli utenti di questi servizi proprietari sono stati inscatolati. Sono pochi gli utenti di Google Talk che hanno parlato con gli utenti Skype e gli utenti Skype di rado hanno parlato con gli utenti AIM. Gli utenti sono rimasti nelle proprie sotto-piattaforme. Il risultato è stato che tutti gli utenti si sono limitati a parlare esclusivamente utilizzando il software del proprio provider: un provider controllava l’intero flusso di messaggistica, dal client di un mittente al server al client di un destinatario. Gli utenti sono stati esposti solo a una singola implementazione XMPP offerta da un singolo provider.
Ciascuna delle piattaforme elencate alla fine ha bloccato i propri utenti migrando da XMPP. Ciò non sarebbe stato possibile se più implementazioni e provider avessero interagito tra loro. Immagina che Bob usi BobClient e BobServer per parlare con Alice e Alice usi AliceClient e AliceServer. BobClient, BobServer, AliceClient e AliceServer dovrebbero tutti rimanere compatibili e utilizzare lo stesso protocollo; è improbabile che si verifichi una migrazione forzata poiché interromperebbe la compatibilità.
Confronta ora la situazione con l’email: nonostante il dominio di Gmail, altri provider di posta elettronica rimangono popolari. Gli utenti di Gmail devono essere in grado di comunicare con utenti non Gmail e viceversa. L’email è molto meno inscatolata rispetto alle suddette piattaforme XMPP proprietarie. Di conseguenza, Google non è stato in grado di controllare la piattaforma di posta elettronica con la stessa facilità; Google non può semplicemente migrare gli utenti di Gmail su una piattaforma non email incompatibile con il resto del panorama della posta elettronica per addomesticare ulteriormente i suoi utenti.
XMPP è ancora vivo e vegeto, ma la sua attuale popolarità è una frazione di quello che era una volta.
Influenza dell’attuazione
Gli standard sono una sorta di accordi stipulati per garantire la compatibilità tra le implementazioni. Tali accordi devono essere concordati dalle stesse implementazioni. Quando un’implementazione diventa dominante, aumenta anche la sua influenza nel processo decisionale rispetto agli standard condivisi. Troppa dominanza può creare una monocoltura in cui l’implementazione dominante è l’unica implementazione conforme alle specifiche.
Con una leva sufficiente, un’implementazione dominante può servire come implementazione di riferimento. Le implementazioni di riferimento sono in genere molto utili e fungono da fonte di verità per testare altre implementazioni. I problemi possono sorgere quando lo sviluppo delle specifiche e l’implementazione di riferimento di livello di produzione diventano strettamente accoppiate, lasciando la fattibilità dell’implementazione di terze parti fuori dal processo decisionale.
Caso di studio: Matrix ed Element
Un esempio di questo fenomeno è Matrix. Matrix è una piattaforma di messaggistica istantanea aperta e federata simile a XMPP, con una specifica molto ampia che vanta molte funzionalità: cronologia lato server, risposte, rich text, reazioni, stanze, E2EE, avatar, nomi visualizzati, indicatori di digitazione, conferme di lettura, verifica del dispositivo … l’elenco continua e cresce ogni mese 3. L’unico client che implementa tutte le funzionalità necessarie è Element. Oltre ad essere il client più popolare, Element funge praticamente da implementazione client di riferimento: è sviluppato dalla stessa azienda che costruisce i server dominanti e la maggior parte delle specifiche. Lo stretto accoppiamento tra Element e le specifiche Matrix consentono di aggiungere funzionalità a una velocità troppo veloce per gli altri client che non riescono a tenere il passo; praticamente ogni utente di Matrix deve aprire Element ad un certo punto per eseguire un’azione che non è supportata in nessun altro client. Lato server, Synapse è l’unico server che implementa abbastanza specifiche per essere utilizzabile, con Dendrite che arriva secondo. Entrambi sono realizzati dalla stessa azienda che sviluppa Element.
Poiché non ci sono client e server di terze parti in grado di sostituire quelli ufficiali, un fornitore è vicino a controllare tutte le parti della piattaforma. La crescente complessità richiesta a client e server può anche consolidare ulteriormente queste implementazioni dominanti, come ho spiegato in precedenza. Matrix è vicino ad essere una piattaforma in scatola perché il client e il server ufficiali possono muoversi indipendentemente.
Non credo che Matrix diventerà presto una piattaforma completamente chiusa; il post del blog “On Privacy versus Freedom” sembra metterlo sul lato buono della questione chiuso/aperto. Applicazioni come gomuks e FluffyChat sembrano tenere il passo con Element abbastanza bene da servire come sostituti parziali. Tuttavia, trovo il suo stato attuale problematico e molto più vicino a chiuso nella concezione di chiuso/aperto rispetto a XMPP, IRC ed e-mail.
Feature creep non standard
Le piattaforme sono più dei loro protocolli. Implementazioni diverse hanno un comportamento unico per distinguersi. I problemi sorgono quando le funzionalità uniche non standard delle implementazioni dominanti crescono oltre un certo punto per creare un circuito chiuso all’interno di una piattaforma aperta.
Casi di studio: provider di posta elettronica
Dopo aver letto il mio precedente articolo, alcune persone mi hanno contattato per chiedere i miei pensieri su alcuni provider di posta elettronica. Non c’è molto che possa distinguere un provider di posta elettronica standard se ospita solo un semplice server di posta elettronica. Per distinguersi, i provider di posta elettronica spesso implementano molte funzionalità oltre alla conformità agli standard di posta elettronica.
La stragrande maggioranza degli account di posta elettronica proviene da una piccola manciata di provider dominanti supportati da grandi aziende (Gmail, Yahoo! Mail, Yandex Mail, Mail.ru, iCloud e altri). Provider come Gmail sono noti per l’implementazione di filtri antispam avanzati prevenuti contro i provider di posta elettronica non mainstream. Gli utenti che ospitano autonomamente server di posta elettronica o utilizzano piccoli provider spesso attivano falsi positivi e finiscono per avere i loro messaggi erroneamente etichettati come spam fino a quando non riescono a costruire una reputazione 4. L’aggiunta di un filtro antispam così complesso rafforza l’oligopolio della posta elettronica creando una barriera d’ingresso per i nuovi arrivati. I mittenti a basso volume sono discriminati, come ha scoperto Migadu:
Abbiamo già potuto vedere filtri antispam dannosi e server configurati in modo errato. In alcuni casi i server dei destinatari hanno intenzionalmente rifiutato le e-mail corrette solo perché siamo un mittente a basso volume. Ironia vuole che è così che dovrebbe essere un mittente ideale. Per migliorare la “ricevibilità” offrono ovviamente il proprio servizio di posta elettronica ospitato a un prezzo elevato.
Un altro esempio: i provider di posta elettronica come Hey.com, Protonmail e Tutanota offrono molte funzionalità incompatibili con IMAP/POP3. Protonmail e Tutanota utilizzano la propria implementazione E2EE non standard (piuttosto che concentrarsi sul miglioramento dell’UX per vanilla PGP) mentre Hey.com offre un’organizzazione della posta lato server. Gli utenti di questi servizi devono utilizzare client Web, desktop e mobile ufficiali 5. Questi tre provider controllano sia il client che il server, fornendo loro i mezzi per il vendor lock-in. Naturalmente, c’è un limite alla quantità di lock-in che questi provider possono raggiungere: come ho spiegato nel caso di studio XMPP, questi provider devono ancora supportare SMTP per rimanere compatibili con il più ampio panorama della posta elettronica.
Soluzioni
Le situazione dunque non sembra essere delle più rosee. Proviamo a concentrarci sulle azioni che utenti e fornitori possono intraprendere per mantenere aperte le piattaforme.
Cosa possono fare gli utenti
Come utente, considera l’utilizzo di client e server creati da diversi gruppi di persone per rendere più difficile l’inscatolamento della piattaforma. Scegli implementazioni che soffrono di meno feature creep. Ciò che distingue un client non dovrebbe essere quali funzionalità ha, ma come queste vengono implementate. Ovviamente, avere alcune caratteristiche uniche è fantastico; i problemi sorgono quando il numero di caratteristiche uniche supera una certa soglia. Seguire entrambe queste pratiche incoraggia le implementazioni ad attenersi alla conformità, all’affidabilità e alla compatibilità degli standard piuttosto che all’innovazione. Scegli la tecnologia noiosa piuttosto che sempre nuove funzionalità brillanti.
Prova ad avventurarti al di fuori dal mainstream dando un’occhiata a fornitori o applicazioni meno popolari. Tutte le implementazioni iniziano da qualche parte e una varietà di implementazioni impedisce una regola per l’oligopolio.
Quando scegli un client e un fornitore, considera gli incentivi del fornitore. A chi devono dar conto i tuoi fornitori? Agli utenti o agli investitori? Hanno superato il punto della sostenibilità finanziaria?
Non sto sostenendo che gli utenti medi stiano facendo qualcosa di sbagliato; aspettarsi che l’utente medio cambi il suo comportamento per il bene superiore è ingenuo. Questo consiglio è rivolto al sottoinsieme di utenti tecnici e abbastanza disposti da pensare alle piattaforme che scelgono e indirettamente mirato alle persone che possono influenzare.
Cosa possono fare i fornitori
Piuttosto che concentrarsi troppo sulla scalabilità, concentrati sul rendere il software lato server facile da installare e federare. Chiudi le iscrizioni se la tua Istanza diventa troppo grande e incoraggia le persone a utilizzare diversi provider. Ci sono diversi casi nel Fediverso che già fanno così. Non sto dicendo che il ridimensionamento non sia importante; piuttosto, sto dicendo che ridurre la barriera all’ingresso per i nuovi fornitori è un approccio alternativo efficace alla scalabilità 6.
Prendi in considerazione la licenza copyleft. Il copyleft è uno degli strumenti più potenti che abbiamo per proteggere la libertà dell’utente impedendo la creazione di opere derivate che cercano di limitare la libertà dell’utente. Ciò rende più difficile per le implementazioni alternative mantenere le modifiche per se stesse nel tentativo di inscatolare gli utenti. La GNU AGPLv3 è particolarmente efficace poiché richiede la distribuzione di codice lato server per i servizi in rete; una proliferazione virale di software con licenza AGPLv3 avrebbe potuto mitigare l’inscatolamento degli utenti XMPP nei primi anni 2000.
Le implementazioni di riferimento vanno bene se non sono troppo dominanti. Assicurati che altre implementazioni possano recuperare l’eventuale ritardo. Se necessario, rallenta l’evoluzione di una specifica, lascia che gli sviluppatori di altre implementazioni partecipino al processo decisionale e dai loro una mano a migliorare le loro implementazioni. Muoversi velocemente e rompere le cose non è l’approccio migliore.
Ad esempio, Element e la Matrix.org Foundation allevierebbero la maggior parte delle mie preoccupazioni facendo quanto segue:
- ridurre le nuove iscrizioni sul matrix.org homeserver, indirizzando gli utenti a server alternativi gestiti da persone diverse;
- adottare un approccio molto conservativo alle nuove funzionalità fino a quando più implementazioni server e client non raggiungeranno la parità con Element, Synapse e Dendrite;
- concentrarsi sulla riduzione dei requisiti di sistema per ospitare un server, riducendo la barriera all’ingresso per i nuovi provider. Questo è già in corso con lo sviluppo di Dendrite.
Svantaggi
Il più grande svantaggio del consiglio appena dato è la velocità di sviluppo. Mantenere la compatibilità e la conformità alle specifiche rallenta la velocità con cui è possibile aggiungere nuove funzionalità. Come sostiene Moxie, Signal potrebbe non essere stato in grado di implementare tante funzionalità se fosse stata una piattaforma aperta; lo sviluppo vincolato alle specifiche è, per definizione, vincolato. Gli utenti sono limitati dal minimo comune denominatore tra le implementazioni partecipanti più diffuse.
Le piattaforme aperte con più provider e implementazioni spesso soffrono di una minore usabilità, specialmente per quanto riguarda l’onboarding. Invece di aprire semplicemente l’app / sito Web ufficiale, gli utenti devono scegliere tra più client e fornitori. Questa può essere una svolta (in negativo) per gli utenti occasionali che vogliono solo provare qualcosa. Uno dei modi migliori per migliorare l’esperienza di onboarding è offrire consigli ai tuoi amici non tecnici; li conosci bene e probabilmente puoi aiutarli a prendere una decisione informata.
Paralleli ad altre situazioni
I linguaggi di programmazione guidati da uno standard piuttosto che da un’implementazione di riferimento in genere hanno una maggiore portabilità, molte buone implementazioni ed è improbabile che svaniscano nel tempo. Gli esempi includono C, C++, Common Lisp, JavaScript e POSIX Shell. Confronta questo con un linguaggio come Python: così tanti pacchetti dipendono dall’approccio dell’implementazione di riferimento CPython alle estensioni C che implementazioni alternative come PyPy devono rimanere perennemente cittadini di seconda classe.
L’approccio basato su standard e consenso allo sviluppo della piattaforma e l’inefficienza che ne deriva è un compromesso visibile in molte parti, anche al di fuori dello sviluppo del software. La maggior parte delle forme di democrazia soffre di burocrazia e lotte interne che soffocano il progresso. Alcuni hanno sostenuto che l’inefficienza della democrazia è una caratteristica, non un bug. Come dice Nathan Myhrvold:
La ragione per cui le società con governi democratici sono posti migliori in cui vivere rispetto alle loro alternative non è a causa di qualche bontà intrinseca alla democrazia, ma perché la sua inefficienza senza speranza aiuta a smussare il potenziale di base del male. Il vincolo di mantenere una popolarità costante è semplicemente un peso troppo grande da sopportare. Quindi, fortunatamente, viene fatto molto poco che sia estremamente cattivo o estremamente buono.
Nathan Myhrvold
Forse il più grande vantaggio di abbandonare la mentalità “muoviti velocemente e rompi le cose” è che oltre a rendere difficile migliorare rapidamente un servizio, abbandonare questo tipo di mentalità rende anche difficile peggiorare rapidamente un servizio.
Riconoscimenti
Denver Gingerich mi ha aiutato a fare brainstorming all’inizio del processo di scrittura e mi ha fornito informazioni utili per la sezione su XMPP.
Grazie a Barna Zsombor e carbolymer per aver dato un buon feedback su IRC.
- Questo commento in particolare[↩]
- si prega di notare che le parole “facile” e “semplice” non sono intercambiabili, sebbene abbiano alcune sovrapposizioni[↩]
- Vedi This Week in Matrix, un blog settimanale di aggiornamenti su Matrix. In particolare guarda gli aggiornamenti delle specifiche.[↩]
- I consigli ufficiali di Google e AWS descrivono questo comportamento nel dettaglio[↩]
- Protonmail offre il proprio bridge che traduce l’API Protonmail in IMAP, consentendo agli utenti di utilizzare i propri client di posta preferiti. Ciò non cambia ancora il fatto che gli utenti devono utilizzare client ufficiali; in questo caso, il client ufficiale è il programma bridge stesso[↩]
- Ho deciso di non usare il sottotitolo sfacciato “La scalabilità è dannosa” perché temevo che i lettori di un determinato sito Web di colore arancione potessero prendere troppo sul serio lo scherzo[↩]
Unisciti alle comunità
