Vendre son logiciel mais le distribuer ?

Et comment faire du déploiement continu et faire une usine logicielle fiable ?

Le problème exposé dans ce sujet a été résolu.

Salut à tous les zesteux et autres zestueuses agrumes.

Je viens quérir votre savoir et votre bonté ce soir pour répondre à plusieurs interrogations qui me taraudent l'esprit.

Avec une amie, nous avons comme projet de développer, grâce à Python et Django, un outil à destination du personnel encadrant les enfants « handicapés ». Ayant, lors des tests qu'ils sont passer aux enfant, beaucoup de valeurs différentes en fonction de l'âge de l'enfant et d'autres paramètres, les tableaux de bilan sont long à remplir puisque il y a beaucoup de valeurs à comparer, à reporter, etc. Le but serait d'automatiser cette tâche.

J'aimerais beaucoup faire un outil open-source car toute aide, toute contribution ne sera que bénéfique tant pour la qualité du produit que pour nous aider à mieux coder (étant tous les deux débutants avec Django). Seulement voilà : est-il possible de diffuser les sources en restant les seuls possibles à pouvoir commercialiser notre produit ? Ou bien seraient-ce deux choses opposées ?

Deuxièmement, et là nous abordons un point de vue plus technique, tant qu'à démarrer un projet, je tiens à le faire sur de bonnes bases. L'utilisation de Git est déjà sûre et certaine, avec peut-être Github, en fonction des réponses à la question précédente. Mais après, je suis un peu perdu. Voilà un peu la liste des outils que j'ai vu, pour certains que j'ai commencé à tester. Qu'en pensez-vous ?

  • Travis-CI comme serveur d'intégration (validation ou non selon, comme Github, des réponses à la question 1).
  • Docker.
  • Utilisation d'AWS ou d'Azure, en fonction de nos préférences, des retours qu'on en a, de nos tests, etc.
  • SonarQube pour la qualité du code.

J'avoue quand même être perdu dans toute cette foule d'informations, d'outils, de liens, de tutoriels. Alors si vous avez des expériences DevOps, des retours à faire sur des outils ou de bons liens à me fournir, n'hésitez pas, tout avis m'est précieux.

Par exemple, dans les questions que je me pose :

  • Comment s'orchestrent Ansible (ou tout autre type Puppet ou Chef), Docker et disons AWS ? Est-ce que je peux configurer Ansible pour qu'il créé le conteneur Docker et le déploie sur une instance AWS ou Azure ?
  • Je cherche des solutions libres et gratuites si possible (sauf pour AWS / Azure). Ansible me semble mieux sur ce point que Chef et Puppet ? Vous confirmez que c'est un choix pertinent ? CFEngine se place-t-il dans ce cas-là ?
  • Des alternatives intéressantes à SonarQube et à Travis-CI ?

Merci beaucoup à tout ceux qui prendront le temps de répondre.

informaticienzero

est-il possible de diffuser les sources en restant les seuls possibles à pouvoir commercialiser notre produit ?

La réponse courte : légalement, c’est possible, mais pas avec les licences libres existantes, et moralement, ça va très certainement décourager les contributions.

La réponse plus longue en edit.

EDIT : la réponse longue, donc.

Si le libre et l’open source sont des concepts différents, ce n’est pas pour rien : il est parfaitement possible d’être open source sans être libre au sens de la FSF. En gros, il faut une licence qui :

  • autorise la diffusion de votre code source ; note bien que ce n’est même pas totalement nécessaire, tu peux parfaitement mettre tes sources à disposition sans pour autant autoriser d’autres gens à les diffuser ailleurs ;
  • interdise toute diffusion ou utilisation commerciale de votre code source ;
  • autorise la contribution de code (on dira création d’un programme dérivé) à condition de vous accorder l’intégralité des droits patrimoniaux portant sur ces contributions.

C’est une combinaison assez spécifique, et qui n’existe pas dans les licences FOSS que l’on trouve usuellement, qu’elles soient françaises ou américaines. Donc si vous partez sur une solution comme ça, il vous faudra écrire la licence vous-mêmes.

Maintenant se pose la question de la « morale ». Premièrement, si votre code est open source, ça veut dire que les gens peuvent tout à fait se servir de votre logiciel sans vous l’acheter, a fortiori si vous autorisez la diffusion gratuite par des tiers.

Deuxièmement, en autorisant les contribution, mais en vous réservant le droit de commercialiser les versions améliorées, vous dépossédez les contributeurs de leur travail pour en tirer, vous, un bénéfice commercial. Dit autrement, vous demandez aux gens de corriger votre code pour qu’il soit de meilleure qualité et mieux bankable. Ce qui n’encourage évidemment pas à la contribution.

Sachant qu’il n’est pas envisageable d’intéresser les contributeurs aux revenus commerciaux du logiciel, c’est beaucoup trop compliqué à gérer.

+7 -0

D'un point de vue purement légal, ça me semble tout à fait possible d'avoir un outil entièrement open-source commercial. En revanche, c'est peu courant puisqu'il devient techniquement impossible de forcer les gens à payer.

Si tu connais l'anglais, je suis tombé sur un article qui donne quelques exemples de jeu/logiciels qui sont open-source mais payant, ce qui pourra te donner de l'inspiration sur comment gérer la chose : Open-source software is not always freeware. Les commentaires sont aussi assez intéressants.

Salut, ce que tu peux faire aussi c'est faire payer les installations, la maintenance en cas de problème et support utilisateur. Éventuellement le développement de modules spécifiques peut aussi être vendu.

Si tu dev le produit et que tu laisses pas un lien tout prêt pour une installation, je ne suis pas sur que beaucoup de personnel soignant s'amuseront à chercher pour l'installer de leur côté. La plupart des utilisateurs cherchent des solutions clés en main (ou font appel au service informatique si c'est une plus grosse structure).

Tu peux essayer de te positionner sur des petites structures, sans personnel dédié informatique (petit cabinet avec presta info), chez des indépendants (psychologue spécialisé dans le handicap ?), voir même sur des plus grosses structures. Tu les contactes, leur propose un entretien téléphonique pour discuter de l'outil. Ensuite s'ils sont intéressés tu leur proposes une démo (par Teamviewer ou autre) ou en direct tu te déplaces chez eux et tu projettes une démo de ton outil. Puis il faut se faire un nom tranquillement.

Si tu as d'autres infos à donner prochainement sur ton projet je suis preneur, je travaille dans le milieu de la santé (plus particulièrement du handicap).

Bon courage et tiens nous au courant ;)

+1 -0

Le modèle économique mentionné par Aurel_B_ se rapproche de celui adopté par RedHat dans le domaine des distributions Linux.

  • En premier lieu il y a un projet libre et gratuit, destiné à tous les publics, c'est Fedora. RedHat sponsorise Fedora et paye des développeurs pour que le projet avance, mais c'est surtout une communauté bénévole qui porte la distribution. Les innovations sont rapides et fréquentes.
  • Ensuite, il y a le système d'exploitation commercial RedHat Enterprise Linux, orienté entreprises. Il est basé sur Fedora, mais se veut le plus stable possible. RHEL est payant parce que RedHat offre des garanties à ses clients : support personnalisé, binaires "prêts à installer", etc.
  • Tout un chacun peut recompiler gratuitement RHEL et le diffuser. C'est le cas de CentOS, une distrib orientée entreprise, libre et gratuite. Le support pour CentOS est effectué par la communauté, sans les garanties de RedHat.

En gros, transposé à votre projet, on peut imaginer que vous lanciez un projet libre et gratuit, avec des contributeurs externes bénévoles, puis que vous proposiez en parallèle une version payante, plus stable et avec support technique.

  • Les pros bien installés préféreront avoir les garanties de la version payante, surtout qu'ils ne voudront pas s'embêter à configurer eux-mêmes le logiciel. En plus d'offrir un certain confort, payer peut être vu comme une manière de remercier les développeurs (vous) pour leur travail.
  • Ceux qui ne peuvent pas s’offrir la licence pourront se tourner vers le projet ouvert et gratuit. En tant que développeur bénévole, je sais que mon travail ne sert pas qu'à vous enrichir, mais qu'il va servir à des gens qui ont peu de moyens.

Voilà, je ne sais pas si cela fait avancer le schmilblick. Bonne chance pour la suite ;)

Edit : conjugaison

+5 -0

Seulement voilà : est-il possible de diffuser les sources en restant les seuls possibles à pouvoir commercialiser notre produit ?

Bien sûr. A la différence de mes VDD je vais pas pondre un pavé mais répondre par l'exemple.

Si je mets une photo sur flickr, je la diffuse mais je reste le seul à pouvoir la commercialiser*.

Si j'écris un article sur mon blog, je le diffuse mais je reste le seul à pouvoir le commercialiser*.

Si je mets les sources d'un logiciel que j'ai créé sur github, je les diffuse mais je reste le seul à pouvoir les commercialiser*.

* C'est à dire vendre le truc, en vendre les droits d'exploitation, l'exploiter commercialement, etc.

+1 -0

Il y a un paquet de produit open-source où la boite derrière commercialise elle le support ou des version +. En vrac : MongoDb, PyCharm, sentry, Qt, etc.

Si tu vend une version "+", les contributions externent risquent d'etre faible. Si tu vend du support, là il devrait moins y avoir de problèmes. Mais de toute façon vu la niche que tu vise, je doute que tu ai des tonnes de dev externe pour t'aider. Les conditions de commercialisation ça se règle par la licence, tu peux la choisir pour faire ce que tu veux.

Merci à tous pour vos réponses. Je vais discuter avec mon amie dans ce cas, mais pourquoi pas se baser sur un modèle libre avec vente de support ou de fonctionnalités précises. Surtout que si on vend une version clé en main, toute prête, ça intéressera sans doute plus le public visé que de devoir tout configurer par eux-mêmes.

Si tu as d'autres infos à donner prochainement sur ton projet je suis preneur, je travaille dans le milieu de la santé (plus particulièrement du handicap).

Aurel_B_

Oui bien sûr, quels détails veux-tu ? Je suis resté assez vague parce que pour l'instant, le projet l'est encore. On a même pas fait le cahier des charges ni une analyse poussée des besoins.

Dans ce cadre tu peux vendre :

  • Une version "cloud" qui évite toute configuration et apporte certaines fonctionnalités en +,
  • Un support garantie et privilégié,
  • l'ajout de fonctions contre paiement (que tu peux mettre open-source ou pas une fois fini)

Si le prix est pas trop chère tu aura des clients. Surtout pour cette niche où a priori les utilisateurs ne sont pas des informaticiens. Tu peux mettre une grosse partie du code Open-Source. De toute façon pour les utilisateurs ça peut rester rentable : heberger, configurer et maintenir la gestion d'un outils en ligne ça a un coût. A toi de faire en sorte (et de leur expliquer) que c'est plus rentable pour eux de te confier ça. Le coté open-source peut alors devenir un argument commerciale ("même si notre boite ferme vous pourrez toujours le faire installer sur un serveur privée")

Dans ce cadre tu peux vendre :

  • Une version "cloud" qui évite toute configuration et apporte certaines fonctionnalités en +,
  • Un support garantie et privilégié,
  • l'ajout de fonctions contre paiement (que tu peux mettre open-source ou pas une fois fini)

Si le prix est pas trop chère tu aura des clients. Surtout pour cette niche où a priori les utilisateurs ne sont pas des informaticiens. Tu peux mettre une grosse partie du code Open-Source. De toute façon pour les utilisateurs ça peut rester rentable : heberger, configurer et maintenir la gestion d'un outils en ligne ça a un coût. A toi de faire en sorte (et de leur expliquer) que c'est plus rentable pour eux de te confier ça. Le coté open-source peut alors devenir un argument commerciale ("même si notre boite ferme vous pourrez toujours le faire installer sur un serveur privée")

Kje

Ça peut être sympa mais sachant que ce peut être des données patients / enfants / nominatives / de santé ça pourrait bloquer un peu.

Si ce sont des données patients / données de santé, il faut se faire "agréger" comme hébergeur de données de santé, ce qui n'est pas si simple.

De nombreux établissements / professionnels sont frileux sur ce type de données externalisées : peur d'où c'est stocké, risque de piratage, utilisation des données. Si tu as affaire à des psychos c'est pire, certains sont encore en mode je stock les infos en dossier papiers dans une armoire fermée à clé et refuses de participer au DPI (Dossier Patient Informatisé).

Par contre l'avantage serait de proposer un système à prix plus faible éventuellement (à la licence : X€ par compte utilisateur par exemple)

Oui bien sûr, quels détails veux-tu ? Je suis resté assez vague parce que pour l'instant, le projet l'est encore. On a même pas fait le cahier des charges ni une analyse poussée des besoins.

informaticienzero

Quand tu auras plus d'infos, je veux bien savoir ce que fera ton outil plus en détail, on a un établissement qui reçoit des enfants en situation de handicap donc les professionnels pourraient être interessés.

+0 -0

Si tu n'est pas en capacité de fournir un hébergement de qualité pour des dossiers de santé compromettant (ce qui représente un défi) tu peux toujours voir l'outil comme une simple plateforme d'aide à la saisie avant impression ou stockage numérique (pdf) à la charge du client.

Pour l'aspect open-source personnellement je ne l'utilise que dans un cas: produit gratuit,installation payante et développement payant. Tu peux aussi faire payer de la customisation d'interface (logo,couleur,bouton) ou de template (pour que le formulaire ressemble aux ancien déjà archivé dans un hôpital spécifique)

Suivant ta volonté d'aidé ou de gagner (faut trouver ton ratio) tu pourra plus ou moins laisser le produit modulaire et personnalisables afin de limiter ou non la "gratuité sans effort"

Si quelqu'un est bon et gentil, il finira ton logiciel gratuitement et tu ne pourra vivre que delà customisation (mais en même temps c'est le principe d'offrir à la communauté, c'est que tu offre, tune vend pas)

+1 -0

N'oublie pas que cela n'enlève qu'une partie du problème puisque ta sécurité réseaux passe aussi lors des transfert d'informations. Ton serveur doit suivre un certains nombre de norme pour respecter l'anonymat des données.

+1 -0

Hello, je vais répondre sur la partie technique.

  • Si tu t'orientes sur un projet commercial vaudrait mieux partir sur bitbucket (ça t'évitera déjà de payer pour un dépôt privé -tu en aura besoin si tu veux faire les chose bien- ) contrairement à Github
  • En terme de serveur d'intégration, Travis-ci est bien, mais je le trouve un peu limité dans les architectures proposés. Dans la solution gratuite tu n'aura le choix qu'entre Ubuntu 12.10 et os x (qui ne fonctionne qu'une fois sur deux), autant dire que ce n'est pas très représentatif du parc de tes potentiels clients. Je te conseillerai plutôt Shippable qui a de très bon avantages. Mais ceux qui devraient t'intéresser c'est surtout qu'étant basé sur docker tu profites de sa flexibilité. C'est à dire que tu peux builder ton app sur toutes les versions de linux de que tu souhaites (debian, fedora, ubuntu, etc.). Une autre fonctionnalité très utile est qu'a la fin de ton build, tu peux pousser automatiquement ton image docker sur AWS, OpenShift et cie et hop, ton application est mise à jour.

Comment s'orchestrent Ansible (ou tout autre type Puppet ou Chef), Docker et disons AWS ? Est-ce que je peux configurer Ansible pour qu'il créé le conteneur Docker et le déploie sur une instance AWS ou Azure ?

Il y'a des pattern qui essayent de mélanger Ansible (et ses homologues) avec Docker, mais je trouve que les deux se marchent un peu sur les pieds. Ansible, tu fait surtout de la gestion de configuration (pour ton infrastructure et/ou tes middlewares), Docker quant à lui vient marcher sur ses plates bandes tout en faisant un peu plus que Ansible. Je dirais qu'il vaut mieux faire du Ansible + AWS ou Docker + AWS, mais pas les trois ensemble.

Pour ce qui est de l'orchestration, AWS te fournit la doc de déploiement dont tu as besoin. Et si tu utilise Shippable, le déploiement se fait de manière transparente.

Je cherche des solutions libres et gratuites si possible (sauf pour AWS / Azure). Ansible me semble mieux sur ce point que Chef et Puppet ? Vous confirmez que c'est un choix pertinent ? CFEngine se place-t-il dans ce cas-là ?

Puppet et Chef aussi sont gratuit, donc là n'est pas le souci. Ansible à le gros avantage de ne pas avoir besoin qu'un agent soit installé sur la machine distante pour pouvoir déployer en plus du fait que si tu fais du Django, tu fais tu python et que Ansible c'est aussi du python. Donc je dirais que de ce point de vue ton choix est pertinent. Après si tu m'a bien compris plus haut, tu ne devrais même pas avoir besoin de Ansible.

Voilà, j'espère que ça t'aidera.

Merci pour ton retour technique. J'ai quand même une question : en quoi Docker et Ansible se marchent-ils sur les pieds ? J'ai essayé de chercher des articles ou des avis mettant en opposition Docker et Ansible, mais je n'ai trouvé que des tutoriels sur comment les associer.

Pour t'aider, voilà comment je comprends la chose : on utilise Ansible pour gérer ses environnements. Par exemple, on l'utilise pour se connecter à un serveur, installer les dernières versions des logiciels dont on a besoin, dont Docker, puis de récupérer le dernier conteneur et hop, voilà, on a un environnement de test / prod tout prêt. Docker, je le vois plus comme conteneur embarquant l'application et ses dépendances, rien d'autres. Après, ce n'est pas impossible que j'ai mal compris.

Et merci pour Shippable, je regarde ça très vite.

J'ai quand même une question : en quoi Docker et Ansible se marchent-ils sur les pieds ?

Ansible n'est pas là uniquement pour installer en One Shot quelque chose sur ton serveur, il est là pour s'assurer que la configuration que tu souhaites soit déployée correctement sur ton serveur quand le besoin s'en fait sentir et que tout ça est reproductible sur n'importe quel environnement.

Dans ton cas, tu auras un fichier de configuration par environnement (test, de prod, etc.) dans lequel tu dis en gros : installes moi nginx, python 3, postgresql et configure les ainsi. C'est là que tu as besoin d'un dépot privé pour la conf de ta prod. Et du coup, la ou tu te marches avec les pieds avec Docker c'est que tu pourrais très bien avoir un DockerFile pour nginx, une autre pour python 3, une autre pour postgresql, … avec un DockerFile pour ton env de test, prod, etc.. Tes DockerFiles portent donc le même type de configuration que pourrais te porter Ansible.

Tu semble penser que tu as besoin de Ansible pour au moins installer Docker, mais n'oublie pas que tu as besoin de python pour Ansible aussi. Dans tous les cas, si tu t'oriente sur du AWS, pas besoin de devoir installer Docker et tout roule.

D'accord, merci d'avoir pris le temps de m'expliquer tout ça. Je pense m'orienter vers une solution à base de Docker alors, pour deux raisons.

  • Amazon Elastic BeanStalk propose le déploiement à partir d'un conteneur.
  • Mon amie et moi n'avons pas les mêmes systèmes et donc pas les mêmes versions de Django. Je ne sais plus les raisons exactes, mais elle a une version de Django en Python 2 seulement. En utilisant Docker et si j'ai bien compris, on peut passer par-dessus ces différences en développant dans le conteneur (me corriger si besoin).
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte