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

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

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

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

Pour un cinéma promouvant le droit au partage

URL d’origine du document

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On y apprendra pèle mêle :

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

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

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

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

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

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

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

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

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

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

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

Laisser le champ libre

Lydia Pintscher

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La philosophie du logiciel libre

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

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

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

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

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

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

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

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

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

Il déclare :

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

Quelle vision déprimante de la nature humaine !

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

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

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

Les rapaces et la sécurité

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

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

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

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

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

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

Le logiciel libre et l’économie

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

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

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

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

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

Le marxisme

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

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

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

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

Liberté de pensée

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

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

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

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

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

L’ordre spontané

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

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

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

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

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

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

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

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

par Felipe Ortega

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

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

Le relais entre les générations

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

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

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

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

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

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

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

Le fossé de connaissances

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

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

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

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

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

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

C’est comme à la maison

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

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

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

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

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

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

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

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

[4] http://oss2006.org

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

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

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

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

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

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

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

par Felipe Ortega

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

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

Le relais entre les générations

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

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

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

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

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

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

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

Le fossé de connaissances

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

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

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

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

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

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

C’est comme à la maison

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

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

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

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

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

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

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

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

[4] http://oss2006.org

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

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

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

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

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

Conflit de génération sur le Web…

Les pères fondateurs avaient imaginé un réseau ouvert, génératif, bidouillable.

Ils sont aujourd’hui amers de constater que le Web est devenu un adolescent qui loin de chercher à émanciper ses utilisateurs, tente plutôt de les forcer dans des cases, de les infantiliser, de ne leur laisser aucun contrôle.

Le constat dressé la semaine dernière par Anil Dash a depuis été largement partagé par les vétérans du Web. Comme l’impression d’un paradis perdu.

Mais la roue tourne et les utopistes des débuts rêvent d’un retour aux sources, d’éduquer les milliards de nouveaux internautes, de leur faire partager leur rêve. Est-ce envisageable ? Surtout, même s’ils prenaient conscience des valeurs que portait le Web à ses débuts, la majorité des utilisateurs serait-elle prête à abandonner ses usages confortables actuels pour reprendre le flambeau des fondateurs et à explorer de nouvelles voies respectueuses de ces valeurs ?

Le retour au bricolage high-tech avec un fer à souder allié au code (Ardhuino, imprimantes 3D, FabLabs…), les initiatives comme celles du projet Webmakers qui vise à éduquer au Web toute une génération pour qu’elle s’en empare au lieu de le consommer, autant de signes d’une prise de conscience qui pourrait modifier la donne. Cet article qui lance un coup d’œil dans le rétroviseur n’est pas un moment de simple nostalgie mais une invitation au renouvellement des idéaux fondateurs.

Le Web que nous avons perdu

article original The Web We Lost par Anil Dash, proposé et présenté par Clochix

Traduction framalang Zii, KoS, Goofy, Garburst, lamessen

L’industrie technologique et sa presse ont traité l’explosion des réseaux sociaux et l’omniprésence des applications pour smartphone comme une victoire sans appel pour Monsieur Tout-le-monde, un triomphe de la convivialité et de l’autonomisation. On a moins parlé de ce que nous avons perdu tout au long de cette transition, et je trouve que les jeunes générations ne savent même pas comment était le Web autrefois.
Alors voici quelques aperçus d’un Web qui pour l’essentiel a disparu :

• Il y a 5 ans, la plupart des photos qu’on voulait partager étaient chargées sur Flickr, où elles pouvaient être taguées par les humains ou même par les applications et services, en utilisant un système de balises. Les images étaient facilement accessibles sur le Web, en utilisant de simples flux RSS. Et les photos chargées pouvaient facilement l’être sous des licences permissives comme celles fournies par Creative Commons, autorisant la modifications et la réutilisation de n’importe quelle façon par des artistes, des entreprises ou des particuliers.

• Il y a une dizaine d’années, Technorati vous laissait chercher sur la majeure partie du Web social en temps réel (cependant la recherche avait tendance à être horriblement longue pour l’affichage des résultats), avec des tags qui marchaient comment le font les hashtags sur Twitter aujourd’hui. Vous pouviez trouver des sites en relation avec votre contenu avec une simple recherche, et savoir qui s’exprimait dans un fil de discussion, indépendamment des outils ou plateformes utilisés pour exposer des idées. À l’époque, c’était tellement excitant que lorsque Technorati ne put faire face au volume croissant de la blogosphère, les utilisateurs furent très déçus. Au point que même quelqu’un d’aussi habituellement circonspect que Jason Kottke se mit à descendre le service en flammes pour l’avoir laissé tomber. Dès l’instant de ses premiers succès pourtant, Technorati avait suscité les louanges de gens comme John Gruber :

Vous pouviez, en théorie, écrire un logiciel pour examiner le code source des quelques centaines de milliers de blogs, et créer une base de données des liens entre ces blogs. Si votre logiciel était assez efficace, il devait pouvoir rafraîchir ses informations d’heure en heure, ajoutant de nouveaux liens à sa base de données en quasi-temps réel. En fait, c’est exactement ce qu’a créé Dave Sifry avec son incroyable Technorati. À ce jour, Technorati surveille 375 000 blogs et a référencé plus de 38 millions de liens. Si vous n’avez jamais joué avec Technorati, vous manquez quelque chose.

• Il y a dix ans, vous pouviez laisser les gens poster des liens sur votre site ou montrer des listes de liens qui pointaient vers votre site. Car Google n’avait pas encore introduit AdWords et AdSense, les liens ne généraient pas de revenus, c’était juste un moyen d’expression ou un outil éditorial. Le Web était un endroit intéressant et différent avant la monétisation des liens, mais en 2007 il devint clair que Google avait changé le Web pour toujours, et pour le pire, en corrompant les liens.

• En 2003, si vous aviez introduit un service d’authentification individuelle opéré par une société, même en documentant le protocole et encourageant les autres à cloner le service, vous auriez été décrit comme quelqu’un qui introduisait un système de surveillance relevant du « Patriot Act ». Il y avait une telle méfiance à l’égard services d’authentification que même Microsoft abandonna ses tentatives de créer un tel système d’inscription. Même si leur expérience utilisateur n’était pas aussi simple que la possibilité omniprésente de s’identifier avec Facebook ou Twitter, le service TypeKey introduit alors avait des conditions légales de partage des données bien plus restrictives. Et pratiquement tous les systèmes qui fournissaient une identité aux utilisateurs autorisaient l’usage de pseudonymes, respectant le besoin qu’ont les gens de ne pas toujours se servir de leur identité légale.

• Au début de ce siècle, si vous aviez créé un service qui permettait aux utilisateurs de créer ou partager du contenu, ils s’attendaient à pouvoir facilement télécharger une copie fidèle de leurs données, ou importer leurs données vers d’autres services compétitifs, sans la moindre restriction. Les entreprises commerciales passaient des années à travailler sur l’interopérabilité autour des échanges de données simplement pour le bénéfice de leurs utilisateurs, quitte à lever théoriquement les barrières pour l’entrée de la concurrence.

• Aux premiers temps du Web social, il était largement admis que de simples gens pourraient être propriétaires de leur identité en ayant leurs propres sites, plutôt que d’être dépendants de quelques gros sites pour héberger leur identité numérique. Dans cette vision, vous possédez votre nom de domaine et contrôlez complètement son contenu, plutôt que d’avoir les mains liées sur un site géré par une grande entreprise. C’était une réaction sensée lorsqu’on prenait conscience que la popularité des gros sites croît et chute, mais que les gens ont besoin d’une identité plus persistante que ces sites.

• Il y a cinq ans, si vous vouliez publier sur votre site du contenu d’un autre site ou d’une application, vous pouviez le faire en utilisant un format simple et documenté, sans avoir besoin de négocier un partenariat ou un accord contractuel entre les sites. L’expérience des utilisateurs n’était donc pas soumise aux caprices des luttes politiques entre les sociétés, mais basée sur l’architecture extensible du Web lui-même.

• Il y a une douzaine d’années, lorsque les gens voulaient soutenir les outils de publication qui symbolisaient cet état d’esprit, ils mutualisaient le coût des serveurs et des technologies nécessaires à ces outils, même si cela coûtait bien plus cher avant l’avènement de l’informatique dans le nuage et la baisse du prix de la bande passante. Leurs pairs de l’univers des technologies, même s’ils étaient concurrents, participaient même à cet effort.

Ce n’est pas notre Web aujourd’hui. Nous avons perdu les éléments-clés auxquels nous faisions confiance et pire encore, nous avons abandonné les valeurs initiales qui étaient le fondement du monde du Web. Au crédit des réseaux sociaux actuels, ils ont apporté des centaines de millions de nouveaux participants sur ces réseaux, et ils ont sans doute rendu riche une poignée de personnes. Mais ils n’ont pas montré le Web lui-même, le respect et l’attention qu’il mérite comme le support qui leur a permis de réussir. Et ils sont maintenant en train de réduire les possibilité du Web pour une génération entière d’utilisateurs qui ne comprennent pas à quel point leur expérience pourrait être beaucoup plus innovante et significative.

Retour vers le futur

Aujourd’hui, lorsque vous voyez des compilations intéressantes d’informations, elles utilisent encore souvent des photos de Flickr, parce qu’il n’y a pas grand-chose à faire avec les maigres métadonnées d’Instagram, et qu’Instagram n’utilise le Web qu’à contre-cœur. Lorsque nous ne pouvons pas retrouver d’anciens messages sur Twitter ou nos propres publications sur Facebook, nous trouvons des excuses aux sites alors que nous avions de meilleurs résultats avec une recherche sur Technorati, qui n’avait portant à sa disposition que de piètres logiciels de son époque. Nous assistons à de stupides combats de coqs avec Tumblr qui ne peut pas récupérer la liste de vos contacts sur Twitter, ou Facebook qui refuse que les photos d’Instagram s’affichent sur Twitter, tout cela parce que des entreprises géantes suivent chacune leur propre programme de développement au lieu de collaborer pour être utiles aux utilisateurs. Et nous nous coltinons une génération de patrons qui sont incités à créer des produits toujours plus bornés et hostiles au Web, tout cela pour permettre à un petit nombre de nantis de devenir toujours plus riches, au lieu de laisser les gens se créer de nouveaux possibles innovantes au dessus du Web lui-même.

Je ne m’inquiète pas, nous allons corriger tout cela. L’industrie technologique, comme toutes les industries, suit des cycles, et le pendule est en train de revenir vers les philosophies globales et émancipatrices sur lesquelles le Web social s’est bâti au début. Mais nous allons devoir affronter un gros défi, ré-éduquer un milliard d’utilisateurs pour leur apprendre ce qu’est le Web, comme nous l’avons fait pendant des années il y a dix ans quand tout le monde a quitté AOL, leur apprendre qu’il y a bien plus à expérimenter sur Internet que ce qu’ils connaissent.

Ce n’est pas ici la polémique habituelle à base de : « ces réseaux verrouillés sont mauvais ». Je sais que Facebook, Twitter, Pinterest, LinkedIn et tous les autres sont de super-sites, qui apportent beaucoup à leurs utilisateurs. D’un point de vue purement logiciel, ce sont de magnifiques réussites. Mais ils sont basés sur quelques hypothèses qui ne sont pas forcément exactes. La première idée fausse d’où découlent beaucoup de leurs erreurs est que donner aux utilisateurs de la flexibilité et du contrôle crée forcément une expérience utilisateur complexe qui empêche leur croissance. La seconde hypothèse erronée, plus grave encore, est de penser qu’exercer un contrôle total sur les utilisateurs est le meilleur moyen de maximiser les profits et la rentabilité de leur réseau.

La première étape pour les détromper, c’est que les gens qui sont en train de créer la prochaine génération d’applications sociales apprennent un peu d’histoire, pour savoir de quoi ils parlent, qu’il s’agisse du modèle économique de Twitter, des fonctions sociales de Google ou de n’importe quoi d’autre. Nous devons savoir ce qui a été essayé et a échoué, quelles bonnes idées étaient tout simplement en avance sur leur temps, et quelles occasions ont été gâchées par la génération actuelle de réseaux sociaux dominants.

Qu’est-ce que j’oublie ? Qu’avons-nous perdu d’autre sur le Web social ?

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

Libres conseils (1/42)

Traduction framalang peupleLa, tibs, Astalaseven, aKa, lerouge, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, jcr83, Goofy, Gatien Bovyn, Antoine, lamessen, AlBahtaar + 2 anonymes

Première Partie, Idées et innovations

1. Du code avant toute chose

Armijn Hemel a utilisé des logiciels libres depuis 1994, lorsque son frère est revenu à la maison avec une pile de disquettes contenant l’une des premières versions de FreeBSD. Un an après, il migrait vers GNU/Linux, et depuis il n’utilise plus que des systèmes de type Unix, que ce soit chez lui, pour ses études à l’université d’Utrecht ou au travail. Depuis 2005, Armijn est membre du noyau dur de l’équipe de gpl-violations.org tout en possédant son propre cabinet de conseil (Tjaldur Software Governance Solutions) spécialisé dans la détection et la résolution de litiges nés de violations de licences GPL.

En 1999, je faisais tout juste mes premiers pas dans l’activisme du logiciel libre et Open Source. J’utilisais déjà Linux et FreeBSD depuis un certain nombre d’années, mais je n’étais encore qu’un simple utilisateur et je souhaitais apporter une contribution en retour. De mon point de vue, la meilleure manière de le faire était d’écrire du code. Étant donné que je ne trouvais aucun projet existant dans lequel j’aurais été à l’aise pour travailler, j’ai décidé de commencer mon propre projet. Avec le recul, je constate que plusieurs raisons m’ont poussé à débuter ce projet. L’une tenait à mes doutes sur le fait que mon code était d’une qualité suffisante pour être accepté dans un projet existant (je n’étais pas un programmeur brillant et d’ailleurs je ne le suis toujours pas), alors que pour un projet personnel, la question ne se pose pas. La seconde raison est certainement l’arrogance de la jeunesse.

Mon idée était de créer un logiciel de présentation, qui pourrait imiter la plupart des fonctionnalités les plus avancées (ou si vous préférez, les plus pénibles) de PowerPoint. À ce moment-là, OpenOffice.org n’existait pas et le choix était relativement limité : LaTeX et MagicPoint, qui sont davantage orientés vers le contenu textuel que sur les effets d’animation. Je voulais créer un logiciel multi-plateforme, et j’ai pensé que pour remplir cet objectif Java serait le meilleur choix.

Le concept était de faire un logiciel de présentation, écrit en Java, qui aurait intégré tous ces effets animés. Je me suis décidé et j’ai commencé le projet.

Toute l’infrastructure nécessaire était déjà disponible : une liste de diffusion, un site web, un système de gestion de versions (CVS). Mais il n’existait aucun code source qui aurait permis à des contributeurs potentiels de travailler directement . La seule chose en ma possession, c’était quelques idées de ce que je voulais faire, une démangeaison à soulager, et des slogans publicitaires séduisants. Je voulais en fait que beaucoup de gens rejoignent le projet pour que celui-ci devienne réellement un projet collaboratif.

J’ai commencé par faire des plans (avec mes nouvelles connaissances en UML) et à les faire circuler. Rien ne s’est passé. J’ai essayé d’impliquer des contributeurs, mais créer une architecture de manière collaborative est très difficile (sans compter qu’a priori, ce n’est sûrement pas le meilleur moyen de créer un logiciel). Après un certain temps, j’ai laissé tomber et le projet est mort en silence, sans qu’une seule ligne de code ait été écrite. Chaque mois je recevais des messages par la liste de diffusion qui me rappelaient que ce projet avait un jour existé, j’ai donc demandé sa mise hors-ligne.

J’en ai tiré une leçon précieuse, quoiqu’un peu douloureuse : dès lors que vous annoncez quelque chose et que vous souhaitez que les gens s’impliquent dans votre projet, assurez-vous au moins qu’il y ait un minimum de code disponible. Peu importe qu’il ne soit pas complètement terminé ; il est acceptable même s’il est mal dégrossi (au début en tout cas). Mais au moins cela démontre l’existence d’une base sur laquelle des contributeurs peuvent travailler et ainsi l’améliorer. Dans le cas contraire, votre projet finira de la même manière que tant d’autres, dont le mien : aux oubliettes.

Finalement, j’ai trouvé mon créneau pour contribuer au progrès du logiciel libre et open source, en m’assurant que les fondements légaux de ceux-ci restent protégés par l’intermédiaire du projet gpl-violations.org. Rétrospectivement, je n’ai jamais utilisé — sans en éprouver de frustration d’ailleurs — les effets animés dans les logiciels de présentation. En fait, je les trouve de plus en plus irritants, ils nous distraient trop du contenu. Pour faire mes présentations, je suis un utilisateur heureux de LaTeX Beamer et occasionnellement — mais avec moins de plaisir — d’OpenOffice.org/LibreOffice.

Crédit photo vampir 42 (CC-BY-SA)

Qui n’a pas son projet libre ?

Plus qu’une mode ou un engouement passager, c’est un véritable mouvement de fond depuis quelques années : toute une communauté qui crée, échange, élabore, donne et reçoit des contributions, enfourche de nouveaux projets…

Fort bien, mais…

SourceForge récemment et Github aujourd’hui sont de véritables cimetières de projets libres et open source qui n’ont jamais trouvé d’audience, d’équipe de développement, de communauté active. Rien de bien tragique là-dedans. On peut estimer que ces plateformes sont pour beaucoup de libristes une sorte de terrain de jeu, de laboratoire, d’incubateur où le code et sa documentation s’expérimentent par à-coups, avec l’enthousiasme et l’énergie de ceux qui s’emparent d’un outil pour le mettre au service de leur créativité. Un excellent moyen d’apprendre en faisant finalement, à code ouvert. Et qu’importe alors l’absence d’aboutissement dans 80% des cas puisque c’est la démarche qui a été formatrice.

Cependant vous pouvez avoir envie de dépasser le stade du hobbyiste sympathique qui va bricoler son génial projet dans son coin. Vous pouvez avoir le désir de mettre toutes le chances de votre côté pour que le projet libre aboutisse vraiment, gagne en notoriété, entre dans une logique commerciale, vous procure amour, gloire et beauté.

C’est précisément l’intérêt du feuilleton dont vous allez déguster les épisodes semaine après semaine.

42 auteurs vous feront partager leur expérience, avec sérieux et humour, vous raconteront leurs ratages et leurs succès, vous diront comment éviter les uns et atteindre les autres. Des principes, des recommandations mais aussi des trucs et des ficelles, bref une ribambelle chatoyante de libres conseils.

Chaque semaine ou presque, l’équipe framalang vous proposera un nouvel épisode traduit du livre électronique en anglais Open Advice.

Chaque semaine — top départ chaque jeudi soir à 21h — une ou deux tranches du gâteau seront proposées à la traduction collaborative sur un framapad, donc en libre accès pour tous ceux qui souhaitent y contribuer. Participez à l’aventure !

La version que nous publierons ensuite ici même, comme dans le premier échantillon ci-dessous qui est une sorte de préambule, est un premier état de la traduction (donc évidemment perfectible), l’étape suivante sera une révision générale de tous les articles pour les joindre en un Framabook à venir.

Eh oui ça se passe comme ça chez Frama !

Les traducteurs de ce premier round d’échauffement :

peupleLa, Astalaseven, Hideki, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, Slystone, schap2, 4nti7rust, Goofy, Antoine, lamessen + 4 anonymes

Libres Conseils

Logiciels libres et open source : ce que nous aurions aimé savoir avant de commencer

Open Advice est une base de connaissances provenant d’une grande variété de projets de logiciels libres. Elle répond à des questions dont 42 contributeurs majeurs auraient aimé connaître les réponses lorsqu’ils ont débuté. Vous aurez ainsi une longueur d’avance quelle que soit la façon dont vous contribuez et quel que soit le projet que vous avez choisi.

Les projets de logiciels libres modifient le paysage du logiciel de façon impressionnante grâce à des utilisateurs dévoués et une gestion innovante. Chacun apporte quelque chose au mouvement à sa façon, avec ses capacités et ses connaissances. Cet engagement personnel et la puissance du travail collaboratif sur Internet donnent toute leur force aux logiciels libres et c’est ce qui a rassemblé les auteurs de ce livre.

Ce livre est la réponse à la question « Qu’auriez-vous aimé savoir avant de commencer à contribuer ? » Les auteurs offrent un aperçu de la grande variété de talents qu’il faut rassembler pour réussir un projet de logiciel : le codage bien sûr, mais aussi le design, la traduction, le marketing et bien d’autres compétences. Nous sommes là pour vous donner une longueur d’avance si vous êtes nouveau. Et si ça fait déjà un moment que vous contribuez, nous sommes là pour vous donner un aperçu d’autres domaines et projets.

pour les géants et ceux qui se tiendront sur leurs épaules [1] 

Avant-propos

Ce livre parle de communauté et de technologies. Il est le fruit d’un travail collectif, un peu comme la technologie que nous construisons ensemble. Si c’est votre première rencontre avec notre communauté, vous pourrez trouver étrange de penser qu’une communauté puisse être le moteur qui propulse la technologie. La technologie n’est-elle pas l’œuvre des grands groupes industriels ? En fait, pour nous c’est presque l’inverse. Les auteurs de ce livre sont tous membres de ce que vous pourriez appeler la communauté du logiciel libre. Un groupe de personnes qui partagent l’idée fondatrice que les logiciels sont plus puissants, plus utiles, plus flexibles, mieux contrôlables, plus justes, plus englobants, plus durables, plus efficaces, plus sûrs et finalement simplement meilleurs quand ils sont fournis avec les quatre libertés fondamentales : la liberté d’utiliser, la liberté d’étudier, la liberté de partager et la liberté d’améliorer le logiciel.

Et bien qu’il y ait maintenant un nombre croissant de communautés qui ont appris à se passer de la proximité géographique grâce aux moyens de communication virtuels, c’est cette communauté qui en a été le précurseur.

En fait, Internet et la communauté du logiciel libre[2] suivaient des développements mutuellement dépendants. Au fur et à mesure qu’Internet grandissait, notre communauté pouvait grandir en même temps. Mais sans les valeurs ni la technologie qu’apportait notre communauté, il ne fait aucun doute à mes yeux que jamais Internet n’aurait pu devenir ce réseau global reliant les personnes et les groupes du monde entier.

À ce jour, nos logiciels font fonctionner la majeure partie d’Internet, et vous devez en connaitre au moins quelques-uns, comme Mozilla Firefox, OpenOffice.org, Linux, et peut-être même Gnome ou KDE. Mais notre technologie peut aussi se cacher dans votre téléviseur, votre routeur sans fil, votre distributeur automatique de billets, et même votre radio, système de sécurité ou bataille navale. Elle est littéralement omniprésente.

Ils ont été essentiels dans l’émergence de quelques-unes des plus grandes sociétés que vous connaissez, comme Google, Facebook, Twitter et bien d’autres. Aucune d’entre elles n’aurait pu accomplir autant en si peu de temps sans le pouvoir du logiciel libre qui leur a permis de monter sur les épaules de ceux qui étaient là avant eux. Mais il existe également de nombreuses petites entreprises qui vivent de, avec, et pour le logiciel libre, dont la mienne, Kolab Systems. Le fait d’agir activement avec la communauté et dans un bon esprit est devenu un élément de succès essentiel pour nous tous. Et c’est aussi vrai pour les plus grosses, comme Oracle nous l’a involontairement démontré durant et après sa prise de contrôle de Sun Microsystems. Il est important de comprendre que notre communauté n’est pas opposée au commerce. Nous aimons notre travail, et beaucoup d’entre nous en ont fait leur métier pour gagner leur vie et rembourser leurs crédits. Donc quand nous parlons de communauté, nous voulons dire des étudiants, des entrepreneurs, des développeurs, des artistes, des documentalistes, des professeurs, des bricoleurs, des hommes d’affaires, des commerciaux, des bénévoles et des utilisateurs. Oui, des utilisateurs. Même si vous ne vous en êtes pas encore rendu compte ou n’avez jamais appartenu à une communauté, vous faites en réalité déjà partie de la nôtre. La question est de savoir si vous allez y participer activement. Et c’est cela qui nous différencie des poids lourds de la monoculture, des communautés fermées, des jardins clôturés de sociétés telles qu’Apple, Microsoft et d’autres. Nos portes sont ouvertes. Tout comme nos conseils. Et également notre potentiel. Il n’y a pas de limite à ce que vous pouvez devenir — cela dépend uniquement de votre choix personnel comme cela a été le cas pour chacun d’entre nous.

Donc si vous ne faites pas encore partie de notre communauté, ou si vous êtes simplement curieux, ce livre offre un bon point de départ. Et si vous êtes déjà un participant actif, ce livre pourrait vous offrir un aperçu de quelques facettes et de quelques perspectives qui seront nouvelles pour vous.

En effet, ce livre contient d’importantes graines de ce savoir implicite que nous avons l’habitude de construire et de transférer à l’intérieur de nos sous-communautés qui travaillent sur diverses technologies. Ce savoir circule généralement des contributeurs les plus expérimentés vers les moins expérimentés. C’est pourquoi il semble tellement évident et naturel à ceux qui fréquentent notre communauté. Ce savoir et cette culture de la collaboration nous permettent de créer d’extraordinaires technologies avec de petites équipes du monde entier au-delà des différences culturelles, linguistiques et de nationalité. Cette manière de fonctionner permet de surpasser des équipes de développement bien plus grandes de certaines des plus grosses sociétés au monde. Tous les contributeurs de ce livre ont une expérience solide dans au moins un domaine, parfois plusieurs. Ils sont devenus des enseignants et des mentors. Au cours des quinze dernières années, j’ai eu le plaisir d’apprendre à connaître la plupart d’entre eux, de travailler avec beaucoup, et j’ai le privilège de compter certains parmi mes amis.

Comme l’a dit judicieusement Kévin Ottens pendant le Desktop Summit 2011 à Berlin, « construire une communauté, c’est construire de la famille et de l’amitié ».

C’est donc en réalité avec un profond sentiment de gratitude que je peux dire qu’il n’y a aucune autre communauté dont je préférerais faire partie, et je suis impatient de vous rencontrer à l’une ou l’autre des conférences à venir.

— Georg Greve

Zürich, Suisse, le 20 août 2011

Georg Greve a fondé la Free Software Foundation Europe (FSFE) en 2000 et en a été le président fondateur jusqu’en 2009. Durant cette période, il a été responsable du lancement et du développement de nombreuses activités de la FSFE, telles que les alliances, la politique ou les travaux juridiques. Il a intensivement travaillé avec de nombreuses communautés. Aujourd’hui, il poursuit ce travail en tant qu’actionnaire et PDG de Kolab Systems AG, une société qui se consacre entièrement aux logiciels libres. Pour ses actions en faveur du logiciel libre et des standards ouverts, Georg Greve a été décoré de la croix fédérale du mérite (Bundesverdienstkreuz am Bande) par la République Fédérale d’Allemagne le 18 décembre 2009. Thank You! Merci !

Ce livre n’aurait pu voir le jour sans la participation de chaque auteur et des personnes suivantes, qui ont aidé à sa réalisation :

Anne Gentle (relecture)

Bernhard Reiter (relecture)

Celeste Lyn Paul (relecture)

Daniel Molkentin (mise en page)

Debajyoti Datta (site internet)

Irina Rempt (relecture)

Jeff Mitchell (relecture)

Mans Rullgard (relecture)

Noirin Plunkett (relecture)

Oregon State University Open Source Lab (hébergement du site internet)

Stuart Jarvis (relecture)

Supet Pal Singh (site internet)

Saransh Sinha (site internet)

Vivek Prakash (site internet)

Will Kahn-Greene (relecture)

* * * * * *

[1] Note des traducteurs : dédicace par allusion à « Nous sommes des nains juchés sur les épaules de géants. » Bernard de Chartres, XIIe siècle

[2] Note de l’auteur : pour moi, l’Open Source n’est que l’un des aspects de cette communauté. Cet aspect particulier a trouvé son articulation en 1998, c’est-à-dire quelque temps après l’arrivée d’Internet. Mais n’hésitez pas à dire « Open Source » au lieu de « logiciel libre » si vous préférez ce terme.

Crédits photo hellojenuine (CC-BY-SA)

Les entreprises utilisant et fabriquant du logiciel libre à destination des écoles primaires sont rares. Il faut reconnaître que le marché est compliqué et beaucoup plus difficile à conquérir puisqu’il faut démarcher chaque mairie là où les conseils généraux suffisent pour les collèges. C’est donc un travail de fourmi que doivent fournir ces sociétés pour exister. Nous avions rencontré en mars dernier les co-présidents d’iMaugis. Aujourd’hui, c’est Éric Seigne, que nous avons le plaisir d’interviewer. Il en profite pour nous annoncer une nouvelle qui devrait, nous l’espérons, faire beaucoup de bruit 😉

Bonjour Éric. Pour ceux qui ne te connaissent pas, peux-tu te présenter ?

Éric Seigne, 34 ans , directeur de la société RyXéo, éditeur de AbulÉdu, ensemble de logiciels libres multidisciplinaires à destination des établissements scolaires. Je suis un des membres fondateurs de l’ABUL, Association Bordelaise des Utilisateurs de Logiciels Libres, ainsi que d’autres associations libres.

Comment as-tu découvert le libre ?

Pendant mes années de lycée, dans le journal local (Sud Ouest) on pouvait lire que se tenaient à Bordeaux des repas entre Experts Linux… À cette époque, j’avais la chance de pouvoir bidouiller l’ordinateur de ma sœur aînée, alors équipée de DOS, tandis que mes amis disposaient d’ Amiga et Amstrad (avec écran couleur, son, jeux…) … Je me contentais du prompt A:>_ …

J’ai ensuite installé un OS/2 puis ai enfin eu mon propre ordinateur, pc offert par mon grand-père.

J’ai trouvé le moyen d’installer une slackware sans en connaître les commandes rudimentaires… J’ai persévéré et ai, comme beaucoup d’autres, apprécié. Après mon bac, je me suis installé à Bordeaux et y ai effectué mes études. J’ai enfin pu participer à ces fameux repas de linuxiens bordelais où la constitution d’une association locale (ABUL) a été décidée. À cette époque, des personnes telles que Pierre Ficheux ont suscité chez moi une réelle admiration ! À tel point qu’une Redhat a remplacé la slackware sur ma machine. La découverte de l’interface graphique n’a finalement pas changé grand-chose… si ce n’est de pouvoir lancer un Netscape… les habitudes étaient déjà trop grandes… j’appréciais les fameuses lignes de commande et ne comptais plus les abandonner.

J’ai également participé à quelques demo-parties et ai pu admirer les prouesses des démos 4k, des équipes dev-gfx-zique… la créativité de ces gens est tout simplement incroyable.

Je savais que je n’aurais pas dû jouer autant avec mon Amstrad 6128 😉
Tu es à l’initiative de nombreux projets ou tu y participes : RyXéo, AbulÉdu, AbulÉdu-fr, AbulÉdu ENT, Le Terrier, Pédagosite, Scideralle…
Vu de l’extérieur, cela commence à ressembler à l’anarchie des projets Framasoft 😉
Tu peux nous les présenter pour y voir plus clair ?

Connais-tu “la cathédrale et le bazar“ ? Ce livre fait partie de mes lectures qui ont eu une grosse influence sur ma trajectoire, au même titre que l’incroyable “hold up planétaire” de Roberto di Cosmo). Je suis un créateur sur le mode « bazar » qui, de temps en temps, essaye de remettre un peu d’organisation « cathédrale » pour repartir sur un cycle bazar et ainsi de suite :

• 1998 création de l’Abul et définition de nos prérogatives à savoir l’éducation, la création du groupe Abul-edu, qui donnera naissance au projet Abuledu

• 1998 l’AFUL signe une convention avec le Ministère de l’Éducation Nationale (Stéphane F., Thierry S., Bernard L., Nat M. Jean-Pierre L. et toute l’équipe de l’AFUL que je ne remercierai jamais assez pour ce coup d’éclat) qui nous ouvre les portes et définit le cadre de travail dont nous bénéficions dans ce secteur

• 1998 Jean Peyratout, instituteur à Gradignan (à 200 m de chez moi), fondateur de l’ABUL nous fait vibrer au son de « je suis instituteur laïc, républicain, gratuit … et néanmoins obligatoire et à ce titre j’ai du mal à mettre mes élèves devant des ordinateurs Microsoft Windows pour leur faire utiliser Microsoft Word (ou Write), Microsoft Excel, Microsoft Encarta, Microsoft truc et ainsi de suite, il y a la une entorse à mon éthique (et mon devoir de neutralité) que j’ai du mal à avaler, j’aimerais savoir si “linux” pourrait pas nous offrir un choix ».

• 1999/2000 le groupe Abul-edu (une trentaine de bénévoles de l’association) installe “des ordinateurs en réseau” dans l’école primaire de Jean Peyratout. On va du recyclage de vieux pc à l’installation d’un “serveur” (de mémoire un P3 avec 128 ou peut-être 256 Mo de RAM) … Camille C. nous amène une techno: “LTSP“… on essaie également XTermKit de Jacques Gélinas… Pour faire simple on pourrait dire que les enfants utilisent AbulÉdu en semaine et des adultes barbus s’adonnent à leur hobby le week end…

• 2000 premières RMLL, le cycle éducation présente des projets extrêmement ingénieux, dont celui de Jacques Gélinas (Hacker kernel, papa de linuxconf) qui enivre la foule… en fin de journée, nous faisons des démonstrations autour d’AbulÉdu. À la fin de la conférence, plus d’une dizaine d’enseignants viennent nous voir et nous disent qu’ils veulent faire la même chose dans leur école. Dans l’euphorie de l’événement on leur lâche un « chiche, revenez dans un an on vous donnera un cd d’installation »

• Cette même année 2000, je crée l’entreprise individuelle Rycks

• Un an plus tard, lors des RMLL 2001, on lance le CDROM AbulÉdu 1.0 basé sur Mandrake 7.2 (je salue et remercie encore les hackers de Mandrake qui nous ont aidés et soutenus)… La communauté s’élargit alors jusqu’en Afrique de l’Ouest, au Burkina Faso, en Côte d’Ivoire et bien naturellement partout en France. Des enseignants comprenant notre démarche vis à vis des enjeux du libre dans le milieu scolaire veulent créer des logiciels pour aider leurs enfants à apprendre à lire, compter… un coup de pouce technique plus tard Le Terrier d’AbulÉdu est né.

• Dans notre approche constructiviste, suite à des retours utilisateurs, nous créons Pédagosite, une nouvelle fois, dans notre bazar. L’idée est de mettre en commun les fiches pratiques et pédagogiques des enseignants contributeurs.

• 2003 l’association ABUL, le groupe abul-edu et AbulÉdu décident de structurer. L’ABUL a pour mission de s’occuper de Linux sur Bordeaux (je schématise) et AbulÉdu prend alors son envol. Le groupe Abul-edu se réunit et créé l’association SCIDERALLE.

• 2003 Rycks devient RyXéo, quittant le statut d’entreprise individuelle pour celui de SARL. Le changement n’intervient pas de façon isolée et AbulÉdu passe alors sur Debian. Nous proposons une solution clé en main de serveurs pré-installés accompagnés de maintenance. Le succès est mitigé : des clients qui nous rapportent de l’argent mais un malaise naît au sein de la communauté qui a du mal à comprendre qu’on puisse vendre du logiciel libre. 5 années plus tard, en 2008, nous relançons « AbulÉdu gratuit », version 8.08. Porteuse d’espoirs, elle nous apporte très rapidement son lot de désillusions, des donneurs d’ordre téléchargent la version gratuite, l’installent dans des écoles mais ne contractent ni support, ni expertise, ni formation auprès de RyXéo, même à 30 euros par mois !

Et la naissance d’AbulÉdu-fr ?

L’association a été constituée en 2010 et regroupe les utilisateurs d’AbulÉdu. Depuis 2011 nous essayons de resserrer les liens entre la communauté et RyXéo, l’association AbulÉdu-fr est la bonne interface pour ça.

Le bilan de l’association est présenté sur le site de l’association. toute aide est la bienvenue, en particulier d’un point de vue financier : l’association a du mal à payer les frais de déplacement pour les développeurs bénévoles lorsqu’ils viennent chez nous (RyXéo) une fois par mois.

RyXéo a toujours eu des liens avec l’éducation, notamment avec les écoles. Sauf erreur de ma part, c’est la seule entreprise, qui, en 2009, répondait intégralement au cahier des charges du ministère lors du Plan École Numérique Rurale. Pourtant de nombreuses autres entreprises ont finalement été retenues lors de ce plan (dont certaines se sont d’ailleurs mystérieusement volatilisées depuis). Comment l’expliques-tu ? Penses-tu que le fait de proposer des solutions libres a été, à ce moment là, un inconvénient ?

Je suis mal placé pour dire si on était les seuls à être compatibles avec le cahier des charges, je dirais juste qu’on a essayé d’apporter la réponse la plus claire possible.

Concernant les truands qui se sont placés sur ce marché pour voler de l’argent public et disparaître après avoir livré partiellement des écoles oui, ça m’a rendu assez malheureux.

Ensuite, ce plan était dans le « plan de relance de l’économie », j’ai observé qu’on a surtout relancé les importations de matériels produits à l’étranger. J’aurais préféré qu’on inverse le ratio matériel-service en s’appuyant par exemple sur du recyclage d’ordinateurs et en mettant beaucoup de ressources humaines en jeu en incluant des heures de passage dans les écoles pour que les entreprises fassent réellement du boulot d’accompagnement technique. Voire qu’on injecte des moyens financiers sous forme de création de postes d’animateurs TICE (ou dans les CDDP ou dans les équipes des Inspections Académiques ou autres structures existantes) pour que les enseignants puissent réellement mettre en pratique des usages avec des professionnels de la pédagogie…

Depuis 2010, de nouveaux logiciels du Terrier ont été développés et certains réécrits. Cela marque une réelle rupture aussi bien au niveau visuel que technologique par rapport aux premiers logiciels. Comment se font ces nouveaux développements ?

• En 2009, nous (RyXéo) avons fait un bilan à la fois fonctionnel et technique des logiciels du Terrier d’AbulÉdu. Nous en avons tiré les 3 principales conclusions:

1. logiciels pertinents et reconnus sur les aspects métier
2. graphismes et ergonomie à repenser
3. améliorations techniques du code applicatif à mettre en œuvre

Je tiens à signaler au passage que les logiciels en question sont vraiment conséquents, par exemple Association nécessite 1500 dessins et près d’un millier de mots (sous forme de sons) enregistrés ! À de nombreuses reprises la communauté des développeurs a lancé des appels à contribution pour avoir des dessins et des ressources libres réutilisables… sans grand succès.

• Ryxéo engage un graphiste (en fait il s’agit d’un dessinateur de BD et illustrateur). En parallèle nous testons différents langages pour nos futurs logiciels (python, pygame, etc) sans en être vraiment convaincus. Puis sur le test du logiciel Raconte-moi, nous tentons l’aventure Qt/C++.
• Au même moment, nous accueillons en stage, un enseignant avec qui nous avons l’habitude de travailler. Avec notre équipe technique, il développe le logiciel Calcul-Mental et travaille en forte collaboration avec le graphiste.

Le résultat est évident : nous sommes séduits… et l’équipe s’étoffe en l’embauchant à l’issue de son stage.

Parlons de choses qui fâchent 😉

Parmi les nouveaux logiciels, certains sont téléchargeables directement, d’autres accessibles uniquement après un achat en boutique. Pourquoi ce changement de politique ? Pourquoi cette différence de traitement entre les logiciels ?

Comme évoqué un peu plus tôt, Ryxéo est une équipe qui regroupe des développeurs, graphistes et pédagogues qui œuvrent à l’essor et au maintien de la solution AbulÉdu. Les salariés de l’entreprise reçoivent un salaire à la fin du mois. Le modèle économique Ryxéo, tel un éditeur, est basé sur le support, la maintenance et les formations autour des solutions proposées à nos clients.

À côté de ça, il faut savoir que l’estimation des dépenses globales au niveau national en logiciels pour les écoles en 2011 est de plusieurs millions d’euros (exemple 500.000 euros pour l’académie de Toulouse, sources : http://tice.ac-toulouse.fr/web/635-cheque-ressources.php) … Ne serait il pas pertinent que les ressources libres en bénéficient ?

Il n’en demeure pas moins que, nous sommes tous très impliqués, individuellement comme collectivement, et ce depuis de nombreuses années, à titre bénévoles dans des associations et des communautés. .

Cela dit, j’avoue qu’un de mes rêves serait de lancer une opération “logiciel libre à prix libre”… Peut être encore trop tôt… Mais un jour viendra, je l’espère.

Pour moi la réussite d’un projet libre n’est pas tant qu’il soit utilisé par des milliers d’utilisateurs que de créer des emplois et de la richesse. La FSF a eu l’intelligence de ne pas mettre de conditions « non commercial » dans la GPL et c’est vraiment important.

Puisque tu parles de “logiciel libre à prix libre”, RyXéo a lancé un Pedagogic Bundle permettant aux utilisateurs d’acheter un pack de logiciels du Terrier. SI je ne me trompe pas, cette opération en anglais a permis de récolter 800 $. Quel bilan en tires-tu ? Pourquoi ce choix d’une opération en anglais ?

C’est un test à plusieurs niveaux: je pense que l’aspect international est compliqué à aborder pour des logiciels pédagogiques, je ne pense pas que les enseignements soient les mêmes partout. Néanmoins je cherche pour voir s’il existerait un « écho » dans la communauté internationale qui gravite autour des logiciels libres et de l’éducation.

800€ c’est très peu et beaucoup : très peu compte tenu de l’exemple qu’on a pris pour s’en inspirer (humble bundle) et beaucoup parce que vu le peu de publicité qu’on a faite on a tout de même des retours.

Ensuite ce sont des personnes plutôt militantes qui nous ont pris ce bundle et nous ont spontanément proposé de participer aux traductions et prochaines offres…

Où en est le projet de micro-blogue pour les écoles primaires porté par l’association AbulÉdu-fr ?

Il s’agit d’un projet porté par l’association. Un projet véritablement important, à faire vivre, demandant du temps. Je profite donc de la tribune offerte pour demander à tout contributeur potentiel de ne pas hésiter à proposer son temps et son aide en remplissant ce formulaire de contact : http://www.abuledu-fr.org/Contacter-l-association.html

Passons à l’actualité chaude de RyXéo. Tu viens, ce samedi de présenter un produit qui devrait faire beaucoup de bruit, la TEDI. C’est quoi ?

Depuis deux ans, le phénomène « tablettes » envahit notre quotidien. Les écoles ne sont pas en reste et certaines, se sont lancées très tôt dans les démarches d’acquisition de ces nouveaux matériels.

La tablette est vue comme un gros téléphone, multi-tâche, à la frontière entre le matériel de productivité et le gadget. À ce titre je me dis que le combat de “détaxe” ou de “vente liée” est perdu ou tout au moins mal embarqué sur ces plates-formes …

Android prend de plus en plus de part de marchés et souffle le chaud et le froid (libre, pas libre, par exemple une version d’Android n’a jamais été publiée) … je fais de la veille technologique active et envisage un éventuel avenir libre aux tablettes scolaires.

RyXéo achète quelques tablettes pour découvrir que l’univers ARM (les puces qui équipent l’écrasante majorité des tablettes pour ne pas dire la totalité) est structuré d’une manière bien différente de la plateforme “pc/intel” que je connais bien. Il est par exemple très compliqué de choisir le périphérique d’amorçage et d’envisager de démarrer sur une clé usb, le réseau ou une carte SD … allons-nous être obligés de développer pour iOS ou Android ?

RyXéo développe cependant une « solution tablettes pour développeurs » sur une plate-forme intel tout en synthétisant notre cahier des charges « école primaire »  :

• Matériel aussi ouvert que possible
• Système d’exploitation libre et logiciels libres
• Assez robuste pour être confié à des enfants
• Léger
• d’un look “sympa” ou tout au moins, sortant de l’ordinaire

J’estime qu’en tant que développeurs nous avons des responsabilités. Je m’explique: si je développe une application pour iOS ou Android je ne peux pas ignorer que l’identité numérique des futurs utilisateurs de mon logiciel sera gérée par un de ces deux géants. Il en va de même pour les données qui seront forcément indexées voire stockées sur le cloud de ces mastodontes, probablement hors du territoire national et donc soumis à une loi qui n’est même pas la nôtre. De ce fait il est de notre responsabilité de proposer des alternatives durables, ouvertes, libres et pérennes. D’autant plus qu’on est dans un domaine ou nos utilisateurs (les enfants) n’ont pas encore construit leur esprit critique et qu’ils font confiance aux adultes que nous sommes pour avoir fait les bons choix !

Comment est né ce partenariat avec Unowhy ?

Après quelques recherches et échanges avec nos clients et partenaires, la tablette qooq/unowhy est identifiée. Contact est pris avec l’industriel, nous achetons une tablette « développeur » et installons un hack d’AbulÉdu en test.

Ensuite tout s’enchaîne, nous rencontrons l’équipe dirigeante de Unowhy, effectuons une démonstration de la tablette « AbulÉdu », et nous voici, samedi 8 décembre 2012, pour l’annonce officielle de cette Tablette.

J’apprécie en particulier sur leur tablette et avec leur approche qu’il n’y a ait aucun connecteur propriétaire: rien que du standard ! (usb, ethernet, sdcard, jack pour le casque) … c’est suffisamment rare pour le signaler !

Présent à Éducatice Unowhy présentait justement son projet de tablette scolaire et parlait d’une expérimentation en collège. Est-ce un projet différent ou bien est-ce également un partenariat avec RyXéo ?

Ce sont deux projets différents qui pourraient paraître complémentaires. Je précise néanmoins que TEDI AbulÉdu a aussi été présentée le 22 sur le stand de Unowhy à Éducatice.

Je ne savais pas. Je n’ai pas eu l’occasion d’aller à Éducatice cette année.

Au niveau du système d’exploitation, je suppose que ce n’est pas iOS. Est-ce Android ou un développement maison ? Une adaptation d’AbulÉdu ?

C’est un vrai GNU/Linux, fondé sur l’excellent boulot de linaro. Et sur lequel nous avons réalisé le même travail que pour AbulÉdu « Live » ou « Serveur ».

Puisqu’on parle de partenariat, il y au final peu d’acteurs dans l’univers du libre au niveau de l’école primaire (ASRI Édu, Beneyluschool, OLPC, OOo4kids, Sankoré, GCompris …). As-tu des échanges, liens avec eux ?

C’est juste de le dire, on est peu nombreux et la quantité baisse avec les années (par exemple cette année nous perdons l’excellente équipe de PingOO). Le grand absent de cette liste est edubuntu, qui, pour moi, est un exemple intéressant : AbulÉdu serveur étant fondé sur ubuntu, j’ai souhaité leur offrir l’interface d’administration d’AbulÉdu il y a quelques années. Tous les paquets .deb existent et marchent dans plusieurs centaines d’école tous les jours en France … Le retour que j’ai eu a été … étonnant : notre interface d’administration étant en PHP le responsable du projet edubuntu n’a même pas daigné le regarder. Aujourd’hui nous faisons et refaisons tous la même chose (des interfaces d’administration) au lieu d’utiliser des forces à la création de ressources pédagogiques, de logiciels d’apprentissages, de retours utilisateurs etc.

Beneyluschool est exemple également intéressant. En 2010 quand on a voulu proposer un ENT à nos clients, on a cherché les sources de la Beneyluschool… introuvables ou alors une version vieille comme Hérode. D’autre part, le site faisant appel à du flash de manière importante, nous avons décidé de créer notre ENT. Cependant, en 2012, Beneyluschool libère le code de sa version 3.0 qui n’utilise à priori plus de flash… Je suis heureux de voir cette nouvelle orientation et le contact est en cours pour voir comment intégrer l’accès à l’ENT depuis les tablettes pour les clients que nous avons en commun.

De même, nous avons intégré OOo4Kids dans AbulÉdu mais quelques ajustements sont encore nécessaires, notamment entre OOo et OOo4Kids (quel logiciel a la priorité sur l’association des fichiers dans le navigateur de fichiers par exemple).

Concernant GCompris la cible et l’approche sont différentes : GCompris est un moteur d’activités ludo-éducatives, Bruno a même ajouté l’interprétation de script python dans GCompris pour simplifier l’ajout de nouveaux modules par des développeurs tiers. Notre approche est différente : nous avons préféré avoir un exécutable indépendant pour chaque logiciel. Par contre au niveau de la distribution AbulÉdu, GCompris fait partie des logiciels que nous diffusons systématiquement.

Avec OLPC et ASRI Édu, nous n’avons pas encore de réels liens mais l’occasion se présentera peut être un jour.

Ryxeo fêtera ses 10 ans l’année prochaine, c’est un véritable succès ! Si tu devais choisir parmi ces propositions laquelle définirait le mieux la situation actuelle ?

* Grâce au choix du logiciel libre, RyXéo est prospère et je suis un patron très riche. * L’équilibre est précaire mais sans le logiciel libre l’aventure n’aurait pas été possible. * RyXéo aurait sûrement été plus prospère en choisissant le logiciel privatif.

À vrai dire, je ne sais pas trop commenter ces aspects. Je dirais que depuis 10 ans, l’aventure est belle, soumise à des moments heureux comme des périodes délicates. Si je devais tirer un bilan, il serait très positif. La prospérité est plus celle du cœur et de la connaissance que du compte en banque mais je ne regrette pas mes choix !

Pour finir, si des lecteurs du blog sont intéressés par un des projets, peux-tu nous dire de quoi vous avez besoin actuellement ?

Le projet AbulÉdu recherche des contributeurs pour collecter des ressources libres sur internet et les ajouter dans l’entrepôt de données data.abuledu.org En trois mois nous avons déjà collecté plus de 5000 ressources libres… aidez-nous pour arriver à 50 000 pour les RMLL 2013 !

Ensuite si nous voulons que notre plate-forme soit remplie de ressources libres, il faut les produire. Nous lançons donc un appel à tous les enseignants créateurs de ressources à les mettre sous licence libre (compatible avec cc-by-sa) et nous les envoyer (ou les envoyer eux même sur l’entrepôt) pour qu’elles soient mises à disposition de tous et indexées selon les normes en vigueur, (LOM, SCOLOM etc.) dans l’entrepôt de données pédagogiques .

Enfin, nous sommes à la recherche de donneurs de voix pour enregistrer des histoires pour les enfants, ou lire des textes.

Sur les aspects techniques, si des développeurs souhaitent rejoindre la communauté AbulÉdu, ils et elles seront chaleureusement accueillis (voir la liste de diffusion dev@abuledu.org) et notamment lors de nos week-ends abuledu@ryxeo.

Merci Éric !