Upload
stefane-fermigier
View
1.274
Download
5
Embed Size (px)
DESCRIPTION
Citation preview
L’Open Source Professionnelun business model d’éditeur open source
Stefane Fermigier, Founder & CEO, Abilian4 juillet 2013
Qui je suis
I’m an open source developer
(And an entrepreneur, too...)
Fondateur d’Abilian
Panorama des acteurs(un peu caricatural)
Les intégrateurs (SSII)
Motivation première: vendre du “jour homme” (forfait / régie)
Maîtrisent souvent plusieurs technologies, mais investissent sur la connaissance de manière “opportuniste”
Démarche qualité “focalisée sur le court terme”
Les éditeursRecherchent avant tout un revenu passif et récurrent
Doivent travailler avec plusieurs intégrateurs, et les convaincre d’utiliser leur techno
Proposent également des “services professionnels à valeur ajoutée” qui n’entrent pas en concurrence avec l’offre des intégrateurs
Démarche qualité qui tient compte du court et du moyen terme
Attention !Cette opposition n’est pas à prendre au pied de la lettre
2 facteurs à prendre en compte:
Focus produit / propriété associée
Revenue mix
Une société peut évoluer au cours de son existence (ex: Nuxeo)
Plusieurs modèles d’éditeur open source
Foundationware / charityware / crowdfunding
Double licence
Open Core
Cloud
Open source professionnel
Plusieurs modèles d’éditeur open source
Foundationware / charityware / crowdfunding
Double licence
Open Core
Cloud
Open source professionnel
Open Source Professionnel
“Business model open source dans lequel l'éditeur tire ses revenus de services professionnels, de la maintenance et du support associés au logiciel qu'il édite." [Source: Wikipedia]
La partie facile
Professional services
Formation
Consulting
Customisation et développements spécifiques
Points d’attention
Formation
Facile à vendre (pour peu qu’on ait l’agréement FAFIEC) et sert souvent d’avant-vente payée
Mais besoin de compétences spécifiques (et de préparation)
Dev spécifiques: attention à ne pas sortir de la roadmap (cf. suite)
Points d’attentionComment équilibrer la demande avec les resources disponibles ?
Equipe professional services séparée de l’équipe de dev, ou non ?
Si oui: comment assurer une bonne circulation des compétences ?
Si non: attention aux contraintes que cela rajoute sur l’équipe de dev
Relation avec les intégrateurs
Comment ne pas être perçu comme concurrents ?
Comment s’assurer un partage équitable des budgets des clients (70/30) ?
Dynamique de la relation commerciale
... et de la relation technique
Le reste
Comment justifier un effort de R&D important quand les revenus ne sont pas directement liés à cet effort ?
Mutualisation
Façon de financer un développement générique en mutualisant plusieurs demandes
Attention: coût plus élevé par rapport à une prestation de pur service
Solution: avoir un client compréhensif (difficile) ou plusieurs clients pour des fonctionnalités similaires
Revenus récurrents
Support
Partenariats (payants) avec les intégrateurs
Maintenance (corrective)
Garanties
Services complémentaires (en SaaS, notamment)
Support
2 phases:
Pendant la réal
Pendant la prod
Attention à l’organisation à mettre en place
En particulier en fonction du SLA
Et au coût...
Maintenance
Correction et mise à disposition de patches bien définis, notamment par rapport à des releases officielles
Pendant des durées qui peuvent être très longues, sans commune mesure avec la dynamique du développement open source
GarantieLa maintenance (et même le support) sont une forme de garantie
Plus généralement, donner au client quelqu’un sur qui tapper en cas de problème
Notamment en cas de besoin de se rassurer sur le plan juridique
Mais attention à l’engagement que cela implique (ex: brevets logiciels)
Services complémentaire
Assistance aux montées de version
Marketplace d’extensions
Configuration / management dans le cloud
Compétences clefsd’un éditeur open source
Raison d’êtreLien entre business et communauté
Two-sided business model
Attentes différentes
Rythme de releases
Accompagnement, outillage
Garanties (SLA)
Technique vs. métier
ProjectsR&D / Distribution
Open Source Vendor Innovation & Distribution
Partners Consulting & Integration
Users / CustomersUsage & contribution
Customers
Integrators
ISV
EcosystemOpen Source
Consulting
Open sourcevendor
Les rôles de l’éditeur
Produit et partage la vision
Gardien du temps
Garant de la qualité
Est au centre d’un écosystème d’innovation ouverte
La vision
La vision d’un produit ou d’une architecture innovants est rarement produite par un comité
Dans tous les cas, importance du leadership
L’éditeur commegardien du temps
Garantie de temps de réponse (SLA)
Roadmap fonctionnelle et technique
Rythme des releases
Timing de la publication de certaines fonctionnalités
Gestion de la dette technique
Maintenance des anciennes versions
La qualité
Tests, intégration continue
Traçabilité
Dette technique, refactoring
Documentation
Perception de la qualité
Ecosystème
Animation d’une communauté d’utilisateurs, de contributeur, de prestataires
Services et produits (ex: plugins) complémentaires de l’offre de l’éditeur
Avantages et inconvénients
Principaux avantages
Développement plus efficace
Evangélisation plus simple
Cycles de ventes plus courts
Constitution d’un écosystème
Cycle de vente
Assistance ProcurementProduct discovery and evaluation Order
Proprietary vendors enter sales cycle at this point in order to demo the product and
supply evaluation copies, give outline costs
6-18 months 1-6 months 1-3 months 1-4 weeks
From this point on, open source vendor enters sales
cycle, behaves as software & services vendor
Principaux inconvénients / risques
Barrière à l’entrée (pour les concurrents) plus basse
Et à la sortie (pour les utilisateurs)
=> Financement plus difficile (par les VC)
Modélisation du récurrent
Entonnoir des ventes (récurrent)
Source: The Open Source Business Model: Key Metrics and Levers, David Skok.
Les variables clefs
Coût d’acquisition d’un client (CAC)
Revenu mensuel recurrent (MRR)
Taux d’attrition mensuel (MCR)
Lifetime customer value (LTV)
Exemple
CAC = 5000 EUR
MRR = 500 EUR
MCR = 2.5%
=> LTV = MRR / MCR = 20000 EUR(en faisant abstraction des coûts)
Source: The Open Source Business Model: Key Metrics and Levers, David Skok.
Observations
Le CAC est lui-même fonction de plusieurs facteurs que l’on peut modéliser
Le ramp-up des commerciaux peut aussi être modélisé
Chaque nouveau client génère un BFR qu’il faut financer d’une façon ou d’une autre
Solution: faire payer d’avance (avec un discount)
Autres variables importantes
Temps de ramp-up des commerciaux
Taux d’upsell (<=> churn négatif)
Délais de paiement
Autres points d’attention
Tensions et complémentarités
Professional services vs. récurrent
Mal nécessaire ou complémentarité ?
Contrôle vs. communauté
Le client n’a pas toujours raison !
Core vs. écosystème
80/20 vs. 20/80
Dérives possiblesDe l’open source professionnel à l’open core
Négliger certains aspects communautaire pour privilégier les revenus à court terme
Ne pas s’investir à 100% sur la qualité pour justifier la maintenance
Ne pas jouer le jeu de la transparence totale
Plus généralement : défauts d’alignements entre les services de l’entreprise
Contact: [email protected]
Web: www.fermigier.comwww.abilian.com
Credits
Icons:
Scale, designed by Stephanie Wauters from The Noun Project