30/05/2008, 09:47:33
> Le vrais problème, avouons-le, n'est pas sur le principe d'une
> organiation faîtière pour le standard KNX,
C'est exactement ce que je viens de dire.
> mais sur le prix du
> logiciel en question ;-). Ce prix est, je suis d'accord, trop élevé.
Justement, ce prix élevé est la conséquence du fait qu'il n'y a pas de
concurrence pour ETS
Si un concurrent veut développer son propre outil de config, il à le
choix entre 2 solutions:
1) "créer un outil qui ne fonctionne qu'avec ses propres produits" et
on tombe dans un système à la TX100 pour lequel on perds tous les
avantages du KNX puisqu'on est limité à une marque.
2) convaincre tous les fabricants de lui fournir des DB de produits
similaires à celles d'ETS, mais dans son propre format puisque celui
d'ETS n'est pas publique. Premièrement c'est un peu stupide puisque ça
obligerait chaque fabricant à fournir ses DB dans plusieurs formats,
ensuite je pense qu'il y a peu de chances que ces concurrents
potentiels arrivent à convaincre tous les fabricants.
==> Donc la concurrence qui obligerait ETS à revoir le prix de son
logiciel à la baisse et qui le pousserait à l'innovation pour défendre
ses parts de marché n'est pas possible tant que le format des DB
n'est pas publique.
> Mais il ne faut pas non plus vouloir le beurre, l'argent du beurre, et
> le fil à couper le beurre ! KNX est un protocol ouvert et rien de
> t'empêche de dévelloper une autre manière d'attaquer le protocole,
> preuve en est le nouveau router IP de Normelec, et les prochains
> produits KNX qui pourront être IP full. Mais, depuis la nuit des
> temps, tout effort de dévelloppement n'est pas gratuit.
La question n'est pas de savoir si c'est gratuit ou pas gratuit. C'est
de savoir si c'est possible ou pas possible.
> Les sources du
> protocole KNX sont disponibles pour tous, les royalties, même si elles
> sont élevées pour tout un chacun, sont là non pour faire de KNX un
> nouveau Microsoft, mais au contraire pour que KNX reste fiable, malgré
> la toujours plus grande quantité de constructeurs et produits qui
> tournent sur ce protocole. Ce n'est pas une mince affaire, et ça coûte
> aussi !
Justement, pour reprendre ton exemple de Microsoft, c'est depuis que
la concurrence des OS libres à réellement démarré que Microsoft a
progressé le plus en matière de sécurité et de fiabilité.
> Perso, je préfère que KNX garde jalousement ses sources ETS , afin
> d'éviter précisément ce qui se passe dans le monde de l'informatique :
> des produits IP ou autres développés "à la pelle" et "au rabais" qui
> ne fonctionnent que les années bissextiles, quand tout va bien ! avec
> des connexions Internet dont la fiabilité nous donnent l'occasion de
> faire de fréquentes pauses-café... ;-))
Avec cette approche, on pourrait purement et simplement interdire tous
les produits bas-de-gamme. Si ils existent, c'est parce qu'il y a une
demande de la part des clients.
Moi je suis pour donner le choix au client de déterminer jusqu'ou il
est disposé à payer plus pour avoir mieux.
Et puis on s'éloigne du problème initial. Si je développe mes propres
programmes qui tournent sur des BCU2 en utilisant bcusdk, je peux les
programmer et les configurer uniquement avec bcusdk. Pour le reste de
la configuration, je peux le faire uniquement avec ETS et il ne m'est
donc pas possible de gérer la configuration complète à l'aide d'un
seul outil.
A+
Jean-François
> organiation faîtière pour le standard KNX,
C'est exactement ce que je viens de dire.
> mais sur le prix du
> logiciel en question ;-). Ce prix est, je suis d'accord, trop élevé.
Justement, ce prix élevé est la conséquence du fait qu'il n'y a pas de
concurrence pour ETS
Si un concurrent veut développer son propre outil de config, il à le
choix entre 2 solutions:
1) "créer un outil qui ne fonctionne qu'avec ses propres produits" et
on tombe dans un système à la TX100 pour lequel on perds tous les
avantages du KNX puisqu'on est limité à une marque.
2) convaincre tous les fabricants de lui fournir des DB de produits
similaires à celles d'ETS, mais dans son propre format puisque celui
d'ETS n'est pas publique. Premièrement c'est un peu stupide puisque ça
obligerait chaque fabricant à fournir ses DB dans plusieurs formats,
ensuite je pense qu'il y a peu de chances que ces concurrents
potentiels arrivent à convaincre tous les fabricants.
==> Donc la concurrence qui obligerait ETS à revoir le prix de son
logiciel à la baisse et qui le pousserait à l'innovation pour défendre
ses parts de marché n'est pas possible tant que le format des DB
n'est pas publique.
> Mais il ne faut pas non plus vouloir le beurre, l'argent du beurre, et
> le fil à couper le beurre ! KNX est un protocol ouvert et rien de
> t'empêche de dévelloper une autre manière d'attaquer le protocole,
> preuve en est le nouveau router IP de Normelec, et les prochains
> produits KNX qui pourront être IP full. Mais, depuis la nuit des
> temps, tout effort de dévelloppement n'est pas gratuit.
La question n'est pas de savoir si c'est gratuit ou pas gratuit. C'est
de savoir si c'est possible ou pas possible.
> Les sources du
> protocole KNX sont disponibles pour tous, les royalties, même si elles
> sont élevées pour tout un chacun, sont là non pour faire de KNX un
> nouveau Microsoft, mais au contraire pour que KNX reste fiable, malgré
> la toujours plus grande quantité de constructeurs et produits qui
> tournent sur ce protocole. Ce n'est pas une mince affaire, et ça coûte
> aussi !
Justement, pour reprendre ton exemple de Microsoft, c'est depuis que
la concurrence des OS libres à réellement démarré que Microsoft a
progressé le plus en matière de sécurité et de fiabilité.
> Perso, je préfère que KNX garde jalousement ses sources ETS , afin
> d'éviter précisément ce qui se passe dans le monde de l'informatique :
> des produits IP ou autres développés "à la pelle" et "au rabais" qui
> ne fonctionnent que les années bissextiles, quand tout va bien ! avec
> des connexions Internet dont la fiabilité nous donnent l'occasion de
> faire de fréquentes pauses-café... ;-))
Avec cette approche, on pourrait purement et simplement interdire tous
les produits bas-de-gamme. Si ils existent, c'est parce qu'il y a une
demande de la part des clients.
Moi je suis pour donner le choix au client de déterminer jusqu'ou il
est disposé à payer plus pour avoir mieux.
Et puis on s'éloigne du problème initial. Si je développe mes propres
programmes qui tournent sur des BCU2 en utilisant bcusdk, je peux les
programmer et les configurer uniquement avec bcusdk. Pour le reste de
la configuration, je peux le faire uniquement avec ETS et il ne m'est
donc pas possible de gérer la configuration complète à l'aide d'un
seul outil.
A+
Jean-François