A ce jour, Dolibarr est complètement en anglais tout comme le site web (dolibarr.org) et l'anglais est devenu avec la 2.4 la langue officielle du projet (le français sera maintenau, il y a donc 2 langues officielles), bien qu'il reste encore beaucoup de commentaires de code en français (mais la la bascule se fera au fur et à mesure des modifications). L'expérience que j'ai d'AWStats, autre projet dont je m'occupe, prouve que tu as entièrement raison sur le fait qu'un projet OpenSource a besoin d'être internationnalisé sans concession pour s'imposer (95% des contributions extérieurs sur AWStats viennent de l'étranger alors que le projet était français au départ). C'est pour cela que Dolibarr est un maintenant un projet anglophone à ce jour. Seul le wiki doit encore être traduit en anglais pour que la bascule soit complète (le forum reste bilangue).
Pour ce qui est du PHP4, Dolibarr est bien un développement en PHP Objet, mais de l'objet compatible PHP4. C'est à dire que les méthodes static et privés/publiques sont présentes mais sans le mot clé "static" ou "private" qui ne sont pas utilisés afin d'avoir une compatibilité sur tous les PHP qui représente encore une base très importante chez de nombreux hébergeurs.
Quand à la modularité d'architecture, c'est aujourd'hui cité comme un point fort des utilisateurs Dolibarr. Une installation vierge de Dolibarr se fait nue, c'est à dire qu'après une installation avec la 2.4, on ne trouvera dans le menu que les éléments de configuration des comptes utilisateurs et la page pour activer les modules fonctionnels. Et tous les modules sont optionnels y compris la gestion des tiers qui dans de nombreux ERP fait parti du noyau même de l'application. Une association pourra par exemple n'activer que le module de gestion des adhérents et ne rien avoir en rapport avec les clients ou fournisseurs si elle veut se limiter à ses cotisations d'adhésion ni ne faire de gestion de comptes.
Il est vrai qu'il s'agit plus d'une modularité fonctionnelle, parfois plus technique comme par exemple le nouveau module agenda/calendrier qui a été fait sur ce principe et a pu être développé dans un coin sans concertation des équipes Dolibarr, puis intégrer en quelques minutes dans le CVS sans risques, alors qu'il s'interface pourtant avec tous les autres modules.
En effet, le système des triggers applicatifs (toute action métier déclenche un trigger) que n'importe qui peut intercepter en plaçant un fichier trigger dans un répertoire facilite également grandement cette modularité et l'interfaçage avec tout type de logiciel extérieur. Mais il peut aussi être utilisé pour changer le comportement interne de l'application. Il est ainsi possible de changer le workflow sans toucher au code (comme par exemple faire en sorte qu'une commande soit crée dès qu'une facture est crée ou l'inverse). On utilise les classes métiers existantes pour faire l'insertion et on utilise le mécanisme des triggers pour que cette méthode soit déclenchée, mais on ne touche pas au code existant. Ceci permet de modifier le comportement interne et tout module extérieur peut amener ses triggers pour changer ce comportement.
Il est vrai, je pense, que c'est une approche différente que celle que tu évoques pour OpenERP et que je ne connais pas, Dolibarr ne faisant pas d'altération de base existante mais uniquement des "compléments" (ajout de tables liées à des tables existantes ou simplement nouvelles tables), ajout de code. Mais cela suffit pour permettre de récupérer des modules développés par des éléments extérieurs très rapidement, car cela revient juste à copier des nouveaux fichiers (mais ceci n'était pas encore opérationnel il y a 1 an) et c'est aussi cette nouveauté qui a permis à la société Auguria de fournir un outils de génération de modules complémentaires basés sur UML et acceleo qui peuvent s'ajouter dans Dolibarr sans impact sur le noyau du projet.
Bref, avec la 2.4 un module applicatif extérieur amène ses écrans, ses habilitations, ses entrées dans les menus, ses triggers (pour permettre à d'autres sous module de s'interfacer aussi sans impact sur le module), ses boites pour la page accueil, ses filtres d'exports, ses règles de sélection d'email pour le module d'emailing de masse, etc... Ceci je pense répond au défaut que tu as évoqué que pour qu'un projet récupère l'adhésion de contributeurs, il doit y avoir isolation du code afin de faciliter les intégrations. C'est d'ailleurs l'effort principal qui a été fait dans la 2.4.
Il y a donc eu de très gros progrès en 1 an depuis l'évaluation de Smile, que j'ai d'ailleurs lu avec grand intérêt et que je trouve très bien faite. Je pense qu'à cet époque le choix d'écarter Dolibarr était justifié (pour toutes les raisons que tu as évoqués d'ailleurs). Gageons que pour une prochaine étude, Dolibarr rentre à nouveau dans la course.
Sinon, Dolibarr ne cherchera pas à remplir 100% des besoins comme le font certains ERP, la politique à ce jour et de plutot viser les 95%, car ce sont les 5% manquant qui amènent une forte complexité dans ce genre d'outils pour les intégrateurs et utilisateurs. Hors l'objectif de Dolibarr et de se positionner sur la simplicité, ce qui fait que Dolibarr vise les PME et indépendants mais pas les grosses entreprises qui elles peuvent être couvertes par des ERP plus anciens et ont des besoins plus important.
C'est donc une orientation différente mais volontaire.
PS: Merci pour ton livre blanc, il est très instructif. Si une mise à jour doit être faite dans les années qui viennent, pense à venir refaire un tour du côté de Dolibarr. La croissance d'adhésion de Dolibarr que l'on connait actuellement laisse présager encore de nombreux progès en 2008.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: quid des références?
Posté par Laurent Destailleur (site web personnel) . En réponse à la dépêche Dolibarr ERP/CRM 2.4 stable est disponible. Évalué à 5.
A ce jour, Dolibarr est complètement en anglais tout comme le site web (dolibarr.org) et l'anglais est devenu avec la 2.4 la langue officielle du projet (le français sera maintenau, il y a donc 2 langues officielles), bien qu'il reste encore beaucoup de commentaires de code en français (mais la la bascule se fera au fur et à mesure des modifications). L'expérience que j'ai d'AWStats, autre projet dont je m'occupe, prouve que tu as entièrement raison sur le fait qu'un projet OpenSource a besoin d'être internationnalisé sans concession pour s'imposer (95% des contributions extérieurs sur AWStats viennent de l'étranger alors que le projet était français au départ). C'est pour cela que Dolibarr est un maintenant un projet anglophone à ce jour. Seul le wiki doit encore être traduit en anglais pour que la bascule soit complète (le forum reste bilangue).
Pour ce qui est du PHP4, Dolibarr est bien un développement en PHP Objet, mais de l'objet compatible PHP4. C'est à dire que les méthodes static et privés/publiques sont présentes mais sans le mot clé "static" ou "private" qui ne sont pas utilisés afin d'avoir une compatibilité sur tous les PHP qui représente encore une base très importante chez de nombreux hébergeurs.
Quand à la modularité d'architecture, c'est aujourd'hui cité comme un point fort des utilisateurs Dolibarr. Une installation vierge de Dolibarr se fait nue, c'est à dire qu'après une installation avec la 2.4, on ne trouvera dans le menu que les éléments de configuration des comptes utilisateurs et la page pour activer les modules fonctionnels. Et tous les modules sont optionnels y compris la gestion des tiers qui dans de nombreux ERP fait parti du noyau même de l'application. Une association pourra par exemple n'activer que le module de gestion des adhérents et ne rien avoir en rapport avec les clients ou fournisseurs si elle veut se limiter à ses cotisations d'adhésion ni ne faire de gestion de comptes.
Il est vrai qu'il s'agit plus d'une modularité fonctionnelle, parfois plus technique comme par exemple le nouveau module agenda/calendrier qui a été fait sur ce principe et a pu être développé dans un coin sans concertation des équipes Dolibarr, puis intégrer en quelques minutes dans le CVS sans risques, alors qu'il s'interface pourtant avec tous les autres modules.
En effet, le système des triggers applicatifs (toute action métier déclenche un trigger) que n'importe qui peut intercepter en plaçant un fichier trigger dans un répertoire facilite également grandement cette modularité et l'interfaçage avec tout type de logiciel extérieur. Mais il peut aussi être utilisé pour changer le comportement interne de l'application. Il est ainsi possible de changer le workflow sans toucher au code (comme par exemple faire en sorte qu'une commande soit crée dès qu'une facture est crée ou l'inverse). On utilise les classes métiers existantes pour faire l'insertion et on utilise le mécanisme des triggers pour que cette méthode soit déclenchée, mais on ne touche pas au code existant. Ceci permet de modifier le comportement interne et tout module extérieur peut amener ses triggers pour changer ce comportement.
Il est vrai, je pense, que c'est une approche différente que celle que tu évoques pour OpenERP et que je ne connais pas, Dolibarr ne faisant pas d'altération de base existante mais uniquement des "compléments" (ajout de tables liées à des tables existantes ou simplement nouvelles tables), ajout de code. Mais cela suffit pour permettre de récupérer des modules développés par des éléments extérieurs très rapidement, car cela revient juste à copier des nouveaux fichiers (mais ceci n'était pas encore opérationnel il y a 1 an) et c'est aussi cette nouveauté qui a permis à la société Auguria de fournir un outils de génération de modules complémentaires basés sur UML et acceleo qui peuvent s'ajouter dans Dolibarr sans impact sur le noyau du projet.
Bref, avec la 2.4 un module applicatif extérieur amène ses écrans, ses habilitations, ses entrées dans les menus, ses triggers (pour permettre à d'autres sous module de s'interfacer aussi sans impact sur le module), ses boites pour la page accueil, ses filtres d'exports, ses règles de sélection d'email pour le module d'emailing de masse, etc... Ceci je pense répond au défaut que tu as évoqué que pour qu'un projet récupère l'adhésion de contributeurs, il doit y avoir isolation du code afin de faciliter les intégrations. C'est d'ailleurs l'effort principal qui a été fait dans la 2.4.
Il y a donc eu de très gros progrès en 1 an depuis l'évaluation de Smile, que j'ai d'ailleurs lu avec grand intérêt et que je trouve très bien faite. Je pense qu'à cet époque le choix d'écarter Dolibarr était justifié (pour toutes les raisons que tu as évoqués d'ailleurs). Gageons que pour une prochaine étude, Dolibarr rentre à nouveau dans la course.
Sinon, Dolibarr ne cherchera pas à remplir 100% des besoins comme le font certains ERP, la politique à ce jour et de plutot viser les 95%, car ce sont les 5% manquant qui amènent une forte complexité dans ce genre d'outils pour les intégrateurs et utilisateurs. Hors l'objectif de Dolibarr et de se positionner sur la simplicité, ce qui fait que Dolibarr vise les PME et indépendants mais pas les grosses entreprises qui elles peuvent être couvertes par des ERP plus anciens et ont des besoins plus important.
C'est donc une orientation différente mais volontaire.
PS: Merci pour ton livre blanc, il est très instructif. Si une mise à jour doit être faite dans les années qui viennent, pense à venir refaire un tour du côté de Dolibarr. La croissance d'adhésion de Dolibarr que l'on connait actuellement laisse présager encore de nombreux progès en 2008.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)