Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

Avez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés 🙂

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.

Sarah Sharp a de multiples passions sympathiques comme on peut le voir sur la page où elle se présente : développeuse, cycliste, jardinière… et geek. Si nous choisissons aujourd’hui de lui donner un écho francophone, c’est parce qu’elle est libriste de longue date et qu’elle a travaillé pendant sept ans dans l’équipe qui gère et maintient le kernel Linux, c’est-à-dire le noyau du système.

Dans un billet sans acrimonie ni attaque ad hominem, elle explique nettement pourquoi elle a cessé d’apporter sa contribution à ce haut niveau de programmation : lassée d’un mode de communication qui tolère et justifie la brutalité entre ses membres, elle regrette que l’équipe du kernel n’ait pas su évoluer vers des rapports humains plus acceptables.

Elle soulève ici une question désagréablement lancinante, celle du délicat respect de chacun ; il n’est pas indifférent qu’une fois encore ce soit une femme qui estime n’avoir plus sa place au sein d’une équipe de développement. Puisse cet exemple nourrir la réflexion et contribuer à faire évoluer un peu les esprits.

Notez que ce texte critique qui a eu un certain retentissement a été suivi d’un volet plus « constructif » de Sarah Sharp, dans lequel elle propose cinq niveaux et appelle à un changement culturel de fond dans les communautés libristes , ce qui est certes plus complexe que de s’abriter derrière l’alibi d’un code de conduite…

Tourner la page

par Sarah Sharp, article original sur son blog : Closing a door.
Traduction Framalang : Sphinx, audionuma, r0u, goofy, line

Voilà un an que ce billet est dans mon répertoire de brouillons. Ce n’était jamais le bon moment pour le publier. je m’inquiétais toujours des contrecoups. Cela fait un bon moment que je tourne autour de l’idée d’évoquer ce sujet en public, mais mon propre refus de reconnaître ce problème a fini par me ronger complètement. Alors le voici.

En un mot : je ne suis plus développeuse du noyau Linux. J’ai transféré en douceur la maintenance du pilote du contrôleur USB 3.0 en mai 2014. En juin 2015, j’ai mis fin à mon rôle de coordinatrice du programme d’ouverture aux femmes du logiciel libre (OPW), et j’ai évolué pour aider à coordonner le programme Outreachy. Le 6 décembre 2014, j’ai animé ce que j’espère être ma dernière présentation sur le développement du noyau Linux. On m’a demandé de coordonner la conférence Linux Plumbers à Seattle en août 2015 et j’ai refusé. La fin de mon mandat au Linux Advisory Board approche et je ne serai pas candidate à ma réélection.

Si j’avais le choix, je n’enverrai jamais plus un correctif, un rapport de bug ou une proposition sur les listes de discussion du noyau Linux. Mes boîtes de réception personnelles ont regorgé de messages de cette liste et je les ai ignorés. Mon travail actuel sur l’activation des modes graphiques dans l’espace utilisateur nécessitera peut-être que j’envoie occasionnellement des correctifs du noyau, mais je sais que je vais passer au moins une journée à craindre les éventuels retours destructeurs de l’interaction avec la communauté qui gère le noyau avant d’envoyer quoi que ce soit.

Je ne fais plus partie de la communauté du noyau Linux.

C’est le résultat d’une longue période de réflexion, et de beaucoup de temps passé à planifier ma succession. Je n’ai pas pris à la légère cette décision de me retirer. Je me suis sentie coupable, pendant longtemps, de ce retrait. Quoi qu’il en soit, j’ai finalement pris conscience que je ne pouvais plus contribuer à une communauté au sein de laquelle j’étais respectée sur le plan technique, mais où je ne pouvais pas demander à être respectée en tant que personne. Je ne pouvais plus travailler avec des gens qui encouragent les nouveaux venus à envoyer des correctifs, et réclament ensuite le droit pour les « mainteneurs » de cracher n’importe quelle grossièreté qu’ils considèrent nécessaire pour conserver une honnêteté affective radicale. Je ne voulais plus travailler professionnellement avec des gens qui s’en sortent malgré leurs blagues subtilement sexistes ou homophobes. Je me sens désarmée devant une communauté qui a un « code de résolution des conflits » qui ne contient même pas une liste explicite de comportements à éviter et une communauté qui n’a pas la volonté de faire appliquer ce code.

J’ai le plus grand respect pour les efforts techniques accomplis par la communauté du noyau Linux. Elle a développé un projet qui se concentre sur le respect des meilleurs standards de code qui existent. La focalisation sur l’excellence technique, la surcharge de travail des mainteneurs et la collaboration entre personnes qui proviennent de différentes cultures et normes sociales sont trois facteurs qui expliquent que les mainteneurs du noyau Linux sont souvent directs, grossiers voire brutaux pour que le travail soit fait. Les meilleurs développeurs du noyau Linux se crient souvent dessus pour corriger mutuellement leur comportement.

Ce type de communication ne me convient pas du tout. J’ai besoin d’une communication qui puisse être brutale sur le plan technique tout en étant respectueuse sur le plan personnel. J’ai besoin que quelqu’un puisse me corriger lorsque je fais une erreur (qu’elle soit technique ou sur le plan social) sans pour autant me faire descendre en tant que personne. Nous sommes humains, nous commettons des erreurs et nous les corrigeons. Nous nous énervons envers quelqu’un, nous sur-réagissons, et puis nous nous excusons et essayons de travailler ensemble pour trouver une solution.

J’aurais préféré que la communication au sein de la communauté du noyau Linux se passe de manière plus respectueuse. J’aurais préféré que les mainteneurs du noyau Linux communiquent de façon plus saine quand ils sont contrariés. J’aurais préféré que davantage de personnes assurent la maintenance du noyau Linux, ainsi ils n’auraient pas eu à être aussi brusques et directs.

Malheureusement, les changements de comportement que j’aimerais voir dans la communauté du noyau Linux ne se produiront sans doute pas de sitôt. Plusieurs développeurs seniors du noyau Linux approuvent le fait que les mainteneurs puissent être durs sur les plans technique et personnel. Même si à titre personnel ce sont des gens charmants, ils ne veulent pas que le mode de communication du noyau Linux change.

Cela veut dire qu’ils font passer les besoins affectifs des autres développeurs du noyau Linux (faire tomber la pression en se défoulant sur les autres, en étant brutal, impoli ou grossier) avant mes propres besoins affectifs (le besoin d’être respectée en tant que personne, et de ne pas être la cible de violence psychologique ou d’injures). C’est une dynamique perverse qui privilégie la position des mainteneurs établis au mépris du respect fondamental de l’être humain.

Je ne publie pas ce message à l’attention des développeurs du noyau. Je ne publie pas ce message pour pointer du doigt des personnes précises. Je publie ce message parce que je suis affligée pour la communauté dont je ne souhaite plus faire partie. Je poste ce message car je suis triste à chaque fois que quelqu’un me remercie de revendiquer de meilleures normes pour la communauté, parce que j’ai finalement abandonné l’idée de changer la communauté du noyau Linux. Le changement de culture est un processus long et douloureux et je n’ai plus l’énergie pour prendre une part active à ce changement de mentalité dans la communauté du noyau.

J’ai l’espoir que la communauté du noyau Linux évoluera avec le temps. J’ai participé à cette évolution, et la documentation, les tutoriels et les programmes que j’ai initiés (comme les stages noyau Outreachy) continueront à se développer en mon absence. Je reviendrai peut-être un jour, lorsque les choses iront mieux. J’ai une carrière de plusieurs décennies devant moi. Je peux attendre. En attendant, il existe d’autres communautés du logiciel libre, plus amicales, où je peux jouer ma partition.

Lorsqu’une porte se ferme, une autre s’ouvre, mais souvent nous restons si longtemps et avec tant de regrets devant la porte fermée que nous ne voyons même pas celle qui vient de s’ouvrir devant nous.

— Alexander Graham Bell

 

________

Crédits image :

• Photo  © Sarah Sharp licence CC-BY-NC-SA

C’est officiel : Google Code, qui permettait aux développeurs de déposer, partager, et collaborer sur du code logiciel (libre ou pas), va bientôt fermer ses portes.

Il va donc rejoindre le mémorial des projets sabordés par Google.

La raison la plus probable, c’est que GitHub (une plateforme concurrente) attire bien plus de développeurs, et donc de code, que Google Code. Non seulement grâce à une interface plus intuitive, mais aussi par une facilité bien plus grande pour les développeurs à collaborer ensemble (plus on est de fous, plus il y a de code produit).

D’ailleurs, Google ne s’en cache pas et propose, dans le courrier annonçant la clôture prochaine du service, un outil permettant de transférer votre projet logiciel de Google Code à GitHub.

Quelles réflexions cela devrait-il nous inspirer ?

D’abord, que malgré sa puissance financière massive, Google n’est pas systématiquement le meilleur dans son domaine. Et qu’une « petite » entreprise (267 salariés, tout de même) comme GitHub, Inc, peut amener le géant de Mountain View à fermer un service qui hébergeait malgré tout plus de 250 000 projets logiciels.

Cela pourrait paraître pour une bonne nouvelle : la diversité et l’innovation resteraient possibles ! L’argent n’achèterait pas tout ! Skynet (pardon, Googleternet) n’aurait pas encore un pouvoir absolu !

Ensuite, que Google continue à être une entreprise qui ne s’entête pas. Si un projet fonctionne, tant mieux (et autant devenir le meilleur au monde dessus). Sinon, tant pis, c’est que le marché n’est pas mûr, que les technologies utilisées n’étaient pas les bonnes, que les équipes n’étaient pas les meilleures, ou que les utilisateurs n’étaient pas prêts. Google Plus étant pour l’instant l’exception à la règle.

Cependant, peut-on considérer cela comme un fait positif ?

Pas vraiment. Car cela concentre encore un peu plus les utilisateurs sur GitHub.

Alors certes, il est toujours possible de quitter GitHub, de reprendre son code et d’aller le déposer ailleurs. Mais si tous les développeurs sont sur GitHub, il y aura une forme de pression sociale à continuer d’utiliser cette plateforme.

Donc, cela soulève deux questions.

1. Les développeurs de logiciels libres ont-il intérêt à utiliser GitHub ?

La plateforme est extrêmement pratique, confortable et performante, il faut le reconnaître.

Mais le code de GitHub n’est pas libre.

Ce manque de transparence peut avoir des conséquences importantes.

D’abord, GitHub pourrait peu à peu se garnir de publicités, tel un sapin de Noël. Cela serait désagréable, mais pas bloquant.

Ensuite, GitHub pourrait modifier les données hébergées sans les accords des auteurs. Par exemple, intégrer des fichiers (publicitaires, malveillants, etc.) dans les .zip téléchargés par millions quotidiennement sur la plateforme. Ca serait peut-être se tirer une balle dans le pied pour la société, mais cela n’a pas empêché Sourceforge, alors plus importante forge logicielle mondiale, de le faire. Et rien que le fait que GitHub puisse le faire est inquiétant et devrait interroger tout développeur de logiciel libre.

Enfin, nous, utilisateurs, n’avons pas le pouvoir sur les choix technologiques ou ergonomiques de GitHub. Si, demain, GitHub décide de modifier l’interface de telle ou telle façon, les développeurs seront tels des consommateurs dans un supermarché qui changerait ses produits d’allées, ou qui supprimerait tel ou tel produit : pris au piège de la volonté d’un tiers.

2. Quel est le modèle économique de GitHub ?

Certes, GitHub est une boite « sympa » (comme l’était Google à ses débuts). L’entreprise est toujours en mode start-up : largement financée par des fonds levés auprès de sociétés de capital-risque. Sans cet argent, GitHub serait déficitaire. Or, si des entreprises comme Andreessen Horowitz (fondées par des anciens de<span lang="en" Netscape) investissent 100 millions de dollars dans GitHub, elles espèrent probablement un retour sur investissement.

Or, la valeur de GitHub (en dehors de l’argent gagné sur les comptes privés), repose essentiellement sur le nombre de comptes utilisateurs (plus de 9 millions) et la quantité de code hébergé (plus de 20 millions de projets). Un peu comme la valeur de Facebook est largement déterminée par leur milliard d’utilisateurs.

GitHub étant en forte croissance, l’entreprise n’est pas à vendre. Cependant, rien ne permet d’affirmer qu’une fois une masse critique atteinte (et l’argent frais épuisé), GitHub ne se déclarera pas ouverte à un rachat. Et là, nul doute que Google pourrait être intéressé.

Alors, que faire ?

S’autohéberger.

Participer à la résistance à ce mouvement centripète de « centralisation du web » ou les plus gros services deviennent toujours plus gros, mettant ainsi en péril — sous prétexte de confort — l’équilibre d’un Internet qui pourrait bien finir aux mains de quelques entreprises.

Mais autohéberger son code, ce n’est pas toujours simple, notamment lorsqu’il faut interagir avec de nombreux développeurs.

De nombreuses forges logicielles, aux codes sources libres, existent déjà. Citons par exemple (liste non exhaustive) :

• Savannah (maintenu par la Free Software Foundation)
• Gna! (fork de Savannah, mais qui ne propose pas git)
• les amis de TuxFamilly
• la forge de l’Adullact, dédiée aux projets des collectivités
• Gitlab.com (dont on va vous reparler plus bas 😉 )
• Gitorious (qui vient de se faire racheter par… Gitlab, fait plutôt rare dans le milieu du logiciel libre)

Et Framasoft, dans tout ça ?

Comme vous le savez (ou non), Framasoft s’est fixé comme objectif – en toute modestie ! – de « Dégoogliser Internet ». Oui, rien que ça.

Il s’agit d’un programme sur 3 ans, visant à :

• sensibiliser le grand public sur les questions de centralisation du Web, de concentration/exploitation des données, et de vie privée ;
• démontrer que notre meilleure chance de résistance se trouve dans le logiciel libre, en mettant en place une trentaine d’alternatives à des services fermés (Google Docs, Skype, Doodle, etc.), suivant une charte de services Libres, Éthiques, Décentralisés et Solidaires ;
• essaimer, en encourageant et en accompagnant les structures qui, après avoir testé les services Frama*, souhaiteraient les mettre en place pour elles-mêmes (en clair, nous ne souhaitons pas recentraliser le Web « chez » Framasoft, mais bien aider les gens qui le souhaitent à s’auto-héberger).

Google Code, et plus largement GitHub, rentrent bien dans les critères de services au code source fermé, qui cherchent à attirer un maximum d’utilisateurs.

Dans notre démarche « Quitter Google », nous annoncions en mai 2014 que nous avions mis en place notre propre forge, basée sur le projet libre Gitlab.

Announcing : git.framasoft.org

Aujourd’hui, nous sommes heureux de pouvoir vous annoncer que la forge git.framasoft.org est désormais ouverte à tous.

Comme pour nos autres services (Framapad, Framadate, etc), nous vous encourageons à tester le service, sur lequel nous prenons les engagements de notre charte L.E.D.S.

Et, si ce dernier vous plaît, nous vous encourageons à… le quitter ! Par exemple en installant gitlab (nous proposerons dans les jours qui viennent une documentation en français, comme pour nos autres services).

https://git.framasoft.org permet la création de 42 dépôts maximum par compte (encore une fois, si vous avez besoin de plus, songez sérieusement à vous auto-héberger). En revanche, petits plus par rapport à GitHub, vous pouvez parfaitement créer des dépôts privés.

Par ailleurs, il est possible de « mirrorer » automatiquement vos dépôts sur GitHub : vous continuez à « engraisser la bête », mais vous êtes déjà moins dépendant, et vous conservez une visibilité auprès des presque 10 millions d’inscrits sur GitHub. Votre dépôt sur notre Gitlab est automatiquement poussé sur votre dépôt Github. C’est d’ailleurs la solution retenue par Framasoft, qui dispose toujours d’un compte GitHub, alors que les développements sont réalisés sur notre forge.

Pour mettre en place ce « mirroring », il suffit de nous écrire un petit mail sur http://contact.framasoft.org/, nous vous expliquerons la marche à suivre et nous nous occuperons du reste.

Comme on dit chez nous : « La route est longue, mais la voie est libre… »

• Accédez à la forge logicielle de Framasoft

EDIT : notre administrateur système vient de réparer la page d’import des dépôts Github sur notre Gitlab (accessible depuis l’interface de création de projet). Il n’a jamais été aussi facile de passer sur une solution libre !

Aujourd’hui, c’est la Saint Valentin, et l’occasion de déclarer son amour des logiciels libres !

Framasoft vous a déjà proposé son adaptation délirante de poèmes pour l’occasion, et voici une petite bande-dessinée qui synthétise l’événement :

Cette bande-dessinée est extraite du nouveau blog Grise Bouille hébergé par Framasoft.

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

Aujourd’hui, ce n’est pas un jour comme les autres. Journée de l’amour pour les uns, journée commerciale à bougonner pour les autres, elle ne laissera personne indifférent. Pourquoi ne lui donner une dimension toute différente, en en profitant pour déclarer notre amour aux logiciels libres, et aux développeurs du libre que nous torturons à longueur d’année, en bons utilisateurs exigeants et spécialistes du yakafokon que nous sommes.

C’est ce que nous propose la FSF avec sa campagne I love Free software, reconduite cette année. Il est important parfois de savoir lâcher prise pour clamer haut et fort que nous les aimons, ces logiciels libres.

Nous avons choisi pour notre part de vous proposer un fork de poèmes que vous devez tous connaître… Demain dès l’aube, de Victor Hugo et Le dormeur du Val d’Arthur Rimbaud.

Demain dès l’aube (v1.337)

Demain, dès l’aube, à l’heure des châteaux en Espagne,
Je râlerai. Vois-tu, je sais que tu m’entends.
De toi j’exigerai de coder des montagnes.
Je ne puis retenir mes commits plus longtemps.

Ce jour, je te le souhaite sans bug à obvier,
Nulle exigence en moi, nulle attente s’induit,
Seul, ton labeur, le dos courbé, mains au clavier,
Fier, voit le fruit de l’écran qui a blanchi tes nuits.

Je ne t’apporterai ni les bitcoins qui tombent,
Ni le vert des dollars qui ternit leur valeur,
Mais bientôt avec toi nous ferons la bombe
Une main sur la bière et l’autre sur le cœur.

Le codeur d’eval()

(v. 4.2)

Dans un réduit obscur il chante une rengaine
Enchaînant follement les semaines aux semaines,
Content quand des lignes obscures s’empilent
Et il boit du maté quand son code compile.

Un codeur jeune, Git ouvert, tête nue
Et la face baignant dans de frais rayons bleus
Dort ; il est vautré dans le PHP chenu
Pâle dans son t-shirt geek au Tux globuleux

Les mains dans le cambouis, il dort. Souriant comme
Sourirait un géant, ce n’est pourtant qu’un homme :
Le livreur de pizzas seul nourrit cet ermite.

Les crashtests, il s’en est déjà bien trop nourri ;
Il dort sur son clavier, la main sur la souris,
Tranquille. Il a deux bugfix dans son commit.

Plein de datalove à vous !

Chez Framasoft, on ne code pas (ou très peu). On utilise le code développé par des personnes formidables, par des communautés de passionné-e-s, et on le propose au grand public sous forme de services libres et gratuits.

Nous tenons donc aujourd’hui à déclarer notre amour aux équipes développant Etherpad (Framapad), Ethercalc (Framacalc), studs & le fork framadate, Wisemapping et Mindmaps (FramindMap), SVG-Edit (Framavectoriel), TinyTinyRSS (Framanews), Wallabag (Framabag), Diaspora* (Framasphère)… et tant d’autres !

Et un spécial chaton d’amour aux équipes (et à la fondation Mozilla) derrière FireFox qui vous permettent  d’utiliser ces applications web depuis un navigateur Libre.

Le développement du plugin a démarré mi-décembre, dont cette annonce aura été le témoin.

La feuille de route prévue était basée sur le fait que que le développeur consacrerait environ la moitié de son temps à MyPads et ce, jusqu’à la fin du mois de février.

Le calendrier est en réalité quelque peu décalé et compressé. Outre les fêtes de fin d’années, le prestataire a préféré en terminer avec ses autres engagements professionnels. Il n’a donc que très peu avancé sur MyPads.

Il a désormais assuré qu’il se dédierait exclusivement jusqu’à la fin du mois de février au plugin. Des progrès rapides devraient être visibles sur notre espace Gitlab (en maintenance pour le moment), à travers le code source, les tickets et le wiki.

Si les tests en conditions réelles ne se feront que dans quelques semaines, la date de sortie annoncée n’est pas pour autant remise en cause : le plugin reste prévu pour la fin du mois de février.

MyPads: development is back

The development of MyPads has begun from the second half of December. Here is the annoucement.

The initial roadmap was based upon the fact the programmer would dedicate half of his time to MyPads development, from December to the end of February.

The schedule will actually be postponed and compressed. In addition to year’s end celebrations, the contractor has chosen to finish his other professional commitments. Consequently he hasn’t done much work for MyPads.

He has confirmed that he will be dedicated full time working on the plugin til the end of February. You’d be able to see significant progress in our Gitlab instance (at the moment down for maintenance), through the source, tickets and the wiki.

If real world tests can only be possible within a few weeks, the announced publishing date isn’t challenged: MyPads remains scheduled before March.

(english version below)

Notre éditeur de texte libre et collaboratif Framapad est une implémentation du logiciel libre Etherpad. Ce  service est mis à la disposition de tous et cela démontre en même temps que ce service peut être proposé de manière décentralisée (même si nous sommes peu nombreux à proposer une instance publique d’Etherpad, des milliers d’instances privées existent).

Au mois de juin dernier, Framasoft a lancé une campagne de financement participatif visant à contribuer activement à l’amélioration d’Etherpad pour y ajouter la gestion des comptes utilisateurs, des groupes et des pads privés. Il n’aura fallu que trois semaines pour que l’objectif soit atteint. Nous vous en remercions une fois encore.

Le but de ce projet  est de permettre aux utilisateurs d’Etherpad, et donc de Framapad, de créer un compte en leur nom, d’y associer des groupes et, pour chaque groupe, des pads. Ces pads pourront être publics, privés sur invitation ou encore d’accès restreints par l’usage d’un mot de passe. Le tout doit prendre la forme d’un plugin pour Etherpad, publié sous licence libre et s’installant de la même manière que tous les autres plugins du logiciel.

Il était prévu que la réalisation débute à la rentrée et que le plugin soit livré en fin d’année. La feuille de route a quelque peu glissé du fait de la surcharge temporaire du prestataire sélectionné. Le coup d’envoi est néanmoins lancé cette semaine et l’ensemble du développement se déroulera sur notre Gitlab via le projet ep_mypads https://git.framasoft.org/framasoft/ep_mypads .

Le plugin est attendu pour la fin du mois de février 2015. Il devrait comporter de petits bonus par rapport au cahier des charges initial.
Les premières semaines seront consacrées à l’écriture du code serveur, à sa documentation et à ses tests. Il faudra attendre début 2015 avec la création de l’interface graphique afin que MyPads puisse commencer à être testé.

Pour rappel, le cahier des charges originel est disponible sur ce pad : http://lite4.framapad.org/p/LEpEOUoQb3/timeslider#24.

Un point sur l’avancement du développement sera réalisé environ toutes les deux semaines.

——-

MyPads : development launched

A stage news will be made around every two weeks.

Nous avons reçu il y a quelque jours un appel téléphonique. Jusque là, rien d’anormal. Ce qui l’était plus, c’était qu’il émanait d’un groupe d’agricultrices. Leur demande ? Faire réaliser un logiciel qui leur permettrait de suivre un programme expérimental d’utilisation de produits en médecines alternatives (homéopathie/aromathérapie notamment). Pour le suivi de l’expérimentation, elles souhaiteraient utiliser un logiciel leur permettant de saisir des données sur leurs smartphones, ainsi qu’obtenir différents types de bilans ou statistiques.

Ce type de développement (quand bien même rémunéré, ce qui serait le cas ici) ne rentre pas vraiment dans le cadre des missions de Framasoft. Cependant, en répondant à leurs questions, il nous est apparu assez clairement que nous avions des valeurs communes (partage du savoir, non appropriation du bien commun, volonté d’agir “ensemble”, etc.).

Nous avions déjà, il y a quelques mois, mis en avant un logiciel libre dédié à l’agriculture : Agritux (on me souffle à l’oreille que si vous êtes intéressés par le sujet, vous devriez aussi jeter un œil à Ekylibre). Il est donc plutôt passionnant de voir des liens se tisser entre ces deux mondes en théorie relativement éloignés.

Pour en savoir plus, nous avons demandé à ces agricultrices de répondre à quelques questions.

Et si vous souhaitez développer une application libre (avec une interface pour smartphone) répondant à leur problématique, n’hésitez pas à les contacter.

Bonjour, pouvez-vous vous présenter, ainsi que votre projet ?

Nous sommes 8 agricultrices regroupées en collectif GEDA (Groupe d’Études et de Développement Agricole) au niveau d’un canton au Nord de Rennes.

Nous échangeons régulièrement sur des thèmes variés techniques ou pas, professionnels ou pas suivant nos propres choix. Nous cherchons également à faire mieux connaitre notre métier en intervenant dans les écoles primaires et maternelles. Nous collaborons également avec les élus de notre territoire. La réflexion collective est en effet un moyen de nous sentir rassurées dans notre métier. Elle nous donne la force d’oser dialoguer avec l’ensemble des acteurs non agricoles de notre territoire et de partager nos travaux au-delà des frontières de nos fermes.

Nous avons décidé en 2012 d’en connaitre davantage sur les médecines alternatives en élevage bovin pour maîtriser la santé de nos troupeaux d’une manière plus respectueuse de l’environnement et de la santé humaine. Très vite nous avons donc commencé à tester l’homéopathie et à observer des résultats positifs sur nos troupeaux. Et depuis notre soif de savoirs et d’expériences s’est accrue : l’aromathérapie, les méthodes d’observation du troupeau (Obsalim®), la phytothérapie, … sont aujourd’hui autant de voies que nous souhaitons découvrir et tester sur nos exploitations pour adapter au mieux notre stratégie d’exploitation. En parallèle notre envie de communiquer pour revaloriser notre beau métier s’est développé. De là est né notre projet sur trois ans qui nous permettra de :

• Assurer le bien-être et améliorer la santé de nos vaches ;
• Acquérir une plus grande autonomie décisionnelle ;
• Limiter l’impact de nos élevages sur l’environnement ;
• Valoriser notre beau métier d’éleveur auprès des acteurs de notre territoire.

Pour atteindre ces objectifs, nous avons notamment décidé de travailler à la conception d’un outil de suivi de notre expérimentation sur Smartphone. C’est dans ce cadre que notre collectif vous a contacté.

Pour cela, vous souhaitez éventuellement faire réaliser un projet logiciel. Pouvez-vous nous en dire plus ?

Pour bien appréhender les problèmes de santé des animaux, une observation minutieuse des bovins est indispensable au quotidien et à tout moment. Un suivi également des traitements alternatifs appliqués (homéopathie, aromathérapie,..) est indispensable aussi pour ensuite pouvoir identifier les facteurs d’échecs ou de réussites de nos expérimentations. Un support pour enregistrer ces informations est donc nécessaire et doit correspondre à nos conditions de travail : plus on a d’animaux, plus le nombre de remarques et d’actions effectuées est important. Comment tout noter en permanence de façon confortable et surtout efficace ?

De nombreux agriculteurs sont aujourd’hui équipés de smartphones. Celui-ci permettrait un enregistrement rapide et confortable quel que soit le lieu d’observation : de la salle de traite aux pâturages. Toutes les informations concernant chaque animal dès sa naissance doivent pouvoir être enregistrées dans cette application: les événements importants et marquants, ses particularités (caractère, physique,…), son comportement, avec les dates, etc… Pour être efficace dans la pratique des médecines alternatives, le moindre événement dans la vie de l’animal peut être important et le choix du traitement à appliquer tout comme sa réussite en dépendent. Ce logiciel nous permettra également de capitaliser plus facilement puis d’analyser collectivement nos résultats d’expérimentations de soins alternatifs aux traitements conventionnels.

Le logiciel libre semble porter certaines valeurs communes avec votre projet, comme par exemple la mutualisation, la coopération, la volonté de partager le savoir et les connaissances, etc. Pourtant, le monde du logiciel et celui de l’agriculture semblent bien éloignés. Aviez-vous entendu parler de logiciel libre ou de culture libre avant d’avoir ce projet logiciel ?

Bien sûr nous en avions entendu parler mais uniquement dans le cadre de la sphère privée avec les logiciels libres de traitement de texte par exemple.

Avant l’émergence de notre projet collectif, nous n’avions pas vraiment fait le lien entre notre métier et le monde de la culture libre, mais dès que l’idée d’un logiciel a émergé nous avons tout de suite pensé à une application gratuite et diffusable à tous. Pourquoi ? Tout simplement parce que notre démarche collective qui vise l’échange et le partage, la reconquête notre autonomie, notre liberté de choisir et celle du mouvement des logiciels libres sont parallèles et cohérentes. Dans les 2 cas il s’agit de démarche de partage et de liberté.

Pour aller plus loin dans le parallèle, grâce à ce projet et en partenariat avec le lycée agricole de notre secteur, nous voulons également transmettre nos expériences au plus grand nombre agriculteurs et aux générations futures d’agriculteurs. Les communautés qui prônent le logiciel libre sont également dans cette démarche puisque les outils développés sont transmissibles, modifiables et adaptables librement.

Et nous ne nous étendrons pas sur la similitude entre les semences agricoles qui pourraient être comparées à des logiciels. Si aujourd’hui nous avons le droit de pouvoir ressemer l’année suivante notre propre semence récoltée (cela est de plus en plus remis en question), nous ne pouvons échanger ou vendre des semences non certifiées. Pourquoi devoir en permanence dépendre des grosses firmes multinationales “de semences” ? Le côté économique est un élément important car une semence “certifiée” a un coût beaucoup plus élevé qu’une semence récoltée sur l’exploitation. Et on ne parle que de blé et d’orge car le maïs hybride ne se développera pas ou de manière dégénérée l’année suivante si on tente de le semer. Sur ce point encore nos idées se rejoignent : à quand la semence libre ? 🙂

Pour les non-initiés, l’informatique (et internet) semble jouer un rôle croissant dans le quotidien d’une exploitation agricole. Vous confirmez ?

Effectivement, sans internet, l’exploitation fonctionne au ralenti…L’accès à l’information se fait de plus en plus via les sites agricoles spécialisés : marchés, réglementation, résultats d’analyses (réaction plus rapide si résultats connus précocement).

La gestion financière de l’exploitation se fait au jour le jour et est facilitée par la consultation régulière des comptes bancaires. La gestion administrative, de plus en plus exigeante et importante est facilitée par les messageries électroniques qui permettent de communiquer plus rapidement et efficacement avec nos différents partenaires, le téléchargement de formulaires.

La gestion des cultures et de ses différents enregistrements se fait fréquemment sur des logiciels spécialisés qui permettent de répondre aux exigences réglementaires (intrants…).

La gestion des troupeaux peut être gérée informatiquement via différents supports : quantités de lait produites, gestion de la reproduction via des aides à la détection de chaleurs, de vêlage, gestion de l’alimentation (en production porcine notamment). L’identification animale se fait via des serveurs spécialisées qui permettent l’accès aux bases de données animales.

Merci ! 🙂 Un petit mot pour la fin ?

Nous aurons bien sûr besoin d’un développeur pour notre logiciel :=), donc si des personnes sont intéressées, contactez-nous par email : frgeda.bretagne (chez) gmail (point) com

Pour financer notre projet sur trois ans, nous avons répondu à l’appel à projet de la Région Bretagne sur Agriculture Écologiquement performante, alors croisez les doigts pour nous 😉

Et surtout merci à vous de nous guider pour nos premiers pas dans ce monde du logiciel libre!!!!