Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément...).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
L'autre a aussi une vie, il n'est pas votre esclave, et notamment son temps ne vous est pas réservé (donc les réponses peuvent prendre du temps notamment).
Il peut faire des erreurs aussi; par exemple même oublier de répondre! Donc le relancer n'est pas mal pris, du moment que c'est pas en insistant lourdement tous les jours, cf. point précédent. Je considère souvent que relancer après 2 ou 3 semaines est une bonne moyenne. Répondre à un email ou un message de rapport après quelques semaines n'est absolument pas rare. On met un sujet dans un coin de notre TODO liste pour "plus tard", puis on répond quand on peut. Après quelques semaines sans réponse, on peut cependant se dire que la personne a peut-être oublier.
Il peut avoir des priorités différentes que vous (et c'est ok). Il faut savoir l'accepter et mettre en valeur les compromis.
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça). Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder. En ce moment, par exemple, j'ai trois contributions pour Sozi que je ne souhaite pas intégrer : une parce qu'elle n'est pas complète, une qui s'apparente à un bricolage et qui mériterait d'être réécrite, et une autre parce qu'elle me semble incohérente avec la philosophie du projet.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça).
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
L'autre problème que je rencontre parfois, c'est qu'une fois la nouvelle fonctionnalité ajoutée, les contributeurs disparaissent et on se retrouve tout seul pour maintenir leur code.
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Forker ou ne pas forker ?. Évalué à 10.
Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément...).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]