Quand on parle d’open source, c’est beaucoup pour parler des licences et un peu du code, mais beaucoup moins souvent des participants, et encore moins des participantes.
Les licences ouvertes donnent le droit aux utilisateurs de modifier les logiciels qu’ils utilisent. Pour que les changements effectués profitent à un maximum de personnes, il faut éviter que chacun ne travaille dans son coin, mais que les évolutions se fassent de manière collaborative et s’additionnent et fassent ainsi progresser le logiciel.
À l’opposé des logiciels fermés créés par des entreprises de manière la plus souvent pyramidale, l’idéal-type du projet open source est développé par une communauté de contributeurs qui, tous, apportent leur pierre à l’édifice et sont autorisés à donner leur avis.
Dans la réalité, les modèles de développement et donc les communautés diffèrent beaucoup d’un projet à l’autre : des projets au fonctionnement opaque mais à licence ouverte jusqu’à ceux qui sont très ouverts et font tout pour accueillir de nouveaux membres.
Ces différences, peu visibles aux non-initiés, sont très importantes pour se faire un avis sur un projet :
-
comme le label “open source” a une valeur d’affichage, connaître le fonctionnement du projet permet de juger s’il est légitime pour profiter de ce label ;
-
pour choisir un projet plutôt qu’un autre lorsqu’on cherche un logiciel, que ce soit pour des raisons éthiques ou pour savoir si on peut compter sur le support de la communauté en cas de problème ;
-
lorsqu’on a envie de contribuer à un projet qui semble intéressant ou enrichissant d’un point de vue technique, il sera plus agréable d’échanger avec une communauté qui a un bon état d’esprit ;
Si chaque projet open source a ses spécificités, il est possible de les classer dans quatre familles :
Le dépôt de code
Les projets “à sens unique” ou le développement est fermé et où l’on peut simplement télécharger le code. Souvent ce code n’est pas utilisable directement car il est incomplet et/ou manque de documentation.
3 cas principaux :
Les minis projets perso
Les petits projets où une personne a développé un outil pour elle et se dit qu’il pourrait servir à d’autres. Elle est prête à le rendre accessible mais pas à fournir d’effort supplémentaire. C’est une manière tout à fait légitime de faire de l’open source : il s’agit d’une contribution à but altruiste et quand on développe sur son temps libre, on n’est pas tenu d’avoir le même niveau de qualité que dans un cadre professionnel.
La contrainte
Les projets qui utilisent du code open source et qui sont obligés par la licence à publier leurs modifications. Il appliquent cette obligation a minima, certains volontairement et d’autres sous la contrainte. Dans ce cas-là, les entreprises communiquent généralement peu sur le sujet car, même si elles respectent la règle du jeu, elles profitent du travail d’un projet sans contribuer dans les mêmes proportions[1].
Les profiteurs
Les projets qui communiquent sur l’open source pour capitaliser sur l’image mais qui, dans la réalité, appliquent un mode de développement fermé. Le cas le plus notable est Android où Google distribue certaines parties du code, et ne rend disponible les nouveautés qu’après un certain temps.
Le développement public
Les projets où l’on peut suivre le développement mais pas ou peu participer, ici quatre grands cas :
La vente de support en cas de problème
Dans de nombreuses entreprises de grande taille, il est nécessaire d’avoir du support pour les logiciels utilisés pour avoir quelqu’un à appeler en cas de problème, plutôt que de reposer uniquement sur ses compétences internes. Les éditeurs qui vendent ce support sous forme d’abonnement annuel à volonté ont donc intérêt à ce que son code soit bien documenté et comporte le moins de bugs possibles.
Les opportunistes
Il s’agit des projets où le développement d’un outil en open source fait partie de la stratégie économique d’une entreprise : ces modèles sont très à la mode chez les éditeurs de logiciels et peut prendre plusieurs formes.
Ici l’intérêt de l’éditeur n’est pas forcément aligné avec celui de la communauté.
La vente de licences
Certaines licences comme la GPL imposent des obligations aux utilisateurs, et notamment de redistribuer les modifications effectuées s’ils vendent des produits qui les utilisent. Or certaines entreprises préfèrent ne pas le faire. Ainsi pour certains logiciels comme la base de donnée MySQL, il est possible de payer pour obtenir le droit d’utiliser l’outil sans appliquer ces obligations.
Pour contribuer au projet, il faut donc donner à l’éditeur le droit de revendre ainsi le résultat de son travail, sans respecter la licence open source.
La vente d’accompagnement pour la mise en place
Pour des logiciels difficiles à mettre en œuvre et/ou pour lesquels l’utilisateur n’a pas d’expérience, une aide est nécessaire, et l’éditeur peut la fournir. Dans ce cas, il aura tout intérêt à ce que son produit soit compliqué et mal ou partiellement documenté, et pour cela, il ira jusqu’à refuser les contributions.
Le cœur ouvert
Il s’agit de fournir le noyau du logiciel en open source mais de faire payer les fonctionnalités avancées. Ici l’opposition avec la communauté pourra parfois être frontale pour décourager tout ce qui pourrait concurrencer la version payante, y compris supprimer des modules existants pour couper l’herbe sous le pieds de développeurs trop entreprenants. La base de donnée MySQL en est un bon exemple.
Les consortiums d’entreprises
Dans le cas de projets réalisés par des consortiums d’entreprises comme Genivi, choisir une licence open source est une garantie pour les participants, et le développement est ouvert car cela facilite les choses. La participation des extérieurs est très variables : parfois bienvenus, ils doivent le plus souvent adhérer au projet pour contribuer, ce qui demande un investissement en temps et en argent.
Les étatiques
Les projets étatiques où le développement open source est devenu la règle (ou même la loi) Mais ce sont des développements spécifiques et n’appellent donc pas de réutilisation et donc de contribution, par exemple les très nombreux projets du service numérique du gouvernement britannique.
Les publicitaires
Les entreprises qui publient des projets matures et poursuivent le développement de manière publique mais sans chercher activement à recruter des participants. Ce mouvement a pris de l’ampleur ces dernières années pour deux raisons principales : l’image de l’entreprise afin d’attirer des profils, et faire plaisir aux employés car cela leur donne de la visibilité, l’archétype étant Netflix[2].
La communauté des pairs
Il s’agit du modèle de développement classique des communauté open source : des contributeurs, souvent avec des profils techniques, s’agrègent sur un projet et travaillent ensemble sans particulièrement se préoccuper du reste du monde. Ceux qui ont l’envie et la patience peuvent devenir contributeurs à leur tour suivant des mécanismes de promotion ou de cooptation informels et en apprenant petit à petit le mode de fonctionnement du projet.
Ce modèle a fait ses preuves, mais il souffre de deux défauts :
-
Le cœur du projet étant souvent composé de développeurs, l’apport des membres non développeur est moins valorisé et leur voix est moins entendue. Ils sont donc moins incités à participer et/ou risquent de se décourager. C’est un des mécanismes qui explique les manques en matière de documentation ou d’utilisabilité dont souffrent ces projets.
-
Le modèle de cooptation informel, souvent trompeusement qualifié de méritocratie, encourage les comportements de “bande de potes” méprisants envers les nouveaux participants qui mènent à des communautés sans diversité, voire toxiques, qui usent les personnes et découragent les nouveaux qui ne sont pas prêt à subir cette attitude. La communauté développant le cœur du système Linux est ainsi célèbre pour ses échanges au ton abrasif et parfois insultants, et le justifiant par le fait que la maitrise technique excuse tout.
La communauté accueillante
Il s’agit des projets ayant fait le choix d’avoir un projet avec une communauté ouverte, et qui sont donc prêts à y consacrer des efforts. Cela demande un travail continuel pour passer du temps avec les nouveaux venus et éviter que les vieux réflexes ne reviennent, et il faut parfois prendre des décisions difficiles, comme l’exclusion de membres dont les contributions ont de la valeur mais au comportement inacceptable.