[Question résolu] Le soldat Gimp en péril ?

mydjey · Le 02/01/2011, à 21:06

lawl a écrit :

Mais qui vous dit que c'est un problème de rémunération ?
GIMP est un vieux projet normal que les contributeurs passent à autre chose ou s'investisent moins.

C'est pas un problème directement lié à la rémunération. Mais comme tu le dis, sans doute au fait que le projet est ancien. Par contre, du côté utilisateur si on à envie que le projet avance ça devient un problème de rémunération, puisque le seul moyen de faire avancé un projet libre si on ne code pas c'est de payer des développeurs.

lawl a écrit :

De plus qui dit que si il n'était que 3 ce n'était pas voulu ? Combien de contributeur au niveau des patch ou plugin ?

D'après les liens fournis dans le premier postes de ce topic, ce n'est pas franchement voulu. J'ai également lu que la version Mac ne verrais pas le jour faute de dev. Je ne vois pas ce qu'il y'a de voulu dans tout ça.

Un dev français a participer au GSOC sur un projet portant sur Gimp, (voir ici). Mais si le core principal n'avance pas ça ne sert malheureusement pas à granche.

ehmicky · Le 02/01/2011, à 21:18

Ca me plairait de contribuer à ce projet, le problème, c'est que j'avais déjà regardé les sources un coup, et c'est vraiment costaud, en plus en C. Ca embarque une grosse partie de GNOME (GTK+, ATK, Cairo), OpenGL, et des bibliothèques telles que libjpeg, libpng, libexif, etc., ça fait beaucoup de dépendances.
D'un autre côté, je suis étonné parce que je pense que c'est typiquement le genre de projet (comme Blender) dont les développeurs libres aimeraient faire partie, c'est quand même plus intéressant qu'un logiciel de stéganographie ou une application de finances domestiques
Je me demande s'il y a pas des problèmes au niveau de la manière avec laquelle on peut contribuer : équipe de devs trop exigeantes, difficulté pour intégrer l'équipe, etc. ?

Dernière modification par ehmicky (Le 02/01/2011, à 21:20)

g_barthe · Le 02/01/2011, à 21:43

en même temps payer un dev si on fait le calcul ca fait quand meme une somme relativement important sur 1 année car je doute qu'il se contente de 100 € mensuel.

Peut être peut on demander aux dév qui ont quitté le projet pourquoi ils ont lachés le projet ?

ssdg · Le 02/01/2011, à 22:27

3. "Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."
- Linus Torvalds

http://www.junauza.com/2010/12/top-50-p … -time.html

lawl · Le 02/01/2011, à 22:29

Je ne vois pas ce qu'il y'a de voulu dans tout ça

Je n'émet que des supposition. Je n'en sais rien. Par contre je sais que j'ai parfois vue des projets libre relativement fermer car le/les dev principaux voulaient avoir la main sur la roadmap voir carrément maîtrisé complètement le code.
Mais cela a l'air différent avec GIMP mais depuis 4 ans :
http://developer.gimp.org/gimpcon/2006/ … developers
Rien a bouger de ce coter la !

Ca embarque une grosse partie de GNOME

Non c'est gnome qui importe GIMP
http://nicolasj.developpez.com/gtk/cour … e_1#LI-C-1

PS : le troisième dev n'a pas lâcher le projet, il ne s'en occupe plus quotidiennement ce qui est différent.

Dernière modification par lawl (Le 02/01/2011, à 22:30)

mydjey · Le 02/01/2011, à 22:45

Je suis tombé sur un lien intéressant sur le logiciel libre, l'argent, toussa :
Vendre des logiciels libres.

lawl · Le 02/01/2011, à 23:41

Toi tu es née avec les dernière pluie non ?

mydjey · Le 03/01/2011, à 12:32

lawl a écrit :

Toi tu es née avec les dernière pluie non ?

?

ehmicky · Le 03/01/2011, à 13:04

Franchement, je me pose la question de savoir si le fait que le projet soit en C ne freine pas certains devs plus à l'aise avec le C++ ou le Java par exemple. Un immense projet comme ça, avec une approche orientée objet mais en C, comme GIMP, me freine personnellement un peu. Après, bien sûr qu'il y a des gens qui sont justement plus à l'aise avec le C, je posais juste une hypothèse.

Dernière modification par ehmicky (Le 03/01/2011, à 13:05)

lawl · Le 03/01/2011, à 21:58

?

Ce que je veux dire c'est que cette page ou la différence entre gratuit et libre il n'y a que les nouveaux dans le libre qui ne les connaissent pas.

jypaigue · Le 04/01/2011, à 20:18

http://libregraphicsworld.org/news.php?readmore=675

Ça ne concerne pas directement le sujet de ce fil, mais il rappel néanmoins ceci : http://www.mail-archive.com/gimp-develo … 21261.html

Dernière modification par jypaigue (Le 04/01/2011, à 20:19)

jypaigue · Le 08/01/2011, à 00:29

http://www.gimpusers.com/news/00339-gim … q1-q2-2011

Un autre article sur le sujet...

kaoron · Le 08/01/2011, à 22:45

Lu un certain nombre de trucs qu'il faut corriger :

- 2,5 développeurs, c'est assez correct et tout à fait erroné à la fois. En réalité, il y a 2 développeurs principaux et une demi-douzaine de développeurs récurrents, et un certain nombre de personnes supplémentaires pour tester, traduire, documenter,. Tous font ça sur leur temps libre, pour faire un travail évalué à celui de 2,5 développeurs professionnels. Donc non, l'équipe de GIMP n'est pas restreinte à deux personnes et un homme-tronc, mais oui, elle est plutôt réduite par rapport aux besoins en développement et au rythme de chaque développeur.

- Les développeurs de GIMP ne veulent pas de développement rémunéré sur le projet, il me semble que c'est inexact. Au souvenir que j'ai d'une discussion sur la ML gimp-devel, c'est le pay-per-feature qui les fait tiquer. AKA une entreprise qui ferait développer une feature particulière sans s'impliquer dans le reste du projet. Un développeur à plein temps, sont pas contre.

Sven Neumann a écrit :

Having someone work on GIMP full-time is something entirely different
than paying for features. It has my full support. But I am afraid that
it will be extremely difficult to find someone capable and willing to do
this job. And it will be extremely difficult to find a company who is
willing to hire a developer and to let him/her work on GIMP full time.

http://lists.xcf.berkeley.edu/lists/gim … 24058.html

- gimp-painter : un développement de patches désynchronisé de GIMP, pas vraiment viable tant qu'ils ne s'impliquent pas dans le projet

- C, un frein pour les développeurs... peut-être, mais ça vaut mieux que Java. Pour avoir lu une bonne tranche du code de GIMP, de GEGL et de BABL, c'est moins le langage que le manque terrible de documentation technique qui freine. GIMP est un projet énorme, très modulaire, et bien que le code soit un des plus limpides que j'ai pu lire l'architecture du projet est sensiblement moins lisible.

- Pas de communauté soudée, ça c'est peut-être le plus gros problème. Le projet GIMP a une communauté éparse et très peu active, pas du tout au courant de son développement en dehors des électrons qui gravitent autour du canal IRC. Le truc, c'est que personne ne veut s'occuper du community management. Une fondation GIMP est parfois évoquée, mais personne ne veut le faire, et ce n'est certainement pas aux développeurs de délaisser leur activité pour s'occuper de maintenir la communauté. De même pour le site web, il manque cruellement d'un administrateur compétent dévoué à cette tâche. Là, il y a un hic.

Enfin la date donnée n'était aucunement une deadline, mais une estimation du temps que prendraient l'implémentation des fonctionnalités annoncées avec un travail abattu équivalent à celui de 2,5 développeurs, afin d'avoir une meilleure lisibilité sur les projets prioritaires et ceux à repousser. GIMP est un habitué des longs cycles de développement et des retards sur les prévisions. C'était pour ainsi dire prévu.

ehmicky · Le 08/01/2011, à 22:51

Effectivement pour ce qui est des 2,5 dévs, j'ai lu depuis des infos indiquant beaucoup plus de monde : seulement il s'agit aussi de testeurs, traducteurs, etc.

jypaigue · Le 09/01/2011, à 00:14

- Les développeurs de GIMP ne veulent pas de développement rémunéré sur le projet, il me semble que c'est inexact. Au souvenir que j'ai d'une discussion sur la ML gimp-devel, c'est le pay-per-feature qui les fait tiquer. AKA une entreprise qui ferait développer une feature particulière sans s'impliquer dans le reste du projet. Un développeur à plein temps, sont pas contre.

Ils ne sont (n'étaient) pas pour non plus : http://www.mail-archive.com/gimp-develo … 19423.html
Bon, enfin c'est compliqué... Le sujet a été abordé il y a peu : http://www.mail-archive.com/gimp-develo … 21378.html

- gimp-painter : un développement de patches désynchronisé de GIMP, pas vraiment viable tant qu'ils ne s'impliquent pas dans le projet

Non, mais il y a une rumeur qui cour comme quoi il serait susceptible de s'impliquer... Ça reste une rumeur. Certaines choses qu'il a fait seront vraisemblablement inclues dans la branche principale de GIMP.

- C, un frein pour les développeurs... peut-être, mais ça vaut mieux que Java. Pour avoir lu une bonne tranche du code de GIMP, de GEGL et de BABL, c'est moins le langage que le manque terrible de documentation technique qui freine. GIMP est un projet énorme, très modulaire, et bien que le code soit un des plus limpides que j'ai pu lire l'architecture du projet est sensiblement moins lisible.

Oui, j'ai entendu d'autres personnes se plaindre de la complexité de l'architecture de GIMP. (Pas de sources...) Une personne proposait d'ailleurs sur IRC d'utiliser le principe des Bounty pour rédiger la doc... (C'est à dire quelqu'un qui serait payé pour faire ça et que ça...). Mais je n'ai pas l'impression que ça ai été retenu...

Pour le reste : kaoron fait un joli résumé, merci.

Bat'al · Le 10/01/2011, à 17:40

Bonjour à tous,

Je suis le dev qui a fait un Summer of Code sur Gimp cet été.

J'aimerai juste rajouter quelques points au très bon résumé de Kaoron:
- Même si le langage est le C, qui est très connu et répandu, Gimp, comme une bonne partie des programmes GTK, utilise les GObject pour avoir de la programmation orienté objet. Et c'est beaucoup moins facile et répandu. Personnellement, j'ai eu beaucoup de mal à m'y mettre. Un bonne partie des gens qui utilisent les GObjects, moi y compris, ne maitrise pas ce qu'ils codent et procède par tâtonnement.

- L'architecture du code est très opaque, à cause du manque de documentation. Il faut parfois parcourir un fichier de 1000 lignes pour comprendre à quoi sert un objet (et les lires en détails pour comprendre comment l'utiliser). Quand j'ai demandé pourquoi il y avait aussi peu de doc, on m'a répondu que c'était comme ça dans le logiciel libre, qu'écrire de la doc est chiant. Pourtant, il faudrait pas forcement beaucoup de documentation pour rendre la tâche du nouveau développeur bien plus facile (quelques diagrammes de classe, un rapide résumé de ce que fait chaque objet, quelques exemples de codes ...).

- Les deux points précédents font que rentrer dans le code de Gimp pour un nouveau est une chose pas évidente. Et c'est un cercle vicieux. Plus c'est dur, moins il y a de dev. Moins il y a de dev, moins il y a de doc, ....

A contrario de la situation de Gimp, on voit du coté de Blender des développeurs qui n'hésitent pas à pondre des documentations de folie sur leur travail (il n'y a qu'a voir ça par exemple). Je pense que la présence de Ton Roosendaal à la tête de l'équipe ne doit pas être étrangère à la situation.

Dans tout les cas, si quelqu'un se sens de se lancer dans le code de Gimp, je suis près à l'aider. Je suis joignable sur IRC (gimp@irc.freenode.org, nick Bat`O).

Edit: au passage, ça m'a motivé pour taper un peu dans la fourmilière. On verra si ça donne quelque chose. Merci http://lists.xcf.berkeley.edu/lists/gim … 26031.html

Dernière modification par Bat'al (Le 10/01/2011, à 19:08)

mydjey · Le 10/01/2011, à 21:47

Merci pour vos deux interventions plus qu'intéressantes kaoron et Bat'al. Elles mériteraient un article complet.
Ces réponses clarifient grandement les choses.

Bat'al a écrit :

Quand j'ai demandé pourquoi il y avait aussi peu de doc, on m'a répondu que c'était comme ça dans le logiciel libre, qu'écrire de la doc est chiant.

Je ne suis pas développeurs mais j'ai tout le temps entendu dire et je comprend très bien, que bien documenter son code est une compétence primordial pour un développeur, et à fortiori pour un développeur de logiciel libre.

Quand vous parler de "documenter" le code c'est seulement le commenter à l'intérieur du code ou faire des docs externes ?

Si c'est un travail qui est fait au même moment que le code lui même, je ne pense pas que ce soit ci chiant que cela, par contre si c'est un boulot qui n'as jamais été fait et qu'il faut reprendre tout le code je conçoit que ça puisse ne pas être passionnant.

En gros c'est un peu paradoxale : Il faut des personnes ayant des compétences de développeurs pour faire un boulot qui n'est pas du développement à proprement dit.

En tout cas si tu as des nouvelles par rapport à tout ça, n'hésite pas à nous tenir au courant Bat'al...

ehmicky · Le 10/01/2011, à 21:56

mydjey a écrit :

Quand vous parler de "documenter" le code c'est seulement le commenter à l'intérieur du code ou faire des docs externes ?
Si c'est un travail qui est fait au même moment que le code lui même, je ne pense pas que ce soit ci chiant que cela, par contre si c'est un boulot qui n'as jamais été fait et qu'il faut reprendre tout le code je conçoit que ça puisse ne pas être passionnant.
En gros c'est un peu paradoxale : Il faut des personnes ayant des compétences de développeurs pour faire un boulot qui n'est pas du développement à proprement dit.

Tu as des applications qui permettent d'extraire le commentaire interne au code, et d'en faire une documentation : Doxygen par exemple.
Perso, je pense que commenter est un boulot de développeur, dans le sens où il est très difficile pour un non-développeur de commenter/documenter une API

Dernière modification par ehmicky (Le 10/01/2011, à 21:57)

Bat'al · Le 10/01/2011, à 22:15

mydjey a écrit :

Quand vous parler de "documenter" le code c'est seulement le commenter à l'intérieur du code ou faire des docs externes ?

C'est les deux en fait. C'est juste une question d'échelle.

A une echelle "locale", il faut des commentaires sur chaque fonction de ton code (a quoi sert la fonction, quels paramètres, ce qu'elle renvoie), pour completer automatiquement la documentation extraite du code. Un exemple dans mon code:

/**
 * gimp_cage_config_remove_last_cage_point:
 * @gcc: the cage config
 *
 * Remove the last point of the cage, in both source and destination cage
 */
void
gimp_cage_config_remove_last_cage_point (GimpCageConfig  *gcc)
{
  g_return_if_fail (GIMP_IS_CAGE_CONFIG (gcc));

  if (gcc->n_cage_vertices >= 1)
    gcc->n_cage_vertices--;

  gimp_cage_config_compute_scaling_factor (gcc);
  gimp_cage_config_compute_edges_normal (gcc);
}

Ce genre de commentaire va compléter automatiquement la documentation extraite du code: http://developer.gimp.org/api/2.0/app/GimpImageMap.html
Cette classe par exemple, n'est pas commenté, c'est donc pas du tout évident de comprendre ce qu'elle fait et comment l'utiliser.

A une plus grande échelle, il faut avoir de la doc qui donne une vue d'ensemble sur l'architecture du code. Quand on construit quelque chose qui doit s'intégrer à un ensemble plus gros, c'est bien de savoir où mettre les pieds. Sinon, c'est un peu comme se balader dans une mine sans plan. Pour cette échelle, on utilise des outils comme des diagrammes UML, des explications en texte, etc

mydjey · Le 10/01/2011, à 22:40

ehmicky a écrit :

Perso, je pense que commenter est un boulot de développeur, dans le sens où il est très difficile pour un non-développeur de commenter/documenter une API

Bien sûr c'est ce que je dis dans mon commentaire. Le bon sens élémentaire, voudrait même que ce soit la même personne qui code ET qui documente la partie du code qu'elle a écrit. C'est un manquement dans le cas de Gimp, faute de reprendre tout le code il pourrait au moins essayer d'établir un nouveau "code de conduite" (si j'ose dire ) pour le code à venir, ça serait déjà ça.

--

Bat'al > Ok pour les précisions. Dans ce cas précis ce n'est pas un travail sur le long terme, qu'il faut.
Ce que je veux dire : si une personne pouvait s'occuper de faire ce travail ingrat, il serait fait une bonne fois pour toute.
Ensuite il suffirait que les devs prennent l'habitude de documenter leur code et ce problème précis serait résolu.

A ton/votre avis et puisque personne ne semble vouloir le faire, est-ce imaginable/réaliste de rémunérer un développeur pour documenter le code de Gimp ?
(on parle donc d'une tache ponctuelle et bien définie).

jypaigue · Le 11/01/2011, à 18:54

A ton/votre avis et puisque personne ne semble vouloir le faire, est-ce imaginable/réaliste de rémunérer un développeur pour documenter le code de Gimp ?

Bat'al a posé la question (merci) et il y a des éléments de réponses : http://www.mail-archive.com/gimp-develo … 21403.html

ehmicky · Le 11/01/2011, à 19:23

[HS]"Michael Schumacher" contributeur de GIMP ? (en espérant qu'il fasse accélérer les choses )[/HS]

Dernière modification par ehmicky (Le 11/01/2011, à 19:24)

Rolinh · Le 11/01/2011, à 20:13

Bat'al a écrit :

- Même si le langage est le C, qui est très connu et répandu, Gimp, comme une bonne partie des programmes GTK, utilise les GObject pour avoir de la programmation orienté objet. Et c'est beaucoup moins facile et répandu. Personnellement, j'ai eu beaucoup de mal à m'y mettre. Un bonne partie des gens qui utilisent les GObjects, moi y compris, ne maitrise pas ce qu'ils codent et procède par tâtonnement.

Je me retrouve tout à fait dans cette description. A force de tâtonner, j'en venais à me demander si c'était normal... mais là ça me rassure!

david96 · Le 12/01/2011, à 01:38

É bé, grâce à ce fil de discussion, j'aurai appris beaucoup de chose sur le développement de GIMP…
Merci à kaoron et à Bat'al pour leurs éclaircissements.

Une zone d'ombre toutefois, qu'est-ce que le « pay-per-feature » ?

Un logiciel aussi connu et utilisé par des millions de personnes ne peut s'éteindre comme ça, j'ai espoir qu'une bonne nouvelle fasse surface.

Mais, ce n'est pas plus mal qu'il y ait ce problème finalement. Car comme beaucoup d'utilisateur, j'étais à 100 000 lieu de penser qu'un tel logiciel puisse rencontrer de problèmes d'effectifs. Le soulever ne fera qu'alerter l'immense communauté du logiciel libre.

À suivre…

jypaigue · Le 12/01/2011, à 07:11

Une zone d'ombre toutefois, qu'est-ce que le « pay-per-feature » ?

Pay-per-feature ou Bounty(ies) : c'est une façon de rémunérer localement un développeur ou une entreprise. Ce(tte) dernier(e) sera payé(e) pour réaliser une tâche bien précise et rien d'autre.

Dernière modification par jypaigue (Le 12/01/2011, à 07:22)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 02/01/2011, à 21:06

Re : [Question résolu] Le soldat Gimp en péril ?

#27 Le 02/01/2011, à 21:18

Re : [Question résolu] Le soldat Gimp en péril ?

#28 Le 02/01/2011, à 21:43

Re : [Question résolu] Le soldat Gimp en péril ?

#29 Le 02/01/2011, à 22:27

Re : [Question résolu] Le soldat Gimp en péril ?

#30 Le 02/01/2011, à 22:29

Re : [Question résolu] Le soldat Gimp en péril ?

#31 Le 02/01/2011, à 22:45

Re : [Question résolu] Le soldat Gimp en péril ?

#32 Le 02/01/2011, à 23:41

Re : [Question résolu] Le soldat Gimp en péril ?

#33 Le 03/01/2011, à 12:32

Re : [Question résolu] Le soldat Gimp en péril ?

#34 Le 03/01/2011, à 13:04

Re : [Question résolu] Le soldat Gimp en péril ?

#35 Le 03/01/2011, à 21:58

Re : [Question résolu] Le soldat Gimp en péril ?

#36 Le 04/01/2011, à 20:18

Re : [Question résolu] Le soldat Gimp en péril ?

#37 Le 08/01/2011, à 00:29

Re : [Question résolu] Le soldat Gimp en péril ?

#38 Le 08/01/2011, à 22:45

Re : [Question résolu] Le soldat Gimp en péril ?

#39 Le 08/01/2011, à 22:51

Re : [Question résolu] Le soldat Gimp en péril ?

#40 Le 09/01/2011, à 00:14

Re : [Question résolu] Le soldat Gimp en péril ?

#41 Le 10/01/2011, à 17:40

Re : [Question résolu] Le soldat Gimp en péril ?

#42 Le 10/01/2011, à 21:47

Re : [Question résolu] Le soldat Gimp en péril ?

#43 Le 10/01/2011, à 21:56

Re : [Question résolu] Le soldat Gimp en péril ?

#44 Le 10/01/2011, à 22:15

Re : [Question résolu] Le soldat Gimp en péril ?

#45 Le 10/01/2011, à 22:40

Re : [Question résolu] Le soldat Gimp en péril ?

#46 Le 11/01/2011, à 18:54

Re : [Question résolu] Le soldat Gimp en péril ?

#47 Le 11/01/2011, à 19:23

Re : [Question résolu] Le soldat Gimp en péril ?

#48 Le 11/01/2011, à 20:13

Re : [Question résolu] Le soldat Gimp en péril ?

#49 Le 12/01/2011, à 01:38

Re : [Question résolu] Le soldat Gimp en péril ?

#50 Le 12/01/2011, à 07:11

Re : [Question résolu] Le soldat Gimp en péril ?

Pied de page des forums