In che modo competi efficacemente con un progetto open source?

Una società con un solido progetto open source in competizione con un prodotto tradizionale open source sembra impossibile da battere.

Ho letto questo articolo in cui l'autore espone questo scenario:

Supponiamo che uno potrebbe dividere un mercato del software, ad esempio la gestione della rete, tra due prodotti. Uno ha fatto tutto il possibile e costava 1 milione di dollari, l'altro solo il 10% in più, ma era gratuito e aperto.

Il prezzo della soluzione commerciale filtrerebbe automaticamente un gran numero di utenti e queste persone dovrebbero passare all'open source. Ma alcuni utenti sarebbero soddisfatti della funzionalità del 10% e la sceglierebbero a fondo.

Ad esempio, ho un computer Macintosh originale sulla mia scrivania. Esegue un elaboratore di testi chiamato MacWrite. Fa tutto, ad eccezione del controllo ortografico, che mi serve un elaboratore di testi. Posso formattare paragrafi, scegliere caratteri, rendere il testo in grassetto o corsivo e persino incollare immagini e grafici. Tutto in un'interfaccia utente "ciò che vedi è ciò che ottieni".

Occupa 76 KB di spazio su disco. Questa è "K" come in "kilobyte".

Confrontalo con Microsoft Word. Penso che l'ultima volta che ho installato Word sia stato di circa 30 MB, molte volte più grande di MacWrite, ma non lo uso per molto più di quanto io usi MacWrite. Come me, molti utenti sono soddisfatti delle funzionalità di base. Non hanno bisogno di tutte le campane e fischietti.

Ma torniamo alla mia analogia. All'inizio, la società commerciale avrebbe probabilmente ignorato il progetto open source. Non rappresenta alcuna minaccia per il loro flusso di entrate, quindi perché dovrebbero prestare attenzione a un avvio?

Se questo progetto è sano e sostenibile, tuttavia, tra circa un anno forse fa il 15% -20% di quello che fa il prodotto commerciale. Ciò dovrebbe far fuoriuscire alcuni utenti dalla loro attività e forse ora iniziano a prestare attenzione.

Molto probabilmente, questa attenzione assumerebbe la forma di marketing contro il progetto. Direbbero che è troppo piccolo o troppo poco potente per essere preso sul serio. E nel breve periodo probabilmente funzionerebbe. Ma il semplice fatto che abbiano riconosciuto il progetto susciterebbe interesse. Alcune persone determinerebbero da sole che non era né troppo piccolo né troppo poco potente e avrebbero iniziato a usarlo.

Passano un altro anno o due e ora il progetto rappresenta fino al 50% della funzionalità del prodotto commerciale. Le persone iniziano a unirsi al progetto a frotte. La società commerciale ora deve fare qualcosa. Cosa fanno? Aggiungono più funzionalità.

Ricorda, il prodotto commerciale ha già fatto il 100% di ciò di cui le persone avevano bisogno. Quindi che tipo di funzionalità potrebbero aggiungere? Quelli non necessari. Potrebbero cambiare l'aspetto dell'interfaccia utente o aggiungere funzionalità al di fuori della gestione della rete. In ogni caso, questo sviluppo costerà denaro e questo inizierà a consumare i margini dell'azienda.

Infine, con una comunità sana e questo afflusso di nuovi utenti, il progetto open source alla fine si avvicinerà all'80% -90% di quello che fa il prodotto commerciale. Avendo esaurito tutte le strade per generare entrate, la società commerciale ha ancora un'ultima opzione: mettere le viti ai restanti clienti. Trova il modo di farli pagare di più, per ottenere ciò che possono dal loro investimento, che alla fine allontanerà i loro clienti.

Inverosimile? Io non la penso così. Esistono solo due requisiti principali:

Innanzitutto, trova un mercato in cui l'open source offre un'alternativa interessante, come la gestione della rete.

In secondo luogo, costruire una comunità sostenibile attorno al progetto open source.

Sembra molto plausibile. Se tu fossi la società di origine chiusa, come competeresti ??

Dal momento che non puoi competere sul prezzo, quindi competi su tutti gli altri punti di vendita che il software ha:

• Caratteristiche
• qualità
• efficacia
• integrazione con altri software
• servizio
• supporto
• vendita diretta

Fondamentalmente, fai quello che ogni altra azienda fa quando sono in concorrenza sui prezzi: tenere il passo o cambiare il gioco.

Rendendo il tuo prodotto migliore dell'offerta open source. Ecco come Photoshop può competere con GIMP.

Penso che il pezzo che citi sia molto fuorviante, in quanto ignora completamente la qualità dell'offerta open source. Ponetevi una domanda leggermente diversa ma correlata:

Come può un'azienda sopravvivere sopravvivere vendendo software open source?

Essendo un frequente collaboratore di alcuni progetti open source, mi sento ragionevolmente autorizzato a lanciare alcuni round di fango dove lo merita.

Nulla di ciò che segue si applica ai progetti OSS speciali come Linux, Firefox, MySQL o PostgreSQL, intendiamoci. Questi sono atipici, in quanto sono supportati da aziende e / o programmatori esperti.

In ogni caso, per i motivi per cui il cliente pagherà per il software:

OSS è incline a presentare funzionalità / I clienti pagheranno per un software più semplice

I collaboratori di OSS hanno tutti la loro funzione per animali domestici. Questi alla fine troveranno la loro strada nella base di codice. Ci vuole una leadership estremamente esperta, ferma e carismatica per evitare il problema, e come qualsiasi altro ragazzo a molti sviluppatori di core OSS manca almeno uno di questi tratti.

Aggiungendo l'insulto al danno, per ogni caratteristica non essenziale che si insinua, un altro non lo vorrà e questo comporterà l'aggiunta di opzioni. I programmatori tendono ad amare le opzioni, ma dal punto di vista dell'interfaccia utente sono un percorso sicuro per una morte lenta e dolorosa di mille tagli.

Gli utenti finali desiderano strumenti semplici. Devono svolgere il proprio lavoro senza alcuna curva di apprendimento o confusione. Vogliono che i loro strumenti prendano le giuste decisioni per loro; non opzioni. Se riesci a fornire qualcosa di più semplice dell'implementazione OSS autonoma, otterrai clienti paganti.

OSS tende ad essere di bassa qualità / I clienti pagheranno per una qualità superiore

Non c'è nulla di intrinsecamente sbagliato nell'apprendimento del codice contribuendo all'OSS, intendiamoci.

Va detto, tuttavia, che per ogni OSS o libreria di alta qualità che è supportato per ogni sorta di ragioni da aziende e programmatori esperti, c'è un oceano di codice spaghetti incline a bug scritto da programmatori inesperti che stanno contribuendo OSS in uno sforzo per imparare la programmazione e chi ha poca o nessuna idea di cosa stiano facendo.

WordPress, ad esempio, è stato biforcuto da B2 (a sua volta progettato da uno studente) da uno studente. Versioni multiple e quantità indicibili di nastro adesivo in un secondo momento, fa il lavoro. Ma sotto il cofano, c'è un diluvio di bug con poco o nessun controllo di qualità. (L'ultima volta che ho provato, non ha superato con successo la propria suite di test.)

I clienti pagheranno per software ben gestito e testato. Quasi tutti proveranno le cose gratuite, intendiamoci, e molti tollereranno persino i bug fino a un certo punto. Ma se le loro entrate dipendono da questo, alla fine cercheranno un software di qualità superiore e lo pagheranno.

OSS tende ad avere un ciclo di sviluppo troppo breve / I clienti pagheranno per evitare problemi

Questo è inerente al processo di sviluppo. Le funzioni per gli animali domestici inserite nella base di codice devono essere rilasciate in tempi ragionevoli. In caso contrario, il rischio è che il progetto OSS perda alcuni dei suoi collaboratori.

A lungo termine, tuttavia, le aziende preferiscono cicli di rilascio lunghi; più a lungo, meglio è. È meno pianificazione e meno lavoro per il reparto IT. Non è un grosso problema se gli utenti finali aggiornano il proprio browser ogni tre mesi circa. È una storia completamente diversa se stai aggiornando applicazioni mission-critical.

C'è stata una recente discussione sull'accelerazione del ciclo di rilascio nell'elenco degli hacker di PostgreSQL. L'argomento conclusivo contro non riguardava il QA e la necessità di prolungare i periodi di beta-test. È stato che alcune aziende stavano già saltando ogni altra versione, perché l'attuale ciclo di rilascio (1 anno) era già troppo veloce per loro.

Contrariamente a WordPress, che ogni tanto discute di un ciclo di rilascio di 3 mesi nonostante un ciclo già troppo breve. (I loro beta sono, a tutti gli effetti, la versione xy0 di ogni versione.)

Avendo alcuni clienti che usano WordPress, posso assicurarti che sono più che felici di occuparmi di loro per garantire che i loro siti non si facciano saltare in faccia quando eseguono l'aggiornamento. I clienti pagheranno per non aver bisogno di preoccuparsi di questo tipo di seccatura.

OSS tende ad abbracciare senza pensarci standard aperti / I clienti hanno solo bisogno di cose per funzionare

Il tag video HTML5 è un esempio qui.

Il caso di Mozilla per il rifiuto di h.264 è che vogliono un codec open source. E sono assolutamente corretti in questo senso: l'ultima cosa che vogliono è essere nella hit list dei troll di brevetti; quindi spingono per Ogg.

Il caso di Apple per abbracciare h.264, al contrario, è pratico: è già ampiamente supportato e ha un'accelerazione hardware (che consente quindi di prolungare la durata della batteria degli iPhone); non esiste una cosa del genere per Ogg.

Milioni di dispositivi iOS venduti in seguito, i siti preoccupati per la consegna di video a questi utenti iOS supportano html5 / h.264. In altre parole, i clienti hanno parlato: a loro non interessano i formati aperti.

L'unica azienda che è contenta del risultato di questa feroce battaglia sui codec è Adobe: gli utenti di Firefox continueranno, di fatto, a utilizzare Flash se vogliono riprodurre video. Se un sito principale passa a video solo per html5 / h.264, un programmatore in circolazione troverà rapidamente un'estensione o un plug-in per convertire i tag video necessari in lettori di video flash. (Potrebbe anche esistere già.) In nome del supporto di standard aperti (che flash, per inciso, non lo è).

Nessuno è mai stato licenziato per aver scelto IBM

È una vecchia battuta del settore, ma c'è del vero: quando si esercita un budget IT, non si viene licenziati per aver scelto ciò che i peer considerano il meglio della razza.

I grandi acquirenti aziendali che non hanno voglia di rischiare continueranno ad acquistare desktop basati su Microsoft, Office, SAP e cosa no; anche se ci sono alternative open source. Proprio come succede di merda .

Quando OSS si fa largo in grandi ambienti aziendali, di solito non è perché il CTO ha visto la luce e ha deciso di utilizzare strumenti gratuiti; piuttosto viene canalizzato da una terza parte che offre servizi (costosi) in cima.

Penso che il nocciolo dell'argomento, secondo cui "il prodotto commerciale ha già fatto il 100% di ciò di cui le persone hanno bisogno" è il punto in cui l'argomento cade a pezzi. Nessun prodotto può pretendere di fare il 100% di ciò di cui le persone hanno bisogno e certamente non nel modo più efficiente (in termini di efficienza dell'operatore), facile da usare e universalmente accettato come "migliore".

Se una cosa del genere fosse possibile, ovviamente l'unica cosa rimanente su cui competere è il prezzo. Ma dal momento che un'applicazione "migliore" oggettiva e universalmente "più efficiente" è impossibile, ci saranno sempre più cose oltre al semplice prezzo su cui competere.

Ci sono alcuni punti positivi in ​​quell'articolo, ma ancora una volta, il mondo reale sembra un sacco di esempi in cui le aziende vicine stanno andando bene. Eccone solo alcuni

1. Linux vs Windows
2. PHP vs. ASP.NET
3. [qualcosa o altro] vs. Visual Studio
4. GIMP vs. Photoshop (mi è stato risposto prima, ma avevo davvero bisogno di un esempio non MS :))
5. vBulletin vs. 30+ altri pacchetti di bacheche

Il problema con l'open source è che è aperto. Se si dispone di quel codice, si produce il prodotto A. Tutta la concorrenza ha lo stesso codice. Quindi spendi tutto questo tempo a scrivere software, a condizione che una parte di esso possa essere fatto da altri collaboratori, ma se gestisci un'azienda, stai spendendo risorse e tuttavia chiunque può venire e iniziare a vendere esattamente lo stesso che hai passato anni sviluppando. Quindi la più grande minaccia per una società open source potrebbe non essere necessariamente una società di tipo close-source, ma le altre 5 società open source.

D'altra parte, se sviluppo software chiuso, sì, puoi copiare le mie idee, ma potrei essere ancora avanti di anni nello sviluppo del software e quando entrerai nel mercato, potrei già possederne il 90%.

Infine, in generale, le aziende che non condividono il codice ma fanno pagare per il loro software, generano più entrate rispetto ai progetti open source. Non appena tali entrate vengono generate, una parte di esse non viene reinvestita non in ingegneria (cosa che si potrebbe sostenere potrebbe essere gratuita se si hanno molti collaboratori open source) ma nel marketing e nella promozione del prodotto e ora si stanno parlando milioni di dollari per che non esiste un lavoro libero.

Alla fine, questa è la formula per il tuo successo: [innovazione ingegneristica] x [marketing] = profitto. Puoi avere il miglior prodotto, ma se nessuno lo sa, nessuno lo usa. E chiaramente se costruisci qualcosa di scadente, nessuna quantità di pubblicità lo salverà. Credo che molti progetti open source abbiano sempre avuto problemi con il [marketing] quando si tratta di penetrare nei mercati di consumo generali.

Un'area in cui la maggior parte dei software open source non può competere con i software proprietari è la curva di apprendimento.

Storicamente, ho avuto difficoltà a incorporare tutti i software open source tranne alcuni nel mio set di strumenti. Di solito sono fantastici quando li capisco, ma in genere non provo questa frustrazione iniziale con il software proprietario.

Non sono sicuro del perché questo sia il caso. Posso dire, tuttavia, che sono più che disposto a pagare per il software che fa il lavoro con il minimo sforzo da parte mia. Questo è lo scopo del software dopo tutto.

Renderlo più facile da implementare rispetto alla concorrenza open source e le persone pagheranno.

Usabilità e funzionalità: l'unica cosa che un progetto commerciale di tipo open source avrà che la maggior parte dei progetti open source non ha è la capacità di controllare una visione forte di ciò che il prodotto dovrebbe essere e fare.

Tutto dipende dalla dimensione / complessità, ma un prodotto software a squadra singola più piccolo sarà in grado di concentrarsi sul mercato a cui stanno cercando di attirare. (Quell'altro esempio: come BBEdit e TextMate sono in grado di attrarre un gruppo di persone disposte a pagare per un editor di testo data la disponibilità di jEdit, gEdit, ecc. Che cosa offre TextMate che è abbastanza attraente da indurre le persone a sborsare oltre $ 20 - $ 30)?

Concentrandosi su problemi specifici del cliente. Molte volte ho visto organizzazioni spendere migliaia di dollari per "quella caratteristica".

Come prodotto open source, devono concentrarsi sulle masse (sfortunatamente le masse non acquistano quei software 10K +), come organizzazione a scopo di lucro ravvicinata, se potessi soddisfare le esigenze dei tuoi clienti chiave / critici seguiranno più attività.

Come già accennato da @SnOrfus, l'assistenza e il supporto sono fondamentali. Ho visto miliardi di volte, le organizzazioni che preferiscono il codice chiuso rispetto all'open source (e persino a pagare un extra) per avere il conforto di essere in grado di afferrare qualcuno just_in_case!

(questo potrebbe essere un po 'incentrato sul cliente aziendale)

La soluzione commerciale può giustamente affermare che la sua fortuna è allineata con il successo dei suoi clienti. Questo è il posizionamento del prodotto. Con alcune eccezioni, gli strumenti generalmente open source sono generalmente visti come il paradiso degli hacker, non esattamente una soluzione focalizzata sul cliente.

Se il tuo cliente ha bisogno di alcune funzionalità, hai la forza finanziaria per consegnarle in tempo. Hai la capacità di fornire supporto 24 ore su 24, 7 giorni su 7 (e di addebitarlo), la risoluzione garantita di problemi critici di livello 0, l'accesso alla tecnologia di nuova generazione molto prima della comunità open source se lavori con gli OEM.

Usa questi a tuo vantaggio. Lascia che anche il prodotto gratuito sia sul mercato, non essere ostile. Semmai, questo espande il mercato - a un certo punto gli utenti del prodotto gratuito potrebbero voler provare le campane e i fischi della tua soluzione commerciale.

Per semplicità, riduciamo i fattori di successo di un software in tre "investimenti":

(Qui, "investimento" è un termine collettivo per le attività in cui devi pagare ora, al fine di ricevere entrate in seguito.)

• vendite e marketing
• sviluppo (include codice sorgente, progettazione del prodotto / interfaccia utente, documentazione e materiali di formazione. Quantità moltiplicata per la qualità. Qualsiasi prodotto di lavoro prodotto qui può essere replicato a basso costo a un numero illimitato di utenti)
• servizi (competenza nel software e nel dominio e capacità di fornire miglioramenti a valore aggiunto in base al cliente)

Il KPI per lo sviluppo è semplice: puoi sviluppare la stessa cosa in modo migliore e più economico di altri. Parte di questo è un puro investimento di risorse e l'altra parte è la saggezza dell'architetto e dei designer.

Per i servizi, avere accesso al codice sorgente del prodotto è un grosso vantaggio. Una società che non ha accesso al codice sorgente spesso non può fornire lo stesso livello di servizio di un'altra società che ha accesso.

Ora torniamo alla domanda del PO: una società di origine chiusa ha una strategia di sopravvivenza?

L'articolo citato da OP sembra auto-limitante perché considera solo due estremi:

• Una società a codice chiuso sviluppa di tasca sua tutto il codice sorgente e ha zero righe di codice open source.
• Una società open source abbraccia pienamente il principio e apre ogni linea di codice mai sviluppata.

Che ne dici dei terreni di mezzo?

• Diverse aziende di software firmano accordi di licenza incrociata per condividere parte del codice sorgente e / o API? (In cui una delle parti è orientata ai servizi.)
• Le aziende che fanno buon uso dei componenti o delle librerie open source con licenza in stile BSD (e apportano contributi in natura), senza aprire il codice sorgente del prodotto principale?
• Aziende che forniscono codice sorgente di software in corso attraverso un accordo di "anteprima della comunità" limitato nel tempo?
• "Fonte disponibile": aziende che forniscono codice sorgente a clienti paganti?

Il mio punto di vista è che le aziende possono sopravvivere se adottano una strategia di codice sorgente parzialmente aperta e parzialmente chiusa, e se fanno bene su tutti e tre i fronti (marketing, sviluppo e servizi). Anche le aziende che adottano una filosofia aperta possono sopravvivere e dovranno fare altrettanto sugli stessi tre fronti.

C'è però un avvertimento: se un software è gratuito, i clienti lo sceglieranno tra alternative anche se il software ha fatto male su alcune metriche?

• vendite e marketing: puoi promuovere un prodotto quasi a costo zero, attraverso il marketing virale?
• sviluppo: un progetto open source può ottenere la maggior parte della sua progettazione / sviluppo / documentazione da volontari non retribuiti? Un'azienda può trarre vantaggio da tale progetto?
• servizi: un progetto software può rivoluzionare il suo dominio software per renderlo molto semplice, in modo che tutti possano diventare un esperto istantaneo, portando a zero la barriera d'ingresso?

Il progetto open source sta inseguendo il progetto commerciale in termini di funzionalità. Questo lascia una sorta di arbitraggio temporale per la società commerciale di competere sulle caratteristiche. Devono correre per implementare costantemente funzionalità per mantenere un vantaggio sulla società open source. È costoso, ma può funzionare.

Come altri hanno già detto, le funzionalità possono includere documentazione e facilità d'uso.

La società può provare a instillare il blocco del fornitore, ma ciò rallenta solo le perdite; non ti guadagna alcun cliente.

Questo lascia due modi principali per mantenere la quota di mercato: supporto e sfruttamento della sfiducia gestionale nei confronti del software open source. Purtroppo, quest'ultimo ti porterà abbastanza lontano. La vendita del supporto funzionerà, tuttavia, e anche quando il progetto open source si afferrerà abbastanza per ottenere una società che vende supporto per essa, la soluzione commerciale avrà un vantaggio essendo l'operatore storico e avendo più esperienza, e anche dall'impressione che lo siano più familiarità con il loro prodotto.

Nel lungo termine, è probabile che tu sia fregato, ma questo può rendere "il breve termine" nel "futuro prevedibile".

Una cosa che nessun altro ha menzionato è la documentazione. Molti programmi non hanno davvero bisogno di molto per essere utilizzabili (Firefox, Openoffice), ma se scrivi una libreria, una sorta di server, un linguaggio di programmazione o solo un programma davvero complicato, la documentazione può far risaltare il tuo.

Il miglioramento della documentazione può ridurre la frustrazione dei tuoi utenti (aumentandone la probabilità di continuare a utilizzare il tuo prodotto e suggerire di utilizzarlo in futuro) e puoi pubblicizzare che i soldi sono ben spesi perché i tuoi clienti non passeranno tanto tempo a scrivere codice (e tempo == denaro).

Questo non è necessariamente open source vs. closed source però - Praticamente tutto è scarsamente documentato. È possibile che il tuo concorrente sia in quell'1% dei progetti che documenta bene le cose, ma è improbabile;)

Molto semplicemente, il trucco è continuare a ridefinire il 100%. FOSS non ha la stessa scala e la stessa forza di un progetto commerciale e ci sono limiti alla stretta concorrenza con un prodotto esistente. Le società di origine chiusa utilizzano gli hook dell'interfaccia utente, pertanto l'utilizzo di un prodotto della concorrenza sembra impossibile a causa di diverse scorciatoie da tastiera. Inoltre, continuano ad aggiungere importanti funzionalità che un concorrente FOSS non potrebbe mai prendere in considerazione. Ad esempio, considera Visual Studio. Era solo un IDE C ++, ma poi hanno iniziato a raggruppare linguaggi e framework completamente nuovi, come .NET. O Visual Studio 2010, che include una libreria di threading di livello commerciale (come in Intel vendono un equivalente standalone) per C ++. FOSS non riesce a tenere il passo con quel tipo di sviluppo e spesso affidabilità.

Scegli come target i mercati aziendali tradizionali e diventa popolare.

Per molte grandi aziende tradizionali si riduce a tre cose:

• un fornitore con cui possono stipulare un contratto vincolante (capacità e affidabilità)
• un fornitore con il quale può far valere contrattualmente un accordo specifico sul livello di servizio (velocizzare la qualità del supporto)
• recensioni di Gartner (questo è l'equivalente moderno di "nessuno viene licenziato per aver scelto IBM)

Tutti e tre sono seguiti insensatamente, e non particolarmente validi. I problemi di capacità sono sempre ipervenduti, gli SLA hanno sempre una scusa e il gartner esamina solo il tipo di persone che ascoltano il gartner, ma quando sei un intermediario in un corp che ha un sacco di dirigenti medio-alti che si mettono nei guai con il superiore quando il senior management sente finalmente che c'è stata una decisione storta che è costata una grande quantità di denaro, hai bisogno di documentazione da una terza parte che supporti la tua posizione se vuoi salvare il tuo lavoro. Anche se sai bene che da un punto di vista tecnico stai gettando grosse pile di denaro nel gabinetto, non vale il rischio di provare a fare la cosa giusta.

Quanti cattivi usi di SAP o SharePoint hai visto tollerare nel settore? Quanti di questi sarebbero stati migliori se fossero stati fatti su qualcos'altro che si adattava meglio, ma non un grande nome industriale?

Uso un sacco di strumenti Microsoft e ho un account MSDN, ma sinceramente ricevo un aiuto migliore dalle persone MS su Twitter rispetto al centro telefonico MSDN. Non riesco a immaginare di ottenere un aiuto peggiore dalla gente dietro e dal progetto open source rispetto a quello che la gente non di supporto twitta nel loro tempo libero, ma ciò non rientra nell'equazione Responsabilità / Gartner.

Come ha detto SnOrfus vendi le funzionalità che facciamo.

Ad esempio: sviluppiamo plugin con alcune funzionalità comuni e li rendiamo gratuiti per il download sul sito di Wordpress. Allo stesso tempo abbiamo il nostro plugin per versione a pagamento che ha funzionalità pro.

Questo ti aiuta a presentare il tuo prodotto a persone di massa, ad esempio il potere dell'open source e delle persone.