Discussion :

[koala01]

Je proposerai à tout le monde de respirer un bon coup et de se calmer, car, si je dois encore user de mon droit de modération (et tout semble parti pour), cela va m'énerver moi, et je risque de demander à l'équipe modération de sévir.

Sans blague, je m'absente une petite journée et les phrases assassines refont leur apparition alors que j'ai valablement prévenu les gens concerné lors de ma première tentative de calmer le jeu (les personnes concernées se reconnaitront).

Ceci dit, Louis, il faut comprendre comment cela fonctionne en pratique, même si dams semble avoir quelque mal à l'exprimer clairement.

Reprenons tout depuis le début.

1- un bug est transmis via le "bugtracker" du projet par la personne qui en a fait l'amère expérience.

2- Tout le monde (toi y compris) a un acces en lecture sur le système de gestion de version concurrentes (SVN, CVS, Mercurial ou autre) et peut donc récupérer le code source originel.

3- N'importe qui peut modifier le code qu'il a récupéré, pour résoudre le problème transmis en [1], pour résoudre un problème qu'il aurait lui-même remarqué ou, pourquoi pas, pour ajouter une fonctionnalité qui n'a pas (encore) été acceptée par le projet.

4- Toute personne ayant modifié le code peut proposer la version modifiée au téléchargement sous réserve de le faire sous la même licence, de fournir le code modifié, et d'indiquer le site du projet originel.

5- Toute personne ayant modifié le code peut proposer un patch à l'équipe du projet

6- un patch proposé par un membre extérieur à l'équipe de développement sera validé et contrôlé avant d'être appliqué à la version de production (et passera sans doute par un trunk, après une première analyse)

7- l'équipe de développement seule a accès en écriture sur le système de gestion de version concurrente.

8- Un membre de l'équipe de développement peut proposer ses modifications du code directement sur le système de gestion de versions concurrentes, MAIS cela se fait sur un "trunk" et non sur la version "de production", de manière à permettre une vérification en profondeur de la viabilité de la modification.

9- En tout état de cause, un retour en arrière est toujours possible grâce au système de version concurrente si, d'aventure, une modification venait à occasionner plus de problèmes qu'elle n'en résout.

Tu constates, Louis, que le processus de validation et la gestion des modifications se fait exactement de la même manière que dans n'importe quelle équipe travaillant sur un code fermé au niveau de l'équipe en charge du projet.

La seule différence tenant, encore une fois, au fait qu'un grand nombre de gens ne faisant pas partie de l'équipe de développement "officielle" peuvent proposer des solutions auxquelles l'équipe "officielle" n'aurait peut être pas pensé (ou auxquelles elle aurait pu penser après un délais plus ou moins long).

Il y a de fortes chances que le développeur qui prétend ne jamais faire d'erreur soit un menteur (ou qu'on ne lui ait jamais fait remarqué ses erreurs s'il en est réellement convaincu), car l'erreur est humaine.

Mais on dit aussi qu'il y a toujours plus dans deux têtes que dans une.

Et c'est là la grande force des projets open-source: plutôt que de se limiter à une dizaine ou une quinzaine de têtes, le projet est susceptible d'obtenir des idées de... n'importe quel tête appartenant à l'un des six milliards d'être humains vivant actuellement.

Même en retirant ceux qui n'entravent que dalle au développement et les petits zigotos qui ont à peine lu un tutorial mal fait mais qui se croient pourtant devenus un crack, cela fait encore beaucoup plus de monde que n'importe quelle société, aussi grande et puissante soit-elle, sera susceptible de regrouper autour de n'importe quel projet

[Louis Griffont]

Bonjour koala01,

Je constate que le fonctionnement que tu décris est bien celui que j'estimais être, d'un projet Open-Source, ce qui me rassure.

Et me fait maintenir, qu'il n'y a donc aucune raison qu'une correction soit plus rapidement corrigé (et j'entends par corriger le principe suivant : mise en évidence, étude, correction logiciel, tests, et déploiement), que dans le monde fermé.

Le fait qu'un plus grand nombre de développeurs (ou tout du moins un nombre indéterminé et supposé considérable - je pense qu'il est difficile d'estimer réellement le chiffre) ayant accès au code source puisse permettre une mise en évidence des problèmes plus rapide, la suite peut par contre être plus lente, ou tout du moins pas plus rapide. Je m'explique, car je sens déjà venir la controverse. Mettons un bug dans un logiciel libre. Admettons que 100 développeurs se penchent dessus et trouvent une correction. Les 100 développeurs remontent leur correction à l'équipe du projet. Cette équipe à donc 100 corrections à vérifier, à étudier, et un patch à créer et tester.

Vous avez le droit de penser que c'est plus rapide, mais je n'en suis pas sûr. Ce qui peut être plus rapide, c'est la mise à disposition des mises à jour (la distribution d'une version corrigée) une fois toutes les étapes de corrections réalisées, car les éditeurs ont des politiques bien établies pour ces mises à jour.

[dams78]

Bonjour koala01,

Je constate que le fonctionnement que tu décris est bien celui que j'estimais être, d'un projet Open-Source, ce qui me rassure.

Et me fait maintenir, qu'il n'y a donc aucune raison qu'une correction soit plus rapidement corriger (et j'entends par corriger le principe suivant : mise en évidence, étude, correction logiciel, tests, et déploiement), que dans le monde fermé.

Le fait qu'un plus grand nombre de développeurs (ou tout du moins un nombre indéterminé et supposé considérable - je pense qu'il est difficile d'estimer réellement le chiffre) ayant accès au code source puisse permettre une mise en évidence des problèmes plus rapide, la suite peut par contre être plus lente, ou tout du moins pas plus rapide. Je m'explique, car je sens déjà venir la controverse. Mettons un bug dans un logiciel libre. Admettons que 100 développeurs se penchent dessus et trouvent une correction. Les 100 développeurs remontent leur correction à l'équipe du projet. Cette équipe à donc 100 corrections à vérifier, à étudier, et un patch à créer et tester.

Vous avez le droit de penser que c'est plus rapide, mais je n'en suis pas sûr. Ce qui peut être plus rapide, c'est la mise à disposition des mises à jour (la distribution d'une version corrigée) une fois toutes les étapes de corrections réalisées, car les éditeurs ont des politiques bien établies pour ces mises à jour.

Et pourquoi dans ton exemple tu ne prendrai pas qu'une version corrigée au lieu de te taper les 100, si une seule fonctionne? D'ailleurs au fil du temps, l'équipe de développement sait très bien quel développeur fait du bon boulot, elle peut donc regarder sa solution en premier, et si elle fonctionne l'adopter.

[Louis Griffont]

Et pourquoi dans ton exemple tu ne prendrai pas qu'une version corrigée au lieu de te taper les 100, si une seule fonctionne? D'ailleurs au fil du temps, l'équipe de développement sait très bien quel développeur fait du bon boulot, elle peut donc regarder sa solution en premier, et si elle fonctionne l'adopter.

Je dirais : par déontologie, par honnêteté vis à vis des 99 autres qui ont bossé, et aussi qu'on ne peut savoir quelle est la meilleure, si l'on en a testé qu'une.
Maintenant, tu as également raison. La première qui arrive et qui fonctionne est retenue et les autres négligées.

[bioinfornatics]

bah en générale on évitait que 100 gard font le même boulout c'est pour ça qu'avec un bug tracker on peut assigner le bug a une personne. Cette personne discute également pour se renseigner sur le bug et les possibilités pour corriger le souci.

[koala01]

De plus, il ne faut pas oublier la puissance d'un outil qui est régulièrement sous employé dans les projets fermés: la COM-MU-NI-CA-TION.

Avant que tu ne me jettes des pierres, je précise que ce n'est pas le cas partout, mais il arrive régulièrement que les gens agissent littéralement comme des handicapés dans ce domaine, et que seules quelques personnes soient au courent de l'ensemble des tenants et des aboutissants.

Dans les projets open-source, les systèmes de gestion de versions concurrentes, les timeline, les "features requests", les todo lists et les bugtrackers représentent une part importante des outils utilisés.

Mais les outils les plus importants sont sans doute les chats, fora, canaux IRC et autre liste de diffusion.

S'il est vrai que certaines décisions sont prises en "petit comité" (comprend: au niveau de l'équipe de développement "officielle"), il y a systématiquement un système de discussion sur lequel les intervenants "ponctuels" peuvent exposer leurs problèmes, poser leurs questions ou se tenir au courant de l'évolution des travaux.

Même sans intervenir lui-même sur l'un de ces canaux de diffusion publique, n'importe qui peut se faire une idée précise de ce que les autres font ou de ce sur quoi ils planchent.

Il peut donc assez facilement déterminer si "cela vaut la peine" qu'il s'intéresse à un problème donné ou si, au contraire, "les autres" sont à son avis sur la bonne voie.

Le mieux, c'est qu'à la limite, s'il a l'impression qu'ils "partent dans une mauvaise direction", il peut parfaitement essayer de défendre son point de vue.

Ce genre de communication est souvent rare dans les projets fermés (bien que certains aient, effectivement, élevé la com au rang de religion ), mais est quasi systématique dans les projets open source.

Et c'est quelque part là que réside la force de ces derniers.

PS: quand je parle de communication, je ne parle pas de la comm à saveur de marketting, mais bel et bien de la comm qui permet de faire surgir les idées par la saine émulation qui peut apparaitre dans un groupe dans lequel chaque voix est entendue

[Louis Griffont]

koala01, tu es en train de me dire que les projets Open-source sont biens ?

Mais, en doutais-je un seul instant ?

Je ne doute absolument pas que les projets Open-Source sont structurés, suivis et parfaitement maîtrisés par une équipe motivée et compétente. Et que le fonctionnement du développement, et du suivi soit très proche au final, de celui des éditeurs de logiciels propriétaires.

Et donc, j'en reviens toujours au même. En quoi, un tel fonctionnement permet des mise à dispositions de corrections plus rapide que dans le monde des éditeurs ? Le nombre de développeurs pouvant apporter leur contribution est plus important, mais au final, le temps est incompressible.

[bioinfornatics]

pour savoir ce qu'est l'open source une vidéo, disponible a partir de ce lien:
- http://dl.free.fr/getfile.pl?file=/oAJgSQPf