Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

E91a97baa90dd7f5a267c79a2cbb04b2?s=128

Stefane Fermigier

July 04, 2013
Tweet

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)

  6. None
  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”
  8. None
  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é
  32. None
  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