I siti di supporto come Stack Overflow sconvolgono il modello open source con supporto a pagamento?

Al fine di rimanere rilevante sul mercato, sto cercando nuovi modelli di business per la mia società di software. Il modello open source con supporto a pagamento sembra adatto per il nostro prodotto, ma ho dubbi sul fatto che un modello di supporto a pagamento sia praticabile in un'era in cui un aiuto di prim'ordine è prontamente disponibile gratuitamente su siti come quelli nello Stack Rete di scambio.

Caso in questione: lo scorso anno ho trasferito i miei dipendenti su Ubuntu perché non volevo pagare per le licenze Win 7 e il nuovo hardware (inoltre, la piattaforma mono era molto interessante). Il mio staff non aveva esperienza Linux, ma è stato in grado di raggiungere 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 ciò abbiamo speso $ 0,00 per qualsiasi tipo di esperienza retribuita.

Per quanto riguarda la mia due diligence, ho eseguito un beta di 3 mesi del modello di supporto pagato freemium con uno dei nostri clienti più piccoli e ho ottenuto risultati mediocri. Mi piacerebbe pensarlo perché il nostro software è così stabile e facile da usare che il cliente non aveva bisogno di molto supporto pagato, ma sospetto che abbiano aggirato i termini del nostro SLA nello stesso modo in cui abbiamo fatto con il passaggio a Ubuntu.

Qualcuno là fuori ha qualche pensiero, consiglio o esperienza rilevante per la mossa che sto prendendo in considerazione? Cosa ha funzionato, cosa no, ecc.?

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 alto livello per i tuoi utenti.

Nessuno vuole pagare buoni soldi per il servizio clienti "run-of-the-mill" o per cose che definirei "conoscenza comune" (almeno all'interno della comunità degli sviluppatori), né voi come azienda vorreste supportare tali 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 dell'interfaccia utente personalizzati e di alta qualità per le 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 che inizino a fornire valore nella propria applicazione software. Poiché molte aziende possono fornire questo prodotto, Telerik si distingue offrendo un migliore supporto ai clienti.

Telerik è più che felice di fornire supporto specifico del dominio per il proprio prodotto. Ma non ti insegneranno Model-View-Controller o come scrivere un'istruzione SQL (anche se il loro servizio clienti deve conoscere queste cose). Per questo, ci sono una serie di altre (e probabilmente migliori) risorse. Né desidero necessariamente chiamare Telerik per il supporto MVC o SQL. In realtà, non voglio chiamare Telerik, se non è necessario. È molto costoso per me e per Telerik sederci al telefono cercando di risolvere un problema.

Quindi vedo un contratto di supporto come "assicurazione". Lo compro, sperando di non aver mai bisogno di usarlo, ma mi sento più sicuro sapendo che ho un team di supporto esperto disponibile per supportarmi in caso di problemi.

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

Credo che la chiave sia, se vuoi offrire supporto come servizio, deve essere il tipo e la qualità del supporto che la gente dirà: "Non userò il prodotto di nessun altro, perché so che posso contare sul tuo l'esperienza del personale nel tuo prodotto per aiutarmi a superare le patch difficili ".

Non esiste un "modello open source di supporto a pagamento". Almeno, non ce n'è molto. Un numero molto limitato di persone singole è stato in grado di far funzionare il modello e un numero ancora più piccolo di aziende. Funziona quando il software ha un alto valore o profili di rischio rispetto al prezzo di acquisto dei suoi concorrenti. Funziona anche quando l'azienda coinvolta si impegna a fondo per convincere gli utenti commerciali a pagare ( ad esempio , MySQL e Red Hat Enterprise Linux).

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

Cosa succederebbe se il 20% degli utenti fosse 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 in più di quante persone utilizzano il sistema dato, altrimenti sarebbe il caso?

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

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

Il profitto e il godimento a casa per i fondatori di un'azienda non sempre si adattano al fatturato dell'azienda, quindi avere altrove un punto in cui i clienti di basso valore può essere vantaggioso per tutti.