Oui c’est ça transformé en formulaire avec un bouton « envoyer » … c’est pré-remplis et l’utilisateur décide d’appuyer sur le bouton, tu peux ainsi dire « seules les demandes de support initiées par le formulaire embarqué dans le module seront traitées » et ça permet de cadrer les choses 
je parlais plus de cela :
if (!empty($this->dolistore_id)) { $header = "Accept: application/xml\r\n"; $header.= "Authorization: Basic ".base64_encode($conf->global->MAIN_MODULE_DOLISTORE_API_KEY.':')."\r\n"; $changelog = @file_get_contents( $conf->global->MAIN_MODULE_DOLISTORE_API_SRV.'/api/products/'.$this->dolistore_id, false, stream_context_create(array('http' => array('header' => $header))) ); if ($changelog === false) // not connected return $currentversion; $xmlParser = xml_parser_create(); xml_parse_into_struct($xmlParser, $changelog, $vals, $index); xml_parser_free($xmlParser); foreach ($vals as $val) { if (strlen(($val['value'])) > 2) { if ($val['tag'] == "MODULE_VERSION") $currentversion = $val['value']; if ($val['tag'] == "DOLIBARR_MAX") $lastversion = $val['value']; } }
Bon c’est plus secret du coup
C’est dans l’idée oui
Arf, sauf que la ça fait des requêtes version dolistore à chaque fois …pour extraire uniquement le numéro de version, je n’ai pas trop idée du poids du fichier xml mais il me semble que le ratio signal/bruit peut être amélioré
D’où la proposition de passer par une mini page php « relais » qui peut-être hébergée sur l’infra du développeur et qui fait cache. Ainsi nous sommes économes vis à vis du dolistore (une requête de temps en temps pour actualiser le cache) et décentralisé/résiliant (si dolistore hs on peut gérer de manière autonome)
je n’extrais pas que le numéro de version, mais aussi la version max de dolibarr (il y a d’ailleurs d’autres infos disponibles)
En passant par le dolistore tu es sur des infos diffusés, j’ai déjà une solution de versioning et tout ce qui me limite à utiliser l’api du dolistore c’est son hypothétique refonte…
Ce que je constate c’est que tu te poses des questions que je me suis déjà posée il y a déjà des années quand j’ai commencé à industrialiser la diffusion de mes modules avec la mise en place de changelog, la création de package…
J’ai déjà diffusé le code me permettant de réaliser cela sur ce forum, tu préfères utiliser d’autre solution c’est ton droit.
Je termine d’ailleurs la diffusion d’un scapping me permettant d’actualiser les pages de présentation de mes modules et d’améliorer la page de présentation du dolistore que je trouve moche au possible
Je vais revenir un peu sur le « bruit » qui me gène dans les échanges que l’on a déjà eu, à savoir la récupération d’informations des personnes achetant des modules que toi tu appelles des clients et que moi je considère comme des « sponsors » de mes développements (plus cohérent avec la commercialisation de module open-source)
Pour ma part, il est hors de questions de forcer ou influencer ses personnes à me transmettre des informations sur leur environnement pour vérifier si ils ont « a jour » de leur achat, mes clients ont le droit d’etre anonyme et si l’un d’eux n’a pas la preuve d’un achat réalisé sur le dolistore, je ne vais pas le poursuivre en justice (et d’ailleurs de part la GPL, cela me serait impossible)
Bonjour,
Dans les modules Easya, dans l’onglet support, tu cliques sur le bouton qui dirige vers notre support, tu vas dans nouvelle demande et on récupère des données pour anticiper les demandes qu’on va faire genre :
- version de Dolibarr
- Dolibarr de démarrage
- Version PHP
Etc et éventuellement des constantes spécifiques selon les modules…
Cela permet déjà de débusquer certains problèmes rapidement…
C’est en clair dans la demande de support
Libre à vous d’en utiliser le code si vous voulez !
1 « J'aime »
Top, et donc ça fait des années que ça aurait pu être ajouté dans le module builder vu que l’idée / le besoin / la solution semble partagée… on lance une PR en ce sens histoire que ça ne soit même plus un sujet de discussions dans les années à venir ?
Bien vu !
Un exemple pour celles/ceux qui n’ont pas de modules de chez vous :
@defrance n’ayant pas de modules de chez toi je n’ai jamais pu « voir » ce genre de choses
Et donc si c’est finalement déjà un truc commun, autant le mutualiser et le verser dans module builder (voir mon message précédent) non ?
A ben tien je n’y avait pas pensé, il faut que je retrouve le PR ou je le propose et que l’on m’envoie bouler…
De toute manière, je ne suis vraiment pas une grande fan du module builder qui apporte plus de problème que de solution, surtout en terme de maintenance dans le temps …
Faire croire que n’importe qui va pouvoir créer des modules clé-en-main avec cet outil et au final se rendre compte que cela complexifie le développement (et je précise que j’ai tenté de l’utiliser
pour du dev, au final c’est une vrai galère à chaque monté de version, je suis revenu à une création de module classique), on est plus dans la comm (dolibarr sait faire ceci ou cela) que la VRAI fonctionnalité.
C’est ce que je supporte de moins en moins : la manière dont est géré l’avenir de dolibarr, en particulier cette fixette de vouloir ressembler fonctionnellement à ODOO alors que l’on ferait mieux de se concentrer pour terminer des fonctionnalités existantes qui ont été posée comme des daubes au milieu de nulle part (par exemple la notion de workstation qui n’est pas rattaché à la fabrication…). il y a une expression pour cela : c’est ni fait ni à faire!
Quand on annonce pour la V20 le support de la 8.3 alors qu’il y a encore des warnings en 8.0 sur la 19 (et ne venez pas me dire que c’est à chacun d’apporter sa pierre à l’édifice, je ne compte plus mes correctifs dans ce domaine), à un moment on se rend compte que le radicalisme de certains dogmes comme deux version majeur par an, l’absence de LTS (enfin cela semble bouger après 10 ans à en parler…) et j’en passe sont contre productif.
3 « J'aime »
L’éternelle question du revenu quand on développe du logiciel libre.
Je n’ai pas non plus la réponse parfaite.
J’ai développé la solution e-commerce Thelia pendant pas mal d’années et j’ai ressassé bien souvent cette question. A chaque fois, ça se termine par de la prestation de services.
J’ai fait le test en vendant un module WordPress 60 euros. J’ai généré du revenu avec mais ce n’est pas fameux non plus. Heureusement que je fais de la presta à côté.
J’ai encore écrit un billet sur ce sujet très récemment : Vendre un plugin WordPress
(J’y parle de WordPress mais on peut le transposer facilement pour Dolibarr aussi)
Pour Dolibarr, je n’ai pas encore fait l’expérience. Je développe régulièrement des modules sur mesure pour divers clients mais je n’ai pas tenté encore la vente d’un module comme produit sur le dolistore ou ailleurs.
Finalement, quand je vous lis, j’étais le seul imbécile à ni mettre mes informations de contact dans mes modules, ni proposer de support 
2 « J'aime »
Merci pour ton billet qui résume assez bien ma position actuelle et mon positionnement marché: Des modules qui apporte en plus des revenus de la notoriété, des presta associés à ses modules et enfin de la formation/conseil.
Je connais d’ailleurs une personne qui a développé un module pour chrome qui se vend tres bien et qui avait la même vision.
Mon analyse c’est d’avoir des modules qui une fois développé me demande le moins possible de maintenance, or à chaque mise à jour majeure, je suis bonne pour faire un tour complet sur ceux-ci, bref deux mois de perdu chaque année. Si je met en avant la maintenance pérenne de mes modules c’est aussi pour dire à mes acheteurs qu’ils pourront obtenir les mises à jours lorsqu’il changeront de version, voir « investir » dans une évolution de ceux-ci qu’ils retrouveront ensuite, d’où le fait que j’ai mis une durée assez longue sur le dolistore correspondant au temps moyen entre deux mise à jours (généralement 3 ans).
J’ai enfin fait un travail important d’automatisation et d’industrialisation de module, tests du code, documentation, packaging et diffusion .
Imaginer juste le temps nécessaire pour changer la page de présentation d’une quarante module sur le dolistore (en 5 langues), annoncer les mises à jours de mes modules à 3000 utilisateurs répartie dans une centaine de pays et traduire en 5 langue chacun d’eux…
Mettre en place du Saas serait une solution plus pérenne en terme de revenu mais demande plus de disponibilité, incompatible avec le fait de donner des cours par exemple, je sais d’expérience que l’on ne passe pas de développeur à intégrateur simplement, même si beaucoup pense qu’un développeur sait tout faire… Cela pourrait fonctionner pour certains produits complexe à mettre en place mais cela m’obligerais d’avoir un autre mode de fonctionnement en terme de travail que je ne souhaite pas, ou trouver un partenariat plus poussé avec un intégrateur et remettre en question mon indépendance…
Oui j’imagine qu’avec le nombre de module que tu proposes, un changement majeur de version de Dolibarr te génère beaucoup de travail.
Il y a quelques exemples notamment dans la communauté WordPress d’activités rentables liées à la vente d’un plugin (je pense à un plugin de cache par exemple). Mais c’est quand même assez rare et il faut tomber sur le bon créneau.
Souvent, être le premier suffisamment bon sur un créneau qui touche la plupart des utilisateurs. Peut-être que des opportunités existent encore mais il faut tomber sur la bonne idée, au bon moment et avoir un peu (beaucoup) de chance. C’est bien moins sûr que de vendre de la prestation de qualité, c’est clair. Mais, il faut avouer, cette « automatisation » de revenu, surtout la décorrélation entre temps passé et revenu fait toujours envie.
Ceci dit avec le support, on peut mettre un gros bémol à l’automatisation. Dans le cas de WordPress par exemple, ça bouge beaucoup, les gens ont souvent des tonnes de plugins avec des conflits possibles etc. Bref c’est rarement simple. Je ne me suis pas facilité la tâche en créant une extension d’un module de paiement, lui même une extension de woocommerce, lui-même une extension de WordPress. Imagine le nombre de soucis possibles … Et encore, il touchait relativement peu au côté « front » et donc aux thèmes.
Avec Dolibarr, les conflits et les soucis semblent plus rares quand même.
J’avoue ne pas trop savoir si je dois considérer mon activité comme rentable, cela dégage pas mal de revenu mais j’y consacre quand meme beaucoup de temps à la maintenance de mes modules. Le point positif c’est de choisir quand et ou je code, donc pas trop l’impression de bosser parfois… On est loin du gars qui a développé un truc et récupère de l’argent sans rien faire ensuite, il y a une forme de « rente » certe mais pas aussi importante que l’on pourrait le croire
Comme disait pasteur : "La chance ne sourit qu’aux esprits bien préparés.”
Dans mon cas, j’étais préparé en terme de compétence php/sql/jquery et avais déjà une culture d’industrialisation de développement.
Ensuite je me surprend toujours à sortir de nouveaux modules avec des fonctionnalité inédite après toute ces années (j’en prépare encore un nouveau pour tres bientôt, vous n’êtes juste pas pret).
Pour ce qui est des incompatibilité plus rare … on parle de multicompany? (et je ne critique pas le module, juste son impact sur les modules tiers).
Ah oui, multicompany Effectivement, il est « central » donc peut poser des soucis.
Pour le reste, je suis d’accord. L’industrialisation c’est important c’est clair. J’aime bien automatiser aussi pour gagner du temps. Toutefois, je ne le fais pas forcément au tout départ. J’attends de voir déjà si « ça prend ».
Après, il y a le revenu généré en direct par le module mais aussi la notoriété qu’il apporte et les projets finalement qu’il va apporter (il joue le rôle d’un commercial finalement).
Oui pour la notoriété, le cout faible du module rentre dans cette logique…
Encore faut-il trouver un module qui apporte de la prestation, le cas de myList est pertinent car il demande d’avoir des compétences en SQL et j’ai mis en place une fonction permettant de « livrer » des listes.
Oui le développement peut-être lié au plugin en lui-même ou carrément pour d’autres besoins spécifiques. Le fait d’être reconnu comme développeur de module, c’est un plus pour les clients qui savent que la personne sait ce qu’elle fait.
L’avantage, si c’est de la prestation liée au module, c’est que le périmètre est bien défini. Là encore, ça permet « d’industrialiser » son travail (dans le bon sens du terme).
1 « J'aime »
Bonsoir Charlene,
J’en suis à une vingtaine d’année de support, que ce soit pour des FAI, du support SI niveau 1 et 2 ou même de la TMA. Je peux affirmer plusieurs choses :
-
tout bug/incident nécessite un minimum de qualification avant de parler facturation, surtout quand on se positionne comme fournisseur (éditeur) d’un logiciel/module
-
un client a, malheureusement, toujours raison jusqu’à ce qu’on lui explique en tout transparence pourquoi il se trompe
-
savoir canaliser les cacas nerveux des clients est la clef d’une bonne relation quand on est fournisseur
En soit, sur ce job, tout passe par les composantes de communication : 20% de blabla et surtout 80% de gestuel, qui font qu’on surinterprètera toujours un mail. Dans un message on a 0% de ce qui fait la communication.
Mon invitation à échanger par téléphone reste ouverte.
Bien à vous
Julien
1 « J'aime »
Bonjour,
Je suis interessée par les modules additionnels ou le développement de nouveau modules. Pouvez vous partager avec moi vos modules à vendre?
Merci
