Open source : les leviers pour un modèle durable

[Indigostar]

L’open source, modèle durable ? À l’heure où la question (ré)attire l’attention, focus sur quelques leviers de financement.

Confluent, Databricks, GitLab, JetBrains, Talend… Autant d’entreprises qui figurent au COSSI (Commercial Open Source Software Index). Ce qui leur vaut cette distinction ? Toutes affichent un chiffre d’affaires annuel de plus de 100 millions de dollars. Elles ont toutefois d’autres dénominateurs communs. À commencer par leur modèle économique, de type open core.

L’essentiel des entreprises classées au COSSI sont sur ce même business model. Parmi les exceptions, il y a SUSE et Red Hat. Ainsi que Mozilla. Les deux premiers ont fondé leur activité sur le support. Le troisième, sur la publicité et les royalties – entre autres par des accords avec des moteurs de recherche.

Support et Open SaaS : les méthodes Red Hat et WordPress

L’approche « support payant » a l’avantage de couvrir potentiellement l’ensemble du cycle de vie des logiciels concernés. Pour certains, les prestations commencent dès la compilation du code source. Et vont jusqu’à la maintenance étendue.
Le modèle est toutefois exigeant en ressources et suppose donc des marges réduites. Il existe aussi un risque que les entreprises clientes finissent par développer leurs propres compétences. Ou qu’elles s’appuient sur d’autres prestataires.

La composante support vient parfois se greffer au modèle dit Open SaaS. C’est-à-dire la fourniture de versions hébergées de logiciels open source. Un mécanisme dans l’absolu plus rémunérateur, et dont le CMS WordPress est un emblème.

Multilicence…

Support payant et Open SaaS peuvent tout à fait entrer dans une approche multilicence. Celle-ci permet de segmenter les droits en fonction des usages. Par exemple en imposant des conditions à ceux qui exploitent un projet en production et/ou le distribuent au sein de leurs propres produits.

Plus une licence est « permissive » (Apache, BSD, MIT…), plus elle est susceptible d’attirer des contributions. Mais aussi d’entraîner la réutilisation du code sans contrepartie. Là interviennent les licences de type copyleft. De manière générale, elles imposent que la redistribution se fasse sous la même licence. C’est le cas de GPL, qu’utilise notamment MySQL.

AGPL va un cran plus loin, en obligeant à ouvrir le code de tout dérivé dès lors qu’on met ses fonctionnalités à disposition par voie de réseau. De grands éditeurs ont basculé, ces dernières années, vers des licences de ce type, pour se protéger des fournisseurs cloud. MongoDB et Elastic ont par exemple adopté SSPL… non approuvé par l’OSI.

Chez Redis, on fonctionne avec trois licences. BSD-3 pour le cœur open source, commerciale pour pour la version Enterprise… et RSAL (Redis Source Available License pour certains modules complémentaires). Elle autorise leur réutilisation, sauf dans certains types de produits dont les bases de données et les moteurs de recherche.

… et open core

Redis, comme Elastic et MongoDB, suit un modèle qui entre dans la catégorie open core : une base gratuite, des compléments payants. Ou le freemium appliqué à l’open source. Avec une question cruciale : trouver le bon équilibre sur le long terme.

Elastic fait partie des projets open core qui centralisent tout le code sur un même dépôt. Entièrement ouvert, mais avec certaines fonctionnalités « éteintes ». Ce type d’approche facilite les contributions communautaires, à condition de bien définir les conditions de propriété intellectuelle. D’autres privilégient une distribution à part pour les fonctionnalités additionnelles ; par exemple, à travers un fork.

Du sponsorware au crowdfunding

On se lance parfois avec l’appui d’organisations. Pour certains, dans le cadre de programmes aboutissant à des bourses, subventions et autres aides. Pour d’autres, en travaillant d’abord sur des besoins internes, avant de publier le code.

Avec sa licence BSL (Business Source License), MariaDB a instauré une autre forme de décalage. La publication des sources intervient en l’occurrence quatre ans après la mise à disposition du code.
La pratique du sponsorware est dans le même ordre d’idée : des projets font payer des accès anticipés à des dépôts privés.

On n’oubliera pas l’option donations. En la matière, GitHub a, depuis 2019, son initiative Sponsors. Elle est venue compléter des plates-formes comme Patreon et Open Collective.

Source : silicon.fr

[ALRBP]

Intéressant, mais ces modèles concernent surtout des gros logiciels avec des clients pros. Dans le cas de Mozilla, et son modèle de sponsoring, un logiciel enduser de grande importance.

Je ne suis pas convaincu que ça soit applicable pour une petite bibliothèque. Pour un gros framework, du “freemium” ça marche (Qt, et encore, leurs finances sont précaires), mais pour les petites bibliothèques comme celles qui ont relancé le débat récemment, le sponsoring me semble inenvisageable et je ne suis pas convaincu que le freemium puisse marcher.

Ce genre de bibliothèques, on en met plein dans un gros projet, et elles sont souvent remplaçables, sachant qu’on n’utilise que des fonctionnalités très basiques ; difficile de convaincre de payer pour ça.