Il codice è tuo? Vendor lock-in e come evitarlo

Mi capita spesso di sentire la stessa storia: un'azienda ha fatto sviluppare un gestionale anni fa, il fornitore è sparito o ha alzato i prezzi, e adesso nessun altro può metterci le mani perché il codice non ce l'ha nessuno. Il sistema funziona, più o meno, ma è una scatola chiusa. Ogni modifica costa cara, ogni richiesta passa da una sola persona, e cambiare fornitore vorrebbe dire buttare tutto e ripartire da zero.

Questo si chiama vendor lock-in: sei legato a chi ti ha venduto il software, non perché il software sia buono, ma perché uscirne costa troppo. La buona notizia è che si evita quasi sempre prima di firmare, con quattro domande. Te le scrivo qui, così le hai pronte.

Cos'è il lock-in, detto semplice

Quando paghi qualcuno per costruirti un software, alla fine del lavoro esistono alcune cose concrete: il codice sorgente (il testo che i programmatori scrivono), gli accessi ai server e ai servizi dove il software gira, i tuoi dati dentro il database, e la documentazione che spiega come funziona il tutto.

Se anche una sola di queste cose resta in mano solo al fornitore, tu non possiedi davvero il sistema. Lo affitti, anche se la fattura dice "sviluppo software". Non è illegale e non è nemmeno sempre in malafede: a volte è solo trascuratezza. Ma il risultato per te è lo stesso.

Le quattro domande da fare prima di firmare

1. Il codice sorgente è mio?

Chiedi esplicitamente: "A fine lavoro, il codice sorgente viene consegnato a me, con la proprietà intestata alla mia azienda?". La risposta deve essere sì, scritta nel contratto. Se ti rispondono che il codice resta loro "per proteggere il know-how", sappi cosa stai comprando: una licenza d'uso, non un software tuo. Può anche andarti bene, ma deve essere una scelta consapevole e il prezzo deve rifletterla.

2. Gli accessi sono intestati a me?

Server, dominio, database, servizi cloud, caselle email tecniche: gli account devono essere intestati alla tua azienda, con la tua carta e la tua email. Il fornitore lavora come collaboratore dentro i tuoi account, non il contrario. È un dettaglio che sembra burocratico finché non litighi con qualcuno che ha in mano le chiavi di casa tua.

3. C'è documentazione che un altro tecnico può leggere?

Non serve un manuale di trecento pagine. Serve il minimo perché un altro sviluppatore, domani, possa aprire il progetto e capire com'è fatto: come si installa, dove stanno le cose, quali servizi esterni usa, come si fa un rilascio. Chiedi di vederne un esempio di un progetto passato. Se la risposta è "è tutto in testa a noi", quella testa diventa il tuo unico fornitore possibile, per sempre.

4. Posso esportare i miei dati, tutti, in un formato leggibile?

I dati sono tuoi per definizione: clienti, ordini, storico, documenti. Chiedi come li esporti e in che formato (CSV, Excel, un dump del database). Fatti fare una prova di esportazione già durante il progetto, non il giorno che vuoi andartene. Un sistema da cui non puoi portare via i dati è una prigione con l'ingresso gratis.

Cosa mettere nero su bianco

Le risposte a voce non bastano. Nel contratto devono comparire, in parole semplici: la proprietà del codice in capo alla tua azienda a saldo avvenuto, l'elenco degli account e a chi sono intestati, l'impegno a consegnare la documentazione, e la procedura di esportazione dei dati. Sono poche righe. Un fornitore serio non ha problemi a scriverle; uno che tentenna su questi punti ti sta già dicendo come andrà a finire.

Attenzione anche alle dipendenze nascoste: se il software è costruito sopra una piattaforma proprietaria del fornitore, la proprietà del codice conta poco, perché senza quella piattaforma non gira. Chiedi sempre: "Se domani sparite, il sistema continua a funzionare? E chiunque altro può mantenerlo?".

Perché io consegno sempre tutto

Nei miei progetti la regola è una: a fine lavoro il cliente ha il codice, gli accessi, la documentazione e i suoi dati. Tutto intestato a lui. Il gestionale che ho costruito per Elite Fitness, per dire, è di Elite Fitness: se domani volessero farlo mantenere da qualcun altro, potrebbero farlo lunedì mattina.

Non lo faccio per generosità. Lo faccio perché voglio che i clienti restino con me per il lavoro che faccio, non perché sono in ostaggio. E funziona meglio anche per me: un cliente libero di andarsene è un cliente che si fida, e un cliente che si fida ti porta il progetto successivo.

Il lock-in si combatte prima della firma, quasi mai dopo. Se hai un preventivo sul tavolo e vuoi capire se queste quattro cose sono a posto, o se hai già un sistema chiuso e vuoi ragionare su come uscirne senza buttare tutto, una chiamata di mezz'ora basta per fare il punto. Costa niente e ti eviti anni di dipendenza.