Il y a des choses justes, mais aussi des incohérences et raccourcis.
> 2) Ennuyer le monde avec des histoires de logiciels
Mouaif...
Le logiciel libre fait du logiciel...
> 3) Se contenter d’imiter d’autres systèmes d’exploitation
> Pendant des années, le FOSS a dû s’efforcer de rattraper le développement de Windows et d’OS X.
Mouaif...
Le but du logiciel libre n'est pas de concurrencer le logiciel proprio. Par contre le logiciel libre ne doit pas disparaitre à cause du logiciel proprio (brevets, intéropérabilité impossible car protocoles non documentés, DRM, etc). Et, un peu réciproquement, le but du logiciel libre n'est pas de "détruire" le logiciel proprio ni d'être le "maître du monde" (comme le dit l'article).
> il ne suffit pas d’égaler Apple. Le but devrait être de le dépasser.
Marrant cette obsession des "concurrents"...
C'est un raisonnement bien "boite commerciale". Normal pour Canonical/Red Hat/etc, moins normal pour la "communauté", et encore moins normal pour quelqu'un qui veut lui donner des leçons au libre.
> Si un non-développeur émet une suggestion susceptible d’améliorer le projet, trop souvent la réponse qu’il obtiendra d’un développeur sera "Nous attendons ton code avec impatience", le développeur sachant très bien qu’il ne s’adresse pas à un codeur.
Ce comportenant est peut-être malheureux, mais bien souvent normal. On a souvent des trucs du style "faut faire un bureau 3D plus joli que MacOSX. Alors, développeurs du libre, faites votre travail ! Et je veux que ça soit glamour ! Et rapide ! Faites de l'assembleur si nécessaire !". Dans ce cas les développeurs vont répondre "va te faire foutre" (dans les grandes lignes). Il y a aussi les "diables, j'ai pris 10 minutes à faire un rapport de bug et aucun développeur n'a voulu passer 3 jours à corriger ce problème. C'est un scandale !".
Les développeurs sont très friand des idées/avis/suggestions des utilisateurs ou, plus précisément, d'avis d'"expert" (c-à-d de quelqu'un qui a réfléchit à un problème même s'il n'a rien à voir avec le codage). Vraiment.
Mais les utilisateurs attendent trop des développeurs (ce qui est en contradiction avec le problème "5) Accorder aux développeurs un statut privilégié"). Ils devaient faire preuve aussi de plus de compréhension et de respet envers les développeurs.
> Quelles qu’en soient les raisons, les gros projets FOSS agissent de plus en plus comme des entreprises commerciales de logiciels. Les dates de publication fixes, par exemple, sont devenues la norme pour de nombreux projets, tels que GNOME, Ubuntu et Fedora
C'est du n'importe quoi principalement pour Gnome et Fedora (Canonical veut faire du pognon avec Ubuntu (ce n'est pas un reproche), ce qui n'est pas le cas de Red Hat avec Fedora).
Une entreprise va fixer une date, mais surtout des nouvelles fonctionnalités pour vendre plus, pour faire du pognon. Gnome ou Fedora ne font pas ça dans cet objectif. C'est uniquement pour coordonner les efforts. Si grosso-modo à la date prévue une fonctionnalité prévue n'est pas prête, et bien elle n'est pas diffusée (ou elle est désactivée). On a vu ça très souvent chez Fedora (et probablement chez Gnome), on le verra encore souvent. Une entreprise commerciale ne fera pas ça car elle a promis cette nouvelle fonctionnalité, car ne pas fournir la fonctionnalité rend le produit moins attractif. L'objectif de l'entreprise n'est alors pas uniquement de coordonner les efforts (afin d'être plus productif dans son développement (pisser du code)), mais de sortir un produit "sexy" (qui se vend et fait du pognon).
On peut regarder du côté de RHEL et Fedora. Fedora sort à date fixe (grosso-modo). Fedora le fait pour améliorer la "productivité" des développements. Pour RHEL ce n'est pas cas (d'ailleurs les dates de sortie ne sont pas annoncées ou sont vagues). Fedora sort à date fixe pour coordonner le travail. RHEL sort lorsque le produit est intéressant pour ses clients payants.
En passant, MS a bien retardé massivement Vista...
Ubuntu est un cas spécial. Ubuntu a les chevilles énorme et croit qu'il lui suffit d'annoncer une date de sortie (quelques soient les nouvelles fonctionnalités) pour que des partenaires soient "tout existé" par l'"évènement" que sera la sortie d'une nouvelle Ubuntu et bossent comme des fous pour être dans les temps.
> Depuis peu, Mark Shuttleworth propose en outre une publication synchronisée pour les projets les plus importants, de sorte qu’il soit plus facile aux distributions de prévoir leur dates de publication, même si jusqu’à présent cette idée n’a pas trouvé un écho très favorable.
Les raisons (pas avouées) de Canonical sont de lui permettre de réduire ses coûts de maintenance d'une distribution "entreprise" (en gros, c'est Red Hat et Novell qui fait le boulot et c'est Canonical qui en profite avec sa popularité). Ces coûts de maintenance sont très élevé car c'est du boulot que les bénévoles ne veulent généralement pas faire. Ce que demande Canonical, ce n'est pas vraiment pour le bénéfice du libre... Ce n'est pas appliqué un modèle de développement (du code) qui vient du monde propriétaire et l'appliquer au libre pour le bénéfice du libre. C'est autre chose. C'est "crétin". Notons que Canonical n'a pas (encore) les moyens de faire ce que faire Red Hat avec RHEL ou Novell avec SLE. http://dag.wieers.com/blog/umts-to-the-rescue-red-hat-only-s(...)
> Qu’advient-il, par exemple, de la politique propre à l’Open Source (ne publier un logiciel que lorsqu’il est prêt)
N'importe quoi. Le logiciel libre ce n'est pas ça. Ça c'est par exemple MS avec Vista (Vista a été énormément retardé), c'est Red Hat avec RHEL, etc.
Le libre, c'est l'ouverture. Ça veut dire aussi diffuser (du moins le permettre) même lorsque ce n'est pas prêt. Ça permet plus de tests, de partager les avis, d'avoir de nouveau contributeur, etc. Le libre, ce n'est pas "ne publier un logiciel que lorsqu’il est prêt" !
Ce que dit Bruce Byfield, je l'ai entendu souvent, mais c'est vraiment du n'importe quoi !
Et s'il n'imaginait pas ses propos dans la perspètive développement, alors c'est un problème d'assurance qualité. Ici c'est au cas par cas et il y a différent niveau. KDE 4.0.0 n'a pas été un "when it's ready for the users" (pas de problème, ça a été annoncé). Par exemple un noyau Linux "vanilla" n'est pas un noyau pour entreprise. Le niveau d'assurance qualité n'est pas suffisant. C'est annoncé, ce n'est pas un problème. Les distributions prennent un Linux "vanilla", puis font le travail nécessaire pour avoir une qualité satisfaisante. A l'opposé, Fedora peut avoir des patchs qui ajoutent des fonctionnalités béta/expérimentales dans le noyau qui ne sont pas encore upstream.
Bref, c'est compliqué et le sacro saint "release when it's ready" n'a pas vraiment de sens. En fait c'est un truc de bon sens mais trop simpliste. Un "release when it's ready" pour Fedora, n'est pas un "release when it's ready" pour RHEL, n'est pas un "release when it's ready" pour kernel.org, etc.
Et franchement, les mainteneurs ne sont pas assez con pour adopter le "release when it is NOT ready". Ce qui n'empêche pas les erreurs, évidemment.
> Tôt ou tard, on ne pourra échapper à des problèmes de contrôle de qualité.
Dans ce cas, du moins c'est ce qui se fait avec Fedora, la fonctionnalité qui n'est pas prête est supprimée ou désactivée. On a souvent vu ça. Et on a aussi souvent vu Fedora repousser de quelques semaines la sortie d'une distribution pour des raisons de qualité. Par contre Ubuntu est bien bête de s'imposer une fenêtre de sortie d'un mois (ben oui, le nom d'une Ubuntu est déjà fixé et c'est le mois de sorti de la distribution). Et encore plus bête d'avoir déjà anoncé la date de sortie de sa futur LTS...
# Mouaif
Posté par IsNotGood . En réponse à la dépêche Neuf mauvaises pratiques du logiciel libre. Évalué à 10.
> 2) Ennuyer le monde avec des histoires de logiciels
Mouaif...
Le logiciel libre fait du logiciel...
> 3) Se contenter d’imiter d’autres systèmes d’exploitation
> Pendant des années, le FOSS a dû s’efforcer de rattraper le développement de Windows et d’OS X.
Mouaif...
Le but du logiciel libre n'est pas de concurrencer le logiciel proprio. Par contre le logiciel libre ne doit pas disparaitre à cause du logiciel proprio (brevets, intéropérabilité impossible car protocoles non documentés, DRM, etc). Et, un peu réciproquement, le but du logiciel libre n'est pas de "détruire" le logiciel proprio ni d'être le "maître du monde" (comme le dit l'article).
> il ne suffit pas d’égaler Apple. Le but devrait être de le dépasser.
Marrant cette obsession des "concurrents"...
C'est un raisonnement bien "boite commerciale". Normal pour Canonical/Red Hat/etc, moins normal pour la "communauté", et encore moins normal pour quelqu'un qui veut lui donner des leçons au libre.
> Si un non-développeur émet une suggestion susceptible d’améliorer le projet, trop souvent la réponse qu’il obtiendra d’un développeur sera "Nous attendons ton code avec impatience", le développeur sachant très bien qu’il ne s’adresse pas à un codeur.
Ce comportenant est peut-être malheureux, mais bien souvent normal. On a souvent des trucs du style "faut faire un bureau 3D plus joli que MacOSX. Alors, développeurs du libre, faites votre travail ! Et je veux que ça soit glamour ! Et rapide ! Faites de l'assembleur si nécessaire !". Dans ce cas les développeurs vont répondre "va te faire foutre" (dans les grandes lignes). Il y a aussi les "diables, j'ai pris 10 minutes à faire un rapport de bug et aucun développeur n'a voulu passer 3 jours à corriger ce problème. C'est un scandale !".
Les développeurs sont très friand des idées/avis/suggestions des utilisateurs ou, plus précisément, d'avis d'"expert" (c-à-d de quelqu'un qui a réfléchit à un problème même s'il n'a rien à voir avec le codage). Vraiment.
Mais les utilisateurs attendent trop des développeurs (ce qui est en contradiction avec le problème "5) Accorder aux développeurs un statut privilégié"). Ils devaient faire preuve aussi de plus de compréhension et de respet envers les développeurs.
> Quelles qu’en soient les raisons, les gros projets FOSS agissent de plus en plus comme des entreprises commerciales de logiciels. Les dates de publication fixes, par exemple, sont devenues la norme pour de nombreux projets, tels que GNOME, Ubuntu et Fedora
C'est du n'importe quoi principalement pour Gnome et Fedora (Canonical veut faire du pognon avec Ubuntu (ce n'est pas un reproche), ce qui n'est pas le cas de Red Hat avec Fedora).
Une entreprise va fixer une date, mais surtout des nouvelles fonctionnalités pour vendre plus, pour faire du pognon. Gnome ou Fedora ne font pas ça dans cet objectif. C'est uniquement pour coordonner les efforts. Si grosso-modo à la date prévue une fonctionnalité prévue n'est pas prête, et bien elle n'est pas diffusée (ou elle est désactivée). On a vu ça très souvent chez Fedora (et probablement chez Gnome), on le verra encore souvent. Une entreprise commerciale ne fera pas ça car elle a promis cette nouvelle fonctionnalité, car ne pas fournir la fonctionnalité rend le produit moins attractif. L'objectif de l'entreprise n'est alors pas uniquement de coordonner les efforts (afin d'être plus productif dans son développement (pisser du code)), mais de sortir un produit "sexy" (qui se vend et fait du pognon).
On peut regarder du côté de RHEL et Fedora. Fedora sort à date fixe (grosso-modo). Fedora le fait pour améliorer la "productivité" des développements. Pour RHEL ce n'est pas cas (d'ailleurs les dates de sortie ne sont pas annoncées ou sont vagues). Fedora sort à date fixe pour coordonner le travail. RHEL sort lorsque le produit est intéressant pour ses clients payants.
En passant, MS a bien retardé massivement Vista...
Ubuntu est un cas spécial. Ubuntu a les chevilles énorme et croit qu'il lui suffit d'annoncer une date de sortie (quelques soient les nouvelles fonctionnalités) pour que des partenaires soient "tout existé" par l'"évènement" que sera la sortie d'une nouvelle Ubuntu et bossent comme des fous pour être dans les temps.
> Depuis peu, Mark Shuttleworth propose en outre une publication synchronisée pour les projets les plus importants, de sorte qu’il soit plus facile aux distributions de prévoir leur dates de publication, même si jusqu’à présent cette idée n’a pas trouvé un écho très favorable.
Les raisons (pas avouées) de Canonical sont de lui permettre de réduire ses coûts de maintenance d'une distribution "entreprise" (en gros, c'est Red Hat et Novell qui fait le boulot et c'est Canonical qui en profite avec sa popularité). Ces coûts de maintenance sont très élevé car c'est du boulot que les bénévoles ne veulent généralement pas faire. Ce que demande Canonical, ce n'est pas vraiment pour le bénéfice du libre... Ce n'est pas appliqué un modèle de développement (du code) qui vient du monde propriétaire et l'appliquer au libre pour le bénéfice du libre. C'est autre chose. C'est "crétin". Notons que Canonical n'a pas (encore) les moyens de faire ce que faire Red Hat avec RHEL ou Novell avec SLE.
http://dag.wieers.com/blog/umts-to-the-rescue-red-hat-only-s(...)
> Qu’advient-il, par exemple, de la politique propre à l’Open Source (ne publier un logiciel que lorsqu’il est prêt)
N'importe quoi. Le logiciel libre ce n'est pas ça. Ça c'est par exemple MS avec Vista (Vista a été énormément retardé), c'est Red Hat avec RHEL, etc.
Le libre, c'est l'ouverture. Ça veut dire aussi diffuser (du moins le permettre) même lorsque ce n'est pas prêt. Ça permet plus de tests, de partager les avis, d'avoir de nouveau contributeur, etc.
Le libre, ce n'est pas "ne publier un logiciel que lorsqu’il est prêt" !
Ce que dit Bruce Byfield, je l'ai entendu souvent, mais c'est vraiment du n'importe quoi !
Et s'il n'imaginait pas ses propos dans la perspètive développement, alors c'est un problème d'assurance qualité. Ici c'est au cas par cas et il y a différent niveau. KDE 4.0.0 n'a pas été un "when it's ready for the users" (pas de problème, ça a été annoncé). Par exemple un noyau Linux "vanilla" n'est pas un noyau pour entreprise. Le niveau d'assurance qualité n'est pas suffisant. C'est annoncé, ce n'est pas un problème. Les distributions prennent un Linux "vanilla", puis font le travail nécessaire pour avoir une qualité satisfaisante. A l'opposé, Fedora peut avoir des patchs qui ajoutent des fonctionnalités béta/expérimentales dans le noyau qui ne sont pas encore upstream.
Bref, c'est compliqué et le sacro saint "release when it's ready" n'a pas vraiment de sens. En fait c'est un truc de bon sens mais trop simpliste. Un "release when it's ready" pour Fedora, n'est pas un "release when it's ready" pour RHEL, n'est pas un "release when it's ready" pour kernel.org, etc.
Et franchement, les mainteneurs ne sont pas assez con pour adopter le "release when it is NOT ready". Ce qui n'empêche pas les erreurs, évidemment.
> Tôt ou tard, on ne pourra échapper à des problèmes de contrôle de qualité.
Dans ce cas, du moins c'est ce qui se fait avec Fedora, la fonctionnalité qui n'est pas prête est supprimée ou désactivée. On a souvent vu ça. Et on a aussi souvent vu Fedora repousser de quelques semaines la sortie d'une distribution pour des raisons de qualité. Par contre Ubuntu est bien bête de s'imposer une fenêtre de sortie d'un mois (ben oui, le nom d'une Ubuntu est déjà fixé et c'est le mois de sorti de la distribution). Et encore plus bête d'avoir déjà anoncé la date de sortie de sa futur LTS...