John Mark Walker – Monetizzare l’Open Source – IV – La chiave per il successo

Ultima puntata della serie di articoli di John Mark Walker – Open Source Ecosystems Manager per Red Hat – sulla monetizzazione dell’Open Source.

Potete leggere l’originale in Inglese: How to Make Money from Open Source Platforms, Part 4: The Key to Success; oppure , qua sotto, la traduzione.

La serie di articoli è stata scritta da Walker a titolo personale, non come rappresentante di Red Hat.

La vittoria dell’Open Source

In questa serie di articoli ho detto e ripetuto che l’Open Source non riguarda tanto l’innovazione quanto la libertà.

Le piattaforme Open Source sono state adottate perché danno la massima libertà nel deploy: si rilascia ciò che si vuole, quando si vuole.

Mi irrita sempre un po’, quindi, quando, leggo sui media mainstream descrivere la comunità Open come una banda di Hippy a cui il denaro non importa e che condividono cantando il software che hanno creato.

Bada bene: io amo “cantare” a proposito del Free Software, ma in quella descrizione c’è una implicazione falsa, relativa al fatto che nell’ambito del Free software non ci sia circolazione di denaro.

È ciò che Paul Krugman definirebbe “una bugia zombie” – perché è una argomentazione che continua a riproporsi, nonostante sia, ogni volta, uccisa dai fatti.

Se pensiamo a tutti coloro che lavorano nell’ambito del Free Software: vendor, service provider, consulenti, sistemisti, veterani dell’IT stiamo pensando in realtà a un ecosistema che fa circolare milioni di miliardi di dollari su scala mondiale.

Stiamo parlando di una economia che, se fosse quella di un Paese, potrebbe eguagliare, se non superare, il PIL degli Stati Uniti.

La quantità totale di transazioni finanziarie, servizi internet, agenzie governative, archivi e ogni sorta di azienda dipendenti dal Free Software è semplicemente impressionante.

Nonostante questo, continuiamo a sentirci dire che il successo dell’Open Source è tutto legato al prezzo, il prezzo di un qualcosa che non può essere venduto perché nessuno pagherebbe per acquistarlo.

Nei miei interventi non manco mai di evidenziare che quando si parla di Free Software e di Open Source non è solo una questione di prezzo, anche se questo aspetto è comunque influente.

E la ragione per cui sappiamo benissimo che non è solo una questione di prezzo sta nella comparazione con i risultati di una tattica di marketing molto nota, il modello “freemium”.

Il modello freemium consiste nel vendere qualcosa dal valore limitato perché sia consumato nella speranza che chi lo acquista sia poi indotto in futuro a comprare il prodotto completo.

C’è sicuramente spazio per i prodotti freemium, come dimostrato dal caso Splunk, ma il vero vincitore non è il freemium: è l’Open Source.

Bastano semplici analisi dei clienti e di come acquistano le soluzioni a loro necessarie per capire come stanno veramente le cose:
come potenziale cliente, perché mai dovrei legarmi a un singolo vendor quando non sono neanche sicuro che il suo prodotto faccia al caso mio?

Inoltre, investire tempo in un prodotto freemium significa averlo in realtà sprecato se si decide di rivolgersi poi a un prodotto o servizio differente. Molto meglio, allora, investire energie e tempo là dove possano essere recuperati.

È questo valore – la libertà – che sta alla base del software Open Source, anche di quello a pagamento, software che ha comunque maggior valore intrinseco ed è più conveniente, nel lungo periodo, rispetto al freemium. La scelta di passare all’Open Source comporta intrinsecamente del valore aggiunto, tanto per lo sviluppatore quanto per l’utente finale.

È questo aspetto che i sostenitori dell’Open Core non sanno assolutamente cogliere: per loro l’Open Source è soltanto un altro strumento di distribuzione di prodotti / servizi freemium, mentre in realtà è molto, molto di più.

Svalutando la piattaforma Open Source svalutano in realtà proprio ciò che i clienti cercano. Vedono l’Open Source solo in termini di strumento di distribuzione o, ancora peggio, come un serbatoio di lavoro gratis che, senza fatica, non farà altro che portare acqua al proprio mulino.

Ma non si può sperare di ottenere in cambio del valore senza prima concedere un po’ del proprio controllo.

E dopo questo lungo preambolo, è decisamente tempo di andare al sodo.

Dadi e bulloni del codice sorgente

A questo punto potreste pensare:

OK, benissimo, il Free Software ha un suo valore intrinseco… Ma come posso usare quel valore per generare profitto?

È come cuocere le salsicce: ci piace mangiarle quando sono pronte, ma cuocerle è sempre un casino. Per i prodotti Open source è lo stesso: quel che segue sono dei suggerimenti per “cucinare” più facilmente, e non sono necessariamente l’unico modo di “cucinare”.

Dopo aver affrontato nel post precedente la productization, la creazione del prodotto, questa come impatta sulle pratiche di ingegnerizzazione?

In primo luogo, se si crea un prodotto con il supporto di test e test di certificazione, probabilmente non sarà possibile utilizzare la stessa release della piattaforma Open Source.

Un altro errore in cui le aziende cadono spesso è che la productization non consista in altro che nell’impacchettare ciò che è Open Source adornandolo con quel tanto che basta per cominciare a vendere.

Ma la strada per l’inferno è lastricata dalle carcasse di migliaia di aziende che avevano pensato che la productization consistesse in niente di più che rendere sexy il prodotto.
La productization del Software Open Source, invece, richiede la capacità di “vedere” il prodotto e coglierne la complessità.
Partiamo da un diagramma che mostra come vengano rilasciate le varie versioni del codice in molti progetti Open Source:

monetizzare Open Source

Il processo Open Source continuerà a produrre nuove versioni delle varie ramificazioni del codice stesso. Al vendor, a questo punto, si prospettano alcune scelte interessanti:

  1. Come decido quali ramificazioni utilizzare per il prodotto?
  2. Come decido che cosa fare delle modifiche applicate al codice sorgente?
  3. Ma non è che andando avanti così sto dando alla gente, gratis, i frutti del mio duro lavoro..?

Le risposte a queste domande sono:

  1. Dipende.
  2. Le modifiche, l’eliminazione dei bug e i miglioramenti vengono applicati rispettivamente alle loro ramificazioni – “madre”.
  3. Forse.

Di nuovo: l’obiettivo non è quello di danneggiare il progetto Open Source che è il “genitore” del prodotto / servizio.

Il prodotto stesso ne risulterebbe danneggiato, evidenziando la sua dipendenza dal codice Open. D’altra parte, non si può neanche mantenere private le modifiche al codice, custodirle gelosamente per sé, perché comunque a ogni modifica ci si troverebbe a un bivio, dover scegliere all’infinito tra ciò che è parte del codice sorgente – Open – e ciò che non si vuole ne faccia parte, e sottoporre i propri team di sviluppo e produzione a un continuo, disordinato flusso di carenze tecniche da risolvere è l’ultima cosa da desiderare.

Una volta che si è scelto di sviluppare un prodotto partendo da un progetto Open Source, con questa scelta si deve fare i conti.

E questo significa lavorare simultaneamente al miglioramento del progetto Open Source di concerto con il miglioramento del prodotto che si è sviluppato.

La buona notizia è che, presa questa decisione, applicata al prodotto una differente etichetta, non è più necessario dimostrare quale versione del prodotto si sta vendendo rispetto all’iniziale progetto open.

Si è, a questo punto, liberi di lavorare tanto sul progetto quanto sul prodotto e sulle loro rispettive evoluzioni senza comunque cannibalizzare gli sforzi produttivi.

E quel che si vende ai propri clienti non è il codice sorgente, ma un valore aggiunto che da esso deriva. Certo, il codice sorgente rappresenta parte del valore, ma non si sta vendendo solo quello.

Una volta terminata la fase di ingegnerizzazione, la situazione si dovrebbe presentare più o meno così:

La parola chiave è “Bar”: la ramificazione stabile su cui vengono effettuati test, certificazioni, Quality Assurance / Quality Engineer, marketing e packaging del prodotto.

È la ramificazione che ha come caratteristica il rimanere più statica rispetto alle altre, soprattutto rispetto a quelle da cui deriva.

Le versioni Open Source saranno probabilmente molto simili alla ramificazione del prodotto, ma sono le implementazioni sul ramo “Bar” – ancora: i test, le certificazioni… – a garantire che il prodotto possa veramente funzionare in tutti gli ambienti operativi in cui lo si sta vendendo.

Ancora una volta, tutto sta non nel codice, ma nel processo.

È il processo a far sì che in vendita vada un prodotto certificato per il maggior numero possibile di configurazioni software e hardware.

Per rendere ancora più chiaro il concetto, nella visualizzazione che segue si tralasciano il codice sorgente e le ramificazioni, riducendo la piattaforma a un insieme autoconcluso:

Con questo schema in mente è facile comprendere come i clienti vengano premiati dal valore aggiunto dell’esperienza acquisita sul prodotto e dalla sua conseguente stabilità, soprattutto tra una release e l’altra.

Tanto gli ISV – i vendor indipendenti a cui è affidata la vendita del prodotto – quanto gli sviluppatori esterni apprezzeranno la stabilità e affidabilità del prodotto stesso, il fatto che le API non siano sottoposte a cambiamenti improvvisi, il fatto che i pacchetti di test siano strutturati in modo tale da mantenere la consistenza del prodotto.

Come vendor ci si avvantaggerà del fatto che, tra una release e l’altra, la stabilità renderà più semplice il supporto al prodotto stesso.

Una volta intrapresa questa strada, i vantaggi sono subito evidenti.

Mentre si sviluppa e mantiene il codice Open Source, si crea anche uno spazio per i clienti che potranno avvantaggiarsi dei contributi creati per il codice Open Source stesso.

Un aneddoto chiarirà ancora di più di che cosa sto parlando:

È il caso di un vendor che, a un certo punto, aveva diviso la community legata al suo prodotto dalla community legata al suo marchio, al suo essere brand.

Fu una scelta controversa, ma questa divisione rese anche possibile concentrarsi sul cercare di vendere il prodotto a veri potenziali clienti, invece di perdere tempo in discussioni con chi non avrebbe mai acquistato il prodotto.

Una soluzione, alla fine, vincente per tutti: il mercato aveva le idee più chiare su che cosa fosse in vendita e che cosa fosse free, l’azienda aveva un prodotto di successo con una sua community, i clienti avevano a disposizione i vantaggi dell’innovazione Open Source, un ottimo prodotto free e una assoluta trasparenza su ciò che era free e ciò che invece era il prodotto.

Un approccio misto

Dovrebbe essere ormai chiaro che, da strenuo sostenitore del free software, non raccomanderei mai una strategia proprietaria per il free software.

Dopotutto, è il motivo per cui non mi piace l’Open Core, giusto?

A dire il vero non è che non mi piace l’Open Core perché è “ideologicamente impuro”: molto più semplicemente, non mi piace perché non funziona.

Questa mia, comunque, non è l’unica “ricetta” per scrivere e vendere software, ma è un buon inizio e dimostra come sia possibile utilizzare l’Open Source per vendere software proprietario.

Ma non avevamo detto che gli approcci Open Core e Ibrido non funzionano?

Infatti non sono questi gli approcci che sto proponendo.

Quello che sto proponendo è di partire da una valida piattaforma Open e, sulla base di essa, iniziare a costruire il prodotto, senza ignorare il valore intrinseco della piattaforma stessa.

In altre parole, in questo scenario, il volano della monetizzazione è la piattaforma Open e, qualunque software a pagamento venga proposto a partire da essa, si crea un circolo virtuoso in cui è la piattaforma Open stessa a trasferire maggior valore intrinseco al prodotto sviluppato: si crea un ecosistema in cui la piattaforma Open è un centro sempre più importante attorno al quale gravitano valore e clienti potenziali in aumento.

Certo: in questo scenario gli add-on al sistema Open – di fatto, il software prodotto sulla base di esso – potrebbe essere Open a sua volta. Ma il circolo virtuoso inizia comunque, quando si cominci a vendere il prodotto nella forma di software certificato.

Scegliere se, a questo punto, si voglia cominciare a vendere software proprietario è una delle opzioni: la chiave è – comunque – quella di non svalutare la piattaforma in sé.

Perché, è bene ricordarlo ancora una volta, una piattaforma Open Source di successo ha un alto valore intrinseco, e una azienda apprezza quel valore, ed è disposta a pagare per esso.

La grande rivelazione

Questo processo non è semplice, non lo direi mai: ma nessun processo di successo lo è.

Creare un prodotto di successo è difficile, sia nel caso in cui sia Open sia nel caso in cui sia invece proprietario, ma almeno, raggiunta la fine di questa serie di articoli, spero che sia più chiaro come ci si possa avvantaggiare dell’innovazione e dei processi dell’Open.

La chiave di tutto è una trasparenza cristallina verso il mercato e i potenziali clienti a proposito di che cosa si stia vendendo, rimuovendo sin dall’inizio qualsiasi possibile fraintendimento e assicurandosi che quei potenziali clienti possano comprendere il valore inerente al prodotto Open Source.

L’Open e gli approcci misti consentono al vendor di dare al mercato e agli utenti quella chiarezza che farà da selezione naturale rispetto ai clienti potenziali, rendendo l’ecosistema più efficiente.


  1. John Mark  Walker: monetizzare l’opensource
  2. John Mark Walker: monetizzare l’Open Source – II – Open Core o approccio ibrido
  3. John Mark Walker – monetizzare l’Open Source – III – Creare un prodotto
  4. John Mark Walker – Monetizzare l’Open Source – IV – La chiave per il successo

3 pensieri su “John Mark Walker – Monetizzare l’Open Source – IV – La chiave per il successo”

Lascia un commento

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