Yama est-il un écosystème open source ?

Aujourd’hui, il devient de plus en plus complexe de trouver un modèle économique stable sur le long terme permettant de financer le développement de logiciels libres.

En effet, cette réflexion est au cœur de nos préoccupations depuis que nous avons lancé notre programme de R&D autour de l’écosystème Yama. Comment contribuer au monde de l’open source tout en trouvant un équilibre économique permettant de rémunérer l’équipe ?

Pendant toute la durée du développement, des réflexions autour de cette thématique ont régulièrement eu lieu au sein de l’équipe. Néanmoins, c’est surtout courant 2024, alors que HashiCorp et Redis venaient de changer de licence et que nous réfléchissions à notre écosystème de microservices, que nous avons décidé de statuer sur cette problématique.

Au travers de ce texte, nous souhaitons vous faire part de nos réflexions et vous présenter notre positionnement.

Yama, un écosystème de gestion du cycle de vie d’un site statique

Avant de commencer, il est important de faire un état des lieux de l’architecture de l’écosystème Yama afin de mieux comprendre comment nous en sommes arrivés à proposer un modèle et une vision uniques en leur genre.

L’écosystème est composé de différentes briques qui peuvent fonctionner de manière totalement autonome. C’est ce que l’on appelle une architecture en microservices :

Yama CMS : le cœur de l’écosystème, qui joue un rôle de liaison entre les différents microservices. Sa fonction principale est de générer des fichiers Markdown et JSON, qui seront ensuite envoyés dans un dépôt Git.
Yama CI : ce service permet d’exécuter des tâches de manière fiable et isolée, à partir de définitions versionnées dans un dépôt de code. Il permet notamment de réaliser les opérations de construction et de déploiement des sites statiques.
Yama Proxy : un service qui s’appuie sur GitPages et permet d’exposer simplement des fichiers statiques stockés dans un espace de stockage S3. Basé sur Caddy, il se place devant le bucket afin d’assurer automatiquement la génération des certificats SSL et la mise en cache.
Yama Analytics : un service permettant de fournir des statistiques web directement à partir des journaux du serveur web. Conçu selon le principe du privacy by design, il garantit une collecte respectueuse de la vie privée tout en offrant des analyses approfondies du trafic de vos sites.
Yama Media : ce service permet de distribuer des fichiers stockés dans un espace de stockage S3 par l’intermédiaire d’un serveur web Caddy, associé à un service Thumbor qui permet le redimensionnement dynamique des images.
Yama Database : ce service permet de stocker des données structurées en s’appuyant sur le standard JSON Schema. Il permet de collecter des données au moyen d’une API REST ou grâce à l’intégration de simples formulaires HTML.

Cette architecture en microservices n’est pas uniquement un choix technique. Elle constitue le fondement de notre approche en matière de distribution des logiciels, de gouvernance et de modèle économique.

En séparant les différentes briques du cœur de Yama, nous pouvons leur appliquer des modalités de distribution distinctes, tout en préservant la possibilité de les utiliser ensemble pour bénéficier de l’intégralité de l’écosystème. Cette distinction nous permet de penser indépendamment la diffusion des logiciels, leur financement et les conditions dans lesquelles ils peuvent être exploités.

C’est précisément cette séparation qui nous permet d’aborder les questions qui suivent : comment garantir les libertés des utilisateurs grâce à une licence open source, comment financer le développement de l’écosystème sans restreindre les usages commerciaux et comment éviter que les services développés bénéficient à des acteurs qui ne contribuent pas à leur pérennité ?

Pour répondre à ces enjeux, nous avons fait des choix qui méritent d’être expliqués, notamment en distinguant le cœur de Yama des microservices qui composent son écosystème.

2024 : un tournant dans l’écosystème open source

L’année 2024 s’inscrit dans une période de tensions autour du modèle économique de l’open source. Plusieurs entreprises qui avaient construit leur succès sur des logiciels largement accessibles ont décidé de modifier leurs licences pour mieux contrôler les usages commerciaux de leurs projets.

Deux événements illustrent particulièrement cette période : le changement de licence de HashiCorp pour Terraform en 2023, puis celui de Redis en mars 2024. Ils ont relancé les discussions sur la définition même de l’open source, les droits des utilisateurs et la pérennité des projets logiciels.

Une rupture de confiance

Il est important d’interroger les conséquences d’un changement de licence sur les utilisateurs qui ont construit leurs outils ou leur modèle économique autour d’un logiciel.

Lorsqu’une entreprise développe un projet open source, les utilisateurs peuvent contribuer à son amélioration, l’intégrer à leurs infrastructures ou bâtir des offres commerciales à partir de celui-ci. Cette adoption repose notamment sur la confiance dans la pérennité du projet et dans les conditions de sa licence.

Lorsque ces conditions évoluent pour restreindre certains usages commerciaux, les utilisateurs concernés peuvent avoir le sentiment que les règles du jeu ont changé après qu’ils ont investi du temps et des ressources dans la technologie et cette situation peut être vécue comme une rupture de confiance.

Une dépendance technique et économique difficile à inverser

Plus une technologie est intégrée à une infrastructure, à des processus métier ou à une offre commerciale, plus il peut être coûteux de s’en détacher.

Un changement de licence peut alors contraindre certaines organisations à choisir entre plusieurs options :

rester sur une ancienne version,
migrer vers une solution concurrente,
maintenir leur propre fork,
adapter leur modèle économique aux nouvelles conditions.

Ces choix entraîneront nécessairement des coûts ; cette dépendance soulève une question centrale : disposer du code source ne suffit pas toujours à garantir la maîtrise de sa stratégie technique.

La capacité de résistance de l’écosystème open source

Les débats autour de Terraform et de Redis illustrent cette dynamique : les décisions des entreprises concernées ont suscité des réactions dans leurs communautés. Ces réactions montrent que la valeur d’un logiciel ne repose pas uniquement sur son code, mais également sur sa communauté.

La possibilité de forker un projet constitue ainsi une garantie importante, mais elle n’est pas suffisante à elle seule. Maintenir durablement une alternative demande des compétences, du temps et des financements.

Un mouvement plus large que HashiCorp et Redis

Ces deux événements ne sont pas isolés. Ils s’inscrivent dans une évolution amorcée plusieurs années auparavant.

Année	Projet ou entreprise	Évolution	Conséquence
2018	MongoDB	Adoption de la SSPL à la place de l’AGPL pour son serveur communautaire.	Restrictions supplémentaires pour les services cloud reposant sur MongoDB.
2021	Elasticsearch et Kibana	Abandon de la licence Apache 2.0 pour le code concerné, au profit de l’Elastic License et de la SSPL.	Création d’OpenSearch par AWS et d’autres contributeurs.
2023	HashiCorp / Terraform	Passage de la MPL 2.0 à la BSL pour les versions futures des principaux produits.	Création d’OpenTofu.
Mars 2024	Redis	Passage de la BSD 3-Clause à la RSALv2 ou à la SSPLv1 pour les versions futures.	Création de Valkey.
Septembre 2024	Elastic	Ajout de l’AGPLv3 comme option de licence pour le code concerné d’Elasticsearch et Kibana.	Retour d’une licence reconnue par l’OSI parmi les options disponibles.

Le cas d’Elastic en 2024 est intéressant : le mouvement n’est pas exclusivement orienté vers des restrictions croissantes. L’entreprise a ajouté l’AGPLv3 comme option pour permettre aux utilisateurs de bénéficier à nouveau d’une licence open source approuvée par l’OSI.

Pourquoi les fournisseurs de cloud sont-ils au centre du débat ?

Les fournisseurs de cloud, ou hyperscalers, sont au cœur du débat pour trois raisons qui se rejoignent. Ils ont les moyens d’héberger des logiciels à très grande échelle, ils peuvent transformer des logiciels open source en services commerciaux, et ils ne contribuent pas toujours à leur développement à la hauteur de ce que leurs créateurs espéraient.

Ils ont les moyens de changer d’échelle : AWS, Google Cloud ou Microsoft Azure, ce ne sont pas juste des serveurs dans un coin d’un datacenter. Ce sont des infrastructures gigantesques, des équipes techniques, des systèmes de facturation, de supervision et de déploiement. Héberger un logiciel pour quelques clients ou le proposer à des milliers d’entreprises à travers le monde, ce n’est pas vraiment le même métier. Et les hyperscalers ont déjà toute l’infrastructure nécessaire pour le faire.

Ils peuvent vendre le travail des autres : imaginons que vous développiez un super logiciel open source. Vous passez des années à le concevoir, à corriger les bugs, à écrire la documentation et à construire une communauté. Un hyperscaler peut ensuite reprendre ce logiciel, l’héberger pour ses clients et leur facturer le service. Il n’a pas nécessairement besoin de développer le logiciel lui-même : il lui suffit de proposer une expérience clé en main, intégrée à son infrastructure.

Et c’est là que ça coince. Vous, vous financez le développement du logiciel. Lui, il peut gagner de l’argent en vendant un service autour de ce logiciel, sans forcément contribuer autant que vous à son développement. Il peut même devenir votre concurrent direct, alors que vous êtes à l’origine du produit !

Le modèle économique de l’open source : bien sûr, tout cela n’a rien d’illégal ni d’incompatible avec les licences open source classiques. C’est même une partie de leur principe : permettre à d’autres de réutiliser, de modifier et de redistribuer le code. Les hyperscalers contribuent d’ailleurs eux aussi à de nombreux projets open source.

Mais il y a une différence entre rendre un logiciel librement réutilisable et réussir à financer durablement son développement. Quand une entreprise investit beaucoup dans un logiciel et voit d’autres acteurs monétiser ce travail à grande échelle, sans que cela se traduise par des revenus suffisants pour financer la suite, elle peut finir par se poser des questions.

On pourrait imaginer un monde idéal où tout le monde réutilise le code, contribue au projet et permet à l’ensemble de l’écosystème de progresser. Mais dans la réalité, les intérêts ne sont pas toujours alignés. Celui qui développe le logiciel, celui qui l’héberge et celui qui le vend à l’utilisateur final ne sont pas forcément la même entreprise.

Alors, faut-il empêcher les hyperscalers d’utiliser l’open source ? Pas nécessairement. Ce serait même contraire à la philosophie de nombreuses licences libres. La vraie question, c’est plutôt : comment financer le développement de logiciels ouverts quand les acteurs qui ont le plus de moyens peuvent aussi être ceux qui en tirent le plus de valeur commerciale ?

Les changements de licence sont une réponse possible, mais ils ont un coût : ils peuvent fragiliser la confiance de la communauté, compliquer les usages commerciaux et provoquer la création de forks. À l’inverse, conserver une licence très permissive permet une réutilisation maximale du code, mais ne garantit pas que ses auteurs pourront continuer à le développer.

Bref, ouvrir le code et financer le projet sont deux problèmes différents. L’open source sait très bien organiser le premier. Pour le second, il n’existe pas de recette universelle.

Alors comment se positionne l’écosystème Yama pour répondre à cette problématique ?

Avant d’expliquer nos choix en matière de licences et de modèle économique, il est important de revenir sur la manière dont l’écosystème Yama a été financé jusqu’à présent.

Nous avons commencé à développer Yama il y a maintenant plus de cinq ans. La majeure partie de cet investissement a été réalisée sur nos fonds propres. Nous avons néanmoins pu bénéficier d’une bourse French Tech, financée par Bpifrance, d’un montant d’environ 30 000 euros. Nous avons également bénéficié du soutien du programme NGI, qui a contribué au financement du développement de Yama Analytics.

Le NGI Zero Commons Fund est un programme de financement soutenu par l’Union européenne et coordonné par la fondation NLnet. Son objectif est de soutenir des technologies ouvertes qui contribuent à faire d’Internet un bien commun : des solutions qui peuvent être développées, étudiées et utilisées collectivement, sans dépendre exclusivement de technologies propriétaires.

Ce type de financement est particulièrement intéressant pour un projet comme le nôtre. Il permet de consacrer des ressources à des développements qui bénéficient à l’ensemble de la communauté, sans nécessairement devoir les rentabiliser immédiatement par leur commercialisation.

Mais il ne faut pas se voiler la face : les subventions publiques ne suffisent généralement pas, à elles seules, à assurer la pérennité économique d’un projet sur le long terme. Nous les considérons davantage comme un moyen d’amorcer la pompe que comme un modèle de financement durable.

Dans notre cas, les montants obtenus restent modestes au regard de l’investissement global réalisé sur fonds propres. Ils nous ont néanmoins permis d’accélérer certains développements en mobilisant des ressources humaines supplémentaires.

Une bibliothèque de microservices open source

Comme nous l’avons expliqué précédemment, Yama repose sur une architecture composée de plusieurs microservices indépendants. Nous avons fait le choix de distribuer l’ensemble de ces microservices sous licence AGPLv3.

Ce choix n’est pas anodin. Nous souhaitons garantir que les libertés offertes par nos logiciels restent préservées. Nous avons également fait le choix de maintenir cette licence dans la durée. Nous ne souhaitons pas revenir sur les conditions de distribution de nos microservices au gré de l’évolution de notre modèle économique.

Pourquoi cette volonté de stabilité ? Parce que la confiance constitue un élément essentiel de la relation que nous souhaitons développer avec nos utilisateurs.

Nous sommes une entreprise à taille humaine. Nous ne pouvons pas nous permettre de construire notre réputation sur la promesse d’une solution ouverte, éthique et respectueuse de ses utilisateurs, puis de modifier les règles du jeu une fois que ces derniers ont investi du temps et des ressources dans notre écosystème. Ce serait non seulement contraire à notre philosophie, mais également un très mauvais calcul sur le plan de la confiance.

Notre objectif n’est pas d’interdire l’utilisation commerciale de nos logiciels. Nous voulons au contraire que nos microservices puissent être utilisés, adaptés et intégrés à des projets professionnels, y compris dans un contexte commercial.

En revanche, nous souhaitons éviter qu’un acteur puisse s’approprier les améliorations apportées au logiciel et les maintenir durablement sous une forme propriétaire, sans rendre accessibles les modifications dans les situations prévues par la licence.

C’est précisément l’un des intérêts de l’AGPLv3. Contrairement à certaines licences libres plus permissives, elle prévoit une obligation de mettre à disposition le code source correspondant d’une version modifiée lorsque celle-ci est utilisée pour fournir un service à travers un réseau.

Cette distinction est importante : nous ne cherchons pas à empêcher les autres de tirer profit de nos développements. Nous souhaitons plutôt que cette exploitation reste compatible avec les libertés que nous voulons garantir à l’ensemble des utilisateurs.

L’AGPLv3 constitue donc un moyen de préserver le caractère libre du logiciel mais elle ne garantit cependant pas, à elle seule, le financement de son développement. C’est pourquoi nous devons également réfléchir à la manière dont nous allons commercialiser les services associés à notre écosystème.

Et dans notre cas, les fournisseurs de cloud sont-ils vraiment un problème ?

Si la question des hyperscalers est importante pour certains projets open source, elle ne représente pas nécessairement une menace de même ampleur pour tous les logiciels.

Dans notre cas, nous n’avons pas la prétention de développer des composants génériques qui viendraient concurrencer directement les grands services proposés par AWS, Google Cloud ou Microsoft Azure. Nos microservices répondent à des besoins précis et s’inscrivent dans un écosystème conçu pour fonctionner de manière cohérente.

Nous n’avons donc pas construit notre modèle économique autour de l’idée que nous devions empêcher les grands fournisseurs de cloud de réutiliser nos développements. Au contraire, si nos logiciels peuvent être utiles à d’autres organisations, nous souhaitons qu’elles puissent en bénéficier. C’est précisément l’un des intérêts d’une licence libre.

Notre situation est donc différente de celle d’un éditeur qui développe un logiciel open source devenu incontournable, puis voit un hyperscaler commercialiser un service concurrent fondé sur ce même logiciel.

Notre principal enjeu n’est pas d’empêcher les autres de tirer profit de nos développements, mais de pouvoir continuer à les maintenir et à les faire évoluer dans la durée.

Nous devons donc trouver un modèle économique qui nous permette de financer ce travail sans remettre en cause notre engagement en faveur des logiciels libres.

Alors, comment financer le développement de microservices open source ?

Notre réponse repose sur une distinction entre les logiciels qui composent l’écosystème et les services que nous proposons pour les exploiter.

Nous avons choisi de proposer une solution en mode SaaS, tout en conservant le cœur de Yama sous une licence propriétaire. Ce cœur est accessible gratuitement. La commercialisation porte sur l’utilisation de nos microservices en mode SaaS.

Cette approche nous permet de distinguer deux usages :

Les utilisateurs techniques peuvent déployer eux-mêmes l’ensemble des microservices sur leur propre infrastructure et bénéficier ainsi de l’écosystème sans payer de licence pour ces logiciels. Ils restent bien entendu responsables des coûts liés à leur hébergement, à leur exploitation et à leur maintenance.
Les utilisateurs qui préfèrent ne pas gérer cette infrastructure peuvent recourir à notre offre SaaS. Ils bénéficient alors de services hébergés et exploités par nos soins, sans avoir à prendre en charge les contraintes techniques associées.

C’est sur cette seconde offre que repose notre modèle de revenus. Nous ne cherchons pas à faire payer l’accès aux logiciels libres, mais à commercialiser le service que représente leur exploitation dans une infrastructure que nous gérons.

Ce modèle nous permet de conserver une approche ouverte pour les utilisateurs qui souhaitent maîtriser leur propre infrastructure, tout en proposant une solution clé en main à ceux qui privilégient la simplicité.

Il répond également à notre volonté de ne pas conditionner l’accès à nos microservices à l’achat d’un abonnement auprès de notre entreprise.

Et si un fournisseur de cloud voulait commercialiser nos microservices ?

Même si ce scénario ne constitue pas aujourd’hui une préoccupation majeure, nous avons réfléchi à la manière dont nous pourrions préserver notre modèle économique.

Notre approche consiste à distinguer la liberté de réutiliser les microservices, que nous souhaitons garantir grâce à l’AGPLv3, de l’accès au cœur propriétaire de Yama, qui joue un rôle central dans l’intégration des différents composants.

Dans l’architecture que nous envisageons, l’accès à ce cœur est soumis à des conditions d’utilisation spécifiques. Nous souhaitons notamment éviter qu’un utilisateur de la plateforme puisse directement connecter nos services par l’intermédiaire d’un fournisseur de cloud ce qui fragiliseraient directement notre modèle économique.

Cette distinction est essentielle : nous ne cherchons pas à interdire la réutilisation de nos logiciels libres, mais à conserver la maîtrise des conditions dans lesquelles notre propre service intégré est exploité.

Nous considérons donc cette approche comme un moyen de préserver notre capacité à commercialiser notre offre SaaS, tout en maintenant une diffusion ouverte des microservices.

Un modèle parmi d’autres, sans prétendre détenir la solution miracle

Nous ne prétendons pas avoir trouvé une réponse universelle à la question du financement de l’open source. Chaque projet possède ses propres contraintes, ses propres utilisateurs et ses propres perspectives économiques.

Notre ambition est plus modeste : proposer un modèle adapté à notre architecture et à nos objectifs, qui nous permette de diffuser nos microservices sous licence libre sans devoir remettre en cause ce choix lorsque notre activité évoluera.

Nous voulons éviter d’avoir à changer de licence pour tenter de compenser les limites d’un modèle économique qui ne fonctionnerait plus. Nous préférons réfléchir dès maintenant à la manière de concilier les libertés accordées aux utilisateurs avec les conditions nécessaires à la pérennité de notre activité.

Notre approche repose donc sur trois principes :

maintenir nos microservices sous une licence libre stable,
permettre leur utilisation autonome et gratuite par ceux qui souhaitent les héberger eux-mêmes,
et financer leur développement grâce à une offre SaaS.

Ce modèle ne supprime pas toutes les difficultés. Il suppose que notre offre hébergée apporte suffisamment de valeur pour convaincre des utilisateurs de la préférer à une installation autonome. Il nécessite également de maintenir une séparation claire entre les composants libres et le cœur propriétaire.

Mais il nous semble constituer une piste cohérente avec notre philosophie : ouvrir nos développements, préserver les libertés de nos utilisateurs et construire un modèle économique qui nous permette de continuer à les faire évoluer.

Et pour ceux qui ne comprennent toujours pas pourquoi le cœur de Yama CMS n’est pas ouvert

Il semblerait que, pour certains défenseurs du logiciel libre, il n’existe que deux catégories de logiciels : ceux qui sont entièrement ouverts, et ceux qui méritent d’être jetés à la poubelle parce que leurs créateurs ont l’indécence de vouloir en vivre.

C’est une vision du monde assez confortable quand on utilise le travail des autres, un peu moins quand on doit payer les gens qui le produisent.

Alors, soyons clairs : nous ne pensons pas que tout doit être ouvert par principe. Nous pensons que l’ouverture du code doit répondre à un besoin, apporter quelque chose aux utilisateurs ou contribuer à un commun numérique. Et nous pensons aussi qu’une entreprise peut développer des logiciels libres tout en conservant une partie de son savoir-faire propriétaire.

C’est précisément le choix que nous avons fait avec Yama.

Tout n’a pas nécessairement vocation à être ouvert

Ouvrir du code présente de nombreux avantages. Cela permet de partager des solutions, de faire émerger des alternatives, de mutualiser les efforts de développement et, parfois, de résoudre collectivement des problèmes auxquels personne n’aurait pu répondre seul. C’est aussi une manière de réduire les silos technologiques et de donner aux utilisateurs davantage de visibilité sur les logiciels qu’ils utilisent.

L’ouverture peut également permettre à une communauté d’améliorer un logiciel, de corriger ses défauts ou de l’adapter à des usages auxquels ses créateurs n’avaient pas pensé.

Mais tous les projets ne bénéficient pas de la même manière de cette démarche.

Quel intérêt y a-t-il à ouvrir une brique de code si elle est tellement spécifique qu’elle ne présente pratiquement aucun intérêt en dehors du produit auquel elle appartient ? Quel intérêt y a-t-il à publier une couche de liaison entre plusieurs composants standards si personne n’a réellement envie de la réutiliser ? Et quel intérêt y a-t-il à transformer un produit commercial en projet open source si cela implique de consacrer une part importante de notre temps à documenter, maintenir et accompagner des utilisateurs qui n’en ont pas réellement besoin ?

Cela ne signifie pas que ce code est inutile ou sans valeur. Cela signifie simplement que l’ouverture du code a un coût, et que ses bénéfices ne sont pas automatiques.

Un projet open source demande du travail, ce travail est parfaitement légitime lorsqu’il contribue à un objectif auquel nous croyons. Mais nous devons aussi choisir où investir notre temps.

Le cœur de Yama CMS : un produit, pas un commun numérique universel

Yama CMS est un produit que nous développons pour répondre à un besoin commercial précis. Il ne s’agit pas simplement d’un petit CMS que l’on installe sur un serveur pour publier son blog.

Le cœur de la plateforme orchestre de nombreux composants. Il y a beaucoup de travail derrière cet ensemble, mais nous ne prétendons pas avoir inventé de nouveaux paradigmes informatiques à chaque ligne de code. Une bonne partie de Yama CMS consiste à faire communiquer des composants existants pour en tirer un service cohérent.

C’est précisément ce qui nous intéresse : proposer un produit qui fonctionne, plutôt que de réinventer chacune de ses briques.

Publier l’intégralité de ce code ne serait pas forcément très utile à notre public cible. Maintenir une documentation publique complète, accompagner les installations et gérer les contributions représenterait un investissement supplémentaire, sans garantie que ces efforts améliorent réellement le produit.

Nous avons donc choisi de concentrer notre démarche d’ouverture sur les composants qui nous semblent les plus pertinents à partager : nos microservices.

Cela ne signifie pas que le cœur de Yama CMS n’a aucune valeur technique. Cela signifie que sa principale valeur réside dans l’assemblage, l’intégration et l’exploitation de l’ensemble pour fournir un service commercial.

Et cet ensemble, nous le développons et le maintenons dans le cadre d’une activité économique.

Mais pourquoi ne pas simplement auto-héberger Yama CMS ?

C’est une question légitime. Si le code était ouvert, chacun pourrait théoriquement installer sa propre instance et l’utiliser librement.

Mais encore faut-il que cela réponde à un besoin.

Pour un développeur qui souhaite héberger son blog ou son site personnel, déployer toute la plateforme Yama CMS n’a pas beaucoup de sens. Cela revient à mettre en place une infrastructure complexe pour un besoin qui peut être résolu beaucoup plus simplement.

Un générateur de sites statiques comme Astro, un dépôt Git et un petit serveur suffisent souvent largement. On peut même se contenter de générer le site sur sa propre machine et d’en envoyer les fichiers sur un serveur.

Pourquoi déployer une plateforme complète pour obtenir un résultat que quelques outils simples permettent déjà d’atteindre ?

Bien sûr, il reste toujours le plaisir de monter son propre cluster Kubernetes ou OpenStack dans son homelab, de passer son week-end à configurer des services et de finir par expliquer à ses proches que tout cela fonctionne parfaitement — sauf quand il faut redémarrer le routeur.

Mais soyons honnêtes : le plaisir de l’auto-hébergement est une chose, sa pertinence économique en est une autre.

La complexité de Yama CMS vient notamment du fait que la plateforme est pensée pour fonctionner en mode SaaS, avec des mécanismes de gestion et d’exploitation adaptés à un service mutualisé. Pour un usage individuel ou à petite échelle, cette complexité apporte peu de bénéfices.

À l’inverse, un CMS git-based plus classique, installé sur un petit serveur ou utilisé localement, sera souvent plus simple à comprendre, à adapter et à maintenir.

L’auto-hébergement de Yama CMS présente donc un intérêt beaucoup plus spécifique : celui des entreprises qui disposent des compétences techniques et des ressources humaines nécessaires pour exploiter la plateforme, et qui souhaitent proposer des sites statiques à leurs propres clients.

Autrement dit, les entreprises qui pourraient utiliser notre technologie pour commercialiser un service comparable au nôtre: en somme, nos concurrents.

Le véritable enjeu : permettre la réutilisation sans ignorer notre propre modèle économique

Nous pourrions imaginer un monde idéal dans lequel toutes les agences web utilisant une même plateforme collaboreraient pour l’améliorer, mutualiseraient leurs développements et feraient progresser ensemble l’outil dont elles dépendent.

Ce modèle existe, et il fonctionne dans certains contextes. Nous sommes nous-mêmes convaincus de l’intérêt de contribuer à des logiciels libres et à des communs numériques.

Mais il suppose que les intérêts des différents acteurs soient suffisamment alignés pour justifier cette coopération.

Dans notre cas, le problème est plus terre à terre.

Nous développons une plateforme que nous souhaitons commercialiser. Si une autre agence disposant des ressources techniques nécessaires peut reprendre notre cœur de métier, déployer une infrastructure comparable et proposer le même service à un prix inférieur, elle peut directement entrer en concurrence avec nous, tout en bénéficiant du travail que nous avons financé.

Nous ne leur reprochons pas de vouloir gagner de l’argent. C’est précisément ce que nous essayons de faire nous-mêmes. Mais nous ne sommes pas obligés de leur fournir gratuitement tous les éléments nécessaires pour reproduire notre produit commercial.

Il faut aussi rappeler qu’une licence open source ne constitue pas un contrat de réciprocité économique. Elle ne garantit pas que ceux qui utilisent un logiciel contribueront à son développement, financeront son maintien ou participeront à sa communauté.

C’est l’une des forces du logiciel libre : chacun peut utiliser et adapter le code dans les conditions prévues par sa licence, sans devoir obtenir une autorisation commerciale particulière.

Mais cette liberté a une contrepartie pour ceux qui développent le logiciel : ils doivent trouver un moyen de financer leur travail sans pouvoir compter systématiquement sur les bénéfices économiques qu’en tirent les autres.

Nous avons donc choisi de ne pas ouvrir le cœur de Yama CMS. Ce choix ne remet pas en cause notre volonté de développer et de publier des logiciels libres. Il définit simplement le périmètre dans lequel nous souhaitons le faire.

Pourquoi ouvrir les microservices, alors ?

Parce que nous considérons que ces briques présentent un intérêt qui dépasse le seul fonctionnement de notre produit commercial.

Yama CI, Yama Proxy, Yama Analytics, Yama Media et Yama Database répondent à des problématiques techniques distinctes. Ils peuvent être utilisés indépendamment du cœur de Yama CMS et s’appuient sur des technologies, des formats ou des protocoles standards.

Nous avons précisément conçu l’architecture de l’écosystème pour que ces composants puissent être réutilisés séparément.

Cette séparation permet de partager des solutions sans nécessairement ouvrir l’ensemble du produit qui les utilise. C’est là que nous voyons un intérêt concret à l’ouverture : publier des briques réutilisables plutôt que rendre public l’ensemble d’un produit dont la valeur repose avant tout sur son intégration et son exploitation.

Les licences que nous avons choisies permettent également des usages commerciaux, dans le respect de leurs conditions. Nous ne cherchons donc pas à interdire aux autres entreprises de gagner de l’argent avec nos microservices.

En revanche, nous souhaitons conserver un modèle économique viable pour financer leur développement et leur maintenance.

Nous ne prétendons pas avoir trouvé la solution miracle

Nous sommes une entreprise. Nous devons générer suffisamment de revenus pour rémunérer l’équipe, payer nos frais et continuer à développer Yama.

Sans cela, le projet finira par s’arrêter. Le dépôt restera en ligne, le dernier commit prendra de l’âge, et nous finirons peut-être par ajouter #OpenToWork à nos profils.

Ce serait dommage, parce que nous pensons que les logiciels que nous développons ont un intérêt réel et méritent de continuer à évoluer.

C’est pourquoi nous expérimentons un modèle dans lequel nous ouvrons les composants qui nous semblent pertinents à partager, tout en conservant un cœur propriétaire qui nous permet de commercialiser une offre cohérente.

Vous pouvez être en désaccord avec cette approche. Vous pouvez estimer que le cœur de Yama CMS devrait lui aussi être ouvert, ou considérer que le terme « open source » ne devrait pas être utilisé pour décrire un écosystème dont une partie reste propriétaire.

Sur ce dernier point, nous préférons d’ailleurs être précis : Yama n’est pas un produit entièrement open source. Son cœur est propriétaire, tandis que plusieurs microservices qui composent son écosystème sont publiés sous licence libre. Nous ne souhaitons pas entretenir la confusion entre ces deux réalités.

Vous pouvez également critiquer notre modèle économique ou considérer qu’il ne correspond pas à votre conception du logiciel libre. Le débat est parfaitement légitime.

En revanche, nous avons parfois du mal à comprendre les critiques qui consistent à réclamer l’ouverture intégrale d’un produit sans jamais se demander comment ses développeurs pourraient financer son évolution. Et nous aurons encore plus de mal à prendre au sérieux les leçons de ceux qui exploitent nos microservices tout en considérant que notre propre modèle économique ne devrait pas exister.

Le logiciel libre donne des libertés à ses utilisateurs. Il ne leur garantit pas que quelqu’un d’autre financera indéfiniment leur développement.

Nous continuerons donc à chercher un équilibre entre ouverture, réutilisation et viabilité économique. Non pas parce que nous aurions trouvé la formule parfaite, mais parce que nous préférons essayer de construire un modèle durable plutôt que de défendre une pureté idéologique qui, à terme, pourrait ne plus produire le moindre logiciel.

Quant aux gardiens autoproclamés de l’orthodoxie open source, qui considèrent qu’un logiciel est soit intégralement ouvert, soit indigne d’exister, nous leur laissons volontiers le dernier mot.

À condition, bien sûr, qu’ils aient aussi une solution pour payer les développeurs.