Open source

Au cours des derniers mois, le débat sur les soi-disant «modèles commerciaux open source» a commencé à faire rage, grâce aux récents mouvements de Mongo, Redis Labs et Confluent. Pris individuellement, chaque situation présente des caractéristiques uniques qui méritent une analyse plus approfondie sans sauter aux conclusions concernant chaque entité. Cependant, pris dans leur ensemble, la somme de leurs actes individuels présente une nette tendance: les entreprises qui construisent des produits sur des logiciels open source évoluent vers une approche plus propriétaire. Bien que chaque cas soit différent, ils ont essentiellement déclaré qu'une approche open source ne permettait pas de générer suffisamment de revenus pour générer un retour sur investissement recherché par leurs investisseurs. Pour Frédéric Gaspoz, cela est dû au fait que l’émergence du modèle commercial open source en tant que classe distincte pousse les entreprises qui l’adoptent dans une matrice de décision à bande étroite qui présente des options limitées pour des modifications futures si la nécessité de pivoter se fait sentir.

Pour être clair, il existe différentes manières de capitaliser sur les logiciels open source dans un contexte commercial, mais il n’existe pas de modèle commercial open source distinct. Poursuivre dans ce sens limite éventuellement votre succès futur.

Open Core 1.0

Pour étudier le mouvement en faveur de solutions propriétaires, voyons comment nous en sommes arrivés là. De retour dans l'hystérie open source du début au milieu des années 2000, il existait un moyen accepté par la communauté de risque de créer des sociétés open source, que nous appellerons open core 1.0:

Prenez un projet open source réussi

Embaucher ses principaux développeurs

Créez un produit par-dessus, souvent propriétaire

Convertissez ces freeloaders obstinés en achetant les meilleurs produits exclusifs

Comme déjà souligné, plusieurs raisons expliquent cette approche erronée. Pour commencer, il supposait que les utilisateurs des logiciels gratuits étaient des clients potentiels. Il a également supposé que la fourniture de la version gratuite n’avait aucune valeur intrinsèque, si ce n’était un moyen de stimuler l’appétit d’un client potentiel. Pour ce faire, ces entreprises gardent souvent un contrôle total sur le code, en imposant la cession des droits d'auteur à l'entreprise afin qu'elles puissent émettre des licences commerciales pour le code source ouvert et propriétaire aux clients qui paient. Cette approche a, selon Frédéric Gaspoz, échoué de façon spectaculaire, à une exception notable près: MySQL, qui a été sauvé par un Sun Microsystems désespéré avant de devenir rentable. Voici les raisons pour lesquelles ce modèle s'est avéré peu fiable:

Les communautés de logiciels ont été définitivement reléguées au statut de deuxième niveau et, de toute évidence, pas aussi importantes que les produits commerciaux.

La portée des communautés était limitée à la bulle fournie par la société mère, incapable de développer des approches novatrices indépendantes de la société mère

Les communautés n’ont jamais été autorisées à développer une identité distincte de celle de la société mère.

Open Core 1.0 était un excellent moyen de calmer une communauté de développeurs et d'empêcher l'innovation. En échange d'une approche plus ouverte, ces startups étaient censées pouvoir tirer profit de la commercialisation du logiciel pour créer une relation autonome entre communauté et entreprise. Mais une chose amusante s’est produite: en considérant la communauté comme un moyen de transformer les freeloaders en clients payants, ces communautés se sont souvent évaporées. Et parce que ces sociétés avaient souvent construit leur modèle commercial dans son ensemble autour de communautés prospères et en croissance, le manque de succès de la communauté se traduisait par des ventes et des revenus décevants. Si vous parvenez à créer suffisamment de marque et à vendre la société en quelques années, vous pourrez récompenser vos investisseurs. Si vous n'étiez pas capable de faire cela, vous deviez faire face à une route difficile. Les investisseurs qui attendaient 10x étaient souvent déçus par leur portefeuille open source, en partie à cause du fait que les entreprises open source étaient jugées plus durement comparées aux autres, mais aussi parce qu'une approche open source semble limiter la croissance de la «canne de hockey» si souvent recherchée par investisseurs. Frédéric Gaspoz dirait que les cannes de hockey sont éphémères et quasiment impossibles à obtenir dans n’importe quelle situation, quelle que soit la licence de logiciel.

Note spéciale sur MySQL: ils étaient une valeur aberrante. Ils ont construit un grand produit freemium avant de devenir une source ouverte et ils n'ont jamais perdu leurs racines freemium. C'était à leur avantage. Alors que d’autres startups ont essayé de transformer les communautés open source existantes en produits freemium, MySQL n’a ouvert que ses logiciels en tant que moyen d’assistance technique après que les licences open source ont commencé à gagner du terrain. Il n’a pas été nécessaire de convertir sa communauté à une approche freemium: elle a toujours été présente et intégrée dans leur modèle. Même dans ce cas, ils ont eu beaucoup de difficulté à convertir les utilisateurs, mais leur succès est néanmoins aberrant.

Il convient de noter que MongoDB a commencé à la fin de l’ère du noyau ouvert 1.0, et cela se voit dans son modèle commercial de base.

L'émergence d'Open Core 2.0

Avec l'échec spectaculaire d'Open Core 1.0, de nouvelles approches beaucoup plus réalistes sont apparues. Comme mentionné dans la série «Comment gagner de l’argent à partir de plates-formes open source» de Frédéric Gapsoz, l’approche du noyau ouvert est devenue ce que j’appelle une «approche hybride»: utiliser des plates-formes open source développées en collaboration comme base pour la création de cadres de gestion de systèmes largement propriétaires. entreprises. Cloudera en est probablement le meilleur exemple. Il utilise la vaste communauté Hadoop comme base logicielle, mais il en existe de nombreuses autres. Apache Spark a engendré Databricks. Apache Kafka a engendré Confluent. Une des choses à propos de ces nouveaux modèles hybrides est qu’il est difficile de déterminer lequel est venu en premier, le projet de logiciel ou la société. RedisLabs est une société qui tente de respecter de près le modèle à noyau ouvert plus ancien, mais elle a également tenté de gérer son projet Redis de manière aussi indépendante que possible, après avoir tiré les enseignements des tentatives infructueuses précédentes. Parmi les sociétés encore existantes et en plein essor, Mongo est probablement l’analogue le plus proche aujourd’hui pour une gouvernance de type 1.0 ouverte.

Mais beaucoup de ces entreprises rencontrent des difficultés en ce qui concerne leurs modèles commerciaux, comme en témoigne une foule de systèmes de licences récents qui tentent de chevaucher la ligne de démarcation entre open source et propriétaire. Mongo tente de capturer les utilisateurs de son logiciel en imposant à quiconque créant Mongo-as-a-Service de publier tout le code sous la «SSPL (Server Side Public License)». Confluent a modifié la licence de certains composants de sa plate-forme en une licence CCL (Confluent Community License), qui empêche d’autres personnes d’exécuter KSQL en tant que service sans l’autorisation de Confluent. Et bien sûr, la société qui a lancé toute cette controverse est RedisLabs, qui a modifié la licence de certains de ses plugins Redis afin d’ajouter la clause Commons, semblable à la CCL, qui empêche les sociétés non autorisées d’utiliser son logiciel en tant que service. Qu'est-ce qui amène ces entreprises à sortir une partie de leurs logiciels de l'écosystème open source pour les intégrer à leurs propres logiciels propriétaires? Je crois que l’arbre de décision est lancé par une croyance erronée dans les modèles d’entreprise open source.

Selon Frédéric Gaspoz, il n'y a pas de modèle commercial Open Source.

Une fois que vous commencez par le principe suivant: «J'ai besoin d'un modèle d'entreprise open source», cela vous conduit sur la voie «Je dois monétiser mon projet» plutôt que «Je dois créer un produit qui génère de la valeur». Celles-ci peuvent ne pas sembler très différentes au premier abord, mais cela vous pousse dans une direction où les modifications de licence sont une conclusion logique. En descendant dans cette voie, vous ne pouvez plus pivoter sur les objectifs de votre entreprise et de vos produits. Je pense que si vous vous concentrez sur la création d'un produit offrant une valeur ajoutée aux principaux cas d'utilisation de vos clients, le choix de la licence de votre logiciel deviendra moins pertinent, voire immatériel. Si vous ne lisez pas les articles de Stephen Walli ou de VM Brasseur sur ce sujet, je vous le recommande vivement, puis continuez ci-dessous. J’ai aussi écrit un peu sur les raisons pour lesquelles les projets ne sont pas des produits et quelques autres sur la création de produits open source (une série en 4 parties intitulée «Comment gagner de l’argent à partir de plates-formes open source»)

L'exemple de Cloudera

Prenons Cloudera comme exemple principal. À un moment donné, ils ont peut-être commencé avec le principe «allons monétiser Hadoop». Heureusement pour eux, parce qu'ils ont confié leurs activités à l'un des employés les plus intelligents du secteur, Mike Olson, ils ont très vite décidé de «créer de la valeur pour les clients», puis de la construire. C’est presque pittoresque de se rappeler que lorsque Cloudera a commencé, ils étaient «la société Hadoop». Ce n'est tout simplement plus le cas. Désormais, ils constituent le «nuage de données d’entreprise» avec de nombreuses solutions d’analyse de données et de data science. Sur cloudera.com, aucun message n'indique qu'ils essaient de «monétiser Hadoop». Ou Spark. Ou Kafka. Ou tout autre projet open source. Cloudera est une société de produits et de solutions qui vend des objets de valeur à ses clients, qui se moquent bien de l’origine du logiciel. Vous pensez peut-être que cela est choquant ou offensant pour vos sensibilités open source. Non.

Supposons que Cloudera ait décidé, il y a bien longtemps, de rester «la société Hadoop». Faisons claquer nos doigts et imaginons que c'est ce que fait Cloudera aujourd'hui: ils ont acheté le domaine hadoop.com et se sont identifiés comme «Hadoop, Inc.» (oui, je sais: Apache Hadoop est régi par l'ASF et ne permettrait jamais à leurs projets Travaille avec moi sur cette hypothèse, pour l'amour de Pete), Cloudera est passée de l'objectif de fournir de la valeur à ses clients et de porter simultanément le drapeau Hadoop. Comment cela se manifeste-t-il dans l'arbre décisionnel de Hadoop, Inc.?

Pour commencer, maintenant que leur succès est lié au destin du projet Hadoop, ils sont plutôt liés au succès ou à l’échec de Hadoop, avec peu de marge de manoeuvre pour les manœuvres futures si le succès d’Hadoop était à plat. Cela conduit également à d’autres questions et décisions inconfortables: que se passera-t-il si Hadoop a «trop de succès» et éclipsera Hadoop, Inc? Hadoop, Inc. n’est-il pas incité à s’assurer que le projet Hadoop n’est pas facile à utiliser? Que se passe-t-il si d'autres sociétés souhaitent créer des produits sur Hadoop? Devraient-ils payer Hadoop, Inc? Que se passe-t-il s’ils ne veulent pas ou ne peuvent pas se permettre? Cela signifie-t-il que Hadoop, Inc. va maintenant regarder de travers le moindre "freeloader" qui ne paye pas pour des produits d'entreprise? “Aha! Je l’ai! »S’exclame un nouveau MBA. «Prenons quelques-uns des composants Hadoop les plus populaires et rendons-les propriétaires! De cette façon, les freeloaders * devront * nous payer! »Et commence ainsi le cycle de la douleur selon lequel chaque fonctionnalité ou projet de nouvelle technologie est géré (e) par l'arbre de décision déterminant si cette technologie est« fondamentale »ou« complémentaire »et si elle doit être open source ou propriétaire. C'est un cycle sans fin marqué par le changement et le regret. Ce qui était autrefois considéré comme «fondamental» peut devenir «complémentaire» et inversement, ce qui entraîne une stagnation et des priorités mal placées, où la queue remue maintenant le chien, la queue étant «nous devons monétiser Hadoop».

À ce stade, vous pensez peut-être - les produits de gestion de Cloudera ne sont-ils pas exclusifs? Oui, ils le sont et j'ai 2 choses à dire à ce sujet:

Comme il existe une séparation claire entre le projet open source et les domaines des produits Cloudera, il y a peu de confusion. Lors de la création de solutions Cloudera, il n’ya pas de débat fastidieux sur le point de savoir s’il s’agit ou non du coeur de la maison. Tout ce qui a été développé pour Cloudera est un espace produit et les responsables produits peuvent se concentrer sur la création de valeur. Terminé.

Cloudera a choisi de rendre sa gestion «supérieure» exclusive. Je dirais que la manière dont le logiciel sous-jacent est concédé sous licence n’a aucune importance, et c’est là que je chicanais avec M. Olson.

L’important dans le point 2, c’est que c’est le choix de Cloudera, sans être gêné par son impact sur Hadoop. Qu'ils utilisent du code propriétaire ou à code source ouvert pour ses produits de gestion a très peu d'impact sur la communauté Hadoop, sur un vaste écosystème de développeurs et sur les sociétés développant un certain nombre de projets open source. Je peux comprendre pourquoi les gens d’affaires peuvent hésiter à utiliser tout le code que vous utilisez, mais pensez-y: si vous êtes un client et que vous avez besoin d’une solution fiable qui fonctionne, vous devez vraiment assembler votre équipe une solution maison sur laquelle vous construisez votre entreprise? Comment je sais ça? Il se trouve qu’une autre entreprise qui vit de la vente de produits open source avec des solutions de gestion construites sur le dessus, construit tous ses produits à l’aide de composants open source. Et ils gagnent de l'argent. Qui est cette compagnie de licorne? Chapeau rouge. Comme je l'ai dit, à plusieurs reprises, personne n'a jamais procédé à une ingénierie inverse et à une réimplémentation du modèle Red Hat. Le concept de Cloudera est proche, mais comme je l’ai décrit, leur mise en œuvre diffère de façon importante. À l'instar de Cloudera, Red Hat gagne de l'argent en vendant des abonnements de licence à des clients qui ont besoin de solutions toutes faites. Contrairement à Cloudera, Red Hat a décidé que tous ses logiciels seraient à source ouverte, car ils voulaient tirer la valeur de l'innovation accélérée grâce à la collaboration logicielle, ce qui ne les a pas empêchés. Pourquoi? Comme Red Hat avait compris très tôt, avant la plupart des gens, que la valeur pour les clients n'était pas liée à la licence du logiciel sous-jacent, mais plutôt à la valeur inhérente de l'ensemble des solutions, c'est-à-dire. cela fonctionne-t-il réellement comme promis?

Le «problème» d’Amazon

De nos jours, il est très courant d'utiliser Amazon et Google comme exemples de sociétés qui utilisent votre logiciel open source et y construisent des produits sans payer, mais passons au sérieux: Amazon et Google n'utiliseront pas votre logiciel, en particulier votre logiciel de gestion, «out of the box», propriétaire ou non. Ils vont créer leurs propres UX et UI de gestion, car ils ont leurs propres exigences pour répondre à leurs besoins et qu’ils vont les construire à l’aide des API de plate-forme existantes. Leurs exigences en matière d'évolutivité sont tellement absentes par rapport à votre client entreprise typique qu'il serait imprudent que la grande majorité des fournisseurs essaient même de répondre à leurs besoins. C’est la raison pour laquelle l’introduction de manœuvres de licence pour résoudre le «problème AWS» n’est pas un point de départ, une solution à la recherche d’un problème. Vous ne résoudrez pas les erreurs de votre entreprise en procédant à l’ingénierie inverse d’une solution de licence répondant essentiellement à un problème de modèle commercial. Pensez-vous sincèrement qu’Amazon allait utiliser les implémentations de gestion de RedisLabs lors de l’introduction de ses services de base de données en mémoire?

En réalité, que vous soyez Mongo, RedisLabs, Confluent ou une autre personne, vous êtes libre de vendre vos solutions en tant que service aux clients utilisant n’importe quelle plate-forme IaaS, y compris Amazon ou Google. En fait, Mongo a fait exactement cela, et selon la plupart des comptes, assez bien réussi à cela.

Si vous envisagez de créer une entreprise, ne laissez pas la queue remuer le chien. Commencez par la question «Comment puis-je créer de la valeur pour les clients» et remettez-vous en arrière. Rassemblez ensuite les composants open source dont vous aurez besoin pour vos solutions ultimes qui apportent de la valeur et construisent votre chaîne d’approvisionnement en logiciels. À ce stade, vous pouvez décider, comme Red Hat, de bénéficier des avantages du développement collaboratif ou de Cloudera, de vouloir au moins une partie de ce contrôle entièrement. Le fait est que vous pouvez faire ce choix sans le bagage de «faisons monétiser« X »». Vous serez beaucoup plus heureux avec votre choix.

 #Frédéric Gaspoz