2021 l'odyssée de l'Open Source

Au risque d'en décevoir certains, je ne suis pas en train de vous annoncer la sortie d'un fan-film inspiré de l'oeuvre de Kubrick.

Aujourd'hui, nous sommes là pour parler de l'écosystème Open Source, et des profonds changements qui le tourmentent ces temps-ci.

Attends, j'ai loupé un épisode ?

Il y a quelques jours Shay Banon, Elastic, annonçait un changement de licence de certains de ses produits (Elasticsearch et Kibana).

En Décembre 2020, c'est RedHat qui communiquait (suite, probablement à son rachat par IBM) que CentOS 7, la variante libre de la célèbre distribution linux commerciale RHEL (pour RedHat Enterprise Linux), allait "changer de modèle".

Le même mois, Mapbox (un autre concurrent américain de Google Maps) décidait de rendre closed source ses SDKs, utilisés partout sur la planète.

Un peu plus loin en arrière, c'était Redis et MongoDB, deux célèbres Bases de données, qui ébranlaient le monde du libre en décidant de changer leurs licences. L'une en créant la Commons Clause, l'autre en créant sa propre licence, la SSPL (Server Side Public License).

Qu'est-ce qui pourrait pousser une entreprise, dont les fondations reposent sur une mentalité "Open Source Initiative friendly", à changer son modèle ?

D'ailleurs, comment ça marche une boite qui crée des technologies Open Source ?

Open Source, libre, et gratuit

Aujourd'hui, la plupart des entreprises IT s'appuient au quotidien sur des librairies, frameworks, et solutions Open Source, leur donnant la liberté de pouvoir facilement gagner du temps pour développer leurs solutions.

Pourtant, si on y réfléchit bien, ces librairies et frameworks représentent des mois, des années d'investissements et se doivent d'être pour la plupart activement soutenus au fil des innovations de leur écosystème. Bref, ils ont un coût.

Comment financer ces projets ?

Co-développer un projet par des entreprises

Financements privés, contributeurs payés ou non, et gouvernance partagée

Un projet co-construit par plusieurs entreprises, et qui bâtit une vision de manière collective, ça existe. Les standards du web sont aujourd'hui spécifiés par le W3C, un consortium qui regroupe des centaines d'entreprises dispatchées sur des centaines de community et business groups.

Cela marche lorsque la gouvernance est bien partagée, et que la vision de ces projets est elle aussi assez bien partagée par des acteurs qui jouent le jeu. Sinon, Google voudra pousser le standard WebUSB, la Mozilla foundation dira non, Microsoft s'abstiendra, et l'innovation sera beaucoup plus lente, et chacun finira par faire son truc dans son coin... Euh...

Financer une fondation qui gère le projet et sa communauté

Financements privés, contributeurs payés ou non, et gouvernance unique

Ce modèle là fonctionne aussi très bien : une seule entité qui agit comme une entreprise pour gouverner, faire évoluer le projet, et qui s'appuie sur la communauté pour capter le besoin avant de prioriser les actions. Cette entité reçoit des financements privés de la part des entreprises qui l'utilisent, et peut accepter des contributions de code de la communauté.

C'est le cas du Kernel Linux par exemple, dont la gouvernance est gérée par la Linux Foundation (qui emploie notamment Linus Torvalds), et dont la communauté de contributeurs est majoritairement employée par les entreprises pour lesquelles le Kernel est stratégique (Intel, RedHat, Samsung, SUSE, IBM, etc...)

Dans ce cas, le modèle est sain dès l'instant où les entreprises qui l'utilisent jouent le jeu (<=> en finançant à la hauteur de leur utilisation et de leurs possibilités)

C'est le cas aussi de la Mozilla Foundation, financée à 90% par... Google. Hein ? Quoi ? Vous ne saviez pas ?

Monter une entreprise et faire rentrer l'argent autrement

... Avec une offre différente

Auto-financé, contributeurs externes possibles, et gouvernance unique

Aujourd'hui, la plupart des frameworks et des langages sont développés et maintenus par ce modèle. Cela fonctionne bien car on a bien l'expertise ultime sur le framework qu'on développe. En le rendant populaire, on augmente par la même occasion les demandes de formation, de certification, de support, de développements spécifiques, etc...

C'est le cas par exemple de Pivotal (filiale de VMWare) qui maintient le célèbre framework Spring. C'était aussi le cas de RedHat (avec le rachat par IBM, il est encore trop tôt pour dire comment cela va changer).

C'est aussi le cas de toutes les entreprises dont la recette est "plus les gens utilisent ce projet, plus je vais gagner d'argent". Exemple : le langage Kotlin par l'entreprise JetBrains, qui édite notamment IntelliJ IDEA, l'IDE le plus réputé des développeurs Java.

Dans ces exemples, le projet n'est pas le produit. Le projet Open Source agit comme une sorte de cheval de Troie, qui permet de créer des demandes entrantes pour faire vivre l'entreprise tout en rendant un énorme service aux personnes qui l'utilisent. Ça, c'est plutôt vertueux et cool !

... Avec une version "améliorée" du projet libre

Auto-financé, peu de contributions externes et gouvernance unique

Sauf que parfois, la haute valeur ajoutée se situe dans le projet, et non dans le produit. Autrement dit, le coeur de l'intelligence, l'ingrédient principal de la secret sauce de l'entreprise, est ouvert. C'est le cas notamment des stratégies Open Core, comme par exemple Nginx, MongoDB, Elasticsearch, etc...

The Secrets of Successful Open Source Business Models

Picking the right model is critical not only for the commercial viability of a project but also to ensure the support of the community. In the worst-case communities and projects have forked as a result of commercial decisions and the resulting governance debates.

BlossomImran Ghory

Ainsi, l'éditeur cherchera à se différencier en donnant de la valeur ajoutée dans des fonctionnalités "payantes", ou des extensions, ou une plateforme SaaS de son outil.

Ahh, et du coup si moi je voulais contribuer une feature sur le core qui était une fonctionnalité de la version Entreprise ? Eh bien on va surement refuser ma contribution... Ces modèles prennent donc le risque (mesuré) qu'ils développeront seuls le projet.

Et où est le problème ?

Ces modèles sont viables dès l'instant où :

• les entreprises jouent le jeu (= financent ou contribuent)
• le projet est suffisamment différent du produit
• la valeur du produit n'est pas à 100% dans le code ouvert, mais ailleurs

Sauf qu'aujourd'hui, nous vivons plutôt dans un monde où les entreprises confondent "Open Source" et "Gratuit".

D'un côté, la plupart des projets ambitieux sont menés à utiliser des technologies Open Source. Et rares sont les projets pouvant y contribuer à la hauteur de la valeur que cela apporte. L'Open Source fait gagner du temps, et permet de faire des choses qu'on n'aurait jamais pu faire sans. C'est là toute la beauté des choses.

Jawg Maps n'a pas dérogé à cette règle. Nous avons gagné du temps grâce à l'Open Source, et peut-être beaucoup plus que ce que nous avons apporté à ce même monde.

Et pourtant, on soutient quand même plusieurs initiatives ouvertes, notamment autour d'OpenStreetMap (comme Pelias, le géocodeur). Un soutien financier, une gratuité de nos services pour des projets libres ET des contributions actives et soutenues sur certains projets.

Mais rien ne nous y oblige, et c'est bien là la limite de ce modèle !

De nombreux projets Open Source sont en souffrance aujourd'hui car toute leur intelligence a été libérée, et qu'en créant un produit utilisé de partout, d'autres entreprises n'ont qu'à reprendre ce projet, l'industrialiser, et le vendre, moins cher (bah oui, la R&D en moins).

C'est exactement ce qu'il s'est passé avec MongoDB, avec Elastic, qui ont été poussés à faire ces changements. Car lorsqu'un industriel aussi puissant qu'Amazon décide de ne pas jouer fair-play, il faut changer les règles pour assurer la pérennité du projet.

Est-ce la fin de l'Open Source ?

Bien sur que non. L'Open Source est et restera longtemps encore la manière la plus intéressante d'innover librement. Cependant, en voyant les débats qui peuvent naitre des volontés de faire reconnaitre ces nouvelles licences "plus restrictives" que les autres au sein de l'Open Source Initiative, je me dis qu'il y a encore beaucoup de chemin à faire.

Développer pour soi et mettre nos innovations à disposition des autres est une philosophie à laquelle je crois. Et pour lui donner vie, il faut que les entreprises y soient plus sensibilisées et aient des rapports sains envers elles. Je ne citerai pas toutes les personnes que j'ai déjà entendu dire "on ne veut que des technologies Open Source, comme ça pas besoin de payer des licences", qui viennent d'ailleurs souvent des mêmes entreprises qui devraient le plus activement contribuer pour faire vivre ces projets.

2021 marquera sans doute le début d'une époque où la méfiance sera de mise. Peut-être pensera-t-on d'abord au modèle de financement et aux risques avant d'ouvrir nos travaux, et peut-être qu'on sera obligés de faire comme ça pour changer les mentalités. C'est dommage.

Et Mapbox dans tout ça ?

Ehh oui, car mapbox-gl-js (un des SDKs compatibles avec nos technologies) est passé récemment sous licence restreinte, et nombreux sont ceux qui nous ont demandé ce qu'on en pensait.

Si on regarde cela à travers le prisme du business : si Amazon et Facebook étaient en train de se saisir de nos technologies pour lancer leurs propres services sans rien contribuer, sans faire aucune démarche de collaboration financière, sur des compétences assez rares (Open GL) et sur lesquelles nous avons investi pendant des années... Ce type de décision aurait surement été envisagé.

Si on regarde cela à travers le prisme communautaire : l'analyse est différente. Sans OpenStreetMap et toute sa communauté de centaines de milliers de contributeurs, ni Mapbox ni les autres (nous y compris) n'aurions existé. Construire un business sur un écosystème Open Source (ou Open Data) est aussi une responsabilité envers cette communauté. N'oublions jamais nos racines.

En fermant ses SDKs, nombreuses sont les personnes qui ont senti que Mapbox leur avait fermé la porte en disant "maintenant, c'est à travers nous ou rien". Si cette manoeuvre a sans doute été faite pour se protéger, elle laisse de côté de nombreux acteurs qui payent le prix de ceux qui n'ont pas joué le jeu.

Selon moi, utiliser la même stratégie que les autres (le vendor-locking) est une erreur. Par contre, permettre aux acteurs de la communauté de pouvoir bénéficier des technologies sans conditions, de trouver des accords commerciaux raisonnables avec les entreprises, et se garder le droit d'exclure quiconque ne respecte pas cette charte serait bien plus efficace.

Juridiquement, personne ne doit rien à une communauté. Éthiquement, les personnes à l'origine de ce projet savent très bien ce qu'ils leur doivent : tout.

Le Roi est mort... vive le Roi ?

Qu'à cela ne tienne, ce changement a été l'occasion de rebattre les cartes et de réveiller en nous et en d'autres l'envie de s'investir ensemble. De cette volonté est né... Maplibre.

Maplibre est un fork de la dernière version libre de la librairie mapbox-gl-js, qui sera développé et maintenu par un consortium d'entreprises et de contributeurs dont nous faisons partie.

À suivre !

Le paysage de l'Open Source est voué à se transformer dans les années à venir. J'ai toujours en tête une phrase d'Olivier (un des fondateurs de Jawg Maps) qui m'a un jour dit "la chose la plus importante pour nous tous, c'est de savoir se réinventer".

On peut puiser dans ces quelques mots la sagesse que je souhaite à tous les acteurs du monde IT et des passionnés du libre, pour prendre en compte ces nouvelles manières de créer, car le monde change.

La meilleure nouvelle de tout ça, c'est qu'on pourra toujours compter sur ceux qui auront envie de tenter l'aventure. Peut-être de manière plus raisonnée, peut-être de manière un peu plus prudente, mais toujours avec autant d'engouement et d'envie de bien faire !

Longue vie à l'Open Source, et bonne année 2021 à tous

Loïc Ortola