J'espère quand même que le mode de fonctionnement par défaut ne consiste pas à faire transiter les informations en clair????
Si c'est pour faire dans le 100% pratique, alors un site web dynamique me semblerait bien meilleur : le "client léger" est le navigateur (celui que l'utilisateur choisit, sur le système d'exploitation qu'il choisit), le protocole est standard (HTTPS). Rien ne vous oblige à rien révéler de vos "secrets industriels", et de toutes manières, vu que vous visez des clients qui privilégient le pratique, la sécurité n'est pas un problème majeur. De plus, vous pourrez réduire énormément les coûts de maintenance, puisque basiquement, vous n'avez plus besoin d'être présent chez le client. Vos sources de dépense seront 1) le développement et la maintenance du logiciel, 2) le support (télépohone, internet, formations...), 3) l'entretien du serveur. Avec une base de clients assez large, j'imagine que le tout ne devrait pas dépasser 100¤/client/an, ce qui doit parfaitement correspondre au budget des TPE. Si vous ajoutez une présence régulière sur site ("J'ai ouvert un email avec un document bizarre et ça marche plus") et le développement d'un client portable, ça va faire exploser le coût du service. J'ai un peu l'impression que votre stratégie commerciale s'appuie sur la naïveté du client sur : 1) la sécurité que vous apportez (quelles sont les garanties offertes? pas grand chose, apparemment) 2) la "liberté" du système (qui ne sera pas libre, ou simplement semi-libre), et 3) la "liberté" du client. Les points 2 et 3 sont essentiel; si votre logiciel (client + serveur) est libre, alors le client sera libre de résilier son contrat avec vous pour aller voir un concurrent moins cher/plus performant. Il sera libre d'installer le soft sur son propre serveur, et de le modifier pour l'adapter à ses besoins. Il sera donc dans une situation de complète autonomie dans ses choix technologiques, et dans le choix de ses fournisseurs. Mais si quelque chose n'est pas libre dans la chaine applicative, alors "peau de zob": vous tenez vos clients par une partie charnue de leur anatomie que je me refuse de citer ici. Vous êtes donc dans une optique de développement fermée, quelque chose qui est justement combattu par le logiciel libre.
Ce que je ne comprends pas vraiment, c'est ce que vous attendez en libérant votre code. Par exemple en libérant la version bêta. Vous vous coupez complètement de tout rapport de bug utile (qui testera si les bugs existent encore avec la version courante, si les patches doivent être modifiés, etc?), et de toutes manières, quiconque intéressé par le côté libre de l'application n'y trouvera pas son compte. Évidemment, vous mettrez d'éventuels concurrents qui utilisent la même application "hors jeu", puisqu'ils devront utiliser une vieille version buggée, et devront eux aussi supporter le coût de la maintenance et de l'évolution du programme (frein à la croissance du secteur, puisque vous dupliquez les efforts de R&D). Vous voulez le beurre, l'argent du beurre et le cul de la crêmière, et à mon avis, vous n'aurez rien du tout. Votre solution "logiciel proprio" + "sécurité boîteuse" + "client captif" n'est pas nouvelle, et même si elle semble immorale à beaucoup d'entre nous ici, elle n'est pas illégale et a soutenu la croissance d'un grand nombre de boîtes informatiques. Je ne me permettrais pas de dire "c'est bien/c'est mal", ce que je peux simplement dire, c'est que ce n'est pas avec ce genre de projets que vous monterez une communauté libre. Et pire encore, je pense que c'est malsain de cultiver l'ambiguité : si votre logiciel est proprio, dites le. Si vous dites qu'il est libre, faites-le. Mais là, c'est vraiment, vraiment pas clair, votre truc.
[^] # Re: Une début d'alternative open source à ... ?
Posté par arnaudus . En réponse à la dépêche XDF (Xul Devis & Factures) : logiciel libre de facturation pour TPE. Évalué à 2.
Si c'est pour faire dans le 100% pratique, alors un site web dynamique me semblerait bien meilleur : le "client léger" est le navigateur (celui que l'utilisateur choisit, sur le système d'exploitation qu'il choisit), le protocole est standard (HTTPS). Rien ne vous oblige à rien révéler de vos "secrets industriels", et de toutes manières, vu que vous visez des clients qui privilégient le pratique, la sécurité n'est pas un problème majeur. De plus, vous pourrez réduire énormément les coûts de maintenance, puisque basiquement, vous n'avez plus besoin d'être présent chez le client. Vos sources de dépense seront 1) le développement et la maintenance du logiciel, 2) le support (télépohone, internet, formations...), 3) l'entretien du serveur. Avec une base de clients assez large, j'imagine que le tout ne devrait pas dépasser 100¤/client/an, ce qui doit parfaitement correspondre au budget des TPE. Si vous ajoutez une présence régulière sur site ("J'ai ouvert un email avec un document bizarre et ça marche plus") et le développement d'un client portable, ça va faire exploser le coût du service. J'ai un peu l'impression que votre stratégie commerciale s'appuie sur la naïveté du client sur : 1) la sécurité que vous apportez (quelles sont les garanties offertes? pas grand chose, apparemment) 2) la "liberté" du système (qui ne sera pas libre, ou simplement semi-libre), et 3) la "liberté" du client. Les points 2 et 3 sont essentiel; si votre logiciel (client + serveur) est libre, alors le client sera libre de résilier son contrat avec vous pour aller voir un concurrent moins cher/plus performant. Il sera libre d'installer le soft sur son propre serveur, et de le modifier pour l'adapter à ses besoins. Il sera donc dans une situation de complète autonomie dans ses choix technologiques, et dans le choix de ses fournisseurs. Mais si quelque chose n'est pas libre dans la chaine applicative, alors "peau de zob": vous tenez vos clients par une partie charnue de leur anatomie que je me refuse de citer ici. Vous êtes donc dans une optique de développement fermée, quelque chose qui est justement combattu par le logiciel libre.
Ce que je ne comprends pas vraiment, c'est ce que vous attendez en libérant votre code. Par exemple en libérant la version bêta. Vous vous coupez complètement de tout rapport de bug utile (qui testera si les bugs existent encore avec la version courante, si les patches doivent être modifiés, etc?), et de toutes manières, quiconque intéressé par le côté libre de l'application n'y trouvera pas son compte. Évidemment, vous mettrez d'éventuels concurrents qui utilisent la même application "hors jeu", puisqu'ils devront utiliser une vieille version buggée, et devront eux aussi supporter le coût de la maintenance et de l'évolution du programme (frein à la croissance du secteur, puisque vous dupliquez les efforts de R&D). Vous voulez le beurre, l'argent du beurre et le cul de la crêmière, et à mon avis, vous n'aurez rien du tout. Votre solution "logiciel proprio" + "sécurité boîteuse" + "client captif" n'est pas nouvelle, et même si elle semble immorale à beaucoup d'entre nous ici, elle n'est pas illégale et a soutenu la croissance d'un grand nombre de boîtes informatiques. Je ne me permettrais pas de dire "c'est bien/c'est mal", ce que je peux simplement dire, c'est que ce n'est pas avec ce genre de projets que vous monterez une communauté libre. Et pire encore, je pense que c'est malsain de cultiver l'ambiguité : si votre logiciel est proprio, dites le. Si vous dites qu'il est libre, faites-le. Mais là, c'est vraiment, vraiment pas clair, votre truc.