Je suis utilisateur de linux depuis plusieurs années maintenant, et depuis toujours j'ai plus ou moins bidouillé quelques sources pour les adapter à mes besoins.
Ces derniers temps, j'ai décidé d'aller plus loin, et de fournir sous forme de patch, les modifications que j'ai apporté pour 2 projets. Il s'agit de roundcubemail [1] et initng [2].
Je l'avais une fois en créant 2 plugins pour gaim, mais je m'étais un peu fait bouler lorsque j'avais traîné à modifier lesdits plugins au changement de version de gaim (qui changeait l'API des plugins à chaque numéro de version ou presque).
Outre le fait que faire une modification pour soit et la fournir sous forme de patch n'implique pas la même somme de boulot, n'avoir aucun retour positif sur sa contribution est très frustrant, et stoppe tout envie de continuer. Je crois que tout le monde ici en est conscient, c'est souvent que l'on voit des journaux sur des plaintes des développeurs du noyau (entre autres).
L'amertume étant passée, j'ai donc contribué à nouveau. Ca se passe globalement toujours de la même manière : inscription sur la ML, lecture des conduites à suivre sur le code que l'on fournit, politesse tout ça, on envoie le patch ou les sources sur la ML, et on attend.
Et cette fois-ci j'ai eu des retours ! Plutôt positif pour le 1er, plus encore pour le 2nd puisqu'il semble qu'il n'y ait plus beaucoup de contributions externes. Les devs d'initng en profitent même pour me faire un petit appel à contribution sur un autre sujet. Je dois avouer que je suis assez tenté d'y répondre favorablement.
Finalement, je regrette de ne pas avoir contribué plus tôt après la frustration rencontrée sur le projet gaim (en plus je connaissais sa réputation, m'enfin...), et je pense que je serai moins réticent maintenant sur le rejet ou l'absence de retour. De toutes façons, il y a tellement de projets libres où ils manquent des bras !
Voilà, j'espère avoir redonné un peu de courage à ceux qui ont vécu la même situation, et peut être qui sait démystifié le principe des contributions à ceux qui n'ont jamais tenté !
[1] http://www.roundcube.net
[2] http://www.initng.org/
Journal Retours d'expérience sur contributions au libre
4
août
2007
# gaim
Posté par ribwund . Évalué à 10.
La plupart des projets libres ne ressemblent pas à ca.
# Acces CVS
Posté par timid . Évalué à 3.
Voir son patch trainer des mois, devoir le réactualiser sans arrêt pour qu'il suive l'évolution du logiciel en attendant d'être intégré ... faut avoir de la motivation quand même !
[^] # Re: Acces CVS
Posté par Olivier Grisel (site web personnel) . Évalué à 2.
Pour ceux qui n'auraient pas encore entendu la sainte parole de Linus a propos de git:
http://video.google.com/videoplay?docid=-2199332044603874737
(la majorité de ce qu'il dit pour git est valable pour mercurial and bazaar).
[^] # Re: Acces CVS
Posté par Misc (site web personnel) . Évalué à 4.
[^] # Re: Acces CVS
Posté par Olivier Grisel (site web personnel) . Évalué à 5.
- tu n'es pas obligé d'attendre que ta branche soit mergée dans la branche officielle de release pour pouvoir continuer de bosser, faire des update, recuperer les modification des autres, travailler sur d'autres parties qui ont besoin de tes modifs a toi.
- meme si tes modifs sont trop experimentales pour etre mergees dans la branche de release officielle (stable toussa), ca n'empeche pas les autres developpeurs t'integegrer tes modifs dans leur branche experimentales a eux pour tester, evaluer, améliorer sans se prendre la tete a s'assurer que le code est suffisamment testé pour meriter d'etre dans la branche de production.
En gros ca assouplit le processus de developement en permettant a des petits groupes de developpeurs de bosser ensemble dans leurs branches experimentales sans mettre en jeu la stabilité de la branche officielle.
[^] # Re: Acces CVS
Posté par Bozo_le_clown . Évalué à 2.
Et comment tu fais ca ?
Si tu continues à bosser dans ta branche initiale sur un autre changement avec des recouvrements (même fichier modifié pour les 2 changeset) et que le premier n'est pas intégré tu risques de te faire jeter tout autant car les autres dev qui veulent récupérer ton boulot ne veulent pas récuperer ton ancien changeset.
Conclusion: tu te crées une autre branches ce qui revient au même que de se créer un autre worspace avec un outils centralisé (avec l'avantage de pouvoir commiter des versions inetrmédiaire il est vrai)
Si il n'y a pas recouvrement c'est autrechose, mais pas facile de l'anticiper.
SVN 1.5 traitera ce pb à la Perforce en mode centralisé
http://blogs.open.collab.net/svn/2007/07/one-quality-of-.htm(...)
Là, en effet les DVCS sont plus simples.
Avec un CVS centralisé, si tu as une branche expérimentale le repository admin te donne les droits sur le repository pour te créer ta propre branche, soit il t'ouvre les droits sur la branche, soit tu envoies ton diff.
Avec un DCVS cependant, c'est aussi une bonne idée de te permettre de pusher ta branche dans l'archive centrale parce que si les autres ont besoin de tes modifs quand tu pars en vacances ca le fait moyen.
# Contribution 'utilisateur'
Posté par Epy . Évalué à 5.
J'ai envoyé le bout qui n'était pas traduit, et ça n'est toujours pas intégré 1 version (+0.1) et trois bêtas plus tard ..
Je ne parlerai pas de mes demandes pour "créer" un soft Libre,
j'espère que les prochaines se passeront mieux.. (ici peut-être ?)
En tant que passionné et utilisateur du Libre il reste encore trop de réactions négatives qui ternissent sérieusement l'image.
Ne serait-ce qu'ici quand on voit un commentaire qui commence par "Je vais me faire descendre par les intégristes du Libre" ou quand un pote me répond que les "Open Source" sont finalement les moins ouverts d'esprit alors que je lui ai simplement expliqué que c'est son navigateur avec moteur IE qui affiche mal le code propre ...
Il y a de quoi se poser des questions, j'espère que cela changera et il faut que nous fassions en sorte que cela change.
[^] # Re: Contribution 'utilisateur'
Posté par Anonyme . Évalué à 10.
Disclaimer : malgré mes envies, je ne contribue que très peu au libre, mais je suis développeur.
Développer un logiciel est une tâche difficile, et ressemble plus a un supplice de sisyphe, qu'a une tache a accomplir : rien n'est jamais terminé, et en plus il faut toujours revenir sur le travail effectué, parfois remémorant des moment difficile - casser quelque chose ou le seul plaisir de l'accomplissement était de le terminer n'est pas une expérience particulièrement agréable. Tout sans presque aucun encouragement voire plutôt des mail d'insultes (plus promptes a être envoyées en privée).
En faisant des petites contributions on ne voit que la partie émergée de l'iceberg, et s'il est frustrant de n'avoir aucun retour quand on a envoyé une contribution au dévelopeur sachez qu'il a nécessairement du mal a les considérer : c'est lui qui est dans le trou de sisyphe. Lui envoyer de l'aide depuis le bord de la falaise est certes sympathique, et je crois qu'il y a toujours une gratitude, même si elle est non exprimée ou suivie de fait. Parce que c'est lui qui reste dans le trou, les autres étant toujours très libre (d'ou le ressentiment lors d'un non suivit de version pour un plugin, pour reprendre le cas gaim).
Mais comme d'habitude, les dévelopeurs sont incompris, quand en général on parle de choix techniques (pas de video dans gaim, moins de hacks ie dans konqueror, etc, etc) ici c'est dans le processus de développement. Et puis on charge la bête, sentimentalement, parfois sans avoir réellement compris la problématique. Notez, ceci est vrai aussi dans le proprio : quand vous avez la commerciale qui sort "mais vous ne pouvez pas faire de logiciels sans bugs ?" a l'équipe de développement sous dimensionée et produisant bonnant mallant du code très correct selon les normes de l'industrie, ca fait mal, très mal.
Alors dans un cas on a l'utilisateur qui rale après le développeur parce qu'il estime que le logiciel est "pas foutu comme il faut", dans l'autre nous avons le contributeur demandant de la reconnaissance (par les faits - patch/intégration - ou exprimée), sans forcément se rendre compte que ca ne tiens pas de l'évidence (un patch c'est toujours du boulot a gérer, et on ne peut pas toujours être de bonne condition pour dire "merci" parce que même si oui c'est bien, c'est encore un truc de plus dans la TODO list, surtout quand on est bénévole)
Donc ma position est la suivante : si l'on attache de l'importance au relationnel, bien choisir son projet en fonction de l'ambiance. Sinon, partir du principe que si l'on participe, c'est pour le bien de tous en particulier de l'utilsateur final, et pas pour le développeur du projet qui n'est donc pas tenu de remercier : l'intérêt de cette position est qu'elle est la plus logique dans le contexte du libre. Le développement du libre désintéressé, sans aucune attente de retour est plus sain, et puis si un jour un merci ou un encouragement tombe, il aura beaucoup plus d'impact.
Pour ma part, je part du principe que je vais me faire jeter pour une raison x ou y, en estimant que si l'on prend de m'expliquer pourquoi ce sera déjà pas mal. Et le reste alors, ne sera que du bonheur.
[^] # Re: Contribution 'utilisateur'
Posté par Gof (site web personnel) . Évalué à 10.
On développe du libre sur son temps libre. Alors parfois on a un peu moins de temps libre, parce que on a du travail à l'unif, ou que on occupe ses temps libres autrement par moment. Il y a des période ou le projet sur lequel on travail ne compile même plus, car on a plus l'environnement de developpement complet.
Quand on a un peu de temps pour coder, on préfère parfois coder pour soi.
Quand on reçoi un patch, ça demande du travail.
Il faut lire le patch, ce qui peut prendre du temps, surtout s'il est gros.
En général, avec l'expérience qu'on a du projet on trouve facilement des morceau de code qui sont pas bon et qui devrais être corrigé. En plus de ça il y a nos préférences personnelles, qui fait que on aurais pas fait comme ça, et que ça correspond pas à notre mode de pensée.
Il faut aussi tester un minimum le patch avant de l'intégré, ce qui nécessite du temps, et un système qui fonctionne.
Rien que le fait d'appliquer le patch et de le commiter ça peut prendre un temps énnervant quand on a autre chose à faire.
Dans le cas d'une nouvelle fonctionalité, ça doit aussi se maintenir. Faire évoluer avec le reste du projet lorsque on change quelque chose, répondre au rapport de bugs, ....
Il m'est déjà arrivé d'enlever des fonctionalités apportées par des contributeurs externe car je n'avais pas envie de les maintenir et qu'ils ne répondait plus.
Parfois je reçois un patch à un momant ou je suis pas vraiment disponible. Je me dis que je dois y répondre, mais finalement ça traîne et j'oublie. "Tant pis".
Par contre, une personne qui a déjà envoyé quelques patches, à qui on a déjà fait de brève remarques pour lui apprendre un peu le fonctionnement du projet, et qui a l'air motivé, on est content de pouvoir lui donner un compte sur le gestionnaire de version de manière à ce qu'il développe avec nous. Quand le projet est suffisamment modulaire il est tout à fait possible de travailler à plusieurs sans se marcher sur les pieds.
Pour résumer, j'aime bien recevoir des patches, quand la personne qui l'envoi est motivée pour le maintenir. Mais il faut être patient quand on envoi un patch, ne pas avoir peur d'insister un peu, mais sans mettre le dev sous pression non plus. Le tout est une question de respect
[^] # Re: Contribution 'utilisateur'
Posté par Zakath (site web personnel) . Évalué à 4.
Sinon, je suis globalement d'accord avec ce que tu as dit, mais il ne faut pas non plus perdre de vue que les développeurs du libre ne sont (sauf rares exceptions) pas payés, alors qu'ils fournissent un travail. Pour accepter de faire bénévolement ce travail, il leur faut recevoir quelque chose en échange, et en règle générale, il s'agit de la reconnaissance de la communauté qu'ils font un bon travail. Enlève cette gratification là, et tout le libre se casse la figure. C'est pour ça qu'il est primordial de toujours remercier les contributions.
[^] # Re: Contribution 'utilisateur'
Posté par Anonyme . Évalué à 2.
Sisyphe n'est pas dans un trou
Arf, je me suis fait avoir avec la version d'Ulysse 31 ou la il est dans un trou :)
( http://www.dailymotion.com/relevance/search/Ulysse+31+sisyph(...) )
[^] # Re: Contribution 'utilisateur'
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
# Donner sans attendre en retour ...
Posté par Olivier Guerrier . Évalué à 7.
Parfois je tombe sur un truc qui ne me manque ou ne me convient pas, et parfois j'ai le temps (ou j'arrive à le prendre), et je code un peu. J'essaye de toujours poster ce que j'ai écrit, soit sur le site du projet, soit sur une liste de diffusion. Et puis en général je n'y pense plus.
Et une fois, quinze mois plus tard, je découvre par hasard en lisant le man sur une debian fraîchement installé qu'un de mes patchs a été intégré en upstream... Noël au printemps :D
Donc voilà, tout ça pour dire que ceux qui attendent quelque chose de leurs contributions seront forcément déçus si rien ne se passe, alors que si vous n'attendez rien, la surprise ne peux être que joyeuse.
(Et puis voir mon patch mergé par Theodore Ts'o avec quasi zéro modifs, ça me rassure un peu sur ma programmation en C...)
[^] # Re: Donner sans attendre en retour ...
Posté par Mat (site web personnel) . Évalué à 5.
Je ne poste pas mes modifications pour que les développeurs et utilisateurs se jettent à mes pieds en me congratulant.
Je tenais juste à souligner le fait qu'un petit mot, que ce soit en provenance des devs, des utilisateurs, d'autres contributeurs etc, est une superbe récompense tout à fait suffisante en ce qui me concerne.
sur quoi je te rejoins totalement.
# Mon point de vue comme mainteneur de projet
Posté par Julien Duponchelle (site web personnel) . Évalué à 7.
Par contre il ne faut pas s'étonné que parfois un patch mette du temps à être intégré dans le tronc. En effet intégrer un patch est une tache peut intérressante et qui a donc tendance à trainer.
Mais on rencontre de tout, certains projet sont vraiment déplaisant avec les contributeurs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.