open source-professionnel

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: sf@fermigier.com

Web: www.fermigier.comwww.abilian.com