Nel 2000 per mettere insieme uno stack di lavoro libero dovevi compilare a mano metà degli strumenti; nel 2010 lo stesso stack si installa con un comando e regge un progetto in produzione. È questo lo scarto concreto tra due decenni di pratica open source, e si misura in ore di lavoro risparmiate su ogni cantiere.

Scrivo da chi monta siti e applicazioni per mestiere, non da chi studia le licenze di professione. Faccio un consuntivo da artigiano: cosa è cambiato negli strumenti liberi tra l’inizio del decennio e oggi, e dove i cambiamenti hanno spostato sul serio il modo di lavorare.

Il contesto

L’Open Source Initiative ha messo nero su bianco la Open Source Definition nel 1998, ricavandola dalle Debian Free Software Guidelines, e nel 1999 ha pubblicato la prima lista di licenze approvate (https://opensource.org/about/history-of-the-open-source-initiative). All’inizio del decennio, quindi, il vocabolario era già fissato: dieci criteri, una procedura di approvazione, una linea netta tra ciò che è libero e ciò che è soltanto gratuito.

A quel tempo il problema non era la teoria delle licenze, ma avere gli strumenti pronti all’uso. Un server LAMP — Linux, Apache, MySQL, PHP o Perl — lo mettevi in piedi, ma ogni pezzo andava configurato per conto suo, e aggiornarne uno rischiava di rompere gli altri. Quello che è maturato nel decennio successivo è la distribuzione e l’integrazione, non i princìpi: quelli erano già fermi nel 1999.

Il controllo di versione distribuito

Nel mio lavoro di tutti i giorni il cambiamento più vistoso è il passaggio dal controllo di versione centralizzato a quello distribuito. Per quasi tutto il decennio lo standard pratico è stato Subversion, erede di CVS: un server unico, una copia di lavoro a testa, nessuna storia in locale.

Lo spostamento ha una data e una causa precise. Nell’aprile 2005 Bitmover ha tolto la licenza gratuita a BitKeeper, lo strumento proprietario usato fino ad allora per lo sviluppo del kernel Linux. Nel giro di poche settimane sono nati due sistemi distribuiti destinati a restare: Git, il cui primo commit è del 7 aprile 2005, con la versione 1.0 rilasciata il 21 dicembre dello stesso anno sotto la cura di Junio Hamano (https://en.wikipedia.org/wiki/Git); e Mercurial, annunciato da Matt Mackall il 19 aprile 2005, con il primo tarball 0.1 del 27 maggio (https://en.wikipedia.org/wiki/Mercurial).

A separarli da Subversion è il modello dei dati, più della velocità — che pure c’è. In un sistema distribuito ogni copia di lavoro porta con sé la storia completa del progetto: ramificare, fondere e frugare nel passato sono operazioni locali, che non chiedono né la rete né i permessi su un server centrale. Il branch smette così di essere un’operazione costosa da pianificare e diventa il modo ordinario di isolare un esperimento o una correzione.

Com’è fatto uno stack libero nel 2010

Lo stack che oggi uso per un sito tipico è interamente libero, e lo installo come insieme coerente con il gestore di pacchetti della distribuzione.

  • Sistema e server: una distribuzione Linux con Apache httpd o, sempre più spesso, nginx, comparso nel 2004 e adottato perché regge bene molte connessioni in parallelo.
  • Persistenza: MySQL o PostgreSQL, ormai maturi entrambi, con il secondo preferibile dove servono integrità referenziale e transazioni.
  • Linguaggio applicativo: PHP per la gran parte del web a contenuti, con framework liberi ormai stabili; oppure Python o Ruby quando il dominio giustifica un framework più strutturato.
  • Controllo di versione: Git o Mercurial, con il repository che fa anche da meccanismo di rilascio verso il server.

A cambiare rispetto a dieci anni fa non sono i singoli mattoni — c’erano quasi tutti già allora — ma il fatto che la distribuzione li tiene allineati. Un aggiornamento di sicurezza arriva firmato e collaudato contro il resto del sistema; le dipendenze sono dichiarate; un secondo sviluppatore rifà l’ambiente leggendo un elenco di pacchetti invece di un foglio di istruzioni.

Il punto critico: la licenza è una scelta di architettura

La parte del decennio più facile da sottovalutare riguarda le licenze. Il 29 giugno 2007 la Free Software Foundation ha pubblicato la versione 3 della GPL, dopo diciotto mesi di consultazione pubblica e quattro bozze (https://www.fsf.org/news/gplv3_launched). La GPLv3 affronta tre questioni che la versione 2 del 1991 non poteva prevedere: la compatibilità con altre licenze libere, i brevetti software e la cosiddetta tivoizzazione, cioè l’uso di firme hardware per impedire l’esecuzione di versioni modificate di un programma libero.

Per chi costruisce — e non si limita a distribuire — la licenza di un componente decide cosa puoi fare con il lavoro che ci appoggi sopra. Una libreria sotto GPL detta i termini al programma che la collega staticamente; la stessa libreria sotto LGPL, o sotto una permissiva di tipo BSD o MIT, lascia altre strade aperte. Scegliere uno strumento libero senza leggerne la licenza vuol dire rimandare una decisione di architettura al momento peggiore, quello della consegna. Nel 2000 ci faceva caso una minoranza; nel 2010 è una voce ordinaria nella valutazione tecnica di ogni dipendenza.

Cosa cambia per chi lavora in piccolo

Per uno studio di poche persone l’effetto cumulativo è questo: la barriera d’ingresso agli strumenti di qualità è scesa quasi a zero, mentre è cresciuta la responsabilità di sceglierli con criterio. Dieci anni fa il vincolo era il costo e la fatica di tirare su l’ambiente; oggi il vincolo è la disciplina di tenere traccia di ciò che usi, capirne i termini e mantenerlo aggiornato.

Il controllo di versione distribuito ha reso normale lavorare con tutta la storia sotto mano, ramificare senza cerimonie e tenere il rilascio dentro lo stesso strumento che traccia il codice. Le licenze, chiarite dalla GPLv3 e dal lavoro dell’OSI, hanno reso esplicito ciò che prima si dava per scontato. Sono due maturazioni distinte, ma portano allo stesso esito: meno tempo a costruire l’impalcatura, più tempo per il problema del cliente. Questo è anche il consuntivo da cui parte noze nel chiudere i suoi primi dieci anni di attività (https://www.noze.it/insights/noze-dieci-anni-2010/).

Cosa resta aperto

Questo consuntivo guarda gli strumenti dal lato di chi assembla, e tace su due fronti ancora aperti nel 2010. Il primo è la sostenibilità di chi mantiene i progetti liberi: che il software ci sia non garantisce che ci sia chi lo cura nel tempo, e molti strumenti che do per scontati dipendono da poche persone. Il secondo è la frammentazione: la convivenza di Git e Mercurial, di più framework equivalenti e di licenze libere non sempre compatibili tra loro scarica sull’utente un costo di scelta che il decennio non ha tolto, ma solo reso più visibile.

Immagine di copertina: Linus Torvalds, creatore di Linux e di Git, fotografato mentre parla alla conferenza Linux.conf.au del 2009 — foto di Christopher Neugebauer, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Linux_Torvalds-Linux_conf_au-2009.jpg