I siti di supporto come Stack Overflow hanno sconvolto il modello open source del supporto a pagamento?

12

Per rimanere rilevante sul mercato, sto cercando nuovi modelli di business per la mia azienda di software. Il modello open source con supporto a pagamento sembra una buona soluzione per il nostro prodotto, ma ho dubbi sul fatto che un modello di supporto a pagamento sia praticabile in un'epoca in cui l'aiuto di alto livello è facilmente disponibile gratuitamente su siti come quelli dello Stack Rete di scambio.

Esempio: ho spostato i miei dipendenti a Ubuntu l'anno scorso perché non volevo pagare le licenze Win 7 e il nuovo hardware (inoltre, la piattaforma mono era molto interessante). Il mio staff non aveva esperienza di Linux, ma è stato in grado di ottenere la relativa competenza in circa 120 giorni con l'aiuto di AskUbuntu, Stack Overflow e alcuni libri "For Dummies". Abbiamo impiegato un consulente Ubuntu per 7 giorni per fornire formazione e supporto, ma oltre a quello abbiamo speso $ 0,00 per qualsiasi tipo di esperienza retribuita.

Riguardo alla mia due diligence, ho eseguito una beta di 3 mesi del modello di supporto a pagamento freemium con uno dei nostri clienti più piccoli, ottenendo risultati mediocri. Mi piacerebbe pensarlo perché il nostro software è così stabile e facile da usare che il cliente non ha bisogno di molto supporto pagato, ma sospetto che abbia aggirato i termini del nostro SLA nello stesso modo in cui lo abbiamo fatto con il passaggio a Ubuntu.

Qualcuno là fuori ha pensieri, consigli o esperienze rilevanti per la mossa che sto considerando? Cosa ha funzionato, cosa no, ecc?

    
posta Mr. JavaScript 01.11.2012 - 03:54
fonte

3 risposte

18

Il supporto a pagamento funziona davvero meglio per le cose specifiche del tuo prodotto che trarranno vantaggio dalla tua esperienza. Se sei un esperto di dominio nel tuo prodotto, sei il più qualificato per essere un consulente di prim'ordine per i tuoi utenti.

Nessuno vuole pagare soldi per il servizio clienti run-of-the-mill o per cose che chiamerei "conoscenza comune" (almeno all'interno della comunità degli sviluppatori), né vorresti come azienda sostenere queste cose .

Esempio: Telerik ha la reputazione di avere un ottimo supporto tecnico. Ci sono un certo numero di aziende che fanno ciò che fa Telerik (forniscono controlli di interfaccia utente personalizzati e di alta qualità per applicazioni aziendali), e sono tutti molto bravi a farlo. Esiste un mercato per questi prodotti perché nessuno vuole passare anni uomo a scrivere una suite di controllo prima di iniziare a fornire valore nella propria applicazione software. Poiché molte aziende sono in grado di fornire questo prodotto, Telerik si distingue offrendo un supporto clienti migliore.

Telerik è più che felice di fornire supporto specifico per il dominio per il proprio prodotto. Ma non ti insegneranno Model-View-Controller o come scrivere una dichiarazione SQL (anche se il loro servizio clienti deve sapere queste cose). Per questo, ci sono una serie di altre (e probabilmente meglio) risorse. Né voglio necessariamente chiamare Telerik per il supporto MVC o SQL. In effetti, non voglio assolutamente chiamare Telerik, se non dovessi. È molto costoso sia per me che per Telerik sedersi al telefono cercando di risolvere un problema.

Quindi vedo un contratto di assistenza come "assicurazione". Lo compro, sperando di non aver mai bisogno di usarlo, ma mi sento più sicuro sapendo di avere un team di supporto esperto che è disponibile a sostenermi se ho un problema.

Questa filosofia si estende a Stack Overflow, in misura sostanziale. Stack Overflow (e siti simili) non si vuole sostituire con il supporto pagato di altre aziende. Quando la gente fa domande laggiù che sono molto specifiche per i controlli di Telerik, chiedo sempre loro: "Che cosa ha fatto Telerik? dire?" "Beh, non li ho mai chiamati." Le persone chiedono prima a SO, perché la maggior parte delle aziende ha un pessimo servizio clienti, e immagino sperino che un dipendente a caso di Telerik si aggiri e risponda alla loro domanda.

Credo che la chiave sia, se hai intenzione di offrire un supporto come servizio, deve essere il tipo e la qualità del supporto che le persone diranno: "Non userò il prodotto di nessun altro, perché so che posso contare sulla competenza del vostro personale nel vostro prodotto per aiutarmi a superare le zone difficili. "

    
risposta data 01.11.2012 - 04:11
fonte
1

Non esiste un "modello open source di supporto a pagamento". Almeno, non c'è molto di uno. Un numero molto esiguo di persone singole è stato in grado di far funzionare il modello e un numero ancora minore di aziende. Funziona quando il software ha un valore elevato o profili di rischio rispetto al prezzo di acquisto dei suoi concorrenti. Funziona anche quando la società coinvolta preme strong per far pagare gli utenti commerciali ( ad es. , MySQL e Red Hat Enterprise Linux).

Come hai dimostrato tu stesso, la maggior parte degli utenti di software open source non spenderà soldi per questo.

    
risposta data 16.11.2013 - 00:12
fonte
0

Che cosa succede se il 20% degli utenti era disposto a pagare per il supporto prima di StackOverflow, ma solo il 10% dopo StackOverflow, ma a causa del supporto gratuito su StackOverflow 5 volte quante persone utilizzano il sistema specificato, altrimenti sarebbe il caso?

Poiché non vi è alcun costo per gli utenti che non pagano il supporto, un "modello open source a pagamento" tende a guadagnare di più, più utenti ci sono.

Un altro modo di pensarci è che un gruppo di programmatori crea un kit di strumenti, che potrebbe richiedere un supporto a $ 300 al giorno e impiegare molte persone di supporto, oppure potrebbe fare molto meno giorni di supporto a $ 2000 un giorno e divertiti di più mentre StackOverflow prende il supporto di base.

Portare profitto e godimento a casa per i fondatori di un'azienda non è sempre in linea con il fatturato dell'azienda - quindi avere da qualche altra parte dei clienti a basso valore può essere di beneficio per tutti.

    
risposta data 16.11.2013 - 01:05
fonte

Leggi altre domande sui tag