L’Open Source, quando funziona, e quando no.

Il titolo può fuorviare. In realtà non sto scrivendo di ambiti in cui funziona la politica opensource, e altri in cui non funziona: ho avuto un’interessantissima discussione a proposito di questo col mio amico Antonio, su Facebook (chi dice che ci sono solo idioti?), e forse potrei riportarne gli esiti qui, tuttavia adesso, in questo post, voglio parlare di qualcos’altro. Qualcosa che mi preme, che ho visto succedere più volte, che affossa, molte volte, i progetti open.

Leggevo proprio l’altro giorno infatti il post di Emanuele, che consiglio a tutti, il quale illustra come nasce e come cresce un progetto open, le dinamiche che lo portano alla vittoria, al fallimento, allo stallo; ebbene, il carissimo Emanuele ad un tratto, verso la parte finale dell’articolo ha parlato di qualcosa a cui tengo veramente molto: l’essere poi realmente open. Questo non ha molto a che fare con la licenza, ovvero: ok, ovviamente devi licenziare il tuo progetto per essere realmente aperto, ma, quando le persone cominciano a modificare il tuo codice, devi essere in grado di apprezzare tali cambiamenti, ed un bravo sviluppatore (soprattutto un bravo project manager) ha la sobrietà e la lucidità di giudicare codice concorrente dall’alto, senza far scendere minimamente in campo l’orgoglio.

In molti purtroppo, hanno ridimensionato il fenomeno dell’opensource, non perchè non funzioni, ma perchè alcuni progetti molto spesso per una ripicca di qualcuno hanno subito ritardi, stalli, portando poi ad un nulla di fatto. È questo poi il motivo per cui GIMP è ancora fermo e non vengono rilasciate versioni stabili da eoni, così come accade per Compiz. Tutti progetti cari al buon telperion, che ne parla come un padre di un figlio che va male a scuola; ci espone di una fantastica patch per GIMP che ne modifica sensibilmente l’interfaccia grafica, portando in alto i controlli dello strumento che si sta utilizzando.

Proposta tale patch, quale risposta viene data? “No ma, noi abbiamo deciso così, guarda, è facile: fai un fork e applica il tuo cambiamento”.

Ma siete scemi? L’ottica del forka o muori è morta da anni. Bisogna essere dei leader calibrati per saper condurre un progetto in totale apertura, e se non lo si è, preferisco accettare che mi venga chiuso il ciclo di sviluppo, piuttosto che vedere esclusi tutti i miei contributi. Ci sono un po’ di progetti che, grazie a queste alzate d’ingegno, sono rimasti fermi anni anzichè portare la ventata d’innovazione che il loro manifesto prometteva: è ora di smetterla con quest’ottica dittatoriale del “si fa come dico io”. No: si deve fare cos’è meglio per tutti. E cos’è meglio per tutti si vede, semplicemente usando il programma, provando le patch concorrenti. Potrebbe sembrare che il tutto rallenti, ma in realtà se si cominciano a scartare i contributi esterni, i tempi si faranno ancora più stretti. E col tempo l’apporto di codice al GIT del progetto calerà drammaticamente, perchè in un’ottica del genere, o sei pagato, o sei fortemente legato (in maniera sentimentale, dico) ad altri membri del progetto, oppure non ci stai, a fare la pecora.

L’opensource è anche fantasia, e chi non lo capisce merita che il proprio progetto affondi.