Je suis d'accord avec lui. La license AGPL est très contraignante:
- elle ne peut pas être bundlée avec d'autres licenses libres comme la GPLv2 (ce qui est un problème car il y a de bonnes libs en GPLv2) ou des licenses propriétaire (heureusement que linux n'est pas AGPL, car on ne pourrait pas avoir de drivers proprio comme NVIDIA)
- elle oblige à distribuer les sources aux utilisateurs. Pour un CMS/eCommerce, cela pourrait etre un problème, ne fut-ce que pour des raisons de sécurités. (permettre à tous les visiteurs du site de télécharger les sources du site)
En réalité, très peu de logiciels libres utilisent l'AGPL (<1%). Les licenses plus ouvertes et moins contraignantes comme MIT (25%) ou LGPL sont souvent préférées.
Sinon, Alfresco suit un modèle opencore exactement comme Odoo. Ils ont une version community et une version propriétaire. La différence c'est que chez Alfresco, ce sont deux produits différents (et donc la colloboration entre les deux est complexes, voire nulle) et chez Odoo, la version propriétaire s'appuie sur la version open source (des modules en plus) de telles sortes que l'amélioration de la version propriétaire passe nécessaireement par l'amélioration de la version open source.
Si je ne me trompe pas, Alfresco a un modèle un peu bizare où les bugs ne sont pas fixés dans la version communautaire, mais uniquement dans la version enterprise. (ce qui est pour moi en non sens de faire une version open source si elle n'est pas clean) Ils ont donc un modèle de double licensing avec AGPL et license propriétaire.
PS: Odoo est passé de AGPL à LGPL depuis la version 9.
mais quelle raison(s) pour que l'interface mobile, nouveau design, et les autres de la liste soient non libres, à part inciter les gens à prendre du non libre?
La raison est que l'on pense que c'est un modèle plus viable pour l'entreprise et meilleur pour soustenir le produit sur le long terme (version open source et propriétaire). Je suis convaincu que la version open source va grandir beaucoup plus vite avec ce modèle.
Le but n'est pas d'inciter les gens à prendre du non libre, mais d'inciter les gens à payer. Le fait est que si tout est open source, c'est mission impossible de faire payer les gens pour le produit. (c'est possible de faire payer pour du service, mais c'est un autre business modèle qui est moins aligné avec les investissements dans le produit)
Sur le fond, on est tous des passionés de logiciel libre et on continue nos efforts avec la communauté, le travail sur Github, … Même sur la version propriétaire, on cherche à avoir un travail collaboratif avec tous les partenaires. (plus de 1000 personnes ont accès aux sources sur Github)
Si on regarde en nombre de lignes de code, 88% de ce que l'on a produit pour cette version est LGPL, 12% est dans Odoo Enterprise (non libre)
Au final, c'est triste de voir que l'open source n'est pas "viable" du point de vue de l'entreprise, qui se rémunère plutôt sur le non open source
Je suis arrivé au même constat après avoir investi 10 ans dans OpenERP / Odoo (et d'autres softs libres) et plusieurs millions d'eur dans le produit.
Mais en réalité, il faut voir les choses différements: l'open source est un très bon modèle de développement de logiciels, mais ce n'est pas un business modèle pour un éditeur. Et il n'est pas incompatible d'avoir un modèle de développement majoritairement libre, et un business modèle qui crée de la valeur.
Faire coincider les deux (un modèle de développement open source, et un business modèle soutenable sur le long terme) est un fait une très bonne chose. (y compris pour l'open source) Il n'y a pas de mal à faire payer qq'un pour qq chose, c'est même plutôt sain.
La difficulé est d'aligner les intérrêts du produit open source avec ceux de la société commerciale. Chose à laquelle, je crois, on est vraiment bien arrivé avec Odoo (mais il nous a fallu plusieurs années).
Par exemple, pour la comptabilité, la majeure partie des améliorations sont dans la partie communautaire: gestion des écritures, plans de comptes et taxes, cloture fin d'année, factures, paiements, réconciliations, … Bref, toute la refonte de la comptabilité Odoo.
La partie Odoo Enterprise s'appuie sur la version communautaire pour y ajouter quelques fonctionnalités, principalement: interfaces banquaires et rapports dynamiques. Pour les interfaces banquaires, il ne pourrait en être autrement car on travaille avec Yodlee qui est un web-service propriétaire assez cher (plusieurs dizaines de milliers d'EUR par an et qui nous fait payer par compte banque synchronisé). Malheureusement, il n'existe aucune solution libre pour s'interfacer directement avec une banque.
Il en de même pour toutes les applications: la version community est nettement améliorée, et on a ajouté une ou deux fonctions payantes en plus dans la partie entreprise.
Odoo va effectivement vers un modèle opencore, mais on pense que la version Enterprise va pousser la version community vers le haut. Car 1/ elle s'appuie dessus (ce ne sont pas deux produits différents) et 2/ les revenus sont principalement investi en développements sur le produit.
Mais, à l'inverse de la plupart des logiciels opencore (prestashop, magento, sugarcrm), la partie community de Odoo est très importante. La partie libre n'est pas juste un "core", c'est un logiciel de gestion complet et plus fourni que toutes les alternatives libres et propriétaires.
Je suis l'auteur du post. J'ai été un peu vite dans l'écriture, la prochaine fois, je focaliserai la news sur Odoo Community uniquement. Cela conviendra plus aux lecteurs. Méacoulpa.
Sur la partie édition inline, summernote et Raptor ont les mêmes fonctionnalités. Mais summernote est très bien codé et facile à étendre (seulement 1000 lignes de code contre 8000 pour raptor).
Raptor a beaucoup plus de fonctions hautniveau comme l'éditeur de liens, l'éditeur d'images, … Mais, puisque l'on fait un CMS, ces fonctionnalités doivent de toutes façons être implémentées pour le CMS (exemple: l'éditeur de liens doit faire de l'auto-complétion sur les pages existantes du CMS, il doit suivre le style bootstrap du reste du CMS, …).
La version actuelle est basée sur CKEditor pour la partie édition du texte, mais on a dû fortement l'améliorer. Le reste (gestion des blocs de construction, adaptation à bootstrap, …) est du code spécifique.
Il y a deux mois, on a remplacer CKEditor par summernote qui est beaucoup plus light et donc facile à améliorer. On a pu régler pleins de problèmes comme: copier/coller efficace (selon les browsers, le style n'était pas bon), undo/redo qui tient compte des manipulations de blocs, sélection et suppression de textes inter-blocs, …
Il va falloir 9 mois pour que le nom Odoo soit aussi connu que OpenERP. Donc, sur le court-terme, c'est effectivement une mauvaise idée. Voici l'évolution des deux termes sur Google Trends:
Le mot "ERP" dévalorisait complètement OpenERP. On ne souhaite plus être comparé à de tels logiciels car:
les fonctionnalités d'Odoo dépassent complètement les ERPs: sites web, boutiques en ligne, business intelligence, points de vente pour les magasins…
un ERP c'est une usine à gaz, Odoo est simple
Odoo n'est pas un gros logiciel, chaque application peut être installée indépendemment. On peut donc l'utiliser uniquement comme un framework web, une CRM, …
En réalité, Odoo a une qualité de code incroyable pour un logiciel de cette importance.
En chiffres, pour comparer:
Odoo 8 a 190k lignes de code (144k python + 50k JS) en incluant le framework TOUS les modules officiesl (240): comptabilité avec 20 pays, cms, ecommerce, point de vente, crm, GPAO, gestion de stock, une dizaine d'app marketing, …
Django, également en Python, a 176k lignes de code pour uniquement un framework, sans aucun module. Rien que SQLAlchemy fait 46k lignes de plus (alors que l'ORM de Odoo est compté dans les 190k)
Bref, c'est difficile de trouver des logiciels d'une certaine taille avec une qualité technique comparable à celle d'Odoo.
le clone de stackexchange (ayant toutes les features) fait seulement 1000 lignes (écrit en 7 jours). A tester ici: https://www.odoo.com/help/1
la plus grosse app, la comptabilité fait 12k lignes. A comparer, gnucash, qui n'a pas la moitié des fonctions de la comptabilité d'Odoo fait 400k lignes de code.
On est donc loin de l'uzine à gaz, d'autant plus que chaque app est indépendante. Installer qu'une seule application rend le système très simple.
C'est ouvert puisque tout le monde peut faire un pull request.
Mais on ne veut pas que des gens externent commitent directment car on veut maintenir notre processus qualité.
Même dans nos propre employés, la plupart n'ont pas droit d'accès à commiter dans le core, ils doivent passer par le processus de tests et code review.
Une équipe "core" d'une vingtaine de personnes, employés de OpenERP SA, a droit de commit sur le coeur.
Toutes les contributions doivent suivre le même trajet, que ce soit pour les 115 développeurs de OpenERP SA ou la communauté:
Créer une branche et faire un pull request
Cette branche doit être code reviewée par une autre personne que l'auteur
Ensuite cette branche est revue par une équipe de 4 experts en ergonomie et testeurs
Si ces étapes sont passées, une personne de l'équipe core peut merger.
Les bugfixes sont plus simples:
Créer une branche et faire un pull request
Review par un membre de l'équipe coeur
En plus des 260 modules officiels, il y a 4000 modules communautaires. Tout le monde peut faire des modules communautaires et les publier sur la plateforme Odoo. Ces modules ne sont pas vérifiés par les core devs d'Odoo et sont distribués à part.
L'Odoo Community Association (l'OCA) participe à la maintenance de certains de ces modules communautaires. Certains contributeurs se sont regroupés dans une association (l'OCA) afin d'améliorer la qualité des contributions communautaires.
Au passage, en nombre de commits, Odoo est le plus grand projet Python sur github et le 8eme tout languages confondus. (Derriere Linux et mono mais devant rails, php)
C'est in clone open source de eventbrite avec des fonctions plus avancees: calendriers et listed does evenements, vents de tickets, sites des evenements, planning design conferences, publication design slides, blog lie aux evenements, …
La plupart des grandes entreprises ne sont pas dans un mode ERP, où tout doit être changé. Dans ce cas, on rentre par le bas. Au lieu d'essayer de remplacer SAP, on déploie OpenERP dans un département pour un besoin très précis: CRM, gestion de projets, maintenance de machines, etc. Même pour les entreprises qui utilisent SAP, maximum 40% de l'activité est réellement gérée sous SAP.
Une fois que l'entreprise utilise OpenERP, il est assez simple de grandir en interne car OpenERP a des modules pour tous les types de besoins. Pour une entreprise utilisatrice, on peut couvrir de nouveaux besoins très rapidement. Odoo gagne alors du terrain sur les logiciels propriétaires petit à petit.
Pour les entreprises utilisatrices de SAP, on peut aussi rentrer par leurs plus petites filiales. SAP est une uzine à gaz et son déploiement ne se justifie généralement pas sur les petites filiales d'un groupes. Dans ce cas, OpenERP est parfait pour la longue tail car plus agile et moins cher.
Pour avoir plus de fonctionalités sur la fiche produit, il faut passer sur le backend (la petite icone à droite du bouton 'Publier' et choisir 'Edit Product')
Pour l'instant le passage backend-frontend n'est pas encore assez simple, on va améliorer cela.
Vous pouvez créer/modifier les états par défaut dans le backend.
Pour le nom, avez-vous essayé de le changer? En mode édition, il suffit de cliquer dessus et renommer. Il y a aussi une option dans 'Customize' pour mettre le logo au lieu d'un nom.
Pouvez-vous me dire dans quelle opération vous avez ce 'Chargement en cours'?
Pour le feedback sur quelle page on est, normalement, on active le menu courant. Mais cela ne marche pas bien avec toutes les pages. On va vérifier.
L'application de création de site web d'entreprises et l'eCommerce sont en beta. On serait donc très intéressé par avoir votre feedback.
Vous pouvez tester ici: (si vous ne voulez pas vous inscrire pour tester, il y a un lien au dessus du formulaire pour arriver directement dans l'application sans s'inscrire)
La doc est en cours d'écriture car la version 1.0 n'est pas encore sortie. La documentation sera assez courte car cela s'appuie sur la base actuelle de OpenERP.
Ce n'est pas une application supplémentaire, mais un nouveau module OpenERP. (en fait, il y a 16 modules: blogs, events, ecommerce, website builder, …)
Oui, tout est intégré. Toute modification faite sur le site se répercute dans la gestion et toute modification faites dans la gestion se répercute sur le site.
C'est extrêmement simple car il n'y a pas d'interfaces, c'est bien intégré.
Les terminaux de paiements ne sont pas prévus. Souvent d'ailleurs, dans les magasins, le terminal de paiement n'est pas lié au point de vente; la caissière tape le montant sur le terminal de paiement directement.
On l'a déjà fait pour un client en Belgique, ce n'est pas compliqué mais c'est différents par pays et même par matériel (terminal bancontact). Notre interface modulaire permet de le faire, même il faut savoir développer des modules OpenERP pour ce faire.
Je pense que si il y a bcp de demandes sur la campagne, on fera les terminaux de paiements.
Oui, effectivement. Mon propos n'est pas bien formulé. J'aurais du dire, mais aucun n'a une bonne interface hardware qui fonctionne "out-of-the-box", ce qui ne les rends utilisables que par des développeurs/experts linux.
L'objectif de la campagne OpenERP est de faire une solution clé-sur-porte que l'on branche et qui fonctionne pour n'importe quel petit commercant, tout en supportant la majorité des besoins: écrans tactiles, imprimantes à tickets, scanner, …
Une note supplémentaire; le site web d'OpenERP est en anglais, mais l'application est disponible en français. L'ensemble (OpenERP et la POSBOX) est développé par des belges, francophones.
[^] # Re: HS non on ne peut pas tout demander au entreprises pures copyleft
Posté par pinky . En réponse à la dépêche Sortie de Odoo 9. Évalué à 3.
Je suis d'accord avec lui. La license AGPL est très contraignante:
- elle ne peut pas être bundlée avec d'autres licenses libres comme la GPLv2 (ce qui est un problème car il y a de bonnes libs en GPLv2) ou des licenses propriétaire (heureusement que linux n'est pas AGPL, car on ne pourrait pas avoir de drivers proprio comme NVIDIA)
- elle oblige à distribuer les sources aux utilisateurs. Pour un CMS/eCommerce, cela pourrait etre un problème, ne fut-ce que pour des raisons de sécurités. (permettre à tous les visiteurs du site de télécharger les sources du site)
En réalité, très peu de logiciels libres utilisent l'AGPL (<1%). Les licenses plus ouvertes et moins contraignantes comme MIT (25%) ou LGPL sont souvent préférées.
Sinon, Alfresco suit un modèle opencore exactement comme Odoo. Ils ont une version community et une version propriétaire. La différence c'est que chez Alfresco, ce sont deux produits différents (et donc la colloboration entre les deux est complexes, voire nulle) et chez Odoo, la version propriétaire s'appuie sur la version open source (des modules en plus) de telles sortes que l'amélioration de la version propriétaire passe nécessaireement par l'amélioration de la version open source.
Si je ne me trompe pas, Alfresco a un modèle un peu bizare où les bugs ne sont pas fixés dans la version communautaire, mais uniquement dans la version enterprise. (ce qui est pour moi en non sens de faire une version open source si elle n'est pas clean) Ils ont donc un modèle de double licensing avec AGPL et license propriétaire.
PS: Odoo est passé de AGPL à LGPL depuis la version 9.
[^] # Re: utiliser weboob pour l'accès bancaire
Posté par pinky . En réponse à la dépêche Sortie de Odoo 9. Évalué à 2.
Vous pouvez allez directement sur github: http://github.com/odoo/odoo si vous ne souhaitez pas passer par les formulaires.
[^] # Re: Libre vraiment?
Posté par pinky . En réponse à la dépêche Sortie de Odoo 9. Évalué à 4.
La raison est que l'on pense que c'est un modèle plus viable pour l'entreprise et meilleur pour soustenir le produit sur le long terme (version open source et propriétaire). Je suis convaincu que la version open source va grandir beaucoup plus vite avec ce modèle.
Le but n'est pas d'inciter les gens à prendre du non libre, mais d'inciter les gens à payer. Le fait est que si tout est open source, c'est mission impossible de faire payer les gens pour le produit. (c'est possible de faire payer pour du service, mais c'est un autre business modèle qui est moins aligné avec les investissements dans le produit)
Sur le fond, on est tous des passionés de logiciel libre et on continue nos efforts avec la communauté, le travail sur Github, … Même sur la version propriétaire, on cherche à avoir un travail collaboratif avec tous les partenaires. (plus de 1000 personnes ont accès aux sources sur Github)
Si on regarde en nombre de lignes de code, 88% de ce que l'on a produit pour cette version est LGPL, 12% est dans Odoo Enterprise (non libre)
Je suis arrivé au même constat après avoir investi 10 ans dans OpenERP / Odoo (et d'autres softs libres) et plusieurs millions d'eur dans le produit.
Mais en réalité, il faut voir les choses différements: l'open source est un très bon modèle de développement de logiciels, mais ce n'est pas un business modèle pour un éditeur. Et il n'est pas incompatible d'avoir un modèle de développement majoritairement libre, et un business modèle qui crée de la valeur.
Faire coincider les deux (un modèle de développement open source, et un business modèle soutenable sur le long terme) est un fait une très bonne chose. (y compris pour l'open source) Il n'y a pas de mal à faire payer qq'un pour qq chose, c'est même plutôt sain.
La difficulé est d'aligner les intérrêts du produit open source avec ceux de la société commerciale. Chose à laquelle, je crois, on est vraiment bien arrivé avec Odoo (mais il nous a fallu plusieurs années).
[^] # Re: Libre vraiment?
Posté par pinky . En réponse à la dépêche Sortie de Odoo 9. Évalué à 8.
En fait, c'est plus compliqué que cela.
Par exemple, pour la comptabilité, la majeure partie des améliorations sont dans la partie communautaire: gestion des écritures, plans de comptes et taxes, cloture fin d'année, factures, paiements, réconciliations, … Bref, toute la refonte de la comptabilité Odoo.
La partie Odoo Enterprise s'appuie sur la version communautaire pour y ajouter quelques fonctionnalités, principalement: interfaces banquaires et rapports dynamiques. Pour les interfaces banquaires, il ne pourrait en être autrement car on travaille avec Yodlee qui est un web-service propriétaire assez cher (plusieurs dizaines de milliers d'EUR par an et qui nous fait payer par compte banque synchronisé). Malheureusement, il n'existe aucune solution libre pour s'interfacer directement avec une banque.
Il en de même pour toutes les applications: la version community est nettement améliorée, et on a ajouté une ou deux fonctions payantes en plus dans la partie entreprise.
Odoo va effectivement vers un modèle opencore, mais on pense que la version Enterprise va pousser la version community vers le haut. Car 1/ elle s'appuie dessus (ce ne sont pas deux produits différents) et 2/ les revenus sont principalement investi en développements sur le produit.
Mais, à l'inverse de la plupart des logiciels opencore (prestashop, magento, sugarcrm), la partie community de Odoo est très importante. La partie libre n'est pas juste un "core", c'est un logiciel de gestion complet et plus fourni que toutes les alternatives libres et propriétaires.
Je suis l'auteur du post. J'ai été un peu vite dans l'écriture, la prochaine fois, je focaliserai la news sur Odoo Community uniquement. Cela conviendra plus aux lecteurs. Méacoulpa.
[^] # Re: Éditeur WYSIWYG
Posté par pinky . En réponse à la dépêche Campagne de financement communautaire pour Odoo. Évalué à 3.
Sur la partie édition inline, summernote et Raptor ont les mêmes fonctionnalités. Mais summernote est très bien codé et facile à étendre (seulement 1000 lignes de code contre 8000 pour raptor).
Raptor a beaucoup plus de fonctions hautniveau comme l'éditeur de liens, l'éditeur d'images, … Mais, puisque l'on fait un CMS, ces fonctionnalités doivent de toutes façons être implémentées pour le CMS (exemple: l'éditeur de liens doit faire de l'auto-complétion sur les pages existantes du CMS, il doit suivre le style bootstrap du reste du CMS, …).
[^] # Re: Éditeur WYSIWYG
Posté par pinky . En réponse à la dépêche Campagne de financement communautaire pour Odoo. Évalué à 5.
La version actuelle est basée sur CKEditor pour la partie édition du texte, mais on a dû fortement l'améliorer. Le reste (gestion des blocs de construction, adaptation à bootstrap, …) est du code spécifique.
Il y a deux mois, on a remplacer CKEditor par summernote qui est beaucoup plus light et donc facile à améliorer. On a pu régler pleins de problèmes comme: copier/coller efficace (selon les browsers, le style n'était pas bon), undo/redo qui tient compte des manipulations de blocs, sélection et suppression de textes inter-blocs, …
[^] # Re: Odoo, c'est le nouveau OpenERP
Posté par pinky . En réponse à la dépêche Campagne de financement communautaire pour Odoo. Évalué à 4.
Il va falloir 9 mois pour que le nom Odoo soit aussi connu que OpenERP. Donc, sur le court-terme, c'est effectivement une mauvaise idée. Voici l'évolution des deux termes sur Google Trends:
Mais sur le long terme, c'est important pour toutes les raisons citées dans l'article: https://www.odoo.com/blog/odoo-news-5/post/odoo-the-new-openerp-156
Le mot "ERP" dévalorisait complètement OpenERP. On ne souhaite plus être comparé à de tels logiciels car:
# Odoo, c'est le nouveau OpenERP
Posté par pinky . En réponse à la dépêche Campagne de financement communautaire pour Odoo. Évalué à 8.
Pour ceux qui ont manque la nouvelle, Odoo est le nouveau nom de OpenERP: https://www.odoo.com/blog/odoo-news-5/post/odoo-the-new-openerp-156
[^] # Re: Lien code source
Posté par pinky . En réponse à la dépêche Sortie de Odoo 8 (anciennement OpenERP). Évalué à 6. Dernière modification le 20 septembre 2014 à 01:12.
En réalité, Odoo a une qualité de code incroyable pour un logiciel de cette importance.
En chiffres, pour comparer:
Odoo 8 a 190k lignes de code (144k python + 50k JS) en incluant le framework TOUS les modules officiesl (240): comptabilité avec 20 pays, cms, ecommerce, point de vente, crm, GPAO, gestion de stock, une dizaine d'app marketing, …
Django, également en Python, a 176k lignes de code pour uniquement un framework, sans aucun module. Rien que SQLAlchemy fait 46k lignes de plus (alors que l'ORM de Odoo est compté dans les 190k)
Bref, c'est difficile de trouver des logiciels d'une certaine taille avec une qualité technique comparable à celle d'Odoo.
Pour donner des exemples:
l'eCommerce fait 2000 lignes de code seulement: https://www.odoo.com/page/e-commerce
le clone de stackexchange (ayant toutes les features) fait seulement 1000 lignes (écrit en 7 jours). A tester ici: https://www.odoo.com/help/1
la plus grosse app, la comptabilité fait 12k lignes. A comparer, gnucash, qui n'a pas la moitié des fonctions de la comptabilité d'Odoo fait 400k lignes de code.
On est donc loin de l'uzine à gaz, d'autant plus que chaque app est indépendante. Installer qu'une seule application rend le système très simple.
[^] # Re: J'ai trop la flemme de vérifier...
Posté par pinky . En réponse à la dépêche Sortie de Odoo 8 (anciennement OpenERP). Évalué à 5.
Alimentaire: Danone (search OpenERP Danone on Google), Exki
[^] # Re: Who do Odoo ?
Posté par pinky . En réponse à la dépêche Sortie de Odoo 8 (anciennement OpenERP). Évalué à 4.
C'est ouvert puisque tout le monde peut faire un pull request.
Mais on ne veut pas que des gens externent commitent directment car on veut maintenir notre processus qualité.
Même dans nos propre employés, la plupart n'ont pas droit d'accès à commiter dans le core, ils doivent passer par le processus de tests et code review.
[^] # Re: Who do Odoo ?
Posté par pinky . En réponse à la dépêche Sortie de Odoo 8 (anciennement OpenERP). Évalué à 8.
Une équipe "core" d'une vingtaine de personnes, employés de OpenERP SA, a droit de commit sur le coeur.
Toutes les contributions doivent suivre le même trajet, que ce soit pour les 115 développeurs de OpenERP SA ou la communauté:
Les bugfixes sont plus simples:
En plus des 260 modules officiels, il y a 4000 modules communautaires. Tout le monde peut faire des modules communautaires et les publier sur la plateforme Odoo. Ces modules ne sont pas vérifiés par les core devs d'Odoo et sont distribués à part.
L'Odoo Community Association (l'OCA) participe à la maintenance de certains de ces modules communautaires. Certains contributeurs se sont regroupés dans une association (l'OCA) afin d'améliorer la qualité des contributions communautaires.
[^] # Re: Lien code source
Posté par pinky . En réponse à la dépêche Sortie de Odoo 8 (anciennement OpenERP). Évalué à 7.
Au passage, en nombre de commits, Odoo est le plus grand projet Python sur github et le 8eme tout languages confondus. (Derriere Linux et mono mais devant rails, php)
https://twitter.com/fheodoo/status/508820507823570946
# Odoo lance une app de gestion des evenements
Posté par pinky . En réponse à la dépêche Une nouvelle version de l'Agenda du Libre vient d'être déployée!. Évalué à 1.
Pour info, Odoo (anciennement OpenERP) lance une application pour la gestion does evenements: https://www.odoo.com/page/events
C'est in clone open source de eventbrite avec des fonctions plus avancees: calendriers et listed does evenements, vents de tickets, sites des evenements, planning design conferences, publication design slides, blog lie aux evenements, …
[^] # Re: Migration?
Posté par pinky . En réponse à la dépêche Odoo: le nouveau OpenERP, avec 10 millions de plus. Évalué à 10.
On en convainc environ 4 chaque jours.
La plupart des grandes entreprises ne sont pas dans un mode ERP, où tout doit être changé. Dans ce cas, on rentre par le bas. Au lieu d'essayer de remplacer SAP, on déploie OpenERP dans un département pour un besoin très précis: CRM, gestion de projets, maintenance de machines, etc. Même pour les entreprises qui utilisent SAP, maximum 40% de l'activité est réellement gérée sous SAP.
Une fois que l'entreprise utilise OpenERP, il est assez simple de grandir en interne car OpenERP a des modules pour tous les types de besoins. Pour une entreprise utilisatrice, on peut couvrir de nouveaux besoins très rapidement. Odoo gagne alors du terrain sur les logiciels propriétaires petit à petit.
Pour les entreprises utilisatrices de SAP, on peut aussi rentrer par leurs plus petites filiales. SAP est une uzine à gaz et son déploiement ne se justifie généralement pas sur les petites filiales d'un groupes. Dans ce cas, OpenERP est parfait pour la longue tail car plus agile et moins cher.
# Demo en ligne
Posté par pinky . En réponse à la dépêche Odoo: le nouveau OpenERP, avec 10 millions de plus. Évalué à 2.
Pour les décideurs pressés, il y a aussi la demo en ligne: https://www.odoo.com/saas_master/demo
[^] # Re: Besoin de votre feedback
Posté par pinky . En réponse à la dépêche OpenERP tour: découverte de l'application de boutique en ligne. Évalué à 1. Dernière modification le 02 février 2014 à 19:33.
Pour avoir plus de fonctionalités sur la fiche produit, il faut passer sur le backend (la petite icone à droite du bouton 'Publier' et choisir 'Edit Product')
Pour l'instant le passage backend-frontend n'est pas encore assez simple, on va améliorer cela.
Vous pouvez créer/modifier les états par défaut dans le backend.
[^] # Re: Besoin de votre feedback
Posté par pinky . En réponse à la dépêche OpenERP tour: découverte de l'application de boutique en ligne. Évalué à 1.
Merci pour le retour.
Pour le nom, avez-vous essayé de le changer? En mode édition, il suffit de cliquer dessus et renommer. Il y a aussi une option dans 'Customize' pour mettre le logo au lieu d'un nom.
Pouvez-vous me dire dans quelle opération vous avez ce 'Chargement en cours'?
Pour le feedback sur quelle page on est, normalement, on active le menu courant. Mais cela ne marche pas bien avec toutes les pages. On va vérifier.
# Besoin de votre feedback
Posté par pinky . En réponse à la dépêche OpenERP tour: découverte de l'application de boutique en ligne. Évalué à 0.
L'application de création de site web d'entreprises et l'eCommerce sont en beta. On serait donc très intéressé par avoir votre feedback.
Vous pouvez tester ici: (si vous ne voulez pas vous inscrire pour tester, il y a un lien au dessus du formulaire pour arriver directement dans l'application sans s'inscrire)
https://linuxfr.org/redirect/89240
Et, ensuite, mettre votre retour d'expérience dans cette discussion.
# Erreur dans la catégorisation de l'article
Posté par pinky . En réponse à la dépêche OpenERP tour: découverte de l'application de boutique en ligne. Évalué à 2.
Cet article ne devrait pas être dans la catégorie Android, mais plutôt communauté ou business.
[^] # Re: Un minimum de doc ?
Posté par pinky . En réponse à la dépêche OpenERP se lance dans la gestion de contenu et l'eCommerce. Évalué à 6.
La doc est en cours d'écriture car la version 1.0 n'est pas encore sortie. La documentation sera assez courte car cela s'appuie sur la base actuelle de OpenERP.
Vous pouvez déjà télécharger la version en développement ici:
https://code.launchpad.net/~openerp-dev/openobject-server/trunk-website-al
https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-website-al
https://code.launchpad.net/~openerp-dev/openerp-web/trunk-website-al
Ce n'est pas une application supplémentaire, mais un nouveau module OpenERP. (en fait, il y a 16 modules: blogs, events, ecommerce, website builder, …)
[^] # Re: Global
Posté par pinky . En réponse à la dépêche OpenERP se lance dans la gestion de contenu et l'eCommerce. Évalué à 5.
Oui, tout est intégré. Toute modification faite sur le site se répercute dans la gestion et toute modification faites dans la gestion se répercute sur le site.
C'est extrêmement simple car il n'y a pas d'interfaces, c'est bien intégré.
[^] # Re: CB?
Posté par pinky . En réponse à la dépêche La gestion des magasins libre. Évalué à 4.
Les terminaux de paiements ne sont pas prévus. Souvent d'ailleurs, dans les magasins, le terminal de paiement n'est pas lié au point de vente; la caissière tape le montant sur le terminal de paiement directement.
On l'a déjà fait pour un client en Belgique, ce n'est pas compliqué mais c'est différents par pays et même par matériel (terminal bancontact). Notre interface modulaire permet de le faire, même il faut savoir développer des modules OpenERP pour ce faire.
Je pense que si il y a bcp de demandes sur la campagne, on fera les terminaux de paiements.
[^] # Re: Précision
Posté par pinky . En réponse à la dépêche La gestion des magasins libre. Évalué à 3.
Oui, effectivement. Mon propos n'est pas bien formulé. J'aurais du dire, mais aucun n'a une bonne interface hardware qui fonctionne "out-of-the-box", ce qui ne les rends utilisables que par des développeurs/experts linux.
L'objectif de la campagne OpenERP est de faire une solution clé-sur-porte que l'on branche et qui fonctionne pour n'importe quel petit commercant, tout en supportant la majorité des besoins: écrans tactiles, imprimantes à tickets, scanner, …
# Disponible en français
Posté par pinky . En réponse à la dépêche La gestion des magasins libre. Évalué à 7.
Une note supplémentaire; le site web d'OpenERP est en anglais, mais l'application est disponible en français. L'ensemble (OpenERP et la POSBOX) est développé par des belges, francophones.