In tutte le mie precedenti collaborazioni giornalistiche, sin dall’inizio ho preferito cominciare entrando direttamente nel merito delle questioni trattate. Mai mi sono lasciato andare alla “sindrome del primo articolo” che induce qualcuno ad annunciarsi piuttosto che preferire un attacco diretto ai temi; tuttavia, penso che per Open || Closed sia necessaria una piccola introduzione.
Negli ultimi anni ha preso piede la tendenza delle persone a riempirsi la bocca di parole che molto spesso assumono poi significati snaturati rispetto alla natura dei termini originali; è per questo motivo che ritengo che si sia pian piano perso il valore del termine “open source”, e vada chiarificato di cosa parlerò negli articoli successivi, oltre che spiegato a chi magari vuole sapere, ma non ha mai osato chiedere.
È curioso infatti che a certi termini venga associato un significato inevitabilmente freak, quando invece essi sono stati inventati proprio per evitare quel tipo di catalogazione; lo spiego quindi in maniera molto semplice. Pensiamo a un ristorante. Un ristorante carino, che ha il suo giro di clientela, e che un giorno decide di mettere nel proprio menù una ricetta nuova la quale per fama, immediatamente, fa il giro di tutto il quartiere. L’opinione comune è che sia buonissima, che valga decisamente la pena andare in quel ristorante per assaggiarla; ma manca di qualcosa.
Generalmente i cuochi sono dei bonaccioni, se chiedi loro una ricetta molte volte, fosse anche per puro vanto personale (un fattore da non sottovalutare quando si parla di ecosistemi aperti), molte volte ti viene data senza far storie. È così che il nostro cuoco suggerisce gli ingredienti ai suoi clienti, finchè non va da lui un cliente, o (meglio ancora) un cuoco di un altro ristorante e lo informa di aver trovato il pezzo mancante: a quel punto la ricetta sarà più completa rispetto a quella precedente, con un contributo esterno e anche con qualcosa in più. Si sarà infatti consolidata una relazione di fiducia tra due persone che possono essere rivenditore e cliente, ma anche rivenditore e rivenditore o, traslando nell’informatica, programmatore e programmatore.
Quando ero piccolo, la mia maestra d’asilo mi ha insegnato che i bravi bambini giocano insieme. Crescendo mi sono reso conto che non è un’idea da freak quella di condividere una soluzione con qualcun altro: si tratta semplicemente di evitargli di reinventare la ruota, ed è qualcosa che viene molto prima del principio di concorrenza, anzi, proprio perchè è antecedente come pensiero, se ne instaura alla base; opera su una soluzione condivisa, e ciascuno degli enti in gioco si distinguerà per come agisce su quella specifica piattaforma. È qualcosa che conviene, spesse volte, anche nelle aziende dove troppo spesso si tende ad affidarsi a soluzioni proprietarie che a lungo termine si rivelano economicamente pessime.
Giocando di squadra invece, nel meccanismo della cosiddetta “coopetition”, si può avere la miglior soluzione ad un costo contenuto e soprattutto con un largo bacino di utenza e di competenza della comunità che segue il prodotto. Condividere il codice di un’applicazione quindi, o una ricetta, o uno schema elettrico di un componente, è qualcosa che non solo fa parte di noi, ma detta in maniera molto più pragmatica, conviene. E conviene non di poco, anzi. In questa rubrica quindi parleremo non proprio dell’aspetto umanistico, di quanto sia bello condividere il codice o una soluzione, o adottarne di aperte, per semplice spirito di “sentirsi bene con se stessi”, piuttosto affronteremo l’argomento insieme in maniera pragmatica: perchè, quindi, è da considerarsi ottimo un ecosistema aziendale basato su standard aperti, perchè conviene a tutti principalmente in maniera economica, e anche, perchè no, il motivo per cui permette a chiunque di lavorare in maniera più trasparente, migliore, con grande guadagno in termini di interoperabilità (e di fatturato) sia del rivenditore che del cliente.
Giochiamo insieme, quindi, ed esaminiamo i vantaggi del gioco in compagnia rispetto al divertirsi da soli, ché magari porta guadagni maggiori nell’immediato, ma nel lungo termine carta canta, e i fatturati di Automattic, Red Hat e Google sono cosine non da ridere.
