Il existe beaucoup de projets morts-nés, ou abandonnés, c'est un fait et je pense que ça a toujours été le cas (les plateformes de dépôts de code les ont juste rendus un peu plus visibles).
Ensuite il y a des projets actifs, mais qui ne sont libres que par mode, sans comprendre ce que ça implique en général (même lorsque c'est à l'avantage du projet comme la contribution externe).
Enfin — et c'est ce qui nous intéresse — il y a tous ces projets qui manquent de temps/main d'œuvre pour tout gérer. C'est vrai pour des petits projets (car c'est souvent une personne seule qui fait tout, souvent sur son temps libre), mais même aussi pour de gros projets. Peut-être parfois même encore plus le cas, car un gros projet est "victime" de son succès, mais sans avoir forcément énormément plus de développeurs (disons que le nombre de développeurs "core" augmente moins rapidement que les contributions "occasionnelles" et rapports de bugs). Personne n'est épargné sur ce point, je pense.
En temps que développeur actif — voire parfois mainteneur — sur certains projets parfois extrêmement connus (GIMP), parfois moins (uchardet, crossroad...), j'adore autant contribuer du nouveau code qu'intégrer ou coordonner de nouvelles contributions. Je trouve cela extrêmement gratifiant d'intégrer du code externe sur un projet auquel on tient. Et c'est encore plus gratifiant quand on arrive à intégrer suffisamment un contributeur actif pour en faire un nouveau développeur core. Mais cela prend un temps fou. Parfois cela prend même plus de temps que si on avait essayé de coder la chose nous même. Très souvent, il faut revoir le code, le commenter, demander des changements, et nous même attendre les changements... Des mois passent. C'est normal.
Recevoir des contributions externes est donc souvent plus qu'une question de gain de temps (au contraire, si des fois on en perd), c'est un gain de qualité (on a bénéficié des yeux d'autrui. On aurait certes mis moins de temps, mais on n'aurait peut-être aussi jamais pensé à faire ce changement), c'est du brainstorming perpétuel avec le monde, c'est de l'intégration de code, mais aussi d'humains (on espère toujours qu'un développeur de qualité finira par devenir dév core), etc.
Bien sûr, de nombreux projets sont totalement irresponsables et "mergent" des bouts de code sans même les tester et en les lisant en diagonal. Github est notamment beaucoup responsable de cette logique. Perso je n'intègre jamais un nouveau code sans essayer de comprendre en détail ce que ça fait, pourquoi il faut changer, puis tester. En outre, on a en général une vision plus vaste du projet que les contributeurs occasionnels et c'est à nous que revient la charge de nous assurer que cela ne casse pas quelque chose d'autres auquel le contributeur n'a pas du tout pensé.
Au final, oui le logiciel libre, c'est souvent l'apprentissage de la patience. On attend beaucoup. Mais faut comprendre que derrière, les gens ont aussi leurs propres priorités. Tu le dis toi-même d'ailleurs:
Premier retour en une semaine et une demande de correction en un mois. Je traîne un peu et presque trois mois plus tard
Dans ton cas, ils ont mis 1 mois pour te demander une correction, et tu mets 3 mois à leur répondre. Mais ils se sont pas plaints (et s'ils le font, c'est pas malin). Ils ont attendus. C'est normal, ça arrive. Ils savent aussi que les contributeurs ont aussi leurs propres priorités et ce n'est pas parce qu'ils ont fait un patch qu'ils vont répondre immédiatement aux demande de correction du dit patch.
Des fois, on perd des patchs ainsi car ils ne reviennent jamais. Mais que peut-on y faire? Nous sommes prêts à les attendre, et on en attend autant des contributeurs envers nous.
Donc oui, pour contribuer au logiciel libre, apprendre la patience et une forme d'empathie (pas de l'empathie émotionnelle, mais disons une sorte d'empathie sociale) fait clairement partie du processus. Le seul moyen d'y échapper est d'être le mainteneur sur tous ses projets et de ne jamais contribuer à un projet tiers.
J'ai contribué en une dizaine d'années à des dizaines de projets. Certains patchs ont été rapides, certains ont pris des mois et des mois. Certains n'ont même jamais été intégrés, notamment j'ai des souvenirs de certaines fonctionnalités précises parmi mes premières contributions, avec des patchs envoyés sur des mailing lists (de projets actifs) qui n'ont jamais eu de réponse. Mais je sais que la faute est mienne car j'aurais dû insister (gentiment et poliment) mais à l'époque, je ne savais pas et ai abandonné.
La contribution aux LL, ça se fait sur le long terme. Mais ce n'est pas grave. Au final je pense que j'ai apporté des pierres vraiment non négligeables à l'édifice du Libre et je suis vraiment content d'avoir appris ce jeu de la patience.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: À propos des nouvelles fonctionnalités
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Cinq ans de projets libres : bilan et retour d'expérience sur la contribution. Évalué à 9.
Il existe beaucoup de projets morts-nés, ou abandonnés, c'est un fait et je pense que ça a toujours été le cas (les plateformes de dépôts de code les ont juste rendus un peu plus visibles).
Ensuite il y a des projets actifs, mais qui ne sont libres que par mode, sans comprendre ce que ça implique en général (même lorsque c'est à l'avantage du projet comme la contribution externe).
Enfin — et c'est ce qui nous intéresse — il y a tous ces projets qui manquent de temps/main d'œuvre pour tout gérer. C'est vrai pour des petits projets (car c'est souvent une personne seule qui fait tout, souvent sur son temps libre), mais même aussi pour de gros projets. Peut-être parfois même encore plus le cas, car un gros projet est "victime" de son succès, mais sans avoir forcément énormément plus de développeurs (disons que le nombre de développeurs "core" augmente moins rapidement que les contributions "occasionnelles" et rapports de bugs). Personne n'est épargné sur ce point, je pense.
En temps que développeur actif — voire parfois mainteneur — sur certains projets parfois extrêmement connus (GIMP), parfois moins (uchardet, crossroad...), j'adore autant contribuer du nouveau code qu'intégrer ou coordonner de nouvelles contributions. Je trouve cela extrêmement gratifiant d'intégrer du code externe sur un projet auquel on tient. Et c'est encore plus gratifiant quand on arrive à intégrer suffisamment un contributeur actif pour en faire un nouveau développeur core. Mais cela prend un temps fou. Parfois cela prend même plus de temps que si on avait essayé de coder la chose nous même. Très souvent, il faut revoir le code, le commenter, demander des changements, et nous même attendre les changements... Des mois passent. C'est normal.
Recevoir des contributions externes est donc souvent plus qu'une question de gain de temps (au contraire, si des fois on en perd), c'est un gain de qualité (on a bénéficié des yeux d'autrui. On aurait certes mis moins de temps, mais on n'aurait peut-être aussi jamais pensé à faire ce changement), c'est du brainstorming perpétuel avec le monde, c'est de l'intégration de code, mais aussi d'humains (on espère toujours qu'un développeur de qualité finira par devenir dév core), etc.
Bien sûr, de nombreux projets sont totalement irresponsables et "mergent" des bouts de code sans même les tester et en les lisant en diagonal. Github est notamment beaucoup responsable de cette logique. Perso je n'intègre jamais un nouveau code sans essayer de comprendre en détail ce que ça fait, pourquoi il faut changer, puis tester. En outre, on a en général une vision plus vaste du projet que les contributeurs occasionnels et c'est à nous que revient la charge de nous assurer que cela ne casse pas quelque chose d'autres auquel le contributeur n'a pas du tout pensé.
Au final, oui le logiciel libre, c'est souvent l'apprentissage de la patience. On attend beaucoup. Mais faut comprendre que derrière, les gens ont aussi leurs propres priorités. Tu le dis toi-même d'ailleurs:
Dans ton cas, ils ont mis 1 mois pour te demander une correction, et tu mets 3 mois à leur répondre. Mais ils se sont pas plaints (et s'ils le font, c'est pas malin). Ils ont attendus. C'est normal, ça arrive. Ils savent aussi que les contributeurs ont aussi leurs propres priorités et ce n'est pas parce qu'ils ont fait un patch qu'ils vont répondre immédiatement aux demande de correction du dit patch.
Des fois, on perd des patchs ainsi car ils ne reviennent jamais. Mais que peut-on y faire? Nous sommes prêts à les attendre, et on en attend autant des contributeurs envers nous.
Donc oui, pour contribuer au logiciel libre, apprendre la patience et une forme d'empathie (pas de l'empathie émotionnelle, mais disons une sorte d'empathie sociale) fait clairement partie du processus. Le seul moyen d'y échapper est d'être le mainteneur sur tous ses projets et de ne jamais contribuer à un projet tiers.
J'ai contribué en une dizaine d'années à des dizaines de projets. Certains patchs ont été rapides, certains ont pris des mois et des mois. Certains n'ont même jamais été intégrés, notamment j'ai des souvenirs de certaines fonctionnalités précises parmi mes premières contributions, avec des patchs envoyés sur des mailing lists (de projets actifs) qui n'ont jamais eu de réponse. Mais je sais que la faute est mienne car j'aurais dû insister (gentiment et poliment) mais à l'époque, je ne savais pas et ai abandonné.
La contribution aux LL, ça se fait sur le long terme. Mais ce n'est pas grave. Au final je pense que j'ai apporté des pierres vraiment non négligeables à l'édifice du Libre et je suis vraiment content d'avoir appris ce jeu de la patience.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]