Vorrei provare a vedere se riusciamo a fare una sintesi di quanto ci siamo detti a proposito dei “modelli di business”.
La discussione è partita dall’articolo di ZdNet in cui si diceva che lo sviluppo di prodotti open source può aprire nuove possibilità per le comunità locali (si parlava del Sudafrica).
L’espressione “business model open source” non l’ho inventata io. La si legge, nei fatti, in tanti posti quando, appunto, si dice che esiste un modo alternativo di “vendere” software: invece di farsi pagare per le licenze, si distribuisce il codice secondo modalità open source e poi si “guadagna” tramite i servizi. I sostenitori dell’approccio open source, incluso lo stesso Stallman, affermano che
Programmers writing free software can make their living by selling services related to the software.
A questa discussione si è aggiunta l’osservazione che alcune aziende avrebbero sviluppato il loro modello di business grazie all’open source. E si sono fatti gli esempi di Google e Amazon.
Paolo, con il suo provocatorio post, dice che non funziona così o che, in ogni caso, non è così semplice.
Io ho detto che secondo me Amazon e Google non esistono in quanto usano il software open source. Hanno un modello di business che può essere creato anche senza usare software open source.
Quindi la discussione, mi pare, ha queste domande di fondo:
- Se non ho ricavi da licenze, posso comunque creare una azienda che sia in grado di sviluppare e distribuire un prodotto software basandosi solo sulla vendita di servizi?
- Il fatto che esista il software open source, abilita delle opportunità e dei modelli di business che altrimenti non ci sarebbero?
Siamo d’accordo almeno su questa sintesi?
If you enjoyed this article, please consider sharing it!
Dobbiamo distinguere tra la forma e la sostanza.
Ha ragione Paolo quando dice che in Italia è difficile vendere i servizi ed aggiungo io, ancora più difficile vendere la consulenza. La gente vuole il prodotto, per questo spesso si tende a rendere fisico il servizio. Questo è un primo discorso di forma e non di sostanza. Mi spiego meglio. Sto lavorando come consulente per un gruppo editoriale che sta lanciando un progetto multimediale su più piattaforme. Si tratta di una free press cartacea, con contenuti distribuiti anche in formato digitale. Ebbene. Per chi acquista la pubblicità on line, noi regaliamo la pubblicità sulla carta, che è maggiormente apprezzata, vista la sua “fisicità”. Questa sfera afferisce al sistema di offerta, quindi non ha importanza cosa vendi o cosa regali, se il modello di business sta in piedi. Esiste invece poi un discorso molto più profondo che afferisce alla sostanza del modello di business ed è questo su cui si sofferma Alfonso Fuggetta. I modelli di business di cui parla, sono ancora sperimentali tanto è vero che Paolo giustamente ne lamenta le fondamenta. Il vero problema non è che Paolo e Alfonso sono in contrasto, ma il fatto che non si sono ancora trovati modelli di business “che voi definite open source”, realmente sostenibili. Ciò non significa che non esistano. Sono convinto che a breve, a furia di sperimentare, qualcuno, con un po’ di fantasia troverà nuove strade commerciali, per l’open source, che ha portato un grande cambiamento, anche culturale sia all’IT, al software ma anche al modo di intendere le relazioni di business. Rimango comunque dell’idea che il termine modello di business open source, sia fuorviante per qualcuno, per questo si è dibattito tanto sul termine, che a mio modesto parere è infelice, mentre il concetto che vi sta dietro ora mi è più chiaro.Grazie.
“1. Se non ho ricavi da licenze, posso comunque creare una azienda che sia in grado di sviluppare e distribuire un prodotto software basandosi solo sulla vendita di servizi?”
A mio parere, bisognerá verificare. L’esperienza di Paolo (e in questo contesto mi sembra utile) mostra le difficoltá di questo modello. Personalmente la risposta potrebbe essere no o si. Una cosa c’é da dire, é facile partire svantaggiati rispetto a chi puó godere anche dei ricavi delle licenze.
“2. Il fatto che esista il software open source, abilita delle opportunità e dei modelli di business che altrimenti non ci sarebbero?”
Secondo me, non crea nuovi modelli di business ma piuttosto la presenza di codice sotto licenza libera unito alla presenza di varie comunitá di sviluppo FLOSS creano una situazione favorevole per la nascita di imprese.
Il rapporto non é diretto é molto simile a quello che lei segnala qui ( http://www.alfonsofuggetta.org/?p=437 ) nell’ultimo punto:
“Per questo facciamo di tutto per migliorare l’ambiente in cui viviamo. Ora […] stiamo lanciando un progetto pubblico per coprire l’intero territorio, circa 600 chilometri quadrati, con una nuvola WiFi che consenta il collegamento gratis senza fili a Internet da ogni punto. Saremo la prima regione al mondo a farlo.”
Una rete WiFi non é che crea direttamente delle imprese, ma averne una di quelle dimensioni é un tassello che rende migliore l’ambiente per creare nuove imprese.
Un ultima cosa. Non per fare le pulci ma quando il buon Stallman parla che i programmatori possono vivere vendendo i loro servizi, bisogna conoscere Stallman. Il modello che prende a riferimento é la sua vita e non pensa al concetto di impresa cosi come noi lo pensiamo. E’ una cosa che a Stallman personalmente interessa ben poco. Come sa vive una vita che per molti anni é stata di assoluta povertá e anche adesso é molto frugale. Quindi per lui molti questioni non sussistono proprio.
Per precisazioni sono sempre qui.
Un saluto a tutti,
3D interessante (grazie), ci provo anch’io.
–“1. Se non ho ricavi da licenze, posso comunque creare una azienda che sia in grado di sviluppare e distribuire un prodotto software basandosi solo sulla vendita di servizi?”
Concordo con Tom: DIPENDE dalla capacità di
1) individuare il mercato e scegliere delle applicazioni strategiche.
Non dimentichiamo che la PA ha speso nel 2004 circa 230M/euro per applicazioni e sviluppi “ad hoc” rispetto a spese di circa 50M/euro per SW di base e ambiente e 53M/euro per “pacchetti” applicativi;(nel 2005 stesso disequilibrio -39% degli investimenti).
Questo è un segno evidente che la PA non trova sul mercato “applicazioni” adeguate alle proprie necessità.
Il risultato netto è che gli sviluppi “ad hoc” generano nel 92% dei casi e per’84% dell’investimento SW proprietario (dati CNIPA), non riusabile e spesso fuori standard (questo lo dico io).
2) adattare il processo di produzione.
Bisogna rendersi conto che l’informatica si è avviata (da un po’) verso l’industrializzazione.
“Produrre” codice (anche buono) ha cessato di essere il valore aggiunto.
Oggi i Paesi neoeuropei ed extraeuropei emergenti “producono codice” (anche buono) ad un terzo dei costi.
E’ necessario capitalizzare e valorizzare le COMPETENZE progettuali e di “processo” (capire come la PA “usa” il SW, quali sono le sue necessità operative, normative, ecc).
3) Produrre applicazioni concretamente usabili, calate nel contesto operativo.
Dobbiamo renderci conto che la “resistenza” della PA all’innovazione è un fenomeno complesso che parte dal rifiuto di “complicazioni” e “stravolgimenti dei processi interni” per approdare all’inerzia.
Il SW deve “servire” in modo “facile” e non interferire con gli equilibri di “potere e responsabilità” nel Sistema PA.
4) Offrire “garanzie” di mantenimento e certificazione di conformità alle normative.
Tasto dolente ma necessario: è un gap che l’OSS deve superare se vuole conquistarsi un Mercato.
–“2. Il fatto che esista il software open source, abilita delle opportunità e dei modelli di business che altrimenti non ci sarebbero?”
A mio avviso sì, alle condizioni di cui sopra.
Perdonate le molte(troppe) “” e l’estrema sintesi.
Disponibile ad approfondire.
Cordiali saluti
Umberto Rossini
umberto.rossini@sideco.com
Per Alfonso,
ecco le mie risposte:
1) Si può ricavare sicuramente dalla vendita di servizi sul software OS. Il problema che ponevo era di quanto questo fatto scalasse. Apparentemente, il modello OS tradizionale fa scalare poco l’impresa.
2) Sicuramente la presenza di software OS rende possibili business non fattibili altrimenti. Banalmente, sono abbassati alcuni costi di ingresso, il che facilita la nascita di microimprese.
Inoltre, come nel caso di Google o Amazon, avere il controllo completo dello stack tecnologico attraveso l’OS può essere un fattore di vantaggio competitivo. Ma su questo punto sono meno sicuro, perchè è possibile che lo stesso approccio possa essere ottenuto anche con prodotti proprietari.
Per Umberto,
non sono affatto d’accordo sui tuoi punti 2) e 4). In particolare, è vero che c’è stato e c’è in atto un tentativo di outsourcing verso altri paesi delle attività di sviluppo. Ma esistono numerosi segnali che questo sta fallendo, proprio perchè l’attività di sviluppo (la scrittura del codice vera e propria) è un’attività critica, che ha un impatto fondamentale sul successo di un progetto o di un prodotto.
Inoltre, vorrei capire di quali certificazioni hanno bisogno prodotti come Apache, Samba, Linux o Tomcat rispetto agli altri prodotti proprietari. Non ho mai visto un problema del genere.
Non sono un esperto, ma mi sono messo a fare un po’ di ragionamenti a riguardo.
Partiamo da questa considerazione: qual è la differenza tra software Open Source e software proprietario?
Il codice sorgente del software Open Source è disponibile a chiunque, gratuitamente, e chiunque può scaricarlo, analizzarlo e modificarlo.
Secondo me avrebbe poco senso sviluppare Open Source, se la comunità è limitata ai dipendenti/collaboratori di un’azienda (perlomeno secondo lo scenario che vado a delineare).
Quindi, nel caso di software disponibile al mondo intero, io ci vedo i seguenti vantaggi:
1. Si ha potenzialmente a disposizione una vasta comunità che sviluppa, fa testing, propone miglioramenti… a costo teoricamente zero
2. Il software non può nascondere “segreti”, è lì da vedere; non si possono nascondere “backdoors” o logiche che attuino secondi fini => sicurezza
3. Il software è potenzialmente più robusto; i bug possono essere analizzati/risolti da chiunque => robustezza
E ci vedo i seguenti svantaggi:
1. Lo sviluppo può spezzarsi in differenti branch; si possono generare prodotti distinti con funzionalità analoghe
2. Le attività non sono ben pianificabili (la comunità lavora secondo ritmi tendenzialmente non prevedibili…)
3. Tutte le buone idee, sono copiabili a costo zero da chiunque, anche da chi sviluppa software proprietario
Qual è, invece, la funzione della licenza? La licenza è il diritto all’uso del software, secondo le condizioni stabilite dal produttore. Il produttore, per creare il software, ha sostenuto delle spese che recupera in parte o totalmente vendendo all’utilizzatore il diritto all’uso del proprio prodotto.
Un’azienda che voglia basare il proprio business sul software Open Source non dovrà ripagarsi le spese di creazione del software con le licenze, in quanto il software lo potrà (dovrà…) sviluppare a basso costo. Il valore aggiunto (e su questo credo di essere in linea con Umberto) sarà la capacità di coordinare un team “virtuale”, distribuito, con disponibilità pressoché “aleatoria”; questa spesa di coordinamento unita alle spese per le azioni di marketing dovranno essere ripagate dalla vendita dei servizi; servizi che necessariamente sono quelli di assistenza, personalizzazione, formazione, consulenza, application management (quali altri?).
A questo punto, per basare il proprio modello di business sul software Open Source credo che:
- l’azienda dovrà collocarsi in settori in cui sia necessaria (e ci si aspetti…) un’alta configurabilità e/o personalizzazione del software (il software stesso dovrà essere pensato come altamente configurabile) => individuazione dei settori/applicazioni
- l’azienda dovrà porsi non tanto come software factory (esiste una potenziale comunità mondiale), ma dovrà avere ottime capacità di marketing, di project management e di assistenza => individuazione di modelli e di processi in questo scenario
Come fa notare Umberto, quello della PA è un settore, ma ce ne potrebbero essere altri.
Per Paolo.
Constato che con i punti 1 e 3 del mio post non sei in disaccordo.
Cercherò di charire il resto:
1) Il mio tentava di essere un discorso complessivo, ovvero “individuare una via” di profitto; anche i punti 2 e 4 andrebbero letti in questo contesto: un insieme di condizioni interdipendenti e necessarie.
2) “[...] segnali che questo sta fallendo, proprio perchè l’attività di sviluppo (la scrittura del codice vera e propria) è un’attività critica, che ha un impatto fondamentale sul successo di un progetto o di un prodotto.”
Non concordo pienamente che questi segnali siano numerosi… ma poco importa: essi sono solo l’evidente risultato, appunto, di una carenza progettuale.
Scrivere un WS o implementare un DB, scrivere una funzione o delle Classi possono presentare qualche lieve diversità fra operatore e operatore ma NON fanno la differenza; lo affermo non in teoria ma per esperienza. Naturalmente a patto che la progettazione e la definizione del “processo” siano esaustivi.
Il mio intervento qui andava letto come: “abbiamo un patrimonio di esperienze e competenze progettuali che è il VERO valore aggiunto del SW”.
3) “[...] Inoltre, vorrei capire di quali certificazioni hanno bisogno prodotti come Apache, Samba, Linux o Tomcat rispetto agli altri prodotti proprietari. Non ho mai visto un problema del genere.”
Qui concordo, infatti nell’”individuare una via” mi sono permesso di spostare l’attenzione su un ben piu’ ampio mercato rispetto ai “SW di base e d’ambiente” del quale fanno parte i “prodotti” da te citati.
Il mio intervento qui andava letto nel suo insieme: “le applicazioni strategiche individuate (ad es. le applicazioni per il governo del Territorio) devono possedere le certificazioni rispetto alle normative e garanzie di supporto.
In questo OSS ha un gap da recuperare.
Saluti
Umberto
Per Emanuele:
Le conseguenze che presenti a proposito del software open source non sono conseguenze dirette della disponibilità del codice sorgente.
Faccio un esempio: il DES, uno dei più famosi algoritmi di cifratura disponibile, è stato pubblico per anni (cioé, trattandosi di un algoritmo, il suo codice sorgente era a disposizione di tutti). Ma i principi di progettazione del DES (i meccanismi per i quali poteva funzionare) sono stati noti soltanto dopo moltissimo tempo. Il risultato era che il DES era resistente a certe specifiche condizioni, alle quali altri algoritmi erano vulnerabili.
La differenza che vedo tra software open source e software proprietario è che per il software open source può essere disponibile, oltre al codice, tutto l’insieme delle decisioni progettuali che hanno prodotto il software stesso.
Senza tale conoscenza il codice in se rischia di essere inutile: è noto, ad esempio, che nel caso di progetti software grandi (per esempio Mozilla) sono passati mesi prima che persone esterne al progetto potessero iniziare a contribuire al progetto stesso. E il codice era disponibile…
Umberto,
concordo che, quando la progettazione è stata esauriente, la creazione di un database o la scrittura di una classe è un fatto banale.
Il problema è che, di norma, la progettazione non è affatto esauriente, perchè le specifiche sono parziali o incomplete. E nel caso di sistemi complessi è estremamente difficile avere specifiche stabili, in grado di “resistere” nel tempo: il cliente può avere una comprensione solo parziale dei propri problemi, o può avere difficoltà ad esprimerla correttamente. Inoltre, è tutto da verificare che l’utente finale sappia come utilizzare la tecnologia per il proprio business: di fatto, è l’uso che fa emergere gli spunti interessanti per il cliente stesso.
E’ quello che sta dietro a tutto il movimento delle “Metodologie Agili”. Se esamini, per esempio, quello che fanno aziende tipo ToughtWorks (www.toughtworks.com), che sono System Integrator internazionali, vedrai che i loro chief scientist sono software developer: persone che si occupano di come si scrive il codice. Oggi si tende a parlare addirittura di “emergent design”.
Per la certificazione, rubo una frase tipica di Alfonso quando parla di software open source: il fatto che il prodotto sia open source non cambia i suoi requisiti di certificazione. Questo è semplicemente un problema per quelli che costruiscono la loro offerta commerciale su tali prodotti.
Dove sta il Free Software Business?…
Troppa gente pensa che Free/Libre software sia la soluzione a tanti problemi, incluso il problema del nanismo delle software house nostrane. Credo che inquadrare il problema in questi termini sia ……
Per Paolo,
[...]“Il problema è che, di norma, la progettazione non è affatto esauriente,[...]”
Concordo, su tutto (anche il seguito dei puntini non riportato).
Ma proprio qui sta il problema: che metodo (metodi) di progettazione utilizzare ?
Ancora meglio: quale (ri)organizzazione della produzione condiziona (e come) il metodo(i) di progettazione ?
Qui soffriamo un po’ di esterofilia e di colonizzazione culturale.
La realtà produttiva nazionale (mi riferisco ancora alla PA che conosco) necessita di una “via” autonoma.
Allo stato, confesso, non ti sò rispondere (ci sto lavorando). Sto “sperimentando” forme miste di progettazione con lo scopo di ridurre al massimo i problemi che citavi.
Fammi gli auguri.
[...]“Per la certificazione, rubo una frase tipica di Alfonso [...]”
Perdonami l’equivoco (se di equivoco si è trattato).
Il problema per la PA con OSS è: “[...]BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.[...] come da http://www.gnu.org/licenses/gpl.txt
Questo la PA non lo accetterà MAI.
Semplicemente perchè NON PUO’.
E’ necessario integrare i SW OS con “garanzie” e certificazioni che tutelino. (questo intendevo).
Un saluto
Umberto
umberto.rossini@sideco.com
Umberto: la parte di licenza che citi è standard e, se ti prendi la briga di leggerti pure gli EULA di Microsoft (uno a caso) noterai che dicono la stessa cosa.
Le garanzie si possono vendere anche sul software distribuito con la licenza GNU GPL.
Per Stefano, (ma anche per tutti)
Cerchiamo di capirci:
Al di la delle facili battute i prodotti Microsoft (ma tutti in generale i prodotti “commerciali”) sono ceduti con un “supporto” “de-facto” che “protegge” la PA da malfunzionamenti fornendo nel contempo le “upgrade” necessarie a “garantire” l’investimento.
Così facendo la PA viene “DERESPONSABILIZZATA” (è questo il fattore fondamentale di successo) dei possibili casini generati dal SW acquistato.
Ovvero il “valore aggiunto” è la Corporate che sta “dietro” il SW.
Con OSS questo è tutto da costruire. Nel senso che la “Comunità” non “garantisce” un bel nulla.
E [...]“Le garanzie si possono vendere anche sul software distribuito con la licenza GNU GPL.”[...] Certo, appunto, facevo notare che (sempre in funzione del discorso avviato nel mio primo post) in questo OSS ha un gap da recuperare.
Non facciamo finta che (tanto per cambiare Marchio) Oracle Spatial .10 “garantisce” i suoi acquirenti tanto quanto PostgresSQL.
Un saluto a tutti
Umberto
Umberto,
scusa, non capisco. Moltissime PA già oggi usano software open source. Alcune regioni fanno bandi che prevedono esplicitamente l’uso di software open source nella realizzazione delle soluzioni.
Se parliamo di società, allora ti rispondo che dietro molti prodotti OS ci sono società (per esempio, MySQL AB dietro MySQL).
Nessuno pretende che la garanzia arrivi da una community. E’ una società (più o meno grande) che garantisce il prodotto.
Umberto: a me pare che stai facendo molta confusione. Non sto facendo battute, sto seriamente dicendo che tra sw libero e proprietario non ci sono differenze sostanziali riguardo le garanzie che possono essere fornite alla PA o ai clienti enterprise.
Forse non capisco il tuo uso del termine ‘garantire’: magari dici che la “percezione della qualità” di Postgresql sia inferiore a quella di Oracle? Ovvero che nessun dirigente è mai stato licenziato per aver scelto Oracle? E chi può negare questo
Purtroppo tramite commenti su un blog non ci si riesce a spiegare più di tanto. Mandami via email il tuo numero di telefono e ne parliamo meglio.
la discussione si fa interessante…
siamo partiti dalle osservazioni sulla sostanziale “non scalabilità” delle imprese che hanno nella produzione di sw open source il loro core-business
e siamo arrivati alle garanzie per il cliente nei vari casi.
Avrei un’esperienza da citare ma porterebbe via troppo tempo, riassumo con una domanda:
conoscete qualcuno che, a fronte di un danno economico causato dal bug di un software “commerciale”, ha ottenuto un risarcimento, facendo valere le presunte “garanzie” ?
Salve,
Scusate.
Ci siamo persi un po’ il discorso che partiva dal primo post e (mea culpa, Stefano hai ragione) rispondendo ai singoli ho forse innescato delle incomprensioni (dovute alla fretta).
Prometto di ritornare sull’argomento con piu’ dettagli appena mi sarà possibile rispondendo anche alle perplessità di Paolo, Stefano e Carlo.
In ogni caso una chiacchierata la faccio volentieri con chiunque abbia passione per questo argomento.
Saluti
Umberto
umberto.rossini@sideco.com
[...] Interessante discussione (proseguita poi qui e qui!)sul blog del Prof. Fuggetta a proposito del business su prodotti Open Source. Da seguire non perdere! [...]
[...] update = Appena finito di scrivere questo post mi sono accorto degli altri due presenti e successivi a quello originario (un classico, per certi versi): reazioni al post di Paolo e commenti, e quindi vediamo se ci capiamo. Prenditi il tempo che ti serve, leggi e rifletti. Puo’ essere illuminante. imprenditoria, opensource [...]
@Umberto: tipicamente le licenze dei software commerciali ti dicono che:
- il prodotto che tu hai acquistato (per esempio AutoCAD) non e’ detto che sia quello che risponda alla tua esigenza (per esempio disegnare componenti tecnici al pc);
- che non e’ detto che il software che hai comprato (per esempio un software di calcolo strutturale o termico) ti dia risultati corretti (se crolla il palazzo che hai costruito per un errore strutturale chi paghera’ tu ingegnere o la software house?);
- il supporto fisico di installazione non si rovinera’;
- e poco altro.
Quindi la frase di Maffulli:
è tragicamente vera.
[...] un pò come da tempo vedo provare a fare il professor Fuggetta in alcuni suoi post di cui non vedo eco [...]