Sommaire

Avant-propos

Ce journal est un partage d'expérience dont l'objectif est d'illustrer l'intérêt, même pour une petite société (ma société algoo, actuellement c'est 3 personnes en CDI, 1 CDD, 1 stagiaire) de produire du code libre et de contribuer au logiciel libre. Mais aussi pourquoi il est important de produire également du code propriétaire.

Introduction

Les lecteurs assidus de LinuxFR savent peut-être que j'ai créé une entreprise il y a désormais un peu plus d'un an.

Pour comprendre la suite de l'article, il faut juste savoir que le métier d'algoo (ma société) est :

de commercialiser le logiciel libre de partage/diffusion de connaissances Tracim

de développer sur mesure des applications web, des API REST et d'intégrer des services distants

d'intervenir sur des missions d'architecture ou des développements spécifiques backend/python

Algoo contribue au logiciel libre et produit autant de code libre que possible.

Pour résumer et reprendre les mots d'un personnage controversé de LinuxFR : "le logiciel libre est un moyen, pas une finalité".

Rappel : produire du libre a un coût

Donc Algoo produit du code libre. Et contribue aussi. Il faut bien comprendre que produire du code, remonter des bugs, etc, c'est bien gentil, mais cela a un coût.

Prenons un exemple simple : un ingénieur payé 36 456€ pour un contrat annuel 217 jours (c'est pas légal, car pour avoir un forfait jours il y a un niveau de rémunération minimum imposé par la convention Syntec. J'invite ceux d'entre vous qui gagnent moins de 40K€ et qui ont un contrat 217 ou 218 jours à lire leur convention collective).

Cet ingénieur travaille 1519h par an, il sera donc payé 24€ brut par heure de travail. A la louche, le coût du salaire est pour l'entreprise 36€/H. A cela on ajoutera les frais fixes : location de bureau, matériel, frais administratifs, etc.

Bref, produire du libre a un coût : le même que de produire du code propriétaire.

Rappel : aucune entreprise n'est philanthrope. Le but est d'une manière ou d'une autre de gagner de l'argent. Pas forcément "gagner le maximum d'argent possible", mais en gagner tout de même.

Donc si on produit du libre, il faut que ça en vaille le coup/coût. C'est le cas, et voici pourquoi.

Intérêts de produire du code libre ou de contribuer…

Marketing et visibilité

Si vous avez déjà passé des entretiens pour des postes de développeur, on a sûrement dû vous demander de montrer du code que vous auriez écrit. L'idée, c'est d'avoir une idée de ce qu'écrit le candidat, mais aussi de s'appuyer sur ce genre de contenu pour échanger sur les problématiques techniques. Ca n'est pas un problème d'écrire du code moche, du moment que ça peut se justifier (délais, prototype, etc).

Dans le cas d'une boîte, c'est un peu différent. Peu de clients vont venir discuter de code avec moi. Ceci étant dit, les clients techniques intéressés pourront aller chercher l'info et voir ce qu'on produit.

Cela apporte de la visibilité également, tant d'un point de vue prospection / image de marque en ligne, que d'un point de vue recrutement.

Ce sera également un argument commercial, genre "on partage certains développements, en contrepartie on bénéficie des développements d'autres sociétés". Bref, le discours classique qui prouve l'intérêt du logiciel libre et de la mutualisation des coûts de développement / maintenance entre confrères.

Produire du logiciel libre a un coût, c'est donc également un argument de qualité. Si on participe à des projets libres, c'est qu'on investit sur ces projets, et en général, l'investissement sur le code est lié à la qualité et au sérieux des prestations qu'on va fournir.

Si on vend des prestations de qualité médiocre, on va simplement exploiter le logiciel libre, par exemple en utilisant un maximum de logiciels libres parce qu'on les considère gratuits. Ce genre de comportement est très courant, notamment dans les agences web qui font du e-commerce (dév. de boutiques basées sur Magento, par exemple). Toutes les agences web qui proposent ce genre de prestation ne font pas du mauvais travail, mais alors comment distinguer "bonne agence" et "mauvaise agence" ?

Nous, nous utilisons des briques libres, et nous investissons dessus. On a une stratégie long terme, donc si une brique doit évoluer, autant qu'elle évolue dans un sens qui nous intéresse. Et pour ça, rien de mieux que de contribuer. Et comme une société a en général une philosophie "unique" (on n'a pas 2 manières de penser antinomiques en même temps), si on vise le long-terme d'un côté (fournisseurs), on vise long-terme de l'autre (client). C'est un gage de confiance et de pérennité de la relation.

Qualité de code

On n'y pense pas forcément, mais produire du logiciel libre permet d'améliorer la qualité du code. D'une part, si on publie du code qui intéresse d'autres personnes, on pourra s'attendre à avoir des feedback, des remontées de bugs, des propositions de patch. Le code va devenir meilleur.

Mais c'est également un moyen de mieux coder en interne. Sachant qu'on développe également du code propriétaire, on ne publie pas tout notre code en libre. Donc on doit faire une séparation. Qui dit séparation, dit modularité et interface. Rendre du code modulaire est une bonne pratique ; qu'on ne met pas naturellement en pratique quand on produit du code sur un unique projet.

Un exemple concret : nous travaillons actuellement sur un projet sur lequel nous devons être capable d'associer codes postaux et villes. C'est le genre de fonctionnalité récurrente. Le fait de décider de publier cette partie du code en libre :

nous force à bien modulariser nos développements

nous permet de réutiliser le cas échéant ce module de manière simple.

C'est une factorisation "de fait" ; donc un bug corrigé pour l'un des projets qui l'utilisera sera immédiatement disponible pour un autre projet. On n'invente rien dans cette démarche ; simplement le fait de publier nous force à modulariser le code et c'est une bonne chose.

Note : cet argument fonctionne car on produit du code libre et du code propriétaire.

Ressources Humaines

C'est un fait : les développeurs aiment participer à des logiciels libres, même les développeurs non passionnés/engagés dans la démarche du logiciel libre.

Produire du logiciel libre est donc un argument attrayant pour recruter, d'autant plus que cela sera également une carte de visite pour le développeur pour le jour où il souhaitera quitter l'entreprise. Il faut être lucide : tant que les intérêts recruteur/salarié sont compatibles il n'y a pas de raison de quitter une entreprise ou de licencier un salarié. Mais une entreprise et un salarié n'ont jamais "le même projet de vie" ou simplement les possibilités / envies d'aller dans la même direction. La fin de la collaboration fait partie de la vie d'une entreprise comme de la vie d'un salarié ; si on gagne à avoir collaboré et qu'on peut se séparer en bons termes, pourquoi ne pas le faire ?

Le fait de contribuer est également dans un certain nombre de cas une nouvelle expérience pour les développeurs car beaucoup d'entre eux "n'osent pas" (ou n'ont jamais été invités à le faire). En les incitant à contribuer, on leur apporte une nouvelle corde à leur arc, un nouveau type d'expérience. C'est en général bien perçu, et c'est donc une raison de plus d'avoir un collaborateur satisfait.

Dans une petite structure un turnover important est compliqué à gérer, car recruter prend du temps et gérer des recrutements/départs est générateur de stress négatif (ce stress n'ayant pas de valeur ajoutée sur la production de l'entreprise). Donc avoir des collaborateurs satisfaits est une bonne idée.

Philosophie d'entreprise

Produire du code libre et contribuer est également fortement lié à la philosophie de l'entreprise. La plupart du temps, on pourrait avoir quasiment le même résultat sans "perdre" la moindre minute à contribuer. Lorsqu'on contribue, comme évoqué précédemment, c'est qu'on investit. On est dans une démarche long-terme ; si on agit ainsi avec les briques qu'on utilise, c'est parce qu'on a une philosophie long-terme, ce qui est également le cas avec nos clients.

On a une démarche type "d'inbound marketing" : on donne pour recevoir.

Fait intelligemment, c'est bénéfique. On ne contribue pas à tous les projets/briques qu'on utilise, mais quand on fait face à un problème, on contribue (remontée de bug, proposition de patch), parce qu'un correctif upstream sera plus facile à maintenir qu'un fork dans notre coin. Et si d'autres personnes en profitent, alors tant mieux.

Intérêt de produire du code propriétaire

Mais il ne faut pas se voiler la face. Ce qui nous fait gagner de l'argent, ce qui fait que nous sommes en mesure de se payer des salaires, ce n'est pas la production de code libre.

Produire du libre, contribuer est un moyen de gagner de l'argent, mais c'est un moyen indirect. Ce qu'on vend, ce sont des services et des développements propriétaires. Rarement des développements libres. Ca arrive, mais ça ne suffit pas pour vivre.

Sur Tracim, par exemple, on va gagner de l'argent en proposant des développements sur mesure, des co-développements, des prestations d'hébergement et de service.

Sur les développements spécifiques ou sur mesure, on va gagner de l'argent en vendant des jours/homme de développement. Le code produit sera en règle général propriétaire et deviendra la propriété de nos clients.

Mais honnêtement, quelle société gagne majoritairement sa vie en produisant du code libre ? Aucune. Les gros contributeurs tels que Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier et leurs algorithmes. Ils contribuent énormément, mais ils ne partagent pas leur avantage concurrenciel.

Alors vous allez me parler de Red Hat. Red Hat est LA référence des entreprises qui gagnent de l'argent en faisant du libre. Et ils ont des développeurs, et non des moindres. Mais leur R&D est une petite partie de la R&D sur laquelle ils capitalisent : tous les logiciels libres qu'ils intègrent dans leur distribution ne sont pas faits chez Red Hat.

Et par ailleurs, ils gagnent de l'argent avec des contrats de service. A ma connaissance ce qu'ils facturent, ce n'est pas du "temps de développement de logiciel libre" mais des contrats de maintenance (qui intègrent dans leurs coûts, de la R&D sur du libre) sur une distribution Linux fournie, complète et robuste.

Une petite entreprise a les même problématiques de rentabilité et d'avantage concurrentiel. Il faut se dévoiler pour être "sexy", mais on ne peut pas tout dévoiler parce que sinon on perd notre différence, notre avantage.

Donc voilà : on fait aussi du code propriétaire, mais finalement comme tout le monde. C'est ce qui nous permet de gagner notre vie ; et il n'y a pas de honte à gagner sa vie:)

Conclusion

Produire du code libre présente des avantages et des inconvénients. D'une manière générale quand on discute avec des gens il faut argumenter pour justifier la production de code libre. Chez Algoo, j'essaie d'insuffler une philosophie inverse : pourquoi produire du code propriétaire par défaut ? Lorsqu'on peut produire du libre et contribuer, et que ça n'a pas d'impact sur la survie de l'entreprise, on produit en libre.

Comme vu ci-dessus, il y a des cas où cela se justifie, et des cas où l'on ne peut pas se le permettre.

Le risque de publier n'est pas que notre code soit réutilisé par des individus indépendants, des associations qui n'ont pas d'argent, ou des entreprises qui seraient "réglo". Non, le risque c'est plutôt de financer de la R&D qui sera directement réutilisable/réutilisée par des concurrents directs et peu scrupuleux. Le monde de l'entreprise n'est pas un monde de bisounours.

On peut en discuter, je suis preneur de vos retours, remarques, questions.