L’open source est une façon de faire du développement logiciel qui est présente depuis déjà un bon moment. Cependant, il y a une tendance forte chez les entreprises à ouvrir le code de ses applications ou librairies afin d’y accepter les contributions.
Par exemple, dans le cas que je connais le mieux, il semble une bonne idée de penser à rendre accessible à tous le code d’une librairie développée pour les développements clients. Cette accessibilité du code permettrait à la communauté de participer à l’effort de développement ou de simplement réutiliser le module librement.
L’idée à la base est assez simple. Si le module en question connaît un bon succès à l’interne, pourquoi ne pas en faire profiter les autres? Vous avez probablement déjà eu une discussion au sujet dans votre organisation.
Souvent, une idée peut sembler intéressante jusqu’à ce que l’on s’intéresse aux petits détails ou que l’on soit à pieds joints dans l’expérience. C’est exactement ce qui arrive avec l’idée d’ouvrir le code d’un développement interne.
La vie d’un projet open source
D’ailleurs, je tiens à être clair. Je suis un très grand fan de l’open source. Mon propos est plus de mettre en éclairage que l’idée n’est pas systématiquement bonne. L’open source sans plan de match ne vaut pas grand-chose en soi.
Habituellement, le démarrage d’un projet open source va comme ceci:
- Un développement initial d’une librairie a lieu
- Le projet en tant que tel prend de la traction à l’interne
- Une pression à rendre à ouvrir le code a lieu
- Un compte Github ou Bitbucket est créé et le code y est téléchargé
- Les développements y ont lieu ou, du moins, une version y est téléchargée périodiquement
- Le projet gagne en visibilité
- Des demandes de support commencent à survenir
À partir de cet instant, l’organisation a quelques décisions à prendre.
- Investir du temps et de l’argent pour supporter les contributeurs et faire de la correction de bogues les utilisateurs. Principalement pour maintenir la réputation de la librairie et de l’entreprise.
- Distancer l’organisation du développement du projet open source.
- Ajouter une mention « à vos risques et périls » pour l’utilisation de la librairie.
La dernière option est vraiment contre-productive considérant que l’open source est avant tout à propos de la création d’une communauté autour du bout le logiciel en question. Si on se déresponsabilise du développement de la librairie et de son utilisation, pourquoi y ouvrir le code?
Ce qui doit être fait
Pour qu’un projet open source puisse avoir une viabilité, je crois que certaines conditions gagnantes doivent être combinées.
- Une feuille de route indiquant la direction que va prendre le projet.
- Des indications claires sur les contributions acceptées par les mainteneurs
- Accepter les contributions externes
Un bon exemple de ce genre de fonctionnements est le projet Rails. Très rapidement, à partir de la page d’accueil du projet sur Github, vous avez une description du projet et une documentation pour se lancer tête baissée dans le projet.
French Coding 