Posté par arnaudus .
En réponse au journal Arrêt d'Elveos.org.
Évalué à 7.
Dernière modification le 28 février 2012 à 09:52.
Je n'ai aucune expérience dans le domaine, mais j'ai l'impression (peut-être un peu naïve) qu'il y a quand même beaucoup de positivisme un peu forcé dans le monde du libre sur ce type de modèle de financement. Certes, a priori comme ça ça parait attractif, mais dans les faits, ça donne quoi? Il y a tellement de problèmes potentiels que ça me fait froid dans le dos rien que d'y penser.
En clair, comment filtrer les propositions, comment évaluer le montant attribué à chaque tâche, et comment évaluer la qualité du travail accompli? L'implémentation d'une fonction ou la correction d'un bug critique n'a de sens que si elle est intégrée uptream (ou au pire sous la forme d'un module comme dans Firefox), mais ça peut ne pas dépendre du développeur. Si le patch n'est pas intégré, qui va le maintenir, qui va s'amuser à compiler les sources pour publier un binaire de temps en temps?
Je me demande aussi comment gérer le processus de développement lui-même. Est-ce que les développeurs sont mis en compétition (ce qui aurait l'avantage d'obtenir plusieurs implémentations à comparer pour ne garder que la meilleure), ou y a-t-il un moyen de privilégier le travail collaboratif? Comment empêcher le financement a posteriori (le dev a déja implémenté la fonction, il essaye juste de monnayer son boulot), qui ne semble pas dans l'esprit du projet?
Sur le plan du fonctionnement, je pense que je préfère les Google Summer truc machin. Ce mode de fonctionnement a l'avantage de sembler plus sain sur le plan du droit du travail (on paye une sorte de salaire sur les mois pendant lesquels le projet est développé, on ne paye pas à la tâche), le principe est d'aider les jeunes à s'insérer dans le monde professionnel du logiciel libre, et surtout les projets viennent d'en haut, ce qui maximise la probabilité que le boulot soit réellement souhaité par les développeurs du projet, et si le code est correct, il y a de fortes chances pour qu'il soit intégré.
# Expérience
Posté par arnaudus . En réponse au journal Arrêt d'Elveos.org. Évalué à 7. Dernière modification le 28 février 2012 à 09:52.
Je n'ai aucune expérience dans le domaine, mais j'ai l'impression (peut-être un peu naïve) qu'il y a quand même beaucoup de positivisme un peu forcé dans le monde du libre sur ce type de modèle de financement. Certes, a priori comme ça ça parait attractif, mais dans les faits, ça donne quoi? Il y a tellement de problèmes potentiels que ça me fait froid dans le dos rien que d'y penser.
En clair, comment filtrer les propositions, comment évaluer le montant attribué à chaque tâche, et comment évaluer la qualité du travail accompli? L'implémentation d'une fonction ou la correction d'un bug critique n'a de sens que si elle est intégrée uptream (ou au pire sous la forme d'un module comme dans Firefox), mais ça peut ne pas dépendre du développeur. Si le patch n'est pas intégré, qui va le maintenir, qui va s'amuser à compiler les sources pour publier un binaire de temps en temps?
Je me demande aussi comment gérer le processus de développement lui-même. Est-ce que les développeurs sont mis en compétition (ce qui aurait l'avantage d'obtenir plusieurs implémentations à comparer pour ne garder que la meilleure), ou y a-t-il un moyen de privilégier le travail collaboratif? Comment empêcher le financement a posteriori (le dev a déja implémenté la fonction, il essaye juste de monnayer son boulot), qui ne semble pas dans l'esprit du projet?
Sur le plan du fonctionnement, je pense que je préfère les Google Summer truc machin. Ce mode de fonctionnement a l'avantage de sembler plus sain sur le plan du droit du travail (on paye une sorte de salaire sur les mois pendant lesquels le projet est développé, on ne paye pas à la tâche), le principe est d'aider les jeunes à s'insérer dans le monde professionnel du logiciel libre, et surtout les projets viennent d'en haut, ce qui maximise la probabilité que le boulot soit réellement souhaité par les développeurs du projet, et si le code est correct, il y a de fortes chances pour qu'il soit intégré.