Ce journal fait un peu suite à ce post de palkeo qui avoua sa difficulté de contribuer au développement du logiciel libre (il peut me corriger si j'ai mal interprété ses propos).
Voici ci-dessous le lien vers un article sur les manières de contribuer au libre, et ce n'est pas une question de CV qui fera de vous un meilleur contributeur. L'auteur est Barbara Shaurette, une vétérane dans l'open source, avec pas moins de 15 années d'expérience en tant que programmeur pro, dont 5 années avec une participation active au sein de la communauté Python, et Django.
Qu'apprend-t-on dans cet article ? Eh bien, que le libre ne s'arrête pas au code et que les manières de mettre la main à la pâte sont suffisamment nombreuses pour se dire qu'on a finalement participé à l'aventure.
En effet, Barbara nous informe qu'il y a le fait de coder pour un projet, mais aussi pour ce qui n'existe pas, tout en le gratifiant d'une licence ouverte sur l'opensource. Quant à ceux qui ne programment pas, ils auront la possibilité d'offrir quelques deniers à des fondations/projets, de donner de leur temps dans des associations/réunions/etc, ou de partager la connaissance (et pas nécessairement leurs connaissances) via des documentations (voir mon journal sur Jacob Kaplan-Moss) et blogs.
- article en question: http://opensource.com/life/12/11/open-source-contributions-come-all-shapes-and-sizes
Cet article donne beaucoup d'exemples en rapport avec Django ou Python, mais c'est le fruit de l'expérience de l'auteur. Je trouve personnellement qu'il n'y a pas de grandes difficultés à trouver comment contribuer pour celui qui se donne la peine de chercher, bien que le fait de ne pas savoir coder puisse en rebuter plus d'un dans cette volonté de rechercher, car on pense à tort que le libre ce n'est que du code.
# Contribuer à la base de code
Posté par hugoatease . Évalué à 5.
Le journal de palkeo était quand même essentiellement construit autour de la difficulté à s'impliquer dans l'effort de programmation d'un logiciel libre. Il était plus question de la problématique de l'intégration à une communauté de développement open-source plutôt que de celle des contributions "auxiliaires".
[^] # Re: Contribuer à la base de code
Posté par xunfr . Évalué à 2.
Heureusement que j'ai pris la peine de rajouter le mot "un peu". Je sais très bien qu'on est dans une autre aventure, mais finalement la problématique de l'intégration ne fait-elle pas partie de la contribution à l'opensource ?
Quelles soient "auxiliaires" ou pas, ce journal vient souligner un article qui traite de la contribution en général.
# Contribuer à la base de code
Posté par hugoatease . Évalué à -4.
Le journal de palkeo était quand même essentiellement construit autour de la difficulté à s'impliquer dans l'effort de programmation d'un logiciel libre. Il était plus question de la problématique de l'intégration à une communauté de développement open-source plutôt que de celle des contributions "auxiliaires".
[^] # Re: Contribuer à la base de code
Posté par xunfr . Évalué à 0. Dernière modification le 09 novembre 2012 à 16:31.
[avis aux modos, erreur de post, peut-on le supprimer?]
# titre
Posté par BAud (site web personnel) . Évalué à 5.
En fait si àmha. Mais je n'entends pas expérience au sens « compétence préalable permettant d'être directement efficace ».
(et je pense que j'irai dans le sens de bshaurette<).
Une expérience c'est aussi savoir se lancer, aborder un sujet qui est resté de côté, apporter une approche complémentaire, faire quelque chose que d'autres n'ont pas encore fait (ou aller plus loin que ce qui est déjà fait). Vous le remarquez tout de suite : mais bon sang, mais c'est bien sûr lorsque vous constatez l'activité d'un contributeur sur un sujet spécifique (=précis) permettant de traiter des sujets qui n'avançaient pas jusque là.
La contribution au libre commence ainsi : quelqu'un qui apporte quelque chose, une contribution, même s'il ne s'en rend pas compte, il apporte un point de vue nouveau. N'aurait-il rien dit, personne ne l'aurait réalisé (ni fait). Le volet expérience, c'est la possibilité d'expérimenter, d'apporter des choses, d'apprendre en même temps éventuellement. Mais cela ne fonctionne que si vous recevez des soutiens de gens qui remarquent ce genre de chose, c'est le point qui me semble important : c'est une forme de reconnaissance, mais c'est avant tout une forme de fonctionnement : laisser faire et permettre de réaliser à ceux qui sont impliqués, sans bâtons dans les roues ni soucis administratifs ; bref, de l'opérationnel efficace.
Je vais prendre un exemple que je connais bien : mon cas sur eagle-usb.
Si je suis devenu contributeur, ce n'est pas parce que j'avais de l'expérience en modem ADSL, mais je souhaitais que le mien fonctionne sur ma distro (et qu'idéalement il fonctionne pour d'autres). Lorsque j'ai suggéré que le support serait mieux fait avec un phpBB plutôt qu'un spip, je me suis vu d'un coup octroyé les clés du site web (le mainteneur web précédent n'était plus joignable). Je l'ai mis en place (bon, déployer un phpBB 2 stait à la portée de n'importe qui, ça n'avait pas été fait jusque là…). Cela a apporté le support en anglais / français (et j'ai ajouté espagnol que je maîtrise aussi).
Ensuite, la doc' est venue d'elle-même, pour constituer une FAQ, j'ai découvert les wiki (ça c'est le côté expérience : essayer quelque chose qui semble répondre au besoin, sans connaissance préalable).
Intégrer le pilote à une distro, c'est facile : suffit de connaître ceux qui peuvent le faire et avoir simplifié le travail en amont (scripter, documenter la compilation, faire des paquets de manière automatique tar.gz d'abord rpm et deb ensuite… les contributeurs se prennent au jeu pour leur propre distro, c'est naturel quand des gens motivés se présentent, bon blino et tv ont joué un rôle crucial tout de même sur le moment et ont complété ce qui manquait).
Il faut effectivement trouver un sujet motivant, avoir beaucoup de demandes, c'est à la fois motivant et démotivant àmha, du choix de documenter pour donner les moyens à d'autres de participer :) Cela m'a tout de même permis de me remettre à l'espagnol (merci les argentins), découvrir le polonais voire d'autre pays d'Europe comme l'Estonie… ça c'est une expérience :) (mais issue de la participation, non anticipée au départ). J'en ai retiré bien d'autres expériences, mais cela dépasserait le cadre de ce commentaire. Le seul point à retenir est : être là au bon moment, motivé sur son sujet, pouvoir faire quelque chose, faire d'autres choses ensuite (au choix de chacun).
[^] # Re: titre
Posté par ckyl . Évalué à 3.
Exactement. Dans le libre comme dans tout projet à partir du moment ou il y a quelque chose tu trouves mal expliqué, qui manque, mal fait, pas automatisé, pas testé, pas documenté tu grognes pour toi, si l'explication n'est pas triviale tu demandes poliment si y'a une raison, et tu le fais. Comme ça soit toute l'équipe en bénéficie et tout le monde gagne en vélocité, soit c'est plus facile pour les utilisateurs.
[^] # Re: titre
Posté par freem . Évalué à 0.
Je suis d'accord…
Sur la reprise d'autorealm, il m'est arrivé à plusieurs reprise d'expliquer du mieux que je pouvais le problème que j'avais sur les mailing list d'autorealm, pourtant pas forcément pleines de dev ni très actives, et certains utilisateurs m'ont répondu, me donnant des idées.
Parfois même en faisant un rapport de progression de mon travail (alors qu'étant le seul dev je n'y était pas contraint)
Un exemple tout bête, en apparence, comme contribution, mais je n'aurais pas réussi à gérer la sauvegarde/le chargement des fichiers sans ça:
J'ai un système de plug-in qui impacte directement sur le modèle de données, ça implique de sérialiser des choses qu'on ne connaît pas, et donc d'identifier à la désérialisation des choses qu'on ne connaît pas encore.
J'étais "parti" (mais sans y arriver) sur un système d'identification unique des plug-ins via leur nom et leurs versions, j'ai expliqué ça sur la mailing list des utilisateurs, et quelqu'un m'a dit, en gros:
"Je suis pas calé sur ça, je ne connaît pas les contraintes en terme de dev, j'ai pas envie de plonger dans le code, mais je pense que ton idée va être très chiante à gérer pour les utilisateurs. Pourquoi ne pas demander au plug-in de nommer les choses qu'ils savent faire, et quand le moteur sauve un fichier, écrire dedans le nom de la fonctionnalité? Quand le moteur charge, il a juste a récupérer le nom de la fonctionnalité et trouver un plug-in qui la supporte."
Et la, paf, ça a fait des chocapics. Grâce à son idée, j'ai réussi à implémenter un truc qui me résistait depuis plusieurs semaines, avec un système pourtant super répandu sur le net: les tags.
Comme quoi, j'irai même dire qu'il n'y a pas besoin de savoir dev pour contribuer au code, parce que c'est ce qu'il a fait indirectement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.