18 façons de différencier les produits open source des fournisseurs en amont
Les produits open source doivent créer une valeur suffisamment différenciée pour que les clients les paient volontairement par rapport à un autre produit (ou gratuit).
Dans les trois premières parties de cette série, j'ai exploré l'open source en tant que chaîne d'approvisionnement, ce qu'est un produit et ce que font les chefs de produit. Dans ce quatrième article, j'examinerai une multitude de méthodes permettant de différencier les produits logiciels open source de leurs projets open source en amont.
Étant donné que les projets open source sont essentiellement des produits d'information, ces méthodes sont susceptibles de s'appliquer à de nombreux produits liés à l'information (pensez aux créateurs YouTube) dont une composante de valeur est distribuée gratuitement. Les chefs de produit doivent faire preuve de créativité lorsque les informations et le matériel nécessaires à la création de votre produit sont librement accessibles aux utilisateurs.
Créer et capter de la valeur
Les chefs de produit sont chargés de créer des solutions qui attirent et fidélisent les clients. Pour créer un client, ils doivent apporter de la valeur en échange d’argent. Tout comme un bon vendeur, un chef de produit ne devrait jamais se sentir coupable de facturer son produit (voir Comment vendre un produit open source par John Mark Walker).
Les produits basés sur l'open source ne sont fondamentalement pas différents des autres produits ou services. Ils doivent créer de la valeur pour les clients. En fait, ils doivent créer suffisamment de valeur pour que les clients paient volontairement un prix suffisant pour payer les coûts de développement et générer un profit. Ces produits doivent également se différencier des produits et services concurrents, ainsi que des projets en amont.
(Scott McCarty, CC BY-SA 4.0)
Bien que les produits basés sur des logiciels open source ne soient pas fondamentalement différents des autres produits et services, il existe certaines différences. Premièrement, une partie des coûts de développement est prise en charge par tous les contributeurs open source. Ces coûts peuvent inclure le code, les tests, la documentation, le matériel, les coûts d'hébergement du projet, etc. Mais même lorsque les coûts de développement sont pris en charge en open source, les coûts sont supportés par le fournisseur qui produit le code. Ceux-ci peuvent inclure les coûts de personnel pour la recherche, l'analyse, la sécurité, les tests de performances, les processus de certification (par exemple, collaboration avec des fournisseurs de matériel, des fournisseurs de cloud, etc.) et bien sûr, les ventes et le marketing.
(Scott McCarty, CC BY-SA 4.0)
Les produits open source performants doivent être en mesure de facturer un coût suffisant pour payer les contributions open source en amont (coûts de développement) et les coûts de production en aval (coûts des fournisseurs). En d’autres termes, les produits ne peuvent facturer un prix suffisant que s’ils créent de la valeur qui ne peut être captée que par les clients qui les paient. Cela peut paraître dur, mais c'est une réalité pour tous les produits. Il y a un dicton en gestion de produits : prier pour payer ne fonctionne pas. Cela dit, ne vous inquiétez pas trop. Il existe des moyens éthiques de capter de la valeur.
Types de valeur
Fondamentalement, il existe deux types de valeur : exclusive et non exclusive. Propriétaire est un gros mot dans le domaine des logiciels open source, mais un mot attrayant dans les secteurs de l'industrie manufacturière, de la finance et d'autres secteurs. De nombreuses sociétés financières mettront en avant leurs algorithmes propriétaires, tout comme les sociétés pharmaceutiques et leurs processus de fabrication. Dans le domaine des logiciels, la valeur propriétaire est souvent considérée comme totalement incongrue avec les logiciels libres et open source. Les gens supposent souvent que la valeur exclusive est une décision binaire. Il est difficile pour les gens d’imaginer la valeur propriétaire dans le contexte des logiciels open source sans être artificiellement contraints par une licence. Cependant, comme nous allons tenter de le démontrer, ce n’est pas si clair.
Du point de vue de la gestion de produits open source, vous pouvez définir la valeur propriétaire comme tout ce qu'il serait très difficile, voire impossible pour le client de recréer lui-même, ou quelque chose que le client potentiel ne croit pas pouvoir recréer. La valeur marchande est à l’opposé de la valeur exclusive. La valeur marchande est la valeur que le client pense pouvoir construire (ou reconstruire) avec suffisamment de temps et d’argent.
Reconstruire la valeur d'une marchandise au lieu de l'acheter n'a de sens que si cela est moins cher ou plus facile que d'acheter un produit. En d’autres termes, un bon produit devrait permettre au client d’économiser de l’argent par rapport à la création de la solution lui-même. C'est dans cet écart de coûts que les produits open source existent et prospèrent.
Avec des produits construits, ou principalement construits, sur une chaîne d'approvisionnement open source, les clients conservent la décision « construire ou acheter » et peuvent cesser de payer à tout moment. Cela est également souvent vrai pour les produits à noyau ouvert. Tant que la majorité de la chaîne d’approvisionnement est open source, le client pourrait probablement reconstruire quelques composants pour obtenir ce dont il a besoin. Le travail du chef de produit open source est le même que pour tout autre produit ou service : créer et fidéliser des clients en leur offrant une valeur qui vaut la peine d'être payée.
Différenciateurs pour les chefs de produits open source
Comme tout artiste, un chef de produit traite la valeur comme support. Ils doivent fixer le prix et emballer leur produit. Ils doivent constamment s'efforcer de différencier leur produit de celui de leurs concurrents sur le marché et des projets en amont qui sont fournisseurs de ce produit. Cependant, la chaîne d'approvisionnement n'est qu'un outil qu'un chef de produit peut utiliser pour se différencier et créer un client.
Il s'agit d'une liste non exhaustive qui devrait vous donner quelques idées sur la manière dont les chefs de produit peuvent différencier leurs produits et créer de la valeur. En lisant la liste, réfléchissez profondément à la question de savoir si un client pourrait recréer la valeur de chaque produit avec suffisamment de temps, d'argent et de volonté.
Chaîne d'approvisionnement : la sélection des fournisseurs en amont est importante. La santé de la communauté en amont est un argument de vente par rapport aux produits basés sur des projets concurrents en amont. Un exemple parfait de ce type de différenciation est celui des produits tels qu'OpenShift, Docker EE et Mesosphere, qui s'appuient respectivement sur Kubernetes, Swarm et Apache Mesos comme fournisseurs en amont. De la même manière que les voitures électriques remplacent les moteurs à essence, le choix de la technologie et de son fournisseur permet une différenciation.
-
Ingénierie qualité : l'intégration continue et la livraison continue (CI/CD) en amont ainsi que les tests utilisateur sont de merveilleuses bases pour créer un produit. Cependant, il est essentiel de s'assurer que le produit en aval, souvent composé de plusieurs projets en amont, fonctionne bien avec les versions spécifiques de tous les composants. Tester ensemble l’ensemble de la solution permet autant de se différencier des fournisseurs en amont que des produits concurrents. Les clients veulent des produits qui fonctionnent.
Certifications sectorielles : des catégories spécifiques de clients, telles que les gouvernements, les services financiers, les transports, l'industrie manufacturière et les télécommunications, ont souvent des exigences de certification. Généralement, ceux-ci sont liés à la sécurité ou à l’audit et sont souvent assez coûteux. Les certifications sont formidables car elles différencient le produit des concurrents et en amont.
Certifications du matériel ou du fournisseur de cloud : le sale secret du matériel bon marché est qu'il change constamment. Ce matériel dispose souvent de nouvelles fonctionnalités avec différents niveaux de maturité. Les certifications matérielles fournissent un niveau de confiance quant au bon fonctionnement du logiciel sur un élément matériel spécifique ou une machine virtuelle cloud. Ils fournissent également un niveau d'assurance que l'entreprise du produit et la plate-forme sur laquelle il est certifié s'engagent à le faire fonctionner ensemble. Un client potentiel peut toujours vérifier lui-même le matériel, mais il n'entretient souvent pas de relations approfondies avec les fournisseurs de matériel et les fournisseurs de cloud, ce qui rend difficile l'exigence de correctifs et de correctifs.
Écosystème : cela représente l'accès à une multitude de solutions complémentaires proposées par des fournisseurs tiers. Encore une fois, l’écosystème offre une certaine assurance que toutes les entités travaillent ensemble pour que les choses fonctionnent bien. Les petites entreprises auraient probablement du mal, voire de l'impossibilité, à exiger que les éditeurs de logiciels individuels certifient leurs plates-formes construites en privé. De telles intégrations sont généralement assez coûteuses pour un utilisateur individuel et sont mieux supportées par les clients d'un produit.
Cycle de vie : les projets en amont sont formidables car ils évoluent rapidement et innovent. Mais de nombreuses versions différentes de nombreux projets en amont peuvent entrer dans la chaîne d'approvisionnement d'un seul produit. S'assurer que toutes les versions des différents projets en amont fonctionnent ensemble sur un cycle de vie donné représente beaucoup de travail. Un cycle de vie plus long donne aux clients le temps d’obtenir un retour sur investissement. En d’autres termes, les utilisateurs consacrent beaucoup de temps et d’argent à la planification et au déploiement de logiciels. L'engagement sur le cycle de vie d'un produit garantit que les clients peuvent utiliser le logiciel et tirer de la valeur de leur investissement pendant une durée raisonnable.
Emballage et distribution : une fois qu'un fournisseur s'engage à prendre en charge un produit pendant un cycle de vie donné (par exemple, cinq ans), il doit également s'engager à assurer l'emballage et la distribution pendant cette période. Les produits et les services cloud doivent offrir aux clients la possibilité de planifier une feuille de route, d'exécuter un déploiement et de s'étendre tout au long du cycle de vie souhaité. Les packages ou services doivent donc rester disponibles pour l'utilisation des clients.
Documentation : ceci est souvent négligé par les projets open source et les fournisseurs. Il est extrêmement important d’aligner la documentation produit sur le cycle de vie du produit, par rapport à la documentation du fournisseur en amont. Il est également important de documenter l'ensemble de la solution fonctionnant ensemble, qu'il s'agisse de l'installation ou des cas d'utilisation pour les utilisateurs finaux. Il est avantageux pour les clients de disposer d'une documentation s'appliquant à la combinaison spécifique de composants qu'ils utilisent.
Sécurité : étroitement liée au cycle de vie du produit, les fournisseurs doivent s'engager à assurer la sécurité pendant la durée de prise en charge du produit. Cela inclut l'analyse du code, l'évaluation des vulnérabilités, la correction de ces vulnérabilités et la vérification qu'elles sont corrigées. Il s’agit d’un domaine particulièrement opportun pour que les produits se différencient des fournisseurs en amont. Il s’agit véritablement d’une création de valeur grâce aux données.
Performances : également étroitement liées au cycle de vie du produit, les fournisseurs doivent s'engager à fournir des tests de performances, des recommandations de réglage et parfois même à rétroporter les améliorations de performances pendant le cycle de vie du produit. C'est un autre domaine opportun pour les produits.
Indemnisation : Il s'agit essentiellement d'une assurance au cas où l'entreprise utilisant le logiciel serait poursuivie en justice par un chasseur de brevets. Souvent, l’équipe juridique de l’entreprise ne dispose tout simplement pas des compétences nécessaires pour se défendre. Même si les clients potentiels pourraient payer un tiers pour des services juridiques, connaîtraient-ils également le logiciel ?
-
Ressources de calcul : vous ne pouvez tout simplement pas accéder aux ressources de calcul sans les payer. Il existe des essais gratuits, mais une utilisation soutenue nécessite toujours de payer, soit via un fournisseur de cloud, soit en achetant du matériel. En fait, il s’agit de l’une des principales valeurs différenciées fournies par les fournisseurs de cloud d’infrastructure en tant que service (IaaS) et de logiciel en tant que service (SaaS). Ceci est assez différent des fournisseurs en amont car ils n’auront jamais le budget nécessaire pour fournir gratuitement le calcul, le stockage et le réseau.
Consulting : L'accès aux connaissances opérationnelles pour configurer et utiliser le logiciel peut être un différenciateur. De toute évidence, une entreprise peut embaucher les talents, avec suffisamment de budget et de volonté, mais les talents peuvent être difficiles à trouver. En fait, on pourrait affirmer que les éditeurs de logiciels ont de bien meilleures chances d’attirer les meilleurs talents, créant ainsi un vide de talents pour les utilisateurs qui tentent de reconstruire eux-mêmes la valeur.
Formation : à l'instar du conseil, l'entreprise qui a écrit, configuré, publié et exploité le logiciel à grande échelle sait souvent comment l'utiliser au mieux. Encore une fois, un client pourrait embaucher le talent avec suffisamment de budget et de volonté.
Connaissances opérationnelles : les solutions IaaS et SaaS offrent souvent ce type de valeur. De même, les bases de connaissances et les expériences connectées qui analysent la configuration d'un environnement installé pour fournir des informations à l'utilisateur (par exemple, OpenShift, Red Hat Insights) peuvent fournir cette valeur. Les connaissances opérationnelles sont similaires à la formation et au conseil.
Assistance : cela inclut la possibilité d'appeler de l'aide ou de déposer des tickets d'assistance et est similaire à la formation, au conseil et aux connaissances opérationnelles. Le support est souvent une béquille pour les chefs de produits open source ; là encore, les clients peuvent souvent recréer leurs propres organisations de support, en fonction de l'endroit où ils souhaitent investir stratégiquement leur budget et leurs ressources humaines, en particulier pour le support de niveau un et de niveau deux. Le support de niveau trois (par exemple, les programmeurs du noyau) peut être plus difficile à embaucher.
Code propriétaire : il s'agit d'un code qui n'est pas publié sous licence open source. Un client peut toujours constituer une équipe de développement logiciel et augmenter le code open core avec les fonctionnalités manquantes dont il a besoin. Pour l'éditeur, le code propriétaire présente l'inconvénient de créer une concurrence contre nature entre le fournisseur open source en amont et le produit en aval. De plus, cette séparation contre nature entre code open source et code propriétaire n’apporte pas plus de valeur au client. On a toujours l’impression que la valeur est anormalement retenue. Je dirais qu’il s’agit d’une forme très sous-optimale de capture de valeur.
Marque : le capital de marque n'est pas facilement mesurable. Cela se résume vraiment à un niveau général de confiance. Le client doit croire que le fournisseur de solutions peut l’aider et le fera lorsqu’il en aura besoin. Il est lent de construire une marque et facile de la perdre. Une réflexion approfondie pourrait révéler qu’il en va de même pour les organisations de soutien internes à une entreprise. Les utilisateurs perdront rapidement confiance dans les organisations de support internes, et cela peut prendre des années pour la reconstruire.
En parcourant la liste, pensez-vous qu’un client potentiel pourrait recréer la valeur de presque n’importe lequel de ces articles ? La réponse est presque assurément oui. Cela est vrai pour presque toutes les fonctionnalités ou capacités des produits, qu'ils soient open source ou même propriétaires. Les fournisseurs de cloud construisent leurs propres processeurs et matériels, et les sociétés de livraison (par exemple UPS, Amazon, etc.) construisent parfois leurs propres véhicules. La pertinence de construire ou d’acheter dépend de l’entreprise et de ses besoins spécifiques.
Ajoutez de la valeur aux bons endroits
Le modèle de licence open source a conduit à une explosion de la disponibilité de composants pouvant être assemblés dans un produit logiciel. En d’autres termes, cela formait une énorme chaîne d’approvisionnement en logiciels. Les chefs de produit peuvent créer des produits à partir d'une chaîne d'approvisionnement entièrement open source (par exemple, Red Hat, Chef, SUSE, etc.), ou mélanger et associer des technologies open source et propriétaires (par exemple, un noyau ouvert comme Sourcefire ou SugarCRM). Le choix d’une méthodologie entièrement open source par rapport à une méthodologie open core ne doit pas être confondu avec la résolution d’un problème commercial. Les clients achètent uniquement des produits qui résolvent leurs problèmes.
Les produits open source d'entreprise sont des solutions aux problèmes, un peu comme un véhicule vendu par un constructeur automobile. Le chef de produit d'un produit open source détermine les exigences, des éléments tels que le cycle de vie (nombre d'années), la sécurité (certifications importantes), les performances (charges de travail importantes) et l'écosystème (partenaires). Certaines de ces exigences peuvent être satisfaites par des fournisseurs en amont (projets open source) ; certains ne le peuvent pas.
Un produit open source est une composition de valeur consommée via une chaîne d'approvisionnement de fournisseurs en amont et de nouvelle valeur ajoutée par l'entreprise qui le crée. Cette nouvelle valeur combinée à la valeur consommée vaut souvent plus ensemble et est vendue à un prix plus élevé. Il est de la responsabilité des équipes produit (y compris l'ingénierie, la qualité, les performances, la sécurité, les aspects juridiques, etc.) d'ajouter une nouvelle valeur aux bons endroits, au bon moment, pour que leurs produits open source valent le prix que les clients paient plutôt que de développer le système. infrastructure nécessaire pour assembler, entretenir et prendre en charge les composants en amont eux-mêmes.