Tu as raison, et c'est aussi ce que dit en un sens Pierre-Alain TORET dans le commentaire du dessus. C'est un système bien plus acceptable et proche de ce que je recherche. D'ailleurs j'en ai déjà fait (en quelque sorte) aussi. Quand j'ai accepté de travailler pour le CNRS notamment, c'était bien parce que je pouvais travailler sur GIMP.
Ça reste néanmoins un truc qui peut potentiellement nous éloigner de nos plans. Quand une organisation nous demande une fonctionnalité précise, si on a de la chance, c'est quelque chose qu'on voulait vraiment faire nous-même de toutes façons. Mais peut-être pas, et alors, cela repousse de quelques semaines tout le reste. Potentiellement cela repousse la maintenance elle-même (si on a des deadlines avec des malus de retard, finir la fonctionnalité devient soudainement plus important que corriger les bugs ou faire la revue de code des autres contributeurs). Cela peut aussi repousser d'autant la sortie suivante du logiciel. À l'inverse, j'ai mis en pause plusieurs branches de fonctionnalités, certaines d'autres contributeurs et certaines de moi-même, alors que ce sont de vraiment super trucs que plein attendent; mais justement parce qu'à un moment, si on veut sortir GIMP 3.0, faut qu'on arrête de faire des à-côtés pour finir les bases (j'ai donc fait un choix sain de maintenance et de stabilité plutôt que de privilégier de nouvelles fonctionnalités à tout prix). Ce n'est pas quelque chose qu'on peut faire si on est payé pour bosser sur la fonctionnalité, qui retarderait toute une sortie pour des millions de personnes. Et aussi les choix techniques deviennent des choix commerciaux (ce qui pourrait même conduire à de mauvais choix dans les cas extrêmes).
Alors je dis pas que c'est entièrement mal, et je suis prêt à refaire ce genre d'accord (par contre, uniquement si cela rentre dans la case des choix techniques acceptables). Mais cela reste tout de même bien moins sain que simplement "payer le développement car ça marche bien". Idéalement même faire les 2: payer des fonctionnalités en plus de financer en partie le développement courant (en fait l'idéal-idéal, c'est même: financer le développement courant + payer ses propres développeurs pour contribuer de nouvelles fonctionnalités adaptées à son business).
C'est ce qu'on propose avec nos financements participatifs, c'est aussi ce que fait Blender (avec le succès que l'on sait depuis fin 2018, voire 2019, où a débuté une progression fulgurante de leurs financements). Ça peut donc exister puisque ça se fait déjà. Perso c'est ce que je veux pousser le plus. 😇
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Sponsors institutionnels ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP fête ses 27 ans avec la version de développement 2.99.14. Évalué à 8.
Tu as raison, et c'est aussi ce que dit en un sens Pierre-Alain TORET dans le commentaire du dessus. C'est un système bien plus acceptable et proche de ce que je recherche. D'ailleurs j'en ai déjà fait (en quelque sorte) aussi. Quand j'ai accepté de travailler pour le CNRS notamment, c'était bien parce que je pouvais travailler sur GIMP.
Ça reste néanmoins un truc qui peut potentiellement nous éloigner de nos plans. Quand une organisation nous demande une fonctionnalité précise, si on a de la chance, c'est quelque chose qu'on voulait vraiment faire nous-même de toutes façons. Mais peut-être pas, et alors, cela repousse de quelques semaines tout le reste. Potentiellement cela repousse la maintenance elle-même (si on a des deadlines avec des malus de retard, finir la fonctionnalité devient soudainement plus important que corriger les bugs ou faire la revue de code des autres contributeurs). Cela peut aussi repousser d'autant la sortie suivante du logiciel. À l'inverse, j'ai mis en pause plusieurs branches de fonctionnalités, certaines d'autres contributeurs et certaines de moi-même, alors que ce sont de vraiment super trucs que plein attendent; mais justement parce qu'à un moment, si on veut sortir GIMP 3.0, faut qu'on arrête de faire des à-côtés pour finir les bases (j'ai donc fait un choix sain de maintenance et de stabilité plutôt que de privilégier de nouvelles fonctionnalités à tout prix). Ce n'est pas quelque chose qu'on peut faire si on est payé pour bosser sur la fonctionnalité, qui retarderait toute une sortie pour des millions de personnes. Et aussi les choix techniques deviennent des choix commerciaux (ce qui pourrait même conduire à de mauvais choix dans les cas extrêmes).
Alors je dis pas que c'est entièrement mal, et je suis prêt à refaire ce genre d'accord (par contre, uniquement si cela rentre dans la case des choix techniques acceptables). Mais cela reste tout de même bien moins sain que simplement "payer le développement car ça marche bien". Idéalement même faire les 2: payer des fonctionnalités en plus de financer en partie le développement courant (en fait l'idéal-idéal, c'est même: financer le développement courant + payer ses propres développeurs pour contribuer de nouvelles fonctionnalités adaptées à son business).
C'est ce qu'on propose avec nos financements participatifs, c'est aussi ce que fait Blender (avec le succès que l'on sait depuis fin 2018, voire 2019, où a débuté une progression fulgurante de leurs financements). Ça peut donc exister puisque ça se fait déjà. Perso c'est ce que je veux pousser le plus. 😇
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]