> « "vous le voulez ? vraiment ? ah bon, on va y réflechir, faudra qu'on l'audite quand meme avant..." »
> Tu fais comme si tu n'avais pas entendu parler des commentaires postés sur des blogs par des gens bien concernés sur le sujet qui revendiquent presque la non diffusion de ce bout de code par esprit de concurrence avec RedHat ?
en effet. ou plutot j'ai déjà dû oublier tellement c'était ridicule. "par esprit de concurrence avec RedHat" ? pourquoi pas avec Microsoft, tant qu'on y est ? c'est franchement risible, et ça concerne toujours l'équivalent d'un boulon de porte des toilettes d'un TGV pour un vendeur de TGV : l'interêt est ailleurs et ça n'a pas changé.
croire Red Hat incapable de créer la même dynamique en deux coups de cuillères à pot pour Fedora et RHES, c'est se faire des illusions. donc ne t'étonne pas si je n'accorde pas grand crédit à des commentaires officieux de ce calibre. c'est comme si un blogueur chez Microsoft se vantait aujourd'hui en 2006 qu'une prochaine mise à jour de IE 7 cassait volontairement et discrètement des réglages de Firefox. employé saoul ou idiot peut-être, information à prendre avec des pincettes certainement.
> Il est effectivement probable que ce bout de code n'ait strictement aucun intérêt. C'est donc à plus forte raison ridicule de refuser de le diffuser, si c'est sans enjeu.
comme j'ai dit avant, il y a plusieurs raisons qui peuvent empêcher une mise en libre, dont : du code pas libre acheté tout fait à gauche ou à droite, ou qui se trouvait déjà dans les cartons d'un des employés, ou sous-traité et donc sans contrôle direct sur son statut de code libre...
tu vois donc que la notion d'enjeu ne suffit pas, il y a aussi des impératifs divers qui viennent tout compliquer, et pas forcément sous leur contrôle. "garder les specs, le refaire mais en libre cette fois" ? oui, mais ça prend du temps et de l'argent. Shuttleworth a les moyens, mais il a surtout envie que son jouet avance vite.
> tout le monde peut comprendre une qualité de code moindre en fonctions des impératifs d'un logiciel.
un que j'ai cité en exemple était "sortir ça tout de suite".
et, au passage, tout le monde ne peut pas comprendre "une qualité de code moindre" : il y a des cons partout, dont beaucoup chez les bloggeurs, et une truie qui gueulerait au code sale ferait beaucoup de bruit et de mauvaise publicité à Ubuntu, sans parler du temps et des resources à consacrer à régler ces soucis de relations publiques.
prendre des mesures préventives face à des hordes de mongolitos qui attaquent et mordent tout ce qui bouge me parait parfaitement raisonnable. ça s'appelle prendre ses précautions.
> En raisonnant comme ça, la moitié des logiciels sur terre ne devraient jamais été publié
euh, quelque chose qui est l'oeuvre d'un ou deux individus et quelque chose codé au départ "par une boite", c'est très, très différent. des évenements historiques comme OpenOffice ou Mozilla sont plutot rares en fin de compte, et absolument pas parfaits.
quel est le but de publier sa production ? pour deux adolescents en jean et rastas qui s'y collent aujourd'hui c'est différent que pour une équipe qui s'y est mis il y a 5 ans, ou pour les dinosaures à la Apache ou GCC qui sont pratiquement nés libres
bref, si quelqu'un ou une boite ne publie pas aujourd'hui le code source de ses outils (pas sa production principale, ses OUTILS), c'est peut-être qu'il s'en fout pour le moment
> Nul développeur n'est contraint de fournir du support. Au contraire, le support se paie. Ca consomme des ressources ; ça en rapporte aussi.
le simple fait de PUBLIER ses chef-d'oeuvres prend du temps et consomme des resources. et même avec marqué en gros "fourni comme tel, aucun support, je n'ai pas le temps et le sujet ne m'interesse plus" avec des têtes de mort et des croix gammées, tu auras quand même des gens qui te contacteront pour du support et gérer ça (lire leurs proses, la poubelliser et éventuellement répondre "non") prend du temps aussi.
(au passage, je n'utilise pas Ubuntu, et j'ai déjà publié des gros pavés)
[^] # Re: UbuntuMac
Posté par Gniarf . En réponse à la dépêche Nouveautés dans le monde Ubuntu. Évalué à 1.
> Tu fais comme si tu n'avais pas entendu parler des commentaires postés sur des blogs par des gens bien concernés sur le sujet qui revendiquent presque la non diffusion de ce bout de code par esprit de concurrence avec RedHat ?
en effet. ou plutot j'ai déjà dû oublier tellement c'était ridicule. "par esprit de concurrence avec RedHat" ? pourquoi pas avec Microsoft, tant qu'on y est ? c'est franchement risible, et ça concerne toujours l'équivalent d'un boulon de porte des toilettes d'un TGV pour un vendeur de TGV : l'interêt est ailleurs et ça n'a pas changé.
croire Red Hat incapable de créer la même dynamique en deux coups de cuillères à pot pour Fedora et RHES, c'est se faire des illusions. donc ne t'étonne pas si je n'accorde pas grand crédit à des commentaires officieux de ce calibre. c'est comme si un blogueur chez Microsoft se vantait aujourd'hui en 2006 qu'une prochaine mise à jour de IE 7 cassait volontairement et discrètement des réglages de Firefox. employé saoul ou idiot peut-être, information à prendre avec des pincettes certainement.
> Il est effectivement probable que ce bout de code n'ait strictement aucun intérêt. C'est donc à plus forte raison ridicule de refuser de le diffuser, si c'est sans enjeu.
comme j'ai dit avant, il y a plusieurs raisons qui peuvent empêcher une mise en libre, dont : du code pas libre acheté tout fait à gauche ou à droite, ou qui se trouvait déjà dans les cartons d'un des employés, ou sous-traité et donc sans contrôle direct sur son statut de code libre...
tu vois donc que la notion d'enjeu ne suffit pas, il y a aussi des impératifs divers qui viennent tout compliquer, et pas forcément sous leur contrôle. "garder les specs, le refaire mais en libre cette fois" ? oui, mais ça prend du temps et de l'argent. Shuttleworth a les moyens, mais il a surtout envie que son jouet avance vite.
> tout le monde peut comprendre une qualité de code moindre en fonctions des impératifs d'un logiciel.
un que j'ai cité en exemple était "sortir ça tout de suite".
et, au passage, tout le monde ne peut pas comprendre "une qualité de code moindre" : il y a des cons partout, dont beaucoup chez les bloggeurs, et une truie qui gueulerait au code sale ferait beaucoup de bruit et de mauvaise publicité à Ubuntu, sans parler du temps et des resources à consacrer à régler ces soucis de relations publiques.
prendre des mesures préventives face à des hordes de mongolitos qui attaquent et mordent tout ce qui bouge me parait parfaitement raisonnable. ça s'appelle prendre ses précautions.
> En raisonnant comme ça, la moitié des logiciels sur terre ne devraient jamais été publié
euh, quelque chose qui est l'oeuvre d'un ou deux individus et quelque chose codé au départ "par une boite", c'est très, très différent. des évenements historiques comme OpenOffice ou Mozilla sont plutot rares en fin de compte, et absolument pas parfaits.
quel est le but de publier sa production ? pour deux adolescents en jean et rastas qui s'y collent aujourd'hui c'est différent que pour une équipe qui s'y est mis il y a 5 ans, ou pour les dinosaures à la Apache ou GCC qui sont pratiquement nés libres
bref, si quelqu'un ou une boite ne publie pas aujourd'hui le code source de ses outils (pas sa production principale, ses OUTILS), c'est peut-être qu'il s'en fout pour le moment
> Nul développeur n'est contraint de fournir du support. Au contraire, le support se paie. Ca consomme des ressources ; ça en rapporte aussi.
le simple fait de PUBLIER ses chef-d'oeuvres prend du temps et consomme des resources. et même avec marqué en gros "fourni comme tel, aucun support, je n'ai pas le temps et le sujet ne m'interesse plus" avec des têtes de mort et des croix gammées, tu auras quand même des gens qui te contacteront pour du support et gérer ça (lire leurs proses, la poubelliser et éventuellement répondre "non") prend du temps aussi.
(au passage, je n'utilise pas Ubuntu, et j'ai déjà publié des gros pavés)