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)

Vous avez peut-être remarqué dans les derniers articles publiés sur le framablog que quelques illustrations à l’humour approximatif étaient signées Gégé, le générateur de Geektionnerd. Ce petit jeu graphique vous est aujourd’hui offert en libre-service par Framasoft.

D’où vient-il ?

C’est une conception des Mozilla Labs dont on peut trouver toute la petite histoire et les caractéristiques techniques sur ce blog de Mozilla hacks. Pour simplifier, Willian Carvalho a voulu réaliser avec Canvas (traitement de l’image en JavaScript) ce qui existait seulement en Flash. C’est une chouette et amusante démonstration de ce qu’on peut faire désormais avec le HTML5, que Mozilla défend et promeut comme le langage du Web, plateforme ouverte de développement…

La version Framalab

C’est Cyrille (avec l’aide de Quentin pour la mise en ligne) qui a réalisé une adaptation francophone, avec la complicité de Simon “Gee” Giraudot qui a fourni les images. Vous pouvez trouver les sources librement disponibles sur le github, n’hésitez pas à le forker, à vous installer votre propre version avec vos images et à fabriquer vous-mêmes des bandes dessinées libres.

Comment ça marche ?

C’est vraiment simple et intuitif. Rendez-vous sur la page du générateur de Geektionnerd, choisissez et déplacez les éléments graphiques, saisissez du texte pour vos “bulles”, redimensionnez les éléments avec les flèches haut/bas du clavier et inversez-les avec les flèches droite/gauche. Vous pouvez enregistrer facilement vos créations ensuite.

…d’ailleurs n’hésitez pas à en faire profiter tout le monde, peut-être publierons-nous vos meilleures réalisations ici, qui sait ?

Et Simon Giraudot, le voilà piraté ? Qu’en dit-il ?

Eh bien nous lui avons posé la question…

Quelle a été ta première réaction quand tu as découvert ce générateur ?

Très bonne ! Lorsque Cyrille a partagé la première version du générateur sur la liste de l’association Framasoft, tout le monde a commencé à jouer avec et à partager ses créations sur la liste. C’est assez marrant de voir mes personnages avec des mots qui ne sont pas les miens dans leur bouche !

D’une certaine façon c’est la continuité logique des créations libres que tu as réalisées avec la série des Geektionnerds ?

À priori c’est pareil. D’ailleurs, les dessins du générateur ne sont pas des dessins « exclusifs », ils sont en fait issus d’articles du blog (donc ils sont déjà sous CC-By-Sa !). Mais oui, c’est l’exacte continuité de ce que je propose dans le Geektionnerd. J’ai placé mes œuvres sous licence libre par conviction, parce que c’est comme ça que je vois « l’art » de manière générale. Le fait que les dessins soient librement modifiables n’est qu’une liberté, mais ça ne veut pas dire que vous allez forcément l’utiliser : grâce à ce générateur, on vous propose d’expérimenter cette liberté et de créer vos propres BD dérivées du Geektionnerd !

Tout le monde peut s’amuser avec ce petit générateur que nous te remercions d’avoir alimenté de tes dessins. Penses-tu que c’est juste un gadget sympathique ou que ça peut déclencher des vocations ?

L’un n’empêche pas l’autre, non ? 😉 Blague à part, c’est surtout un outil de loisir, à mon sens. Ça reste du bidouillage de dessins et de textes, je ne me verrais pas réaliser une histoire complète avec ça, par exemple. Mais après, qui sait ? Avec les licences libres, les possibilités sont infinies : imaginez une personne qui a une idée géniale de scénario pour une BD, mais ne sait absolument pas dessiner. Grâce aux contributions que l’on met dans le pot commun de l’art libre (et je ne parle pas que de moi ici mais de tous les artistes libres), il pourrait tout à fait récupérer une énorme base de données de dessins et les arranger comme il le veut pour correspondre à son scénario. Sympa, non ?

Si l’on va un peu plus loin, ce genre de pratiques implique la fin de l’œuvre unique, puisque chacun peut utiliser, copier, remixer, re-créer et diffuser des comic strips ? l’analogie avec les 4 libertés du logiciel libre est frappante, non ?

Oui, c’est exactement ça. Pour autant, il ne faut pas voir ça comme une trahison de l’œuvre ou un manque de respect de l’auteur (ce genre d’argument revient souvent lorsqu’on parle de modifier les œuvres sans l’autorisation de l’auteur – un des principes d’une licence libre). L’œuvre originale, le Geektionnerd, reste une « œuvre unique », si l’on veut. La différence avec une œuvre sous régime de droit d’auteur classique, ce n’est pas que vous allez vous l’approprier et en faire ce que vous voulez : ça, honnêtement, vous le faites aussi avec des œuvres protégées.

La différence, c’est que là, non seulement personne ne viendra vous demander des comptes et vous traiter de voleur, mais en plus, on vous y encourage ! Tu parles de l’analogie avec les 4 libertés du logiciel libre : je pense aussi, personnellement, aux deux modèles que propose Florent Latrive dans son livre Du bon usage de la piraterie. Il explique que, classiquement, on aimait considérer les artistes comme des  « génies romantiques » qui avaient une inspiration naturelle et quasi-divine. Mais l’artiste est en fait plus proche du « hacker », qui s’approprie toutes les informations qui l’entourent pour créer quelque chose de nouveau. Tous les artistes passent leur temps à reprendre, copier, réutiliser les œuvres du passé. La licence libre ne fait que se mettre en accord avec cette réalité qui est pourtant loin d’être spécifique à l’art libre ! On connait la fameuse citation de Picasso, « Les bons artistes copient, les grands artistes volent ». Aurait-il mis ses œuvres sous licence libre si cela avait existé à son époque ? C’est une autre question 😉

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.

Source : Impression 3D : une Américaine conçoit son propre disque vinyle (Numerama)

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

Université et communauté

Kevin Ottens

Kevin Ottens est un « hacker » de longue date au sein de la communauté KDE[1]. Il a largement contribué à la plateforme KDE, en particulier à la conception des API et frameworks. Diplômé en 2007, il est titulaire d’un doctorat en informatique qui l’a amené à travailler, en particulier, sur l’ingénierie des ontologies[2] et les systèmes multi-agents. Le travail de Kevin au KDAB inclut le développement de projets de recherche autour des technologies KDE. Il vit toujours à Toulouse, où il est enseignant à mi-temps dans son université d’origine.

Introduction

Les communautés du Libre sont principalement animées par l’effort de bénévoles. De plus, la plupart des personnes qui s’impliquent dans ces communautés le font lors de leur cursus universitaire. C’est la période idéale pour s’engager dans de telles aventures : on est jeune, plein d’énergie, curieux et l’on veut probablement façonner le monde à son image. Voilà tous les ingrédients d’un bon travail bénévole.

Mais, en même temps, être étudiant ne laisse pas forcément beaucoup de temps pour s’engager dans une communauté du Libre. En outre, la plupart de ces communautés sont assez vastes et les contacter peut faire peur.

Cela soulève évidement une question dérangeante : si les communautés du Libre ne réussissent pas à attirer la nouvelle génération de contributeurs talentueux, est-ce parce qu’elles ne cherchent pas activement à étendre leur activité dans les universités ? Cette question pertinente, nous avons essayé d’y répondre dans le contexte d’une communauté qui produit des logiciels, à savoir KDE. Dans cet article, nous nous concentrerons sur les aspects auxquels nous n’avions pas initialement pensé mais qu’il nous a fallu aborder pour répondre à cette question.

Construire un partenariat avec une université locale

Tout commence, réellement, par le contact avec les étudiants eux-mêmes. Et pour ça, rien de mieux que de se rendre directement dans leur université et de leur montrer à quel point les communautés du Libre peuvent être accueillantes. À cet effet, nous avons construit un partenariat avec l’université Paul Sabatier de Toulouse  plus précisément, avec l’un de ses cursus – nommé IUP ISI (NdT : Ingénierie des Systèmes Informatiques) – axé sur le développement logiciel.

L’IUP ISI était très orienté sur les connaissances « pratiques » et avait à ce titre un programme pré-établi pour les projets étudiants. Un point particulièrement intéressant de ce programme est le fait que les étudiants travaillent en équipe « inter-promotions ». Des étudiants de troisième et quatrième années, généralement en équipes de 7 à 10, apprennent à collaborer autour d’un objectif commun.

La première année de notre expérience, nous nous sommes raccrochés à ce programme en proposant de nouveaux sujets pour les projets, et en nous concentrant sur des logiciels développés au sein de la communauté KDE. Henri Massie, directeur du cursus, a très bien accueilli cette idée, et nous a laissés mettre cette expérience en place. Pour cette première année, nous nous sommes vu attribuer deux créneaux horaires pour les « projets KDE ».

Pour créer rapidement un climat de confiance, nous avons décidé, cette année-là, d’offrir quelques garanties concernant le travail des étudiants :

• Aider les professeurs à avoir confiance dans les sujets abordés : les projets sélectionnés étaient très proches des sujets enseignés à l’IUP ISI (c’est pourquoi, pour cette année, nous avons ciblé un outil de modélisation UML et un outil de gestion de projet) ;
• donner un maximum de visibilité aux professeurs : nous avons mis à leur disposition un serveur, sur lequel étaient régulièrement compilés les projets étudiants, accessible à distance à des fins de test ;
• faciliter la participation des étudiants à la communauté : les responsables des projets étaient désignés pour jouer le rôle du « client », soumettre leurs exigences aux étudiants et les aider à trouver leur chemin dans le dédale de la communauté ;
• enfin, pour mettre le pied à l’étrier aux étudiants, nous leur avons donné un petit cours sur « Comment développer avec Qt et les autres frameworks produits par KDE ».

Au moment de l’écriture de ces pages, cela fait cinq ans que nous menons de tels projets. De petits ajustements dans l’organisation ont été apportés ici et là, mais la plupart des idées sous-jacentes sont restées les mêmes. La majorité des changements ont été le résultat d’un intérêt grandissant de la communauté, désireuse d’établir un partenariat avec les étudiants, et d’une plus grande liberté pour nous quant aux sujets que nous pourrions couvrir dans nos projets.

De plus, tout au long de ces années, le directeur nous a donné une aide et des encouragements constants, attribuant effectivement plus de créneaux pour les projets de la communauté du Libre et prouvant que notre stratégie d’intégration était juste : établir de la confiance dès le début est la clé d’un partenariat entre la communauté du Libre et l’Université.

Comprendre que l’enseignement est un processus interactif

Durant ces années à tisser des liens entre la communauté KDE et la filière IUP ISI, nous nous sommes retrouvés en situation d’enseignement afin d’assister les étudiants dans des tâches liées à leurs projets. Quand vous n’avez jamais enseigné à une classe pleine d’étudiants, vous avez sans doute encore une image de vous, il y a quelques années, assis dans une classe. En effet, la plupart des enseignants ont un jour été étudiants… Parfois même, pas le genre d’étudiant très discipliné ni attentif. Vous aviez sans doute l’impression d’être submergé : l’enseignant entrait dans la salle, faisait face aux étudiants, et déversait sur vous ses connaissances.

Ce stéréotype est ce que la plupart gardent à l’esprit de leurs années d’études et la première fois qu’ils se retrouvent en situation d’enseigner, ils veulent reproduire ce stéréotype : arriver avec un savoir à transmettre.

La bonne nouvelle, c’est que rien n’est plus éloigné de la vérité que ce stéréotype. La mauvaise nouvelle, c’est que si vous essayez de reproduire ce stéréotype, vous allez très probablement faire fuir vos étudiants et ne ferez face qu’à un manque de motivation pour participer à la communauté. L’image que vous donnez de vous est la toute première chose dont ils vont se souvenir de la communauté : la première fois que vous entrez dans la salle de classe, vous êtes, pour eux, la communauté.

Pour éviter de tomber dans le piège de ce stéréotype, il vous faut prendre un peu de recul et réaliser ce que signifie réellement d’enseigner. Ce n’est pas un processus à sens unique où l’on livre la connaissance aux étudiants. Nous sommes arrivés à la conclusion que c’est en fait un processus à double sens : vous êtes amené à créer une relation symbiotique avec vos étudiants. Les étudiants et les enseignants doivent tous sortir de la salle de classe avec de nouvelles connaissances. Il vous faut livrer votre expertise, bien sûr, mais afin de le faire efficacement, vous devez en permanence vous adapter au cadre de référence de vos étudiants. C’est un travail qui rend très humble.

Cette prise de conscience génère pas mal de changements dans la manière d’entreprendre votre enseignement.

• Vous allez devoir comprendre la culture de vos étudiants. Ils ont probablement des expériences assez différentes des vôtres et vous allez devoir adapter votre discours à eux ; par exemple, les étudiants que nous avons formés font tous partie de la fameuse « génération Y » qui, en matière de leadership, loyauté et confiance, présente des caractéristiques assez différentes de la génération précédente.
• Vous allez devoir réévaluer votre propre expertise, puisque vous allez devoir adapter votre discours à leur culture. Vous aborderez vos propres connaissances selon un angle très différent de celui dont vous avez l’habitude, ce qui vous mènera inévitablement à des découvertes dans des domaines que vous pensiez maîtriser.
• Enfin, vous allez devoir vous forger des compétences en présentation ; l’enseignement consiste réellement à sortir de votre zone de confort afin de présenter vos propres connaissances tout en les gardant intéressantes et divertissantes pour votre audience. Cela fera de vous un meilleur présentateur.

Ainsi, vous deviendrez un meilleur enseignant. De plus, vous remplirez mieux vos objectifs : des étudiants bien formés, dont certains s’engageront dans la communauté du Libre.

Conclusion

Au bout du compte, pourquoi feriez-vous tous ces efforts pour établir une relation de confiance avec une université et sortir de votre zone de confort en améliorant votre manière d’enseigner ? Eh bien, cela se résume vraiment à la question initiale à laquelle nous avons tenté de répondre : 

Si les communautés du Libre ne réussissent pas à attirer de nouveaux contributeurs venus des universités, est-ce simplement dû à leur inaction ?

D’après notre expérience, la réponse est oui. Au cours de ces cinq années passées à bâtir un partenariat avec l’IUP ISI, nous avons attiré deux étudiants par année en moyenne. Certains d’entre eux nous ont quittés après quelque temps, mais certains sont devenus des contributeurs très actifs. Les autres gardent encore une certaine nostalgie de cette période de leur vie et continuent de nous soutenir même s’ils ne contribuent pas directement. En ce moment même, nous avons une équipe locale KDE qui a réussi à organiser efficacement une conférence de deux jours pour notre dernière « release party » (NdT : soirée de lancement).

Parmi ces anciens étudiants, pas un seul ne se serait impliqué dans le projet KDE sans ces projets universitaires. Nous serions passés complètement à côté de ces talents. Par chance, nous n’avons pas été inactifs.

[1] http://www.kde.org

[2] https://fr.wikipedia.org/wiki/Ontologie_(informatique)

Université et communauté

Kevin Ottens

Kevin Ottens est un « hacker » de longue date au sein de la communauté KDE[1]. Il a largement contribué à la plateforme KDE, en particulier à la conception des API et frameworks. Diplômé en 2007, il est titulaire d’un doctorat en informatique qui l’a amené à travailler, en particulier, sur l’ingénierie des ontologies[2] et les systèmes multi-agents. Le travail de Kevin au KDAB inclut le développement de projets de recherche autour des technologies KDE. Il vit toujours à Toulouse, où il est enseignant à mi-temps dans son université d’origine.

Introduction

Les communautés du Libre sont principalement animées par l’effort de bénévoles. De plus, la plupart des personnes qui s’impliquent dans ces communautés le font lors de leur cursus universitaire. C’est la période idéale pour s’engager dans de telles aventures : on est jeune, plein d’énergie, curieux et l’on veut probablement façonner le monde à son image. Voilà tous les ingrédients d’un bon travail bénévole.

Mais, en même temps, être étudiant ne laisse pas forcément beaucoup de temps pour s’engager dans une communauté du Libre. En outre, la plupart de ces communautés sont assez vastes et les contacter peut faire peur.

Cela soulève évidement une question dérangeante : si les communautés du Libre ne réussissent pas à attirer la nouvelle génération de contributeurs talentueux, est-ce parce qu’elles ne cherchent pas activement à étendre leur activité dans les universités ? Cette question pertinente, nous avons essayé d’y répondre dans le contexte d’une communauté qui produit des logiciels, à savoir KDE. Dans cet article, nous nous concentrerons sur les aspects auxquels nous n’avions pas initialement pensé mais qu’il nous a fallu aborder pour répondre à cette question.

Construire un partenariat avec une université locale

Tout commence, réellement, par le contact avec les étudiants eux-mêmes. Et pour ça, rien de mieux que de se rendre directement dans leur université et de leur montrer à quel point les communautés du Libre peuvent être accueillantes. À cet effet, nous avons construit un partenariat avec l’université Paul Sabatier de Toulouse  plus précisément, avec l’un de ses cursus – nommé IUP ISI (NdT : Ingénierie des Systèmes Informatiques) – axé sur le développement logiciel.

L’IUP ISI était très orienté sur les connaissances « pratiques » et avait à ce titre un programme pré-établi pour les projets étudiants. Un point particulièrement intéressant de ce programme est le fait que les étudiants travaillent en équipe « inter-promotions ». Des étudiants de troisième et quatrième années, généralement en équipes de 7 à 10, apprennent à collaborer autour d’un objectif commun.

La première année de notre expérience, nous nous sommes raccrochés à ce programme en proposant de nouveaux sujets pour les projets, et en nous concentrant sur des logiciels développés au sein de la communauté KDE. Henri Massie, directeur du cursus, a très bien accueilli cette idée, et nous a laissés mettre cette expérience en place. Pour cette première année, nous nous sommes vu attribuer deux créneaux horaires pour les « projets KDE ».

Pour créer rapidement un climat de confiance, nous avons décidé, cette année-là, d’offrir quelques garanties concernant le travail des étudiants :

• Aider les professeurs à avoir confiance dans les sujets abordés : les projets sélectionnés étaient très proches des sujets enseignés à l’IUP ISI (c’est pourquoi, pour cette année, nous avons ciblé un outil de modélisation UML et un outil de gestion de projet) ;
• donner un maximum de visibilité aux professeurs : nous avons mis à leur disposition un serveur, sur lequel étaient régulièrement compilés les projets étudiants, accessible à distance à des fins de test ;
• faciliter la participation des étudiants à la communauté : les responsables des projets étaient désignés pour jouer le rôle du « client », soumettre leurs exigences aux étudiants et les aider à trouver leur chemin dans le dédale de la communauté ;
• enfin, pour mettre le pied à l’étrier aux étudiants, nous leur avons donné un petit cours sur « Comment développer avec Qt et les autres frameworks produits par KDE ».

Au moment de l’écriture de ces pages, cela fait cinq ans que nous menons de tels projets. De petits ajustements dans l’organisation ont été apportés ici et là, mais la plupart des idées sous-jacentes sont restées les mêmes. La majorité des changements ont été le résultat d’un intérêt grandissant de la communauté, désireuse d’établir un partenariat avec les étudiants, et d’une plus grande liberté pour nous quant aux sujets que nous pourrions couvrir dans nos projets.

De plus, tout au long de ces années, le directeur nous a donné une aide et des encouragements constants, attribuant effectivement plus de créneaux pour les projets de la communauté du Libre et prouvant que notre stratégie d’intégration était juste : établir de la confiance dès le début est la clé d’un partenariat entre la communauté du Libre et l’Université.

Comprendre que l’enseignement est un processus interactif

Durant ces années à tisser des liens entre la communauté KDE et la filière IUP ISI, nous nous sommes retrouvés en situation d’enseignement afin d’assister les étudiants dans des tâches liées à leurs projets. Quand vous n’avez jamais enseigné à une classe pleine d’étudiants, vous avez sans doute encore une image de vous, il y a quelques années, assis dans une classe. En effet, la plupart des enseignants ont un jour été étudiants… Parfois même, pas le genre d’étudiant très discipliné ni attentif. Vous aviez sans doute l’impression d’être submergé : l’enseignant entrait dans la salle, faisait face aux étudiants, et déversait sur vous ses connaissances.

Ce stéréotype est ce que la plupart gardent à l’esprit de leurs années d’études et la première fois qu’ils se retrouvent en situation d’enseigner, ils veulent reproduire ce stéréotype : arriver avec un savoir à transmettre.

La bonne nouvelle, c’est que rien n’est plus éloigné de la vérité que ce stéréotype. La mauvaise nouvelle, c’est que si vous essayez de reproduire ce stéréotype, vous allez très probablement faire fuir vos étudiants et ne ferez face qu’à un manque de motivation pour participer à la communauté. L’image que vous donnez de vous est la toute première chose dont ils vont se souvenir de la communauté : la première fois que vous entrez dans la salle de classe, vous êtes, pour eux, la communauté.

Pour éviter de tomber dans le piège de ce stéréotype, il vous faut prendre un peu de recul et réaliser ce que signifie réellement d’enseigner. Ce n’est pas un processus à sens unique où l’on livre la connaissance aux étudiants. Nous sommes arrivés à la conclusion que c’est en fait un processus à double sens : vous êtes amené à créer une relation symbiotique avec vos étudiants. Les étudiants et les enseignants doivent tous sortir de la salle de classe avec de nouvelles connaissances. Il vous faut livrer votre expertise, bien sûr, mais afin de le faire efficacement, vous devez en permanence vous adapter au cadre de référence de vos étudiants. C’est un travail qui rend très humble.

Cette prise de conscience génère pas mal de changements dans la manière d’entreprendre votre enseignement.

• Vous allez devoir comprendre la culture de vos étudiants. Ils ont probablement des expériences assez différentes des vôtres et vous allez devoir adapter votre discours à eux ; par exemple, les étudiants que nous avons formés font tous partie de la fameuse « génération Y » qui, en matière de leadership, loyauté et confiance, présente des caractéristiques assez différentes de la génération précédente.
• Vous allez devoir réévaluer votre propre expertise, puisque vous allez devoir adapter votre discours à leur culture. Vous aborderez vos propres connaissances selon un angle très différent de celui dont vous avez l’habitude, ce qui vous mènera inévitablement à des découvertes dans des domaines que vous pensiez maîtriser.
• Enfin, vous allez devoir vous forger des compétences en présentation ; l’enseignement consiste réellement à sortir de votre zone de confort afin de présenter vos propres connaissances tout en les gardant intéressantes et divertissantes pour votre audience. Cela fera de vous un meilleur présentateur.

Ainsi, vous deviendrez un meilleur enseignant. De plus, vous remplirez mieux vos objectifs : des étudiants bien formés, dont certains s’engageront dans la communauté du Libre.

Conclusion

Au bout du compte, pourquoi feriez-vous tous ces efforts pour établir une relation de confiance avec une université et sortir de votre zone de confort en améliorant votre manière d’enseigner ? Eh bien, cela se résume vraiment à la question initiale à laquelle nous avons tenté de répondre : 

Si les communautés du Libre ne réussissent pas à attirer de nouveaux contributeurs venus des universités, est-ce simplement dû à leur inaction ?

D’après notre expérience, la réponse est oui. Au cours de ces cinq années passées à bâtir un partenariat avec l’IUP ISI, nous avons attiré deux étudiants par année en moyenne. Certains d’entre eux nous ont quittés après quelque temps, mais certains sont devenus des contributeurs très actifs. Les autres gardent encore une certaine nostalgie de cette période de leur vie et continuent de nous soutenir même s’ils ne contribuent pas directement. En ce moment même, nous avons une équipe locale KDE qui a réussi à organiser efficacement une conférence de deux jours pour notre dernière « release party » (NdT : soirée de lancement).

Parmi ces anciens étudiants, pas un seul ne se serait impliqué dans le projet KDE sans ces projets universitaires. Nous serions passés complètement à côté de ces talents. Par chance, nous n’avons pas été inactifs.

[1] http://www.kde.org

[2] https://fr.wikipedia.org/wiki/Ontologie_(informatique)

Vous finirez par savoir tout ce qu’ils ont oublié

Leslie Hawthorn

Gestionnaire de communautés internationalement reconnue, conférencière et auteur, Leslie Hawthorn a plus de 10 ans d’expérience dans la gestion de projets high tech, le marketing et les relations publiques. Elle a récemment rejoint AppFog⁽¹⁾ en tant que responsable de la communauté, où elle est chargée du recrutement de développeurs. Auparavant, elle a travaillé comme responsable de communication au laboratoire open source de l’Université de l’état de l’Oregon et comme responsable de programme au sein de l’équipe open source de Google, où elle a géré le Google Summer of Code⁽²⁾, créé le concours que l’on connaît maintenant sous le nom Google Code-in et lancé le blog de développement open source de la société.

« La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment mettre rapidement le logiciel en route, une vue d’ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c’est exactement tout ce que les auteurs de la documentation connaissent parfaitement. Si parfaitement, qu’il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d’énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner. » Karl Fogel, Produire du logiciel libre⁽³⁾

Quand pour la première fois vous commencez à travailler sur un projet de logiciel libre et open source, la courbe d’apprentissage est raide et le chemin difficile. Vous risquez de vous retrouver abonné à des listes de diffusion ou dans des salons de discussion avec toutes sortes de gens renommés, comme le créateur de votre langage de programmation favori ou le responsable de votre logiciel préféré, et vous vous demanderez si vous serez un jour suffisamment qualifié pour contribuer efficacement. Ce dont vous n’aurez pas forcément conscience, c’est à quel point ces gens sages ont oublié le long chemin qui les a menés au succès.

Prenons une analogie simple : dans un projet open source, le processus d’apprentissage, comme utilisateur ou comme développeur, c’est un peu comme apprendre à faire du vélo. Pour les cyclistes expérimentés, « c’est aussi facile que de monter à vélo ». Vous avez probablement fait du vélo quelques fois et vous comprenez son architecture : une selle, des roues, des pédales et un guidon. Pourtant, vous montez en selle, concentré sur votre avancée et soudainement vous découvrez que ce n’est pas aussi simple que ce que vous pensiez : à quelle hauteur faut-il régler votre selle ? Quel équipement vous faut-il quand vous grimpez une colline ? Quand vous en descendez une ? D’ailleurs, avez-vous vraiment besoin de ce casque ? (un conseil : oui, absolument).

Lorsque vous vous mettez au vélo, vous ne savez même pas quelles questions poser et vous ne les trouverez que dans vos genoux endoloris, des points de côté et des courbatures dans le dos. Même dans ce cas, vos questions ne correspondront pas toujours aux réponses dont vous avez besoin ; quelqu’un pourrait s’aviser de vous dire d’abaisser la selle quand vous lui dites que vos genoux font mal, mais d’autres peuvent aussi bien supposer que tout ça est nouveau pour vous et que vous finirez bien par le découvrir par vous-même. Ils ont oublié qu’il faut se battre avec les changements de vitesse, se rendre compte qu’on n’a pas les bons éclairages ni les réflecteurs adéquats, comment tourner à gauche en levant la bonne main, parce qu’ils font du vélo depuis si longtemps que tous ces gestes sont pour eux comme une seconde nature.

Le scénario reste le même lorsque vous débutez dans le monde des logiciels libres et open source. Lorsque vous compilez un paquet pour la première fois, vous allez inévitablement arriver à un obscur message d’erreur ou un autre genre d’échec. Et lorsque vous demanderez de l’aide, une bonne âme vous dira sans doute : « c’est facile, il suffit de faire make -toto -titi -tata ». Sauf que pour vous, ce n’est pas facile. Il n’y aura probablement pas de documentation pour toto, titi ne fera pas ce qu’il est supposé faire et qu’est ce que ce truc tata avec ses huit homonymes sur Wikipédia ? Évidemment, vous ne voulez pas être un boulet, mais vous allez avoir besoin d’aide pour réussir vraiment à faire quelque chose.

Vous allez peut-être persister à reprendre les mêmes étapes, rencontrer les mêmes échecs, et la frustration ira grandissant. Peut-être que vous allez vous lever pour prendre un café en pensant que vous reviendrez sur le problème plus tard. Ce qu’aucun de nous dans le monde des logiciels libres et open source ne voudrait voir se produire, c’est précisément ce qui se passe pour beaucoup : boire cette tasse de café est infiniment meilleur que de se sentir ignorant et intimidé, et vous n’allez pas plus avant dans votre découverte du Libre.

Prenez conscience dès maintenant que vous finirez par connaître ces choses que les experts autour de vous ont oubliées ou qu’ils ne communiquent pas car ces étapes sont évidentes pour eux. Toute personne plus expérimentée que vous est passée par les mêmes affres que vous en ce moment pour apprendre à faire ce que vous vous efforcez de faire. Voici quelques conseils pour rendre votre parcours plus facile :

N’attendez pas trop longtemps avant de demander de l’aide. Personne ne veut être un boulet et personne n’aime avoir l’air perdu. Cela dit, si vous n’arrivez pas à résoudre votre problème après avoir essayé pendant 15 minutes, il est temps de demander de l’aide. Vérifiez dans la documentation sur le site web du projet que vous utilisez le bon canal IRC, le forum ou la liste de diffusion pour demander de l’aide. De nombreux projets ont des canaux d’aide en ligne spécialement pour les débutants, gardez donc un œil sur des mots tels que mentor, débutant et mise en route.

Parlez de votre processus (de réflexion). Il ne s’agit pas seulement de poser des questions, mais de savoir quelles sont les bonnes questions à poser. Au début, vous ne saurez pas forcément quelles sont ces bonnes questions. Donc quand vous demanderez de l’aide, détaillez ce que vous essayez de faire, les étapes par lesquelles vous êtes passé, et les problèmes que vous avez rencontrés. Signalez aux futurs mentors du canal IRC ou de la liste de diffusion que vous avez lu le manuel en incluant des liens vers la documentation que vous avez lue sur le sujet. Si vous n’avez trouvé aucune documentation, le signaler poliment peut aider.

Apprenez à connaître votre propre valeur. En tant que nouveau contributeur dans un projet, vous êtes un atout précieux. Non pas pour vos connaissances, mais pour votre ignorance. Lorsque vous commencez à travailler sur des logiciels libres et open source, rien n’est assez évident à vos yeux et tout mérite donc d’être expliqué. Prenez des notes à propos des problèmes que vous avez rencontrés, et de la façon dont ils ont été résolus. Puis utilisez ces notes pour mettre à jour la documentation du projet, travailler avec la communauté à des démos vidéo ou autres documents de formation pour les cas les plus épineux. Quand vous rencontrez un problème vraiment frustrant, comprenez que vous êtes en position idéale pour faire en sorte que le prochain qui tombera dessus ne rencontrera pas les mêmes difficultés.

1. http://www.appfog.com/ ^{^}
2. http://fr.wikipedia.org/wiki/Google_Summer_of_Code ^{^}
3. http://framabook.org/8-produire-du-logiciel-libre ^{^}

Vous finirez par savoir tout ce qu’ils ont oublié

Leslie Hawthorn

Gestionnaire de communautés internationalement reconnue, conférencière et auteur, Leslie Hawthorn a plus de 10 ans d’expérience dans la gestion de projets high tech, le marketing et les relations publiques. Elle a récemment rejoint AppFog⁽¹⁾ en tant que responsable de la communauté, où elle est chargée du recrutement de développeurs. Auparavant, elle a travaillé comme responsable de communication au laboratoire open source de l’Université de l’état de l’Oregon et comme responsable de programme au sein de l’équipe open source de Google, où elle a géré le Google Summer of Code⁽²⁾, créé le concours que l’on connaît maintenant sous le nom Google Code-in et lancé le blog de développement open source de la société.

« La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment mettre rapidement le logiciel en route, une vue d’ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c’est exactement tout ce que les auteurs de la documentation connaissent parfaitement. Si parfaitement, qu’il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d’énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner. » Karl Fogel, Produire du logiciel libre⁽³⁾

Quand pour la première fois vous commencez à travailler sur un projet de logiciel libre et open source, la courbe d’apprentissage est raide et le chemin difficile. Vous risquez de vous retrouver abonné à des listes de diffusion ou dans des salons de discussion avec toutes sortes de gens renommés, comme le créateur de votre langage de programmation favori ou le responsable de votre logiciel préféré, et vous vous demanderez si vous serez un jour suffisamment qualifié pour contribuer efficacement. Ce dont vous n’aurez pas forcément conscience, c’est à quel point ces gens sages ont oublié le long chemin qui les a menés au succès.

Prenons une analogie simple : dans un projet open source, le processus d’apprentissage, comme utilisateur ou comme développeur, c’est un peu comme apprendre à faire du vélo. Pour les cyclistes expérimentés, « c’est aussi facile que de monter à vélo ». Vous avez probablement fait du vélo quelques fois et vous comprenez son architecture : une selle, des roues, des pédales et un guidon. Pourtant, vous montez en selle, concentré sur votre avancée et soudainement vous découvrez que ce n’est pas aussi simple que ce que vous pensiez : à quelle hauteur faut-il régler votre selle ? Quel équipement vous faut-il quand vous grimpez une colline ? Quand vous en descendez une ? D’ailleurs, avez-vous vraiment besoin de ce casque ? (un conseil : oui, absolument).

Lorsque vous vous mettez au vélo, vous ne savez même pas quelles questions poser et vous ne les trouverez que dans vos genoux endoloris, des points de côté et des courbatures dans le dos. Même dans ce cas, vos questions ne correspondront pas toujours aux réponses dont vous avez besoin ; quelqu’un pourrait s’aviser de vous dire d’abaisser la selle quand vous lui dites que vos genoux font mal, mais d’autres peuvent aussi bien supposer que tout ça est nouveau pour vous et que vous finirez bien par le découvrir par vous-même. Ils ont oublié qu’il faut se battre avec les changements de vitesse, se rendre compte qu’on n’a pas les bons éclairages ni les réflecteurs adéquats, comment tourner à gauche en levant la bonne main, parce qu’ils font du vélo depuis si longtemps que tous ces gestes sont pour eux comme une seconde nature.

Le scénario reste le même lorsque vous débutez dans le monde des logiciels libres et open source. Lorsque vous compilez un paquet pour la première fois, vous allez inévitablement arriver à un obscur message d’erreur ou un autre genre d’échec. Et lorsque vous demanderez de l’aide, une bonne âme vous dira sans doute : « c’est facile, il suffit de faire make -toto -titi -tata ». Sauf que pour vous, ce n’est pas facile. Il n’y aura probablement pas de documentation pour toto, titi ne fera pas ce qu’il est supposé faire et qu’est ce que ce truc tata avec ses huit homonymes sur Wikipédia ? Évidemment, vous ne voulez pas être un boulet, mais vous allez avoir besoin d’aide pour réussir vraiment à faire quelque chose.

Vous allez peut-être persister à reprendre les mêmes étapes, rencontrer les mêmes échecs, et la frustration ira grandissant. Peut-être que vous allez vous lever pour prendre un café en pensant que vous reviendrez sur le problème plus tard. Ce qu’aucun de nous dans le monde des logiciels libres et open source ne voudrait voir se produire, c’est précisément ce qui se passe pour beaucoup : boire cette tasse de café est infiniment meilleur que de se sentir ignorant et intimidé, et vous n’allez pas plus avant dans votre découverte du Libre.

Prenez conscience dès maintenant que vous finirez par connaître ces choses que les experts autour de vous ont oubliées ou qu’ils ne communiquent pas car ces étapes sont évidentes pour eux. Toute personne plus expérimentée que vous est passée par les mêmes affres que vous en ce moment pour apprendre à faire ce que vous vous efforcez de faire. Voici quelques conseils pour rendre votre parcours plus facile :

N’attendez pas trop longtemps avant de demander de l’aide. Personne ne veut être un boulet et personne n’aime avoir l’air perdu. Cela dit, si vous n’arrivez pas à résoudre votre problème après avoir essayé pendant 15 minutes, il est temps de demander de l’aide. Vérifiez dans la documentation sur le site web du projet que vous utilisez le bon canal IRC, le forum ou la liste de diffusion pour demander de l’aide. De nombreux projets ont des canaux d’aide en ligne spécialement pour les débutants, gardez donc un œil sur des mots tels que mentor, débutant et mise en route.

Parlez de votre processus (de réflexion). Il ne s’agit pas seulement de poser des questions, mais de savoir quelles sont les bonnes questions à poser. Au début, vous ne saurez pas forcément quelles sont ces bonnes questions. Donc quand vous demanderez de l’aide, détaillez ce que vous essayez de faire, les étapes par lesquelles vous êtes passé, et les problèmes que vous avez rencontrés. Signalez aux futurs mentors du canal IRC ou de la liste de diffusion que vous avez lu le manuel en incluant des liens vers la documentation que vous avez lue sur le sujet. Si vous n’avez trouvé aucune documentation, le signaler poliment peut aider.

Apprenez à connaître votre propre valeur. En tant que nouveau contributeur dans un projet, vous êtes un atout précieux. Non pas pour vos connaissances, mais pour votre ignorance. Lorsque vous commencez à travailler sur des logiciels libres et open source, rien n’est assez évident à vos yeux et tout mérite donc d’être expliqué. Prenez des notes à propos des problèmes que vous avez rencontrés, et de la façon dont ils ont été résolus. Puis utilisez ces notes pour mettre à jour la documentation du projet, travailler avec la communauté à des démos vidéo ou autres documents de formation pour les cas les plus épineux. Quand vous rencontrez un problème vraiment frustrant, comprenez que vous êtes en position idéale pour faire en sorte que le prochain qui tombera dessus ne rencontrera pas les mêmes difficultés.

1. http://www.appfog.com/ ^{^}
2. http://fr.wikipedia.org/wiki/Google_Summer_of_Code ^{^}
3. http://framabook.org/8-produire-du-logiciel-libre ^{^}