Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : ga3lig, lenod, peupleLa, LAuX, billouche, Goofy, jcr83, purplepsycho, Jej, KoS, Julius22, kalupa, tuki, lamessen, okram + Sinma

La collaboration entre projets

Henri Bergius

Henri Bergius est le fondateur de Midgard(1), un dépôt de contenu pour les logiciels libres. Il a aussi été longtemps impliqué dans la géolocalisation d’ordinateurs de bureaux sous Linux ainsi que dans les communautés Maemo et Meego. Il dirige un petit cabinet de conseil nommé Nemein, bidouille CoffeeScript et PHP et passe beaucoup de son temps à faire de la moto dans des régions reculées du continent Eurasien. Il vit dans la froide ville nordique d’Helsinki, en Finlande.

Il se peut qu’il existe un système complètement nouveau dans lequel vous pouvez être défini davantage par qui vous êtes plutôt que par ce que vous possédez, par ce que vous avez créé et partagé, parce que d’autres personnes ont ensuite construit sur cette base

– John Seely Brown, ancien directeur de Xerox PARC dans An Optimist’s Tour of the Future (Mark Stevenson, 2010)

Le monde du logiciel libre est pour l’essentiel divisé en tribus rassemblées autour de choses appelées projets. Il existe des projets majeurs tels que GNOME(2), KDE(3) ou Drupal(4) et il existe bien d’autres projets plus modestes tournant autour d’une seule application ou bibliothèque logicielle.

En fait, les qualifier de « projets » est un peu ridicule.

Selon moi, un projet est l’organisation d’un effort visant un but que l’on puisse atteindre et comprend un calendrier avec dates de début et de fin. Ainsi, GNOME 3.1 serait par exemple un projet tandis que GNOME, pris dans son ensemble, n’en est pas un. Il s’agit d’une communauté d’individus qui entretiennent et créent le corps d’un logiciel par de petits efforts variés ou des projets.

Assez de pédantisme. Le souci avec le concept de projet c’est qu’il finit par maintenir une séparation entre les personnes. Cela crée des communautés isolées souvent réticentes voire incapables de collaborer avec « la concurrence ». Mais en fin de compte, toutes ces communautés sont composées de personnes écrivant des logiciels libres. Et ce sont elles qui décident de l’utilisation possible ou non d’un logiciel dans différents environnements.

En fin de compte, nous voulons tous que le logiciel que nous avons créé soit utilisé par d’autres. Mieux encore : nous voulons que les autres joignent leurs efforts aux nôtres et créent des choses sympa à partir de ce que nous avons créé. Après tout, ceci constitue le cœur même des logiciels libres.

Alors pourquoi érigeons-nous ces murs autour de nous ? Garder une communauté isolée ne fait que favoriser une mentalité de type « nous contre eux ». Les incompatibilités des différents langages de programmation contribuent déjà fortement à notre division. Pourquoi en rajouter ?

La leçon de Midgard

Il est une chose que j’aurais voulu savoir quand j’ai démarré, dans cette période optimiste des « .com » de la fin des années 90 : c’est qu’en réalité le développement de logiciels ne gagne rien à s’isoler. Avec un peu d’efforts nous pouvons partager nos logiciels et nos idées par le biais de communautés, ce qui renforce et améliore à la fois les logiciels et les communautés.

Quand j’ai démarré ma carrière dans le logiciel libre, c’était l’époque des grands projets. Netscape ouvrait son code source, la fondation Apache prenait forme et des sociétés de capital-risque venaient de partout. Tenter de bâtir sa communauté devenait la norme. C’était le chemin assuré vers la gloire, la fortune et la réalisation de choses extraordinaires.

Alors nous avons construit nos propres infrastructures web. À ce moment-là il n’y en avait pas tant que cela, en particulier pour le tout jeune langage PHP. Le PHP n’était même pas notre premier choix. Nous l’avions seulement choisi au terme d’un long débat sur l’utilisation de Scheme(5) que notre développeur principal préférait. Mais le PHP gagnait alors en popularité, devenant le langage de programmation de la Toile. Et nous voulions construire la Toile.

Au début, les choses semblaient prometteuses. Beaucoup de développeurs rejoignaient notre communauté et commençaient à y contribuer. Il y a même eu des entreprises fondées autour de Midgard. Notre infrastructure gagnait en fonctionnalités et devenait de plus en plus liée à Midgard.

Avec le recul, c’est là que nous avons fait une erreur. Nous avons positionné Midgard pour être distinct du PHP lui-même. Quelque chose que vous installeriez séparément, et utiliseriez comme base pour y construire des sites entiers. Il fallait soit suivre notre voie, soit suivre celle de tout le monde.

Avec Midgard, vous deviez utiliser notre interface de dépôt de contenus pour tout, aussi bien pour notre gestion des utilisateurs que pour le modèle de permissions. Vous deviez utiliser notre système de modèles et stocker beaucoup de votre code dans le dépôt au lieu d’utiliser un système de fichiers.

Ceci ne passait évidemment pas très bien auprès de l’ensemble de la communauté PHP. Nos idées leur semblaient étranges, et Midgard, à ce moment-là, était même distribué en tant que gigantesque correctif à la base de code puisqu’on ne pouvait pas charger de modules avec PHP3.

Les années ont passé et la popularité de PHP a connu des hauts et des bas. Pendant ce temps, la communauté Midgard est restée relativement constante : un petit groupe soudé faisant des progrès sur le long terme mais séparé du monde plus large de PHP.

Nous nous sommes toujours demandé pourquoi il était si difficile d’interagir avec le monde PHP. Même d’autres communautés faisant des choses complètement différentes, comme l’environnement de bureau GNOME, semblaient plus faciles à approcher. Ce n’est que récemment, après des années d’isolement, que nous avons pris conscience du problème. En résumé : les infrastructures nous séparent alors que les bibliothèques nous permettent de partager notre code et nos expériences.

À propos des bibliothèques et des infrastructures

En définitive, les logiciels ont pour objectif l’automatisation, la construction d’outils que les autres peuvent utiliser pour résoudre des problèmes ou se connecter entre eux. Avec les logiciels, ces outils comportent plusieurs couches. Il existe des services de bas niveau comme les systèmes d’exploitation, puis les bibliothèques, les infrastructures, les boîtes à outils et enfin les applications elles-mêmes.

Les applications sont toujours écrites pour des usages spécifiques, donc entre elles il existe peu de possibilités de partage de code.

Les possibilités les plus séduisantes se situent au niveau des bibliothèques et infrastructures. Une infrastructure, si elle est suffisamment générique, peut généralement être utilisée pour construire différentes sortes de logiciels. Une bibliothèque, quant à elle, peut être utilisée pour apporter un élément particulier de logique ou de connectivité là où le besoin s’en fait sentir. De mon point de vue, c’est dans cette couche que le plus gros de la programmation devrait être fait, avec des applications spécifiques qui ne sont que des connexions entre diverses bibliothèques au sein d’une infrastructure qui s’occupe alors de faire tourner l’application en question.

Qu’est-ce qu’une bibliothèque et qu’est-ce qu’une infrastructure ? Les gens utilisent souvent ces termes indifféremment bien qu’il existe une règle grossière qui permet de les différencier : une bibliothèque est une ressource à laquelle votre code fait appel, alors qu’une infrastructure est une ressource qui fait appel à votre code.

Si vous voulez que votre code soit utilisé et amélioré, le meilleur moyen est de maximiser le nombre de ses utilisateurs et contributeurs potentiels. Avec le logiciel libre, cela fonctionne en s’assurant que votre code peut être adapté à de multiples situations et environnements.

En définitive, ce que vous voulez développer c’est une bibliothèque. Les bibliothèques c’est cool.

Comment faire en sorte que la collaboration fonctionne

Le plus difficile est de franchir la barrière du « eux-contre-nous ». Les développeurs de l’autre communauté sont des bidouilleurs concevant du logiciel libre, tout comme vous. Il suffit donc de franchir le pas et de commencer à leur parler.

Une fois le débat engagé, voici quelques points que j’ai trouvés importants quant à l’application effective des idées communes ou des bibliothèques au-delà des frontières du projet

• Utilisez des licences permissives et essayez d’éviter les cessions de droits d’auteurs et autres exigences que les utilisateurs potentiels trouveraient onéreuses. Hébergez le projet en terrain neutre. Pour les projets web, Apache est un assez bon havre. Pour les projets bureautiques, Freedesktop est probablement le meilleur choix. Utilisez des technologies qui n’imposent pas trop de contraintes. Les bibliothèques doivent être de bas niveau, ou fournir des API (interfaces de programmation) D-Bus utilisables avec n’importe quel système.
• Évitez les dépendances spécifiques à une infrastructure. KDE a, par exemple, trouvé GeoClue difficile à adopter parce qu’il utilise des paramètres spécifiques à l’interface GNOME. Rencontrez les autres. Si vous venez du projet GNOME, allez à l’aKademy et donnez-y une conférence. Si vous êtes développeur KDE, allez parler au GUADEC. Après avoir partagé une bière ou deux, la collaboration par IRC vient beaucoup plus naturellement.
• Enfin, vous devez accepter que votre implémentation ne soit pas utilisée par tout le monde. Mais si, au moins, d’autres mettent en œuvre les mêmes idées, alors une collaboration reste possible.

Bonne chance pour abattre les frontières du projet ! Dans la plupart des cas, cela fonctionne si vos idées sont bonnes et présentées avec un esprit ouvert. Mais même si vous ne trouvez pas de terrain d’entente, tant que votre application remplit sa fonction pour vous, ça n’a pas été fait en vain. Après tout, ce qui compte c’est de proposer des logiciels et d’offrir la meilleure expérience utilisateur possible.

(1) http://midgard-project.org/

(2) gnomefr.org

(3) fr.kde.org

(4) drupalfr.org

(5) http://fr.wikipedia.org/wiki/Scheme

Crédit photo : mommy peace – (CC BY-NC-SA 2.0)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, yann, Goofy, peupleLa, KoS, Nys, Julius22, okram, 4nti7rust, zn01wr, lamessen

Des sauvegardes pour votre santé mentale

Austin Appel

Austin Appel, alias « scorche », est un professionnel de la sécurité informatique qui passe son temps à casser (il est dûment autorisé, évidemment) des choses précédemment réputées sécurisées. On le croise souvent enseignant le crochetage de serrure durant des conférences de sécurité et de hacking. Dans le monde de l’open source, il fait une foule de choses pour le projet Rockbox et a œuvré bénévolement pour le projet One Laptop Per Child (un ordinateur portable par enfant).

Les sauvegardes c’est bien. Les sauvegardes c’est super. Un administrateur compétent fait toujours des sauvegardes régulières. On apprend ça dans n’importe quel manuel traitant de l’administration des serveurs. Le problème c’est que les sauvegardes ne sont vraiment utiles qu’en cas d’absolue nécessité. Lorsque quelque chose de grave arrive au serveur ou à ses données et qu’on est forcé de se replier sur autre chose, les sauvegardes viendront à point nommé. Cependant, cela ne devrait jamais arriver, n’est-ce pas ? À n’importe quel autre moment, à quoi cela sert-il pour vous et votre environnement serveur d’avoir des sauvegardes ?

Avant d’aller plus loin, il est important de noter que ce conseil vaut pour les administrateurs serveurs des plus petits projets open source — la majorité silencieuse. Si vous maintenez des services qui vont engendrer une grande frustration, et même peut-être faire du tort s’ils sont indisponibles, vous devriez considérer ceci avec la plus grande circonspection.

Pour le reste d’entre nous qui travaillons sur d’innombrables petits projets ayant des ressources limitées, nous avons rarement deux serveurs séparés pour la production et les tests. En vérité, avec tous les services qu’un projet open source doit maintenir (système de gestion de version, services web, listes de diffusion, forums, ferme de compilation, bases de données, traceurs de bogues ou de fonctionnalités, etc.), des environnements de test séparés sont souvent de l’ordre du rêve. Malheureusement, l’approche courante de l’administration systèmes est d’avancer avec précaution et mettre les systèmes à jour uniquement en cas de nécessité absolue, afin d’éviter tout problème de dépendance, de code cassé, ou n’importe laquelle des millions de choses qui pourraient mal se dérouler. La raison pour laquelle vous êtes nerveux n’est pas que vous pourriez manquer d’expérience. Il est important de savoir que vous n’êtes pas seul dans ce cas. Que nous l’admettions ou non, beaucoup d’entre nous ont été (et sont probablement encore) dans cette situation. Il est triste que cette inaction — découlant de la peur de détruire un système fonctionnel — conduise souvent à des services en fonctionnement qui ont souvent plusieurs versions de retard, ce qui implique de nombreuses failles de sécurité potentiellement sérieuses. Cependant, soyez assuré que ce n’est pas la seule manière de jouer le jeu.

Les gens ont tendance à jouer un jeu différent selon qu’ils aient une infinité de vies ou qu’ils doivent recommencer depuis le début dès lors qu’une seule erreur a été commise. Pourquoi devrait-il en être autrement pour de l’administration systèmes ? Aborder le concept de sauvegardes avec un état d’esprit offensif peut complétement changer votre conception de l’administration systèmes. Au lieu de vivre dans la peur d’une dist-upgrade complète (ou de son équivalent pour yum, pacman, etc.), celui qui est armé de sauvegardes est libre de mettre à jour les paquets d’un serveur, confiant dans le fait que ces changements pourront être annulés si les choses tournent au vinaigre. La clé du succès réside tout entière dans l’état d’esprit. Il n’y a aucune raison d’avoir peur tant que vous avez vos données sauvegardées sous la main comme filet de sécurité lorsque vous sautez le pas. Après tout, l’administration système est une expérience d’apprentissage permanente.

Bien sûr, si vous ne validez pas vos sauvegardes, vous reposer sur elles devient un jeu très dangereux. Heureusement, les administrateurs systèmes expérimentés savent que le commandement « Garde des sauvegardes à jour » est toujours suivi par « Valide tes sauvegardes ». À nouveau, c’est un mantra que les gens aiment réciter. Ce qui, en revanche, ne tient pas de façon élégante dans un mantra entraînant est la manière de valider rapidement et simplement ses sauvegardes. La meilleure manière de dire qu’une sauvegarde est fonctionnelle est, bien sûr, de la restaurer (de préférence sur un système identique qui n’est pas en cours d’utilisation). Mais, une fois encore, en l’absence d’un tel luxe, on doit faire preuve d’un peu plus de créativité. C’est là (tout du moins pour les fichiers) que les sommes de contrôle peuvent vous aider à vérifier l’intégrité de vos fichiers sauvegardés. Dans rsync, par exemple, la méthode utilisée par défaut pour déterminer quels fichiers ont été modifiés consiste à regarder la date et l’heure de la dernière modification, ainsi que la taille du fichier. Cependant, en utilisant l’option ‘-c’, rsync utilisera une somme de contrôle MD4 de 128 bits pour déterminer si les fichiers ont changé ou non. Bien que ce ne soit pas toujours la meilleure idée à mettre en œuvre à chaque fois en toute occasion — à cause d’un temps d’exécution beaucoup plus long qu’un rsync normal et d’une utilisation accrue des accès disques — cette méthode permet de s’assurer que les fichiers sont intègres.

Le rôle d’un administrateur systèmes peut être éprouvant par moments. Il n’est cependant pas nécessaire de le rendre plus stressant que nécessaire. Avec le bon état d’esprit, certaines commandes de précaution apparemment à but unique et limité peuvent être utilisées comme des outils précieux qui vous permettent de progresser de façon agile, tout en gardant votre santé mentale intacte et la vitesse tant appréciée dans les projets open source.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang :lerouge, lamessen, CoudCoud, Kev, peupleLa (relectures),Goofy, Jej, Julius22, kalupa, 4nti7rust, ga3lig, Tsigorf, maat

Aimer l’inconnu

Jeff Mitchell

Jeff Mitchell passe ses journées de travail à s’activer sur tout ce qui touche aux ordinateurs et aux réseaux et son temps libre à barboter dans toutes sortes de projets de logiciels libres et open source. Ce qu’il préfère c’est la convergence des deux. Après avoir travaillé en tant qu’administrateur systèmes professionnel de 1999 à 2005, il maintient son niveau de compétences en les mettant bénévolement au service de projets libres en divers lieux. Ces temps-ci, son activité pour le Libre est dédiée à l’administration systèmes pour KDE¹ et c’est l’un des développeurs principaux du lecteur Tomahawk². Jeff vit actuellement à Boston, aux États-Unis.

Récemment, à mon travail, j’ai fait partie d’une équipe qui faisait passer les entretiens d’embauche pour un poste d’administrateur systèmes. Après avoir parcouru quelques dizaines de curriculum vitae nous avons finalement convoqué notre premier candidat. Celui-ci — appelons-le John — avait aussi bien l’expérience de petites structures, style laboratoire informatique, que de plus vastes opérations dans des centres de données. À première vue, les choses se présentaient bien, si ce n’est qu’il avait eu cette réponse bizarre à quelques-unes de nos questions : « je suis administrateur systèmes ». Le sens de cette phrase n’a pas été immédiatement clair pour nous, jusqu’à ce que l’échange suivant ait lieu :

Moi : Donc, vous avez dit que vous n’avez pas d’expérience avec Cisco IOS, mais qu’en est-il des réseaux en général ?

John : Eh bien, je suis administrateur systèmes.

Moi : Oui, mais que diriez-vous sur les concepts de réseau ? Les protocoles de routage comme BGP ou OSPF, les VLANs, les ponts réseaux…    

John, exaspéré : Je suis administrateur systèmes.

C’est à ce moment-là que nous avons compris ce qu’il voulait dire. John ne nous disait pas qu’il connaissait toutes ces choses que nous lui demandions puisqu’il était administrateur systèmes ; il nous expliquait que parce qu‘il était administrateur systèmes, il n’en savait rien. John était administrateur systèmes et cela signifiait pour lui que ces tâches étaient celles d’un administrateur réseau. Sans surprise, John n’a pas obtenu le poste.

Dans bien des projets open source, la spécialisation est une malédiction et non une bénédiction. Qu’un projet relève d’une catégorie ou l’autre dépend souvent de la taille de l’équipe de développement ; la spécialisation à l’extrême peut entraîner de graves perturbations dans un projet en cas de départ d’un développeur, que ce soit en bons ou mauvais termes, qu’on le regrette ou non. Il en va de même pour les administrateurs systèmes de projets open source, bien que la pénurie générale de ces derniers semble autoriser aux projets une marge de tolérance parfois dangereuse.

L’exemple le plus flagrant qui me vienne à l’esprit impliquait un projet spécifique dont le site de documentation (y compris toute celle de l’installation et de la configuration) était indisponible depuis plus d’un mois. La raison : le serveur était en panne et la seule personne qui en avait l’accès naviguait sur un « bateau pirate » avec les membres du parti pirate suédois. C’est une histoire vraie.

Cependant, tous les points de défaillance ne sont pas dus à l’absence des administrateurs systèmes ; certains sont artificiels. Sur un gros projet, les décisions des droits d’accès à l’administration systèmes étaient assumées par un seul administrateur. Il ne s’était pas seulement réservé certains droits d’accès uniquement pour lui-même (vous l’avez deviné : oui, il a disparu pendant un certain temps, et oui, cela a causé des problèmes) ; il avait aussi décidé de la façon dont les droits d’accès devaient être accordés, en fonction de la confiance qu’il portait personnellement au candidat. La « confiance », dans ce cas, se fondait sur une seule chose : non pas le nombre de membres de la communauté qui se portait garant pour cette personne, ni depuis combien de temps cette personne était un contributeur actif et de confiance pour le projet, ni même depuis combien de temps il connaissait lui-même cette personne dans le cadre de ce projet. Au lieu de cela, elle reposait sur la façon dont il connaissait personnellement quelqu’un, ce par quoi il entendait la façon dont il connaissait cet individu en personne. Vous imaginez bien à quel point cela est adapté à une équipe d’administrateurs systèmes disséminée sur toute la planète…

Bien sûr, cet exemple ne fait qu’illustrer la grande difficulté pour un administrateur systèmes open source de trouver le juste milieu entre sécurité et capacité. Les grandes entreprises peuvent se permettre d’avoir du personnel redondant, et ce, même si le travail se répartit selon différentes responsabilités ou domaines de sécurité. La redondance est importante. Mais qu’en est-il si la seule possibilité d’avoir une redondance pour l’administrateur systèmes est de prendre la première personne se présentant au hasard sur votre canal IRC ou une personne quelconque proposant son aide ? Comment pouvez-vous raisonnablement avoir confiance en cette personne, ses capacités et sa motivation ? Malheureusement, seuls les contributeurs principaux du projet ou une petite partie d’entre eux peuvent savoir quand la bonne personne se présente en utilisant le même modèle de toile de confiance³ qui sous-tend une grande partie du reste du monde open source. L’univers des projets open source, leurs besoins et les personnes qui veulent contribuer à un projet particulier forment une extraordinaire diversité ; par conséquent, la dynamique humaine, la confiance, l’intuition et la manière d’appliquer ces concepts à un projet open source sont de vastes sujets, bien au-delà de la thématique de ce court article.

Une chose importante a cependant facilité la découverte de cette ligne d’équilibre sécurité/capacité : l’essor des systèmes de gestion de versions distribués, ou DVCS (NdT : Distributed Version Control System, système de gestion de version distribué). Auparavant, les contrôles d’accès étaient primordiaux car le cœur de tout projet open source — son code source — était centralisé. Je me rends bien compte que beaucoup doivent penser : « Jeff, tu devrais pourtant le savoir, le cœur d’un projet, c’est sa communauté, pas son code ! ». Ma réponse est simple : les membres de la communauté vont et viennent, mais, si quelqu’un fait accidentellement un « rm -rf » sur tout l’arbre du système de gestion de versions de votre projet et que vous manquez de sauvegardes, combien de ces membres de la communauté vont continuer à s’investir dans le projet et aider à tout recommencer à zéro ? (Mes propos se basent sur une histoire vraie dans laquelle un membre de la communauté saoul qui s’énervait à déboguer un bout de code, lança un « rm -rf » sur toute sa contribution, avec l’intention de supprimer tout le code du projet. Par chance, il n’était pas administrateur systèmes et n’avait donc pas accès au dépôt central, et il était trop saoul pour se rappeler qu’il travaillait seulement sur une copie du projet.)

Le code du projet est son cœur ; les membres de sa communauté en sont l’énergie vitale. Privé de l’un ou de l’autre, vous aurez du mal à garder un projet vivant. Avec un logiciel de gestion de version (NdT : VCS pour version control system) centralisé, si vous n’avez pas eu la présence d’esprit de mettre en place un système de sauvegarde régulier, vous pourriez, avec de la chance, ré-assembler l’arborescence complète du code source à partir des différents éléments contribués qu’auront gardés les autres personnes. Mais pour la majorité des projets, l’historique du code est aussi important que le code lui-même et cela, vous l’aurez tout de même entièrement perdu.

Ce n’est plus le cas désormais. Quand tous les clones locaux ont tout l’historique du projet et que des sauvegardes de secours peuvent être effectuées chaque nuit, en lançant une tâche planifiée aussi simple que « git pull », les dépôts centralisés ne sont plus que des outils de coordination. Cela en diminue l’importance de quelques degrés. Le projet doit toujours être protégé contre les menaces aussi bien internes qu’externes : les systèmes non corrigés sont toujours vulnérables à des exploits bien connus. Un administrateur systèmes malveillant peut tout mettre sans dessus dessous, un système d’authentification déficient peut permettre l’entrée de codes malveillants dans la base, et un « rm -rf » accidentel sur le dépôt central peut toujours coûter cher en temps de développement. Mais ces défis peuvent être surmontés, et à l’ère des serveurs privés virtuels (VPS) abordables et des centres d’hébergement de données, les absences des administrateurs systèmes peuvent également être compensées. (Il vaut mieux cependant s’assurer d’avoir un accès redondant au DNS ! Oh et mettez aussi vos sites internet sur un dépôt vérifié et certifié [DVCS] , et faites des branches pour les modifications locales. Vous me remercierez plus tard.)

Les DVCS permettent la redondance du cœur de votre projet pour trois fois rien, ce qui est une bonne façon d’aider les administrateurs systèmes à dormir la nuit et nous donne l’impression d’être un peu des maîtres du temps. Cela veut aussi dire que si vous n’êtes pas sur un DVCS, arrêtez de lire immédiatement et passez sur l’un d’eux. Ce n’est pas qu’une question d’espace de travail et d’outils. Si vous vous souciez de la sécurité de votre code et de votre projet, vous migrerez.

La redondance du code source est une nécessité, et en général plus vous avez de redondances, plus vos systèmes sont robustes. Il semble aussi évident que vous voulez une redondance de vos administrateurs systèmes ; ce qui vous semblera peut-être moins évident, c’est que l’importance de la redondance ne se joue pas tant en termes de personnes qu’en termes de niveau des compétences. John, l’administrateur systèmes, a travaillé dans des centre de stockage des données et au sein d’entreprises qui avaient des systèmes d’administration redondants mais des niveaux de compétences rigides, définis. Cela fonctionne dans de grandes entreprises qui peuvent payer pour embaucher de nouveaux administrateurs systèmes avec des compétences à la carte. Mais la plupart des projets open source n’ont pas ce luxe. Vous devez faire avec ce que vous avez. Cela veut dire bien sûr que, pour que l’administration systèmes soit redondante, une solution — et c’est parfois la seule — consiste à répartir la charge : d’autres membres du projet prenne chacun  une ou deux compétences jusqu’à ce qu’il y ait redondance.

Il n’y a guère de différence entre le côté développement et le côté créatif d’un projet ; si la moitié de votre programme est écrite en C++, l’autre moitié en Python, et qu’un seul développeur sait programmer en Python, son départ du projet provoquera de gros problèmes à court terme et pourrait aussi causer de sérieux problèmes à plus long terme. Encourager les développeurs à se diversifier et à se familiariser avec d’autres langages, paradigmes, bibliothèques, etc. entraîne que chacun de vos développeurs gagne en valeur ; cela ne devrait pas choquer : l’acquisition de nouvelles compétences est le résultat d’un apprentissage qui se poursuit tout au long de la vie, et un personnel mieux formé a aussi plus de valeur. (Cela rend aussi le curriculum vitae de chacun plus attractif, ce qui devrait être une bonne motivation.)

La plupart des développeurs open source que je connais considèrent comme un défi et un plaisir de s’aventurer sur de nouveaux territoires : c’est justement ce genre d’état d’esprit qui les a menés à développer de l’open source au départ. De même, les administrateurs de systèmes open source sont une denrée rare, et ne peuvent se permettre de s’enliser dans une routine. De nouvelles technologies intéressantes pour les administrateurs systèmes apparaissent constamment et il existe souvent de nouvelles façons d’utiliser des technologies actuelles ou anciennes afin de renforcer l’infrastructure ou d’améliorer leur efficacité.

John n’était pas un bon candidat parce qu’il apportait peu de valeur ajoutée ; et il apportait peu de valeur car il n’était jamais allé au-delà des limites du rôle qui lui était attribué. Les administrateurs systèmes open source qui tombent dans ce piège ne nuisent pas seulement  au projet dans lequel ils sont impliqués sur le moment, ils réduisent  leur valeur pour d’autres projets utilisant des technologies d’infrastructure différentes et qui auraient vraiment besoin d’un coup de main ; cela diminue les capacités globales de la communauté open source. Pour un administrateur de logiciel libre efficace, il n’existe pas de zone de confort.

1. http://www.kde.org/ ^{^}
2. http://www.tomahawk-player.org/ ^{^}
3. http://fr.wikipedia.org/wiki/Toile_de_confiance ^{^}

Que les gros salaires lèvent le doigt, surtout en temps de crise… Mais ce qu’il y a peut-être de plus intéressant dans l’affaire Depardieu, ce qu’elle a rebondi sur une mise en accusation globale du financement du cinéma français, grâce à une tribune mordante de Vincent Maraval dans Le Monde.

On notera au passage que c’est un producteur qui a mis les pieds dans le plat et non un journaliste, ce qui en dit long sur l’inféodation d’une profession qui préfère se voiler la face en se cantonnant à voir des films (gratos) en pondant leur anecdotique et souvent insignifiant « J’aime / J’aime pas ».

« Le système est sclérosé », surenchérit ici Jérémie Nestel, du collectif Libre Accès, en insistant sur une revendication dont le persistant refus devient de plus en plus difficile à justifier : ce qui est financé sur fonds publics doit être placé tôt ou tard sous licence libre. Tard ce serait ici pas plus d’une dizaine d’années en n’attendant surtout pas la trop lointaine échéance du domaine public, 70 ans après les morts de tous les protagonistes d’un film !

Musique, littérature, cinéma… Internet révèle chaque jour davantage une culture soumise à l’industrie culturelle qui ne profite qu’à une minorité, qui criminalise le partage et qui ne peut ou veut s’adapter à son époque.

Pour un cinéma promouvant le droit au partage

URL d’origine du document

Jérémie Nestel – 6 janvier 2013 – Libre Accès
Licence Art Libre

Notre mémoire collective contribue à forger une morale commune fait de références similaires.

Cette mémoire collective repose essentiellement sur « des œuvres de l’esprit ».

L’incapacité des politiques à préserver les biens communs dont ceux issus des œuvres de l’esprit annonce la fin du contrat social de notre société.

Pourquoi aliéner notre liberté à une société privilégiant des intérêts particuliers à l’intérêt général ?

Les débats autour d’Hadopi, du droit d’auteur et des nouvelles taxes demandées au public pour financer des rentes à vie aux stars des médias et aux multinationales du divertissement trouvent un écho à deux articles du monde commentant l’exil fiscal de Depardieu.

Tout d’abord ce premier article du Monde « Depardieu, enfant perdu de la patrie » faisant le parallèle entre la volonté de Depardieu de renoncer à sa nationalité et une thèse de Pierre Maillot sur l’identification des Français aux acteurs.

L’article suggère que « le Français qui se reconnaît dans Depardieu se reconnaît perdu ». En choisissant l’exil et « sa déchéance nationale » Depardieu devient le symbole d’une France dont le lien social est brisé.

Le deuxième article du Monde « Les artistes français sont trop payés », coup de gueule du producteur Vincent Maraval, qui relativise l’exil de Depardieu au regard des salaires indécents des acteurs du cinéma Français.

On y apprend que le salaire des acteurs n’est pas lié à la recette commerciale de leur film mais à leur capacité à obtenir les fonds cumulés du CNC, des taxes, des avantages fiscaux et de la télévision publique.

« Est-il normal qu’un Daniel Auteuil, dont les quatre derniers films représentent des échecs financiers de taille, continue à toucher des cachets de 1,5 million d’euros sur des films coproduits par France Télévision ? »

Cet article nous apprend qu’aucune des grandes productions françaises ne doit sa viabilité économique à son exploitation commerciale mais uniquement au financement public direct ou indirect.

Ces fonds publics ne servent pas à faire émerger une esthétique cinématographique française mais à maintenir une société d’acteurs et de producteurs percevant des millions.

Système complètement sclérosé où les réseaux de distribution des salles de cinéma et des chaînes de télévision sont saturés par des grosses productions françaises ou américaines et incapables de s’adapter à la démocratisation des outils numériques de production cinématographique et à la multiplicité des réalisateurs !

L’article de Maraval aura donné lieu à des réactions en chaîne du milieu du cinéma, Libération annonçant même une série de conférences dédiées.

On y apprendra pèle mêle :

Thomas Langmann : « Le système d’avance sur recette du CNC, symbole de l’exception culturelle française, est devenu un comité de copinage. Formé de trois collèges, les choix de l’avance sur recettes restent entièrement à la discrétion de ces commissions. ».

Olivier Bomsel : « Les chaînes françaises n’achètent donc que des créneaux de diffusion : leur seul actif est la valorisation instantanée par la diffusion ».

C’est peut-être là le plus grand scandale, au final. Qu’importe que des acteurs perçoivent des millions comme Daniel Auteuil grâce à des fonds publics, mais pourquoi priver les Français de leur droit au partage sur des productions qu’ils ont contribué à financer ?

Si Canal plus avec Studio Canal détient un catalogue grâce aux films qu’ils ont produits, pourquoi interdire ce droit aux chaînes publiques, chaînes publiques qui appartiennent aux Français ?

La société française est prise en otage d’une économie cinématographique et musicale défaillante ne pouvant se maintenir qu’en exigeant toujours plus de taxes, et en privant les français de leur droit au partage. Dans ce contexte surprenante intervention de la ministre de la Culture Aurélie Filippetti, à la tribune de Maraval, pour affirmer que le mode de financement du cinéma est « un un système vertueux ». Pour pérenniser un système défaillant on ne parlera pas d’une nouvelle économie bâtie sur le partage mais de régulation.

En toile de fond, de l’affaire Depardieu, on retiendra sa capacité à mobiliser sur une affaire somme toute personnelle, deux présidents de la République : Incroyable pouvoir d’influence des acteurs du cinéma sur le politique !

Ce n’est donc pas demain qu’un Ministre de la Culture affirmera que tout film produit à l’aide de financement public (CNC, de France Télévision, aides régionales, Européenne etc.) puisse être diffusé sous une licence libre favorisant le partage. L’appropriation « des catalogues de films » par les multinationales du divertissement vole à notre humanité des pans entiers de notre culture commune. Il n’est donc pas injuste de penser qu’au bout de dix ans d’exploitation un film puisse être diffusé sous une licence libre compte tenu que ceux qui l’ont réalisé ont déjà été rémunérés.

Le partage, l’échange de films qui ont marqué notre vie est un acte social à l’heure du numérique aussi banal que de chanter en famille des chansons en fin de dîner.

Crédit photo : Vincent Roche (Creative Commons By-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Goofy, lerouge, lamessen, peupleLa (relectures), maxlath, Julius22, kalupa, ga3lig, lamessen

Laisser le champ libre

Lydia Pintscher

Lydia Pintscher est une femme naturellement douée pour apprivoiser les gens, les geeks et les chatons. Entre autres, elle est en charge des programmes de mentors de KDE (Google Summer of Code, Google Code-in, Season of KDE), membre fondateur des groupes de travail de la communauté KDE et membre du conseil de KDE e.V.

Le logiciel libre a un ennemi. Ce n’est pas celui auquel pensent la plupart des personnes sur Internet. Non, l’ennemi, c’est le manque de participation active.

Chaque jour des milliers de personnes se mettent à chercher ce qui pourrait bien donner un sens à leur vie, et se demandent comment réaliser quelque chose qui compte vraiment. Tous les jours des milliers de lignes de code pour des logiciels libres sont en attente d’écriture et de débogage, des programmes attendent d’être mis en avant et traduits, des éléments artistiques attendent de voir le jour et ainsi de suite.

Malheureusement, il arrive beaucoup trop souvent que la connexion ne s’établisse pas entre tous ces individus et tous ces projets. Il y a plusieurs raisons à cela. Tout commence avec des personnes qui ne connaissent rien au logiciel libre, à tous ses avantages et à ses valeurs. Mais on commence à y arriver. Les gens commencent à utiliser et peut-être même à comprendre le logiciel libre à grande échelle. Les projets de logiciels libres vivent de la conversion de certains de leurs utilisateurs en contributeurs actifs. Et c’est là que les problèmes sérieux commencent.

J’ai accompagné des centaines d’étudiants avec des programmes de tutorat et je suis allée sensibiliser de diverses façons aux projets de logiciels libres. J’ai travaillé avec des gens enthousiastes dont la vie a pris un tour bien meilleur grâce à leurs contributions aux logiciels libres. Mais il y a un leitmotiv que je vois encore et toujours et ça me brise le cœur parce que je sais maintenant à côté de quels talents nous passons à cause de ça : ne pas se sentir autorisé à faire quelque chose d’extraordinaire. Un collègue tuteur du Google Summer of Code a mieux résumé ceci en disant : « on a rarement l’impression que les contributeurs de l’open source n’ont pas eu la permission de travailler sur des trucs mais plutôt qu’ils ne se sont pas précipités assez vite au bon moment ». Les contributeurs potentiels pensent souvent qu’ils ne sont pas autorisés à contribuer. Les raisons en sont nombreuses et reposent toutes sur des malentendus. Voici les préjugés les plus courants d’après mon expérience :

• « Je ne sais pas coder. Pas moyen pour moi de contribuer. »
• « Je ne suis pas vraiment bon pour ça. On n’a pas besoin de mon aide. »
• « Je serais rien qu’un boulet. Ils ont des choses plus importantes à gérer. »
• « On n’a pas besoin de moi. Ils doivent avoir déjà assez de gens bien plus brillants que moi. »

Ces préjugés sont presque toujours sans fondement et j’aurais aimé savoir il y a bien longtemps qu’ils sont si répandus. J’aurais dès le début abordé très différemment mon travail de sensibilisation.

Le plus simple, pour sortir quelqu’un de cette situation, c’est de l’inviter en personne. « Cet atelier que nous proposons ? — Oui, bien sûr, tu devrais venir ». « Ce bogue remonté dans le traqueur de bogues ? — Je suis sûre que tu es la personne idéale pour essayer de le corriger ». « Ce communiqué de presse qu’il faut préparer ? — Ce serait super si tu pouvais le relire et t’assurer qu’il est bon ». Et si ce n’est pas possible, assurez-vous que votre matériel de promotion — vous en avez bien un peu, non ? — précise clairement quel genre de personnes vous recherchez et ce que vous estimez être les prérequis.

Assurez-vous surtout de toucher les personnes en-dehors du cercle des contributeurs habituels, car la barrière est encore plus haute pour eux. À moins de dépasser cette limite, vous ne recruterez que vous-même — c’est-à-dire que vous aurez davantage de contributeurs semblables à ceux que vous avez déjà. Les personnes semblables à celles déjà présentes sont géniales, mais pensez à toutes les autres personnes extraordinaires à côté desquelles vous passez et qui pourraient apporter de nouvelles idées et de nouvelles compétences à votre projet.

Entre les biens communs et le communisme, y aurait-il davantage qu’une parenté lexicale ? Le logiciel libre libère-t-il plus que le code ? Est-il l’instrument d’une lutte contre le capitalisme monopolistique, ou bien une ressource développée en marge du temps salarié et qu’il est pratique de piller dans une logique de marché ?

Des questions de ce type, et d’autres bien plus brutales encore, sont depuis longtemps posées par toutes sortes de personnes et pas seulement dans le milieu de l’informatique ou de sa culture. Voyez par exemple les réflexions avancées sur ce forum de marxistes révolutionnaires, cette autre analyse politico-philosophique déjà ancienne qui pose justement la problématique du Libre au-delà du logiciel en essayant « d’interpréter Marx dans le contexte du logiciel libre ». Ou encore ce texte d’Ernest Everhard qui analyse assez bien les limites politiques du logiciel libre, lequel ne peut suffire à transformer à lui seul la société — une prise de position dont la conclusion est la suivante : « il est nécessaire d’exproprier les grands éditeurs de logiciels ».

Bref, voilà bien un serpent de mer qui donne lieu à beaucoup d’approximations, de conjectures et de théories. Ou plutôt, que l’on tente fréquemment de rapprocher plus ou moins judicieusement de théories ou idéologies aussi variées que contradictoires, comme c’est le cas dans l’article de Jonathan Roberts.

Posons cependant l’hypothèse que ce débat est fertile car il oblige les libristes à se positionner et réfléchir au-delà de leurs mantras stallmanniens. Et peut-être à cerner mieux ce que le mouvement du logiciel libre n’est pas. « Ni de droite ni de gauche » prétendent constamment tous ceux qui refusent de reconnaître dans quel contexte politique il se déploie ou non. « Ni marxiste ni capitaliste » vont peut-être nous expliquer doctement certains commentateurs. Mais encore ? « Ni libertaire ni libertarien » ?

Ne prenez pas trop au sérieux les rapprochements forcément discutables que vous lirez ci-dessous, voyez-y plutôt une invitation à débattre. Librement.

La philosophie du logiciel libre

d’après Jonathan Roberts The philosophy of free software (Tech Radar)

Beaucoup de gens adorent se lancer dans un bon débat. Nous leur avons demandé (un peu comme une boutade) s’il était plus facile d’appréhender Linux sous l’angle du marxisme ou sous celui du capitalisme.

Les réponses qui nous sont parvenues étaient très drôles, mais la plupart étaient aussi plutôt élaborées et nous ont invités à réfléchir : comment Linux et le mouvement du logiciel libre trouvent-ils leur place dans les vastes débats philosophiques, économiques, éthiques et religieux qui passionnent les êtres humains depuis des siècles.

En constatant que même Linus Torvalds s’était lancé dans des spéculations aussi oiseuses, comme on peut le voir dans l’interview qu’il a donnée l’été dernier à la BBC, nous avons pensé qu’il serait amusant de poursuivre la conversation.

Nous allons aborder Linux et le logiciel libre selon une perspective cavalière, en l’examinant sous l’angle de quelques-uns de ces débats sans fin. Nous jetterons un coup d’œil à quelques théories pour savoir dans quelle mesure elles pourraient s’appliquer à notre système d’exploitation favori.

Tout d’abord cet avertissement : selon nous, ce qui est le plus important avec Linux et le logiciel libre, c’est qu’il s’agit d’une réalité pratique. C’est tout simplement sympa que ce truc fonctionne bien, c’est gratuit et les gens peuvent prendre beaucoup de plaisir à l’utiliser et à l’élaborer, certains peuvent même gagner un peu d’argent par la même occasion. Tout le reste n’est que littérature, donc ne soyez pas trop bouleversé par ce que vous allez lire !

Puisque nous avons mentionné l’interview de Linus Torvald à la BBC, commençons par là. Il y déclare : « …l’open source ne marche vraiment que si chacun y contribue pour ses propres raisons égoïstes… la propriété fondamentale de la GPL2 c’est sa logique de simple donnant-donnant : je te donne mes améliorations si tu promets que tu me feras profiter des tiennes ».

Ce qui rend l’observation de Torvalds intéressante c’est qu’on peut la mettre en rapport avec des discussions en philosophie, éthique, biologie, psychologie et même mathématiques qui remontent à Platon (au moins). Dans La République, Platon examine les notions de justice et de morale en posant la question : sont-elles des constructions sociales ou un Bien abstrait ?

Au cours du dialogue, Glaucon, un des protagonistes, évoque l’histoire de l’anneau magique de Gygès qui rend invisible celui qui le porte. Il présume que, juste ou injuste, tout homme qui porterait cet anneau agirait de la même façon : en prenant ce qui lui plaît sur les étals du marché, en s’introduisant dans les maisons pour y coucher avec qui lui plaît ou encore en tuant ses ennemis.

Il déclare :

« Si quelqu’un recevait ce pouvoir d’invisibilité et ne consentait jamais à commettre l’injustice ni à toucher au bien d’autrui, il paraîtrait le plus insensé des hommes à ceux qui auraient connaissance de sa conduite, (…) car tout homme pense que l’injustice est plus profitable que la justice. » (Platon, La République, II, 360d, traduction Robert Baccou)

Quelle vision déprimante de la nature humaine !

Que vous vous accordiez ou non avec Glaucon, il est évident que Torvalds soulève ce même point : sans contraintes sociales telles que la GPL v2, je ne serais pas en mesure de croire qu’en échange de mes améliorations du code, vous me donneriez les vôtres en retour.

Pourquoi le feriez-vous ? Après tout, si vous vous contentez de prendre mon code pour améliorer votre logiciel, vous aurez un avantage sur moi : moins de travail pour un meilleur résultat — et les gens sont égoïstes !

Il semble que même Platon, comme l’a fait plus tard Torvalds, ait au moins considéré que le monde ne tourne pas avec des gens qui disent : « asseyons-nous tous en rond autour d’un feu de camp pour chanter “Si tous les gars du monde…” et le monde sera meilleur ».

Les rapaces et la sécurité

Bruce Schneier traite du même problème dans son dernier ouvrage Liars and Outliers http://www.schneier.com/book-lo.htm… ; il met en évidence à quel point ce débat est courant, tant à l’intérieur qu’à l’extérieur du monde de la technologie. Dans son livre, il décrit un processus appelé le jeu du Faucon-Colombe, inspiré de la théorie des jeux.

La théorie c’est que dans une population d’oiseaux sauvages en compétition pour la même quantité limitée de nourriture, certains sont des faucons et d’autres des colombes. Les faucons sont agressifs et vont se battre pour leur nourriture : quand ils rencontrent un autre faucon, ils vont tous les deux se combattre, et l’un obtiendra la nourriture tandis que l’autre sera blessé voire tué. Les colombes, au contraire, sont passives, et lorsqu’elles sont deux devant la même nourriture, elles choisissent de la partager entre elles. Si un faucon et une colombe sont confrontés, alors c’est toujours le faucon qui aura la nourriture et la colombe va choisir de se retirer.

Bien que vous puissiez tirer bien des conclusions de l’analyse de ce jeu, l’observation la plus importante que fait Schneier est la suivante : quel que soit le scénario envisagé, il y aura toujours au moins quelques faucons dans le lot.

Si la population au départ était composée à 100% de colombes, quelques-unes s’arrangeraient rapidement pour avoir pas mal de nourriture supplémentaire pour elles seules, en se comportant comme des faucons, sans trop de risques d’affronter d’autres colombes qui se comporteraient elles aussi comme des faucons. Bien entendu, à mesure que la population de faucons s’accroît, arrivera un moment où les conséquences en seront dommageables à l’ensemble de la population. Il n’y aura plus assez de nourriture pour les colombes, qui mourront lentement après s’être retirées de tous les combats sans nourriture, et les faucons auront de plus en plus d’affrontements avec leurs semblables, courant des risques plus grands d’être tués.

Bon, arrêtons là avec les faucons et les colombes. Quels rapports avec le logiciel libre et la GPL ? Eh bien on pourrait en déduire que sans la GPL « qui nous permet d’être égoïstes », comme le dit Torvalds, nous pourrions nous trouver dans la situation où trop de faucons s’emparent du code sans contribuer en échange, ce qui dégraderait progressivement la confiance et la participation, et finirait par détruire notre population de programmeurs open source.

Dans le reste de l’ouvrage, Schneier propose divers « mécanismes de sécurité » pour nous aider à avoir confiance dans les actions des autres, et nous permettre de travailler de façon collaborative même si nous ne pouvons pas forcément adhérer aux motivations (égoïstes) des autres. Tandis que Schneier signale des facteurs tels que la loi, l’évolution des neurones miroirs, etc., la GPL pourrait également être considérée selon cet angle ,à savoir comme un mécanisme de sécurité destiné à renforcer la confiance mutuelle et la collaboration. Et c’est aussi très malin.

Le logiciel libre et l’économie

En plus d’être un cas d’étude intéressant pour ceux qui s’intéressent à la coopération, le logiciel libre a reçu beaucoup d’attention pour ses similarités avec divers systèmes économiques. Un bon exemple en est Bill Gates, qui en 2005 disait : « Il y a des communistes des temps modernes qui voudraient se débarrasser des primes pour les (…) éditeurs de logiciels de diverses façons »

Maintenant, bien sûr, il est possible que l’intérêt de Gates ait moins été de tirer un bilan économique sérieux que d’effrayer le marché des entreprises américaines capitalistes qui aiment le libre-échange en les dissuadant d’utiliser des logiciels libres ; c’est une observation qui revient assez fréquemment pour mériter qu’on la prenne en considération.

Le premier point à noter est que le logiciel libre a peu à voir avec le communisme soviétique, dont les principales caractéristiques étaient la planification centralisée et un état policier imposant, complétés par des camps de prisonniers et de travail forcé. Ceux qui ont suivi le logiciel libre depuis suffisamment longtemps savent que la planification centralisée ne se produit que rarement, sinon jamais : la multiplication des formats logiciels, des distributions, suites bureautiques, environnements de bureau, serveurs web et de courriels en est une preuve suffisante.

Qui plus est, personne n’est obligé de travailler sur du logiciel libre ou de l’utiliser. En fait, étant donné que tous les formats de fichier sont implémentés avec un code ouvert, n’importe qui peut les ré-implémenter dans un programme concurrent sans sourciller. Beaucoup se sont emparés de ces arguments pour suggérer que – pour la plus grande frustration de Bill Gates, on peut bien l’imaginer – le logiciel libre a moins en commun avec le communisme soviétique que les pratiques de nombreuses entreprises propriétaires.

Des entreprises comme Apple et Microsoft sont réputées et même félicitées pour leur planification verticale ; elles sont aussi tristement célèbres par la façon dont elles enchaînent les utilisateurs à leurs logiciels et matériels informatiques en créant par défaut des formats de fichiers fermés et propriétaires que les programmes concurrents ne sont pas en mesure d’implémenter facilement eux-mêmes.

Le marxisme

Si le logiciel libre a peu de rapport avec le communisme soviétique, peut-être a-t-il davantage en commun avec le marxisme.

L’une des idées centrales dans cette vision du monde est qu’en détenant les moyens de production, que ce soit les machines, le savoir ou quoi que ce soit d’autre, les classes dominantes peuvent exploiter les classes dominées; tant qu’ils ne possèdent pas les moyens de production, les travailleurs doivent céder « volontairement » leur force de travail contre un salaire pour acheter les biens nécessaires à leur survie : un toit, des vêtements, de la nourriture et des loisirs. Ils ne peuvent véritablement choisir de travailler, et ils ne peuvent jamais avoir vraiment leur mot à dire sur leurs salaires ou la redistribution des profits.

Une des idées constantes chez Marx, c’est son espoir que la situation pourra être améliorée, avec des travailleurs qui conquièrent leur liberté au sein d’une société sans classes dans laquelle les moyens de production seront détenus en commun.

Puisque, dans le monde contemporain, l’un des principaux moyens de production est le logiciel, le logiciel libre correspond assez bien au système de Marx. Le code est effectivement un bien commun. Tout le monde est libre de le lire, de l’étudier, de le partager, de le remixer et le modifier. De ce fait, il est impossible que les travailleurs soient enchaînés par ceux qui les dominent dans le système de classes, puisque à tout instant chacun peut choisir d’utiliser les moyens de production, c’est-à-dire le code, à ses propres fins.

Liberté de pensée

Eben Moglen plaide en faveur de l’influence que la propriété commune du code peut avoir sur notre société, dans un discours prononcé aux Wizards of OS 3, intitulé « Les pensées sont libres : le logiciel libre et la lutte pour la liberté de pensée ».

Dans son discours, il a soutenu que « perpétuer l’ignorance, c’est perpétuer l’esclavage » (il sait vraiment tourner une phrase !). Son argument est que sans la connaissance de l’économie, sans la connaissance de l’ingénierie, de la culture et de la science – toutes ces choses qui font tourner le monde, les classes dominées ne pourront jamais espérer améliorer leur situation, ni espérer s’emparer des moyens de production.

Les logiciels libres, ainsi que le matériel libre, la culture libre et tout ce qui gravite autour du Libre, libèrent des moyens qui mettent la liberté de pensée et d’information à portée de main, si elle n’est déjà atteinte.

Les serveurs web ne sont pas limités seulement à ceux qui possèdent les moyens de production, parce que le code est libre, donc n’importe qui peut partager à sa guise n’importe quelle création culturelle de son choix. Ce peut être une simple chanson, mais ça peut aussi être le moyen de créer une monnaie mondiale, décentralisée, comme le Bitcoin, ou les plans de toutes les machines nécessaires pour construire votre propre petite ville, comme dans le Global Village Construction Set.

Ce qui importe, c’est que tout cela a été rendu possible par la propriété commune du code.

L’ordre spontané

Si vous n’êtes pas trop convaincu que le logiciel libre est un mouvement qu’aurait pu soutenir Marx, vous pourriez être surpris d’apprendre que vous disposez d’un bon argument : c’est une excellente illustration du libre-échange, cette théorie tellement chérie des capitalistes et tellement haïe des marxistes et militants anti-mondialisation sur toute la planète. Bon, peut-être pas le libre-échange, mais du moins c’est l’illustration d’une des idées majeures qui le sous-tend, celle de l’ordre spontané.

Une des principales idées du libre-échange c’est que, guidées par la main invisible du marché, les fluctuations de prix s’ajustent en fonction des efforts individuels d’une manière qui favorise le bien commun. Cette idée est étroitement associée à Adam Smith et Friedrich von Hayek, qui ont utilisé le terme d’ordre spontané pour la décrire, mais elle remonte en fait à David Hume, l’un des plus grands philosophes du mouvement des Lumières écossais.

Hume croyait qu’en l’absence d’autorité centralisée, les conventions et les traditions ressortent pour minimiser et résoudre les conflits et pour réguler les activités sociales. Contrairement à Smith et Hayek cependant, Hume croyait que les passions humaines vont au-delà du simple appât du gain et que de ces passions peuvent découler règles et conventions.

Quel rapport avec les logiciels libres ? Eh bien, c’est plutôt évident, non ? Le logiciel libre est un exemple d’ordre spontané dans le sens où l’entend Hume. Puisque les personnes qui y travaillent ne peuvent en retirer qu’un maigre profit et qu’il est distribué gratuitement, l’argent y tient peu de place. Dans le logiciel libre les communautés s’associent librement et travaillent ensemble à la création de logiciels auxquels la société dans son ensemble accorde de la valeur.

Il existe cependant quelques signes susceptibles d’influencer les projets sur lesquels les développeurs décident de travailler. Par exemple, si les utilisateurs d’un logiciel libre trouvent une meilleure alternative, ils vont probablement migrer vers celle-ci. Les développeurs, peu désireux de coder des logiciels qui risquent de n’être utilisés par personne, pourraient bien eux aussi aller voir ailleurs et travailler sur de nouveaux projets que les gens trouveront plus utiles.

De cette façon, et sans incitation au profit, les développeurs de logiciels libres concentrent réellement leurs efforts dans les domaines qui seront les plus utiles au plus grand nombre, c’est-à-dire pour le plus grand bien de la société dans son ensemble.

Traduction Framalang : ga3lig, Coco, Aa, Lignusta, goofy, jcr83, peupleLa (relectures), Sylvain, CoudCoud, lamessen + Julius22

Préparez-vous pour le futur : l’évolution des équipes dans le logiciel libre et open source

par Felipe Ortega

Felipe Ortega est chercheur et chef de projet à Libresoft, un groupe de recherche de l’Université Rey Juan Carlos [1] en Espagne. Il développe de nouvelles méthodologies pour analyser les communautés collaboratives ouvertes (comme les projets de logiciels libres, Wikipédia et les réseaux sociaux). Il a mené des recherches approfondies sur le projet Wikipédia et sa communauté de contributeurs. Felipe participe activement à la recherche, la promotion et l’éducation/formation sur le logiciel libre, plus particulièrement dans le cadre du Master « Logiciel libre » de l’URJC [2]. C’est un fervent défenseur de l’ouverture des ressources éducatives, du libre accès aux publications scientifiques et de l’ouverture des données scientifiques.

Dans son célèbre essai La Cathédrale et le Bazar [1], Eric S. Raymond souligne l’une des plus importantes leçons que chaque développeur doit apprendre : « Un bon logiciel commence toujours par un développeur qui gratte là où ça le démange ». Vous ne pouvez comprendre à quel point cette phrase est vraie avant d’avoir vous-même vécu la situation. En fait, la majorité des programmeurs de logiciels libres et open source (si ce n’est tous) est certainement passée par cette étape où il faut mettre les mains dans le cambouis sur un tout nouveau projet, ou en rejoindre un, désireux d’aider à le rendre meilleur. Cependant, de nombreux développeurs et autres participants dans les communautés libres et open source (rédacteurs de documentation, traducteurs etc.) négligent généralement une autre importante leçon soulignée par Raymond plus loin dans son essai : « Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent ». C’est le thème central que je veux traiter ici. Vous devez penser à l’avenir de votre projet, et aux nouveaux arrivants qui un jour prendront le relais et continueront de le faire avancer.

Le relais entre les générations

Tôt ou tard, de nombreux projets libres et open source devront faire face à un relais générationnel. Les anciens développeurs en charge de la maintenance du code et des améliorations finissent par quitter le projet et sa communauté pour des raisons diverses et variées. Il peut s’agir de problèmes personnels, d’un nouveau travail qui ne laisse pas assez de disponibilités, d’un nouveau projet qui démarre, ou du passage à un autre projet qui semble plus attirant… la liste peut être assez longue.

L’étude du relais générationnel (ou renouvellement des développeurs) dans les projets de logiciel libre et open source reste un domaine émergent qui nécessite davantage de recherches pour améliorer notre compréhension de ces situations. En dépit de cela, certains chercheurs ont déjà collecté des preuves objectives qui mettent en lumière certains processus. Pendant l’OSS 2006 (NdT : Conférence sur l’Open Source System [4]), mes collègues Jesús González-Barahona et Gregorio Robles présentèrent un travail intitulé « Le renouvellement des contributeurs dans les projets de logiciel libre ». Dans cette présentation, ils exposèrent une méthodologie pour identifier les développeurs les plus actifs – généralement connus comme les développeurs principaux – à différents moments, pendant toute la durée d’un projet donné. Ils appliquèrent ensuite cette méthode à l’étude de 21 gros projets, en particulier Gimp [5], Mozilla [6] et Evolution [7]. En bref, ils ont découvert qu’on peut distinguer trois types de projets en fonction du taux de renouvellement des développeurs.

• Les projets avec des dieux du code : ces projets reposent en grande partie sur le travail de leurs fondateurs et le relais générationnel est très faible, voire nul. Gimp se classe dans cette catégorie.

• Les projets avec de multiples générations de codeurs : des projets comme Mozilla montrent clairement un modèle de renouvellement des développeurs, avec de nouveaux groupes actifs qui prennent en main la gestion du développement et de la maintenance du code des mains mêmes du noyau des anciens contributeurs.

• Les projets composites : Evolution appartient à une troisième catégorie de projets ; il connaît un certain taux de renouvellement, mais celui-ci n’est toutefois pas aussi marqué que pour les projets de la catégorie précédente, parce qu’atténué par la rétention de certains des principaux contributeurs au cours de l’histoire du projet.

Cette classification nous amène à une question évidente : quel est le modèle le plus fréquemment rencontré dans les projets de logiciels libre et open source ? Pour tout dire, les résultats de l’analyse menée sur l’échantillon de 21 projets lors de ces travaux établissent clairement cette conclusion : ce sont les projets à multiples générations, ainsi que les projets composites qui sont les plus communément rencontrés dans l’écosystème des projets libres et open source. Seuls Gnumeric et Mono ont montré un modèle distinct avec une forte rétention d’anciens développeurs, ceci indiquant que les personnes contribuant à ces projets auraient de plus fortes raisons de continuer leurs travaux sur le long terme.

Cependant ce n’est pas le cas le plus courant. Au contraire, cette étude donne plus de légitimité au conseil suivant : nous devons préparer, à plus ou moins long terme, le transfert de notre rôle et de nos connaissances au sein du projet vers les futurs contributeurs qui rejoignent notre communauté.

Le fossé de connaissances

Toute personne faisant face à un changement significatif dans sa vie doit s’adapter à de nouvelles conditions. Par exemple, quand vous quittez votre emploi pour un autre, vous vous préparez à une période pendant laquelle il vous faudra vous intégrer dans un autre groupe de travail, dans un nouveau lieu. Heureusement, au bout d’un moment vous aurez pris vos marques dans ce nouvel emploi. Mais parfois vous aurez gardé de bons amis de votre ancien boulot, et vous vous reverrez après avoir bougé. Parfois alors, en discutant avec des anciens collègues, vous pourrez savoir ce qu’il est advenu avec la personne recrutée pour vous remplacer. Cela ne se produit que rarement dans les projets open source.

Le revers du relais générationnel dans un projet libre peut apparaitre sous une forme très concrète, à savoir un fossé de connaissances. Quand un ancien développeur quitte le projet, et particulièrement s’il avait une expérience approfondie dans cette communauté, il laisse derrière lui ses connaissances aussi bien concrètes qu’abstraites, qui ne sont pas forcément transmises aux nouveaux venus.

Un exemple évident, est le code source. Comme dans toute production intellectuelle bien faite – du moins, c’est ce à quoi on pourrait s’attendre, non ? – les développeurs laissent une marque personnelle chaque fois qu’ils écrivent du nouveau code. Parfois, vous avez l’impression d’avoir une dette éternelle envers le programmeur qui a écrit ce code élégant et soigné qui parle de lui-même et qui est facile à maintenir. D’autres fois, la situation est inverse et vous bataillez pour comprendre un code très obscur sans un seul commentaire ni indice pour vous aider.

C’est ce que l’on a essayé de mesurer en 2009, dans une recherche présentée à l’HICSS 2009 (NdT : Hawaii International Conference on System Sciences [8]). Le titre en est « Utiliser l’archéologie logicielle pour mesurer les pertes de connaissances provoquées par le départ d’un développeur ». Au cas où vous vous poseriez la question, cela n’a rien à voir avec des histoires de fouet, de trésors, de temples, et autres aventures palpitantes. Ce qui a été mesuré, entre autres choses, c’est le pourcentage de code orphelin laissé par les développeurs ayant quitté des projets libre et/ou open source, et qu’aucun des développeurs actuels n’a encore repris. Pour cette étude, nous avons choisi quatre projets (Evolution, GIMP, Evince et Nautilus) pour tester la méthode de recherche. Et nous sommes arrivés à des résultats assez intéressants.

Evolution présentait une tendance plutôt inquiétante car le taux de code orphelin augmentait au cours du temps. En 2006, près de 80 % de l’ensemble des lignes de code avaient été abandonnées par les précédents développeurs et étaient restées intouchées par le reste de l’équipe. À l’opposé, Gimp affichait un modèle tout à fait différent, avec une volonté claire et soutenue par l’équipe de développement de réduire le nombre de lignes orphelines. Souvenons-nous au passage que Gimp avait déjà été qualifié de projet des dieux du code et bénéficiait donc d’une équipe de développement bien plus stable pour surmonter cette tâche harassante.

Cela signifie-t-il que les développeurs de Gimp avaient une bien meilleure expérience que ceux d’Evolution ? Honnêtement, on n’en sait rien. Néanmoins, on peut prévoir un risque clair : plus le taux de code orphelin est élevé, plus l’effort à fournir pour maintenir le projet est important. Que ce soit pour corriger un bogue, développer une nouvelle fonctionnalité ou en étendre une préexistante, il faut faire face à du code que l’on n’a jamais vu auparavant. Bien sûr les programmeurs d’exception existent, mais peu importe à quel point l’on est merveilleux, les développeurs de Gimp ont un avantage certain ici, puisqu’ils ont quelqu’un dans l’équipe qui a une connaissance précise de la majorité du code à maintenir. De plus, ils travaillent à réduire la portion de code inconnu au cours du temps.

C’est comme à la maison

Ce qui est intéressant, c’est que certains projets parviennent à retenir les utilisateurs sur des périodes bien plus longues qu’on aurait pu s’y attendre. Là encore, nous pouvons trouver des preuves empiriques justifiant cette déclaration. Pendant l’OSS 2005 [9], Michlmayr, Robles et González-Barahona présentèrent des résultats pertinents concernant cet aspect. Ils étudièrent la persistance de la participation des responsables de logiciels sur Debian en calculant ce qu’on appelle la demi-vie. C’est le temps nécessaire à une population donnée de développeurs principaux pour perdre la moitié de sa taille initiale. Le résultat fut que la demi-vie estimée des responsables Debian était approximativement de 7 ans et demi. En d’autres termes, l’étude ayant été menée sur une période de six ans et demi (entre juillet 1998 et décembre 2004), donc depuis Debian 2.0 jusqu’à Debian 3.1 (versions stables uniquement), plus de 50 % des responsables de Debian 2.0 contribuaient encore à Debian 3.1.

Debian a créé une sorte de procédure très formelle pour accepter de nouveaux codeurs logiciels (aussi connus sous le nom de développeurs Debian) qui inclut l’acceptation du Contrat Social Debian et la démonstration d’une bonne connaissance de la Politique Debian. Résultat, on peut s’attendre à avoir des contributeurs très engagés. C’est en effet le cas, puisque les auteurs de l’étude ont constaté que les paquets délaissés par les anciens développeurs étaient généralement repris par d’autres développeurs de la communauté. C’est seulement dans le cas où le paquet n’était plus utile qu’il a été abandonné. Je pense que nous pouvons tirer quelques conclusions de ces travaux de recherche :

1. Passez du temps à développer les principales lignes directrices de votre projet. Cela peut commencer par un seul et court document, qui détaille simplement des recommandations et des bonnes pratiques. Cela peut évoluer à mesure que le projet grandit, et permettre aux nouveaux arrivants tant de saisir rapidement les valeurs principales de votre équipe, qu’à comprendre les traits principaux de votre méthodologie.
2. Forcez-vous à suivre des standards de codage, des bonnes pratiques et un style élégant. Documentez votre code. Insérez des commentaires pour décrire les sections qui seraient particulièrement difficiles à comprendre. Ne pensez pas que c’est du temps perdu. En fait, vous faites preuve de pragmatisme en investissant du temps dans l’avenir de votre projet.
3. Dans la mesure du possible, lorsque le moment vient pour vous de quitter le projet, essayez d’avertir les autres de cette décision longtemps à l’avance. Assurez-vous qu’ils comprennent quelles parties essentielles du code nécessiteront un nouveau développeur pour le maintenir. Idéalement, si vous formez une communauté, préparez au moins une procédure simple afin d’automatiser la transition, et assurez-vous de n’oublier aucun point important avant que la personne ne quitte le projet (particulièrement si celle-ci est un développeur clé).
4. Gardez un œil sur la quantité de code orphelin. Si celle-ci augmente trop rapidement, ou si elle atteint une trop grande proportion de votre projet, cela indique clairement que vous allez avoir des problèmes dans peu de temps, en particulier si le nombre de rapports de bogues augmente ou si vous envisagez une nouvelle implémentation de votre code avec de fortes modifications.
5. Assurez-vous de toujours laisser assez d’astuces et de commentaires pour qu’à l’avenir un nouvel arrivant puisse s’approprier votre travail.

J’aurais voulu savoir que vous arriviez (avant de partir)

Je reconnais que ce n’est pas très facile de penser à ses successeurs lorsque vous programmez. La plupart du temps, vous ne vous rendez tout simplement pas compte que votre code pourrait à la fin être repris par un autre projet, réutilisé par d’autres personnes ou que vous pourriez éventuellement être remplacé par un autre, qui continuera votre travail après vous. Cependant, le plus remarquable atout des logiciels libres et open source est précisément celui-là : le code sera réutilisé, adapté, intégré ou exporté par quelqu’un d’autre. La maintenance est une composante essentielle de l’ingénierie logicielle. Mais cela devient primordial dans le cas des logiciels libres et open source. Ce n’est pas seulement une question de code source. Cela concerne aussi les relations humaines et la netiquette. C’est quelque chose qui va au-delà du bon goût. Quod severis metes (« On récolte ce que l’on a semé »). Souvenez-vous en. La prochaine fois, vous pourriez être le nouveau venu qui viendra combler le vide de connaissance laissé par un ancien développeur.

[1] http://www.urjc.es

[2] http://www.urjc.es/estudios/masteres_universitarios/ingenieria/software_libre/index.htm

[3] http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar.html

[4] http://oss2006.org

[5]  logiciel de création graphique, http://www.gimp.org

[6] https://www.mozilla.org/fr/firefox/fx/

[7] logiciel de messagerie, http://projects.gnome.org/evolution

[8] archives de la conférence, http://www.informatik.uni-trier.de/~ley/db/conf/hicss/hicss2009.html

[9] http://oss2005.case.unibz.it

Traduction Framalang : ga3lig, Coco, Aa, Lignusta, goofy, jcr83, peupleLa (relectures), Sylvain, CoudCoud, lamessen + Julius22

Préparez-vous pour le futur : l’évolution des équipes dans le logiciel libre et open source

par Felipe Ortega

Felipe Ortega est chercheur et chef de projet à Libresoft, un groupe de recherche de l’Université Rey Juan Carlos [1] en Espagne. Il développe de nouvelles méthodologies pour analyser les communautés collaboratives ouvertes (comme les projets de logiciels libres, Wikipédia et les réseaux sociaux). Il a mené des recherches approfondies sur le projet Wikipédia et sa communauté de contributeurs. Felipe participe activement à la recherche, la promotion et l’éducation/formation sur le logiciel libre, plus particulièrement dans le cadre du Master « Logiciel libre » de l’URJC [2]. C’est un fervent défenseur de l’ouverture des ressources éducatives, du libre accès aux publications scientifiques et de l’ouverture des données scientifiques.

Dans son célèbre essai La Cathédrale et le Bazar [1], Eric S. Raymond souligne l’une des plus importantes leçons que chaque développeur doit apprendre : « Un bon logiciel commence toujours par un développeur qui gratte là où ça le démange ». Vous ne pouvez comprendre à quel point cette phrase est vraie avant d’avoir vous-même vécu la situation. En fait, la majorité des programmeurs de logiciels libres et open source (si ce n’est tous) est certainement passée par cette étape où il faut mettre les mains dans le cambouis sur un tout nouveau projet, ou en rejoindre un, désireux d’aider à le rendre meilleur. Cependant, de nombreux développeurs et autres participants dans les communautés libres et open source (rédacteurs de documentation, traducteurs etc.) négligent généralement une autre importante leçon soulignée par Raymond plus loin dans son essai : « Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent ». C’est le thème central que je veux traiter ici. Vous devez penser à l’avenir de votre projet, et aux nouveaux arrivants qui un jour prendront le relais et continueront de le faire avancer.

Le relais entre les générations

Tôt ou tard, de nombreux projets libres et open source devront faire face à un relais générationnel. Les anciens développeurs en charge de la maintenance du code et des améliorations finissent par quitter le projet et sa communauté pour des raisons diverses et variées. Il peut s’agir de problèmes personnels, d’un nouveau travail qui ne laisse pas assez de disponibilités, d’un nouveau projet qui démarre, ou du passage à un autre projet qui semble plus attirant… la liste peut être assez longue.

L’étude du relais générationnel (ou renouvellement des développeurs) dans les projets de logiciel libre et open source reste un domaine émergent qui nécessite davantage de recherches pour améliorer notre compréhension de ces situations. En dépit de cela, certains chercheurs ont déjà collecté des preuves objectives qui mettent en lumière certains processus. Pendant l’OSS 2006 (NdT : Conférence sur l’Open Source System [4]), mes collègues Jesús González-Barahona et Gregorio Robles présentèrent un travail intitulé « Le renouvellement des contributeurs dans les projets de logiciel libre ». Dans cette présentation, ils exposèrent une méthodologie pour identifier les développeurs les plus actifs – généralement connus comme les développeurs principaux – à différents moments, pendant toute la durée d’un projet donné. Ils appliquèrent ensuite cette méthode à l’étude de 21 gros projets, en particulier Gimp [5], Mozilla [6] et Evolution [7]. En bref, ils ont découvert qu’on peut distinguer trois types de projets en fonction du taux de renouvellement des développeurs.

• Les projets avec des dieux du code : ces projets reposent en grande partie sur le travail de leurs fondateurs et le relais générationnel est très faible, voire nul. Gimp se classe dans cette catégorie.

• Les projets avec de multiples générations de codeurs : des projets comme Mozilla montrent clairement un modèle de renouvellement des développeurs, avec de nouveaux groupes actifs qui prennent en main la gestion du développement et de la maintenance du code des mains mêmes du noyau des anciens contributeurs.

• Les projets composites : Evolution appartient à une troisième catégorie de projets ; il connaît un certain taux de renouvellement, mais celui-ci n’est toutefois pas aussi marqué que pour les projets de la catégorie précédente, parce qu’atténué par la rétention de certains des principaux contributeurs au cours de l’histoire du projet.

Cette classification nous amène à une question évidente : quel est le modèle le plus fréquemment rencontré dans les projets de logiciels libre et open source ? Pour tout dire, les résultats de l’analyse menée sur l’échantillon de 21 projets lors de ces travaux établissent clairement cette conclusion : ce sont les projets à multiples générations, ainsi que les projets composites qui sont les plus communément rencontrés dans l’écosystème des projets libres et open source. Seuls Gnumeric et Mono ont montré un modèle distinct avec une forte rétention d’anciens développeurs, ceci indiquant que les personnes contribuant à ces projets auraient de plus fortes raisons de continuer leurs travaux sur le long terme.

Cependant ce n’est pas le cas le plus courant. Au contraire, cette étude donne plus de légitimité au conseil suivant : nous devons préparer, à plus ou moins long terme, le transfert de notre rôle et de nos connaissances au sein du projet vers les futurs contributeurs qui rejoignent notre communauté.

Le fossé de connaissances

Toute personne faisant face à un changement significatif dans sa vie doit s’adapter à de nouvelles conditions. Par exemple, quand vous quittez votre emploi pour un autre, vous vous préparez à une période pendant laquelle il vous faudra vous intégrer dans un autre groupe de travail, dans un nouveau lieu. Heureusement, au bout d’un moment vous aurez pris vos marques dans ce nouvel emploi. Mais parfois vous aurez gardé de bons amis de votre ancien boulot, et vous vous reverrez après avoir bougé. Parfois alors, en discutant avec des anciens collègues, vous pourrez savoir ce qu’il est advenu avec la personne recrutée pour vous remplacer. Cela ne se produit que rarement dans les projets open source.

Le revers du relais générationnel dans un projet libre peut apparaitre sous une forme très concrète, à savoir un fossé de connaissances. Quand un ancien développeur quitte le projet, et particulièrement s’il avait une expérience approfondie dans cette communauté, il laisse derrière lui ses connaissances aussi bien concrètes qu’abstraites, qui ne sont pas forcément transmises aux nouveaux venus.

Un exemple évident, est le code source. Comme dans toute production intellectuelle bien faite – du moins, c’est ce à quoi on pourrait s’attendre, non ? – les développeurs laissent une marque personnelle chaque fois qu’ils écrivent du nouveau code. Parfois, vous avez l’impression d’avoir une dette éternelle envers le programmeur qui a écrit ce code élégant et soigné qui parle de lui-même et qui est facile à maintenir. D’autres fois, la situation est inverse et vous bataillez pour comprendre un code très obscur sans un seul commentaire ni indice pour vous aider.

C’est ce que l’on a essayé de mesurer en 2009, dans une recherche présentée à l’HICSS 2009 (NdT : Hawaii International Conference on System Sciences [8]). Le titre en est « Utiliser l’archéologie logicielle pour mesurer les pertes de connaissances provoquées par le départ d’un développeur ». Au cas où vous vous poseriez la question, cela n’a rien à voir avec des histoires de fouet, de trésors, de temples, et autres aventures palpitantes. Ce qui a été mesuré, entre autres choses, c’est le pourcentage de code orphelin laissé par les développeurs ayant quitté des projets libre et/ou open source, et qu’aucun des développeurs actuels n’a encore repris. Pour cette étude, nous avons choisi quatre projets (Evolution, GIMP, Evince et Nautilus) pour tester la méthode de recherche. Et nous sommes arrivés à des résultats assez intéressants.

Evolution présentait une tendance plutôt inquiétante car le taux de code orphelin augmentait au cours du temps. En 2006, près de 80 % de l’ensemble des lignes de code avaient été abandonnées par les précédents développeurs et étaient restées intouchées par le reste de l’équipe. À l’opposé, Gimp affichait un modèle tout à fait différent, avec une volonté claire et soutenue par l’équipe de développement de réduire le nombre de lignes orphelines. Souvenons-nous au passage que Gimp avait déjà été qualifié de projet des dieux du code et bénéficiait donc d’une équipe de développement bien plus stable pour surmonter cette tâche harassante.

Cela signifie-t-il que les développeurs de Gimp avaient une bien meilleure expérience que ceux d’Evolution ? Honnêtement, on n’en sait rien. Néanmoins, on peut prévoir un risque clair : plus le taux de code orphelin est élevé, plus l’effort à fournir pour maintenir le projet est important. Que ce soit pour corriger un bogue, développer une nouvelle fonctionnalité ou en étendre une préexistante, il faut faire face à du code que l’on n’a jamais vu auparavant. Bien sûr les programmeurs d’exception existent, mais peu importe à quel point l’on est merveilleux, les développeurs de Gimp ont un avantage certain ici, puisqu’ils ont quelqu’un dans l’équipe qui a une connaissance précise de la majorité du code à maintenir. De plus, ils travaillent à réduire la portion de code inconnu au cours du temps.

C’est comme à la maison

Ce qui est intéressant, c’est que certains projets parviennent à retenir les utilisateurs sur des périodes bien plus longues qu’on aurait pu s’y attendre. Là encore, nous pouvons trouver des preuves empiriques justifiant cette déclaration. Pendant l’OSS 2005 [9], Michlmayr, Robles et González-Barahona présentèrent des résultats pertinents concernant cet aspect. Ils étudièrent la persistance de la participation des responsables de logiciels sur Debian en calculant ce qu’on appelle la demi-vie. C’est le temps nécessaire à une population donnée de développeurs principaux pour perdre la moitié de sa taille initiale. Le résultat fut que la demi-vie estimée des responsables Debian était approximativement de 7 ans et demi. En d’autres termes, l’étude ayant été menée sur une période de six ans et demi (entre juillet 1998 et décembre 2004), donc depuis Debian 2.0 jusqu’à Debian 3.1 (versions stables uniquement), plus de 50 % des responsables de Debian 2.0 contribuaient encore à Debian 3.1.

Debian a créé une sorte de procédure très formelle pour accepter de nouveaux codeurs logiciels (aussi connus sous le nom de développeurs Debian) qui inclut l’acceptation du Contrat Social Debian et la démonstration d’une bonne connaissance de la Politique Debian. Résultat, on peut s’attendre à avoir des contributeurs très engagés. C’est en effet le cas, puisque les auteurs de l’étude ont constaté que les paquets délaissés par les anciens développeurs étaient généralement repris par d’autres développeurs de la communauté. C’est seulement dans le cas où le paquet n’était plus utile qu’il a été abandonné. Je pense que nous pouvons tirer quelques conclusions de ces travaux de recherche :

1. Passez du temps à développer les principales lignes directrices de votre projet. Cela peut commencer par un seul et court document, qui détaille simplement des recommandations et des bonnes pratiques. Cela peut évoluer à mesure que le projet grandit, et permettre aux nouveaux arrivants tant de saisir rapidement les valeurs principales de votre équipe, qu’à comprendre les traits principaux de votre méthodologie.
2. Forcez-vous à suivre des standards de codage, des bonnes pratiques et un style élégant. Documentez votre code. Insérez des commentaires pour décrire les sections qui seraient particulièrement difficiles à comprendre. Ne pensez pas que c’est du temps perdu. En fait, vous faites preuve de pragmatisme en investissant du temps dans l’avenir de votre projet.
3. Dans la mesure du possible, lorsque le moment vient pour vous de quitter le projet, essayez d’avertir les autres de cette décision longtemps à l’avance. Assurez-vous qu’ils comprennent quelles parties essentielles du code nécessiteront un nouveau développeur pour le maintenir. Idéalement, si vous formez une communauté, préparez au moins une procédure simple afin d’automatiser la transition, et assurez-vous de n’oublier aucun point important avant que la personne ne quitte le projet (particulièrement si celle-ci est un développeur clé).
4. Gardez un œil sur la quantité de code orphelin. Si celle-ci augmente trop rapidement, ou si elle atteint une trop grande proportion de votre projet, cela indique clairement que vous allez avoir des problèmes dans peu de temps, en particulier si le nombre de rapports de bogues augmente ou si vous envisagez une nouvelle implémentation de votre code avec de fortes modifications.
5. Assurez-vous de toujours laisser assez d’astuces et de commentaires pour qu’à l’avenir un nouvel arrivant puisse s’approprier votre travail.

J’aurais voulu savoir que vous arriviez (avant de partir)

Je reconnais que ce n’est pas très facile de penser à ses successeurs lorsque vous programmez. La plupart du temps, vous ne vous rendez tout simplement pas compte que votre code pourrait à la fin être repris par un autre projet, réutilisé par d’autres personnes ou que vous pourriez éventuellement être remplacé par un autre, qui continuera votre travail après vous. Cependant, le plus remarquable atout des logiciels libres et open source est précisément celui-là : le code sera réutilisé, adapté, intégré ou exporté par quelqu’un d’autre. La maintenance est une composante essentielle de l’ingénierie logicielle. Mais cela devient primordial dans le cas des logiciels libres et open source. Ce n’est pas seulement une question de code source. Cela concerne aussi les relations humaines et la netiquette. C’est quelque chose qui va au-delà du bon goût. Quod severis metes (« On récolte ce que l’on a semé »). Souvenez-vous en. La prochaine fois, vous pourriez être le nouveau venu qui viendra combler le vide de connaissance laissé par un ancien développeur.

[1] http://www.urjc.es

[2] http://www.urjc.es/estudios/masteres_universitarios/ingenieria/software_libre/index.htm

[3] http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar.html

[4] http://oss2006.org

[5]  logiciel de création graphique, http://www.gimp.org

[6] https://www.mozilla.org/fr/firefox/fx/

[7] logiciel de messagerie, http://projects.gnome.org/evolution

[8] archives de la conférence, http://www.informatik.uni-trier.de/~ley/db/conf/hicss/hicss2009.html

[9] http://oss2005.case.unibz.it

Avec ce sourire, nous en profitons pour vous remercier chaleureusement de votre soutien cette année, qu’il s’agisse d’un don^[1], d’une participation ou tout simplement en diffusant la bonne parole du Libre autour de vous.

Rendez-vous en 2013, parce qu’il reste encore plein de sales gosses à convertir 😉

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)