Et pour les cas où il faut diagnostiquer des lenteurs sur un serveur sans rien toucher ni perturber : https://www.youtube.com/watch?v=tYieP2s34YI . Bon courage pour faire ça en C++ :)
Pas besoin de refaire la bataille, le C++ (et le C) est gagnant de quelques pourcents.
Pour les calculs scientifiques, cela se vérifie avec scimark2 (FFT, calcul matriciel… ) http://scribblethink.org/Computer/javaCbenchmark.html
Ne connaissant pas clion, je peux te répondre sur les 3 autres que j'ai pu utiliser pour de vrais projets. Leur debuggers ne rivalisent pas avec celui d'Eclipse, la raison technique est simple : le fait de pouvoir discuter avec la JVM permet de tout contrôler et d'avoir un état complet et fiable de tous les threads, des "stacktraces" et des objets.
Pour JProfiler, c'est exactement la même chose, mais une vidéo sera plus parlante : https://www.youtube.com/watch?v=032aTGa-1XM et ce n'est qu'une toute petite partie des possibilités.
J’apprécie aussi beaucoup d'avoir une vue d'ensemble chronologique (en temps réel) sur les attentes liés aux IO et aux locks.
Pour Eclipse vs les autres, en C++ les IDE ne peuvent pas faire de miracle pour le refactoring ou la complétion à cause principalement des void** et des directives de preprocessing.
Je pense que la seule vraie façon d’appréhender les avantages du trio Java/Eclipse/JProfiler est de l'utiliser dans un projet conséquent.
Le GC est pénalisant quand il prend beaucoup temps, cad quand il y a un très grand nombre d'objets à se débarrasser. Mais la cause reste tout de même un très grand nombre de créations d'objets dans un temps très courts.
Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++ (moins rapide qu'en Java par exemple). De plus, la fragmentation mémoire augmente et l'utilisation de la mémoire vive aussi inutilement.
Avoir un programme performant en C++ c'est surtout s'assurer de minimiser les allocations et d'avoir le plus possible un "layout" mémoire optimal (localité des données).
En Java, il y a tout un tas de GC différents à utiliser en fonction des besoins.
Je pense que les programmeurs utilisant Unity se définissent plus comme programmeurs C#, le moteur Unity étant manipulé en C# à la manière d'une librairie quelconque. Bref, à moins de vouloir recoder un moteur 3D, on peut très bien se passer du C++ ;)
La guerre du "c'est qui le plus rapide" entre C++ et Java est terminée depuis un bout de temps.
Un code bien écrit en Java est en moyenne plus lent (de l'ordre de 10 %) car la JVM doit interpréter les instructions et compiler à la volée les méthodes les plus pénalisantes pour les performances.
Je parle de moyenne ici, il y a des cas (rares) ou Java sera beaucoup plus lent qu'un code ultra optimisé en C++ mais il sait être plus rapide dans certains cas (car la JVM est capable de générer du code machine mieux optimisé car elle a plus de contexte à l'exécution qu'un compilateur), ce n'est pas un mythe.
Les allocations mémoires en Java sont aussi beaucoup plus rapides qu'en C/C++.
Des centaines de benchmarks sont disponibles sur internet pour qui chercherait des chiffres précis.
Concernant le fait qu'il n'y ait pas de 'unsigned' en Java, c'est effectivement embêtant pour l'écriture du code mais en runtime cela n'a pas d'impact. Quand on pense que la gestion des 'unsigned' était prévue en Java 1.0 mais viré à la dernière minute car "pas le temps"…
Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?
Avec 10 ans d’expérience en C++ et 20 en Java, de mon point de vue, le plus gros "gap" entre les 2 n'est pas tant le langage que les outils autours. Rien dans le monde C++ n'égale le trio Java/Eclipse/JProfiler.
Faut-il apprendre C++ de nos jours : OUI. Cela permet d'apprécier Java ;)
900 000 lignes de code, je trouve cela juste gigantesque (c'est des années de travail à temps plein).
Faut-il comprendre de vos explications qu'il a eu 911825 (921630-905) lignes de code supprimées? modifiées?
De ce que je comprend sur https://www.openhub.net/p/gimp , le code actuel de Gimp représente :
- 817267 lignes de code
- 125212 lignes de commentaires
- 190860 lignes vides
D'où une certaine incompréhension (toujours présente).
Ce qui est critiquable c'est le fait de prendre un standard "internationnal" (et pas le meilleur…) et d'en faire sous-truc, cad un standard "franco-allemand", documenté avec des fichiers XLSX. Tout cela sous couvert de la "Norme Sémantique Européenne EN 16931" (380,81 €HT chez Afnor).
Bref, c'était bien trop demandé à notre élite informatique de JUSTE permettre de transférer à l'administration française soit des métadonnées sous forme XML UBL avec la facture soit d'intégrer le XML en fichier intégré (PDF/A). On leur demandait même pas l'effort sur-humain de supporter UBL et CII ;)
J'en profite pour informer les lecteurs que le même développement a été réalisé dans notre ERP OpenConcerto (en natif sans librairie externe). Il sera disponible en standard dans la prochaine version (1.6).
Cela permet d'importer des factures fournisseurs et d'intégrer le xml 'Factur-X' dans le PDF des factures clients.
Des oursins dans les poches? Pas de problèmes, on a pensé à vous : http://code.openconcerto.org
Fichier:
/trunk/OpenConcerto/src/org/openconcerto/erp/config/mappingCompta_fr.xml
Les modules, c'est simple, on les copie dans le dossier "Modules" :)
Ils se gèrent ensuite via Fichiers / Modules.
Java, 6 Go de mémoire vive?!? Ouch.
OpenConcerto fonctionne pourtant parfaitement avec 512Mo avec de grosses bases de données…
A l'heure où je vous lirez ces lignes, mon OpenConcerto avec 11 fenêtres ouvertes depuis 8 heures sur notre base interne avec des milliers de facture, clients, etc… et chargé de 10 ans d'historique : 80Mo de mémoire vive sont utilisés.
Par contre côté navigateur internet, effectivement quelques gigas sont utilisés pour 30 onglets… ;)
Tout fonctionne bien avec les derniers OpenJDK. On a pu voir quelques bugs sur Swing sur la version 7 d'OpenJDK sur Linux, réglés depuis en version 8 d'OpenJDK.
Pas de vidéo à vous fournir, mais une réponse : vous pouvez mettre des droits par utilisateur et ainsi masquer des menus/fonctionnalités.
Pour les utilisateurs récalcitrants, je conseille de commander de manuel et de frapper l'utilisateur avec jusqu'à ce qu'il arrête de se plaindre de ne pas trouver le bon bouton (un annuaire peut convenir à cette tâche).
D'après https://www.ocsinventory-ng.org/fr/#ocs-pro l'accès à la roadmap est payante (offre pro), le lien sur la feuille de route n'est donc pas d'une grande utilité pour le lecteur "lambda".
Le problème que vous chercher à résoudre n'a pas de solution réalisable au cas ou vous l'auriez pas encore compris.
Vous aurez beau avoir un service distant (horodatage, blockchain, Chuck Norris etc…),
il suffit que le logiciel en amont soit modifié pour ne pas envoyer les informations (ou pas les bonnes) pour frauder.
Les plus érudits feront du "man in the middle" pour intercepter les messages.
Dans la pratique, la fraude va être beaucoup plus simple, les fraudeurs utiliseront 2 logiciels, un pour rire et imprimer un ticket de caisse au client, l'autre pour la caisse officielle.
Et pendant ce temps la… d'autres détourneront des milliards légalement :)
Peut être que pour Photoshop, il y 98% de versions piratées, mais dans le monde de la gestion, le piratage est marginal. Une recherche sur "cegid compta torrent" donne le ton :)
Ça fait un peu tâche lors d'un contrôle fiscal, une réflexion de l'inspecteur du type "je ne trouve pas la facture de votre logiciel de comptabilité dans votre grand livre, pourriez vous me fournir la facture?"
La tendance des gros du marché est de migrer vers des logiciels en ligne à abonnement, cf Sage.
tu as bizarrement mis des critères différents ("utilisateurs" contre "utilisateurs légaux") entre chaque ligne.
On peut conclure par "utilisateurs acceptant de payer", et je ne vois pas où tu veux alors en venir : le problème reste de réussir à faire payer dans les 2 cas.
Pirater un logiciel GPL (dans le sens l'utiliser sans payer), c'est déjà plus dur à faire car par définition… gratuit.
Chose également importante dans le monde des entreprises : il est quasi impossible de se passer d'un logiciel de compta/gestion commerciale.
3 choix :
- utiliser un logiciel propriétaire, licence payante (ou pseudo gratuite pour certains mais avec d'autres contreparties)
- pirater un logiciel propriétaire
- utiliser logiciel libre, licence gratuite par définition
Pour 100 utilisateurs d'OpenConcerto, en gros on a 2% x 890 € soit : 1 780 €
Pour 100 utilisateurs de Sage (imaginons un produit à 890 €, 2% de piratage) : 98% x 890 € : 87 220 €
Le delta de revenu est assez important et explique en grande partie (de mon point de vue) pourquoi des logiciels comme Odoo ont besoin de cash pour pouvoir concurrencer les gros ERPs. Ce qui était la question d'origine :)
Assez simplement :
- pour les clients ayant un contrat de maintenance : 0 €
C'est le deal du contrat de maintenance, on assure le client d'avoir un logiciel opérationnel.
- pour les "je vais quand même pas payer un contrat de maintenance pour un logiciel gratuit" : 96 €
Soit 4 de nos jetons de maintenances (ceux bien chers à 24 € le 1/4 d'heure), parce que d'expérience on sait très bien qu'en moyenne on devra y passer une heure dans les abysses du "comment je peux payer?" "ma carte est refusée", "je viens de commander il y a 1 minute et j'ai pas encore reçu mon attestation", "est ce que l'attestation est valable sur Mac", "est ce que je peux revendre mon attestation", etc… :)
En gros, nous misons sur la quantité pour rentrer dans nos frais de développement. Le système de caisse actuel étant sans prétentions, on met plutôt en avant le reste : gestion commerciale, compta, paye…
je suis juste curieux de savoir pourquoi certains prennent ce chemin.
Quelques pistes de réponse basée sur mon expérience (jOpenDocument, jOpenRay, OpenConcerto…) :
- plus le logiciel est important, plus l'équipe de développement se doit d'être importante : sur un ERP comme OpenConcerto, plus de 400 000 lignes de code à maintenir.
- l'utilisateur "lambda" n'a aucune idée du travail que représente "un gros" logiciel et n'est pas prêt à payer en fonction de cela.
- pour un logiciel de gestion, le libre est dans 99% des cas un choix économique
- le 0 coût de licence se transforme vite en dépense 0.
- les contradictions pleuvent pour resté à 0 dépense, ex : "je ne vais quand même pas acheter un manuel pour savoir me servir de ce logiciel gratuit" , "payer pour de l'assistance? non mais c'est de l'arnaque ce logiciel" ou encore "je préfère payer un logiciel propriétaire qui offre 2h de hotline gratuite que de payer une maintenance sur un logiciel libre".
Au final, le logiciel libre comme OpenConcerto doit vivre avec des revenus générés par 2% des utilisateurs.
Le logiciel propriétaire est financé par 100% de ses utilisateurs (légaux).
De ce que je peux voir, ceux qui s'en sorte en 100% libre sont, par ordre croissant :
- ceux qui mises tout sur la monétisation de leurs utilisateurs (wordpress, firefox)
- ceux qui ont réussi à équilibrer taille du projet/logiciel et revenus annexes (iText, OpenConcerto…)
- ceux qui ont une brique logiciel critique pour des grandes sociétés (apache, eclipse, docker, linux…)
Plutôt que de végéter ou de passer son temps à équilibrer les budgets, certains préfèrent proposer un logiciel de base libre et vendre une version premium (concoctée pour migrer le plus possible les utilisateurs de base en utilisateur premium pour quelques détails indispensables). On citera Odoo pour les ERPs, Zimbra pour la messagerie…
Ce qui fait qu'on s'en sort avec OpenConcerto et pas jOpenDocument :
- une offre cloud clef en main, sécurisée et moins chère que toute solution auto-hébergée
- une hotline à la carte au top techniquement et chère (24€ pour 15 mins)
- une extensibilité/personnalisation du logiciel sans limites (hormis celle du chéquier du client)
La version 1.5.1 est maintenant officiellement disponible en téléchargement.
Nous avons fait en sorte d'être le plus clair possible sur l'évolution du logiciel par rapport à la législation, via une page dédiée accessible depuis la page principale.
Pour résumer, sur tous les sujets (compta, gestion, caisse, paye, …), les développements sont faits pour que logiciel respecte la loi en tant et en heure. Quand les textes nous imposent d'impliquer notre responsabilité, nous appliquons les tarifs les plus tassés possibles (DSN : 72€, Loi de finance 2016 : 96€).
Bref, c'est du "détail" pour nous, l'important c'est de sortir la version 2.0 et conquérir le monde :)
I feel like I could… like I could… like I could… TAKE ON THE WORLD!!
[^] # Re: À la fois troll, à la fois fait divers
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 1.
Et pour les cas où il faut diagnostiquer des lenteurs sur un serveur sans rien toucher ni perturber : https://www.youtube.com/watch?v=tYieP2s34YI . Bon courage pour faire ça en C++ :)
[^] # Re: À la fois troll, à la fois fait divers
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3.
Pas besoin de refaire la bataille, le C++ (et le C) est gagnant de quelques pourcents.
Pour les calculs scientifiques, cela se vérifie avec scimark2 (FFT, calcul matriciel… ) http://scribblethink.org/Computer/javaCbenchmark.html
Ne connaissant pas clion, je peux te répondre sur les 3 autres que j'ai pu utiliser pour de vrais projets. Leur debuggers ne rivalisent pas avec celui d'Eclipse, la raison technique est simple : le fait de pouvoir discuter avec la JVM permet de tout contrôler et d'avoir un état complet et fiable de tous les threads, des "stacktraces" et des objets.
Pour JProfiler, c'est exactement la même chose, mais une vidéo sera plus parlante : https://www.youtube.com/watch?v=032aTGa-1XM et ce n'est qu'une toute petite partie des possibilités.
J’apprécie aussi beaucoup d'avoir une vue d'ensemble chronologique (en temps réel) sur les attentes liés aux IO et aux locks.
Pour Eclipse vs les autres, en C++ les IDE ne peuvent pas faire de miracle pour le refactoring ou la complétion à cause principalement des void** et des directives de preprocessing.
Je pense que la seule vraie façon d’appréhender les avantages du trio Java/Eclipse/JProfiler est de l'utiliser dans un projet conséquent.
[^] # Re: Phobie du GC
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 6.
Le GC est pénalisant quand il prend beaucoup temps, cad quand il y a un très grand nombre d'objets à se débarrasser. Mais la cause reste tout de même un très grand nombre de créations d'objets dans un temps très courts.
Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++ (moins rapide qu'en Java par exemple). De plus, la fragmentation mémoire augmente et l'utilisation de la mémoire vive aussi inutilement.
Avoir un programme performant en C++ c'est surtout s'assurer de minimiser les allocations et d'avoir le plus possible un "layout" mémoire optimal (localité des données).
En Java, il y a tout un tas de GC différents à utiliser en fonction des besoins.
Je pense que les programmeurs utilisant Unity se définissent plus comme programmeurs C#, le moteur Unity étant manipulé en C# à la manière d'une librairie quelconque. Bref, à moins de vouloir recoder un moteur 3D, on peut très bien se passer du C++ ;)
[^] # Re: À la fois troll, à la fois fait divers
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 9.
La guerre du "c'est qui le plus rapide" entre C++ et Java est terminée depuis un bout de temps.
Un code bien écrit en Java est en moyenne plus lent (de l'ordre de 10 %) car la JVM doit interpréter les instructions et compiler à la volée les méthodes les plus pénalisantes pour les performances.
Je parle de moyenne ici, il y a des cas (rares) ou Java sera beaucoup plus lent qu'un code ultra optimisé en C++ mais il sait être plus rapide dans certains cas (car la JVM est capable de générer du code machine mieux optimisé car elle a plus de contexte à l'exécution qu'un compilateur), ce n'est pas un mythe.
Les allocations mémoires en Java sont aussi beaucoup plus rapides qu'en C/C++.
Des centaines de benchmarks sont disponibles sur internet pour qui chercherait des chiffres précis.
Concernant le fait qu'il n'y ait pas de 'unsigned' en Java, c'est effectivement embêtant pour l'écriture du code mais en runtime cela n'a pas d'impact. Quand on pense que la gestion des 'unsigned' était prévue en Java 1.0 mais viré à la dernière minute car "pas le temps"…
Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?
Avec 10 ans d’expérience en C++ et 20 en Java, de mon point de vue, le plus gros "gap" entre les 2 n'est pas tant le langage que les outils autours. Rien dans le monde C++ n'égale le trio Java/Eclipse/JProfiler.
Faut-il apprendre C++ de nos jours : OUI. Cela permet d'apprécier Java ;)
[^] # Re: Lignes de code
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à 7. Dernière modification le 26 mai 2018 à 18:16.
900 000 lignes de code, je trouve cela juste gigantesque (c'est des années de travail à temps plein).
Faut-il comprendre de vos explications qu'il a eu 911825 (921630-905) lignes de code supprimées? modifiées?
De ce que je comprend sur https://www.openhub.net/p/gimp , le code actuel de Gimp représente :
- 817267 lignes de code
- 125212 lignes de commentaires
- 190860 lignes vides
D'où une certaine incompréhension (toujours présente).
# Lignes de code
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à -3.
Juste pour pour la migration de vers GTK3 ?
Euh.. comment dire…
https://informationisbeautiful.net/visualizations/million-lines-of-code/
[^] # Re: OpenConcerto
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 10.
Ce qui est critiquable c'est le fait de prendre un standard "internationnal" (et pas le meilleur…) et d'en faire sous-truc, cad un standard "franco-allemand", documenté avec des fichiers XLSX. Tout cela sous couvert de la "Norme Sémantique Européenne EN 16931" (380,81 €HT chez Afnor).
Bref, c'était bien trop demandé à notre élite informatique de JUSTE permettre de transférer à l'administration française soit des métadonnées sous forme XML UBL avec la facture soit d'intégrer le XML en fichier intégré (PDF/A). On leur demandait même pas l'effort sur-humain de supporter UBL et CII ;)
# OpenConcerto
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 8.
J'en profite pour informer les lecteurs que le même développement a été réalisé dans notre ERP OpenConcerto (en natif sans librairie externe). Il sera disponible en standard dans la prochaine version (1.6).
Cela permet d'importer des factures fournisseurs et d'intégrer le xml 'Factur-X' dans le PDF des factures clients.
Notez qu'il existe bien d'autres standards tels que UBL (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl) et GS1. Félicitation donc à notre élite informatique nationale pour avoir créé un nouveau standard.
[^] # Re: ergonomie ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 1.
Des oursins dans les poches? Pas de problèmes, on a pensé à vous :
http://code.openconcerto.org
Fichier:
/trunk/OpenConcerto/src/org/openconcerto/erp/config/mappingCompta_fr.xml
[^] # Re: modules
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 1.
Les modules, c'est simple, on les copie dans le dossier "Modules" :)
Ils se gèrent ensuite via Fichiers / Modules.
Java, 6 Go de mémoire vive?!? Ouch.
OpenConcerto fonctionne pourtant parfaitement avec 512Mo avec de grosses bases de données…
A l'heure où je vous lirez ces lignes, mon OpenConcerto avec 11 fenêtres ouvertes depuis 8 heures sur notre base interne avec des milliers de facture, clients, etc… et chargé de 10 ans d'historique : 80Mo de mémoire vive sont utilisés.
Par contre côté navigateur internet, effectivement quelques gigas sont utilisés pour 30 onglets… ;)
[^] # Re: Développement de spécifs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 1.
https est maintenant activé pour https://code.openconcerto.org/
Merci pour votre retour!
[^] # Re: OpenJDK
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 1.
Tout fonctionne bien avec les derniers OpenJDK. On a pu voir quelques bugs sur Swing sur la version 7 d'OpenJDK sur Linux, réglés depuis en version 8 d'OpenJDK.
[^] # Re: ergonomie ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 3.
Pas de vidéo à vous fournir, mais une réponse : vous pouvez mettre des droits par utilisateur et ainsi masquer des menus/fonctionnalités.
Pour les utilisateurs récalcitrants, je conseille de commander de manuel et de frapper l'utilisateur avec jusqu'à ce qu'il arrête de se plaindre de ne pas trouver le bon bouton (un annuaire peut convenir à cette tâche).
[^] # Re: typo sur le site + questions produit
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 2.
Merci c'est corrigé.
Pour la liaison sur un serveur "externe", OpenConcerto sait faire un tunnel SSL/TLS tout seul.
Devait arriver en 2017, mais arrivera en 2018 : client léger et interface web.
[^] # Re: Coquille
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 1.
Merci! C'est corrigé.
[^] # Re: Offre cloud
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 2.
C'est une base de données dédiée, des performances à gogo, les sauvegardes et la maintenance technique.
[^] # Re: Développement de spécifs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.5.2. Évalué à 3.
Je pense qu'on a un problème de lien depuis qu'on est passé full https :)
Le lien pour le code source est http://code.openconcerto.org/
On va corrigé ça rapidement.
Pour l'API, oui c'est prévu.
# Roadmap
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OCS Inventory Serveur 2.4 est publié. Évalué à 2.
D'après https://www.ocsinventory-ng.org/fr/#ocs-pro l'accès à la roadmap est payante (offre pro), le lien sur la feuille de route n'est donc pas d'une grande utilité pour le lecteur "lambda".
[^] # Re: e-Caisse
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Pastèque v8 et nouvelles de la loi de finances 2016. Évalué à 7.
Le problème que vous chercher à résoudre n'a pas de solution réalisable au cas ou vous l'auriez pas encore compris.
Vous aurez beau avoir un service distant (horodatage, blockchain, Chuck Norris etc…),
il suffit que le logiciel en amont soit modifié pour ne pas envoyer les informations (ou pas les bonnes) pour frauder.
Les plus érudits feront du "man in the middle" pour intercepter les messages.
Dans la pratique, la fraude va être beaucoup plus simple, les fraudeurs utiliseront 2 logiciels, un pour rire et imprimer un ticket de caisse au client, l'autre pour la caisse officielle.
Et pendant ce temps la… d'autres détourneront des milliards légalement :)
[^] # Re: Alternative à Odoo
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Pastèque v8 et nouvelles de la loi de finances 2016. Évalué à 3.
Peut être que pour Photoshop, il y 98% de versions piratées, mais dans le monde de la gestion, le piratage est marginal. Une recherche sur "cegid compta torrent" donne le ton :)
Ça fait un peu tâche lors d'un contrôle fiscal, une réflexion de l'inspecteur du type "je ne trouve pas la facture de votre logiciel de comptabilité dans votre grand livre, pourriez vous me fournir la facture?"
La tendance des gros du marché est de migrer vers des logiciels en ligne à abonnement, cf Sage.
Pirater un logiciel GPL (dans le sens l'utiliser sans payer), c'est déjà plus dur à faire car par définition… gratuit.
Chose également importante dans le monde des entreprises : il est quasi impossible de se passer d'un logiciel de compta/gestion commerciale.
3 choix :
- utiliser un logiciel propriétaire, licence payante (ou pseudo gratuite pour certains mais avec d'autres contreparties)
- pirater un logiciel propriétaire
- utiliser logiciel libre, licence gratuite par définition
Pour 100 utilisateurs d'OpenConcerto, en gros on a 2% x 890 € soit : 1 780 €
Pour 100 utilisateurs de Sage (imaginons un produit à 890 €, 2% de piratage) : 98% x 890 € : 87 220 €
Le delta de revenu est assez important et explique en grande partie (de mon point de vue) pourquoi des logiciels comme Odoo ont besoin de cash pour pouvoir concurrencer les gros ERPs. Ce qui était la question d'origine :)
[^] # Re: Autre exemple de Logiciel Libre et de conformité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Pastèque v8 et nouvelles de la loi de finances 2016. Évalué à 6.
Assez simplement :
- pour les clients ayant un contrat de maintenance : 0 €
C'est le deal du contrat de maintenance, on assure le client d'avoir un logiciel opérationnel.
- pour les "je vais quand même pas payer un contrat de maintenance pour un logiciel gratuit" : 96 €
Soit 4 de nos jetons de maintenances (ceux bien chers à 24 € le 1/4 d'heure), parce que d'expérience on sait très bien qu'en moyenne on devra y passer une heure dans les abysses du "comment je peux payer?" "ma carte est refusée", "je viens de commander il y a 1 minute et j'ai pas encore reçu mon attestation", "est ce que l'attestation est valable sur Mac", "est ce que je peux revendre mon attestation", etc… :)
En gros, nous misons sur la quantité pour rentrer dans nos frais de développement. Le système de caisse actuel étant sans prétentions, on met plutôt en avant le reste : gestion commerciale, compta, paye…
[^] # Re: Alternative à Odoo
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Pastèque v8 et nouvelles de la loi de finances 2016. Évalué à 8.
Quelques pistes de réponse basée sur mon expérience (jOpenDocument, jOpenRay, OpenConcerto…) :
- plus le logiciel est important, plus l'équipe de développement se doit d'être importante : sur un ERP comme OpenConcerto, plus de 400 000 lignes de code à maintenir.
- l'utilisateur "lambda" n'a aucune idée du travail que représente "un gros" logiciel et n'est pas prêt à payer en fonction de cela.
- pour un logiciel de gestion, le libre est dans 99% des cas un choix économique
- le 0 coût de licence se transforme vite en dépense 0.
- les contradictions pleuvent pour resté à 0 dépense, ex : "je ne vais quand même pas acheter un manuel pour savoir me servir de ce logiciel gratuit" , "payer pour de l'assistance? non mais c'est de l'arnaque ce logiciel" ou encore "je préfère payer un logiciel propriétaire qui offre 2h de hotline gratuite que de payer une maintenance sur un logiciel libre".
Au final, le logiciel libre comme OpenConcerto doit vivre avec des revenus générés par 2% des utilisateurs.
Le logiciel propriétaire est financé par 100% de ses utilisateurs (légaux).
De ce que je peux voir, ceux qui s'en sorte en 100% libre sont, par ordre croissant :
- ceux qui mises tout sur la monétisation de leurs utilisateurs (wordpress, firefox)
- ceux qui ont réussi à équilibrer taille du projet/logiciel et revenus annexes (iText, OpenConcerto…)
- ceux qui ont une brique logiciel critique pour des grandes sociétés (apache, eclipse, docker, linux…)
Plutôt que de végéter ou de passer son temps à équilibrer les budgets, certains préfèrent proposer un logiciel de base libre et vendre une version premium (concoctée pour migrer le plus possible les utilisateurs de base en utilisateur premium pour quelques détails indispensables). On citera Odoo pour les ERPs, Zimbra pour la messagerie…
Ce qui fait qu'on s'en sort avec OpenConcerto et pas jOpenDocument :
- une offre cloud clef en main, sécurisée et moins chère que toute solution auto-hébergée
- une hotline à la carte au top techniquement et chère (24€ pour 15 mins)
- une extensibilité/personnalisation du logiciel sans limites (hormis celle du chéquier du client)
[^] # Re: Autre exemple de Logiciel Libre et de conformité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Pastèque v8 et nouvelles de la loi de finances 2016. Évalué à 3.
La version 1.5.1 est maintenant officiellement disponible en téléchargement.
Nous avons fait en sorte d'être le plus clair possible sur l'évolution du logiciel par rapport à la législation, via une page dédiée accessible depuis la page principale.
Pour résumer, sur tous les sujets (compta, gestion, caisse, paye, …), les développements sont faits pour que logiciel respecte la loi en tant et en heure. Quand les textes nous imposent d'impliquer notre responsabilité, nous appliquons les tarifs les plus tassés possibles (DSN : 72€, Loi de finance 2016 : 96€).
Bref, c'est du "détail" pour nous, l'important c'est de sortir la version 2.0 et conquérir le monde :)
[^] # Re: Et pendant ce temps là, économie en se débarrassant de Microsoft en France.
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 49 de l’année 2017. Évalué à 10.
Prédiction du jour:
Nantes va investir 0 € dans LibreOffice, puis va se plaindre de lourdeurs, de problèmes d'ergonomie, de compatibilité…
Utilisateurs mécontents et problèmes techniques récurrents justifieront une marche arrière dans quelques années.
On aura préféré économiser 1.5M€, au lieu de se contenter de 1M€ et d'en investir 0.5M€ dans les logiciels opensource utilisés.
[^] # Re: Coûts
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Un an après, faisons le point sur wallabag.it. Évalué à 4.
Oui, je ne dis pas que c'est de la perte, je signale juste que c'est un coût à prendre en compte.
Si tu passes 200h à tricoter des pulls pour 20€, le gain est bien de 20€, on est d'accord :)