Monopoli e architettura della rete · 2016-06-04 by mmzz
A favorire i monopoli non sono solo le regole del mercato (o l’assenza di esse), ma anche l’attuale architettura della rete (o l’assenza di essa).
Non voglio fare il nostalgico, ma Internet è cambiata molto, e non per il meglio.
Se invece di avere già SMTP lasciassimo il servizio di email al mercato, nel contesto competitivo di oggi, cosa avremmo?
Quattro/cinque operatori, ciascuno con applicazioni verticali non interoperabili: uno per Apple/iPhone, uno per Google/Android, uno di IBM, eccetera.
L’utente sarebbe un captive customer e dovrebbe avere una casella email per ciascuno per poter scrivere a tutti.
Esattamente come negli anni ’80: avevamo i servizi mail di SNA, BitNET, DECNET, Fidonet, OSI X.400, uucp, …
Tutte cose sbaragliate da TCP/IP+SMTP, non perchè fosse tecnicamente superiore, ma perché era open e interoperabile.
Adesso, se voglio spedire posta, devo rispettare RFC 821 e successivi, e il modello di business è cosa che riguarda me e i miei utenti.
Ci guadagno, ci perdo? Basta che rispetti lo standard. Se mi comporto male l’utente se ne va da un’altro e la concorrenza è fatta, perché l’utente può scegliere.
Nessun regolatore deve intervenire, perché l’architettura favorisce il pluralismo nel mercato.
Se avessimo sviluppato i social network come abbiamo fatto con IP, TCP, SMTP, HTTP invece che farne una applicazione Web, ora ci sarebbe una famiglia di protocolli ai quale tutti si devono attenere per scambiare messaggi personali.
Poi ci sarebbero diverse applicazioni o piattaforme che li archiviano e presentano più o meno bene e che competono per servizi aggiuntivi: ci sarebbero piattaforme open, quelle a pagamento, quelle che fanno advertising.
L’utente sceglie.
(Toh, guarda, il protocollo esisterebbe, si chiama XMPP ed è decentralizzato.)
Lo stesso per le piattaforme cooperative: dovrebbe esistere un protocollo che consente il brokeraggio di un qualcosa, inclusa la valutazione di reputazione, l’interfaccia con i circuiti di scambio monetario e quant’altro serve.
Ci sarebbero una pluralità di “piattaforme”: alcune sarebbero locali, altre globali, alcune generaliste, altre specializzate.
Queste IMHO sarebbero infrastrutture al servizio dell’economia.
L’architettura originaria di Internet favoriva la concorrenza perché centrata su protocolli interoperabili tra diverse applicazioni, tipicamente decentrate, e non su applicazioni verticali centralizzate.
Oggi gli RFC sembrano fermi, tutti cercano di sviluppare applicazioni proprietarie o al massimo li usano come base per servizi proprietari.
L’espressione moto efficace usata da Moxie Marlinspike è cannibalizing a federated application-layer protocol into a centralized service, ed è a suo dire una ricetta sicura per il successo.
Avrà ragione, ma il risultato generale dell’approccio verticale centralizzatore è la corsa al monopolio.
Chi ci perde: tutti. Chi ci guadagna: chi vince. Chi può tentare di vincere: chi è già in vantaggio.
Questo ha una scia di conseguenze sugli utenti, a partire dall’assenza di scelta, passando per il lock-in fino ai problemi con i dati personali, di cui stiamo cominciando a vedere oggi l’inizio.
Regolare questo significa entrare nel merito delle tecnologie intervenendo nell’architettura delle infrastrutture della rete.
Non con le leggi, ma sviluppando protocolli e programmi migliori, aperti, interoperabili possano offrire una alternativa agli utenti delle piattaforme e creino un vero mercato.
L’UE potrebbe favorire un processo di sviluppo di infrastrutture competitive, non accettare le architetture che centralizzano e cannibalizzano Internet.
Big data bubble burst contàgio - pensieri dalla zona di interdizione