La perfection, c'est beaucoup demander... contentons nous de l'excellence. ;)
Blague à part, pour rentrer dans ton raisonnement, cette "excellence" perçu reposerai sur tous les contributeurs. En premier lieu l'équipe de developpement (leader, developpeurs, artistes...) bien sur, mais également le 2eme cercle (projets/librairies connexes utilisés, distro/packageurs...) et le 3eme cercle (utilisateurs, presse...). Le 3 eme cercle est tres important, car non seulement il peut faire le succès du produit, mais l'utilisateur est le contributeur de demain (1er ou 2eme cercle)
À partir de là, soit les moyens suivent derrière, soit ils ne suivent pas. Soit le modèle du libre est capable de fournir les moyens de la perfection, soit il ne l'est pas.
Les moyens ne sont pas figés: Le modèle du libre semble pouvoir potentiellement fournir ces moyens dans la plupart des applications grand public, et qui fonctionne par amélioration successive, ce qui exclue:
- Les jeux à scénario (genre qui se fini en 6-8h et qu'on ne retouche plus ensuite)
- Applications pro spécialisé et pointu
mais cela inclue lecteur/editeur texte, video, photo, navigateur internet, ...)
Mais effectivement tous n'y arrivent pas. Et cela semble tenir à pas mal de paramettres: buzz du projet, choix techniques, ambiance dans l'équipe, prise de décision (dictateur bienveillant/malveillant, consensus...), accueil des nouveaux contributeurs, ( ....).... et pour rajouter encore de la complexité, les recettes qui marche dépendent du contexte, de l'appli ...
Mais ce que je constate, c'est que dans certains cas ça marche, et d'autres non. Voir même quelques changements/décisions font passer un projet du bon coté: mozilla Vs Firefox, xfree86 Vs xorg... et pourtant, je me souviens qu'a l'époque de xfree86, on justifiait (moi y compris) l'archaïsme et la très lente évolution de xfree par la difficulté de trouver des développeurs assez compétant pour bosser sur un serveur X. Le changement impressionnant après le fork à démontré que le problème n'était pas au niveau des ressources...
Maintenant, un fork est un cas extreme, mais il y a aussi des changements différents. Comme le changement kicker vers plasma. L'équipe de dev a considérablement grossi, les contributions externe sont devenu possible.... tout à changé... Mais au prix d'un investissement considérable du leader, en plus de ses qualités personnelles. Sur les jeux KDE aussi, il y a eu un avant/apres, et j'y ai vu de près que non, les moyens ne sont pas constants du tout, mais il faut aller les chercher. Et que la différence entre le succès et l'échec se joue à peu de chose.
Exemple: Gof, développeur très méritant de Kopete, m'a raconté une fois qu'il y avait un développeur qui pourrissait tellement l'ambiance que 2 gas avaient quitté la team, et que lui-même avait failli partir. Heureusement, le "pourrisseur" est parti avant. Je suis arrivé juste après, et j'y ai découvert une équipe très sympathique, compétente et accueillante. Du coup, j'y ai pris plaisir, grace à Gof au passage, et plus tard, j'ai encouragé d'autres personnes talentueuses à rejoindre KDE... l'effet papillon. Dans le bon sens cette fois ci, mais ça aurait pu être l'inverse.
Voilà comment 1 gas, même pas leader, peut faire aller les choses dans le mauvais sens. Imagine ensuite pire, un leader sans vision qui refuse les patchs et les nouveaux contributeurs...
"Donc la question se pose, si Gimp n'est pas parfait, à qui la faute ?"
J'en sais rien, pour avoir un vrai avis, faudrait lire les mailing lists, lRC, proposer des patchs bien foutu et voir s'ils sont acceptés avec compliments et compte SVN en prime (ce qui s'est passé pour moi chez KDE), ou refusé sous un prétexte bidon.
Je ne sais pas ce qui se passe chez gimp, je ne peux faire que des constatations et des suppositions. Mais si je prends Inskcape et Gimp, 2 logiciels que j'utilise bcp, depuis des années, à la fois au travail et à la maison:
Au niveau du 3eme cercle
- The Gimp a un net avantage d'utilisateur et de notoriété (http://www.googlefight.com/index.php?lang=fr_FR&word1=gi(...) par exemple)
- The Gimp a un avantage au niveau historique également
Le tout donne un meilleur potentiel de ressource
Au niveau du 2 eme cercle:
- Les 2 se base sur GTK (et on peut pas dire que GTK soit inconnu de Gimp...)
- Les distro traitent équitablement les 2, voir package par defaut gimp alors que Inkscape est en option (sur Suse)
Et au final, c'est étonnement Inkscape qui évolue tres vite, dans le sens de ce que veulent les gens, avec des roadmap prévu, et suivis (http://wiki.inkscape.org/wiki/index.php/Roadmap ). A coté, Gimp semble stagner ou avoir stagné pendant des années, et refusé des demandes aussi basiques que les dossiers de calques. Cela me fait penser qu'il y a un problème dans l'équipe de dev (organisation, personnes, architecture...)... quelque chose ne colle pas ou n'a pas collé pendant longtemps.
Il serait même intéressant d'avoir des statistiques comparatives (nombre de commit, nombre de commiteur, turn over, évolution de ceci dans le temps, demande de fonctionnalités clos après rejet & acceptation... ).
Alors après, c'est à l'équipe de Gimp de voir.... Peut-etre que le pb est résolu et qu'on en verra les effets plus tard, ou qu'il est toujours là à pourrir le projet.
Alors, loin de moi l'idée d'insulter qui que ce soit, et surtout pas une équipe de développement OSS, et encore moins sans savoir ce qui s'y passe (ambiance, bébé ou décès, ...) . Mais je n'accepte pas trop la politique de l'autruche, et préfère largement l'attitude de Aaron Seigo, qui a humblement et publiquement analysé les problèmes de Kicker, avant d'y remédier, ou celle de Keith Packard, qui a affronté la pire situation qui soit, celle dite du "dictateur malveillant".
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Suite de "Ce qui manque à GNU/LINUX........ Évalué à 8.
Blague à part, pour rentrer dans ton raisonnement, cette "excellence" perçu reposerai sur tous les contributeurs. En premier lieu l'équipe de developpement (leader, developpeurs, artistes...) bien sur, mais également le 2eme cercle (projets/librairies connexes utilisés, distro/packageurs...) et le 3eme cercle (utilisateurs, presse...). Le 3 eme cercle est tres important, car non seulement il peut faire le succès du produit, mais l'utilisateur est le contributeur de demain (1er ou 2eme cercle)
À partir de là, soit les moyens suivent derrière, soit ils ne suivent pas. Soit le modèle du libre est capable de fournir les moyens de la perfection, soit il ne l'est pas.
Les moyens ne sont pas figés: Le modèle du libre semble pouvoir potentiellement fournir ces moyens dans la plupart des applications grand public, et qui fonctionne par amélioration successive, ce qui exclue:
- Les jeux à scénario (genre qui se fini en 6-8h et qu'on ne retouche plus ensuite)
- Applications pro spécialisé et pointu
mais cela inclue lecteur/editeur texte, video, photo, navigateur internet, ...)
Mais effectivement tous n'y arrivent pas. Et cela semble tenir à pas mal de paramettres: buzz du projet, choix techniques, ambiance dans l'équipe, prise de décision (dictateur bienveillant/malveillant, consensus...), accueil des nouveaux contributeurs, ( ....).... et pour rajouter encore de la complexité, les recettes qui marche dépendent du contexte, de l'appli ...
Mais ce que je constate, c'est que dans certains cas ça marche, et d'autres non. Voir même quelques changements/décisions font passer un projet du bon coté: mozilla Vs Firefox, xfree86 Vs xorg... et pourtant, je me souviens qu'a l'époque de xfree86, on justifiait (moi y compris) l'archaïsme et la très lente évolution de xfree par la difficulté de trouver des développeurs assez compétant pour bosser sur un serveur X. Le changement impressionnant après le fork à démontré que le problème n'était pas au niveau des ressources...
Maintenant, un fork est un cas extreme, mais il y a aussi des changements différents. Comme le changement kicker vers plasma. L'équipe de dev a considérablement grossi, les contributions externe sont devenu possible.... tout à changé... Mais au prix d'un investissement considérable du leader, en plus de ses qualités personnelles. Sur les jeux KDE aussi, il y a eu un avant/apres, et j'y ai vu de près que non, les moyens ne sont pas constants du tout, mais il faut aller les chercher. Et que la différence entre le succès et l'échec se joue à peu de chose.
Exemple: Gof, développeur très méritant de Kopete, m'a raconté une fois qu'il y avait un développeur qui pourrissait tellement l'ambiance que 2 gas avaient quitté la team, et que lui-même avait failli partir. Heureusement, le "pourrisseur" est parti avant. Je suis arrivé juste après, et j'y ai découvert une équipe très sympathique, compétente et accueillante. Du coup, j'y ai pris plaisir, grace à Gof au passage, et plus tard, j'ai encouragé d'autres personnes talentueuses à rejoindre KDE... l'effet papillon. Dans le bon sens cette fois ci, mais ça aurait pu être l'inverse.
Voilà comment 1 gas, même pas leader, peut faire aller les choses dans le mauvais sens. Imagine ensuite pire, un leader sans vision qui refuse les patchs et les nouveaux contributeurs...
"Donc la question se pose, si Gimp n'est pas parfait, à qui la faute ?"
J'en sais rien, pour avoir un vrai avis, faudrait lire les mailing lists, lRC, proposer des patchs bien foutu et voir s'ils sont acceptés avec compliments et compte SVN en prime (ce qui s'est passé pour moi chez KDE), ou refusé sous un prétexte bidon.
Je ne sais pas ce qui se passe chez gimp, je ne peux faire que des constatations et des suppositions. Mais si je prends Inskcape et Gimp, 2 logiciels que j'utilise bcp, depuis des années, à la fois au travail et à la maison:
Au niveau du 3eme cercle
- The Gimp a un net avantage d'utilisateur et de notoriété (http://www.googlefight.com/index.php?lang=fr_FR&word1=gi(...) par exemple)
- The Gimp a un avantage au niveau historique également
Le tout donne un meilleur potentiel de ressource
Au niveau du 2 eme cercle:
- Les 2 se base sur GTK (et on peut pas dire que GTK soit inconnu de Gimp...)
- Les distro traitent équitablement les 2, voir package par defaut gimp alors que Inkscape est en option (sur Suse)
Et au final, c'est étonnement Inkscape qui évolue tres vite, dans le sens de ce que veulent les gens, avec des roadmap prévu, et suivis (http://wiki.inkscape.org/wiki/index.php/Roadmap ). A coté, Gimp semble stagner ou avoir stagné pendant des années, et refusé des demandes aussi basiques que les dossiers de calques. Cela me fait penser qu'il y a un problème dans l'équipe de dev (organisation, personnes, architecture...)... quelque chose ne colle pas ou n'a pas collé pendant longtemps.
Il serait même intéressant d'avoir des statistiques comparatives (nombre de commit, nombre de commiteur, turn over, évolution de ceci dans le temps, demande de fonctionnalités clos après rejet & acceptation... ).
Alors après, c'est à l'équipe de Gimp de voir.... Peut-etre que le pb est résolu et qu'on en verra les effets plus tard, ou qu'il est toujours là à pourrir le projet.
Alors, loin de moi l'idée d'insulter qui que ce soit, et surtout pas une équipe de développement OSS, et encore moins sans savoir ce qui s'y passe (ambiance, bébé ou décès, ...) . Mais je n'accepte pas trop la politique de l'autruche, et préfère largement l'attitude de Aaron Seigo, qui a humblement et publiquement analysé les problèmes de Kicker, avant d'y remédier, ou celle de Keith Packard, qui a affronté la pire situation qui soit, celle dite du "dictateur malveillant".
PS: désolé pour le roman ;)