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

Slide 1

Slide 1 text

L’Open Source Professionnel un business model d’éditeur open source Stefane Fermigier, Founder & CEO, Abilian 4 juillet 2013

Slide 2

Slide 2 text

Qui je suis

Slide 3

Slide 3 text

I’m an open source developer (And an entrepreneur, too...)

Slide 4

Slide 4 text

Fondateur d’Abilian

Slide 5

Slide 5 text

Panorama des acteurs (un peu caricatural)

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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”

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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)

Slide 11

Slide 11 text

Plusieurs modèles d’éditeur open source Foundationware / charityware / crowdfunding Double licence Open Core Cloud Open source professionnel

Slide 12

Slide 12 text

Plusieurs modèles d’éditeur open source Foundationware / charityware / crowdfunding Double licence Open Core Cloud Open source professionnel

Slide 13

Slide 13 text

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]

Slide 14

Slide 14 text

La partie facile Professional services Formation Consulting Customisation et développements spéciﬁques

Slide 15

Slide 15 text

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éciﬁques (et de préparation) Dev spéciﬁques: attention à ne pas sortir de la roadmap (cf. suite)

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Le reste Comment justiﬁer un effort de R&D important quand les revenus ne sont pas directement liés à cet effort ?

Slide 19

Slide 19 text

Mutualisation Façon de ﬁnancer 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 (difﬁcile) ou plusieurs clients pour des fonctionnalités similaires

Slide 20

Slide 20 text

Revenus récurrents Support Partenariats (payants) avec les intégrateurs Maintenance (corrective) Garanties Services complémentaires (en SaaS, notamment)

Slide 21

Slide 21 text

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...

Slide 22

Slide 22 text

Maintenance Correction et mise à disposition de patches bien déﬁnis, notamment par rapport à des releases ofﬁcielles Pendant des durées qui peuvent être très longues, sans commune mesure avec la dynamique du développement open source

Slide 23

Slide 23 text

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)

Slide 24

Slide 24 text

Services complémentaire Assistance aux montées de version Marketplace d’extensions Conﬁguration / management dans le cloud

Slide 25

Slide 25 text

Compétences clefs d’un éditeur open source

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

La qualité Tests, intégration continue Traçabilité Dette technique, refactoring Documentation Perception de la qualité

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Avantages et inconvénients

Slide 35

Slide 35 text

Principaux avantages Développement plus efﬁcace Evangélisation plus simple Cycles de ventes plus courts Constitution d’un écosystème

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Principaux inconvénients / risques Barrière à l’entrée (pour les concurrents) plus basse Et à la sortie (pour les utilisateurs) => Financement plus difﬁcile (par les VC)

Slide 38

Slide 38 text

Modélisation du récurrent

Slide 39

Slide 39 text

Entonnoir des ventes (récurrent) Source: The Open Source Business Model: Key Metrics and Levers, David Skok.

Slide 40

Slide 40 text

Les variables clefs Coût d’acquisition d’un client (CAC) Revenu mensuel recurrent (MRR) Taux d’attrition mensuel (MCR) Lifetime customer value (LTV)

Slide 41

Slide 41 text

Exemple CAC = 5000 EUR MRR = 500 EUR MCR = 2.5% => LTV = MRR / MCR = 20000 EUR  (en faisant abstraction des coûts)

Slide 42

Slide 42 text

Source: The Open Source Business Model: Key Metrics and Levers, David Skok.

Slide 43

Slide 43 text

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 ﬁnancer d’une façon ou d’une autre Solution: faire payer d’avance (avec un discount)

Slide 44

Slide 44 text

Autres variables importantes Temps de ramp-up des commerciaux Taux d’upsell (<=> churn négatif) Délais de paiement

Slide 45

Slide 45 text

Autres points d’attention

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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 justiﬁer 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