En janvier 2022, Marak Squires, un développeur désormais bien connu de la communauté Open Source, a fait parler de lui en sabotant volontairement deux de ses librairies JavaScript, faker.js et colors.js, utilisées par des millions de projets à travers le monde.
Son geste, radical et controversé, a mis en lumière une fragilité dans l'écosystème Open Source et la dépendance de nombreuses entreprises à des projets maintenus par des individus souvent bénévoles. Squires justifiait son action par le manque de reconnaissance et de soutien financier de la part des grandes entreprises qui profitaient de son travail sans contrepartie.
Cet épisode, loin d'être isolé, soulève une question cruciale pour les développeurs de logiciel libre : comment ne pas s’épuiser en bénévolat dès que notre travail commence à rencontrer un succès ? En d'autres termes: comment se faire rémunérer en tant que développeur Open Source ?
Se faire rémunérer en tant que développeur open source
Si les premiers hackers, étaient mus par une vision utopique d'un monde numérique partagé dont les contributions reposent sur la passion, aujourd'hui, le monde a changé.
En effet, à présent, les logiciels libres sont partout.
L'open source n'est plus l'apanage d'une poignée de passionnés, il est devenu un pilier de l'économie numérique.
Les géants du web, comme Google, Facebook ou Amazon, produisent et utilisent massivement des logiciels open source pour construire leurs empires tandis que d’autres entreprises de toutes tailles s'appuient sur ces briques logicielles libres pour développer leurs propres produits et services.
Mais … s'ils sont partout et en développement constant, qui finance ces développements ?
Et surtout … comment ?
Quelles solutions ?
Le support comme économie de service
Une solution souvent rencontrée est celle de la monétisation du support d’un projet.
Petit rappel utile : Un projet open source est toujours fourni “AS IS” et “WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND”
Partant de cette réalité légale, certains mainteneurs adoptent l’attitude suivante :
- Les bugs seront corrigés quand j’en aurai le temps et l’envie;
- Les features supplémentaires seront implémentées quand j’en aurai le temps et l’envie;
- Vous êtes autonomes pour installer mon logiciel;
- Si vous voulez une correction en priorité, une date de livraison pour une feature ou si vous avez un besoin impérieux de mon aide, veuillez prendre contact avec moi pour établir un contrat de service.
Les avantages :
En tant que leader de votre projet, vous êtes l’interlocuteur le plus compétent pour satisfaire le besoin de votre client.
De même, la plupart du temps, cela ne choquera personne que le tarif normalement classique soit majoré d’un certain pourcentage comme “soutien à l’open source” car finançant une ou deux journées pour la communauté.
Les inconvénients :
Si ce mode de fonctionnement est toujours populaire, on constate en pratique que les utilisateurs (même en tant qu’entreprise) privilégieront l’utilisation d’une solution concurrente voire d’abandonner la demande de fonctionnalité plutôt que de sortir le portefeuille.
L’exemple :
Le plus connu est celui de la société Red Hat qui partage certains de ses produits open source mais dont le support est payant.
L'entreprise propose également Red Hat Enterprise Linux (RHEL) avec un abonnement payant qui inclut un support technique, des mises à jour de sécurité, et des services de conseil.
Les dons
Pendant longtemps, le modèle dominant de financement des projets open source a été celui du don. Les utilisateurs, particuliers ou entreprises, pouvaient contribuer financièrement pour soutenir leurs projets préférés notamment via la plateforme “Buy me a Coffee”.
Les avantages :
Les dons, particulièrement les récurrents, vous permettent de financer l’équivalent de quelques heures par semaine dédiées à votre projet.
De plus, vous gardez la totale liberté d’organisation et de prioritisation de votre travail.
Les inconvénients :
En pratique, ce modèle, basé sur la générosité et la reconnaissance, est fragile et inégalitaire. Il dépend fortement de la popularité de votre projet, de votre capacité à vous faire connaître et à mobiliser une communauté de donateurs : des actions bien éloignées du développement technique pur.
Le dual licensing
Le dual licensing, ou double licence, est une stratégie où le même logiciel est proposé sous deux licences distinctes :
- une licence libre dite "contraignante" permettant une utilisation libre et obligeant la redistribution des versions modifiées du code source (classiquement une licence de type GPL)
- une licence libre dite "permissive" (telles que MIT ou Apache2) voire une licence commerciale permettant à des entreprises d’inclure une librairie (modifiée ou non) comme dépendance de leur projet.
Les avantages :
Cette approche permet de garder le caractère libre d’un projet pour le plus grand nombre tout en permettant au créateur de générer des revenus lorsque son projet est utilisé au sein d’un projet propriétaire et commercial.
Les inconvénients :
Cependant, elle ne conviendra pas à ceux qui estiment les licences de type GPL comme trop contraignantes pour la dissémination (et donc le succès) de leur projet.
Conclusion
Vous hésitez encore à vous faire rémunérer et si cela est en accord avec la philosophie du libre ? Rappelez vous que le logiciel libre n'est pas une ressource infinie et gratuite. Derrière chaque ligne de code se cache un individu qui a investi du temps, de l'énergie et des compétences : VOUS.
