Perso, de ce que je lis, je ne vois rien de majeur même si c'est toujours bon à prendre : des corrections de bugs et des outils de déploiement.
De mon expérience dans le service Open Source, j'ai jamais eu de mal pour que le client paye pour des corrections de bug ou de l'installation sur place.
Par contre, il y a un vrai souci pour arriver à financer le travail de fond : maintenance, gestion de la dette technique et développement de nouvelles fonctionnalités majeures (en dehors de celles clairement demandées par un client mais c'est souvent du très spécifique). La partie infra projet aussi est infinançable (pas forcément le matos mais le temps passé dessus).
Ce qu'on oublie souvent, c'est que les patches remontés génèrent aussi beaucoup de boulot côté communauté : relire les patches, faire des retours, demander les ajustements, tester et intégrer tout cela demande un temps non négligeable. Et souvent non financé, généralement, le seul qui est financé est la boîte de service qui fait le support qui aura écrit le patch initial. Sur un des projets sur lequel je bossais, je passais clairement beaucoup plus de temps que l'auteur initial sur la majorité des patches.
Pour moi, sur des projets de migration de ce genre, il devrait y avoir du plus ambitieux que corriger des bugs. Et surtout, il faudrait que, d'une manière ou d'une autre, on arrive à financer les développeurs upstream également.
Faire remonter l'argent upstream, c'est très compliqué.
[^] # Re: Et si...
Posté par Guillaume Smet (site web personnel) . En réponse au journal Munich revient sur Windows. Évalué à 10.
Ce que j'ai trouvé de mieux en cherchant vite fait, c'est ça : https://joinup.ec.europa.eu/news/munich-now-major-contributo .
Perso, de ce que je lis, je ne vois rien de majeur même si c'est toujours bon à prendre : des corrections de bugs et des outils de déploiement.
De mon expérience dans le service Open Source, j'ai jamais eu de mal pour que le client paye pour des corrections de bug ou de l'installation sur place.
Par contre, il y a un vrai souci pour arriver à financer le travail de fond : maintenance, gestion de la dette technique et développement de nouvelles fonctionnalités majeures (en dehors de celles clairement demandées par un client mais c'est souvent du très spécifique). La partie infra projet aussi est infinançable (pas forcément le matos mais le temps passé dessus).
Ce qu'on oublie souvent, c'est que les patches remontés génèrent aussi beaucoup de boulot côté communauté : relire les patches, faire des retours, demander les ajustements, tester et intégrer tout cela demande un temps non négligeable. Et souvent non financé, généralement, le seul qui est financé est la boîte de service qui fait le support qui aura écrit le patch initial. Sur un des projets sur lequel je bossais, je passais clairement beaucoup plus de temps que l'auteur initial sur la majorité des patches.
Pour moi, sur des projets de migration de ce genre, il devrait y avoir du plus ambitieux que corriger des bugs. Et surtout, il faudrait que, d'une manière ou d'une autre, on arrive à financer les développeurs upstream également.
Faire remonter l'argent upstream, c'est très compliqué.