Ce n’est pas Framasoft qui vous dira le contraire, on peut contribuer au logiciel libre et faire ainsi partie de sa communauté sans être nécessairement un développeur de logiciel libre.

Rédiger de la documentation, signaler un bug, traduire, donner, etc. il y a plein de manières de participer, à commencer par les utiliser et le faire savoir.

Comment les non-programmeurs peuvent contribuer aux projets open source

How non-programmers can contribute to open source projects

Duncan McKean – 4 juin 2013 – Blog personnel
(Traduction : « Anonymes », nos excuses car un bug Framapad empêche de citer tous les traducteurs/ices que nous remercions au passage)

Beaucoup de gens intéressés par l’idée d’apporter leur aide à des projets open source mais n’ayant absolument aucune compétence en programmation m’ont demandé ce qu’ils pouvaient faire. Eh bien, voici quelques moyens pour ces non-programmeurs de contribuer à de tels projets.

Il est important de noter qu’il est bon de contribuer aux projets des logiciels que vous utilisez. Ainsi, vous pourrez vous-même bénéficier de vos contributions.

Utilisez le logiciel

Le meilleur moyen de contribuer à des projets open source est d’utiliser les produits eux-mêmes. Écrivez votre livre avec Libre Office Writer. Dessinez vos images avec Krita. Créez des choses à imprimer en 3D avec FreeCAD ou Blender. Réservez vos tickets de concert en ligne via Firefox. Faites vos comptes avec Grisbi. Jouez à Flightgear, Battle for Wesnoth, Vega Strike, UFO : Alien Invasion.

Traquez les bugs

Maintenant que vous utilisez le logiciel, vous pouvez éventuellement rencontrer des bugs quand vous essayez de faire quelque chose. Ou alors, le logiciel peut avoir un comportement autre que celui qui était attendu.

Entrez en contact avec les développeurs et prévenez-les. Les développeurs travaillent sur les retours de leurs utilisateurs, ceci les aide à perfectionner le produit. De plus, les sources étant libres, les bugs sont en général rapidement corrigés.

Chaque projet aura un lien pour signaler un bug. Allez-y, identifiez-vous et décrivez ce bug dans les détails. N’oubliez pas d’indiquer quelle version du logiciel vous utilisez ainsi que les caractéristiques de votre ordinateur.

Écrivez de la documentation

Contribuer à écrire la documentation d’un projet pour le rendre plus clair et plus simple à comprendre.

La plupart du temps, les développeurs sont trop occupés à coder et la documentation a besoin d’un peu d’attention. Vous pouvez la mettre en forme afin qu’elle soit plus claire, ajouter des images ou des tutoriels. Si certaines parties du projet ne sont pas claires, il suffit de demander sur les listes de diffusion. Ainsi, lorsque vous recevrez une réponse, vous pourrez l’ajouter à la documentation. Dès que les personnes qui maintiennent le projet saisiront ce que vous faites, leurs réponses seront encore plus efficaces et utiles.

Traduisez

Il y a beaucoup de personnes dans le monde qui utilisent ce projet et certaines d’entre elles pourraient ne pas parler la langue dans laquelle celui-ci a été distribué. Si vous parlez couramment un langage peu connu, contactez les développeurs/l’équipe de documentation et offrez vos services. Vous pourriez participer à la traduction de l’interface, de la documentation ou encore du site web.

Offrez vos compétences

Regardez les projets individuels et voyez ce dont ils ont besoin. Vous pouvez apporter quelque chose ? Vous êtes designer sonore et pourriez créer quelques sons pour un jeu vidéo open source ? Concepteur d’interface ? Vous pourriez aider en remaniant l’interface utilisateur pour la rendre plus ergonomique. Il est également possible de lancer des entreprises viables utilisant ou formant aux logiciels open source.

Vous pouvez aussi contribuer à la culture du libre en publiant ce que vous créez sous certaines licences Creative Commons. Vos créations peuvent ainsi aider à promouvoir le logiciel pour lequel elles ont été créées. Ceci inclut :

• les images ;
• les programmes ;
• les tutoriels ;
• les manuels d’installation et de documentation ;
• les livres.

Utilisez la licence CC BY-SA pour que chaque réutilisation de votre travail soit elle aussi placée sous licence libre, CC BY si la façon dont il est réutilisé vous importe peu. Vous trouverez plus d’informations à ce sujet sur le site des Creative Commons.

Prêchez la bonne parole

Aider à la prise de conscience des projets open-source est très important. N’agressez pas tout le monde, faites juste savoir quels projets vous utilisez. Créé avec MyPaint sous LinuxMint. Écrit en Sigil sous Ubuntu. Je suis fier d’utiliser WordPress. Toutes ces mentions sont utiles.

Faites des dons

Enfin, leur donner de l’argent. Avec de l’argent, le projet peut embaucher des développeurs supplémentaires qui pourront corriger des bugs plus rapidement, créer de nouveau outils, les améliorer pour vous. Certains projets proposent des dons occasionnels, alors que d’autres vous permettent de payer de petites sommes mensuellement. C’est une meilleure idée car cela aide les développeurs à mieux gérer leurs revenus quand ils savent quelle somme d’argent ils reçoivent de façon sûre.

Soyez professionnel

L’une des principales critiques faites aux logiciels open source est le manque de professionnalisme. Peu importe la manière dont vous contribuez à un projet open source, mettez un point d’honneur à le faire de façon professionnelle. L’élévation du niveau de qualité d’un projet commence avec ses utilisateurs. Assurez-vous que vous agissez de manière professionnelle lorsque vous discutez de projets avec d’autres et créez des contributions de qualité quand vous utilisez des logiciels open source.

Maintenant que vous savez tout ça, lancez-vous et allez aider à rendre les projets open source géniaux.

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

Éric Bruillard est professeur au STEF – ENS Cachan.

L’article ci-dessous reprend une présentation faite le 15 décembre 2012 lors des Rencontres Wikimédia, à l’université Paris Descartes.

Remarque : Vous pouvez également accéder directement à la version ODT et PDF du document.

Wikipédia face aux institutions

Éric Bruillard – décembre 2012

Introduction

Il y a cinq ans, en mars 2007, j’avais écrit un article intitulé « Wikipédia : la rejeter ou la domestiquer ». J’avançais l’idée, qui a souvent été mal comprise, que Wikipédia ne pouvait pas « avoir une présence reconnue dans l’enseignement en France, ses principes mêmes (neutralité) n’étant pas compatibles avec les valeurs de l’école laïque et républicaine française, valeurs qui conduisent à privilégier certains points de vue et à en interdire d’autres ». J’ajoutais que Wikipédia pouvait cependant avoir une place, d’une part comme projet encyclopédique avec des participations actives à ce projet, comme faire écrire des articles à des élèves, et, d’autre part, comme une encyclopédie à laquelle beaucoup auraient recours, dans une posture de consommateur.

Ces deux directions ont été effectivement suivies, et des utilisations constructives sont repérables dans l’enseignement secondaire ou supérieur, quoique la « consommation » est certainement beaucoup plus développée que la participation. Mais Wikipédia aurait-elle maintenant une présence reconnue dans l’éducation ?

Dans un premier temps, nous allons tenter de situer les discours généraux sur Wikipédia, notamment dans l’éducation nationale. Ensuite, nous verrons en quoi Wikipédia est maintenant une véritable institution, statut qui n’est pas sans poser de nouvelles questions. Enfin nous traiterons la question de l’évaluation des articles de cette encyclopédie : une évaluation interne s’est installée alors que l’évaluation externe ne semble pas beaucoup progresser : serait-ce révélateur de relations encore difficiles avec un projet collectif que l’on a toujours du mal à appréhender ?

Wikipédia : quoi de neuf depuis 2007 ?

Le premier constat que l’on peut faire, sans avoir spécialement besoin de l’étayer, est celui de la croissance impressionnante du projet Wikipédia : une présence très importante (notamment via Google), des utilisations qui se multiplient, notamment dans l’éducation, de nouveaux projets associés…

Pourtant, face à ce formidable déploiement, on s’aperçoit, notamment à travers le discours d’étudiants ou d’enseignants, d’une méconnaissance persistante du fonctionnement de Wikipédia, d’idées reçues tenaces, d’utilisations contestées, d’interrogations sur la fiabilité…

Wikipedia nous aide d’ailleurs à cerner ce que qu’est une idée reçue : « une opinion, située entre le stéréotype, le cliché et le lieu commun », précisant qu’elle a « la particularité de s’admettre aisément » parce qu’elle est « très répandue, que celui qui la transmet la considère très souvent comme évidemment démontrée ; elle est agréable à admettre, parce qu’elle répond (le plus souvent simplement) à une question redondante, ou gênante, ou complexe : elle aide à ne plus réfléchir et s’impose insidieusement ». Justement, un peu de réflexion s’impose.

Comme il est possible à n’importe qui de créer ou modifier le contenu d’un article, que ce n’est pas réservé à des spécialistes, il ne semble pas possible qu’il y ait des articles de qualité et on ne peut en aucun cas s’en remettre à Wikipédia. Ce discours de sagesse populaire continue à être très souvent énoncé. Prenons juste un seul exemple : “Wikipedia is a free, web-based, collaborative, multilingual encyclopedia project. Anybody is able to change, add or remove articles on Wikipedia. This of course is prone to many problems as some authors may be: biased, vandalise the article or write incorrect information.”

Les études comparatives qui ont été menées attestent du contraire et l’expérience quotidienne de nombre d’entre nous montre qu’on lui fait malgré tout confiance. Peu d’études nouvelles sont disponibles. La seule étude récente est intitulée Assessing the accuracy and quality of Wikipedia entries compared to popular online encyclopaedias A preliminary comparative study across disciplines in English, Spanish and Arabic. Mais les auteurs remercient la Wikimedia Foundation pour son soutien financier. D’autres institutions ne sont sans doute intéressées à financer une évaluation des articles de Wikipedia, préférant laisser planer le doute et les idées reçues.

Quelle présence officielle dans l’éducation ?

Si la neutralité de l’éducation nationale française l’invite à ne pas citer de marque ou de nom de produit dans ses programmes officiels, sauf exception, elle est conduite à veiller sur ce qui est proposé. Une recherche sur le site officiel Eduscol atteste de la présence de Wikipédia.

On trouve des revues de presse ; un dossier déjà ancien sur les usages pédagogiques ; des recommandations, des définitions issues de Wikipédia, le fait que Wikipedia offre une nouvelle fonctionnalité (l’exportation de pages au format epub, ce qui permet de constituer une sélection d’articles à consulter hors ligne sur une liseuse ou sur smartphone).

On trouve également référence à Wikipedia dans des sujets de bac, des ressources pour la résolution de problèmes, des dossiers pédagogiques… mais avec le plus souvent des modes de citation approximatifs (cf page 2 de ce document). Dans les ressources pour la classe terminale générale et technologique, Physique-chimie, Série S (Eduscol), on trouve 10 références à Wikipédia.

Ce bref tour d’horizon nous en apprend plus sur le système éducatif que sur Wikipédia. Cette dernière apparaît pratique et très utile, mais demeure un motif récurrent de complaintes, attestant des difficultés (ou de l’incapacité ?) du système éducatif à traiter les évolutions en cours sur les savoirs, leur diffusion, leur mise en question… Une utilisation parfois « honteuse », que l’on peut rapprocher des usages des calculatrices en collège il y a quelques années^[1] : une sur utilisation, une maîtrise très diversifiée et un manque de formation des élèves. Au début du collège, utiliser la calculatrice est considéré comme une tricherie, il ne faudrait s’en servir que pour contrôler les résultats des opérations que l’on fait à la main. Mais dès la 4e, la tricherie est quelque sorte légalisée, notamment avec les fonctions trigonométriques, et ceux qui ont acquis une bonne maîtrise des calculatrices, sont alors avantagés. Le système éducatif prend peu en charge, voire pas du tout, la formation des élèves à cette maîtrise.

Wikipédia dans le site Eduscol – 10 décembre 2012

Les objets informatiques spécifiques du système éducatif ne sont pas bien traités par Wikipédia. Ainsi, l’article ENT est encore une ébauche de piètre qualité. On retrouve une même ébauche, non signalée comme telle, sur l’expression « manuel numérique », page modifiée pour la dernière fois le 28 juin 2010^[2]. C’est une version quasi « ministérielle » qui est proposée, la page « discussion » n’est pas ouverte et aucun article dans une autre langue n’est associé. Ce n’est toutefois par mieux en anglais où l’article “digital textbook” est une présentation du programme de ministère de l’éducation de Corée du Sud ! Les exemples sont coréens, avec des liens vers Toshiba et Fujitsu. Il s’agit d’un article sur le projet coréen, et pas sur l’initiative californienne par exemple.

Enfin, pour clore ce rapide tour d’horizon, un site de l’académie de Montpellier propose de « créer un manuel numérique à l’aide de Wikipédia ». Il est écrit : « Wikipédia est une excellente ressource pour construire un livre numérique dans le but d’explorer un sujet ou d’entamer une recherche documentaire. Pour inciter les étudiants à utiliser Wikipédia comme outil de départ plutôt que comme finalité d’une recherche, un enseignant peut facilement fournir à ses étudiants une collection d’articles de références sous la forme d’un livre numérique. Retrouvez les différentes étapes de création d’un livre numérique dans un mode opératoire mis à disposition sur le site “Prof Web”. »

Si on clique sur l’adresse indiquée, on retrouve le même paragraphe à la virgule près, puis un petit mode d’emploi. Tous les éléments sont présents : citation et même copié-collé. Un exemple mais avec la parapluie de la bonne pratique (il faut utiliser simplement comme point de départ). On se sert de Wikipedia mais d’une manière non risquée !!! On ne cherche pas à comprendre, mais à trouver une pratique que l’on considère légitime et que les autres ne pourront pas contester.

Cette méfiance persistante sur un projet maintenant très établi ne cache-t-elle pas des caractéristiques encore mal connues ou mal comprises. Et Wikipedia, s’il est encore regardé de travers par les institutions, ne serait-il pas aussi une institution ?

Wikipédia est une institution

En effet, pour la recherche, une simple interrogation sur Wikipedia dans Google Scholar produit de très nombreux résultats ; depuis 2011 : 45 700 résultats ; depuis 2012 : 23 100 résultats (à titre de comparaison, on obtient pour les mêmes dates concernant Britannica : 13100 / 7320). Dans les travaux auxquels on accède, il y a des études sur le fonctionnement même de Wikipédia : contenus, conflits, participation, etc. ; des outils pour Wikipédia.

Issus de son fonctionnement même, l’encyclopédie fournit des corpus très utiles pour les linguistes, notamment les paraphrases et modifications locales dans l’historique des révisions des articles, conduisant à améliorer les performances d’applications de TAL : traduction automatique, question-réponse, génération…

Encore plus intéressant, dans un processus d’institutionnalisation de Wikipédia, le projet Semanticpedia associe le ministère de la culture, l’INRIA et Wikimedia France. Cette collaboration vise à « réaliser des programmes de recherche et développement appliqués à des corpus ou des projets collaboratifs culturels, utilisant des données extraites des projets Wikimédia ». Il s’agit notamment de fournir des données culturelles accessibles à tous, dans une version Web sémantique structurée ; en gros devenir la référence pour la culture avec des modes d’interrogation très avancés dans des formes de déclaration sémantique.

Wikipédia est même vu comme un nouvel outil d’évaluation : une évaluation de la réputation ponctuelle, la fréquentation de Wikipédia étant considéré comme outil de mesure ; mais aussi, l’influence qu’une personne a sur un pays ou même sur une civilisation, qui pourrait être mesurée en fonction des liens menant à sa page Wikipédia.

Ainsi, Wikipédia est devenu outil de référence, même s’il s’en défend. C’est déjà un attracteur très puissant pour les recherches et, selon Kien Quach Tat^[3] (2011), au Vietnam, Wikipédia est ce qui permet aux lycéens de valider une information trouvée sur un autre site.

Quelle implication du fait que Wikipédia est une institution ? Peut-on être en dehors de Wikipédia ? Comme elle devient la référence, peut-on continuer à l’ignorer, si une information nous concernant est fausse, peut-on encore traiter cela par le mépris ou l’absence de réaction n’est pas une sorte d’acquiescement ? En tous cas, si Wikipedia gère très efficacement les vandalismes, on sait qu’elle est mal armée pour lutter contre des organisations qui cherchent à imposer leur point de vue. Un projet d’émancipation ne s’est-il pas transformé en un instrument de domination ? On n’en est pas (encore) là ! Demeure une question clé : comment évaluer un article de Wikipédia ?

Comment évaluer un article de Wikipédia ?

En 2007, Wikipédia précisait qu’elle n’avait pas les moyens de juger de la crédibilité d’une information et que la fondation cherchait des solutions à cette absence de validation du contenu des articles, notamment « par l’ajout de systèmes de notation, d’identification des versions non vandalisées et par des collaborations avec des chercheurs et des enseignants » (Bruillard, 2007). Des avancées importantes ont été réalisées. Wikipédia évalue elle-même les articles qu’elle produit. Ainsi, l’article Projet :Évaluation est consacré à « déterminer l’état des articles de Wikipédia selon deux critères : leur importance et leur avancement ».

Mais quelle évaluation externe peut-on trouver ?

Quand on lance la requête « évaluation article Wikipédia », via Google, environ 16 900 000 de résultats (0,42 secondes) sont fournis. Mais la grande majorité de ces résultats correspondent à des articles de Wikipedia. La requête « évaluer un article de Wikipédia » -wikipedia.org ne donne aucun résultat. Enlever les guillemets dans la requête conduit à 8 040 000 résultats (0,19 secondes). Que trouve-t-on ?

D’abord des conseils, il s’agit d’évaluer le nombre et la qualité des sources, de consulter l’historique (combien de personnes y ont contribué, et quand), de consulter l’évaluation de l’article et surtout de le comparer à d’autres sources !

Le tutoriel Cerise propose d’autres conseils :

• « Voir si le plan est bien construit et détaillé
• Juger de la qualité de la rédaction : syntaxe, orthographe, synthèse, illustration, …
• Repérer les liens vers les notes et les définitions
• Voir s’il y a une bibliographie récente et mise à jour
• Voir s’il y a un portail sur le thème sélectionné. »

Les guides de la BU de l’université de Rennes 2 dans une page sur « évaluer l’information » consacre un petit encart à Wikipédia en conseillant de regarder les avertissements sur les pages, la date de création (onglet “historique”) et les débats (onglet “discussion”). Cela renvoie à un article du Monde.fr et étrangemenent, aux évaluations internes de Wikipédia.

Sur la Teluq, Marc Couture, dans son cours sur l’évaluation de la crédibilité des documents en ligne, traite du cas particulier de « la crédibilité de Wikipédia ». Il constate que les critères généraux ne s’appliquent qu’imparfaitement aux articles de Wikipédia. Ainsi, ceux reliés à l’insertion dans la littérature spécialisée : « Ce critère prendra donc une valeur toute relative compte tenu à la fois du rôle que joue une encyclopédie dans la littérature scientifique ou savante, et de la difficulté à évaluer le nombre de références à un article de Wikipédia. » Les critères sur l’auteur ne sont pas applicables, les autres (la validation du contenu, forme et la structure du document) sont soit sans garantie soit réfèrent aux classements et processus internes de Wiipédia.

Cherchant dans les sources en anglais, on trouve de nouveau beaucoup de redondances, avec une référence citée, reprise, tronquée dans la Wikipedia anglaise. Un article intitulé Wikipedia:Researching with Wikipedia n’a pas d’équivalent en français avec la recommandation rituelle : “Wikipedia should be a starting place for research, not an end destination and independent confirmation of any fact presented is advised”.

Cet article fournit un lien avec une page sur l’évaluation des articles de Wikipédia, page que l’on retrouve ici (source Phoebe Ayers, en octobre 2006). En fait, ce texte donne tous les éléments pour évaluer un article, les autres sources n’en sont souvent qu’une reprise tronquée. Au bout du compte, c’est une source datée de 2006 (et qui est peut-être antérieure) qui donne les meilleures informations et fait le point le plus complet sur les modes d’évaluation des articles.

Mais est-ce que les procédures d’évaluation préconisées sont opérationnelles ? Autrement dit, peut-on appliquer ces processus dans des utilisations courantes, c’est-à-dire hors situations particulières (notamment scolaires) et de nécessités de vérification. On peut raisonnablement penser que non, si je m’en réfère à mes propres utilisations et ce que peuvent dire les étudiants. Qui confronte systématiquement ce qui est écrit dans un article de Wikipédia à d’autres sources ?

Ce que l’on peut regretter, c’est l’absence de cartographie thématique, alors que l’on imagine qu’il y a des zones de fiabilités différentes, des repérages a priori pourraient guider le lecteurs (les articles dans le domaine X sont plutôt fiables, alors que dans le domaine Y c’est problématique), des marques reconnaissables. Alors que l’on comprend qu’il faut consulter l’historique et les discussions, il y a peu d’outils de visualisation nous donnant une image interprétable ; en conséquence, historique et discussions restent très difficiles à analyser rapidement. En effet, il s’agit de prendre en compte la dynamique collective et temporelle et de pouvoir juger une ressource de par l’histoire de sa construction et des discussions qui l’ont accompagnée. Mais comment le faire rapidement et de manière fiable sans instrumentation. History Flows^[4] proposait des visualisations intéressantes. Mais il ne semble pas que ce travail ait été repris et il demeure mal connu.

Des enjeux de formation : guider des consommateurs via des passeurs outillés

L’évaluation dépend bien évidemment dépend de la finalité, du public visé, etc. et on pourrait refuser une sorte d’évaluation intrinsèque des articles de Wikipédia. Mais le jugement sur cette qualité a des incidences fortes, notamment sur les représentations sociales de ce projet encyclopédique. Chacun a ses propres croyances sur Wikipédia, mais il n’y a pas de « sagesse collective » ou de connaissance collective nous en donnant une image moins naïve. Comment juger de la qualité ? On voit que la question est délicate : qualité proportionnelle ou inversement proportionnelle au nombre de contributeurs ; processus linéaire d’accroissement avec quelques accidents ou des formes de plateau, voire des régressions ? La qualité des collaborations aurait un effet sur la qualité des articles.

Selon une étude récente, les changements apportés pour assurer la qualité des articles, avec de nouveaux contributeurs nombreux, aurait un effet négatif sur le recrutement de ces nouveaux contributeurs découragés par les mécanismes mis en place. Ainsi, incontestablement, un processus de professionnalisation a été organisé, processus qui a un effet dissuasif. D’un autre côté, on s’aperçoit que les « consommateurs », rôle que nous prenons tous à un moment ou à un autre pour Wikipédia, ont du mal à sortir d’une vision très naïve et se satisfont d’une sorte de « bonne pratique » paravent : on n’utiliserait que pour commencer une recherche, on ne s’arrêterait jamais sur un article de Wikipédia. Comportement que très peu de personnes adoptent, sauf dans des contextes très particuliers. Alors que l’on propose des modèles à discuter de perméabilité entre concepteurs et consommateurs, on s’aperçoit que pour Wikipédia, il y a d’un côté des concepteurs très instrumentés et d’un autre côté des consommateurs très peu outillés. Entre les deux, on peut s’interroger sur les connaissances, les instruments pour les « médiateurs » (enseignants, documentalistes, etc.). Ne devraient-ils pas en savoir collectivement beaucoup plus que les « simples » utilisateurs ?

Wikipedia est un excellent analyseur des évolutions éducatives : un discours rituel sur la nécessité de développer des utilisations du « numérique », une présence effective mais comme une espèce de sous culture, acceptable parce qu’elle rend des services, pratique mais décriée. Wikipedia est une mine pour les chercheurs, c’est aussi un projet en avance dans le domaine de la culture et dans celui du Web sémantique. Mais comment maîtriser cette technologie collective ? On ne perçoit pas encore bien toutes les potentialités et limites de l’écriture collective. Une tension apparaît : si on apprend par l’écriture, des contraintes de forme trop fortes découragent, l’exigence de qualité risque de conduire à un élitisme par trop restrictif. Il faudrait professionnaliser les intermédiaires, afin de palier le manque d’instrumentation, notamment permettant de visualiser des processus de construction pour juger une production. La question de l’expertise des éducateurs se pose avec une certaine urgence. Pourquoi n’arrive pas à se développer un regard plus professionnel sur les productions de ce travail collectif ?

Crédit photo : Kalexanderson (Creative Commons By)

La semaine dernière, nous publiions la traduction L’open source n’est pas une zone de guerre, les hommes ne sont pas tous des connards.

Armony Altinier, fondatrice du groupe accessibilité de l’April et l’une des initiatrices de la soirée Libre Diversité, a souhaité réagir à cet article.

Pas de sexisme chez les Libristes ?

Armony Altinier – Mai 2013

Le Framablog a publié récemment une traduction d’un article intitulé « L’open source n’est pas une zone de guerre, les hommes ne sont pas tous des connards ».

Titre éloquent qu’on a immédiatement envie de compléter en disant : « et les femmes ne sont pas toutes des féministes ». Dont acte, merci pour cette évidence.

Cet article était introduit un peu maladroitement^[1] de cette façon : « Un constat sensiblement différent du billet Sexisme chez les geeks : Pourquoi notre communauté est malade, et comment y remédier de MarLard, qui fit couler beaucoup d’encre récemment dans la blogosphère francophone. »

Qu’en est-il exactement ? Le monde du Libre serait-il un doux rêve échappant à un monde structuré en groupes sociaux dominant d’autres groupes ? Malheureusement, point besoin de statistiques complexes pour se rendre compte que la diversité semble une utopie bien lointaine dans tout événement libriste. L’April, dans une enquête interne basée sur leurs adhérent-e-s, avait même révélé que seuls 6% de ses membres étaient des femmes… Cela signifie-t-il que la majorité des libristes (des hommes donc) sont des connards ? Bien sûr que non !

Non, la très grande majorité des libristes n’est pas sexiste, ils se fichent simplement des inégalités qui existent dans leur communauté.

Prenons une analogie simple pour distinguer les différents types de responsabilité.

Quelqu’un commet un vol : c’est un voleur. Quelqu’un voit un vol se commettre et aide la personne à s’enfuir : ce n’est pas un voleur, c’est un complice parce qu’il a agi pour aider le voleur. Quelqu’un voit un vol être commis et ne réagit pas : ce n’est pas un voleur (auteur de l’acte), ce n’est pas un complice (aucune action directe pour aider), c’est juste quelqu’un qui s’en fiche.

Or, si seule une minorité de libristes est sexiste (avec des actes tels que décrits par MarLard), qu’une part un peu plus importante est complice (en relayant des propos qui minimisent de tels actes par exemple ou en en plaisantant ouvertement), la très grande majorité s’en fiche complètement !

Distinguer sexisme et reproduction sociale du patriarcat

Les mots en -isme comme le racisme ont une signification particulière : ils intègrent une dimension idéologique forte. Cela signifie une implication de l’individu derrière cette croyance.

Dans le cas du racisme par exemple, dont le mot sexisme est inspiré selon Wikipédia, il implique que la personne croit que les êtres humains sont divisés en différentes races dont certaines seraient supérieures à d’autres.

On retrouve cette notion de croyance dans le sexisme, où certaines personnes croient que les hommes en tant que groupe social seraient par nature supérieurs au groupe social des femmes. Ainsi, dire que quelqu’un ou qu’une communauté est sexiste a forcément un côté dénonciateur. Ce qui tend à avoir pour effet une réaction pour « défendre » les personnes accusées de sexisme à titre individuel. Or, mettons-nous à la place des femmes de la communauté Perl auteures du billet de blog traduit sur le Framablog : elles ont de bons copains geeks parmi elles, et elles savent très bien qu’ils ne se sentent pas supérieurs à elle parce que ce sont des hommes. Ils ne sont donc pas sexistes et le crier bien fort est un gage d’amitié et de soutien face à ce qui est considéré, à tort, comme une agression.

Pourtant, ce n’est pas parce que des personnes à l’échelle individuelle ne théorisent pas la supériorité des hommes sur les femmes qu’aucune discrimination n’existe de facto dans notre société. Et en n’agissant pas ou en minimisant ces faits, ces personnes reproduisent une société patriarcale qui est non seulement sexiste, mais qui exclut tout individu qui n’entre pas dans le schéma de perfection associé aux attributs de la virilité version XXIe siècle : force physique (et donc absence de faiblesse ou de handicap), accumulation d’argent, jeunisme, diplômes, position sociale dominante…

Ainsi, je me demande en quoi relayer ce message d’amitié individuel sur le Framablog apporterait un éclairage différent aux propos de MarLard comme il a été dit en introduction ? Car les faits sont incontestables : des communautés libres très homogènes dans leur profil c’est-à-dire très masculines, très blanches, valides, technophiles et j’en passe…

Le Libre, un atout pour le féminisme ?

Le féminisme implique deux choses :

1. Accepter d’ouvrir les yeux sur la réalité choquante des discriminations
2. Vouloir prendre une part active pour que les choses changent

Si les mouvements du logiciel et de la culture libres ont bien quelque chose en commun avec les mouvements féministes, c’est leur volonté de modifier l’ordre des choses pour favoriser un écosystème qui libère l’individu. Or, l’ordre établi est celui du patriarcat.

Et si le logiciel libre sortait du pré carré geek pour s’ouvrir à toutes et tous, sans discrimination ? Cela impliquerait de revoir le fonctionnement interne de chaque organisation et de développer un écosystème favorable et ouvert (tiens !) en se souciant de faire de la place à des voix différentes (faire émerger de nouvelles et nouveaux intervenant-e-s par exemple, ce qui suppose de leur faire de la place), à choisir des lieux accessibles à toutes et tous et à investir des lieux différents (pas seulement des repaires de technophiles).

Le slogan du Framablog reprend une phrase du documentaire de Hannu Puttonen Nom de code : Linux : « Ce serait peut-être une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait que du code ». Beau défi, n’est-ce pas ? Certain-e-s s’y essaient déjà, et vous ?

Pour aller plus loin, vous pouvez relire un article du Framablog sur les femmes et le logiciel libre.

Arrive-t-il parfois qu’utiliser un programme non libre soit une bonne chose ?

Is It Ever a Good Thing to Use a Nonfree Program?

Richard Stallman – Version du 21 mai 2013 – CC By-Nd
Traduction : Framalang (Eijebong, Jtanguy, Penguin, GPif, Smonff, Melchisedech, igor_d, Thérèse, Asta, satbadkd)

Si vous faites fonctionner un programme non libre sur votre ordinateur, il vous prive de votre liberté ; c’est vous qui en êtes la victime principale. Le fait que vous l’utilisiez peut affecter les autres indirectement, car cela encourage le développement de ce programme non libre. Si vous faites la promesse de ne pas redistribuer le programme aux autres, vous faites une erreur, car rompre une telle promesse est mal et la tenir est encore pire. Ici encore, c’est vous la victime principale.

C’est encore pire si vous recommandez à d’autres d’exécuter ce programme non libre, ou si vous les y incitez. Quand vous le faites, vous les incitez à abandonner leur liberté. Par conséquent, ce qu’on doit éviter absolument c’est d’entraîner ou d’inciter autrui à exécuter des logiciels non libres (quand le programme utilise un protocole secret pour communiquer, comme c’est le cas pour Skype, le fait de l’utiliser entraîne les autres à le faire aussi, il est donc extrêmement important de rejeter tout usage de ce genre de programme).

Mais il existe un cas particulier où l’utilisation d’un logiciel non libre, voire le fait d’exhorter les autres à faire de même, peut être une chose positive. Il s’agit du cas où l’utilisation du logiciel non libre vise directement à mettre fin à l’utilisation de ce même logiciel.

En 1983, j’ai décidé de développer le système d’exploitation GNU, en tant que remplacement libre d’Unix. La manière pragmatique de le faire était d’écrire et de tester les composants un à un sur Unix. Mais était-ce légitime d’utiliser Unix pour cela ? Était-ce légitime de demander à d’autres d’utiliser Unix pour cela, étant donné qu’Unix était un logiciel privateur^[1] ? Bien entendu, s’il n’avait pas été privateur, il n’y aurait pas eu besoin de le remplacer.

Je suis arrivé à la conclusion qu’utiliser Unix pour mettre fin à l’utilisation d’Unix était légitime. J’y ai vu une sorte de participation minimale à une entreprise malfaisante, gang criminel ou campagne politique malhonnête par exemple, dans le but de l’exposer au grand jour et d’y mettre fin. Bien que participer à une telle activité soit mal en soi, y mettre fin excuse une participation périphérique mineure, comparable à la simple utilisation d’Unix. Cet argument ne justifierait pas d’être chef de bande, mais j’envisageais seulement d’utiliser Unix, pas de travailler pour son équipe de développement.

Le remplacement d’Unix a été achevé quand le dernier élément essentiel a été remplacé par Linux, le noyau créé par Linus Torvalds en 1991. Nous continuons à ajouter des composants au système GNU/Linux, mais cela ne requiert pas l’utilisation d’Unix, donc cela ne la justifie pas – plus maintenant. Par conséquent, quand vous utilisez un programme non libre pour ce genre de raison, vous devriez vous demander de temps en temps si le besoin existe toujours.

Cela dit, il reste d’autres programmes privateurs qui ont besoin d’être remplacés, et des questions analogues se posent souvent. Faut-il que vous fassiez tourner le pilote privateur d’un périphérique pour vous aider à développer un pilote de remplacement ? Oui, sans hésiter. Est-il acceptable d’exécuter le JavaScript non libre d’un site web afin de faire une réclamation contre ce même code JavaScript non libre ? Bien sûr – mais pour le reste vous devriez faire en sorte que LibreJS le bloque pour vous.

Toutefois cette justification ne s’étendra pas à d’autres situations. Les personnes qui développent des logiciels non libres, même des logiciels avec des fonctionnalités malveillantes, donnent souvent comme excuse le fait qu’elles financent d’une manière ou d’une autre le développement de logiciel libre. Cependant, une entreprise qui est fondamentalement dans l’erreur ne peut pas se dédouaner en dépensant une partie de ses bénéfices pour une noble cause. Par exemple, une partie des activités de la Fondation Gates est louable (pas toutes), mais cela n’excuse pas la carrière de Bill Gates, ni Microsoft. Si une entreprise travaille directement contre la noble cause grâce à laquelle elle essaye de se légitimer, elle se contredit et cela mine ladite cause.

Il vaut même mieux en principe éviter d’utiliser un programme non libre pour développer du logiciel libre. Par exemple, on ne devrait pas demander aux gens d’exécuter Windows ou MacOS dans le but de porter des applications libres sur ces plateformes. En tant que développeur d’Emacs et GCC, j’ai accepté des modifications qui leur permettent de fonctionner sur des systèmes non libres tels que VMS, Windows et MacOS. Il n’y avait aucune raison de rejeter ce code, mais je n’avais pas demandé aux gens de faire tourner des systèmes non libres pour le développer. Ces modifications provenaient de personnes qui utilisaient de toute manière ces systèmes.

L’exception « développer sa propre alternative » est valide dans certaines limites, et cruciale pour la progression du logiciel libre, mais nous devons éviter que cette pratique ne se banalise, de peur qu’elle ne se transforme en une excuse universelle justifiant n’importe quelle activité lucrative impliquant des logiciels non libres.

C’est ce qui arrive à un développeur britannique.

Il s’en réjouit et nous avec 😉

Le gouvernement britannique me paye pour faire de l’open source toute la journée

The UK government pays me to write open source all day

Jake Benilov – 17 mai 2013 – QuickPeopleBlog
(Traduction : RyDroid, goofy, @zessx, Sylvain, MFolschette, Asta, Chuckman + anonymes)

Je suis développeur. Voici le graphique récapitulant mes contributions open source sur Github pour les 12 derniers mois (les carrés verts représentent les jours où j’ai fait des commits dans des dépôts open source) :

Bien que je fasse aussi de l’open source pendant mon temps libre, la plupart de ces points verts apparaissent pendant mes heures de travail au Government Digital Service (NdT. unité gouvernementale chargée de revoir le fonctionnement des services gouvernementaux en ligne), une équipe du Bureau du Cabinet britannique.

Je ne suis pas un cas isolé dans mon équipe. Si vous jetez un coup d’œil à la page Github du GDS, vous trouverez beaucoup de code. Mieux encore, notre travail ne se déroule pas seulement en marge des TIC gouvernementales : nous sommes responsables du site GOV.UK, la principale plateforme de publication du gouvernement britannique, et l’accès principal à toutes les opérations gouvernementales.

Un point où j’ai peut être exagéré : comme James Stewart (un des directeurs développement du GDS) le souligne, le GDS fait aujourd’hui du « code ouvert » plutôt que de « l’open source ». Cela signifie que le GDS rend les sources disponibles sous une licence de libre diffusion (LLD), mais ne soutient ou n’établit aucune communauté autour. Dans tous les cas, le « code ouvert » est génial pour de nombreuses raisons.

Équité envers le contribuable

Les sources gouvernementales devraient être ouvertes. Après tout, si le code a été écrit grâce aux impôts du contribuable, ce n’est que justice que le contribuable puisse l’avoir en retour. Fait intéressant, le critère n°15 du Digital by Default Service Standard (NdT. document explicitant les critères auxquels doivent répondre les services gouvernementaux en ligne) récemment publié devrait institutionnaliser cela et faire en sorte que tous les futurs projets du gouvernement britannique soient mandatés pour ouvrir leurs sources par défaut :

Rendez tout nouveau code source ouvert et réutilisable, et publiez-le sous les licences appropriées (ou fournissez une raison valable pour laquelle ce n’est pas possible pour certaines parties spécifiques du code source)

Équité envers la communauté de l’open source

Nous utilisons des langages et frameworks open source (la majorité de GOV.UK est écrite en Ruby et Scala), des serveurs web open source, nous gérons et configurons nos sources avec des outils open source (Git et Puppet), et nous déployons sur les systèmes d’exploitation open source (tournant sous Linux). Redistribuer n’est que justice.

Transparence

Disposer de mon code source GDS sur GitHub facilite ma vie de développeur au GDS. Si j’ai besoin d’intégrer, de réutiliser ou d’étendre un autre composant du GDS, j’ai juste à cliquer dans mon navigateur ou à cloner le dépôt.

La transparence bénéficie aussi à ceux en dehors du GDS. Besoin de connaître les règles pour calculer une pension d’État ? Regardez les sources. Vous avez trouvé un bug dans la page des jours fériés ? Vous pouvez soumettre une pull request pour le corriger.

Je connais des sociétés qui ont des programmes open source internes, et c’est certainement un pas dans la bonne direction, mais le fait de rendre presque tout disponible nous rapproche de l’idéal d’une propriété commune du code.

En bonus, puisque les bidouilles et les raccourcis sont visibles par tout le monde, il en résulte une diminution des bricolages hasardeux.

Réutilisation

Bien qu’une bonne partie du code que nous écrivons est spécifique à nos problématiques, une large part est générique, et pourrait facilement être adaptée à l’usage d’autres administrations centrales, régionales ou locales, ou dans le secteur privé. En fait, les gens commencent déjà à le faire. Vous voulez du bon code pour un front-end ? Le voici. Vous voulez un système de login unique de qualité gouvernementale ? Le voilà. Vous voulez construire vos propres réponses intelligentes ? Ne vous gênez pas.

Marketing

Le « code ouvert » est un bon argument marketing pour l’image de marque du GDS. Quand je dis à d’autres hackers que je fais de l’open source au travail, les sourcils se lèvent. J’ai entendu des gens extérieurs au GDS en parler en termes de « startup gouvernementale » ; il est évident que l’open source améliore l’image de la marque.

Pour le CV

Pour des raisons purement égoïstes, il est vraiment agréable d’avoir un portfolio de mon travail, un endroit où je peux apporter aux gens une preuve tangible de ma capacité (ou mon incapacité ?) à coder en Ruby.

J’aimerais que davantage d’employeurs fassent cela (et pas seulement le secteur public). Si le vôtre ne le fait pas, peut-être que les raisons évoquées ci-dessus pourront aider à le convaincre de changer d’avis ?

« L‘open source n’est pas une zone de guerre. Les hommes ne sont pas tous des connards. » Tel est le titre d’un article publié par des femmes de la communauté Perl.

Un constat sensiblement différent du billet Sexisme chez les geeks : Pourquoi notre communauté est malade, et comment y remédier de MarLard, qui fit couler beaucoup d’encre récemment dans la blogosphère francophone.

L’open source n’est pas une zone de guerre. Les hommes ne sont pas tous des connards.

Open Source Is Not A Warzone. Not Every Man Is A Dick.

Collectif féminin de la communauté Perl – Mai 2013 – Site personnel de Su-Shee
(Traduction : audionuma, Sphinx, tcit, Ag3m, Garburst, audionuma, goofy, MFolschette, Asta, Hype, KoS + anonymes)

Nous sommes des femmes techniciennes. Nous faisons de l‘open source. Nous faisons partie de la communauté open source.

Nous assistons à des conférences techniques, participons à des groupes d’utilisateurs et à des hackatons avec nos collègues développeurs masculins.

Et nous aimons ça.

Nous avons le sentiment que l’écrasante majorité des hommes à qui nous avons affaire sont des personnes intelligentes, certains sont même des mecs sympas qu’on aime bien.

Oui, nous avons rencontré des connards dans nos vie. Oui, nous avons subi des agressions, parfois même en public et au grand jour. Oui, nous nous sommes fait taper dessus régulièrement et sans finesse, nous avons été dégoutées et dérangées et parfois nous avons frôlé la panique. Certaines d’entre nous ont connu la violence. On nous a tripoté le cul et les nichons, on s’est fait reluquer, siffler et on a eu droit au crétin bourré qui se met en travers. Oui, certaines d’entre nous ont atteint le proverbial plafond de verre durant leurs carrières.

C’est le côté le plus négatif de nos vies et en effet, nous jugeons les réunions et les rencontres selon le degré de bien-être, le sentiment de sécurité et le niveau de connerie affichée ou dissimulée qu’on y ressent.

Mais ce n’est qu’UN aspect du fait d’être une femme et nous ne voulons pas laisser cet aspect dominer notre manière de vivre et de nous comporter dans les communautés techniques de notre choix.

Nous avons le sentiment que la tendance à développer des codes de conduite, des règlements et des règles spécifiquement pour les conférences techniques et d’autres rassemblements liés à la technologie dépasse de beaucoup la réalité que nous avons connue jusqu’à présent.

Nous ne soutenons pas la généralisation de la culpabilité diffuse à un genre tout entier et nous ne voulons pas être suspicieuses envers chacun de nos collègues participant à une communauté.

Nous considérons également les rassemblements de techniciens comme des événements professionnels. Nous attendons donc de chaque participant qu’il se comporte selon les règles que les communautés open source considèrent comme « professionnelles ». Les présentations grossières que l’on a vues lors d’événements récents ont provoqué un scandale suffisant pour faire le point sur cette question.

Nous souhaitons également utiliser un vocabulaire approprié : une « agression » est un acte de violence, un acte agressif pour prendre l’ascendant sur une personne. Nous ne ressentons pas une médiocre tentative de drague comme une agression. Un regard indiscret dans notre décolleté n’est pas une agression. Si quelqu’un nous touche sans le vouloir, ce n’est pas une agression. Le « bisou » français typique est quelque chose de culturel et pas une agression. Une accolade (hug) peut être un acte absolument amical et pas une agression, même s’il peut ne pas être bienvenu.

Nous aimons aussi penser logiquement, et en tant que femmes techniciennes, nous pouvons même nous défendre avec des statistiques : considérant que nous représentons à peu près 1 % à 20 % (ce qui est déjà un pourcentage de femmes extrêmement haut) de n’importe quelle communauté, rencontrer seulement 2 connards dans une conférence de 500 personnes est une chance FANTASTIQUE, nulle part ailleurs dans nos vies quotidiennes la probabilité n’est aussi faible.

Débattons également des problèmes légaux : comment un code de conduite pourrait-il aider contre les agressions, les viols ou les passages à tabac ? Tout ça est DE TOUTE FAÇON illégal à peu près partout dans le monde. Il existe DÉJÀ un code de conduite : la loi, aussi partiale et faible soit-elle.

Regardons les choses en face : aucun connard ne va être stoppé par un code de conduite impuissant à interdire les comportements inopportuns, c’est bien pour cela que ce sont des connards. Cependant, une grande proportion d’hommes se feront discrets, par culpabilité, parce que ce sont ceux qui se remettent en question, de manière réfléchie, par rapport à leur propre connerie.

Nous préférons que le bon goût, le professionnalisme et les comportements se développent grâce à une culture de bon goût, de plaisanteries, d’idées de fond et de standards, et non par l’écriture d’une longue liste de choses déplaisantes et interdites. Nous préférons agir contre le comportement des connards lorsqu’il se manifeste.

Mais nous considérons aussi les rassemblements open source comme des événements sociaux et nous allons le dire en public : lors d’un événement social il peut y avoir de la *hum* sexualité, de l’amitié, des taquineries ou du flirt. Cela fait partie du fait que les humains vivent ensemble. Nous considérons la libération sexuelle des années 70 comme un progrès qui nous a donné, à nous les femmes, de nouvelles libertés pour vivre comme nous le voulons. Nous n’y renoncerons pas.

Nous nous voyons dans la tradition du féminisme responsabilisant, de l’émancipation en ayant appris à dire non, en étant capables de nous défendre nous-mêmes et nous ne voulons pas être les victimes indirectes d’actes de surprotection « globaux » qui au fond condamnent chaque comportement social entre les hommes et les femmes.

Nous sommes des « femmes du Perl » et à vrai dire notre communauté nous plaît plutôt bien.

(Peut-être êtes-vous membre d’une communauté complètement différente et, néanmoins d’accord avec nous : faites-le moi savoir :)).

Tout comme le sont d’autres femmes, qui ne seront pas citées ici.

Bien à vous – Su-Shee (Susanne Schmidt), castaway (Jess Robinson), gshank (Gerda Shank), ether (Karen Etheridge), druthb (D Ruth Bavousett), auggy (Augustina Ragwitz), Lady Aleena

L’un des auteurs que l’on traduit le plus sur le Framablog, Glyn Moody, choisit ici de mettre les pieds dans le libre plat.

Et si on n’utilisait plus les licences libres, qui ne sont pas sans poser problèmes, en plaçant directement le code dans le domaine public ?

Les avantages pourraient finalement dépasser les inconvénients !

Remarque : Sur le même thème on pourra également lire (ou acheter) notre framabook Un monde sans copyright… et sans monopole. Sans oublier notre auteur Pouhiou qui place directement ses romans dans le domaine public et s’en explique ici dans un fort intéressant dialogue avec Lionel Maurel aka Calimaq.

Pourquoi il est temps d’arrêter d’utiliser les licences libres

Why it’s time to stop using open source licences by Glyn Moody

Glyn Moody – 13 février 2013 – The H Open
(Traduction : Tr4sK, aKa, Sphinx, Isdf, Penguin, ProgVal, lamessen, Shanx, Amargein, ronane, MFolschette, Isser)

Les logiciels libres reposent sur un paradoxe. Afin que les utilisateurs puissent être libres, les licences libres utilisent quelque chose remettant en cause la liberté : le copyright. Ce dernier est un monopole intellectuel se basant sur la restriction de la liberté des gens à partager, la liberté est donc restreinte et non pas étendue. Quand Richard Stallman, en 1985, a créé la GNU Emacs General Public License, cela représentait un bidouillage brillant, maintenant il est peut-être temps de passer à autre chose.

Nous y sommes déjà et des éléments le montrent. Il y a 18 mois, les gens ont commencé à remarquer le déclin des licences copyleft vers des licences plus permissives comme la licence Apache ou BSD. Plus récemment, la croissance de GitHub a attiré l’attention, montrant également que de plus en plus de gens n’utilisent plus de licences sur GitHub (ce qui peut s’avérer problématique d’une certaine manière).

Je ne pense pas que le déclin des licences copyleft soit la preuve d’un échec, bien au contraire ! Je l’écrivais dans mon édito précédent, le logiciel libre a au fond gagné, prenant le pouvoir dans la plupart des secteurs clés de l’informatique. De la même manière, le passage à des licences permissives n’a été rendu possible que grâce au succès du copyleft : les idées participant à la création collaborative et à la contribution à un projet que l’on utilise sont maintenant généralisées. Il n’y a donc plus besoin de licences copyleft « fortes » pour faire respecter ces valeurs, elles font désormais partie de l’ADN des codeurs. Ian Skerrett le déclarait ainsi en 2011 :

« On n’a plus besoin de s’assurer que les développeurs ou les entreprises soient honnêtes. Ils contribuent aux projets open source parce que cela les aide dans leur travail. S’il fallait s’assurer que les développeurs sont honnêtes, pourquoi y aurait-il autant de projets Apache réussis ? Prenons l’exemple du projet Eclipse qui utilise un copyleft faible. Je ne connais que très peu de contributions ayant été intégrées à Eclipse parce que le développeur avait été forcé de contribuer à cause des obligations de licence. Les gens contribuent aux projets qu’ils utilisent parce qu’ils ont saisi le bénéfice qu’ils pouvaient recevoir grâce à leur contribution. »

C’est aussi pourquoi nous ne devons pas nous n’inquiéter du cloud computing — parfois présentée comme la tueuses des licences libres — puisqu’il n’y a pas de distribution obligeant à publier les éventuelles modifications du code. Mais une fois de plus, nous n’avons pas besoin de cette obligation : si une entreprise d’informatique de cloud computing veut pleinement tirer les bénéfices du logiciel libre, elle y contribuera de toute façon. Si elle ne le fait pas, elle n’a rien compris.

Quelle licence devons-nous donc adopter si on n’utilise pas une licence copyleft ? Apache ? BSD ? Pourquoi pas aucune licence du tout , c’est à dire mettre le logiciel dans le domaine public ? Après tout, c’est la conclusion logique du mouvement vers des licences de plus en plus permissives — une qui permet tout.

Compte tenu des discussions passionnées qui ont tendance à se produire lorsqu’on émet l’idée qu’il y a un mouvement des licences copyleft traditionnelles vers des licences légèrement plus permissives, je soupçonne que l’idée d’évoluer vers une licence complètement permissive sera choquante pour certains. À l’évidence, cela semblerait impossible, car conduisant « certainement » à l’effondrement du logiciel libre lui-même si celle-ci était largement adopté.

Un article intéressant de Clark Asay, maître de conférences à la Penn State Univerity Dickinson School of Law (et aussi frère de Matt Asay, personnalité connue de tous dans le logiciel libre) étudie cette idée en profondeur et présente quelques arguments convaincants sur le fait que placer les logiciels libres dans le domaine public fonctionne et s’avère bénéfique.

Asay (Clark et non Matt) remarque qu’il y a un coût à utiliser des licences libres en termes de conformité. Les entreprises dépensent énormément d’argent en se préoccupant de faire les choses bien, mais les programmeurs, eux aussi, perdent du temps à s’occuper de détails légaux alors qu’ils pourraient être en train d’écrire davantage de lignes de code. En particulier, l’incompatibilité entre les nombreuses licences et leurs variantes est une barrière importante à de plus larges réutilisations et collaborations. Ces problèmes signifient que les logiciels libres ne sont pas utilisés aussi largement et efficacement qu’ils le pourraient, commercialement ou non. Ces difficultés peuvent expliquer en partie le glissement vers des licences plus « permissives », guidé par le désir d’éviter justement ces problèmes.

Asay se met alors à examiner les deux objections majeures à rendre le code disponible librement, sans aucune licence. La première tient au fait que les entreprises risquent de récupérer du code puis de l’enfermer, ce qui selon lui a peu de chance de se passer puisque, en faisant ainsi, elles écarteraient beaucoup des bénéfices que seuls les logiciels libres offrent :

« Si une société devait prendre la responsabilité d’un projet et le rendre fermé, elle n’obtiendrait certainement pas le travail bénévole que les contributeurs du monde entier ont envie d’offrir aux projets disposant de licences ouvertes. Sans ce travail bénévole, les sociétés perdraient un des avantages les plus significatifs des modèles ouverts d’innovation, et ce travail bénévole resterait probablement fidèle à la version ouverte du projet. C’est pourquoi les sociétés encouragent d’ores et déjà à ouvrir le plus de projets possibles et à y contribuer. Car en faisant ainsi, cela va attirer une force de travail bénévole et déclenchera une innovation correspondant mieux à à leurs besoins et stratégies.

Est-ce que la réciprocité (c’est-à-dire l’obligation de contribuer au projet en contre-partie) permet d’éviter la désertion des contributeurs individuels ? Il semble peu probable que, dans la plupart de cas, les contributeurs individuels aient le temps, l’intérêt et les ressources pour s’emparer d’un projet non-réciproque et d’en créer un équivalent fermé. La littérature suggère que les buts espérés par les individus qui contribuent à des projets aux licences ouvertes, ont peu à voir avoir avec un avantage financier direct. Leurs intérêts pour la contribution résident plutôt dans la créativité, l’amélioration de sa réputation, et les bénéfices financiers indirects. Bien qu’il soit toujours possible pour des contributeurs de s’emparer d’un projet ouvert et de le rendre fermé pour l’intégrer dans leurs propres produits (et ainsi contrevenir à ce modèle ouvert d’innovation), les mêmes raisons qui suggèrent que les sociétés ne le feront pas s’appliquent également aux contributeurs individuels. Les contributeurs individuels sont encore moins à même d’abandonner les buts qu’ils espèrent atteindre dans la contribution à des projets ouverts, en plus de n’avoir que des ressources limitées pour réussir à fermer et maintenir un projet. »

L’autre objection majeure qu’il met en avant est que si le logiciel est placé dans le domaine public, il n’existe aucune exigence pour que tous les programmeurs reçoivent la reconnaissance qu’ils méritent pour leur contribution à un projet. Cette reconnaissance peut être importante en raison de l’estime des pairs dont ils jouissent en retour et peut même aboutir à des compensations économiques sous la forme d’offres d’emploi et d’augmentations de salaire.

Attribution et réputation

Je suis d’accord pour dire qu’attribuer le mérite d’un projet est important, et cela de manière cruciale. En fait, je pense que cela représente la clé du problème concernant les produits numériques partagés sur Internet, étant donné que les bénéfices économiques dépendent de cela. Toutefois, forcer cette attribution grâce à des licences ne représente peut-être pas le meilleur moyen. Asay l’explique ainsi :

« Dans une large mesure, l’approche de la gestion de la propriété intellectuelle choisie par les modèles d’innovation ouverts (c’est-à-dire les licences classiques des projets open source) échoue à remplir ses missions. Par exemple, le respect des licences attribution-only (mention de l’auteur original du projet) provoque l’enfouissement d’une telle reconnaissance dans les documents légaux ; cela fait que la reconnaissance d’une telle paternité devient minime. Cette réalité montre que ceux qui contribuent en utilisant des licences attribution-only, bien qu’étant motivés par une certaine forme de reconnaissance, obtiendront un tout autre type de reconnaissance que celui engendré par la propriété intellectuelle. Dans le monde du logiciel libre et open source, des outils comme GitHub, utilisé largement comme outil social de développement, peuvent fournir plus efficacement la reconnaissance que cherchent les programmeurs. Le fait que de plus en plus de contributions à des logiciels effectuées via GitHub se font sans avertissement de non-respect de la propriété intellectuelle ou des clauses de licences montre que le « prix » d’un tel avertissement à cause d’une documentation légale obscure n’en est pas un, du moins pour ceux qui contribuent. »

En effet, les personnes et les entreprises ont déjà commencé à utiliser les profils GitHub comme un moyen d’afficher et de mesurer la capacité à coder. Je soupçonne que cela deviendra bientôt la norme, avec des moyens plus formels d’établir sa réputation dans le monde du développment, apparaissant aux côtés de ceux informellement dictés par les normes sociales au sein de la communauté du logiciel libre.

Après avoir abordé les deux principales objections de se passer de licences open source traditionnelles, Asay examine ensuite ce que le domaine public signifierait en pratique :

« Une approche du style domaine public devrait remplacer efficacement les droits d’auteurs automatiques, supprimer tous les droits liés aux brevets (les deux respectant les droits des brevets déjà obtenus ainsi que de façon prospective), et renoncer à tous les recours possibles venant avec eux. Les droits liés au secret commercial, le cas échéant, devraient êtres supprimés dès que le titulaire des droits a publié le logiciel ou le contenu au public. On peut dire que renoncer à tout droit de marques est non seulement inutile mais déconseillé, car les autres pourraient utiliser les marques pour embrouiller les consommateurs quant à la source du logiciel ou du contenu. En effet, c’est exactement pourquoi la licence CC (Creative Commons), qui inclut une licence dédiée au domaine public dans son répertoire légal, exclut expressément les droits de marque dans son outil. »

Ce dernier point sur les marques est important, bien qu’il puisse sembler étrange de prétendre que tous les monopoles intellectuels et marques doivent être conservés, parce qu’ils servent un but très différent de celui du droit d’auteur ou des brevets. Les marques sont conçues pour protéger les consommateurs contre la fraude, plutôt que de chercher à exclure les concurrents, même si c’est la façon dont elles sont souvent utilisées aujourd’hui.

Mais pour les projets open source, les marques sont purement une question de réputation — c’est à dire qu’elles deviennent des garanties de qualité lorsqu’elles sont appliquées à un programme. N’importe qui peut prendre le code et l’utiliser et l’adapter de différentes façons. Mais il ne pourra pas utiliser la marque du projet, car cela impliquerait qu’il s’agit d’une version officielle « approuvée ». Ce qui serait évidemment problématique pour une variété de raisons, à commencer par celle de la sécurité.

Asay aborde également une objection importante dans sa thèse selon laquelle placer un logiciel dans le domaine public serait la meilleure façon de le distribuer : si c’était le cas, pourquoi tout le monde s’en tiendrait à la licence GPL ou Apache ? Comme il le souligne :

« Dans le monde du logiciel libre et open source, par exemple, il n’existe aucun outil reconnu ou largement utilisé dévoué au domaine public. A la place, l’Open Source Initiative et la Free Software Foundation — les deux principales organisations de défense des logiciels libres dans le monde — refusent ou approuvent les licences ouvertes utilisées dans la communauté. S’il est vrai que divers projets pourraient tout simplement ignorer ces licences recommandées et d’adopter une approche par domaine public — certaines ayant essayé de faire exactement cela — cette approche suppose que les organisateurs de ces projets comprennent comment le faire. »

Le fait est qu’il est actuellement assez difficile de placer un logiciel dans le domaine public, premièrement parce qu’il y a un biais culturel contre une telle attitude, même au sein de la la communauté du logiciel libre, et deuxièmement parce que légalement c’est un processus délicat. En effet, Asay suggère que nous avons besoin d’une nouvelle législation — ce qu’il appelle Public Domain Act (NdT, en français : « Loi du Domaine Public ») — pour rendre ce processus plus facile. Il faudra évidemment prendre en compte les différents systèmes de copyright ayant cours dans le monde — par exemple, ceux qui mettent plus l’accent sur les « droits moraux ».

Il y a quelques années, j’ai demandé à Richard Stallman ses points de vue sur la manière dont le copyright devrait être réformé, particulièrement concernant l’aspect logiciel. Voici ce qu’il a répondu :

« Pour la plupart des types de travaux, je pense que le droit d’auteur serait acceptable si nous l’avions (1) fait plus court (je suggère 10 ans), (2) permis la redistribution de copies dans un but non commercial et sans modification, (3) défini comme fair use les réutilisations sous forme de remix. Cependant, je pense que les logiciels et autres œuvres d’usage pratique doivent être libres. »

Notez qu’il pense, lui aussi, que le logiciel devrait être exempt de tout copyright — en d’autres mots, dans le domaine public — mais il a ajouté quelques mises en garde :

« Je serais heureux de voir l’abolition du copyright dans le logiciel si c’était fait de façon à s’assurer que le logiciel est libre. Après tout, l’objectif du copyleft est d’atteindre ce but pour les dérivés de certains programmes. Si tous les logiciels étaient libres, le copyleft ne serait plus nécessaire.

Cependant, l’abolition du copyright peut aussi être faite de manière erronée et pourrait n’avoir aucun effet sur les logiciels propriétaires typiques (qui sont restreints par des CLUF, Contrats de Licence Utilisateur Final, et le secret du code source plus que par le copyright), et ne ferait que porter atteinte à l’utilisation du copyleft. J’y serais naturellement opposé. »

Placer les logiciels libres dans le domaine public serait équivalent à abolir le droit d’auteur pour ces programmes tout en laissant le code propriétaire intact. Est-ce vraiment un problème ? Personnellement, je ne le pense pas, pour les raisons que j’ai mentionnées : toute entreprise prenant du code dans le domaine public et se l’appropriant perd tous les avantages de son ouverture. Il est vrai qu’il reste des programmes hérités des maisons de logiciels à l’ancienne qui ont toujours été propriétaires, mais leurs existence n’affecte pas vraiment le monde plus large du logiciel libre, qui est maintenant arrivé à l’indépendance et à l’autosuffisance. Ce que Microsoft et ses semblables font en ce moment est quelque peu hors de propos.

Bien sûr, le passage au domaine public ne signifiera pas la disparition des licences libres actuelles — elles seront toujours là pour ceux qui souhaitent les utiliser. Comme toujours, le choix et la liberté personnelle sont capitaux. Mais j’espère que les gens y réfléchiront à deux fois avant d’introduire de nouvelles licences, ou même avant d’en mettre à jour d’anciennes. En particulier, j’espère qu’il n’y aura jamais de GNU GPL version 4. Au contraire, nous devons parachever la révolution que Richard Stallman a commencée il y a près de trois décennies en rendant le logiciel libre véritablement libre, en le plaçant dans le domaine public et en brisant les chaînes qui le lient encore à ce monopole vieux de trois cents ans nommé copyright.

GitHub est aujourd’hui la plus dynamique forge de développement de logiciels libres. Mais n’y aurait-il pas, dans sa conception même, quelques problèmes de gouvernance et de circulation du code qui menacent l’efficacité, voire la viabilité, des projets ?

Remarque : Pull request, issue, commit… nous présupposons que vous êtes familier avec le vocable GitHub, mais si un gentil lecteur veut nous les préciser dans les commentaires, qu’il/elle n’hésite surtout pas 😉

De la citoyenneté dans le développement de logiciels open source

On Citizenship in Open-source software development

Christophe Maximin – 8 mai 2013 – Blog personnel
(Traduction : ProgVal, Melchisedech, nano-plink, TheCamel, Al + anonymes)

Comment GitHub peut révolutionner la question en donnant le pouvoir aux utilisateurs dans les dépôts auxquels ils contribuent.

TL;DR : En donnant un véritable statut social aux personnes contribuant à un dépôt, GitHub résoudrait le problème des projets-zombies ayant une communauté éparpillée. En permettant à ces citoyens de collaborer réellement les uns avec les autres, et non avec le seul propriétaire, les dépôts seront vivants tant que leur communauté existera, de manière complètement auto-régulée.

L’année a très bien commencé pour GitHub. Après avoir levé cent millions de dollars d’Andreesen-Horowitz et atteint les trois millions d’utilisateurs en janvier (3,4 millions et plus à présent), ils sont sur une dynamique qu’il sera difficile d’arrêter.

Néanmoins, le service a aussi ses défauts, et si certaines personnes pointent du doigt de tous petits problèmes liés aux services et aux applications, le problème que je m’apprête à décrire touche à la nature même de nos interactions sur la plate-forme.

1. État actuel d’un dépôt

Chaque dépôt que vous créez est un petit pays avec une très faible population : 1 habitant, vous, le créateur/roi/commandant suprême.

Même si votre dépôt a des centaines de rapports de bugs créés par d’autres, et des centaines de pull requests, il n’y a qu’une seule personne aux commandes.

Bien sûr, vous pouvez ajouter des collaborateurs à votre dépôt, mais il ne seront que des collaborateurs, des membres du cabinet, choisis juste parce que vous le souhaitez. Bien sûr, dans le cas des organisations, vous pouvez ajouter des co-commandeurs suprêmes.

Mais c’est tout. Vous n’atteindrez probablement pas cinquante collaborateurs/membres; même si votre dépôt est vraiment populaire, et même si des centaines de personnes y contribuent. Est ce que cela vous parait normal ?

Ce ne serait pas un problème si ce n’était pas la cause de…

2. La fragmentation des dépôts et de leurs fonctionnalités

J’ai vu la chose suivante arriver bien trop souvent :

• Le développeur abandonne graduellement un projet à cause de nouveaux engagements dans sa vie, ou juste parce qu’il n’est plus intéressé. Et donc il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas.
• Le développeur est dépassé par les rapports de bugs et les pull requests qu’il reçoit. Et bien qu’il sache qu’il a une solide communauté autour de ce projet, il ne peut pas juste ajouter quelqu’un comme collaborateur car il devra quand même lire chaque ligne pour être sûr que tout est en ordre. Et donc, il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas vraiment.

Et vous vous dites : « Qui s’en soucie ? N’importe qui peut forker le dépôt et donner une nouvelle vie au projet autre part ! »
Bien entendu, mais combien de fois avez-vous vu cela se faire réellement ?
La plupart du temps, les gens forkent le projet pour régler « le » bug qu’ils voulaient régler, et c’est tout.

Maintenant, si vingt personnes agissent de la sorte, cela devient une vraie tragédie : le projet est en fait encore mis à jour, mais à vingt autres endroits. Vous devrez fusionner les commits de 20 dépôts différents pour être à jour de toutes les nouvelles choses cools que vous pouvez faire avec le projet. Mais vous ne le ferez jamais. Certains forks sont incompatibles de toute façon.

D’autre part, comme le projet « semble vivant », personne ne se presse pour essayer de le remplacer. La léthargie se poursuit alors encore et encore, et va créer la confusion chez n’importe quel nouveau venu quant à l’état du projet, sur l’emplacement des dernières mises à jour, et sur leur éventuelle acceptation par la communauté.

Je ne vais pas donner de noms (ce n’est pas bien de pointer du doigt publiquement) , mais je suis sûr que vous voyez à quoi je fais référence.

3. Le pouvoir au peuple, le pouvoir à la cité

Sans entrer dans un débat sur les multiples définitions du mot citoyenneté, vous trouverez ici une liste de quelques fonctionnalités qui en feront une réalité. Rien de ce qui est listé ici n’est absolu, et ce sera à l’administrateur de définir les règles.

• Tout le monde peut voter pour une issue.
• Tout le monde peut voter pour une pull request, avec un merge automatique quand une majorité (ou quelque chose d’autre à définir) est atteinte.
• Les citoyens se voient attribuer des « points de karma » suivant les votes positifs ou négatifs qu’ils reçoivent sur leurs commits et leurs réponses aux issues. Les citoyens ont un total de points pour ce dépôt, et pour le reste de GitHub.
• Tous les commits qui sont approuvés par le peuple vont dans un branche spécifique préfixée « par_le_peuple_* » .
• Les administrateurs ont toujours le droit de veto sur ce qu’ils veulent, et peuvent complètement couper ce mode « auto-pilote » .

Conclusion

Il est temps que les gens qui contribuent à des projets acquièrent enfin une réelle existence. Il n’y a vraiment rien à perdre, et cela semble pour moi être une évolution naturelle et inévitable de toute façon.

La question est : combien de temps devrons nous attendre ?