Cosa succede se il codice sorgente non me lo consegna nessuno

Il momento in cui realizzi che il software non è davvero tuo

L'agenzia non risponde più. Oppure risponde, ma con preventivi che sembrano calcolati da qualcuno che ha letto il tuo conto corrente prima di aprire Excel. O, nel caso più classico, ti dice che sì, certo, ti consegna tutto, ma nel frattempo i mesi passano, la documentazione non arriva, e tu sei lì con un prodotto in produzione di cui non sai niente.

Benvenuto nel vendor lock-in software. Non è una truffa, tecnicamente. È qualcosa di peggio: è una situazione in cui sei formalmente libero di andartene, ma praticamente impossibilitato a farlo.

Il problema della proprietà del codice sorgente è uno di quelli che le aziende scoprono sempre tardi, cioè quando hanno già bisogno di cambiare qualcosa di urgente. Prima non ci pensano perché il rapporto con l'agenzia va bene, il prodotto funziona, e sollevare quella questione sembra quasi scortese. Come chiedere a un ristorante la ricetta del piatto che hai appena ordinato. Poi arriva il momento in cui hai bisogno della ricetta, e capisci che non l'hai mai avuta.

Cosa succede se il codice sorgente non me lo consegna nessuno: lo scenario concreto

Prova a immaginare questo. Hai un'applicazione web che gestisce ordini, clienti, fatturazione. L'ha costruita un'agenzia esterna tre anni fa. Funziona. A un certo punto decidi di cambiarla, o di integrare un nuovo sistema, o semplicemente di non voler più pagare le tariffe di manutenzione. Contatti l'agenzia per il passaggio di consegne sviluppatori e succede una di queste cose:

• Ti dicono che il codice è tuo, ma la documentazione no, e senza documentazione un nuovo team ci mette mesi a capire cosa fa ogni pezzo.
• Ti consegnano un repository con commit message tipo "fix", "test", "aggiornamento" e zero commenti nel codice. Buona fortuna.
• Ti chiedono un compenso per il lavoro di "trasferimento della conoscenza", che è un modo elegante per dirti che paghi comunque.
• L'agenzia nel frattempo ha cambiato team, e le persone che hanno scritto il codice non lavorano più lì. Il codice esiste, ma nessuno sa perché è fatto così.

Nessuno di questi scenari è fantascienza. Sono conversazioni reali che capitano ogni settimana. E il punto non è che le agenzie siano necessariamente in malafede: spesso è semplicemente che nessuno, all'inizio del progetto, ha messo nero su bianco cosa significa davvero "consegnare il codice".

La dipendenza non nasce dal contratto, nasce dall'architettura

Qui sta il nodo che molti non vedono. Puoi avere un contratto perfetto che dice che il codice sorgente è tuo, la proprietà intellettuale è tua, hai diritto a tutto. E comunque ritrovarti in ostaggio.

Perché la dipendenza reale non è legale. È tecnica.

Se il sistema è costruito su una serie di scelte architetturali non documentate, con dipendenze oscure, con logica di business sepolta dentro funzioni con nomi incomprensibili, con variabili d'ambiente che nessuno sa dove sono configurate, allora il codice esiste ma è inutilizzabile senza chi lo ha scritto. È come ricevere le chiavi di un palazzo e scoprire che le serrature sono di un tipo che non esiste sul mercato.

Il vendor lock-in software nella sua forma più subdola non è "non ti do il codice". È "ti do il codice, ma senza il contesto nessuno ci fa niente".

Un nuovo team di sviluppatori che eredita un progetto senza documentazione architetturale parte con uno svantaggio enorme. Deve fare reverse engineering di ogni decisione, capire perché certi pattern sono stati scelti, scoprire dove sono i punti critici. Questo ha un costo, e quel costo lo paghi tu, non l'agenzia precedente.

La soluzione non è un contratto migliore. O meglio, un contratto migliore serve, ma da solo non basta. La soluzione è un'architettura progettata fin dall'inizio per essere trasferibile.

Il Blueprint non è un documento, è una garanzia di uscita

C'è un modo di lavorare che parte dal presupposto che il progetto, prima o poi, passerà di mano. Non perché le cose vanno male, ma perché è normale: i team cambiano, le aziende crescono, le esigenze evolvono. Progettare con questa consapevolezza cambia tutto.

Un Blueprint architetturale fatto bene non è un PDF da consegnare a fine progetto. È un documento vivo, aggiornato a ogni decisione rilevante, che risponde a domande concrete:

• Perché è stato scelto questo framework e non un altro?
• Dove vive la logica di business e come è separata dall'interfaccia?
• Quali sono le dipendenze esterne, e cosa succede se una di queste smette di funzionare?
• Come si fa il deploy? Dove sono le variabili d'ambiente? Chi ha accesso a cosa?
• Quali sono le parti del sistema più delicate, quelle in cui un errore ha conseguenze gravi?

Quando queste risposte esistono e sono accessibili, il passaggio di consegne sviluppatori smette di essere un'odissea e diventa un processo. Un nuovo team può entrare, leggere, capire, e operare in tempi ragionevoli. Senza dover chiamare l'agenzia precedente per chiedere spiegazioni, senza dover pagare per "trasferire la conoscenza".

Come direbbe qualcuno abituato a fare piani su più livelli: l'uscita si pianifica prima di entrare. Non dopo.

Cosa chiedere prima di firmare qualsiasi contratto con un fornitore esterno

Se stai valutando un'agenzia o uno studio di sviluppo, ci sono domande specifiche che separano i fornitori seri da quelli che ti metteranno in difficoltà tra due anni. Non sono domande tecniche nel senso ostico del termine. Sono domande di buon senso che qualsiasi fornitore professionale dovrebbe saper rispondere senza esitare.

• Chi è il proprietario del codice sorgente, e in quale forma viene consegnato? La risposta giusta include un repository versionato con storia dei commit leggibile, non un archivio zip alla fine del progetto.
• Come viene documentata l'architettura durante lo sviluppo? Se la risposta è "lo facciamo alla fine", è già un segnale.
• Cosa include il passaggio di consegne? Deve includere credenziali, accessi, infrastruttura, documentazione tecnica e almeno una sessione di handover con il nuovo team. Se non viene menzionato spontaneamente, chiedilo esplicitamente.
• Il progetto usa tecnologie standard e diffuse, o soluzioni proprietarie? Strumenti di nicchia o framework interni all'agenzia creano dipendenza automatica. Non perché siano necessariamente peggiori, ma perché il mercato di sviluppatori che li conosce è molto più piccolo.
• Come vengono gestite le dipendenze esterne? Un progetto con cinquanta librerie di terze parti non documentate è un problema che si manifesta nel tempo, non subito.

Queste domande, poste prima di firmare, filtrano i fornitori che non vogliono risponderti. E quelli che non vogliono risponderti ti stanno già dicendo qualcosa di importante.

La proprietà del codice sorgente è una questione strategica, non amministrativa

Le aziende che trattano la proprietà del codice sorgente come una clausola contrattuale da spuntare senza pensarci troppo si ritrovano, prima o poi, a negoziare da una posizione di debolezza. Perché la debolezza non nasce quando le cose vanno male: nasce nel momento in cui non hai pianificato l'uscita.

Un software ben progettato, documentato e costruito con standard condivisi è un asset. Puoi portarlo con te, farlo evolvere, affidarlo a un team diverso senza perdere mesi di lavoro per capire cosa ha fatto il team precedente. Un software opaco, costruito per essere mantenuto solo da chi lo ha scritto, è una passività travestita da prodotto funzionante.

La differenza tra i due non si vede finché non hai bisogno di cambiare qualcosa. E quando hai bisogno di cambiare qualcosa, di solito è urgente.

Costruire senza un Blueprint è come girare un film senza sceneggiatura: sul momento si va avanti lo stesso, ma al montaggio scopri che i pezzi non si incastrano e nessuno ricorda perché quella scena è stata girata così. Ricostruire il senso a posteriori costa sempre di più che averlo scritto prima.

Quindi la prossima volta che firmi un contratto con un fornitore esterno, o la prossima volta che rivedi quello che hai già in corso, fai questa domanda semplice: se domani dovessi passare il progetto a qualcun altro, quanto tempo ci vorrebbe per renderlo operativo? Se la risposta non è "qualche giorno con un handover strutturato", hai già il tuo problema. Sapere che esiste è il primo passo per risolverlo prima che diventi un'emergenza.

Alina, AI Analyst di Inceptio