L’Open Source Professionnel - un business model d’éditeur open source

Présentation du business model d'éditeur open source.

Transcript

1. L’Open Source Professionnel un business model d’éditeur open source Stefane Fermigier, Founder & CEO, Abilian 4 juillet 2013
2. Qui je suis
3. I’m an open source developer (And an entrepreneur, too...)
4. Fondateur d’Abilian
5. Panorama des acteurs (un peu caricatural)
7. 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”
9. Les éditeurs Recherchent 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
10. 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)
11. Plusieurs modèles d’éditeur open source Foundationware / charityware / crowdfunding Double licence Open Core Cloud Open source professionnel
12. Plusieurs modèles d’éditeur open source Foundationware / charityware / crowdfunding Double licence Open Core Cloud Open source professionnel
13. 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]
14. La partie facile Professional services Formation Consulting Customisation et développements spécifiques
15. 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)
16. Points d’attention Comment é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
17. 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
18. Le reste Comment justifier un effort de R&D important quand les revenus ne sont pas directement liés à cet effort ?
19. 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
20. Revenus récurrents Support Partenariats (payants) avec les intégrateurs Maintenance (corrective) Garanties Services complémentaires (en SaaS, notamment)
21. 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...
22. 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
23. Garantie La 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)
24. Services complémentaire Assistance aux montées de version Marketplace d’extensions Configuration / management dans le cloud
25. Compétences clefs d’un éditeur open source
26. Raison d’être Lien entre business et communauté Two-sided business model Attentes différentes Rythme de releases Accompagnement, outillage Garanties (SLA) Technique vs. métier
27. Projects R&D / Distribution Open Source Vendor Innovation & Distribution Partners Consulting & Integration Users / Customers Usage & contribution Customers Integrators ISV Ecosystem Open Source Consulting Open source vendor
28. 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
29. 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
30. L’éditeur comme gardien 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
31. La qualité Tests, intégration continue Traçabilité Dette technique, refactoring Documentation Perception de la qualité
33. 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
34. Avantages et inconvénients
35. Principaux avantages Développement plus efficace Evangélisation plus simple Cycles de ventes plus courts Constitution d’un écosystème
36. Cycle de vente Assistance Procurement Product 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
37. 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)
38. Modélisation du récurrent
39. Entonnoir des ventes (récurrent) Source: The Open Source Business Model: Key Metrics and Levers, David Skok.
40. Les variables clefs Coût d’acquisition d’un client (CAC) Revenu mensuel recurrent (MRR) Taux d’attrition mensuel (MCR) Lifetime customer value (LTV)
41. Exemple CAC = 5000 EUR MRR = 500 EUR MCR = 2.5% => LTV = MRR / MCR = 20000 EUR
 (en faisant abstraction des coûts)
42. Source: The Open Source Business Model: Key Metrics and Levers, David Skok.
43. 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)
44. Autres variables importantes Temps de ramp-up des commerciaux Taux d’upsell (<=> churn négatif) Délais de paiement
45. Autres points d’attention
46. 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
47. Dérives possibles De 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
48. Contact: sf@fermigier.com Web: www.fermigier.com www.abilian.com
49. Credits Icons: Scale, designed by Stephanie Wauters from The Noun Project