Payer les mainteneurs open source est une bonne chose
(jacobian.org)- L’écosystème open source est utilisé par de nombreuses personnes et entreprises, mais il existe une contradiction : dès qu’un mainteneur gagne sa vie grâce à des fonctionnalités commerciales, un emploi dans une grande entreprise ou une levée de fonds, les critiques arrivent en premier
- Ici, open source est employé dans un sens plus large que les définitions strictes de l’OSI et de la FSF : si le code source peut être lu, modifié et redistribué sous une forme dérivée, cela inclut aussi Polyform, la licence JSON et la BSL
- La durabilité ne concerne pas seulement la gouvernance ou la santé de la communauté : elle désigne aussi la capacité des mainteneurs à vivre confortablement tout en couvrant leurs besoins de base comme le logement, la nourriture et les soins médicaux
- Django est utilisé chaque jour par des centaines de milliers de personnes, mais seules deux personnes sont rémunérées pour travailler directement sur Django lui-même : un Fellow à temps plein et un Fellow à temps partiel de la DSF ; Python est utilisé chaque jour par des millions de personnes, mais compte moins de 12 mainteneurs rémunérés
- Patreon, GitHub Sponsors, le VC, l’Open Core et les licences non OSI ont tous leurs défauts, mais si la colère vise les mainteneurs individuels, il devient difficile d’élargir la valeur sociale de l’open source
Pourquoi il est bon que les mainteneurs soient payés
- Le point de départ est que le fait que des mainteneurs open source soient payés n’est pas une exception, mais quelque chose à célébrer
- Plutôt que de blâmer les mainteneurs qui ont trouvé un moyen de gagner leur vie, il faut critiquer les structures et les systèmes qui rendent difficile le fait d’être rémunéré
- Les personnes qui veulent vivre de leur travail open source devraient pouvoir satisfaire leurs besoins de base et vivre confortablement
- L’open source est une collaboration bénéfique pour tous, avec l’idée sous-jacente qu’un monde sans open source serait bien pire qu’aujourd’hui
Open source au sens large et durabilité
- Open source et free software sont employés ici dans un sens large, et non selon les définitions strictes de l’OSI et de la FSF
- Il s’agit de logiciels dont le code source peut être lu, modifié et redistribué sous forme dérivée
- Cela inclut non seulement les licences OSI et FSF, mais aussi les licences Polyform, la licence JSON et la BSL
- Les définitions étroites comme « seules les licences approuvées par l’OSI sont open source » ou « seule la GPL est un vrai logiciel libre » sont vues comme une partie du problème
- L’expérimentation et la diversité des licences sont nécessaires ; même avec davantage de restrictions que « utilisable par n’importe qui, pour n’importe quel usage », un logiciel peut entrer dans la catégorie open source
- La durabilité désigne la possibilité, pour les mainteneurs, d’écrire du logiciel libre tout en menant une vie correcte ou confortable
- Le minimum consiste à couvrir les besoins de base comme le logement, la nourriture et les soins médicaux
- Idéalement, il devrait aussi être possible de vivre confortablement, voire luxueusement, uniquement grâce au travail open source
L’open source actuel n’est pas durable
- La part des personnes qui gagnent leur vie uniquement en écrivant du logiciel libre est, parmi l’ensemble des ingénieurs logiciel, pratiquement proche de zéro
- Des entreprises comme Canonical, Red Hat, Hashicorp ou Mozilla emploient des personnes travaillant sur l’open source, mais leur taille reste très faible comparée aux millions d’ingénieurs qui écrivent des logiciels propriétaires
- Tous les ingénieurs de ces organisations n’écrivent pas uniquement de l’open source, et beaucoup d’organisations reposent sur un modèle économique où une partie du produit est propriétaire
-
Les chiffres de Django et Python
- Des centaines de milliers d’ingénieurs utilisent Django chaque jour
- Les personnes rémunérées pour se consacrer à Django lui-même sont un Fellow à temps plein et un Fellow à temps partiel employés par la DSF, soit 1,5 personne
- Des millions de personnes utilisent Python chaque jour, mais moins de 12 personnes sont payées pour travailler sur Python
- Cela inclut les Developers-in-Residence de la PSF et quelques mainteneurs qui travaillent sur Python dans le cadre de leur emploi chez des entreprises comme Google ou Microsoft
- Dans une situation durable, Django devrait compter environ 12 personnes à temps plein rémunérées à un niveau proche de la médiane du secteur, et Python devrait en compter plusieurs dizaines
- À lui seul, PyPI nécessiterait au minimum une équipe de 10 à 15 personnes au vu de son périmètre, de son échelle et de son importance
- Même dans une situation où « une personne quelconque au Nebraska » maintient seule une dépendance essentielle, il faut des collègues pour que cette personne puisse bien vivre et partir en vacances ; c’est cela, la durabilité
L’idéal d’un soutien public et l’écart avec la réalité actuelle
- L’idéal serait que le logiciel libre soit reconnu comme un bien public et que la société et les gouvernements le financent de manière appropriée
- Cette vision suppose aussi de résoudre des problèmes comme la santé, l’accès au logement, les transports publics et les filets de sécurité sociale
- Mais ces changements n’arriveront pas immédiatement, et il n’est même pas certain qu’ils se produisent de notre vivant
- Dire « les gouvernements devraient financer cela, donc les entreprises privées ne devraient pas payer les mainteneurs » revient, tant que les gouvernements ne le font pas, à conclure que « les mainteneurs ne devraient pas être payés »
- Dans le monde actuel, il faut reconnaître que les mainteneurs ont besoin d’être rémunérés
Toute manière d’être payé est déjà une victoire
- Dans la réalité, la durabilité de l’open source signifie que de l’argent est effectivement versé aux mainteneurs
- Si un mainteneur a trouvé un moyen d’écrire du logiciel libre tout en payant son loyer, c’est déjà un exemple positif
- Les formes que peuvent prendre ces exemples positifs sont variées
- Être employé par Microsoft pour travailler sur Python
- Recevoir une subvention
- Atteindre un niveau de soutien durable sur Patreon
- Lever des fonds auprès de VC pour développer du logiciel libre
- Créer une entreprise durable avec un modèle Open Core
- Travailler dans une entreprise comme Hashicorp
- Financer un projet ouvert avec une option d’hébergement payante
- Utiliser avec succès une licence non approuvée par l’OSI pour éviter une exploitation à la Amazon
Les critiques récurrentes et leurs limites
- Chaque fois qu’un mainteneur est payé, des critiques liées au mode de financement apparaissent
- Les licences non OSI ne seraient pas open source
- Les personnes employées par Microsoft seraient soumises aux intérêts de l’entreprise et donc indignes de confiance
- Patreon serait de la mendicité
- GitHub Sponsors aiderait Microsoft à capter une rente
- Le financement VC mènerait à un rug pull ou à l’enshittification
- L’Open Core serait un bait and switch
- Un mainteneur dit même avoir été critiqué pour avoir vendu des t-shirts
- Chaque approche présente de vrais problèmes
- Le financement VC s’accompagne de conditions et peut entraîner des problèmes plus tard
- Patreon, GitHub et Stripe prélèvent une partie des dons
- Les restrictions supplémentaires de PolyForm ou de la BSL entrent en conflit avec l’idéal de la liberté 0
- Il peut être frustrant, dans un outil Open Core, de voir qu’une fonctionnalité essentielle que l’on souhaite n’est disponible que sous licence payante
- Ces systèmes peuvent être critiqués, mais attaquer le mainteneur individuel qui a reçu de l’argent, c’est diriger sa colère au mauvais endroit
- C’est comme crier sur quelqu’un parce qu’il a fait ses courses alors que le seul magasin accessible est Dollar General : le problème n’est pas l’individu, mais les structures et les politiques
Les exigences de pureté limitent la valeur sociale de l’open source
- Beaucoup plus de personnes devraient pouvoir écrire du logiciel libre tout en étant payées
- Pour cela, il faut accepter des modes de financement qui ne sont pas purs ou qui sont imparfaits
- Les mécanismes de financement et les inégalités sociales doivent continuer à être critiqués et transformés
- Lorsqu’un mainteneur trouve un moyen d’être payé, le célébrer est plus bénéfique pour l’ensemble de l’open source
1 commentaires
Avis sur Hacker News
J’ai du mal à accepter qu’on inclue dans la catégorie open source « ce qui n’est pas une licence approuvée par l’OSI »
Si elle n’est pas approuvée par l’OSI, c’est parce que la communauté l’a défini il y a longtemps et que, dans un sens toujours valable aujourd’hui, ce n’est pas de l’open source
Au-delà de ça, je ne suis pas convaincu par l’idée de considérer comme des victoires tout un ensemble de choses de nature très différente. Par exemple, « être employé par Microsoft pour travailler sur Python » peut, selon les détails du poste, relever davantage du piège que de la victoire ; voir https://ghuntley.com/fracture/
Tout l’article explique pourquoi il rejette volontairement la définition de l’OSI, et l’argument opposé semble simplement faire appel à la définition de l’OSI, qu’il rejette explicitement
Il précise qu’il emploie délibérément « open source » / « free software » en minuscules, non pas au sens de l’Open Source™ de l’OSI ou du Free Software™ de la FSF, mais dans un sens large : « logiciel dont le code source peut être lu, modifié et dont des versions modifiées peuvent être distribuées sous conditions »
Il dit donc inclure dans son propre « open source » non seulement les licences OSI/FSF, mais aussi Polyform, la JSON license et la BSL
J’ai plutôt l’impression qu’il propose de qualifier d’« open source » diverses formes de travail rémunéré
Par exemple, si RHEL reste open source, les programmeurs de Red Hat sont des développeurs open source salariés ; mais si RHEL est désormais un logiciel propriétaire, alors le nombre de personnes payées pour du travail open source diminue
La vraie question du débat est plutôt : « cette définition est-elle encore la plus pertinente aujourd’hui ? »
Elle l’est peut-être, mais interroger cette définition est en soi une question tout à fait légitime, et c’est ce que les gens semblent faire en ce moment
L’OSI n’approuve désormais une nouvelle licence que lorsqu’elle estime qu’elle comble un vide que les licences déjà approuvées par l’OSI ne couvrent pas ; il existe donc d’innombrables licences possibles qui satisfont à tous les critères de la définition sans être approuvées
[1] https://opensource.org/osd/
Il y a quelques semaines, j’ai écrit à un sénateur au sujet de l’absence totale, aux États-Unis, de soutien public aux ingénieurs indépendants et aux petits projets FOSS
NLNet, dans l’UE, est excellent, et les États-Unis auraient vraiment besoin de quelque chose du même genre
Cela dit, connaissant directement la mise en œuvre de projets de transport, et voyant l’énorme gaspillage qu’elle contient, je n’arrive pas à décider si ce type de soutien ne risquerait pas plutôt d’aggraver la situation
J’ai envie d’être d’accord et je comprends la position, mais dès qu’on utilise le mot « toujours », les nuances disparaissent
Si une entreprise finance quelqu’un pour travailler sur de l’open source tout en orientant le projet dans une direction contraire aux intérêts des autres utilisateurs, peut-on vraiment dire que c’est une bonne chose ? Je ne le pense pas
Je suis favorable au fait que les gens puissent gagner leur vie, mais le simple fait de produire du code source « relativement libre » ne suffit pas à rendre acceptables de mauvais comportements
L’idée centrale est de ne pas laisser le parfait faire obstacle au bien
Il faudrait œuvrer pour que toutes les personnes qui veulent travailler sur des bases de code open source reçoivent les financements publics qu’elles méritent, mais, en attendant, il faut aussi accepter la réalité où des entreprises financent une partie du code FLOSS
Dire que l’État devrait financer cela paraît souhaitable, mais si l’État ne le fait pas réellement, on peut finir par conclure que « les mainteneurs open source ne devraient pas être payés »
Si la communauté et les utilisateurs ne financent pas, des entreprises privées le feront, et elles auront alors leur mot à dire
L’open source ne doit pas devenir du « travail gratuit » externalisé dont les grandes entreprises se nourrissent
Le modèle freemium, comme dans l’écosystème WordPress, où l’on maintient une version gratuite GPL2+ tout en vendant des add-ons premium à télécharger, des licences de mise à jour et du support, est celui qui a le mieux fonctionné
L’open source ressemble à la politique : celui qui finance détient le pouvoir de décision. Si la communauté n’est pas économiquement autonome, les financements extérieurs détermineront la direction
Beaucoup de contributions open source sont admirables et dignes d’éloges, mais la journée, la plupart travaillent pour des entreprises privées qui cherchent à accroître leur part de marché et leur contrôle économique
D’une main, on contribue à l’open source ; de l’autre, le travail effectué dans une entreprise privée en annule en partie les effets
L’open source doit donc se financer lui-même et devenir une force économique et politique indépendante. Sinon, il restera toujours du côté de ceux qui subissent les règles, et devra continuer à lutter contre les tentatives du lobbying privé de l’affaiblir
En général, elles aboutissent à des livrables sur une période donnée, et l’open source passe alors du statut de hobby à plein temps à celui de métier
Il est peu probable que la direction dans laquelle une entreprise entraîne un projet soit bonne, mais on ne peut pas dire qu’elle soit toujours mauvaise
On peut aussi imaginer une situation où la direction voulue par l’entreprise intéresse beaucoup plus d’utilisateurs potentiels, tandis que la petite minorité d’utilisateurs existants peut forker le projet
C’est un bon contexte pour se rappeler l’Open Source Initiative et les origines de sa définition
En 2007, dans son propre historique, l’OSI expliquait avoir abandonné l’attitude moraliste et conflictuelle autrefois associée au « free software » pour vendre l’idée avec les arguments pratiques et business qui avaient convaincu Netscape, et avoir adopté le terme « open source » ainsi que la rhétorique pragmatique et favorable au marché développée par Raymond
Quelques décennies plus tard, il est un peu amusant de voir des utilisateurs de licences non approuvées par l’OSI, qui cherchent à empêcher l’exploitation par les grandes entreprises, se faire dénoncer de façon très moraliste au motif qu’ils ne feraient pas du « vrai open source »
http://web.archive.org/web/20071115150105/https://opensource...
Avec cette dernière, il est souvent impossible d’héberger un service utilisant du code sous licence BUSL, ce qui crée un risque business
Des questions suivent : faut-il consulter un avocat pour savoir si un cas d’usage donné est autorisé, comment savoir à quel moment on franchit la limite même si tout va bien aujourd’hui, est-ce lorsque le service génère du chiffre d’affaires ou seulement lorsqu’il est fourni directement à des clients ?
Dans une société organisée comme un cabinet de conseil, à la IBM ou Collins, où les services entre équipes internes font aussi l’objet d’une facturation interne, cela peut poser problème même si aucun client externe ne paie
Il n’est pas non plus clair si l’on peut embaucher des développeurs pour contribuer quand l’upstream ne répond pas aux bugs ou aux demandes de fonctionnalités, intégrer le code à l’infrastructure et aux outils internes, ou le mélanger librement à des projets plus vastes
Indépendamment de l’aspect moral de ces licences, le seul point de vue business suffit à expliquer pourquoi on peut les juger incompatibles avec l’OSI et donc, dans l’esprit aussi, non « open source »
La communauté dans laquelle je me suis le plus impliqué ces dernières années était R/tidyverse
Certains développeurs sont rémunérés par des organisations comme RStudio (désormais Posit) ou le R Consortium pour travailler sur le logiciel, la documentation et la communauté
Mon expérience comme programmeur dans ce domaine a été excellente. Quand il existe des contributeurs OSS financés à plein temps, des personnes avec un effet de levier énorme consacrent beaucoup de temps au projet, et des milliers de passionnés de R en bénéficient
Quand on utilise des bibliothèques comme les packages tidyverse, Shiny ou RMarkdown, la documentation est très bien organisée et les exemples sont à la fois simples et excellents
Il arrive souvent que l’intuition « ça doit marcher à peu près comme ça » soit immédiatement correcte, et il est fréquent que la fonction ou le package ait été conçu ainsi dès le départ
Il semble que la présence d’au moins une personne dédiée améliore fortement la qualité de l’OSS, peut-être parce qu’elle aide à coordonner des dizaines de petites contributions
Les projets open source accordent souvent moins d’attention à des domaines essentiels comme la documentation et l’expérience utilisateur. Même parmi mes projets OSS préférés, certains ont une expérience utilisateur épouvantable ; les contributeurs aiment ajouter des fonctionnalités, mais semblent moins enclins à les organiser en un package cohérent pour les utilisateurs ou à écarter les contributions inutiles et confuses
Par rapport aux communautés qui comptent très peu, voire aucun, contributeur OSS financé à plein temps, on trouve beaucoup plus de petites frictions et d’incohérences dans les bibliothèques, l’interopérabilité et surtout la documentation
La communauté R a été un exemple remarquable de l’énorme bénéfice à long terme que peut apporter à une communauté le fait de rémunérer des dizaines de personnes travaillant à plein temps sur l’OSS, et je suis reconnaissant de pouvoir me tenir sur les épaules de ces humbles géants
Je suis d’accord avec l’idée que « chaque fois qu’un mainteneur trouve un moyen d’être payé, c’est une victoire »
Cela devient plus courant, et il y a de nombreux exemples qui méritent d’être célébrés [0]
[0] https://fossfox.com/
Je fais des dons à plusieurs projets open source
Il y a des projets, comme le noyau Linux, qui semblent pouvoir s’en sortir sans mes dons, mais si je pensais qu’ils en avaient besoin, je donnerais sans hésiter
Pour les autres projets, je préférerais les voir échouer plutôt que compromettre la définition de l’open source. Pour moi, les deux reviennent au même
Je ne sais pas quand FOSS a commencé à être compris non plus comme « libre comme dans liberté d’expression », mais comme « gratuit comme dans bière gratuite »
Beaucoup de discussions sur la rémunération des développeurs semblent mélanger les deux
Open source signifie que la source est ouverte et que l’on a la liberté de la consulter et de la modifier, pas que le coût est de 0
Dans le code, vendre un produit logiciel tout en publiant librement le code n’est peut-être pas un modèle économique très réaliste, mais cela reste conforme à la définition de l’open source
La liberté de hacker et de modifier a toujours été indissociable d’un coût de licence de 0
Si les premières licences libres/ouvertes avaient autorisé l’accès au source et les modifications tout en facturant des frais de licence, ou si le FOSS des débuts avait permis l’usage gratuit mais interdit les modifications, il n’aurait pas eu le succès qu’il a aujourd’hui
Les deux libertés du « free software » ont toujours été liées
La liberté n’intéresse pas grand monde, mais le coût intéresse tout le monde
Même beaucoup de développeurs FOSS refusent d’être payés et rejettent ceux qui le sont. Pour eux, l’argent est une sorte de kryptonite
Je pense que cette philosophie, qui va à l’encontre de la règle très fondamentale selon laquelle tout doit être rémunéré, y compris le temps humain, est l’une des grandes raisons pour lesquelles le FOSS reste derrière les logiciels commerciaux et propriétaires/fermés
Comme les utilisateurs n’ont pas à investir, le projet peut s’étendre à un marché potentiel bien plus vaste que s’il était payant
Le fait que ce soit gratuit a quelque chose qui dérègle le jugement des gens
Dans une étude proposant du chocolat gratuit et du chocolat à 0,01 dollar, même lorsque le chocolat à 0,01 dollar était bien plus haut de gamme et offrait un meilleur rapport qualité-prix, l’option gratuite était beaucoup plus populaire
Beaucoup d’utilisateurs veulent simplement télécharger quelque chose, l’essayer quelques minutes, puis s’arrêter. Ou au moins pouvoir l’essayer et, dans le pire des cas, revenir à la version gratuite pour éviter d’avoir l’impression d’avoir fait un mauvais investissement
Cet article interprète la phrase « mais ce n’est quand même pas de l’open source » comme une critique de la distribution de logiciels sous diverses licences source-available
Certaines personnes l’entendent peut-être ainsi, mais pour moi il s’agit simplement de ne pas diluer un terme qui a un sens précis
Parfois, les licences source-available sont meilleures pour le business, et je comprends pourquoi les entreprises les choisissent
C’est une option moins généreuse, mais cela reste une bonne chose. De la même manière qu’on peut comprendre que tout logiciel ne publie pas son code source
Je pense que les organisations technologiques de type coopérative représentent l’avenir
Comme les gens ne veulent pas travailler gratuitement, les contributions aux logiciels open source seront forcément toujours à la traîne par rapport aux entreprises privées
Je me demande s’il existe des projets open source qui se monétisent afin de rémunérer les contributeurs
Si je finis un jour par créer une startup à succès, j’ai l’intention d’explorer ce modèle