Je connais des développeurs RH impliqués dans la couche input du système et dont le travail est effectivement de s'assurer que les tablettes Wacom sont bien intégrées et de résoudre les éventuels soucis rencontrés par ce genre de clients.
Je ne dis pas après qu'ils travaillent à plein temps grâce à ce genre de clients ou de problématiques (les input c'est aussi les touchpad, les claviers, les empreintes digitaux, les accéléromètres, les capteurs divers et variés, etc.). Mais très clairement ça en apporte des gains mesurables.
Et je n'ai nullement dis que Pixar finançait à lui seul une grosse vague d'améliorations du bureau GNOME (ou Linux en général) mais que des changements étaient liés à leurs besoins que le support qu'ils paient permet de financer. Il y a une différence d'échelle je pense importante entre ce que j'ai dis et ce que tu en retires. De la même façon que Microsoft ou Apple peuvent faire des correctifs ou quelques fonctions suivant la demande de certains clients, mais qu'ils ne vont pas mettre une armée de développeurs pour ça non plus.
Ce dont je parle n'a rien d'extraordinaire. Et ce n'est pas déconnant qu'un développeur ne soit pas au courant de cela. Tu sais des entreprises qui ont des RHEL avec support, il y en a des tas, et chacun peuvent remonter des problèmes spécifiques que Red Hat va essayer de satisfaire. Ce n'est pas pour autant qu'on va dire au développeur ou mettre sur le site Web "Pixar a aidé sur ce point" car finalement c'est un contrat qu'ils ont avec RH comme les autres avec des problèmes un peu particuliers. Je n'ai nullement mentionné un partenariat plus renforcé que cela. J'ai juste pointé que Pixar était un client, comme d'autres ils paient RH et que RH grâce à ces sous répond (ou essaye tout du moins) à leurs besoins.
Mais cela est très générique, on pourrait parler de comment les grosses structures qui ont des besoin de haute disponibilité élevées ont permis de mettre en place la mise à jour (partiel) du noyau sans le redémarrer. RHEL et Suse sur ce point ne font que de répondre à des demandes de clients qui payent le support et qui ont exprimé ce besoin important.
Ce dont je veux mettre en exergue c'est que la relation client / éditeur comme celui que je viens de décrire, mais qui existe ailleurs, nul doute que Canonical et Suse par exemple en ont de leur côté, permet d'être profitable à tout le monde si l'éditeur publie le code source du travail à la fin. Et qu'il faut essayer d'encourager la présence d'entreprises dans l'écosystème pour financer tout ou partie ce genre de choses.
Il ne faut pas croire que les éditeurs commerciaux de LL comme Red Hat, Suse, Canonical ou même Collabora font des correctifs pour la beauté du geste au gré de leurs envies. Une bonne part de ces correctifs sont financés d'une façon ou d'une autre par des clients qui ont exprimé (ou non) un besoin spécifique et qu'ils tentent de satisfaire au mieux. Il ne semble pas très courant qu'un client paye une fonctionnalité complète toute seule (ce serait probablement trop cher).
[^] # Re: non merci
Posté par Renault (site web personnel) . En réponse au journal Adobe sous Linux ?. Évalué à 4. Dernière modification le 13 décembre 2018 à 09:17.
Je connais des développeurs RH impliqués dans la couche input du système et dont le travail est effectivement de s'assurer que les tablettes Wacom sont bien intégrées et de résoudre les éventuels soucis rencontrés par ce genre de clients.
Je ne dis pas après qu'ils travaillent à plein temps grâce à ce genre de clients ou de problématiques (les input c'est aussi les touchpad, les claviers, les empreintes digitaux, les accéléromètres, les capteurs divers et variés, etc.). Mais très clairement ça en apporte des gains mesurables.
Et je n'ai nullement dis que Pixar finançait à lui seul une grosse vague d'améliorations du bureau GNOME (ou Linux en général) mais que des changements étaient liés à leurs besoins que le support qu'ils paient permet de financer. Il y a une différence d'échelle je pense importante entre ce que j'ai dis et ce que tu en retires. De la même façon que Microsoft ou Apple peuvent faire des correctifs ou quelques fonctions suivant la demande de certains clients, mais qu'ils ne vont pas mettre une armée de développeurs pour ça non plus.
Ce dont je parle n'a rien d'extraordinaire. Et ce n'est pas déconnant qu'un développeur ne soit pas au courant de cela. Tu sais des entreprises qui ont des RHEL avec support, il y en a des tas, et chacun peuvent remonter des problèmes spécifiques que Red Hat va essayer de satisfaire. Ce n'est pas pour autant qu'on va dire au développeur ou mettre sur le site Web "Pixar a aidé sur ce point" car finalement c'est un contrat qu'ils ont avec RH comme les autres avec des problèmes un peu particuliers. Je n'ai nullement mentionné un partenariat plus renforcé que cela. J'ai juste pointé que Pixar était un client, comme d'autres ils paient RH et que RH grâce à ces sous répond (ou essaye tout du moins) à leurs besoins.
Mais cela est très générique, on pourrait parler de comment les grosses structures qui ont des besoin de haute disponibilité élevées ont permis de mettre en place la mise à jour (partiel) du noyau sans le redémarrer. RHEL et Suse sur ce point ne font que de répondre à des demandes de clients qui payent le support et qui ont exprimé ce besoin important.
Ce dont je veux mettre en exergue c'est que la relation client / éditeur comme celui que je viens de décrire, mais qui existe ailleurs, nul doute que Canonical et Suse par exemple en ont de leur côté, permet d'être profitable à tout le monde si l'éditeur publie le code source du travail à la fin. Et qu'il faut essayer d'encourager la présence d'entreprises dans l'écosystème pour financer tout ou partie ce genre de choses.
Il ne faut pas croire que les éditeurs commerciaux de LL comme Red Hat, Suse, Canonical ou même Collabora font des correctifs pour la beauté du geste au gré de leurs envies. Une bonne part de ces correctifs sont financés d'une façon ou d'une autre par des clients qui ont exprimé (ou non) un besoin spécifique et qu'ils tentent de satisfaire au mieux. Il ne semble pas très courant qu'un client paye une fonctionnalité complète toute seule (ce serait probablement trop cher).