Ultimamente mi sono ritrovato a lavorare a vari progetti iOS sviluppati da terzi e di cui non detenevo i diritti del codice sorgente, cioè la maggior parte del lavoro era stato fatto da altri.

La cosa che mi è saltata subito all’occhio è stato il numero elevato di codice opensource utilizzato, potrei ipotizzare il 90% del codice totale.

Ad una prima analisi viene da esclamare “bello! ci sono già un sacco di cose pronte!” ma in realtà questa situazione mi mette a disagio. Stiamo programmando un software o stiamo assemblando i pezzetti fatti da altri cercando di farli coesistere?

Sono pienamente convinto che ci sia una grande differenza tra programmare e utilizzare codice opensource in modo massiccio e l’avvento di soluzioni come CocoaPods e affini forse sta incentivando questa mania.
Sono a favore dell’opensource e sono a favore dell’utilizzo del codice open nei progetti ma con parsimonia.

Nei miei progetti, quelli che creo per i miei clienti, il codice è al 90% mio e solo un 10% è codice opensource.

Qual’è il motivo? Semplice, si tratta di avere il massimo controllo del progetto. Ovviamente c’è del lavoro in più da fare ma questo mi permette di poter operare all’interno del codice del mio software in ogni maniera.

Ci sono alcuni punti durante la vita di un progetto che vanno presi in considerazione:

1. Bugs. I software contengono sempre dei bugs e se il codice non è nostro, una volta scovato, è un problema risolverlo. Se utilizziamo codice opensource la procedura di fix è decisamente più lunga e talvolta controproducente.
2. Aggiornamenti. Apple ci sta abituando a lavorare con un linguaggio di programmazione in continua evoluzione: Swift. Cosa accade quando toglierà il supporto a Swift 3 e dovremo passare a Swift 4? Se utilizziamo codice di qualcun altro è possibile che saremo costretti ad attendere. Ma il nostro cliente,  il nostro business e peggio ancora, il business del nostro cliente avrà tutto questo tempo?
3. Manutenzione. Se il codice open che abbiamo utilizzato smette di essere mantenuto cosa accade? Passiamo ad altro!, potremmo dire, ma questo comporta del lavoro in più, chi lo paga? Altri potrebbero dire “ci facciamo nostro il codice e continuiamo a mantenerlo”, ma mantenere codice non nostro significa doverlo analizzare in profondità per conoscere ogni riga. Chi lo paga questo tempo?

Solo questi 3 punti mi bastano per capire che utilizzare codice opensource in modo massiccio all’interno dei progetti per i miei clienti non è una scelta saggia, né per me né per i clienti stessi che si aspettano alta professionalità e si affidano a questa per portare avanti il proprio business.

Altra nota negativa è che in questo modo stiamo crescendo programmatori con l’idea che la realizzazione di un software sia l’assemblaggio di pezzi di codice altrui.
A mio avviso è un grande danno, perché il mondo della programmazione, quello reale, quello dove si sta ore su ore davanti al codice per creare un software, è molto differente rispetto allo studiarsi le API di un framework su cui baseremo un software non sapendo minimamente cosa quel codice farà.

Mi ripeto, non sono contro l’opensource né contro l’utilizzo di quest’ultimo all’interno dei progetti. Va usato con parsimonia.

Buona programmazione!