Cela fait un certain temps que le « modèle commercial open source » s’est imposé. Et le nom de ce modèle est évidemment le cloud. Mais ce qui est évident en théorie ne signifie pas que ce modèle est facile à mettre en œuvre dans la pratique. Comme l'a dit un jour Tim Bray, sommité en matière de logiciels, « les qualités qui font que des personnes excellent dans la création de logiciels [open source] de grande valeur à partir de rien ne sont pas nécessairement celles qu’il faut pour les rendre opérationnels ». Et Tim Bray a raison. Mais c’est aussi vrai que ces dernières années, les entreprises open source sont devenues exceptionnellement bonnes dans les opérations cloud. Il suffit de demander à Jay Kreps, le CEO de Confluent.

Entrée en bourse au début de l'année, Confluent affirme qu’elle va permettre d’exploiter les données en mouvement, ou les données en continu. Confluent est le principal sponsor du projet open source Apache Kafka, et pour couvrir les coûts de ce développement, Confluent a déployé un service cloud en 2017. Aujourd'hui, Confluent Cloud représente 22 % des revenus de l'entreprise. Plus révélateur encore, selon Jay Kreps, la croissance de cette activité cloud a augmenté de 200 % lors du premier appel à résultats de Confluent, dépassant la croissance globale du chiffre d'affaires de l'entreprise au cours du trimestre (64 %), et s'accélérant même au-delà du taux de croissance de 134 % de Confluent Cloud sur 12 mois rampant.

Le dur chemin du cloud 

Cependant, comme le souligne Tim Bray, « il n’a pas été facile d’y parvenir ». Comme l'a fait remarquer le CEO de Confluent lors de la conférence sur les résultats trimestriels, « les gens sous-estiment l'effort nécessaire pour créer un produit d'infrastructure cloud de classe mondiale. Il faut faire un produit à l'échelle de chaque cloud, de chaque région, disposer de l'ensemble des technologies de réseau, de la sécurité sous-jacente… C'est énorme. Et avant d’en arriver là, vous n'êtes pas vraiment prêt à travailler avec les meilleurs clients. Nous avons franchi ce seuil. Cela peut étonner compte tenu du temps que nous avons investi dans notre offre cloud. Mais sachez que nous y avons travaillé pendant des années. En réalité, c’est très difficile de développer un produit véritablement natif du cloud et de le faire correctement », a-t-il ajouté.

En d'autres termes, c’est facile de dire que « le cloud est la réponse » pour satisfaire la demande des clients et répondre au modèle de monétisation de l'open source, mais c'est assez difficile à réaliser. Comme l'a fait remarquer M. Bray, l'écriture d'un excellent logiciel et l'exploitation d'un excellent logiciel nécessitent des compétences très différentes. Cependant, de plus en plus, les clients ne veulent pas développer le logiciel eux-mêmes. C'est pourquoi, des entreprises comme Confluent investissent massivement dans les logiciels et les opérations. Si une entreprise développe un projet open source, comment fait-elle pour transformer ce projet (formidable que les développeurs adorent) en activité florissante (pour laquelle les clients sont prêts à payer) ? Le cofondateur de MongoDB, Eliot Horowitz, a quelques réponses à apporter à ce sujet.

Difficile passage au cloud pour MongoDB

Aujourd'hui, MongoDB Atlas, le service de base de données de MongoDB, génère plus de la moitié des revenus de l'entreprise. Mais il n'en a pas toujours été ainsi. MongoDB a passé des années à construire et à exploiter l’outil de surveillance MongoDB Monitoring Service (MMS) qui a précédé son service de base de données, bien avant le lancement d'Atlas en 2016. Dans une interview, M. Horowitz a déclaré que « l’objectif de MongoDB a toujours été de délivrer un service de base de données complet », conformément à la vision initiale de l’entreprise de lancer une offre de plateforme en tant que service. Mais celle-ci a choisi de commencer avec MMS pour « apprendre à bien gérer les opérations cloud, de façon à être prêts à lancer Atlas pour de bon, et de ne pas avoir à repartir de zéro ». Pour les entreprises open source en quête d'un modèle à suivre, celui est aussi bon qu'un autre. En bref, commencer par un petit service cloud utile, même si sa portée fonctionnelle est quelque peu limitée au départ.

Voilà pour la partie opérationnelle. Mais pourquoi un client devrait-il s'adresser à un fournisseur particulier ? Si le projet sous-jacent est open source, n'importe qui peut construire un service cloud autour de ce projet. C'est pourquoi Confluent (ainsi que ses pairs comme Redis) tente également de différencier son service cloud en ajoutant des extensions propriétaires au noyau open source. C’est exactement le modèle de licence open-core que l'industrie utilise depuis des années. M. Kreps fait remarquer que l'objectif de son service cloud, y compris ces extensions propriétaires, est de « permettre de tirer plus facilement de la valeur de Kafka », même si l'entreprise explique plus clairement pourquoi un client devrait payer pour cela. En effet, ce modèle est devenu quelque peu standard, même pour les fournisseurs de cloud, qui ajoutent souvent leurs propres extensions propriétaires à des logiciels par ailleurs open source. De cette façon, Confluent et les autres fournisseurs différencient leurs services respectifs.

Développer des ressources à partager 

Tel est l'objectif. Mais aussi importante que soit cette éventuelle utopie du cloud, rien n’est possible sans le développement préalable d’un logiciel open source. En tant que tel, Confluent continue à développer ses opérations cloud, même si l’entreprise continue également à rendre Kafka aussi solide que possible, en le traitant comme une « primitive de bas niveau pour réimaginer ces types d'applications de streaming de données ». M. Kreps poursuit : « Nous avons vraiment fait en sorte de simplifier de plus en plus la prise en main de Kafka (sur site, comme ailleurs), et à simplifier encore plus la mise à l'échelle en production grâce au cloud. Avec le cloud, « nous pouvons simplement le faire pour vous », a encore déclaré Jay Kreps. « En 30 secondes, nous pouvons rendre pour vous cette nouvelle capacité de classe mondiale opérationnelle ».