Le document traite du modèle économique des éditeurs open source, soulignant l'importance d'un équilibre entre services professionnels et revenus récurrents, ainsi que la gestion des relations avec les intégrateurs. Il aborde également les défis liés à la maintenance, à l'innovation, et aux attentes de la communauté open source. L'importance de la qualité, de la roadmap produit, et des stratégies de financement est également mise en avant.

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. ProjectsR&D / Distribution
Open SourceVendor
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 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

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 lesVC)

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