Di chi è il codice: le domande da fare prima di firmare
Le domande che si fanno tardi
Nella fase di offerta si discute di prezzo, di tempi e di funzionalità. Quasi mai di cosa resta in mano vostra quando il progetto è finito. È comprensibile: sono domande che sembrano ostili in un momento in cui si sta costruendo un rapporto, e si rimandano.
Il problema è che diventano urgenti nel momento peggiore — quando volete cambiare fornitore, quando un investitore fa la sua verifica prima di un round, o quando serve che un'altra squadra metta le mani su una parte del sistema. A quel punto non si negozia più: si scopre.
Sono cinque domande, si fanno in dieci minuti e un fornitore serio ha già le risposte pronte.
1. Di chi è il codice sorgente
La domanda va posta esattamente così: a chi appartiene il codice sviluppato, e da quando. Le risposte possibili sono diverse e tutte legittime, purché siano esplicite.
Il codice può essere ceduto a voi, integralmente, a saldo pagato. Può essere concesso in licenza d'uso, restando del fornitore. Può essere misto: vostro il lavoro fatto su misura, in licenza le componenti riutilizzabili che il fornitore usa su più clienti.
L'ultima è la situazione più comune e non c'è niente di male, ma va scritta: quali parti sono in licenza, cosa succede a quella licenza se il rapporto finisce, e se resta valida anche in caso di cessazione dell'attività del fornitore. Una frase generica come "il software è di proprietà del cliente" senza distinguere questi casi non vi protegge, perché non descrive la realtà di come è costruito.
2. Dove sta il codice, e chi può prenderlo
La proprietà sulla carta non serve se non potete accedervi. Il codice deve stare in un repository intestato alla vostra organizzazione, con almeno una persona vostra fra chi ha i permessi di amministrazione.
Non è un dettaglio formale. La differenza fra "il codice è vostro" e "il codice è vostro e sta in un posto a cui accedete oggi, senza chiedere" è tutta la differenza che conta il giorno in cui il rapporto si interrompe in modo non amichevole.
Stessa logica per la documentazione minima: come si costruisce, come si mette in produzione, quali variabili di configurazione servono. Senza quella, un repository consegnato è una scatola chiusa.
3. A nome di chi sono gli accessi
Fatevi elencare tutti i servizi su cui gira il prodotto — hosting, database, posta transazionale, pagamenti, servizi esterni, dominio — e per ciascuno chiedete a nome di chi è il contratto e chi ha l'utenza principale.
L'impostazione corretta è semplice: gli account sono della vostra società, e il fornitore vi accede con utenze proprie che voi potete revocare. Il contrario — tutto intestato al fornitore, con voi che non comparite da nessuna parte — capita spesso e non è quasi mai malafede: è comodità. Ma vi mette in una posizione da cui si esce solo ricostruendo.
Vale la pena includere anche il dominio, che è la cosa più facile da dimenticare e la più fastidiosa da recuperare.
4. Cosa succede ai dati
I dati che il sistema raccoglie sono vostri, ma la domanda pratica è un'altra: in quanto tempo e in che formato ve li potete portare via.
La risposta buona è che esiste un modo di esportarli in un formato leggibile — una copia del database, o file strutturati — senza dover chiedere lo sviluppo di una funzione apposita, e senza costi non previsti. Se l'unica strada è "vi prepariamo noi un'estrazione", chiedete quanto costa e in quanti giorni: sono numeri che è meglio conoscere prima.
Se il sistema tratta dati personali, c'è anche la parte di responsabilità reciproca da mettere per iscritto. Non è un adempimento formale da rimandare: è quello che stabilisce chi risponde di cosa se qualcosa va storto, e va concordato con chi segue la privacy nella vostra azienda.
5. Da cosa dipendete senza saperlo
Ogni software poggia su cose costruite da altri: librerie, servizi esterni, piattaforme. È normale ed è il motivo per cui costruire oggi costa meno che dieci anni fa. Le domande utili sono due.
Ci sono dipendenze che vincolano? Un servizio esterno con un prezzo che cresce con l'uso, una piattaforma da cui il prodotto non si può staccare senza riscriverlo. Non è necessariamente un problema, ma è una scelta che deve essere vostra e consapevole, non una sorpresa.
Come sono licenziate le componenti open source usate? La quasi totalità è liberamente utilizzabile in un prodotto commerciale. Una minoranza pone condizioni che possono contare, per esempio in una vendita o in un round. Un fornitore attento ha un elenco di cosa ha usato: chiederlo è ragionevole.
Come si scrive senza trasformarlo in una battaglia
Queste cose non richiedono un contratto complicato. Richiedono una pagina, scritta in italiano semplice, che dica: di chi è cosa, dove sta, chi accede, come si esce.
E vale la pena inquadrarla per quello che è. Non è una difesa contro il fornitore: è la condizione perché il rapporto possa durare per scelta e non per vincolo. Un partner che punta a restare il vostro riferimento tecnico per anni non ha alcun interesse a tenervi legati con la chiusura — ha interesse a che restiate perché lavorare insieme funziona.
Il modo in cui reagiscono a queste cinque domande, del resto, è già metà della valutazione.
Un contratto chiaro sulla proprietà non serve per il giorno in cui vi separate. Serve perché per tutti gli altri giorni non dovete pensarci.
