Entretien

Vincent Picavet est un contributeur de longue date à l’écosystème de la géomatique libre et en particulier autour de QGIS (il est voting member de QGIS.org) et PostGIS. Il est par ailleurs président de la société Oslandia, qui rassemble de nombreux autres contributeurs à QGIS ou à d’autres outils SIG (Système d’Informations Géographiques) libres.

Nous vous partageons aujourd’hui sa vision sur les modèles économiques vertueux et les écosystèmes ouverts pérennes

Vincent, vois-tu des points à ajouter à cette présentation ?

J’ai commencé à m’intéresser à l’Open Source à l’époque de Debian Slink (1999, ndlr), mais je n’ai jamais été un gros contributeur en code. En revanche, je me suis beaucoup impliqué pour promouvoir l’esprit initial de l’Open Source de partage et de collaboration, et pour faire connaître les projets de SIG Open Source : comment les utiliser et aussi comment tirer parti de leurs spécificités pour aller plus loin que l’usage classique.

Au final, je pense que ma contribution majeure à l’Open Source est d’avoir co-fondé et de diriger Oslandia, qui regroupe des gens qui, eux, font des contributions techniques majeures aux outils Open Source tout en évoluant dans le cadre d’un modèle économique viable et conforme aux valeurs de l’Open Source.

Et aujourd’hui, c’est aussi ça que l’on souhaite contribuer à la communauté Open Source : un modèle économique, et plus globalement un modèle organisationnel d’entreprise. Pour l’heure, on a créé, conscientisé, explicité en interne et documenté ce modèle, et maintenant, on souhaite le partager avec l’extérieur pour que d’autres puissent s’en inspirer, comme on s’est inspiré de ce qu’ont partagé Red Hat ou GitLab par exemple.

Qu’est-ce qui vous a poussé initialement à documenter ce modèle ?

Cette documentation est importante pour nous par plusieurs aspects. D’abord, pour comprendre comment on fonctionne et avoir du feedback, afin de pouvoir évoluer en fonction du contexte. C’est également important en termes de valorisation de l’entreprise aux yeux des salariés. Souvent en interne, on a tendance à voir plus les points de friction, les points noirs et à oublier un peu ce qui fonctionne bien. Finalement, communiquer vers l’extérieur est souvent une bonne méthode pour rendre visible les aspects positifs en interne.

Ensuite, il y a la volonté de montrer et de prouver que ces modèles sont possibles. C’est une démarche sociétale, qui reflète à la fois des velléités individuelles mais portées également par l’entreprise ; et cela fait partie du rôle social de l’entreprise de continuer à diffuser ce modèle là.

Enfin, il y a aussi un intérêt économique : plus on parle des aspects organisationnels, plus les clients viennent nous voir pour avoir plus d’explications sur ces sujets, ce qui se concrétise par des prestations d’animation des équipes, etc. Il se trouve que c’est en totale cohérence et une sorte de prolongement naturel de ce que l’on fait déjà sur la partie SIG, pour laquelle on est rapidement confronté au modèle organisationnel des entreprises.

Tu pourrais expliciter ce lien ?

Les gens nous sollicitent d’abord comme experts techniques et nous exposent leur besoin en termes techniques, avec des éléments qui deviennent rapidement complexes. En se cantonnant à ce rôle, on pourrait répondre directement à leur besoin exprimé en leur livrant une solution également technique qui risque de vite ressembler à une « usine à gaz ». Par exemple, ils vont réclamer une synchronisation multimaster de bases de données, alors que dans 95% des cas la solution à apporter n’est pas technique mais organisationnelle.

Il faut donc remonter au niveau organisationnel de l’entreprise, via les questions de cycle de vie de la donnée, de responsabilité de la donnée, du modèle organisationnel, en prenant en filigrane la donnée. Une fois ces questions organisationnelles résolues et le nouveau besoin fonctionnel identifié, la réponse technique est le plus souvent beaucoup plus simple.

On faisait ainsi déjà un peu de conseil organisationnel en lien avec l’activité de SIG ; on faisait aussi du conseil organisationnel par rapport au modèle de développement Open Source et à l’inner source. Le conseil sur le mode d’organisation de l’entreprise vient donc former un tout cohérent, qui aujourd’hui a une valeur sur le marché en tant qu’offre de service.

Votre activité et notamment la gestion du cycle de la donnée a donc été l’amorce de votre réflexion quant au fonctionnement interne d’Oslandia ?

Ça a plutôt été la convergence de plusieurs éléments vers un tout complètement cohérent. Il y a d’abord, effectivement, le métier que l’on fait : en travaillant sur les bases de données et la gestion de la donnée, on en vient à travailler sur l’organisationnel, comme je le disais. C’est le besoin historique auquel répond Oslandia. Ensuite, on a recruté des gens sur leurs compétences et pas sur leur localisation géographique, ce qui a amené le télétravail comme un élément essentiel de notre fonctionnement. Et enfin, il y a le conseil que l’on fournit sur la structuration de modèle de développement Open Source.

Ces trois éléments ont fusionné pour aboutir à la réflexion organisationnelle venant redéfinir le fonctionnement interne de l’entreprise, que ce soit la partie RH, l’organisation du temps de travail, etc.

Tu parles d’une position d’éditeur, alors que vous êtes positionnés sur des projets qui ont une authentique gouvernance communautaire. C’est quoi la position d’éditeur au sein d’un projet à gouvernance communautaire ?

Historiquement, avant de pouvoir se positionner en tant qu’éditeur, on a collaboré sur de nombreux projets Open Source. Une notion qui revient souvent est celle de la coopétition. On travaille en collaboration avec d’autres entreprises sur des projets Open Source ou des projets client, alors que par ailleurs sur le marché on est en concurrence directe avec elles sur des appels d’offres. On a toujours réussi à le faire de façon assez naturelle dans le monde des SIG Open Source et cela a sans doute été facilité par le fait que le marché est en croissance et suffisamment large.

Dans le cadre d’un projet communautaire, c’est un peu la notion de co-éditeur. Il y a deux aspects à concilier, qui peuvent devenir facilement antagonistes : le positionnement et le discours vis-à-vis des clients, du marché d’une part ; et l’approche vis-à-vis la communauté d’autre part. Il faut trouver un équilibre pour avoir un positionnement de marché qui favorise la réussit de l’entreprise et un positionnement par rapport à la communauté qui fasse que l’on en reste un bon citoyen du libre. Cet équilibre est difficile à trouver mais indispensable.

Sur QGIS, qui est un des projets sur lesquels on se positionne en tant qu’éditeur, on peut estimer qu’il y a une dizaine de sociétés dans le monde qui peuvent revendiquer ce statut de co-éditeurs, avec des contributeurs majeurs et des core committers.

Cette pluralité, c’est aussi ce que l’on vend à nos clients : un des arguments de vente de l’Open Source est l’absence de vendor lock-in. Aussi, si on reproduit avec une position d’éditeur dominant et unique cette situation de vendor lock-in, on perd l’avantage par rapport à nos concurrents propriétaires. On a donc intérêt, en tant qu’éditeur, à conserver un écosystème concurrentiel : il faut trouver un équilibre entre la part de marché que l’on veut prendre et la part de marché que l’on est obligé de laisser à nos concurrents pour que nos arguments de vente Open Source soient pertinents.
En gardant un système concurrentiel global et équilibré, dans lequel on peut être leader, ou du moins où l’on possède une part de marché suffisante pour évoluer, on évite cette problématique. On a une meilleure solidité de l’écosystème et cette solidité nous porte ; en tant que prestataire/éditeur de logiciel libre, notre croissance repose sur la croissance de l’écosystème. Ainsi, si l’on fait croître l’écosystème, notre marché croît naturellement. Ensuite, on peut développer notre activité pour croître au-delà, mais pour cela il faut d’abord maintenir l’écosystème.

Si on a choisi de se positionner en tant qu’éditeur QGIS, c’est parce que dans la partie SIG, on a une bascule de la typologie des clients, qui étaient historiquement plutôt des collectivités et qui maintenant sont plutôt des grands comptes, pour qui il est nécessaire d’avoir un interlocuteur du type éditeur : pour avoir de la maintenance et une garantie de pouvoir mettre des solutions en production pour des milliers d’utilisateurs ; mais également d’avoir un interlocuteur vers lequel se retourner en cas de problème. Le passage à la notion d’éditeur, c’est un peu prioriser la garantie logicielle (maintenance) par rapport à l’ajout de fonctionnalités.

Cela correspond au stade de maturité du projet QGIS. En termes fonctionnels, il n’y a pas aujourd’hui d’évolutions majeures manquantes : concernant QGIS Desktop, et même QGIS serveur, on a une maturité qui nous permet de rentrer en compétition avec les gros du secteur. Par contre, au niveau de la suite applicative, il y a des choses qui font encore défaut, comme l’application builder qui existe chez ESRI, qui permet de générer de l’applicatif assez facilement ; mais cela ne correspond à un besoin que pour 10 à 20 % des utilisateurs de la techno.

Donc au final on a une solution libre adaptée pour plus de la moité des utilisateurs de solutions propriétaires. Par contre, en termes de confiance dans le logiciel, de maintenance et de ce que les clients peuvent attendre d’un outils qu’ils vont mettre en production à grande échelle, il y a encore des efforts à faire, notamment sur la personnalisation, l’intégration dans le SI, les déploiements automatisés, la qualité des mises à jour, l’absence de régression.
La qualité est un point sur lequel Oslandia s’est très tôt positionné et a orienté le projet QGIS, et aujourd’hui on veut le promouvoir et le vendre, notamment au travers de notre offre éditeur et de la maintenance logicielle. Cela présente aussi l’intérêt d’avoir du budget récurrent pour financer des aspects du projets qui sont difficiles à financer par ailleurs (correction de bugs, infrastructure de test auto/CI).

Actuellement, financer des fonctionnalités, c’est relativement facile : les clients sont prêts à payer pour cela. Financer de la maintenance globale, c’est plus complexe à faire sur du one-shot, donc on cherche un modèle pour ça, et le modèle d’éditeur OpenSource le permet.

En ce qui concerne la mutualisation des travaux de fond, comment un projet comme QGIS s’organise-t-il ?

Cela se fait d’abord au niveau communautaire. Il y a une association de droit suisse QGIS.org, qui fournit la structure nécessaire à l’avancée du projet. Elle a désormais des membres soutien, qui paient jusqu’à plusieurs milliers d’euros annuel. Elle bénéficie d’un budget d’environ 100k€/an, entièrement investi dans le projet sous diverses formes :

• des appels à projets ou développements pour des choses de plus en plus orientées refactoring, infrastructure, maintenance; soit autant de sujets difficilement finançables par des clients. Il s’agit surtout de financer des travaux préliminaires, ce qui permettra ensuite d’aller chercher des financements tiers ;
• du bug fix à chaque release ;
• des financements spécifiques d’actions liées à la maintenance, l’infrastructure ou la documentation.

C’est aussi une dimension que l’on pousse au niveau français, au travers de l’association OSGeo-FR et d’un chapitre QGIS.org francophone en cours de création.

En tant qu’Oslandia, on fait pour le moment plutôt de la mutualisation pour le développement de fonctionnalités. Le modèle pour la maintenance est celui de l’abonnement avec des conditions de garantie classiques, que l’on commence tout juste à vendre.

Un élément intéressant dans le fonctionnement du projet QGIS est la mention dans les notes de sortie à la fois du commanditaire de chaque fonctionnalité et des personnes qui l’ont réalisée techniquement.

Oui, c’est un élément important du cercle vertueux : cela permet de donner de la visibilité et d’améliorer l’image de marque à la fois du projet, des clients et des développeurs. C’est d’ailleurs quelque chose que l’on explique lors de notre avant-vente. On mentionne que le financement dans le cœur permet de réduire les coûts de maintenance, mais aussi que c’est un élément possible de communication, ainsi qu’une manière de gagner en notoriété et en crédibilité auprès de la communauté. Cela permet par la suite d’améliorer les relations avec le projet et d’avoir une meilleure prise en compte par elle d’un besoin spécifique ou atypique à un moment. L’image de marque est très importante dans un contexte Open Source.

C’est vrai également pour nous à Oslandia : notre image auprès de la communauté nous permet d’être plus efficace dans nos échanges avec celle-ci. C’est une valeur inestimable car c’est sur elle que se fonde ce qui va faire la différence en termes de qualité de service par rapport à ce que peuvent proposer nos concurrents.
La marque Oslandia est également précieuse pour nos clients au regard de la communauté. C’est pourquoi il faut donner autant de visibilité à ceux qui font qu’à ceux qui financent. On a vraiment travaillé sur cette dimension au sein de la communauté QGIS, et aujourd’hui QGIS.org favorise cette approche. C’est vraiment un cercle vertueux qui bénéficie à toutes les parties prenantes. Par exemple, récemment, une réalisation d’Oslandia financée par Orange était mise en avant sur le site de QGIS.org. Ça soigne l’image d’Orange au sein de la communauté, mais cela joue également pour Oslandia en termes d’avant-vente : des futurs clients vont venir nous solliciter sur la base de cette publicité, on les renvoie vers Orange pour qu’ils détaillent la réalisation en question, et dans le même temps ils font notre promotion, les futurs clients reviennent ainsi vers nous avec un marché à la clé. Nos clients qui parlent de nous, c’est vraiment l’atout le plus efficace en avant-vente.

Après, il existe des cas particuliers où les financeurs ne veulent pas être cités, pour diverses raisons, mais cela reste peu courant.

Le modèle de l’écosystème QGIS est-il transposable à d’autre projets ?

Oui, en théorie il n’y a pas de raison que cela ne le soit pas. La principale difficulté, dans les projets Open Source à succès et en croissance, c’est de suivre la continuité du projet. À des moments donnés il faut faire des choix, et même dans le projet QGIS il y a des tensions internes notamment entre les contributeurs initiaux de QGIS, qui contribuaient en tant que hobby, et les professionnels actuels, qui ne veulent notamment pas avoir à travailler le week-end. Chez Oslandia nous sommes de ce côté là, pour être cohérents avec le modèle sociétal que l’on promeut : on ne veut pas que les gens qui travaillent chez nous passent la semaine à travailler sur des projets client et le week-end à faire des revues de code sur QGIS.

Pour en revenir au sujet de la transposition du modèle de QGIS à d’autres projets, je dirais qu’on ne peut pas répliquer le fonctionnement actuel du projet QGIS à un autre projet qui serait dans une phase de maturation différente ou empreint d’une philosophie différente. En effet, l’évolution d’un projet est dictée par son écosystème. Parfois certains acteurs peuvent se retrouver en déphasage par rapport à l’évolution du projet, ou au changement de l’écosystème. Il faut alors gérer ces dissensions pour continuer à avancer.

De l’extérieur, on a l’impression que le succès de QGIS est en partie dû à l’écosystème dans lequel il s’inscrit et notamment les standards ouverts qui le structurent.

Si on prend un peu de recul par rapport au projet QGIS, on voit qu’au-dessus, il y a l’OSGeo International, qui a un rôle fondamental depuis 2004 et la création d’une fondation pour promouvoir les projets SIG libres, dont QGIS n’est qu’une partie. L’OSGeo a fait beaucoup d’efforts pour assurer la pérennité des projets en leur fournissant un cadre de développement adapté ; tant au niveau de l’infrastructure – même si cet aspect est moins important aujourd’hui avec les plates-formes comme Github ou Gitlab – que de la méthodologie. Pour être accepté au sein d’OSGeo, un projet doit passer une période d’incubation, respecter des critères de gouvernance, qui comprend un PSC (Project Steering Committee, ndlr) avec une diversité d’acteurs à l’intérieur de celui-ci, tout un ensemble d’éléments, qui constituent au final une culture de gestion de projet Open Source ; et cette culture joue le rôle d’un standard pour les modes de fonctionnement.

Concernant les standards d’interopérabilité technique, ils sont très nombreux dans le SIG, que ce soit ceux de l’ISO, du W3C ou de l’OGC (Open Geospatial Consortium, ndlr). Ces standards ouverts jouent un rôle capital car ils ont permis et permettent encore aux logiciels libres de rentrer dans des marchés et des infrastructures existantes. Mais, s’il est utile pour l’Open Source de pouvoir s’appuyer sur ces standards, réciproquement, les organismes de standardisation trouvent intéressant d’avoir des implémentations de références accessibles et ouvertes. Cette synergie se trouve formalisée par le memorandum of understanding entre l’OSGeo et l’OGC. Même s’il y a pu avoir des divergences de vue techniques entre l’OGC et des projets OpenSource, l’OSGeo est très investie dans l’OGC, ce qui est à souligner quand on sait que l’OGC a à l’origine une culture industrielle, d’un groupe fermé de gros acteurs qui décident des orientations qui les arrangent. Il y a eu de leur part une prise de conscience de la nécessité de l’ouverture dans la rédaction des standards pour qu’ils ne se retrouvent pas bousculés par des solutions qui leur échappent et qui soient plus efficaces.

Aujourd’hui il y a un mouvement de convergence entre les acteurs. En tout cas c’est une force de l’Open Source que de pouvoir implémenter des standards, et ainsi continuer à échapper aux problématiques de vendor lock-in.

Quel est l’impact de la vague de l’Open Data sur le SIG en général et le SIG Open Source en particulier ?

Le projet Open Data le plus important pour nous en matière de SIG, c’est OpenStreetMap, qui pré-date le mouvement Open Data très institutionnalisé tel que l’on connaît aujourd’hui. C’est un projet remarquable et d’une ampleur gigantesque. Mais, paradoxalement, la communauté OSM me semble toujours très complexe et d’un abord parfois rugueux : on y rencontre beaucoup d’égos et des acteurs qui semblent plus attachés à leurs intérêts privés qu’au bien commun.

Techniquement, c’est un projet qui a un impact très fort et on l’intègre au quotidien dans nos travaux (fond de carte, traitement de données). Il y a des outils qui sont arrivés en Open Source parce qu’OSM les a popularisés ; mais comme ils ont été développés totalement en dehors de l’OSGeo et de sa culture de gouvernance dont on parlait précédemment, ils rencontrent parfois des problèmes de maintenance et de pérennité.

Et votre avis sur ses liens avec l’Open Source ?

Quand on a vu arriver le mouvement Open Data, après OpenStreetMap, on a constaté – avec un peu d’amusement – qu’ils se posaient les mêmes questions que l’on s’était posées quinze ans auparavant : sur les licences, etc. On retrouvait les mêmes problématiques, mais avec des acteurs différents. De fait, l’Open Source a pu apporter des solutions à l’Open Data, même s’il ne faut pas occulter le fait que le monde de la donnée a des spécificités qui interdisent une transposition directe des leçons et fonctionnement de l’Open Source : typiquement, certaines problématiques de licences sont sans doute plus complexes que dans le cas de l’Open Source (OpenStreetMap et l’OdbL en sont une très belle illustration), avec des zones grises encore énormes, alors que dans le logiciel les zones grises sont maintenant assez limitées. Les liens avec la politique et les institutions sont aussi très complexes, alors que la question se posait beaucoup moins dans le monde du logiciel Open Source, parce qu’il n’y avait pas jusqu’ici la notion de souveraineté telle qu’on peut la retrouver avec la donnée. Même si ces problématique apparaissent aujourd’hui aussi dans l’Open Source.

Donc l’Open Source a pu servir, dans une certaine mesure, de modèle ou du moins de point de repère pour l’Open Data, et réciproquement l’Open Data, notamment sur la partie SIG, contribue à promouvoir l’Open Source, car une fois qu’un acteur est sensibilisé au principe de l’Open Data, il l’est aussi aux enjeux de l’Open Source et aura plus naturellement tendance à chercher des solutions Open Source pour mettre en œuvre sa politique Open Data.

Avez-vous constaté un impact de l’évolution réglementaire au niveau français (loi Lemaire) ou européen (directives Inspire, PSI / Open Data) ?

La directive Inspire a clairement eu une influence, car elle concerne la donnée SIG qui est notre cœur de métier. Elle s’inscrit dans une dynamique plus globale au niveau européen en faveur du logiciel libre et surtout de l’interopérabilité, ce qui favorise globalement la dynamique vertueuse entre Open Data et Open Source. Cela influe notre activité sur plusieurs aspects : roadmap, financements, besoins, et surtout les cercles vertueux que l’on s’efforce de développer.
Concernant les autres textes, l’influence est moindre. La loi Lemaire a des effets, mais pas directs : elle développe surtout la culture open dans le milieu, ce qui nous bénéficie au final.

Actuellement, vous êtes 17 chez Oslandia. A terme, avez-vous un objectif de croissance ?

Il y a des paliers dans la croissance d’une entreprise. Je suis convaincu que notre modèle organisationnel actuel passe facilement à l’échelle jusqu’à 25/30 collaborateurs ; à 25, on aurait un plus un grand confort en termes de rentabilité, car un meilleur rapport production/coûts fixes. C’est donc notre objectif à court/moyen terme : pas 2020, mais 2021. Pour le moment nous sommes complètement indépendants, on a une croissance purement interne.

J’ai aussi une vision très organique de l’écosystème Open Source, donc ce que j’envisage, ce n’est pas la croissance d’une entreprise monolithique sur un sujet dédié, mais plus des spin-off, un ensemble d’entreprises, je ne sais pas quelle forme cela pourra prendre, mais l’objectif est de garder l’agilité qu’on peut avoir aujourd’hui, tout en continuant à croître en termes de parts de marché ou de types de prestations que l’on peut fournir ou de types de logiciels aussi.
Je ne peux pas dire exactement quel modèle permettra de faire ça, mais ce qui est sûr c’est que l’on va éviter de devenir une boîte pyramidale et monolithique de 300 personnes, même si on en avait les moyens car ce serait en partie renier les valeurs que l’on a aujourd’hui.

En termes de recrutement : est-ce facile ?

Étrangement, on n’a pas tant de problème de recrutement que ça. Aujourd’hui, si on a du mal à trouver des gens, c’est parce que l’on a encore élevé nos standards pour les candidats, pas tant au niveau technique qu’au niveau humain/savoir-être et adéquation à notre modèle d’entreprise. Et comme on n’est pas contraints par le temps, on préfère prendre le temps de trouver les bonnes personnes.

On a complètement refondu notre processus de recrutement au début 2019 : il est plus carré, plus complet ; on s’est fait accompagner pour aller chercher les bons outils qui permettent de faire l’analyse. J’ai toujours recruté au ressenti et à la compétence technique : je ne regrette aucune décision mais le process restait largement améliorable. Aujourd’hui on a pas trop de difficulté à trouver des personnes car on a une originalité dans notre positionnement et aussi une réflexion sur le modèle organisationnel, le sens, les valeurs, et ça parle à des profils de personnes qui sont en général sensibles à l’Open Source et très douées techniquement.

Notre cohérence entre ce que l’on fait et comment on le fait a une grande valeur aujourd’hui dans le processus de recrutement. Le fait de l’expliciter en amont nous confère également une marque employeur qui facilite énormément la phase de recrutement. On commence à en voir les premiers retours actuellement : pour un poste on a eu 15 candidatures, j’ai mené 7 entretiens et les 7 étaient des gens vraiment intéressants. Cela nous permet également d’affiner nos recherches. On a fait 2 recrutements en septembre, 3 semaines après on avait notre séminaire d’entreprise, à l’issue duquel des membres avaient l’impression que ces recrues étaient là depuis toujours. C’est la preuve que notre process de recrutement est utile, efficace, et que la visibilisation de notre positionnement est une grosse valeur ajoutée.

Récemment et pour la première fois, on a recruté un développeur junior, et on pense que c’est une bonne chose et qu’il faudra renouveler, afin de les former, de les acculturer, et qu’on puisse prévoir à l’avance ce qu’ils seront une fois senior, qu’ils soient la version idéale d’eux-mêmes pour l’entreprise. Avant on ne pouvait pas faire ça pour des raisons économiques, de distance et de maturité du modèle qui rendait compliqué la formation de recrues. Aujourd’hui on a plus de souplesse et moins de risque du fait de la taille de l’équipe et de l’équilibrage que cela permet.

Sur l’Open Source en général, quelles sont les selon toi les tendances majeures ?

J’observe aujourd’hui un double-mouvement : d’une part un risque informatique accru, car il y a une dépendance de plus en plus grande de notre société au numérique – et l’Open Source n’est pas étanche à ce risque ; mais d’autre part on a une prise de conscience de ces risques (faille open SSL, etc.). Il y a des efforts au niveau européen en cours de structuration, création de fondations de gros industriels, qui permettent de limiter les risques en passant par la consolidation des logiciels libres. Est-ce que ce sera suffisant ? Je ne sais pas.

Évidemment force est de constater aussi le côté rouleau-compresseur des GAFAM. Concernant la captation de valeur qui peut être faite par ces gros acteurs, cela rejoint ma réflexion plus globale sur le niveau d’implication politique de l’Open Source : le problème de captation ne peut pas être réduit à un problème de licence, mais pose plutôt celui de la simple existence d’Amazon par exemple. Je n’ai pas de solution à proposer et n’ai pas de parti-pris, mais il faut se demander si les problématiques considérées comme propres à l’Open Source ne sont en fait plus larges, et comment le monde Open Source va avoir tendance soit à se refermer sur lui-même, soit à s’étendre de manière fédérée sur des sujets qui dépassent l’informatique. En ce sens l’exemple de la Quadrature du net est parlant : de problèmes vraiment propres à l’informatique, voire au logiciel Libre, ils sont arrivés à être fer de lance sur des sujets de société.

Ton avis sur le mouvement de migration vers des licences plus vraiment Open Source ? (MongoDB SSPL/ Business Source Licence)? Et sur l’autre mouvement qui produit des licences non-Open Source, le retour de l' »Ethical Source » (Hippocratic License)?

Le premier mouvement est pour moi une conséquence de l’arrivée de la finance mondialisée et des Venture Capitalists dans le monde de l’Open Source, avec une volonté de monétiser des choses à coup d’arguments juridiques, ce qui va à l’encontre de la philosophie Open Source. Pour ma part je garde une vision assez stricte du libre et des 4 libertés fondamentales. On peut faire ce que l’on veut en dehors, mais alors il ne faut pas appeler ça Open Source et encore moins logiciel libre. C’est une mauvaise réponse à un mauvais problème. Le problème est ailleurs, et tenter de le résoudre ainsi aura des dégâts collatéraux importants et qu’on ne maîtrise pas.

Idem pour les licences éthiques, le problème n’est pas sur la licence mais sur ce que l’on définit comme éthique, domaine dans lequel le consensus est impossible. Ça reste un bon instrument pour faire prendre conscience et transformer la culture, mais ça ne peut pas être un objectif en soi tel quel. Je trouve plus intéressant le projet de Contrat Mainteneurs, car il permet d’acquérir de la valeur sans dénaturer l’Open Source. Mais je ne sais pas si ce mécanisme sera suffisant pour faire émerger un modèle économique pérenne et stable face aux géants pré-cités.

Photos by Kevin Ku , Patrick Tomasso ,Richard Balog , Adeolu Eletu , chuttersnap, John Salvino , Simon Maage , Sebastian Pichler, Francesco Gallarotti , Cytonn Photography on Unsplash