Cos’è Laravel: che cosa implica per chi commissiona un sistema

Le due righe «PHP 8.4, Laravel 13» in offerta non sono un dettaglio tecnico: decidono per quanto il sistema riceverà patch di sicurezza, che cosa costerà in più e quanto sarà cara la consegna a un altro sviluppatore.

L’offerta arriva nel pomeriggio di venerdì, e nella parte tecnica ci sono due righe che in riunione nessuno legge ad alta voce: «PHP 8.4» e «Laravel 13». Il prezzo è comprensibile, il termine è comprensibile, e queste due righe sembrano la cucina interna del fornitore — all’incirca tanto importanti quanto il trapano con cui si farà il buco nel muro, e per questo di solito le si salta come un dettaglio tecnico di cui risponde qualcun altro. La firma, però, sta sotto l’intero documento, e sono proprio queste due righe a decidere per quanto il sistema riceverà ancora patch di sicurezza, che cosa vi farà arrivare una fattura mensile oltre al prezzo di sviluppo e quanto sarà cara, fra tre anni, la consegna a qualcun altro.

Questo articolo non riguarda se PHP sia un buon linguaggio e se Laravel sia un buon framework, perché a quella domanda rispondono gli sviluppatori fra di loro e l’acquirente da quella conversazione non ricava nulla di pratico. Riguarda quattro cose che l’acquirente può verificare da solo e senza competenze tecniche: il calendario di supporto, la licenza, il mercato del lavoro e le condizioni di consegna. Tutte e quattro sono pubbliche, tre di esse sono date oppure somme di denaro, la quarta è ciò che sul mercato si può e non si può sapere, e nessuna dipende da quanto sia convincente il testo dell’offerta — perciò conviene verificarle proprio in quella settimana in cui sul prezzo si può ancora discutere.

Cos’è Laravel, cos’è PHP, e perché non sono una scelta sola

PHP è un linguaggio di programmazione in cui è scritta la parte server del sistema — quella che gira presso il fornitore o sul Suo hosting e che l’utente non vede mai. Laravel, invece, è un framework, cioè una base di codice già scritta in PHP che risolve ciò che si ripete in quasi ogni progetto: l’autenticazione degli utenti, le interrogazioni al database, le code, l’archiviazione dei file, l’invio della posta. In offerta stanno uno accanto all’altro come una scelta sola, ma sono due prodotti distinti, mantenuti da due squadre diverse con due calendari di supporto diversi, ed è proprio per questo che conviene leggerli separatamente.

Quanto sia diffuso il linguaggio è più difficile da dire di quanto ci si aspetti. W3Techs, che scansiona regolarmente più di venti milioni di siti, ad agosto di quest’anno scrive che PHP è usato dal 70,2% di tutti i siti di cui questo strumento conosce il linguaggio di programmazione lato server. Quest’ultima condizione è quella che di solito scompare quando il numero viene ricopiato in una presentazione: non si parla del 70% di tutti i siti del mondo, ma del 70% di quelli che questo strumento concreto è in grado di riconoscere, e una parte di quel riconoscimento la descrive esso stesso come ricavata indirettamente — se la pagina è WordPress, allora è PHP.

Per l’acquirente è più utile un altro numero della stessa pagina. Fra i siti di cui W3Techs determina anche la versione di PHP, il 63,3% gira sull’ottava, il 28,7% sulla settima e il 7,9% ancora sulla quinta, sebbene la settima versione abbia perso anche le patch di sicurezza già quattro anni fa. Significa che circa un terzo del PHP misurabile in rete oggi gira su codice per cui nessuno prepara più patch, e non è successo perché il linguaggio sia cattivo o perché qualcuno abbia sbagliato in sviluppo. È successo perché nessuno ha commissionato e pagato il cambio di versione, ed è proprio questa la parte di rischio che l’acquirente può sia vedere sia governare.

Il calendario di supporto PHP è il primo documento che conviene aprire

La regola del gruppo di sviluppatori PHP è breve e pubblica: ogni ramo di versione riceve il supporto completo per due anni dal primo rilascio stabile, poi ancora due anni soltanto di patch di sicurezza critiche, e dopo quattro anni non viene più mantenuto affatto. In questa regola c’è un dettaglio che i riassunti tagliano quasi sempre: le date di fine vere nella tabella sono allineate all’ultimo giorno dell’anno, non all’anniversario del rilascio a novembre, perciò «due anni dall’uscita» e ciò che sta scritto nella tabella di php.net differiscono di un mese o due.

In pratica significa questo. La versione 8.2 è ora in modalità solo correzioni di sicurezza, e il suo supporto termina già a fine di quest’anno, quindi fra circa quattro mesi. La versione 8.3 ha perso il supporto completo a fine dell’anno scorso e riceverà patch di sicurezza fino a fine del 2027, quindi ancora circa sedici mesi. La versione 8.4 resterà in supporto completo fino alla fine di quest’anno e poi resterà ancora due anni in modalità solo correzioni di sicurezza, mentre la più recente 8.5, uscita a novembre dell’anno scorso, riceve il supporto completo per tutto l’anno prossimo e le patch di sicurezza fino a fine del 2029.

Il supporto della versione 8.1 è terminato l’ultimo giorno dell’anno scorso, ed è proprio questo caso che merita attenzione se Lei ha già un sistema, non un’offerta. Se il fornitore tre anni fa l’ha costruito sulla 8.1 e da allora nessuno ha cambiato nulla, oggi gira su un ramo già in end of life, a cui le patch di sicurezza non arrivano più, e non lo segnala né il server, né il browser, né il sistema stesso. La pagina si apre esattamente come ieri, i clienti non notano nulla, e l’unico posto in cui lo si vede è questa stessa tabella pubblica, che si apre in meno tempo di quanto serva a leggere la prima pagina dell’offerta.

Il calendario Laravel è più corto di quello PHP

Laravel formula la propria politica in modo ancora più breve: correzioni di bug per diciotto mesi, patch di sicurezza per due anni, e una nuova major version ogni anno all’incirca nel primo trimestre. Un rilascio con supporto a lungo termine, che nel settore si chiama LTS, oggi non c’è più — nelle versioni vecchie c’era davvero, ma nella tabella di quest’anno quella colonna non esiste affatto, perciò un’offerta in cui sta scritto «LTS Laravel» descrive qualcosa che al momento nessuno vende. È una promessa più corta di quella che molti acquirenti si aspettano da un framework su cui si costruirà un sistema per i prossimi cinque anni.

In cifre, secondo la stessa documentazione Laravel, l’ordine è questo. Laravel 13 è uscito a marzo di quest’anno, riceverà correzioni di bug fino al terzo trimestre del prossimo anno, e le patch di sicurezza fino al 17 marzo 2028. La finestra delle correzioni di bug di Laravel 12 si è chiusa a metà agosto di quest’anno, cioè diciassette giorni prima di scrivere queste righe, e le sue patch di sicurezza termineranno a febbraio del prossimo anno. Il supporto di sicurezza di Laravel 11 è terminato in primavera di quest’anno, quindi un sistema che oggi gira sull’undicesima versione gira già senza patch, per quanto bene appaia dall’esterno.

Presti attenzione al fatto che la fine delle correzioni di bug di Laravel 13 è indicata come trimestre, non come data precisa. È un’imprecisione della formulazione di Laravel stessa, e non è un problema finché la si ricopia esattamente come sta lì; il problema comincia nel momento in cui il fornitore o l’acquirente la arrotonda a un giorno concreto e poi pianifica il budget su un numero che nella fonte non c’è. Un altro limite da conoscere prima di scegliere la versione: Laravel 13 richiede almeno PHP 8.3, perciò un sistema sulla tredicesima versione non si può lasciare sulla 8.2 nemmeno se la 8.2 stessa ricevesse ancora per un po’ le patch di sicurezza.

Che cosa significano insieme i due calendari per il sistema che commissiona oggi

Se il sistema viene consegnato su Laravel 13 insieme a PHP 8.4 o 8.5, la prima data in cui qualcosa deve per forza muoversi è marzo 2028, quando terminano le patch di sicurezza di Laravel, e sono circa diciotto mesi e mezzo da oggi. PHP in questa combinazione non è il vincolo, perché entrambi questi rami ricevono patch di sicurezza più a lungo del framework, quindi la prima cosa che invecchia è Laravel, non il linguaggio. È anche l’unico modo onesto di rispondere alla domanda «per quanto questo sistema durerà senza un investimento ulteriore» — non con una sensazione, ma con la più vicina delle due date pubbliche.

Se lo stesso sistema viene consegnato su Laravel 13, ma PHP 8.3, l’ordine si inverte e il primo termine arriva in circa sedici mesi, quando terminano le patch di sicurezza di questo ramo PHP. Se il fornitore scrive su Laravel 12, che per un progetto già esistente resta una scelta del tutto normale, le patch di sicurezza terminano a febbraio del prossimo anno, e la vita di un sistema nuovo comincia con sei mesi fino al primo cambio di versione obbligatorio. La differenza fra la prima e la terza variante è un anno, che si può guadagnare in una sola conversazione prima del contratto, e che dopo la firma non si può più comprare.

Due errori in questo conto sono così diffusi che conviene nominarli a parte. Il primo è confondere il supporto completo con il supporto di sicurezza, perciò sentendo che «il supporto di PHP 8.4 termina a fine anno» conviene chiedere quale delle due finestre si intenda: termina la correzione dei bug ordinari, ma le patch di sicurezza arrivano ancora per due anni. Il secondo è credere alla frase di Laravel stessa, secondo cui il passaggio a una nuova major version di solito occuperebbe un giorno o meno; è un obiettivo formulato dagli sviluppatori, non una media misurata, e in un contratto non lo si può scrivere come termine.

La licenza costa zero, e questo è vero soltanto per il linguaggio e il framework

Il framework Laravel viene distribuito con licenza MIT, che è una delle licenze open source più semplici e consente di usare, modificare e rivendere il codice, chiedendo soltanto di conservare l’avviso di copyright. Con PHP è un po’ più complicato, e questa complicazione è attuale proprio ora, perché la licenza cambia: le versioni fino alla 8.5 inclusa escono con la revisione 3.01 della licenza PHP, mentre a partire dalla 8.6 passano alla quarta revisione, che php.net stesso descrive come licenza «Modified BSD» e che in pratica coincide con BSD-3-Clause. In nessuna di queste varianti è prevista una tariffa.

Significa che per il linguaggio in sé e per il framework in sé l’azienda non paga né per utente, né per nucleo di processore, né per anno, e questo zero non è una promozione che un giorno finirà. Per confronto vale il modello che usa Microsoft SQL Server: lì si licenzia o per nuclei, o per server insieme alle licenze di accesso client, l’edizione Standard è limitata al minore fra quattro socket di processore e ventiquattro nuclei, e l’edizione Express gratuita — a un socket o quattro nuclei. Le somme precise qui non le scriviamo, perché il listino cambia e va letto presso Microsoft; per l’acquirente è confrontabile il modello, non il numero — un prodotto calcola in base alla quantità di hardware, l’altro non calcola affatto.

Nell’acquisto questo ha due conseguenze che conviene annotare subito. La prima è piacevole: non c’è un audit delle licenze, non c’è un ricalcolo annuale per gli utenti cresciuti durante l’anno, e non c’è la situazione in cui il fornitore del software dopo tre anni arriva con una fattura per un limite superato. La seconda è quella che si tende a dimenticare: l’open source toglie la dipendenza dal proprietario del framework, ma non toglie la dipendenza in generale. La dipendenza si sposta altrove — sull’agenzia che sola sa come il progetto è montato, sui prodotti a pagamento che stanno accanto al codice, su un abandoned package che nessuno mantiene più, e su una major version il cui supporto è finito. Questi quattro posti sono quelli che l’acquirente deve verificare, perché la riga della licenza su di essi non dice nulla.

Dove Laravel comincia comunque a costare: i prodotti che non sono il framework

La stessa squadra che mantiene Laravel vende anche diversi prodotti, e in offerta tendono a stare sulla stessa riga del framework, come se ne fossero una componente. Laravel sul proprio sito distingue da sé queste due cose: i package — Horizon, Telescope, Pulse, Scout, Sanctum, Octane e altri — sono sotto licenza MIT e gratuiti, mentre i prodotti sono Cloud, Forge, Nightwatch, Vapor e Nova, e costano denaro ogni mese o ogni anno. Envoyer continua a essere venduto a parte. Nessuno di questi prodotti è necessario perché un sistema Laravel funzioni, ed è proprio per questo che la loro presenza in offerta è una scelta, non una necessità.

Ad agosto di quest’anno i prezzi erano questi. Forge, con cui si gestiscono i server, costa 12, 19 o 39 dollari USA al mese a seconda del piano. Nova, che è un pannello di amministrazione, costa 99 dollari una tantum per un progetto insieme agli aggiornamenti annuali e 79 dollari all’anno per continuare gli aggiornamenti, mentre la licenza illimitata costa rispettivamente 299 e 249 dollari, e copre i Suoi progetti, non i progetti dei Suoi clienti. Nightwatch, che raccoglie gli eventi del sistema, parte da un piano gratuito e sale a 20, 60 e 300 dollari al mese, più un sovrapprezzo per gli eventi oltre il limite incluso. Laravel Cloud parte da 5 dollari al mese più i consumi, e Envoyer costa da 10 a 50 dollari al mese.

La domanda per l’acquirente non è se questi prodotti siano buoni, perché di solito lo sono e fanno risparmiare allo sviluppatore diversi giorni al mese. La domanda è quali di essi siano inclusi nel prezzo nominato, su quale account siano registrati e che cosa ne avvenga se Lei fra due anni cambierà fornitore. Un abbonamento che sta sull’account dell’agenzia e che nel contratto non è menzionato è esattamente la dipendenza che la licenza MIT non toglie, perché MIT parla del codice, non dell’account in cui viene pubblicato e sorvegliato.

Che cosa succede se lo sviluppatore sparisce

«Il codice può essere ripreso da qualsiasi sviluppatore Laravel» è una frase giuridicamente vera e praticamente incompleta, e l’abbiamo scritta anche noi. La licenza MIT permette davvero a un’altra azienda di lavorare su questo codice, senza chiedere permesso né a noi né alla squadra Laravel. Se il nuovo sviluppatore sarà utile già nella prima settimana, lo decidono quattro cose del tutto diverse, e tutte e quattro si possono verificare prima che il contratto sia firmato.

La prima è la major version. Una consegna da Laravel 11 a una squadra nuova non è una consegna, è un progetto di cambio di versione, perché il supporto di sicurezza lì è già finito e il primo lavoro non sarà una nuova funzionalità, ma il cambio di versione in ritardo fino a un rilascio ancora supportato. La seconda è la distanza dalla convenzione del framework: la documentazione Laravel presuppone una certa disposizione di cartelle e classi, e più il progetto se n’è allontanato, più cara è la presa di conoscenza. Un numero qui non c’è e in nessuna fonte esiste; c’è soltanto la direzione; l’acquirente però può chiedere in modo del tutto concreto che cosa nel progetto sia stato scritto contro il comportamento predefinito e quale necessità lo richiedesse.

La terza sono le dipendenze, cioè i package di terzi su cui il sistema fa affidamento. Composer, che nel mondo Laravel li gestisce, conserva un file con le versioni esatte, ed è prezioso proprio perché un nuovo sviluppatore può installare esattamente ciò che vedeva il precedente, non ciò che oggi è il più recente. Questo file non garantisce due cose: che il package sia ancora disponibile per il download, e che nel frattempo non vi sia stata trovata una vulnerabilità. Il comando composer audit mostra entrambe in una sola chiamata, ed è la forma più breve di domanda che si possa porre su una base di codice altrui.

La quarta è un abandoned package, e qui le parole ingannano. Packagist, il catalogo pubblico di Composer, segnala che i manutentori si sono fermati, ma questo non significa che il package sparisca o smetta di funzionare: swiftmailer continua a essere servito, ha 449 milioni di installazioni registrate, l’ultimo rilascio è del 2021, e allo stesso tempo ha tre vulnerabilità note. Nella nostra stessa base di codice di questo sito, che è Laravel 13 insieme al pannello di amministrazione Filament, ci sono 109 package di produzione e nessun abandoned package — è il nostro numero sul nostro progetto, non una media di settore, perché una media di settore pubblicata non esiste da nessuna parte.

Quanto è grande il mercato del lavoro, e perché un numero preciso non lo dirà nessuno

Alla domanda se in Italia sia facile trovare una persona che prenda in carico il sistema, la risposta onesta è che una statistica pubblica sugli sviluppatori PHP o Laravel in Italia non esiste. Ci sono dati indiretti, e valgono esattamente quanto precisamente li si descrive. Nell’indagine PHP di JetBrains dell’anno scorso, fra 1.720 persone per cui PHP è il linguaggio principale, il 64% lavora con Laravel, il 25% con WordPress e il 23% con Symfony; il lavoro sul campo è avvenuto in primavera, l’indagine è sbilanciata a favore degli utenti degli strumenti JetBrains, cosa che l’azienda riconosce essa stessa, e i gruppi di rispondenti più numerosi arrivano da Giappone, Stati Uniti, Russia, Cina e Francia, non dai Paesi baltici.

A livello europeo Eurostat a maggio di quest’anno riferisce che l’anno scorso nell’Unione europea lavoravano 10,45 milioni di specialisti delle tecnologie dell’informazione e della comunicazione, pari al 5,0% di tutti gli occupati e il 2,6% in più rispetto all’anno precedente. Sull’Italia, in un aggregato precedente della stessa fonte, c’è un altro numero, più utile all’acquirente della crescita complessiva: nel 2023 il 5,00% delle imprese italiane cercava o tentava di assumere specialisti di questo tipo, e fra le imprese italiane che cercavano, il 58,43% non è riuscito a coprire il posto.

Questi numeri riguardano gli specialisti del settore in generale, non il PHP, e non si devono ricopiare come un’affermazione sul mercato del lavoro Laravel in Italia — né da noi, né dal fornitore che li cita nella Sua offerta. Noi stessi, nella nostra pagina di servizi, abbiamo scritto che trovare gli sviluppatori che prendono in carico il lavoro è facile; preparando questo articolo non abbiamo trovato fonti per questa affermazione, perciò qui non la ripetiamo. Per l’acquirente la sequenza pratica è comunque un’altra: non credere alla grandezza del mercato, ma fare in modo che la base di codice sia tale che una persona nuova vi entri a basso costo, indipendentemente da quante persone simili ci siano.

Dove tracciamo noi stessi il confine nell’offerta

Scriviamo in Laravel dal 2013, quando è uscita la quarta versione, e in pratica significa che siamo passati più volte esattamente da ciò di cui questo articolo avverte — un cambio di major version che non è il lavoro di un giorno e che non si può fare in mezzo ad altri compiti. Nella nostra pagina di sviluppo di sistemi Laravel ci sono il prezzo e i tempi, ed è una conversazione a parte; in questo articolo c’è soltanto ciò che in un’offerta si può verificare, indipendentemente da chi l’abbia scritta e da quanto bene sia scritta.

Ciò che non affermiamo è che qualsiasi sviluppatore prenda in carico qualsiasi base di codice con la stessa facilità, perché la sezione precedente dice il contrario. Ciò che affermiamo è più concreto e più verificabile: il repository è del cliente dal primo giorno, vi stanno sia il file delle dipendenze, sia la documentazione, sia la configurazione di rilascio, e al momento della consegna la versione è quella che in quel momento riceve ancora le patch di sicurezza. Se Le sembra che la scelta sia in realtà fra un prodotto pronto e un sistema su misura, allora è un altro discorso, che abbiamo scritto a parte, e se la domanda riguarda proprio un e-commerce, allora il confronto tra WooCommerce e Laravel risponde con più precisione di questo articolo.

In pratica il pacchetto di consegna comprende il repository con tutta la cronologia, il file delle dipendenze con le versioni esatte, un README con i passi di avvio, la configurazione di rilascio e gli accessi a tutti gli account in cui il sistema opera. Questo è ciò che si può promettere e verificare. Ciò che non si può promettere è il mercato: quante persone in Italia prenderanno questo lavoro e a quale prezzo non è in mano nostra e non sta in nessuna statistica pubblica, perciò a questa domanda non rispondiamo con un numero convincente. L’unica cosa che qui lavora davvero a favore dell’acquirente è che la base di codice è ordinaria, la versione è supportata e la documentazione è scritta in quel momento, non rimandata alla settimana della consegna.

Che cosa chiedere prima di firmare

La prima domanda riguarda le date: quale major version di Laravel e quale ramo PHP saranno nel sistema il giorno stesso della consegna, e quando terminano le relative patch di sicurezza. La risposta è due date, entrambe si verificano in due pagine pubbliche in cinque minuti, e vanno scritte o nel contratto o almeno nella corrispondenza. Se il fornitore nomina una versione il cui supporto termina prima del periodo di garanzia, non è vietato e a volte è addirittura giustificato, ma allora devono saperlo entrambe le parti, e nel prezzo deve essere chiaro chi pagherà il passaggio.

La seconda domanda riguarda gli abbonamenti: quali prodotti a pagamento — Forge, Cloud, Nova, Nightwatch, Vapor o Envoyer — servono al funzionamento del sistema, quanto costano insieme al mese e su quale account stanno. La terza riguarda il repository: da quale giorno è Suo, se vi è il file delle dipendenze e se nel controllo automatico è incluso il comando composer audit. La quarta è la domanda di denaro che di solito si rinvia a dopo e poi si trova con sorpresa nel budget: chi pagherà il cambio di major version fra un anno e mezzo e se rientra nel contratto di manutenzione o sarà un nuovo incarico.

Nessuna di queste quattro domande chiede che Lei capisca il codice, e nessuna va presa come sfiducia verso il fornitore. Tutte riguardano ciò che succederà dopo che il progetto sarà finito e la fattura pagata, e un buon fornitore risponde subito, perché queste date le sa a memoria. Se la risposta a una di esse richiede una settimana o si trasforma in una spiegazione di perché la domanda non conti, quella è già una risposta.

Queste quattro domande non sostituiscono la valutazione tecnica e non rispondono se l’architettura proposta sia buona, ma eliminano gran parte delle sorprese sgradevoli che di solito arrivano al secondo o terzo anno, quando l’entusiasmo iniziale è finito e il sistema semplicemente funziona. Se ha un’offerta in mano e non è convinto di che cosa le versioni scritte significhino per i Suoi termini e il Suo budget, ci scriva — la risposta a queste quattro domande si può preparare senza aprire il codice.