Gestion des evolutions de Dolibarr

Bonjour à tous,
Je rebondis sur le post de Charles (defrance)
Autant l’évolution de Dolibarr doit être planifiée, autant elle doit être réfléchie ! En effet, l’intégration d’un client Android n’est pas une priorité. Je passe sur le possible conflit d’intérêt de Dolidroid, ce n’est malheureusement pas le seul.

L’idée de ce topic est d’organiser plus fonctionnellement parlant les évolutions de Dolibarr. On voit clairement les lacunes du produit. Il me semble que la consultation des intégrateurs dans cette réflexion serait une bonne chose.

Pour moi qui suit intégrateur, les prélèvements SEPA auraient du être prévu de longue date afin d’avoir un logiciel exploitable sur ce point rapidement. Les fonctionnalités « fournisseurs » ne sont pas suffisantes, il y a du travail à faire de ce coté. Les fonctionnalités « charges » sont insuffisante dans la réalité. La « compta » arrive il est temps. Beaucoup de modules sont à compléter ou non terminés.

On est donc encore loin d’un logiciel « complet »
Je passe sur la philosophie du libre mais il existe dans le commerce des solutions bon marchées qui font tout ça pour les petites structures.

Bonjour à tous et merci à Philippe de (re)lancer le débat, ce que j’hésitais à faire.

En tant que développeur/intégrateur, je suis également impacté par les problèmes évoqués ici et ailleurs concernant le modèle actuel de gouvernance de dolibarr.

Par contre, je pense qu’il nous faudrait prendre le taureau par les cornes plutôt que débattre régulièrement de ces problèmes sans y apporter de solutions.

  1. Pour le SEPA, c’est de notre faute à tous, développeurs, intégrateurs, utilisateurs, clients, etc de n’avoir pas préparer le sujet en temps et en heure.

Le premier post sur ce sujet ici date du 26 octobre si mes yeux voient clairs… soit il y a environ 3 semaines !

Alors la question (à se poser avant tout développement) est « qui en a besoin ? » et si quelqu’un en a besoin, pourquoi n’a t’il pas réagi avant ?

Je note en tout cas que la réactivité est bonne puisque un développeur s’y est mis.

  1. Pour le rythme de sortie des versions, il avait été évoqué à une époque qu’une équipe se charge de maintenir une version LTS (long term support) qui serait mise à jour tous les 2 ans.

Rassemblons nous entre intégrateurs et prenons le projet en charge ! On pourrait peut-être même en profiter pour y intégrer des modules qui ont dû mal à être admis dans le core, malgré que leurs auteurs le souhaitent.

  1. Pour aller plus loin, je rêve d’un nouveau « dolibarr.pro » qui soit une vitrine plus professionnelle pour les intégrateurs de dolibarr… j’ai des idées sur le sujet mais je suis sûr que vous aussi…

A bientôt pour vous lire,
Christophe

Je rajouterai qu’il n’y a pas que les intégrateurs qu’il faut entendre mais aussi les utilisateurs… Les intégrateurs sont plus disciplinés sur l’aspect retour d’anomalie certe mais une page pour reporter simplement une anomalie détecté aurait du sens (encore plus si derrière il y a une réponse, un correctif ou une évolution). Au passage, quand un client me fait part d’un problème lié au core, je ne passe pas par une ouverture de bug mais post directement le correctif sur la forge.
sinon quelques remarques au sujet des modules disponible sur le dolistore:
Serait-il possible avant la diffusion générale d’une version de transmettre aux développeurs de modules (qui ne sont pas forcément adhérent à l’association) une version dite ‹ gold › un mois avant sa date de diffusion prévue afin que nous puissions valider celle-ci pour nos propres modules. ou alors ajouter ceux-ci à la mailing list du roadmap des versions.
Il me semblerait pertinent enfin de définir une règle pour définir à partir de quand un module commercial devrait être intégré nativement dans le core (un certains nombre de vente, un certains chiffre d’affaire, …).

Il y a plus qu’une page : carrément un forum dédié à cela. Ça ne suffit pas pour toi ???

Tu ne dois pas être le seul. Pour autant, ouvrir un bug permet un suivi plus clair pour tout le monde. Je pense que c’est une erreur, même si j’admets que la procédure peut paraître plus fastidieuse.

Les versions sont disponibles sur github. Et la roadmap est assez claire.
Je suis d’accord cependant avec le fait d’être au moins prévenus à l’avance, dans le style « piqure de rappel » par le biais par exemple de la liste de dev.
Au passage, il me semble que tout développeur/intégrateur devrait à minima s’inscrire sur la liste de dev.
Et je ne vois pas en quoi le fait d’être membre ou non de l’association vient faire quoi que ce soit ici.

Là je ne suis carrément pas d’accord avec toi. Cela relève d’abord de l’envie du développeur de faire intégrer ou pas son module. Et ensuite de l’équipe de développement pour l’accepter ou non.

Je reprend ici le texte (en le modifiant) que j’ai mis dans le topic Prevelement où il n’avait pas ça place.

Les sorties de version de Dolibarr: la Roadmap est fixé depuis maintenant plus de deux an : wiki.dolibarr.org/index.php/Category:RoadMap.
Il serait peux être intéressants de la remettre en question, mais par exemple, la grosse amélioration de la 3.5, c’est le support complet de DoliDroid (application Android pour Dolibarr). Ce qui ne vous concerne peux être pas directement, mais c’est une chouette évolution depuis le temps que l’on parle de cette application.

Si je refait l’histoire la 3.4 est sortie très en retard car nous avions décider de la geler plus tard à cause du DevCamps 2012. Donc la 3.5, n’est ni en avance ni précipitée, elle rattrape juste les deux mois de retard de la 3.4. J’ai demander a reporter la 3.5 car nous voulons faire un autre DevCamps 2013, mais pas avant février 2014, donc non, la 3.5 sortira conformément au planning.

Y a t’il conflit d’intérêt sur la sortie de cette version, pour vendre une application payante (et libre) sur un produit libre et gratuit … Il y a surtout, je pense, une volonté de respecter le planning, le conflit d’intérêt aurait été de ne pas sortir la 3.4 au moins de février et bloquer les autres évolutions jusqu’à ce que soit compatible complètement avec DoliDroid.

Au sujet des modules à racheter à chaque version, c’est les éditeurs de module qui choisissent de vous refaire payer, c’est leur choix, peux être qu’en faisant pression, vous pouvez obtenir plus de flexibilité de leur part sur ce sujet.
Il est fréquent que des dépôt (répository) existe pour chaque module, demander l’accés en lecture a ces dépôt à l’éditeur.

Sur la question des améliorations entre les versions et les souhaits des intégrateurs. C’est simple, si vous, intégrateurs, vous avez des demandes d’évolution qui sont financée, et que vous vous adressez à des développeurs, faite mettre noir sur blanc dans le contrat de service, que vous souhaitez que ces développements soit intégré dans la branche dev de dolibarr (donc pour la future version), et vous ne payer que quand c’est effectivement le cas.

Sur l’intégration des modules dans le core, avec git c’est pas très compliqué, et on travaille tous correctement avec cette outils
Par exemple, conformément a ce qu’on avait dit avec defrance, j’ai essayé d’intégrer Projet v2 gratuit, mais il y avait un travail a faire coté qualité du code du module projet avant de l’intégré. J’ai fait un peu, mais par manque de temps je n’ai pas pu aller au bout des deux démarches. Je garde espoir de trouver le temps de le faire, a moins qu’un autre dev s’en charge. Si cette demarche avait été faite depuis le debut du module, cela fait longtemps qu’il serait dans le core.
J’ai le même problème avec certain de mes module que j’ai laisser traîner sans les intégré par manque de temps ou de volonté (assortiement, import/export multiprix, etc…)

Avec Jfefe, on a essayé de mettre sur les rail un site de financement collaboratif pour de Dolibarr. Ce site n’aura pour but que de mettre en relation les financeur et les intégrateur/développeur, un peu a la sauce codeur.com mais dédier Dolibarr et ceux qui ont le label Partner (oui il faut l’étendre au intégrateur). Ça fait 6 mois qu’il est presque fait, mais on a pas le temps, en ce moment, de le mettre en ligne.

La question de qui a les droits de valider les pull request, aujourd’hui c’est Eldy et Juanjo (2bytes), et Régis, mais il n’intervient plus beaucoup. Quand je vois le nombre de repasse que fait Eldy sur les pull request qu’il a accepter d’intégrée (sur les miennes également ;-), pour ceux qui suive les commit regardez bien ceux qui se nomme « tons of bugs »), je me demande si mettre 4 personnes de plus avec ces droits serait vraiment judicieux.

Aussi utilisons DoliForge. Une pull request qui référence un bug ou une tache de Doliforge est beaucoup plus facilement intégré dans le core que si c’est en vrac. Oui, c’est procédurier et consommateur un peu en temps, mais cela sert vraiment.

Bonjour à tous,

Pour revenir sur « les conflits d’intérets », cela n’a rien à voir avec les sorties de versions précisement. Le soucis c’est que la version de Dolibarr est (il me semble) faite pour fonctionner avec Dolidroid par exemple. Le soucis est que Dolidroid n’est pas gratuit donc effectivement on peut se poser des questions. Où était l’urgence de rendre compatible Dolibarr avec cette appli qui je le rappelle est proposé par Eldy ! Il y a aussi du code pour Google il me semble ! L’optimisation du code de Dolibarr pour des applis payantes ne me parait pas logique. Ce devrait être l’inverse.

J’avoue être un peu déçu par le comportement de certains développeurs qui facturent, facturent et facturent. Je rejoins Charles (defrance) sur le fait qu’a partir d’un certain moment, les modules devraient être intégrés. A voir si c’est en fonction du nombre de ventes, du ca … J’ajouterai que dans ma philosophie, les modules devraient être su le store afin de faire profiter Dolibarr des ventes. Si Dolibarr n’était pas là, les modules non plus.

Lors du Devcamps, il doit y avoir des intégrateurs (non développeurs) qui vont avoir un regard différent très orienté clients et « fonctionnalités » afin de décider des fonctionnalités à finaliser (elles sont nombreuses) et/ou à ajouter.

Les outils. Ils sont effectivement bien complets mais par forcément accéssibles. Le soucis, est qu’un simple utilisateur est très vite refroidi par la complexité et les sujets du forums. ça ne donne pas envie de faire le pas vers Dolibarr. Nombreux sont ceux qui le font seuls.

Enfin les nouvelles versions : En effet, le rythme des sorties est un peu rapide. Surtout quand il faut revoir une partie des modules parce qu’une table à juste changé de nom. Une version majeure tous les 2 ans me parait suffisante. L’intéret est également coté developpeurs pour qui la maintenance sera moindre. Le jeu est de stabiliser et FINIR les modules incomplets (fournisseurs, charges…)

Rares sont les utilisateurs finaux qui ont une réelle philosophie du libre. S’ils doivent payer cher pour Dolibarr à cause des modules sans arrêt à racheter, ils fairont le choix d’autres solutions propriétaires de gescom.

Voilà voilà…à vous lire…

Bonjour,

Je ne viens pas critiquer Dolibarr car je l’utilise tous les jours et toutes mes équipes en sont très content mais je pense quand même qu’avant de le rendre compatible avec Dolidroid , il faudrait se poser quelques questions.

Avez vous vu un CRM sans module mail ?
Avez vous vu un ERP sans gestion de frais de transport ?

Si vous voulez toucher plus d’utilisateurs il faudrait je pense répondre au minimum à l’utilisation normal d’un CRM et après d’un ERP.

Cordialement,

XP

bon je vais tenter de répondre rapidement
sur la page de remonté d’anomalies : le forum c’est sympa mais tous les utilisateurs de dolibarr n’ont pas forcément envie de créer un compte sur un forum (sans parler de son fonctionnement actuel et du fait que l’on post sur quel forum -org/fr/de…)
idem pour la remonté/correction de bug : on gagne en vitesse et en simpliité : on détecte une anomalie, si on est capable on la corrige. Si il faut attendre une semaine ente le moment où on détecte un pb et où il est corrigé, ben on avance pas (surtout si entre-temps il y a gel de la version et que l’évolution doit attendre la prochaine version)
Ensuite pour ce qui est des roadmaps et autre mailing list : c’est quand meme un peu hard pour s’y retrouver
L’idée d’un LTS (long term support) est bonne en particulier pour les intégrateurs et surtout leur clients qui ne sont pas tous des geek avide de derniere version nighlty build), un erp qui se met à jour toute les 3 mois n’est pas exploitable sereinement.
Enfin, que l’on rajoute au core des lignes pour faire fonctionner des modules/produits payant, je trouve cela moyen… a la limite on ajoute des hooks trigger et ensuite on utilise ceux-ci

Et je ne parle même pas du choix technologique imposé de dolidroid (et l’absence d’un dolidIOS) que je trouve tres discutable, j’aurai préféré largement un theme en responsive design.

1 « J'aime »

Bonjour
Pour information, nous travaillons activement sur la réalisation d’un module de prélèvement SEPA pour Dolibarr
Celui-ci devrait être proposé début Février sur Dolistore.

Quelqu’un pourrait-il me dire combien d’exemplaires de Dolibarr sont actuellement utilisés ?

Cordialement

Bonjour,
Que va faire exactement de plus votre module par rapport à la « maj » de Alexandre (Aspangaro) ?
Maintenant vous dire combien de Dolibarr gère le prélèvement c’est une bonne question !
@+

Bonjour
Je ne connais pas cette mise à jour, pouvez vous m’en dire plus N