LeBouquetin a écrit 1919 commentaires

Sur ton blog tu écris ceci :

J'avais besoin de refondre complètement la bibliothèque pour la rendre plus maintenable, plus facile aussi pour que n'importe quel dev ou intégrateur front s'en empare.

Et d'après le repo github (et d'après le blog aussi, mais c'est l'occasion de mettre le lien vers le code source) la licence est GPL 3.

Cette licence est trop contraignante pour que les dev web s'emparent du projet. L'intérêt d'une lib pour un dev web est d'améliorer son projet. La GPL va contaminer son projet ce qui n'est pas acceptable dans beaucoup de cas.

Je te suggère (si tu peux et veux) de passer en MIT ou LGPL. Tu ne contraindras pas d'éventuels utilisateurs, donc ils intégreront ton player et te feront des retours : rapports de bugs, questions, échanges voire correctifs.

Exemple : pour Tracim on a développé un module python de génération de "preview" qui est indépendant et qui est en MIT. On a des retours de différents utilisateurs, des améliorations, et des gens l'utilisent dans un contexte professionnel où la GPL est rédhibitoire (pour une dépendance).

La contamination de la GPL au programme qui utilise ta lib va imposer au développeur de faire des arbitrages avec d'autres dépendances qui n'ont rien à voir (mais qui ne sont pas compatibles GPL).

GPL et AGPL pour un produit fini sont bien, mais pas pour une lib qui doit/peut/va être intégrée dans des projets variés (si l'objectif est d'étoffer ta base d'utilisateurs et de faire grandir ton projet).

Illustration très concrète : on est en train de réfléchir à l'intégration d'un player audio dans Tracim. En GPL ta lib est écartée d'office car potentiellement incompatible avec la licence de l'ensemble de nos dépendances.

En MIT ou LGPL, c'est ok car ça nous laisse faire ce qu'on veut par ailleurs. Dans les deux cas on contribuera upstream sur les problème que l'on rencontre.

Oui c'est plutot ça.

Je trouve cette idée super bonne et je la note dans un coin pour Tracim…

Si le problème est d'avoir une interface utilisateur qui fait le job en appelant les outils en séquence et que tu as un budget (pas forcément énorme) au lieu d'y passer du temps, on (Algoo) peut te faire un outil qui fasse le job.

On développe des applications web python/javascript ainsi que des outils graphiques en python/tk ou python/qt (avec ou sans installeur).

De ce que je comprends, il faut une interface qui permet de sélectionner un fichier, qui enchaîne les commande et restitue un fichier, ça ne va pas chercher très loin en terme de complexité de dév (donc de coût).

Bien vu ! Je n'avais pas pensé à placer Algoo comme ça ;)

Techniquement je vois juste mal comment garantir une comptabilité correcte sans contraintes fortes

On est bien d'accord :)

ni comment maintenir le demi million de lignes de code Javascript nécessaire à un logiciel qui doit s'occuper de comptabilité, gestion commerciale, paye, etc…

Je pense qu'on n'écrit pas en JS pur ce genre d'outil en mode web

Dolibarr n'est pas un mauvais choix, peut-être que la version web d'OpenConcerto placera ce dernier comme une alternative pour ceux qui ne jurent que par le "zéro install" des applications web. Wait&See.

Il y a une roadmap de sortie prévue pour la version web de OpenConcerto ? Avant de lancer Algoo, j'avais regardé OpenConcerto et je ne l'avais pas retenu mais je ne sais plus pour quelle raison. Il me semble que je n'avais pas une vision complète de ce que j'attendais d'un tel outil. Je n'avais d'ailleurs pas retenu Dolibarr non plus : j'étais parti sans rien :-o

Je ne sais pas / ne suis pas sûr que Dolibarr soit aussi complet par rapport aux problématiques comptabilité, paie … je suis preneur d'un retour si tu connais (aujourd'hui je ne gère pas la paie ni la comptabilité : c'est mon cabinet d'expert comptable qui fait ce travail … mais ça n'est pas figé, en particulier en fonction des recrutements que l'on aura)

Attention à ne pas en venir à dénigrer des projets qui ont une autre stratégie et un autre positionnement (je dis ça par rapport au mode arc-en-ciel qui a une petite coloration négative;)

Personnellement, quand je vois ce que je manipule avec Dolibarr et les outils que manipule ma comptable, OpenConcerto me semble largement dans les standards d'interface sur ce genre d'outil.

Au niveau du code, je n'ai pas regardé, je n'ai pas d'avis.

Par contre je t'ai plussé Guillaume, parce que les "trucs négatifs en mode maxi-flou", outre que j'aime bien l'expression, c'est clair que les deux messages ne sont pas du tout argumentés donc la critique n'est pas constructive - donc à ignorer de mon point de vue.

J'imagine + un logo quelque part (site, générique, etc) que le placement de Tracim dans le scenario de ZeMarmot :-D

Je te contact par email d'ici 10/15 jours. Ça va me laisser le temps de réfléchir un peu plus.

Merci pour tes retours, à très bientôt.

Merci pour cette réponse super détaillée 👍

Niveau sponsoring par une entreprise, comment ça se passe ? C'est possible d'avoir une facture ? Je serai intéressé par sponsoriser votre projet à travers Algoo, mais je ne sais pas comment ça se passe comptablement (a priori on ne peut pas donner : il faut nécessairement une facture - en tout cas c'est comme ça qu'on avait fait avec Grammalecte). Dans le cas de Algoo, un versement annuel serait plus intéressant qu'un paiement récurrent.

Je comprends ça, mais je me rends compte que j'ai mal formulé ma question. Ce que je demandais c'est plutôt : les gens qui vous financent cliquent sur "financer ZeMarmot" ou sur "financer Gimp" ?

D'après ce que je comprends vous n'avez pas encore de quoi vivre … vous faites quoi en parallèle ? Des boulots alimentaires ? Dans quel domaine ?

Jehan, l'argent que vous touchez c'est pour le travail sur Zemarmot ou pour le dev sur Gimp ?

Intéressant. Je ne savais pour gitlab ; ils le font ?

XMPP est toujours là, mais il ne s'est pas imposé comme le support de communication en ligne de référence. Facebook, google etc. ont laissé tomber.

En fait je pense que c'est dans l'autre sens : Google, Facebook ont laissé tomber XMPP et en conséquence (?) XMPP ne s'est pas imposé.

Mais à la réflexion, je me demande si l'échec de XMPP n'est pas arrivé avec le virage "mobile" et les applications de messagerie instantanée type WhatsApp complètement auto-centrées.

Tu as une responsabilité au présent. C'est à dire tant que la boite tourne. Si elle ne tourne plus (c'est une évidence) tu n'es plus responsable.

Tu as une responsabilité vis-à-vis de tes salariés tant qu'ils sont salariés. Donc jusqu'à ce qu'ils soient effectivement licenciés (ou partis).

Si tu les licencies du jour au lendemain sans jamais leur avoir parlé des difficultés, sans les avoir préparés à l'éventualité, c'est un problème.

La responsabilité dans ce cas c'est aussi de s'en rendre compte et de limiter les dégats qui sont inévitables.

Et on est totalement d'accord. C'est très différent de dire "c'est la merde, on fait ce qu'il faut pour limiter les dégats" et "la responsabilité du dirigeant vis-à-vis de ses salariés c'est un point de vue".

Juste pour clarifier : aujourd'hui, je n'ai pas embauché un directeur général comme je l'évoque (mais c'est une piste qui me semble intéressante). En revanche je suis en train de devenir "businessman" et plus "ingénieur logiciel", et pour ça je suis accompagné parce que je ne connais pas vraiment algoo (et moi) a tout intérêt à s'entourer de spécialistes.

Ma réflexion a pris du temps mais ma conclusion a été la suivante : diriger une boîte en restant technique a de fortes chances de brider son évolution : soit tu te concentres sur ce que fait le produit (le quoi), soit tu te concentres sur le comment.

À partir de là j'avais 2 options :

1. embaucher un dirigeant qui me dirait donc ce qu'il faut faire.
2. évoluer vers un vrai rôle de dirigeant, avec les conséquences que ça a.

Aujourd'hui je suis en train de graviter sur un travail marketing, produit, commerce ; je me fais accompagner sur ces sujets parce que c'est ce dont a besoin Algoo (et aussi parce que ça m'intéresse).

Algoo et moi sommes 2 : une personne morale et une personne physique. Il faut bien dissocier les deux.

Pour en revenir à la question, c'est en faisant du réseau (en ligne, hors ligne) que j'ai rencontré des gens qui m'ont accompagné avec plus ou moins de succès ; aujourd'hui toujours à travers cette démarche j'ai rencontré une boîte qui m'apporte exactement ce dont j'avais besoin. Ça ne s'est pas fait du premier coup.

Tu es dans quel coin ? on peut en discuter de vive voix si tu veux.

Ysabeau dit ceci :

Quand on est chef d'entreprise, on a une responsabilité sociale.

Ce à quoi tu réponds :

C'est un point de vue parmi d'autres.

Ça m'interpelle.

Je suis chef d'entreprise, mais en fait c'est même pas la question :

• quand tu es guide de haut-montagne, tu as des gens sous ta responsabilité, même si la sécurité civile peut envoyer des hélicoptères au cas où tu en aurais eu marre et que tu serais descendu seul, en courant.
• quand tu gères des serveurs pour tes clients, tu as une responsabilité, même si contractuellement tu n'as pas signé "je serais respectueux avec vous et je ne vous ferai pas faux bond sur un coup de tête"
• quand tu as une famille, tu as une responsabilité vis-à-vis de ta moitié et de tes enfants.
• quand tu gères une entreprise c'est la même chose.

Je crois pas que ce soit un point de vue d'assumer les responsabilités qui vont avec notre rôle : c'est un moyen d'assurer une société cohérente et pérenne.

Prendre en compte ses responsabilités et les assumer, c'est un pré-requis du contrat social qui permet à une société (au sens humain pas au sens économique) de perdurer, non ?

Tu peux aussi rester président et embaucher un directeur général. Tu continues à gérer l'orientation stratégique de "ton bébé", tu travailles / participes à sa notoriété, sa réalisation mais tu ne gères pas toi-même le quotidien et l'opérationnel.

Je suis en plein dans cette phase de lâcher la technique, et en étant accompagné sur les aspects que je ne maîtrise pas, je trouve ça intéressant. Je fait toujours un peu de code sur des trucs transverses, mais sur le produit Tracim … non.

Après, tout dépend de l'ambition que tu as pour ton produit. D'une manière ou d'une autre, à un moment tu es obligé de grossir si tu as une certaine ambition pour ton projet.

La première étape, de mon point de vue, c'est ce qu'évoque Benoît : être clair et explicite sur ce que tu fais. Ça met l'utilisateur ou le client face à ses responsabilités tout en laissant la porte ouverte à de nouveaux venus.

La seconde étape c'est d'éduquer tes utilisateurs et clients en les incitant à faire les choses selon les règles - y compris si cela peut passer par la vente de prestations.

Le seul de nos clients qui ait été touché par l'incendie OVH (en tout cas pour lequel on est plus ou moins concerné) c'est un client qu'on "tracte" depuis 1 an pour lui proposer un service d'infogérance de ses serveurs. C'est dans notre intérêt - on veut lui vendre une prestation, mais c'est aussi dans le sien : avoir une infrastructure résiliente et des sauvegardes. C'est pas de chance car il s'est enfin décidé juste avant l'incendie, ce qui fait qu'on n'a pas eu le temps de mettre en place ce qu'il fallait :-s

Sérieux ?

tu peux pas dire tout le monde s'en sert sauf s'il a le meme business que moi

Ca se rapproche un peut du modèle Creative Commons - Non Commercial où la licence interdit explicitement certaines utilisations.

Mon problème n'est pas tant là que « comment bien combiner » des morceaux de licence libre et des limitations d'utilisation (et indirectement avoir des retours d'expérience).

Il y a 2 approches qui se trament pour le moment :

• faire des briques libres et d'autres non libres (gratuites et à code source ouvert selon le cas d'utilisation)
• faire du libre soumis à contrat commercial (un peu comme le fait/faisait RedHat)

Je cherche à avoir une vue d'ensemble pour évaluer la situation est les possibilités.

C'est du pain béni ce genre d'incident pour les journalistes :-/

Les sauvegardes fonctionnent. Sur le VPS d'un de mes clients on les a testé / utilisés à plusieurs reprises. C'était un service très bien. C'est juste qu'on avait aucune info sur la localisation des sauvegardes (l'interface est pour le moins épurée) et que dans ces conditions, naïvement je pensais que c'était fait dans les règles de l'art.

À la décharge d'OVH, ça fait un an que je tanne mon client pour lui proposer un service d'infogérance et de ne pas exploiter un serveur "sans filets" (comme beaucoup de clients OVH l'ont fait probablement).

Je suis un peu déçu de OVH sur cette affaire ; après c'est pas la majorité des cas (la plupart de leur infrastructure est bien sauvegardée géographiquement ailleurs) et c'est pas de la faute de OVH si la majorité une bonne partie de ses clients ne se préoccupe pas des sauvegardes.

Maintenant, les sauvegardes obligatoires, systématiques et gratuites, c'est pas crédible. Quand on connait le coût …

Perso, pour des fonctionnalités dans le noyau, je dirais tout simplement que ce n'est pas possible. Pour le reste, tu peux toujours faire des plugins non libres si ça vous paraît acceptable.

Oui c'est probablement le plus simple

Après, franchement, m'est avis que ça va être un peu pénible pour vous de gérer cela sur le long terme.

C'est effectivement le cas ; mais c'est aujourd'hui la seule solution viable que j'ai en tête (dans la mesure où "faire totalement du libre" ne serait pas envisageable - je garde un peu espoir, surtout que le client est ok pour que ça soit libre à terme)

Le libre, on l'oublie souvent, c'est quand même hyper pratique en fait.

On est bien d'accord là dessus.

Ce que je trouve toujours marrant dans ces cas-là, c'est que ça ne leur pose aucun souci d'utiliser librement les fonctionnalités contribuées (directement ou indirectement) par tous vos autres clients.

En fait c'est plus subtile que ça. Le cas est un client qui développe une communauté. Il a besoin d'un outil et s'appuie sur un outil libre. Il finance (largement) le développement de fonctionnalités supplémentaires pour répondre à ses besoins. Il ne voit aucun problème à ce que les fonctionnalités soient utilisées par ailleurs y compris par ses "concurrents" mais pas pour le cas d'utilisation précis.

Ça se comprend dans la mesure où créer une communauté c'est "le premier arrivé est celui qui réussit" et qu'ils perdront en crédibilité si un concurrent fait le même travail au même moment sans avoir dépensé de manière conséquente pour le développement des fonctionnalités en question.

la question n'est pas "je ne veux pas qu'on utilise la fonctionnalité que j'ai financée" mais "je ne souhaite pas que mes concurrents utilisent l'ensemble des fonctionnalités que j'ai fait développer précisément pour me faire concurrence sur ce projet particulier que je mets en place - pour le reste je m'en fiche".

ça pourrait mais c'est contre-productif car ça empêche tout un tas d'utilisateurs d'exploiter la fonctionnalité alors que ce n'est pas ce que demande le client (il veut juste que sur un cas d'usage qu'il envisage ses concurrents ne puissent pas utiliser les développements qu'il a financés - mais il est ok que ses concurrents exploitent les dév qu'il a financés si c'est pour une autre utilisation).

De plus ça empêche toute contribution externe pendant 2 ans sur des fonctionnalités qui sont potentiellement au coeur du logiciel, c'est pas top.

Mais c'est une piste.