Open source: la ricetta per imparare a giocare insieme

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.

Facebook Comments

6 COMMENTS

  1. Buon inizio, che saluto direttamente con una richiesta. Hai scritto:

    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.

    Io due settimane fa ho invece incontrato un programmatore che sostiene che per fare Open Source
    “o bisogna avere l’appoggio di un ente che lo supporti oppure essere una grande azienda che può permettersi di guadagnare anche su altro.”

    Ho raccontato quella storia qui:

    http://stop.zona-m.net/it/2012/01/da-chi-e-sostenibile-lopen-source/

    e ha scatenato parecchi commenti, soprattutto nella versione inglese ( http://stop.zona-m.net/2012/01/who-can-afford-open-source/ )

    per ovvie ragioni, mi interessa anche un commento tuo, e di tutti i lettori di questo sito

  2. @M. Fioretti: Il tuo commento ed il parere di quel programmatore sono emblematici. Sempre più spesso infatti si tende a trattare i prodotti open source come gratuiti e a confoderli con del software proveniente da ONLUS o simili.

    È normale che se la tua azienda non ha una strategia che comprenda un business plan con l’ottica di rilasciare il codice, sei bello che fallito. Il discorso del programmatore che tu citi funziona solo se a sviluppare è appunto qualcuno senza interesse economico.
    Ti pare che Matt Mullenwegg o Larry Page siano persone che fanno beneficienza? 😛

    Bisogna saper sfruttare l’ambiente, secondo me, anzichè puntare ad avere un ricavo nel modo tradizionale con una strategia nuova. Quindi piuttosto che tentare di adattare una nuova logica di lavoro ad una vecchia logica di profitto, bisogna rimodernare un po’ il concetto di collaborazione e soprattutto ricercare in che modo si può “fare soldi” su qualcosa del genere.

    Mi ripeto: i fatturati di medie imprese come Automattic parlano da soli.

    • “Il tuo commento”?

      veramente io, che Open Source non significa “gratuito o proveniente da ONLUS o simili”, lo so da più di 15 anni. Lo so benissimo che è tutt’altra cosa.

      Il mio ruolo in quell’articolo è soltanto “voi che ne pensate di quel che dice Francesco? Secondo voi quanto è corretto o generalizzabile il suo punto di vista?”

  3. Si, intendevo il tuo commento come contenuto inserito nel contesto 😉
    Per me risulta vero quanto ho scritto: risulta generalizzabile nell’ambito di quelle organizzazioni che considerano il software libero una soluzione stile ONLUS. Non metto in dubbio le tue conoscenze, anzi: ti dico che quella di Francesco è la tipica risposta secondo me emblematica da persona frustrata nel vedere che l’open source, così come viene adattato alle attuali strategie di mercato, non rende quanto dovrebbe.

    Non prende minimamente in considerazione, per quello che credo, un manager che non sappia allocare nel modo giusto le risorse o una compagnia che non abbia una strategia open valida.
    È giusto se si dice, per cercare di “fare soldi” con l’open secondo il modello di business tradizionale, allora o sei una ONLUS o saluti.

LEAVE A REPLY

Please enter your comment!
Please enter your name here