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.

Stefane Fermigier

July 04, 2013
Tweet

More Decks by Stefane Fermigier

Other Decks in Business

Transcript

  1. 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”
  2. 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
  3. 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)
  4. Plusieurs modèles d’éditeur open source Foundationware / charityware / crowdfunding

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

    Double licence Open Core Cloud Open source professionnel
  6. 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]
  7. 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)
  8. 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
  9. 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
  10. Le reste Comment justifier un effort de R&D important quand

    les revenus ne sont pas directement liés à cet effort ?
  11. 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
  12. 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...
  13. 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
  14. 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)
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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)
  23. Les variables clefs Coût d’acquisition d’un client (CAC) Revenu mensuel

    recurrent (MRR) Taux d’attrition mensuel (MCR) Lifetime customer value (LTV)
  24. Exemple CAC = 5000 EUR MRR = 500 EUR MCR

    = 2.5% => LTV = MRR / MCR = 20000 EUR
 (en faisant abstraction des coûts)
  25. 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)
  26. 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
  27. 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