19-11-18, 10:18
De mon côté, je très frileux a l'idée d'un fork.
Déjà, parce que je pense qu'il ne faut pas sous-estimer l'importance de la compatibilité entre versions. On parle d'un éditeur non-destructif : avec darktable, on ne sauvegarde pas le résultat de la retouche, mais le moyen d'y arriver. Donc, sans un darktable qui sache le lire et l'appliquer à un raw, un .xmp n'est pas exploitable. Si darktable fait des changements incompatibles, ce sont les centaines d'images traitées avec les vielles versions qui sont à mettre à la poubelle. Alors OK, je pourrais toujours installer un vieux darktable pour reprendre ces traitements, mais combien de temps le vieux darktable sera-t-il installable et utilisable ? Vu la quantité de dépendances de darktable, il ne faut pas s'attendre à ce que les versions d'aujourd'hui continuent à marcher dans plusieurs années sans effort de maintenance.
Python 3 a été cité dans ce thread, et j'ai l'impression que c'était cité comme modèle de ce qu'il faut faire. Python 3 est sorti en 2008, et dix ans plus tard on n'est toujours pas sorti du merdier que le cassage de compatibilité a entraîné. Je ne connais pas grand monde qui ait subi cette transition et qui considère ça comme un exemple à donner.
Après, forker au sens « écrire du nouveau code », c'est la partie la plus facile. Non pas que ce soit facile d'écrire du nouveau code, mais ça reste la partie émergée de l'iceberg comparé à la maintenance de ce nouveau code à long terme (n'importe quelle étude sur la répartition des coûts dans le développement d'un logiciel vous confirmera que le développement initial est petit devant tout le reste), la construction d'une nouvelle communauté de développeurs, l'animation d'une communauté d'utilisateurs, ...
C'est facile de trouver quelques exemples de forks qui ont réussi et plus difficile de lister les forks qui ont échoué pour une raison très simple : les forks qui ont raté, vous n'en avez jamais entendu parler. Mais moi, les fois où j'ai vu un développeur se plaindre du développement d'un soft et commencer son fork, ça n'a en général pas donné des LibreOffice et des NextCloud, mais plutôt un développeur qui part dans son coin, qui fait un truc pas mal pendant quelques mois puis qui jette l'éponge parce qu'il se démotive.
Par exemple, dans la liste de ce que le « darktable next generation » devrait faire, PhotoFlow coche la plupart des cases : http://aferrero2707.github.io/PhotoFlow/. Sur le papier, ça a l'air à peu près parfait. Mais si on regarde les indicateurs de bonne santé de la communauté : https://github.com/aferrero2707/PhotoFlo...ntributors Vs https://github.com/darktable-org/darktab...ntributors par exemple, ça ne donne pas envie de miser sur PhotoFlow pour l'avenir.
Déjà, parce que je pense qu'il ne faut pas sous-estimer l'importance de la compatibilité entre versions. On parle d'un éditeur non-destructif : avec darktable, on ne sauvegarde pas le résultat de la retouche, mais le moyen d'y arriver. Donc, sans un darktable qui sache le lire et l'appliquer à un raw, un .xmp n'est pas exploitable. Si darktable fait des changements incompatibles, ce sont les centaines d'images traitées avec les vielles versions qui sont à mettre à la poubelle. Alors OK, je pourrais toujours installer un vieux darktable pour reprendre ces traitements, mais combien de temps le vieux darktable sera-t-il installable et utilisable ? Vu la quantité de dépendances de darktable, il ne faut pas s'attendre à ce que les versions d'aujourd'hui continuent à marcher dans plusieurs années sans effort de maintenance.
Python 3 a été cité dans ce thread, et j'ai l'impression que c'était cité comme modèle de ce qu'il faut faire. Python 3 est sorti en 2008, et dix ans plus tard on n'est toujours pas sorti du merdier que le cassage de compatibilité a entraîné. Je ne connais pas grand monde qui ait subi cette transition et qui considère ça comme un exemple à donner.
Après, forker au sens « écrire du nouveau code », c'est la partie la plus facile. Non pas que ce soit facile d'écrire du nouveau code, mais ça reste la partie émergée de l'iceberg comparé à la maintenance de ce nouveau code à long terme (n'importe quelle étude sur la répartition des coûts dans le développement d'un logiciel vous confirmera que le développement initial est petit devant tout le reste), la construction d'une nouvelle communauté de développeurs, l'animation d'une communauté d'utilisateurs, ...
C'est facile de trouver quelques exemples de forks qui ont réussi et plus difficile de lister les forks qui ont échoué pour une raison très simple : les forks qui ont raté, vous n'en avez jamais entendu parler. Mais moi, les fois où j'ai vu un développeur se plaindre du développement d'un soft et commencer son fork, ça n'a en général pas donné des LibreOffice et des NextCloud, mais plutôt un développeur qui part dans son coin, qui fait un truc pas mal pendant quelques mois puis qui jette l'éponge parce qu'il se démotive.
Par exemple, dans la liste de ce que le « darktable next generation » devrait faire, PhotoFlow coche la plupart des cases : http://aferrero2707.github.io/PhotoFlow/. Sur le papier, ça a l'air à peu près parfait. Mais si on regarde les indicateurs de bonne santé de la communauté : https://github.com/aferrero2707/PhotoFlo...ntributors Vs https://github.com/darktable-org/darktab...ntributors par exemple, ça ne donne pas envie de miser sur PhotoFlow pour l'avenir.