Pourquoi l’open-source ?

La solution Open Lowcode est le résultat de centaines de jours d’effort. J’ai décidé de le publier en open-source total (pas de freemium ou de doubles licences) et voici pourquoi.

Je ne suis pas un partisan naturel de l’économie collaborative. J’ai eu l’occasion de vérifier dans de nombreuses situations que l’argent est un meilleur arbitre que les alternatives telles que la politiques, les réseaux personnels, ou même la morale. Si je fais quelque chose qui a de la valeur pour quelqu’un, cette personne me paie, et je fais ce que je veux avec l’argent: c’est équilibré, honnête et pratique. Plus généralement, je pense que l’on ne réfléchis pas assez aux problèmes en termes économiques. Nous ferions mieux d’étudier l’histoire d’un point de vue économique que de gloser sur les maitresses des rois.

Pourquoi alors choisir l’open-source ? Certaines raisons sont liées à ma situation personnelle. J’ai développé l’outil “Open Lowcode” sur mon temps personnel en étant employé d’une grande enterprise, et j’ai utilisé ce logiciel à mon travail, ce qui m’a permis de le valider. Rendre “Open Lowcode” open-source était la solution la plus élégante de sortir de la zone grise légale dans laquelle je me trouvais sans que personne (ni mon employeur, ni moi) n’ait quoi que ce soit à payer. Cela me permet aussi de publier le logiciel sans quitter pour l’instant mon emploi.

Open Lowcode est une initiative modeste. Etre complètement libre est un différenciateur facile à mettre en place, et dans de nombreuses situations, cela peut faire la différence pour faciliter l’adoption. C’est d’autant plus le cas que l’on peut maintenant avoir une solution complètement open-source à l’exception de la couche applicative, qui représente souvent la majorité des coûts. OS et bases de données ont maintenant des solutions de référence.

Même si je n’étais pas un enthousiaste du logiciel libre, après plus de 20 ans en direction informatique, je suis maintenant convaincu que c’est la bonne solution dans la plupart des cas. D’abord, le logiciel ne coûtant rien à copier et distribuer, un utilisateur supplémentaire ne coûte rien. Si le logiciel est gratuit, un utilisateur supplémentaire qui se débrouille tout seul est complétement transparent. C’est différent d’une boulangerie qui offrirait des croissants gratuits aux étudiants, et qui pourrait se mettre en difficulté à cause de cela. Il y a de plus de nombreux inconvénients à rendre un logiciel commercial. Le coût des ventes est énorme, souvent beaucoup plus important que les investissements dans le produit. Au contraire, le logiciel libre se diffuse par le bouche à oreille. Et je ne suis pas sûr qu’il soit possible, pour un vendeur de logiciel, de gérer correctement la situation où ils bénéficient d’une rente de clients captifs. Presque toujours, cela veut dire, à des degrés divers, un produit limité et des coûts de license astronomiques.

Le logiciel libre est de meilleur qualité, et souvent de façon vraiment significative par rapport aux alternatives commerciales. C’est d’abord grâce à l’ouverture des sourrces: elle permet aux utilisateurs de trouver, et souvent de corriger eux-mêmes, les défauts. Une autre raison de cette qualité est le processus de décision. Un éditeur de logiciel n’est pas le meilleur endroit pour prendre des décisions de long-terme sur le produit: celles-ci seront affectées par des considérations politiques et marketing, parfois de court-terme. Le processus de décision sera presque toujours meilleur que l’instinct du développeur de l’application, surtout s’il a l’occasion de discuter directement avec ses utilisateurs.

L’open-source a aussi ses dangers: sans le modèle économique évident de la vente de licenses, il n’est pas facile de mettre en place une communauté durable pour maintenir l’outil dans le temps, c’est à dire une communauté où tous les contributeurs y trouvent leur compte. Le plaisir et l’égo peuvent parfois suffire, mais c’est improbable pour un logiciel d’entreprise qui a aussi ses composants nécessaires et ennuyeux. Il est évidemment possible de contribuer à l’outil sur son temps de travail, ce qui est fréquent. On peut en général développer une fonction manquante ou corriger une erreur en moins de temps qu’il n’en faudrait pour contacter le support d’un logiciel commercial.