C'est tout à fait juste, et d'un point de vue utilisateur on va y gagner sur le court terme, mais d'un point de vue économique il va y avoir un problème dans le financement de futur projets. Qui va encore financer le bootstrap de gros projets comme ça sans espoir d'éviter que le mastodonte Amazon ne vienne lui manger son business?
Or il ne faut pas se leurrer, on a mongo, elastic ou docker à ce niveau de finition car ils ont eu des financements qui ont permis de payer les dev et surtout le marketing qui après à permis à la communauté de se focaliser sur ces projets et les améliorer/industrialiser ensuite. Ce n'est plus l'inverse comme avant où c'était les communauté qui créait des champions qui après pouvaient se financer.
Bon si ce sont surtout les gros acteur du SaaS qui développent des moteurs en open source why not, mais alors in-fine 90% de l'utilisation qu'on aura sera sur ces plates formes, donc bah… non open source ^
On ne peux pas leur demander de fournir directement des $ aux auteurs alors qu'ils fournissent déjà du code. Pour moi c'est l'un ou l'autre, mais demander les deux ce n'est pas très correct pour eux.
Ensuite c'est plus que là le modèle économique de coo-pétition arrive à ses limites. Le développement et surtout l'organisation et le marketing nécessaire pour faire connaitre son produit est juste faramineux désormais avec la concentration des utilisations vers quelques outils au lieu d'une large diversité avant.
Mais l'essentiel des flux économiques n'arrivent pas vers les auteurs car désormais les utilisateurs préfèrent payer pour le service tout compris que mettre en place et gérer eux même (on ne peux pas leur reprocher).
Ici AWS et Elastic sont en compétition frontale, avec AWS qui récupère les plus values et Elastic qui a principalement investi (et là on parle en M$), donc forcément ça coince et ça se tire dans les pattes.
On risque donc d'arriver à une situation où on aura:
* un retour des outils sous licence pour une utilisation en interne, basé sur des moteurs open source, mais avec une scalabilité limitée (mais bien souvent suffisante)
* un service SaaS/PaaS avec les sources des moteurs des services qu'on utilisera, mais bien sûr pas le code et surtout la configuration et l'expertise pour le mettre en place à grande échelle (c'est leur métier à Amazon, et on ne donne pas gratuitement son métier)
Dans tous les cas on aura de bon moteurs, c'est déjà ça ^
Amazon tente de dire que non ce n'est pas un fork, avec autant de rajout et une opposition frontale au business d'elastic, c'est un vrai fork.
Que certaines modifications soient reportées upstream le temps que ce dernier est encore en vie oui, mais par exemple les parties sécurité qui font doublons avec la version Enterprise d'Elastic elles ne seront jamais intégrées upstream en open source.
Je pense qu'on va avoir une pénurie d'investisseurs pendant quelques temps pour lancer de nouveau gros outils comme ça avant que la parade à AWS ne soit trouvée. Car là certains vont perdre beaucoup d'argent, et ça ne sera pas Amazon ^
On les disait mort sur l'année 2018, on est en 2019 et on ressort la même chose.
C'est vrai qu'ils se sont fait prendre de vitesse sur la monétisation de tout ça. Les ordonnanceurs et autres surchouches K8s sont ce qui est utilisé par les plus grands comptes et que la partie principale de leur ancien dev n'est que le moteur d'un outil tier, donc non monétisable (ou juste à la marge, mais ça ne fera clairement pas le chiffre voulu par les investisseurs).
Mais faut pas tout jeter non plus. Il faut voir si leur version Enterprise n'attaque pas plus sérieusement les grands comptes qu'un écosystème comme k8s ne saurait le faire. La présence de vrai outil d'audit et de rapport pdf de consommation peux avoir bien plus de valeur au yeux de ceux qui sont près à payer pour un tel outil qu'une meilleure intégration pour automatiser le déploiement d'un loadbalanceur.
Si par contre ils tentent de jouer les muscles sur la partie technique face à Kubernetes là c'est sûr, c'est trop tard.
Leur matos ou pas ça ne change pas le fait que la partie soft peu être faite par un tiers, surtout que là on parle de trucs complexes avec des compilos et cie.
Sinon le vrai risque c'est côté image: "oh ils ne font pas tout eux même, ils utilisent des outils dépassés, etc etc". Et ça c'est autrement plus important pour eux qu'avoir 3 pull requests par an pour fixer une typo dans leur doc.
J'ai déjà réussi à me perdre dans une ville inconnue (Nuremberg) alors que j'avais 600m à faire, avec un plan en main (un peu grossier, juste les grande avenues, soit 2 en fait).
Par contre gérer les représentation spaciales ne me m'a jamais posé de soucis. Peux être un question d'échelle?
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
Pas que, car tu peux aussi avoir certains qui sont obligés d'utiliser des outils dans leur référentiel d'outil si il y en a un qui a été homologué (il y a plusieurs niveaux à l'intérieur et c'est sacrément galère et surtout cher s'y être mais bon).
Les très vitaux pour la nations sont ainsi obligés sur certains secteurs de ne prendre que dans ce catalogue (pas sur le poste bureautique de la secrétaire, mais côté serveur/infra là c'est carrément plus restrictif).
The operational cost of avoiding split-brains altogether is very high
Je pense qu'ils doivent revoir cette estimation, car leur image en ayant pris un coup (comme gitlab à l'époque), je ne suis pas sûr que gérer pleinement les splitbrains soit si cher que ça au final désormais.
Mais c'est bien ça qui est triste, c'est que ça marche et qu'une fois encore le marketing a bien plus de poids que les faits objectifs.
Là où je pense qu'ils prennent des risques, c'est vraiment sur le fait de devoir mettre toute la stack dans leur propre licence, car dans les faits même ceux qui veulent ça sera infaisable (sauf si tu as tout en MIT/BSD, mais bon tu as bien du LGPL dans le tas, voir du GPL sur des processus à côté).
Donc c'est tellement infaisable que là même le marketing va avoir du mal à cacher le côté totalement faux de l'histoire quand les premiers qui vont "essayer" vont démontrer que c'est infaisable.
Je me doute bien qu'ils ont déjà prévu ça, juste que d'habitude ils mettent déjà les graines de leur future argumentaire dans l'annonce précédente, mais là j'arrive pas à voir l'astuce.
A moins que ce soit un genre de "pied dans la porte": on mets THE grosse limitation dans cette version, ça couine car c'est pas faisable à cause des autres projets GPL qui ne veulent/peuvent pas changer leur licence alors que eux les gentils mongo ils l'ont fait, et donc licence version 2 qui est un peu moins restrictive juste sur ce point là, et hop ils sont les gentils de l'histoire même si on regarde le fil complet c'est totalement l'inverse.
Je ne suis pas totalement d'accord avec cette vision des choses:
En tout cas, cela semble être une belle tentative de la part de MongoDB à faire basculer une bonne partie des utilisateurs vers la version payante du logiciel. […]
En effet, si tu prends le soucis d'un autre angle, ils demandent simplement la même chose que la GPL, mais au niveau du service, un peu comme on prends au niveau du processus pour la GPL.
Donc forcer oui, mais à respecter les règles du logiciel libre sur le long terme, plus que juste open source, car c'est trop simple de bypasser l'AGPL dans les faits.
Est-ce qu'au passage ceci va faire que certains qui ne veulent pas fournir leur code vont devoir payer, oui. Est-ce si mal que ça? (si on se place du côté logiciel libre).
Bon après d'une manière plus réaliste, je pense comme toi qu'en effet c'est un bon effet marketing & juridique => monétisation en hausse de leur offre. Et si c'est vraiment forcer à ouvrir toute la stack d'un service, ça va migrer sérieusement dans le futur, ou bien ne pas mettre à jour.
Je voterai sur la taille de la communauté et crédibilité du sponsor de Rust? C'est largement supérieur en matière de poids de décision que quelques intérêts techniques entre des langages qui sont chacun déjà de grosses avancées par rapport à ce qu'on utilise en terme de ROI sur le temps de dev (et surtout de debug je crois ).
Après Ada est vieux et utilisé dans l'industrie non? Donc côté crédibilité ça doit tenir la route. Faudrait poser la question directement je pense.
Nop, car in fine les perfs ne sont pas trop impactées, et ça faisait augmenter artificiellement le nombre de commits de cette société et donc leur lisibilité.
Je t'assure que je l'ai pris pleine face lors d'un call, que c'était un choix réfléchi et conscient :)
(ils n'étaient pas lead du projet, donc plus rude de pourrir le reste, la doc étant déjà présente etc etc).
Non c'est plus simple et efficace que ça: juste complexifier le code à l’extrême. Là où par exemple tu as un cas d'utilisation assez simple, bah tu vas utiliser 36 libs tierces pour obtenir le même résultat, et là bon courage si tu ne connais pas les subtilités de ces libs, comment (bien) les imbriquer etc etc.
ou alors mettre 4 niveaux de classes là où tu sais pertinemment que tu n'auras jamais besoin de créer de nouvelles classes filles. Etc etc.
En fait c'est assez simple comme méthode: tu prends tout le bon sens qui te fais dire en général: "non là c'est too much, ça va devenir imbitable à maintenir et débugger", bah tu le supprime. Tu auras un code certe open, mais good luck a qui veux le modifier s'il n'est pas parmi ceux qui l'ont complexifier juste pour le complexifier.
dans le genre j'ai eu à gérer un autre cas: une société qui souhaite participer au projet en mettant des devs à dispo, mais qui te dis en off très clairement que par contre elle compte faire en sorte que seuls des dev professionnel (aka les siens) ne pourront modifier le code (alors que le projet a toujours voulu qu'un utilisateur "standard" soit capable sans avoir fait une thèse en génie logiciel).
Là l'effet est imparable: byebye les patchs communautaires, et tu es obligé de passer par elle pour demander une évolution.
Mais c'est plus "professionnel" donc c'est mieux hein ^
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. une personne qui poste sur un tel canal se "débarrasse" de l'information sans en prendre la responsabilité, sans s'assurer qu'il a bien été compris par les autres, et qu'une solution va être conçue et gérée. Il a écrit, ce n'est plus son problème. Le projet dans son ensemble va exploser, mais c'est plus "son" problème.
Il n'y a pas de 2 et 3. Le 1 a tué ton projet en permettant à des irresponsables d'être membres de ton équipes.
Par contre c'est sûr ça évite d'avoir à expliquer les choses, et à entendre des avis contradictoires. C'est bien plus agréable. D'un point de vue projet c'est une hérésie.
(je mets de côté ceux en remote qui n'ont pas le choix, mais alors il faut une organisation qui permet de palier ce soucis, mais qui va alors remettre du désagréable sur la ligne…)
La remarque est totalement valable je trouve, car en effet c'est plus un terme générique que de celui de son implémentation "historique".
Après chacune a ses différences, mais si on mets de côté la partie configuration (qui se différencie de plus en plus avec le temps entre les outils), les utilisateurs finaux ne font plus la différence une fois devant leur interface.
Surtout que la plupart des interfaces ne montrent que le sommet de l'iceberg, (juste host+service avec status et output, et c'est tout) sans trop chercher à faire comprendre les autres notions (rien que HARD/SOFT c'est important, et pourtant pas bien mis en valeur pour que tout le monde comprenne sans avoir lu une doc de 500 pages )
Reste que ceux qui doivent administrer la plateforme de supervision eux font la différence, mais bon ils sont dans la mine, alors c'est pas visible, même si ça fait toute la différence sur le projet au final ^
Tu oublies leur cible commerciale principale:
- les professionnels en entreprise qui n'ont pas cette connaissance (ou pas le temps) et pour qui il faut que "juste ça marche" :D
Le fait que ta réponse soit en négative est assez révélateur. Ok elle est "directe" mais elle a l'intérêt d'être dans le réel et prendre du recul (qu'on soit d'accord ou pas avec les points, c'est une autre histoire).
Est-ce que ton historique de réponse te fait avoir des -1 gratuits, ou bien est-ce que les questions de fonds et que "les end users avant ceux qui font techniquement (hobby ou job)" est non audible car non agréable?
[^] # Re: Community over code
Posté par Jean Gabes (site web personnel) . En réponse au lien Elastic Search préforké. Évalué à 2.
C'est tout à fait juste, et d'un point de vue utilisateur on va y gagner sur le court terme, mais d'un point de vue économique il va y avoir un problème dans le financement de futur projets. Qui va encore financer le bootstrap de gros projets comme ça sans espoir d'éviter que le mastodonte Amazon ne vienne lui manger son business?
Or il ne faut pas se leurrer, on a mongo, elastic ou docker à ce niveau de finition car ils ont eu des financements qui ont permis de payer les dev et surtout le marketing qui après à permis à la communauté de se focaliser sur ces projets et les améliorer/industrialiser ensuite. Ce n'est plus l'inverse comme avant où c'était les communauté qui créait des champions qui après pouvaient se financer.
Bon si ce sont surtout les gros acteur du SaaS qui développent des moteurs en open source why not, mais alors in-fine 90% de l'utilisation qu'on aura sera sur ces plates formes, donc bah… non open source ^
[^] # Re: contribuer
Posté par Jean Gabes (site web personnel) . En réponse au lien Elastic Search préforké. Évalué à 3.
On ne peux pas leur demander de fournir directement des $ aux auteurs alors qu'ils fournissent déjà du code. Pour moi c'est l'un ou l'autre, mais demander les deux ce n'est pas très correct pour eux.
Ensuite c'est plus que là le modèle économique de coo-pétition arrive à ses limites. Le développement et surtout l'organisation et le marketing nécessaire pour faire connaitre son produit est juste faramineux désormais avec la concentration des utilisations vers quelques outils au lieu d'une large diversité avant.
Mais l'essentiel des flux économiques n'arrivent pas vers les auteurs car désormais les utilisateurs préfèrent payer pour le service tout compris que mettre en place et gérer eux même (on ne peux pas leur reprocher).
Ici AWS et Elastic sont en compétition frontale, avec AWS qui récupère les plus values et Elastic qui a principalement investi (et là on parle en M$), donc forcément ça coince et ça se tire dans les pattes.
On risque donc d'arriver à une situation où on aura:
* un retour des outils sous licence pour une utilisation en interne, basé sur des moteurs open source, mais avec une scalabilité limitée (mais bien souvent suffisante)
* un service SaaS/PaaS avec les sources des moteurs des services qu'on utilisera, mais bien sûr pas le code et surtout la configuration et l'expertise pour le mettre en place à grande échelle (c'est leur métier à Amazon, et on ne donne pas gratuitement son métier)
Dans tous les cas on aura de bon moteurs, c'est déjà ça ^
# A ce niveau là c'est un vrai fork
Posté par Jean Gabes (site web personnel) . En réponse au lien Elastic Search préforké. Évalué à 2.
Amazon tente de dire que non ce n'est pas un fork, avec autant de rajout et une opposition frontale au business d'elastic, c'est un vrai fork.
Que certaines modifications soient reportées upstream le temps que ce dernier est encore en vie oui, mais par exemple les parties sécurité qui font doublons avec la version Enterprise d'Elastic elles ne seront jamais intégrées upstream en open source.
Je pense qu'on va avoir une pénurie d'investisseurs pendant quelques temps pour lancer de nouveau gros outils comme ça avant que la parade à AWS ne soit trouvée. Car là certains vont perdre beaucoup d'argent, et ça ne sera pas Amazon ^
[^] # Re: LBO
Posté par Jean Gabes (site web personnel) . En réponse au journal Gandi s'ouvre aux investisseurs. Évalué à 1.
Et quand il y a une diminution du revenu de la société? On applique la même relation?
Tu vas me dire que dans un certain sens c'est déjà le cas, avec certains qui sont mis dehors, les autres gardant le même salaire.
[^] # Re: Retour de bâton
Posté par Jean Gabes (site web personnel) . En réponse au lien pour bien s'amuser avec son éditeur de texte favori. Évalué à 5.
Je vous d'ici l'échange, digne des face à face entre bandes rivales sur un pont, de nuit, chacun avec son otage :)
# Rien de neuf au final
Posté par Jean Gabes (site web personnel) . En réponse au lien Docker is dead ?. Évalué à 5.
On les disait mort sur l'année 2018, on est en 2019 et on ressort la même chose.
C'est vrai qu'ils se sont fait prendre de vitesse sur la monétisation de tout ça. Les ordonnanceurs et autres surchouches K8s sont ce qui est utilisé par les plus grands comptes et que la partie principale de leur ancien dev n'est que le moteur d'un outil tier, donc non monétisable (ou juste à la marge, mais ça ne fera clairement pas le chiffre voulu par les investisseurs).
Mais faut pas tout jeter non plus. Il faut voir si leur version Enterprise n'attaque pas plus sérieusement les grands comptes qu'un écosystème comme k8s ne saurait le faire. La présence de vrai outil d'audit et de rapport pdf de consommation peux avoir bien plus de valeur au yeux de ceux qui sont près à payer pour un tel outil qu'une meilleure intégration pour automatiser le déploiement d'un loadbalanceur.
Si par contre ils tentent de jouer les muscles sur la partie technique face à Kubernetes là c'est sûr, c'est trop tard.
[^] # Re: nvidia
Posté par Jean Gabes (site web personnel) . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 3.
C'est juste, toutes mes excuses pour eux.
[^] # Re: nvidia
Posté par Jean Gabes (site web personnel) . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 8.
Leur matos ou pas ça ne change pas le fait que la partie soft peu être faite par un tiers, surtout que là on parle de trucs complexes avec des compilos et cie.
Sinon le vrai risque c'est côté image: "oh ils ne font pas tout eux même, ils utilisent des outils dépassés, etc etc". Et ça c'est autrement plus important pour eux qu'avoir 3 pull requests par an pour fixer une typo dans leur doc.
# Réponse: non dans mon cas ^^
Posté par Jean Gabes (site web personnel) . En réponse au sondage Les programmeurs ont-ils le sens de l'orientation ?. Évalué à 2.
J'ai déjà réussi à me perdre dans une ville inconnue (Nuremberg) alors que j'avais 600m à faire, avec un plan en main (un peu grossier, juste les grande avenues, soit 2 en fait).
Par contre gérer les représentation spaciales ne me m'a jamais posé de soucis. Peux être un question d'échelle?
[^] # Re: SSPL vs AGPL
Posté par Jean Gabes (site web personnel) . En réponse au lien pas de MongoDB dans Debian et RedHat. Évalué à 0.
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
# Terme un peu fort ^^
Posté par Jean Gabes (site web personnel) . En réponse au lien Le serveur PEAR est hors-ligne suite à une infection.. Évalué à 2.
"Infection" : le terme est un peu fort je trouve: ce n'est que du PHP. Ok c'est pas génial, mais de là à le traiter d'infection quand même…. (⌐■_■)
Plus sérieusement, pas de chance pour ceux qui l'utilisent dans leur build actuellement.
[^] # Re: ni chaud ni froid
Posté par Jean Gabes (site web personnel) . En réponse au journal KDE is dying. Évalué à 1.
Pas que, car tu peux aussi avoir certains qui sont obligés d'utiliser des outils dans leur référentiel d'outil si il y en a un qui a été homologué (il y a plusieurs niveaux à l'intérieur et c'est sacrément galère et surtout cher s'y être mais bon).
Les très vitaux pour la nations sont ainsi obligés sur certains secteurs de ne prendre que dans ce catalogue (pas sur le poste bureautique de la secrétaire, mais côté serveur/infra là c'est carrément plus restrictif).
[^] # Re: Faut lire les journaux
Posté par Jean Gabes (site web personnel) . En réponse au journal Github m. Évalué à 2.
Faut croire que leur mécanisme de splitbrain a mal fonctionné (cf https://githubengineering.com/mysql-high-availability-at-github/ où ils en parlent):
Je pense qu'ils doivent revoir cette estimation, car leur image en ayant pris un coup (comme gitlab à l'époque), je ne suis pas sûr que gérer pleinement les splitbrains soit si cher que ça au final désormais.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . En réponse au journal SSPL: All your service are belong to us. Évalué à 5.
Mais c'est bien ça qui est triste, c'est que ça marche et qu'une fois encore le marketing a bien plus de poids que les faits objectifs.
Là où je pense qu'ils prennent des risques, c'est vraiment sur le fait de devoir mettre toute la stack dans leur propre licence, car dans les faits même ceux qui veulent ça sera infaisable (sauf si tu as tout en MIT/BSD, mais bon tu as bien du LGPL dans le tas, voir du GPL sur des processus à côté).
Donc c'est tellement infaisable que là même le marketing va avoir du mal à cacher le côté totalement faux de l'histoire quand les premiers qui vont "essayer" vont démontrer que c'est infaisable.
Je me doute bien qu'ils ont déjà prévu ça, juste que d'habitude ils mettent déjà les graines de leur future argumentaire dans l'annonce précédente, mais là j'arrive pas à voir l'astuce.
A moins que ce soit un genre de "pied dans la porte": on mets THE grosse limitation dans cette version, ça couine car c'est pas faisable à cause des autres projets GPL qui ne veulent/peuvent pas changer leur licence alors que eux les gentils mongo ils l'ont fait, et donc licence version 2 qui est un peu moins restrictive juste sur ce point là, et hop ils sont les gentils de l'histoire même si on regarde le fil complet c'est totalement l'inverse.
On verra bien, si c'est ça ca va vite arriver.
# Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . En réponse au journal SSPL: All your service are belong to us. Évalué à 4.
Je ne suis pas totalement d'accord avec cette vision des choses:
En effet, si tu prends le soucis d'un autre angle, ils demandent simplement la même chose que la GPL, mais au niveau du service, un peu comme on prends au niveau du processus pour la GPL.
Donc forcer oui, mais à respecter les règles du logiciel libre sur le long terme, plus que juste open source, car c'est trop simple de bypasser l'AGPL dans les faits.
Est-ce qu'au passage ceci va faire que certains qui ne veulent pas fournir leur code vont devoir payer, oui. Est-ce si mal que ça? (si on se place du côté logiciel libre).
Bon après d'une manière plus réaliste, je pense comme toi qu'en effet c'est un bon effet marketing & juridique => monétisation en hausse de leur offre. Et si c'est vraiment forcer à ouvrir toute la stack d'un service, ça va migrer sérieusement dans le futur, ou bien ne pas mettre à jour.
[^] # Re: All hail to Rust
Posté par Jean Gabes (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 7.
Je voterai sur la taille de la communauté et crédibilité du sponsor de Rust? C'est largement supérieur en matière de poids de décision que quelques intérêts techniques entre des langages qui sont chacun déjà de grosses avancées par rapport à ce qu'on utilise en terme de ROI sur le temps de dev (et surtout de debug je crois ).
Après Ada est vieux et utilisé dans l'industrie non? Donc côté crédibilité ça doit tenir la route. Faudrait poser la question directement je pense.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
Oui, si il y en a qui veulent forker. Dans les faits, beaucoup en parlent, très (très) peu le font ^
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Nop, car in fine les perfs ne sont pas trop impactées, et ça faisait augmenter artificiellement le nombre de commits de cette société et donc leur lisibilité.
Je t'assure que je l'ai pris pleine face lors d'un call, que c'était un choix réfléchi et conscient :)
(ils n'étaient pas lead du projet, donc plus rude de pourrir le reste, la doc étant déjà présente etc etc).
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Oui oui, juste que ça peux l'être aussi en Open Source de manière consciente et calculée :)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Non c'est plus simple et efficace que ça: juste complexifier le code à l’extrême. Là où par exemple tu as un cas d'utilisation assez simple, bah tu vas utiliser 36 libs tierces pour obtenir le même résultat, et là bon courage si tu ne connais pas les subtilités de ces libs, comment (bien) les imbriquer etc etc.
ou alors mettre 4 niveaux de classes là où tu sais pertinemment que tu n'auras jamais besoin de créer de nouvelles classes filles. Etc etc.
En fait c'est assez simple comme méthode: tu prends tout le bon sens qui te fais dire en général: "non là c'est too much, ça va devenir imbitable à maintenir et débugger", bah tu le supprime. Tu auras un code certe open, mais good luck a qui veux le modifier s'il n'est pas parmi ceux qui l'ont complexifier juste pour le complexifier.
# Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 5.
salut,
dans le genre j'ai eu à gérer un autre cas: une société qui souhaite participer au projet en mettant des devs à dispo, mais qui te dis en off très clairement que par contre elle compte faire en sorte que seuls des dev professionnel (aka les siens) ne pourront modifier le code (alors que le projet a toujours voulu qu'un utilisateur "standard" soit capable sans avoir fait une thèse en génie logiciel).
Là l'effet est imparable: byebye les patchs communautaires, et tu es obligé de passer par elle pour demander une évolution.
Mais c'est plus "professionnel" donc c'est mieux hein ^
# Perte de reponsabilité
Posté par Jean Gabes (site web personnel) . En réponse au journal Points de douleur du Team Chat ?. Évalué à 3.
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. une personne qui poste sur un tel canal se "débarrasse" de l'information sans en prendre la responsabilité, sans s'assurer qu'il a bien été compris par les autres, et qu'une solution va être conçue et gérée. Il a écrit, ce n'est plus son problème. Le projet dans son ensemble va exploser, mais c'est plus "son" problème.
Il n'y a pas de 2 et 3. Le 1 a tué ton projet en permettant à des irresponsables d'être membres de ton équipes.
Par contre c'est sûr ça évite d'avoir à expliquer les choses, et à entendre des avis contradictoires. C'est bien plus agréable. D'un point de vue projet c'est une hérésie.
(je mets de côté ceux en remote qui n'ont pas le choix, mais alors il faut une organisation qui permet de palier ce soucis, mais qui va alors remettre du désagréable sur la ligne…)
[^] # Re: Forks de Nagios
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Découverte de l’outil de supervision Prometheus. Évalué à 5.
La remarque est totalement valable je trouve, car en effet c'est plus un terme générique que de celui de son implémentation "historique".
Après chacune a ses différences, mais si on mets de côté la partie configuration (qui se différencie de plus en plus avec le temps entre les outils), les utilisateurs finaux ne font plus la différence une fois devant leur interface.
Surtout que la plupart des interfaces ne montrent que le sommet de l'iceberg, (juste host+service avec status et output, et c'est tout) sans trop chercher à faire comprendre les autres notions (rien que HARD/SOFT c'est important, et pourtant pas bien mis en valeur pour que tout le monde comprenne sans avoir lu une doc de 500 pages )
Reste que ceux qui doivent administrer la plateforme de supervision eux font la différence, mais bon ils sont dans la mine, alors c'est pas visible, même si ça fait toute la différence sur le projet au final ^
[^] # Re: Quelle facilité de mise en place ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Suricata 4.0 : la détection d’intrusion en mode hipster. Évalué à 1.
Tu oublies leur cible commerciale principale:
- les professionnels en entreprise qui n'ont pas cette connaissance (ou pas le temps) et pour qui il faut que "juste ça marche" :D
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 2.
Le fait que ta réponse soit en négative est assez révélateur. Ok elle est "directe" mais elle a l'intérêt d'être dans le réel et prendre du recul (qu'on soit d'accord ou pas avec les points, c'est une autre histoire).
Est-ce que ton historique de réponse te fait avoir des -1 gratuits, ou bien est-ce que les questions de fonds et que "les end users avant ceux qui font techniquement (hobby ou job)" est non audible car non agréable?