open || closed

Open source: la ricetta per imparare a giocare insieme

linuxwindow

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 “”, 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.

Alessio Biancalana

Alessio Biancalana

Il giorno che i suoi genitori gli regalano il suo primo computer, comincia la sua avventura nel mondo del digitale. Parecchi anni dopo, avviene per lui il contatto con il sistema operativo Linux e (conseguentemente) con il mondo dell’open source: un mondo fatto di codice, numeri, compiti, obblighi, contributi ma soprattutto di persone, e di complessi rapporti che le legano. Studente di Ingegneria Informatica, giornalista online riguardo il codice aperto e i sistemi Unix, ma soprattutto smanettone nell’anima.

Twitter 

9 commenti

Commenti e reazioni su:

Loading Facebook Comments ...

9 Comments

  1. Oberon

    27/01/2012 alle 10:16

    Credo proprio che ti leggerò anche qui.
    In bocca al lupo.

  2. M. Fioretti

    27/01/2012 alle 10:43

    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

  3. Alessio Biancalana

    27/01/2012 alle 12:05

    @Oberon: Grazie mille della fiducia; crepi 🙂

  4. Alessio Biancalana

    27/01/2012 alle 15:55

    @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.

    • M. Fioretti

      28/01/2012 alle 15:23

      “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?”

  5. Alessio Biancalana

    29/01/2012 alle 00:32

    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.

  6. Pingback: Software Open Source o proprietario? Per rispondere ci vuole una cultura del software? | Stop

  7. Pingback: Software Open Source o proprietario? Per rispondere ci vuole una cultura del software? | :: Daniele Bailo ::

  8. Pingback: Software Open Source o proprietario? Per rispondere ci vuole una cultura del software? | Daniele.punto.Bailo

Lascia una replica

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

No Trackbacks.

TechEconomy è il portale di informazione dedicato a manager, imprenditori e professionisti che vogliono approfondire e comprendere l’impatto delle tecnologie nello sviluppo del business nelle PMI come nell’industria, nella finanza, nei servizi.
Si rivolge insomma a tutti coloro che vogliono capire come le nuove realtà dell'Information Technology - Web 2.0, e-Business, net economy - stiano cambiando l’economia, e con essa la società.
Inizio
Shares
Share This