Open Source, standards et dette technique

Il y a vingt ans, Camptocamp était une entreprise pionnière dans l'adoption de l'Open Source. Aujourd'hui, l'Open Source est devenu un courant dominant et la grande majorité de l'industrie s'accorde sur les nombreux avantages de ses pratiques. De fait, le modèle Open Source est devenu un standard de facto dans certains domaines tels que le développement de frontends Web.

De nombreuses entreprises utilisent de plus en plus de logiciels Open Source dans leur infrastructure et leurs stacks de développement, et il existe de nombreuses raisons avérées de le faire, comme les formats standards ou la sécurité par l'ouverture, pour n'en citer que quelques-unes.

Malgré ces avantages, les entreprises qui contribuent ouvertement à l'Open Source — sans même parler d'open-source leurs propres projets— ne sont pas encore très courantes, et la plupart des entreprises considèrent l'Open Source comme un avantage uniquement pour les consommateurs.

Alors pourquoi contribuer à des logiciels Open Source ?

Pendant des années, j'ai pensé que le meilleur argument en faveur de la contribution à des projets existants était la maintenance et la compatibilité. Si je fais un fork d'un projet et que j'y ajoute des fonctionnalités, il y a un risque que mes changements deviennent de plus en plus difficiles à maintenir au fil du temps. Si les principaux développeurs du programme sont au courant de mes changements et ont l'intention de les suivre, ce risque sera considérablement réduit.

Ainsi, contribuer mes modifications garantit qu'elles resteront compatibles avec le code de base au fil du temps. Il pourrait même y avoir des améliorations à mon code si d'autres personnes rencontrent un besoin similaire à l'avenir et décident de construire sur la base de mes changements.

Aujourd'hui, cependant, je pense que l'exemple que je viens de donner est un cas spécifique d'une règle plus générale, qui englobe des raisons plus pragmatiques de contribuer du code en Open Source. Ce contexte plus général est lié au concept de dette technique : l'idée que les décisions techniques impliquent un coût caché (une "dette") qu'il faudra payer à l'avenir pour rattraper l'état de l'art de la technologie.

Comment minimiser la dette ?

La réduction de la dette technique est un sujet vaste —et parfois conflictuel. Cependant, je pense que l'on peut supposer qu'une façon de réduire ce risque est de s'en tenir aux standards. Plus un projet s'en tient aux standards industriels, moins il est probable qu'il doive être porté sur une autre stack technologique dans un avenir proche.

Et si les standards ne répondent pas à mes besoins ?

Face à une fonctionnalité manquante, le réflexe de la plupart des gens pourrait être de commencer à construire un composant spécifique pour répondre à leur cas d'utilisation. Pour reprendre les termes du théoricien de la stratégie Simon Wardley, ils déplaceront ce composant au stade de la genèse, ce qui le rendra plus imprévisible — voire erratique —, moins standard, et donc plus susceptible d'accumuler de la dette technique à terme.

Il existe cependant un autre moyen. Si mon besoin n'est pas satisfait, et qu'il s'agit réellement d'un besoin valide (ce qui est une question très importante à poser en premier lieu), alors d'autres personnes pourraient avoir ce besoin à l'avenir. Lorsque ce sera le cas, quelqu'un, quelque part, créera un nouveau standard pour ce besoin. Lorsque ce nouveau standard sera appliqué, la dette de mon composant spécifique deviendra évidente.

Et si, au lieu de construire un composant spécifique pour compenser l'absence de standard, je définissais moi-même le nouveau standard ? L'Open Source vous permet de faire exactement cela ! Il vous donne l'opportunité d'être le premier à fournir une implémentation ouverte à un besoin générique, et la chance d'en faire le nouveau standard. Si ce nouveau standard est adopté, vous n'avez pas seulement résolu votre problème, mais vous n'avez pas non plus accumulé de dette technique. En fait, vous êtes en avance sur les autres utilisateurs, car vous avez défini la nouvelle norme.

Mais on n'est pas des GAFA !

Il est évident que la majorité des entreprises ne peuvent pas se permettre d'avoir des ingénieurs qui se concentrent sur des RFC de l'IETF ou qui adaptent des normes ISO à leurs besoins.

Cependant, une norme ne doit pas nécessairement être aussi compliquée. Imaginons que j'utilise un outil en ligne de commande populaire, mais que je doive spécifier une option qui n'existe pas encore. Je pourrais bidouiller quelque chose autour de la génération de son fichier de configuration pour produire les options dont j'ai besoin. Je pourrais également patcher cet outil et ajouter une nouvelle option pour mes besoins, et contribuer à ce changement dans le projet. Il y a de fortes chances que si j'ai besoin de cette option, quelqu'un d'autre en ait besoin aussi.

Désormais, chaque fois que quelqu'un aura besoin de cette fonctionnalité, il utilisera ma nouvelle option. J'ai contribué à un nouveau standard, et je n'ai pas créé de dette technique de mon côté.

Ce n'est pas la taille des pas qui compte, c'est vraiment la direction dans laquelle vous les effectuez.

Où commencer ?

L'Open Source n'est pas qu'une philosophie. Elle englobe les questions de licence, les standards technologiques, la culture, et bien plus encore.

Chez Camptocamp, nous sommes engagés dans l'approche Open Source depuis des années.

Cela signifie que nous avons l'habitude de résoudre des problèmes en termes génériques et de créer de nouveaux standards.

Cela signifie également que nous avons des contacts dans de nombreuses communautés Open Source, ce qui nous permet de réfléchir à des idées et de contribuer rapidement à des projets, assurant ainsi une boucle de feedback rapide sur notre travail.

Lorsque nous mettons en œuvre des logiciels Open Source pour nos clients, nous cherchons activement à limiter la dette technologique. Parce que nous croyons en un monde de standards, nous ne voulons pas que nos clients se sentent complètement bloqués par une stack technologique à l'avenir. Ou même avec nous !