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