Il lock-in è una pratica per cui un produttore fa in modo che i suoi clienti abbiano difficoltà e costi notevoli ad usufruire di beni e servizi di un altro produttore a lui concorrente. Detta così suona veramente male, ma a guardare la realtà dei fatti invece sembra che sia la tattica commerciale più in voga, non solo tra i produttori, ma anche troppo spesso tra i clienti—anche se, a volte, inconsapevolmente.

Nel mio piccolo mi trovo spesso ad ascoltare discorsi tipo “io fin qui posso arrivare ma se devi andare oltre devi ricontattare quello che ti ha fatto il lavoro” oppure “il vecchio programmatore ci ha lasciati, non sappiamo come mettere le mani sul suo lavoro e già altri due programmatori ci hanno prospettato di rifare tutto da capo”. È chiaro il problema: qualche sedicente professionista ha fatto un pessimo lavoro che funzionava benissimo finché dietro c’era lui ma nel momento in cui un’altra persona deve metterci mano, ecco che sorgono i problemi. E purtroppo questi altri sedicenti professionisti sembra non vedano l’ora di assicurarsi per la vita un nuovo cliente rifacendogli tutto male come prima ma in modo che solo loro sono in grado di gestire, e via così. Senza tenere conto che per la vita c’è solo la morte e che oggi siamo qui ma domani chissà, mentre il nostro lavoro facilmente ci sopravviverà.

Abbiamo visto perché il lock-in è male per i clienti, ma vediamo perché al fornitore può sembrare un’ottima idea. È chiaro che assicurarsi un cliente che torna è una garanzia economica, ma la questione è che se, per qualsiasi motivo, il cliente si trova costretto a rivolgersi ad altri, è fregato. Risultato: un cliente di cattivo umore e una pessima figura per il fornitore che verrà invariabilmente bollato come incompetente, imbecille, disadattato, o peggio. Non sarebbe meglio avere un cliente felice e soddisfatto che, a quel punto, torna da noi perché gli abbiamo fatto un buon lavoro? E se per caso dovesse rivolgersi ad altri, in primo luogo non dovrebbe affrontare costi impraticabili, e in secondo luogo il fornitore farebbe una figura migliore sia con il cliente che col nuovo fornitore che a sua volta, se un bel giorno avesse bisogno di una mano, potrebbe ricordarsi di quel suo collega, non di quel suo acerrimo e sleale concorrente.

A queste premesse, evidentemente non c’è possibilità di vittoria. Purtroppo l’informatica è un campo talmente archetipico per questo genere di comportamento per cui l’espressione “reinventare la ruota” si applica con frequenza allarmante. Praticamente ogni giorno mi trovo di fronte a ruote ogni volta diverse e, quel che è peggio, ogni volta fatte male, perché se la ruota fosse fatta bene, nessuno avrebbe difficoltà ad aggiustarla qui e là quando serve. Ovviamente l’ideale sarebbe non reinventare la ruota ma usare una ruota già fatta. Uscendo dalla metafora della ruota che, a questo punto, comincia a mostrare qualche limite, la questione è: perché riscrivere un framework quando ne esistono già di eccellenti? Perché rifilarmi i tuoi esperimenti che io lo so già al 150% che troverò un bug talmente notevole e imbarazzante che resterò un quarto d’ora a cercare di rimettermi la mandibola in sede?

Perché voi clienti non pretendete la garanzia contrattuale che il lavoro che vi viene fornito sia eseguito a regola d’arte e che impieghi soluzioni ad hoc solo ed esclusivamente quando non sia stato possibile trovare una soluzione sviluppata da terzi e con relative garanzie di funzionamento? Perché non è concepibile l’idea che spendere un po’ di più adesso si riflette in notevoli risparmi sul medio e lungo termine?

Forse perché fin’ora siete stati regolarmente turlupinati da supposti esperti che invece poi è uscito che erano degli incompetenti, degli imbecilli, dei disadattati? Mh, forse sì.