Si l'open source et le logiciel libre gagnent du terrain dans notre quotidien, nous ne sommes en général que des bénéficiaires de ces communs. Habitués à une position de consommateur dans un écosystème numérique ouvert, pourtant pensé avec une certaine symétrie. Participer est donc possible, même si vous n'êtes pas développeur.
Contribuer. Dans son bilan de la seconde année du projet Contributopia, Framasoft définissait cette action comme le fait d'« œuvrer ensemble à concrétiser des idées communes ». On pense souvent au monde du logiciel libre et au fait que cela ne concerne que les développeurs et la participation au code source. Ce n'est pas le cas.
Internet n'est pas qu'un grand supermarché
Les premiers sites web (dont INpact Hardware, devenu Next INpact) puis les blogs sont nés de cette volonté de partage du savoir individuel. Avant que chacun ne soit plus qu'un avatar sur les réseaux sociaux, potentiel influenceur commentant le monde en 280 caractères dans un immense brouhaha, l'Internet symétrique devait nous permettre de ne pas être que consommateur, mais aussi producteur de connaissances décentralisées.
Cela ne s'est pas (tout à fait) passé comme prévu. Et même lorsque l'on parle de logiciel, ce n'est jamais que ça. C'est en général un projet, parfois disponible dans différentes langues, nécessitant donc des traductions. De la documentation, pour expliquer comment utiliser l'outil ou participer. Mais aussi une interface graphique, une expérience utilisateur, des logos et visuels. Quand le succès est au rendez-vous, une communauté, avec laquelle il faut interagir. Un budget, à boucler. Bref, un ensemble de compétences nécessaires, à faire travailler ensemble.
Et ce n'est pas facile. Le débat, aussi récurrent que douloureux, sur la participation des graphistes au monde de l'open source et la recherche d'un juste milieu entre sécurité et simplicité des interfaces en est la preuve.
Mais chacun peut participer à sa manière.
Notre dossier sur la maîtrise de Git et de ses plateformes :
- Open source, libre et communs : contribuer ne nécessite pas de développer
- Apprenez à utiliser Git : les bases pour l'évolution d'un document
- Git remote : comment héberger vos documents et codes source sur un serveur
- Git : comment travailler avec plusieurs remotes
- Fork et pull request : la participation open source par l'exemple
- GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser
Le cas PeerTube (entre autres)
Prenons l'exemple d'un projet open source français à succès : PeerTube. Cette plateforme vidéo décentralisée, basée sur le standard ActivityPub, a été lancée par Framasoft il y a quelques années. Chocobozzz, son développeur principal, a été recruté par l'association qui se finance principalement par les dons.
La première manière d'aider cette alternative à YouTube est donc le soutien financier. Une collecte « perlée » est d'ailleurs en cours autour des fonctionnalités de la v3. 34 000 euros ont déjà été récoltés sur les 60 000 demandés. Mais c'est loin d'être la seule manière d'apporter son aide au projet.
Sur son dépôt GitHub, il détaille comment (en anglais, pour ne pas se limiter au public francophone). Ce sont des actions simples, comme nous le faisons sur nos propres projets : participer à la communauté, dire quelles fonctionnalités vous manquent, celles que vous aimeriez voir évoluer, déclarer des bugs, etc.
Comme tout bon gestionnaire de logiciel open source, GitHub propose un outil pour effectuer des remontées. Il suffit d'avoir un compte pour participer. Il est utilisable en ligne ou via les différentes applications proposées par le service. L'équipe de PeerTube est également disponible via IRC, Matrix ou le forum dédié au projet.
La traduction passe par le compte Weblate de Framasoft où l'on peut voir les langues concernées et ce qu'il reste à traduire. Même en français, tout n'est pas finalisé à 100 % ! Là aussi une documentation est disponible pour vous expliquer quoi faire et comment. Si vous avez un peu de connaissances en développement, vous pouvez également participer à la documentation, à l'amélioration du site ou la création de thèmes et plugins.
Parfois, il suffit d'en parler à ses proches pour initier un effet boule de neige. On retrouve des mécaniques similaires pour d'autres projets libres, comme le gestionnaire de finances Kresus, la plateforme d'auto-hébergement Yunohost. Même les Freebox (reposant en partie sur du logiciel libre) ont leur propre bug tracker permettant aux clients d'indiquer les problèmes qu'ils rencontrent et suivre leur résolution.
Les communs et le libre au-delà du code (et du numérique)
Mais comme le monde associatif (auquel il est souvent associé), le libre est divers et ne s'arrête pas aux logiciels. C'est pour cela que l'on parle plutôt de communs. Et là aussi il existe bien des projets à soutenir.
On pense bien entendu à l'un des plus visibles : Wikipédia. Si chacun y pioche régulièrement des connaissances, l'encyclopédie collaborative est le fruit du travail de milliers de contributeurs. 5 700 sur le dernier mois, pour 932 000 modifications sur 372 000 pages selon les statistiques disponibles à l'heure où nous écrivons ces lignes. Vous avez envie de participer et de faire partager vous aussi votre savoir ? Il y a un guide du débutant pour cela.
Tout aussi proche de notre quotidien, Open Food Facts, base de données collaborative sur les produits alimentaires avec plusieurs dérivés : Open Beauty Facts (produits de beauté) et Pet Food Facts (aliments pour animaux). Chacun peut y ajouter des références depuis son smartphone ou remplir les informations de ceux en ligne. Sur la page consacrée aux contributions, l'équipe dit aussi rechercher de l'aide en développement, gestion de projet, de communautés ou en communication.
Vous pouvez également faire de la cartographie via OpenStreetMap, du fact checking avec Captain Fact et pourquoi pas votre petit bout d'Internet, à travers les FAI associatifs locaux comme ceux de la fédération FDN. Car après tout, le numérique n'est qu'une des manières d'apporter sa pierre, bien d'autres moyens existent déjà IRL.
Commentaires (55)
#1
Concernant Open Street Map, je peux recommander StreetComplete , une chouette app qui aide à ajouter pas mal d’infos sur les rues et les magasins autour de soi.
#1.1
Personnellement, j’utilise l’application Android Vespucci. L’interface est plutôt simple à utiliser mais les contributions sont difficiles. Elle présente les champs à la manière d’une liste clé/valeur et ce n’est pas toujours facile de savoir quoi renseigner dans chaque champ. Mais les contributions arrivent assez rapidement sur OpenStreetMap.
#1.2
Dommage de ne mettre qu’un lien vers le store privateur de Google, quand d’autres stores, libres et open sources, la proposent aussi.
L’appli sur F-Droid
Le dépôt git (qui contient l’apk)
#1.3
Merci aussi pour cette découverte :)
#2
Merci pour cet article !
Nous tenons juste à préciser que depuis le lancement de Contributopia (oct. 2017) nous avons réalisé à quel point nous ne sommes pas doué·es pour accueillir les contributions, et donc ça fait trois ans qu’on se soigne, qu’on aprend, mais c’est loin d’être parfait : nous sommes loin d’être exemplaires.
Concernant PeerTube, ayant une micro-équipe qui bosse dessus et qui -en ce moment- essaye prioritairement d’avancer sur les fonctionnalités de la v3, il se peut qu’on ne puisse pas accueillir les nouvelles contributions tout de suite, ni avec toute l’énergie qu’elles mériteraient…
Bref : on ne fait que de notre mieux, et merci d’être patient·es avec nous ;)
(ces précisions mises à part : il est top cet article, merci encore ! – Pouhiou, pour Frama)
#3
Bravo pour cet article. Petite interrogation/suggestion : pourquoi ne pas le mettre en accès libre ?
Je doute que cet article suffise “par lui-même” (genre premier article de NXI que de nouveaux lisent) à générer des conversions vers des abonnements payants, en revanche il permet de bien présenter la richesse et la diversité de l’esprit “open source”.
Perso j’aimerais donc bien le diffuser “librement” à mon entourage.
#3.1
Le bouton de partage est là pour ça. Pour le reste, il sera accessibles à tous en accès libre à terme comme tous nos articles ;)
#4
Sympa l’article, je connaissais pas CaptainFact, je crois que je vais m’y inscrire sous peu.
#5
D’autres façons de contribuer aux logiciels : rapporter des bugs, c’est enquiquinant mais utile, rédiger des tutoriels, traduire la documentation, créer des modèles (templates, layout quel que soit le nom).
#5.1
C’est un peu ce que dit l’article en fait
#RTFN
#5.2
C’étaient des précisions et bien au-delà des exemples cités en fait.
L’intérêt des tutoriels, par exemple, c’est qu’on n’est pas obligé de les mettre dans des endroits aussi épouvantables et peu accueillants que les github. L’autre intérêt c’est que, plus il y a en a mieux c’est. Ils se complètent les uns les autres, en outre, la diversité, des styles de rédactions, des accès fait que, fatalement, quelqu’un qui cherche une info va tomber à un moment sur le tutoriel qui lui fait comprendre ce qu’il ne comprenait pas.
#6
L’envie de contribuer n’est pas inexistante mais le problème est souvent qu’en dehors de rares initiatives comme l’application StreetComplete, c’est souvent assez inhospitalier pour les néophytes et les non-développeurs.
Récemment, j’ai justement voulu rapporter un bug sur le bugtracker de PHP et le ticket a été fermé sans explication sur l’origine de “Pourquoi ça se déclare comme comportement”. Et quand on voit les discussions qu’il peut y avoir sur chaque ticket, ça donne le sentiment qu’à moins de ne pas avoir la main dans le code, on est juste pas légitime à exprimer des avis.
Donc à défaut, je me contente de petits contributions sur Wikipédia quand je vois des petites erreurs dans les paragraphes.
#6.1
C’est totalement vrai, être développeur open-source demande aussi d’avoir des compétences de dialogue et d’écoute que malheureusement tout le monde n’a pas (ce qui n’en fait pas de mauvais codeurs) :-( Il faut voir qu’en faisant de l’open-source, on se voit cumuler plusieurs métiers genre développeur - support technique - relation client - marketing , et la plupart du temps il n’y a pas les ressources pour mettre 1 personne sur chaque rôle.
#7
“open source et le logiciel libre”
Il y a une différence ? Selon le site de l’Open Source initiative il n’y en a pas vraiment : https://opensource.org/osd
Et sinon a quand un dépot Git avec les sources de NextInpact ?
#7.1
N’ouvre pas la porte des enfers
#7.2
Trop tard.
Pour la faire courte Mimoza, la qualification “d’open source” recouvre une grande variété de situations. Le seul point commun est qu’en tant qu’utilisateur tu as la garantie de pouvoir disposer du source du code. Et le plus souvent de le modifier comme tu l’entends, mais ça dépend. En particulier, tu peux n’avoir le droit que d’étudier le code et le modifier “pour toi” mais sans autorisation de le réexploiter.
C’est pour ça que l’Open Source Initiative déroule (si je me souviens bien ça fait tellement longtemps) une dizaine de critères différents.
Le logiciel libre est plus protecteur… Du savoir universel, mais plus restrictif d’une certaine manière pour ses utilisateurs.
Contrairement à l’open source dont une des implémentations les plus connues est “fais ce que tu veux de mon code, y compris l’exploiter commercialement, oublie juste pas de me citer” (typiquement MIT) le logiciel libre utilise le droit pour explicitement de donner tous les droits sur le code que tu récupères MAIS t’oblige également, si tu publies du code dérivé, à le faire sous les mêmes conditions.
(Je grossis le trait, il y a plus de nuances, mais en gros c’est ça).
Imaginons que je trouve un super outil de génération de personnages, mais je veux l’enrichir pour y ajouter par exemple de nouvelles manières de générer.
Sous une licence open source vraiment permissive (genre MIT), je peux très bien prendre le code de l’outil, l’enrichir, le publier et l’exploiter sous une licence propriétaire qui empêche quiconque d’étudier/réutiliser mon code (mon code). Ma seule obligation concrètement est de signaler dans ma licence que j’utilise le code de XXX sous licence MIT. Je n’ai même pas l’obligation de fournir mon code source.
En bref, on peut “fermer” un logiciel open source.
Sous une licence de logiciel libre, typiquement la GPL, dès lors que je distribue mon logiciel (payant ou gratuit peu importe) je serais obligé de le faire sous la même licence (donc j’autorise quiconque aux mêmes droits -et mêmes obligations !- sur ma version modifiée que moi j’ai eue initialement). En particulier je suis obligé de mettre le code source à disposition.
En bref, un logiciel “libre” ne peut que rester ouvert (Il faut le comprendre comme “libre de tout asservissement par une entité spécifique”).
Voilà la définition historique du logiciel libre, telle qu’elle était défendue au départ par la FSF.
Seul le logiciel libre peut réellement garantir l’accès/partage perpétuel à la connaissance, en tout cas d’un point de vue légal. Après plus personne ne conserve une mise à disposition, ma foi on n’y peut rien. Idem si au final les gens qui auraient été intéressés par un outil pour l’étendre et l’exploiter sont repoussés par ces obligations, et qu’au final le logiciel meurt faute d’avoir des gens pour le maintenir. C’est la limite de l’exercice : pour certains outils généralistes ce n’est pas compliqué de fédérer suffisamment de gens, pour d’autres ça peut être infaisable (tout particulièrement les outils “pointus” dans des domaines métier précis).
Car bien que théoriquement on puisse exploiter commercialement du logiciel libre (ça fait partie des droits octroyés), dans la pratique c’est extrêmement compliqué (sauf à faire du “faux logiciel libre” mais c’est un sujet à part entière ^^, ou à avoir un marché de niche / un outil incontournable). C’est typiquement pour ça que le premier modèle économique des boîtes qui arrivent à en vivre c’est un modèle de support ou fonctionnalités premium.
Tandis que l’open source permet de plus facilement trouver un équilibre entre les intérêts de l’éditeur (conserver la “maîtrise” du produit qui le fait vivre) et des utilisateurs (pouvoir disposer du code par exemple en cas de faillite de l’éditeur, pour pas être complètement coincé avec des données non migrables).
C’est entre autres pour ça que depuis quelques années la FSF a assoupli sa doctrine, notamment sur la manière de déterminer à partir de quand tu dérives un logiciel libre (et donc tombe sous le coup de sa licence).
Dans l’idée que si elle était trop restrictive aucun éditeur de grande ampleur n’oserait plus réutiliser du code (et donc potentiellement y recontribuer).
L’évolution de l’écosystème tendant à montrer que c’était une stratégie judicieuse. :)
L’évolution vient aussi de ce que certaines sociétés de service spécialisées ont tordu le vocabulaire “logiciel libre” jusqu’à le faire confondre avec “l’open source” dans l’esprit de la plupart des gens (dont les décideurs). Et ça c’est sale, parce que ça dessert tout le monde (sauf elles, du moins à court terme). Mais on n’y peut pas grand chose.
Again, je te le fais en mode résumé bourrin. ^^
#8
Il me paraît pas inutile de noter qu’il y à d’autre projets qui gravite autour de wikimédia que Wikipédia mais qui mérite aussi de s’y pencher:
Et mon petit préféré (bien qu’assez peu actif en comparaison):
Les autres me paraissent plus anecdotique à par wikidata mais c’est un truc un peu particulier.
#9
Une autre manière de contribuer au libre qui n’a pas été mentionné et de faire ce qui est fait dans l’article : parler du logiciel ou du site. Ca permet de le faire découvrir et donc d’agrandir la base des utilisateurs potentiels qui eux pourront peut-être contribuer d’une des manières présentées dans cet article.
Je connaissais pas non plus Captain Fact donc faire de la pub est donc aussi un moyen efficace de « contribuer » :)
#9.1
Oui j’y avais pensé vu que pas mal de projets le mentionne, puis j’ai zappé à la relecture finale
Je vais ajouter merci 
#10
Pour le coup, je contribue régulièrement à OSM (OpenStreetMap), à titre perso ou pro, et je pense que c’est l’une des contributions les plus accessibles (avec Wikipédia). Il y a un petit tuto, les données se superposent des images satellite, c’est réel et concret, ça parle à pas mal de monde. Après, bien connaitre les clés, sous-clés voir valeurs (types et attributs) de chaque type d’objet, ça demande plus d’investissement, mais ça n’empêche pas de commencer à améliorer les données existantes. Surtout que je trouve sur interface web très intuitive pour les non-initiés.
La plupart des contributeurs à OSM sont des locaux qui connaissent le terrain, et ça c’est un gros plus pour la qualité des données. Si tous les gens qui lisent ce commentaire vont fureter autour de chez eux en mode édition (il faut un compte, mais c’est peanuts), je suis sûr qu’il y aura des améliorations à apporter ;)
#11
Je ne connaissais pas, je l’ai installé et ai déjà soumis des corrections. ^^
Merci ! :)
#12
Et les sous. Donnez des sous à ces projets.
Beaucoup sont financés sur les deniers personnels des mainteneurs, et même si recevoir quelques modestes donations (ça permet très rarement aux devs de vivre) ne va pas suffire à maintenir la motivation, leur absence, elle, peut porter le coup fatal, surtout quand ton projet a 10 ans d’âge et est largement utilisé. Les tweets c’est bien, les articles aussi, il en faut absolument, mais il ne faut surtout pas se limiter à ce type de soutient gratuit. Le logiciel gratuit est gratuit parce que qqun paie, trop souvent avec son temps libre à coder le soir et les weekends, ou pendant une période de chômage.
#13
Sujet connexe, c’est Amnesty International qui faisait le constat que depuis l’avènement de Facebook, ils n’ont jamais eu autant de soutiens moraux, de +1 et de Like, les gens sont très actifs sur les réseaux sociaux, mais hélas, les donations restent basses, et ce sont toujours les mêmes qui donnent : les plus pauvres. Les gens aisés (sans généraliser non plus hein) préfèrent “offrir” un like, mais surtout pas des €.
#14
On peut également citer Common Voice (la contribution y est encore plus simple et rapide que sur Wikipédia ou OpenStreetMap), dont l’objectif est de concevoir un système de reconnaissance vocale libre et respectueux de la vie privée, histoire de ne pas avoir à dépendre exclusivement des GAFAM (Alexa, Cortana, Google Assistant, Siri…)
Pour cela, il suffit de se rendre sur le site et de choisir l’une des deux activités. Soit donner un peu de sa voix en lisant de courtes phrases, qui aideront à entraîner le moteur de reconnaissance vocale, soit écouter les enregistrements d’autres utilisateurs pour vérifier que les enregistrements correspondent bien au texte.
C’est tout bête, mais pour obtenir un système réellement efficace, il faudrait dans les 10 000 heures d’enregistrements, avec la plus grande diversité de contributeurs possible. Actuellement, pour le français, avec 12 391 contributeurs et seulement 576 heures validées, on en est encore loin.
#14.1
Je viens d’essayer, effectivement c’est très accessible !
Par contre sous Chrome, j’avais une voix déformée toute aiguë alors que sous Firefox, aucun problème.
#14.2
Ce genre de système marche pas en open source ça demande une quantité de donnés faramineuse. La db de cortana pèse 15To 😅 et elle est pas fini.
Sur des trucs plus léger l’open source marche bien genre les traducteurs brail. Microsoft utilise deux libs open source pour ça dans Windows.
#14.3
Il y a plusieurs paliers. On ne passe pas directement d’une reconnaissance médiocre, inutilisable, à une reconnaissance absolument parfaite. Et il existe des cas d’usage pour les premiers paliers.
Sur le site de Common Voice, ils donnent ces estimations :
Les francophones sont actuellement dans le deuxième pallier, tandis que les anglophones, avec 1500 heures validées, s’approchent du degré de reconnaissance d’un être humain.
Après, c’est sûr, ça n’avance pas forcément aussi vite qu’on le voudrait, et certains profils de contributeurs sont malheureusement très peu présents : africains, québécois… ou tout simplement les femmes, qui ne sont que 11% déclarées dans le dernier jeu de données.
Peu être qu’un jour il y aura un article dans la presse ou un reportage télé qui fera mouche. Peut être qu’une entreprise (Orange aurait très bien pu demander à ses 150 000 employés de contribuer pour pouvoir l’utiliser dans son enceinte Djingo), des associations locales ou l’État (bon, ok, là je rêve un peu) arriveront à motiver les gens ou les paieront pour le faire.
En attendant, avec seulement 1226 contributeurs (dix fois mois que les francophones), le Kabyle a déjà obtenu quasiment autant d’heures validées que nous (506h), et avec seulement 405 contributeurs (trente fois moins que nous), le Kinyarwanda (langue bantoue dont je n’avais jamais entendu parler) a déjà obtenu 405h validées.
C’est aussi ça qui est bien avec le libre. Il suffit de gens motivés pour pouvoir créer un modèle de reconnaissance pour une langue qui sera peut être ignorée par les grandes entreprises, puisque considérée comme peu rentable de par leur faible nombre de locuteurs.
#15
Sans viser Framasoft en particulier, l’expérience personnelle en matière de remontés de bug, restent souvent sans réponses et surtout sans correctifs.
On ne sait généralement même pas si le rapport de bug est lu par quelqu’un où s’il est directement envoyé dans /dev/null.
Mozilla, Gnome, Vivaldi, PHP, Paypal, Nebula… j’ai remonté des problèmes en tout genre à ces projets là, après m’être inscrit sur leur plateforme ou avoir passé 15 heures à trouver un lien de contact, sans jamais avoir eu un seul retour.
Même pas un “not a bug”, “won’t fix”, “can’t replicate” ou autre qui montrerait que le message ait bien été lu par quelqu’un quelque part.
Sans compter les bugs qu’on découvre et pour lesquels on s’aperçoit qu’ils ont déjà un ticket ouvert depuis 15 ans et confirmé par 600 personnes sans qu’il n’y soit donné la moindre suite par d’éditeur.
Je conçoit que ces projets en particulier ne sont pas un simple script avec comme seuls utilisateurs trois pécores dans leur garages, mais dans ces conditions, c’est peu encourageant pour contribuer de cette façon. Du coup bah on fait avec et on laisse le bug où il est en espérant qu’une mise à jour du code le fasse disparaître avant la fin du siècle.
C’est dommage en fait, car y a certains services, même payants, qu’on aimerait utiliser mais vu qu’ils sont montés par des startup désordonnés, c’est globalement de la merde sur le plan technique (genre un site web dont la page pèse 40 Mo et dont le script boucle et télécharge 20 fois le même fichier CSS de 2 Mo).
C’est d’autant plus frustrant quand on possède les capacités et les connaissances pour corriger ça en 5 minutes, qu’on leur donne la solution, parfois avec le code, mais que le problème est toujours là après 6 mois (alors que le principal atout vanté aux web-apps est “une mise à jour rapide et un déploiement en temps réel”).
Bref, contribuer c’est cool, mais savoir recevoir les contribution ce n’est pas juste un problème mental (certains dév refusent d’accepter qu’ils puissent avoir fait une erreur) mais aussi technique (mise en place d’un lien de contact, d’une page simple de remonté de bugs) et de moyens (prendre un dév pour tester et corriger le code).
#16
Je ne pense pas qu’il faille inputer ça à l’ego des développeurs (ça doit arriver mais assez rarement, enfin j’espère) à mon avis c’est encore et toujours une question de moyens, trop de volume de travail par rapport aux ressources, alors forcément les rapports de bugs s’empilent, et les moins impactant passent à la trappe. 😔
#17
Même avec un profil plus technique tu as le pb, j’ai publié plusieurs patches pour Gentoo, je suis informaticien (architecte technique SAP donc rien à voir avec le libre) : Tu ouvres un ticket explique le bug et fourni le patch corrigeant le code source : 1 fois sur 2 tu te fais allumer parce que c’est pas la bonne façon de faire ! (pas le bon outil, ou pas respecter le process qui est décrit quelque part dans un didacticiel mal écrit qui prend 3 semaines à suivre avant de débuter)
Genre moi perso je ne comprends rien à l’usine à gaz qu’est git, ça ne m’intéresse pas d’apprendre ce qu’est une pull request, pourtant je sais corriger du python, tout langage scripté voir même du C. Je peux contribuer et corriger de nombreux bugs, mais comme je ne rentre pas dans le moule du projet mes contributions sont ignorées. Souvent les bugs restent corrigés dans mon coin, la communauté open source les ignorant…
Ma plus grosse contribution est sur ffado (pilote linux pour les cartes son et platine firewire) j’ai tout migré de python 2.7 à 3 et de QT4 à QT5, mis à jour tous les composants qui étaient obsolètes, corrigé des tonnes de warning à la compilation, refais l’interface du mixer. À défaut d’accès SVN, j’ai envoyé le patch (~1 / 2mo de code sources quand même) au dev était content, a tout analyser et décortiquer, il a fallu que je justifie chaque changement par mail (genre expliquer que QT4 ou Python 2.7 était désuet), il n’a pas tout repris, donc il reste tous les warning C++ sur des pointeurs inadaptés, et l’interface graphique est restée avec ces soucis d’ergonomie…
Donc pour résumer pour développer dans le libre il faut soit être très motivé et prêt à justifier des heures et des heures pour que quelqu’un de l’autre côté décide ou non d’intégrer ton code, soit se spécialiser sur un projet pour maitriser tout le processus, et pouvoir devenir un sachant aigri qui jugera les contributions des nouveaux venus.
Bref pas facile, les mots “contribution” ou “libre” sont un peu galvauder pour un débutant : tout le monde n’a pas accès en écriture au projet, et faire publier une correction relève du parcours du combattant.
#17.1
Note que c’est aussi pour ça que Git (enfin les outils de gestion de versions en général) et les pull requests existent, pour faciliter les échanges entre les développeurs, la communauté, etc. La justification se fait au commit, pour éviter justement d’avoir 400 modifications dont tu ne comprends pas forcément le sens avec un gros patch unique qui vient d’un tiers.
Alors oui certains projets sont plus accueillants que d’autres, mais la formalité dans les participations est aussi un mal nécessaire. Contribuer c’est aussi le comprendre. Sinon ça revient à dire “moi je veux pouvoir venir en AG, refaire les statuts, dire ce qu’il faut faire et s’ils ne suivent pas ma proposition c’est qu’ils n’ont rien compris”. On avance rarement de la sorte
#17.2
Sinon oui tu as globalement raison. C’est un peu un cercle vicieux, à fortiori pour les logiciels dont les communautés sont assez “techniques”.
Beaucoup ont un à priori de “si tu me contactes t’es déjà au parfum” et ne tentent même pas de faire preuve d’ouverture d’esprit ou pédagogie.
Ce qui n’aide pas à avoir de nouvelles contributions, donc laisse les développeurs seuls sur le pont, ce qui leur pourrit encore plus le moral. XD
Il est dommage que cette expérience ait eu un relant aigre-doux pour toi.
) un comportement de tête à claque.
Je ne préjuge rien concernant cette expérience ci, je veux bien croire que ton interlocuteur a eu un peu (beaucoup ?
Cela dit, il faut aussi comprendre que suivre les processus est une condition non suffisante pour qu’un bug soit corrigé (confer le ressenti du Hollandais ;)), mais complètement nécessaire.
Je pense que nous sommes tous d’accord ici pour dire qu’il n’y a rien de plus frustrant que de perdre du temps en communication / gestion de projet qui pourrait être consacré à du technique.
D’ailleurs c’est une des causes du manque, apparent ou réel, de réactivité communautaire face aux utilisateurs : organiser des process solides, savoir comment remonter et structurer de l’information, c’est tout un métier à part entière. De même que la gestion de projet à proprement parler.
(L’autre grande raison étant tout bêtement, ou tristement, que tu remontes un bug sur une portion logicielle pour laquelle il n’y a plus de mainteneur, ou en tout cas de “sachant”, ou juste trop petite communauté pour la masse de problèmes à traiter).
Sinon, par rapport à Git, je comprends tout à fait que ça te donne l’impression d’être une usine à gaz (notamment selon la manière dont on projet organise son code avec), mais en soi ce n’en est pas une.
C’est un outil surpuissant de gestion du code, même s’il ne fait pas de miracles non plus (si A et B modifient les mêmes portions de code en réécrivant tout, bah à eux de gérer leur conflit
).
La pull request, c’est une notion au vocabulaire contre-intuitif mais extrêmement précieuse pour organiser des contributions communautaires comme le souligne David.
Comme quand tu “clones” tu récupères tout le code, et que quand tu te places sur une “branche” pré-existante en local elle est associée à la branche de même nom sur le dépôt distant…
Par défaut sur un dépôt lambad tu pourrais directement propager tes modifs sur le dépôt distant (et donc répercuter à tout le monde).
Tu imagines bien les soucis que ça peut causer sur un projet populaire si tu propages du code foireux.
-> Les branches “principales” (voire toutes ^^) sont protégées, seules quelques personnes responsables peuvent directement les “faire avancer”, généralement les auteurs historiques.
Toute autre personne ne peut que “soumettre (request) une demande de récupération (pull) de ses modifs” à ces responsables.
Ça permet (normalement) d’avoir une revue de code avant intégration qui permet d’assurer que le projet reste cohérent en termes de normes d’écriture et d’architecure au fil des évolutions. :)
#18
Et encore plus simple comme contribution, remerciez les développeurs.
Quand t’as un truc tenu par une personne voir 2 ou 3, ils sont content d’avoir des retours d’utilisateurs
#18.1
Tu as tout à fait raison.
D’ailleurs du coup j’en profite : merci à toi fofo pour ta contribution aux pilotes de carte son (même si perso ça me concerne pas ^^)
En espérant que cette expérience particulière ne t’aura pas dégoûté.
Et merci à tous les INpactiens qui contribuent d’une manière ou d’une autre
#19
Voilà, d’un côté on nous dit “pas besoin d’être dév pour contribuer” et de l’autre “faut utiliser un logiciel A hyper-spécifique, te créer un compte, respecter la syntaxe et proposer une solution clé en mains au bug”.
C’est une question d’ouverture d’esprit comme tu dis, et de motivation : c’est vrai qu’un pull-request tout prêt c’est plus simple et plus rapide. Mais ce n’est pas le standard. Le standard c’est michu qui a un problème. Les utilisateurs qui se trouvent être dév qui parlent aux dév et dans leur langage, c’est du bonus. Pas l’inverse.
#20
Salut,
Ayant peu de compétence en développement (voir proche du null) j’ai pu contribué sur la traduction d’interface d’un projet anglais - francais et sur la traduction d’articles.
la procédure était clair sur l’outil à utiliser et c’était sympa de se sentir “utile” même si réellement la contribution n’est pas “fonctionnelle” (j’entends par là correction de bug ou ajout de code)
#21
Le ‘il n’est pas nécessaire d’être développeur pour contribuer’ vise à mettre en avant qu’on peut contribuer sans toucher au code (dons, pub, tutoriels, traductions….).
Si tu contribues au code, tu n’es pas le standard Michu, et l’attente de qualité et de formalisation à laquelle tu est soumis est plus forte (avec les avantages et les inconvénients que ça implique).
Perso au boulot ça m’arrive de devoir prendre en compte des soumissions ‘pas dans les formes’, et ça me fait toujours rager de passer des heures à jouer aux 7 différences pour retrouver mes petits alors qu’il aurait suffit au contributeur de passer quelques minutes à suivre la procédure pour m’épargner ce calvaire.
J’imagine que c’est pareil pour un mainteneur de logiciel open source, à ceci près qui lui n’est souvent même pas payé pour le faire.
En fait je trouve même ça triste un commentaire comme celui de fofo9012, parce qu’il y a des jours, peut-être des semaines de son travail qui n’ont pas été prises en compte, mais qui l’auraient peut-être été s’il avait pris les quelques heures nécessaires pour apprendre à utiliser les outils qui lui auraient permis de contribuer ‘dans les règles’. Ce qui a été fait de son travail est aussi en partie la conséquence de son choix de ne pas avoir appris à utiliser ces outils.
Après même quand on fait l’effort de respecter les formes des fois on tombe sur un trou du cul ou dans un trou noir, et ça reste extrêmement frustrant.
#22
Je pense que c’est un excellent exemple de frictions qu’il peut y avoir. Peut-être que si tu avais eu à ce moment quelques bons conseils, ça ne se serait pas passé comme ça? C’est très risqué en effet de partir sur un gros refactoring. Dans ce genre de cas je pense qu’il faut établir la communication bien en amont, pour avoir l’avis du mainteneur avant de rentrer dans le vif (peut-être l’avais-tu fait?). Parce que évidemment, passer un temps fou pour quelque chose qui sera refusé, il n’y a rien de plus dégoûtant. Dans ton cas, apparemment plein de choses ont été gardées donc c’est plutôt une réussite, même si ce ne fut pas simple. En général on essaie de faire des patchs focalisés sur un point précis pour éviter de s’exposer à trop de problèmes “secondaires” (autrement dit, pas tous les oeufs dans le même panier).
Même si je comprends cette frustration, il faut aussi se mettre à la place du mainteneur : un inconnu déboule et propose des tonnes de changements (je caricature, ça ne s’est peut-être pas passé exactement comme ça). Il y aura forcément un peu de méfiance au premier abord. Ça peut prendre du temps de comprendre exactement le use-case qui exige ces changements. Aussi, le contributeur en général ne pense qu’à son propre use-case, alors que le mainteneur est garant de la cohérence de l’ensemble et ne doit pas perdre de vue peut-être une myriade d’autres situations. Il y aura certainement des points qui peuvent vous paraître anodins mais qui seront critiques pour le mainteneur. Si le mainteneur a un haut niveau d’exigence, c’est peut-être rebutant pour des premières contributions, mais c’est peut-être aussi un gage de qualité pour le projet. Dans le cas que tu cites, avec les warnings du compilo, peut-être que tu as raison mais (désolé) on ne peut pas juger sans avoir l’autre son de cloche.
Quant aux pull-requests en général ça s’accompagne d’outils de code-review qui justement permet de fluidifier les échanges entre le contributeur et le mainteneur.
#23
Je n’ai pas précisé mais étant informaticien j’ai fait les choses à peu près correctement :) : c’était en réalité plusieurs patchs. (un migrant de python 2 à 3, un autre pour QT, un autre s’occupant des warning, de la migration de scons…)
Initialement je n’avais pas vraiment prévu de contribuer mais simplement d’apprendre python pendant une semaine de congé plutôt que de suivre des tutos de hello world pas trop utile, j’ai décidé d’étudier du code que j’avais sous la main. Comme ce package devenait problématique sous Gentoo avec ces dépendances datées, j’ai fait la migration vers python3. (histoire de lire bcp de code et d’en modifier un peu :) )
L’interface graphique étant gérée en PyQt4 j’ai appris Qt en même temps, et décider d’enchainer la migration vers PyQt5. (même remarque : Fin 2016 c’était un des derniers paquet à dépendre de Qt4, avec feu Amarok qui n’a pas survécu à Qt5 :rip: )
Bref c’est une contribution opportuniste, si j’ai voulu témoigner c’est que je pense que je ne suis pas un cas isolé, et malheureusement devoir justifier pendant des mois quelques jours de travail, ne m’a pas spécialement donné envie de recommencer :-/ (Pi j’ai posté mes patches en novembre 2016 sur la maillist, la version 2.4 (majeure
) basée sur mon travail est sortie 13mois pus tard : http://ffado.org/posts/ffado-2.4.0-release/
#23.1
Ben en tout cas félicitations d’être allé jusqu’au bout et d’avoir persévéré. C’est vrai qu’il y a parfois de quoi se décourager.
#24
Forcément ça allait partir en enfer, avec des gens voulant faire croire que libre est plus proche de copyleft que d’open-source…
La FSF a voulu jouer au plus malin, et a définit “libre” comme open-source, pour faire un enrobage faisant croire que c’est plus que ça (que ça s’approche du copyleft), c’est tout ce qu’on peut dire.
Ha si, on peut dire que la “tactique” de la FSF s’est retournée contre elle, et que les gens ont pris le libre tel que défini par la FSF et non pas tel qu’enrobé par la FSF, dommage.
N’en déplaise à la FSF et ses fans, suivant leur définition une licence MIT est tout aussi libre qu’une licence GPL. Aucune différence sur le libre, le libre est binaire, soit c’est libre soit ça ne l’est pas, et le libre ne parle jamais de ne pas aimer fermer.
Pour ceux qui sont curieux du libre : ne tombez pas dans le panneau de ceux qui veulent faire croire que le libre est plus que l’open-source, ce n’est pas le cas, c’est juste des gens qui n’apprécient pas que le libre a pris dans le monde et pas le copyleft (qui est libre aussi, mais empêche de fermer; pas de chance, ça empêche aussi de faire du libre genre impossible de mélanger 2 logiciels si un est en GPL version 2 et l’autre en GPL version 3, alors que les 2 logiciels sont séparément libres, donc de moins en moins de gens jouent avec le copyleft).
Pour ceux que ça intéresse sans tomber dans le panneau des pro-copyleft, on peut résumer :
PS : et si on veut troller, on peu lancer que la FSF n’a rien à faire du libre… Sauf exception (le logiciel), sinon le mouvement “open content” / “libre” dans son ensemble (donc comprenant pas que du logiciel, ça inclut Wikipedia) s’intéresse bien plus au libre que la FSF donc, le mouvement du libre va bien plus loin que la FSF ne le veut et accepte du non copyleft ainsi que du non logiciel (par exemple, Wikipedia est du non logiciel non copyleft).
#24.1
Le seul qui trolle ici c’est toi. Clairement ta culture du libre et de l’open source est récente, sinon tu ne mélangerais pas tout.
Libre = copyleft. Ça a toujours été la définition historique.
Le mot de copyleft n’a été créé que pour justement faciliter la compréhension des notions derrière la GPL parce que “free” pouvait être interprété aussi bien comme liberté “de l’utilisateur” (d’exploiter n’importe comment, y compris en se réappropriant) que liberté “du logiciel” (au sens où il ne peut être “enfermé” par quiconque).
Tout ce qui est libre est également open source.
Tout ce qui est open source n’est pas forcément libre.
Bref, de toute façon le reste de ton commentaire montre que aussi bien les distinctions juridiques entre les différentes licences que les enjeux qui en découlent te dépassent complètement.
Il est juste dommage que tu prétendes maîtriser le sujet (sur un ton péremptoire et portant jugements péjoratifs de surcroît).
Par ailleurs, sur l’évolution de la perception tu dis absolument n’importe quoi.
Ce n’est pas la FSF qui a poussé à confondre libre et open source.
Ce sont tous les éditeurs logiciels qui ont vu la montée en popularité des enjeux de maîtrise d’outil par les clients qui ont poussé à mort pour que l’on considère que “libre = open source” alors que ça n’a rien à voir, mais ça leur permettait d’améliorer leur image.
(On peut citer en exemple typique une entreprise française qui a déjà fait la une plusieurs fois sur NXI qui adore perpétuer la confusion parce que c’est dans son intérêt).
#25
Euh !! j’ai du raté quelque chose car la licence CC by-sa utilisé par Wikipédia m’apparait bien copyleft, le “sa” c’est pour “share-alike”, c’est-à-dire “partage à l’identique”. On peut donc faire ce qu’on veut de Wikipédia du moment qu’on cite les auteurs et qu’on partage sous les mêmes conditions.
#26
J’ai voulu trop troller et me suis mélangé les pinceaux avec un autre projet, tu as raison (et tu as rien raté), Wikipedia est “copyleft”. Et pan sur le bec, pour répondre un peu sec c’est mieux quand on ne se trompe pas…
#27
Le seul souci avec le logiciel libre, idée confortée quand je lis les diverses interventions ici, c’est qu’il y a de l’humain derrière. Et que parfois, l’humain est con.
Je ne suis pas développeur, mais quand je teste un outil et que je vois des comportements qui me paraissent chelou ou mal documentés qui m’ont demandé de creuser, je contribue en ce sens.
Dans le dernier cas, c’est souvent ici que la magie du fork intervient. Le dernier que j’ai constaté dans mes geekages persos était Gogs forké en Gitea parce que le développeur était l’unique mainteneur du repo.
Pour résumer, dans mon cas j’essaye surtout de contribuer à la documentation… Parce qu’il n’y a rien de plus rageant que le “README.md” avec 3 lignes de commandes sans explications qui échoueront dès qu’on sort de Debian/Ubuntu.
#28
Dans les communs il y a aussi la culture en licence libre qui est potentiellement accessible à des non développeurs.
Je pense notamment à la BD Pepper & Carrot de David Revoy, traduite en une vingtaine de langues pour certains épisodes (le traducteur danois n’a même pas quinze ans si je me souviens bien, c’est chouette !), il y a une BD dérivée, des jeux, etc. …
Pour parler de ma paroisse, je fais partie de l’association Khaganat qui créé un univers en licence libre (CC-BY-SA), j’y ai écrit quelques nouvelles, et animé quelques ateliers créatifs où on invente de la faune et de la flore, dessins compris (moi je sais pas dessiner mais je guide ceux qui savent faire, c’est des bons moments en général !).
#29
Au passage on voit bien que le travail de sape du vocabulaire et de l’histoire par l’écosystème commercial a été bien efficace…
Tu bosserais pas chez LA toi ? XD
(Je rappelle à titre purement accessoire que la notion de “free software” a été ébauchée puis définie fermement par Richard Stallman, fondateur du projet GNU et de la Free Software Fondation. Alors aller prétendre ensuite que la FSF a “déformé la notion de logiciel libre”, c’est ‘achement savoureux.
)
Note pour finir : mon propos n’est absolument pas de prétendre que seul le logiciel libre est intéressant et l’open source le mal, trèèèès loin de là.
À mon sens les deux sont complémentaires et indispensables.
En revanche faut arrêter de perpétuer une confusion entre deux approches et modèles de licence TRÈS différents.
#30
“La traduction passe par le compte Weblate de Framasoft où l’on peut voir les langues concernées et ce qu’il reste à traduire.”
Jsuis pas dev, donc ça y est, je viens de compléter à 100 % les trads françaises :) (Bon, il ne reste plus qu’à checker les erreurs de vérification, on verra ça demain 😁)
J’ai bon ?
#31
C’est surtout que « free », en anglais, peut signifier aussi bien libre que gratuit. Et malheureusement, la plupart des gens n’y voyaient que des logiciels gratuits, sans voir tout ce que ça pouvait leur apporter.
#32
Pour les curieux, ne tombez pas dans le panneau, ici c’est du troll.
La source : https://www.gnu.org/philosophy/free-sw.html
la définition exacte de la FSF de libre fait beaucoup la différence : libre ne veut pas du tout dire copyleft, même la FSF dit explicitement que MIT est libre
https://directory.fsf.org/wiki/License:X11
“This is a lax permissive non-copyleft free software license”
On ne peut pas faire plus clair : une licence MIT n’est pas copyleft, mais est libre à 100%.
Il y a juste de gens qui veulent faire croire que le libre a un lien avec le copyleft.
Je te défie de démontrer ça.
(allez, je t’aide : OSI avait accepté la licence NASA comme open source, la FSF a dit pas libre à cause d’une clause, c’est le seul cas connu… Et la NASA n’utilise plus cette licence depuis des lustres. Dommage)
Les pro-copyleft ne cesseront de m’étonner à essayer de tromper (car la on est dans la tromperie, le mensonge, quand on répète sans se renseigner) les gens juste parce que le libre / open source a pris mais pas le copyleft… Et dire qu’il suffirait à la FSF de changer leur propre définition pour dire que libre = copyleft, mais bizarrement ils ne le font pas :).
#32.1
Ils ont fait évoluer leurs positions depuis quelques années sous la pression de l’écosystème et par pragmatisme (mieux vaut toujours des logiciels open source que du propriétaire), mais ce n’était pas du tout la définition originelle.
Tu fais ce que tu veux, mais merci de ne pas confondre historique et présent. :)
#33
C’est pourtant simple.
Le copyleft, c’est libre, et ça doit le rester. À partir de là, toutes les licences libres qui permettent qu’à un moment, ça ne soit plus libre, sont en contradiction avec la philosophie du libre (et donc du copyleft).
Par exemple, un logiciel sous licence BSD est libre : le code source est disponible, on a le droit de le modifier, de le redistribuer… mais à tout moment, n’importe qui a le droit d’en faire un logiciel propriétaire. C’est d’ailleurs ce qu’ont fait Apple et Sony pour leurs systèmes, par exemple.
Il faut se dire qu’il y a deux courants de pensée. Un premier, très philosophique et politique, qui défend les droits de l’utilisateur, tandis que l’autre, plus pragmatique, se focalise sur des considérations techniques et économiques (la licence libre nous permet de développer plus rapidement, de faire des économies, de faire adopter plus facilement notre technologie par le plus grand nombre pour asseoir notre monopole, comme ce fut le cas pour Android…).
L’un va défendre les droits des utilisateurs, tandis que l’autre sera plutôt défendu par les entreprises.
#34
Oh mais la on est d’accord, vu qu tu as séparé la notion de “libre” (BSD est libre) et le courant de pensée de la FSF (BSD est “trop” libre car permet de fermer et la FSF n’aiment pas même si ils disent que c’est bien libre).
Ce qui m’amusent sont les gens qui veulent faire croire que la FSF a défini libre comme le copyleft alors qu’il est bien clair que ce n’est pas le cas, la FSF communique beaucoup mais n’écrit pas noir sur blanc dans la définition, perso je trouve ça amusant (je préfère en rire car sinon je râlerai, je passe pas mal de temps à expliquer que non le libre ne se limite pas aux copyleft et des attaques incessantes contre du libre qui ne plaît pas car laisse trop de libertés aux gens)
C’est caricatural, une tonne d’individus (pas entreprises) trouvent l’idée de la GPL sympa sur la papier mais en pratique très chiante (impossible de mettre du code GPLv2 dans un programme GPLv3 par exemple, trop de questions sur les limites droit ou pas droits), et surtout sont pour inciter (c’est libre, tu peux fermer mais tu devrais pas) plutôt que forcer (c’est libre et tu gardes libre ou tu fais pas).
C’est un choix philosophique, le monde a choisi d’ailleurs que forcer, ben bof ;-).
PS : j’hésite… allez, c’est sans parler des gens “anti-capitalistes” qui disent qu’interdire le commercial serait dans la “philosophie du libre” (alors que c’est complètement incompatible), ou que ça serait légitime d’interdire au FN d’utiliser (alors que c’est complètement incompatible), ce qui est rigolo avec la “philosophie du libre” c’est que chacun y met le la sienne et parfois sans se rendre compte que c’est complètement incompatible avec la définition “mère” :). Bref, voila, ça a ouvert la partie trollesque…
#35
Si on pouvait éviter les dérives n’importe nawak sur des débats sans fin ou chacun campe sa position, ça rendrait les commentaires plus lisibles. Merci
#36
Bravo pour réussir à inventer n’importe quelle excuse, de créer ta propre réalité alternative, pour ne pas accepter la réalité.
(pour info la définition de “libre” par la FSF, les 4 libertés, n’ont pas changées depuis un très gros moment, le présent est quasi identique à l’historique, j’utilise donc leur définition originelle, ils se sont fait juste avoir parce que les gens ont adoré leur définition originelle de libre sans prendre leurs idées sur le copyleft qu’ils ont mises à côté)
archive.org n’a que la page de 1998, mais déjà en 1998 ils avaient cette définition de logiciel libre (il manquait certes la “liberté 0”, mais ne change rien à notre discussion), “triste” réalité
.
https://web.archive.org/web/19980126185518/https://www.gnu.org/philosophy/free-sw.html
Tu noteras que je référence la FSF elle-même, son site, sa définition de “libre”, dans leur langue natale pour ne pas avoir de soucis de traduction, qui ne parle jamais (dan la définition, ce qui n’est pas dans la définition n’est que du marketing) d’empêcher de fermer, quand tu n’apportes aucune référence à tes dires.
Les pro-copyleft et pro “esprit de libre qu’on n’a pas écrit dans la définition” sont si mauvais perdants, les gens ont pris goût à avoir plus libertés que ce qu’ils voulaient… Je te défie de trouver une seule référence sérieuse sur l’idée que BSD ou MIT n’auraient pas été libres un jour (il n’y en a pas vu que ces licences ont toujours été libres…).
PS : David, oups, bon j’essaye de ne pas y retourner :-p.