Openbravo ERP vs Odoo, Actualizaciones

Estaba viendo los vídeos de las Jornadas de Odoo (Antiguo OpenERP) en Granada y en algún momento tocaron el tema de las actualizaciones, lo cual me ha recordado que tenía este punto pendiente en la comparativa entre Openbravo vs OpenERP 2014.

 

A día de hoy hay una diferencia fundamental en cuanto actualizaciones entre estos dos sistemas, Openbravo desde la versión 3.0 utiliza una especie de rolling release y Odoo sigue sacando una versión completamente nueva y disruptiva respecto a la anterior más o menos cada año y medio. En Openbravo la situación era similar a la de Odoo hasta la versión 3.0 pero a partir de ahí armaron una buena base y decidieron que en lugar de planificar grandes cambios a medio o largo plazo iban a ir mejorando paulatinamente esta versión y empezaron a sacar una nueva revisión cada mes con corrección de errores y si se daba el caso con algunas nuevas funcionalidades. Digo empezaron porque desde el segundo trimestre de este año ha cambiado la política y, aunque sigue siendo de rolling release,  han decidido actualizar el mapa de ruta y ahora las publicaciones pasan a ser trimestrales.

En Odoo hasta donde yo se no ha cambiado sustancialmente el proceso de actualización. Saben que tienen un problema porque tener versiones completamente diferentes y en las que se rediseña y reescribe parte del código de módulos enteros crea graves problemas de compatibilidad ya que rompe mucho del código propio que escriben los implantadores. Una de las soluciones propuestas es OCA, ¿y qué es OCA? es una asociación para que los proyectos de la comunidad estén por una parte mejor integrados con el núcleo del producto y por otra parte para repartir los esfuerzo tanto económicos como de talento entre los diferentes socios interesados, con esto consiguen convertir módulos que inicialmente serían propios de un implantador en semioficiales y como consecuencias tanto su diseño como código estarían auspiciados por la propia Odoo y soportados en el proceso de actualización. Como veis en realidad no solventa el problema, lo suaviza un poco.

 

Vayamos a la parte técnica, Openbravo utiliza una librería llamada dbsourcemanager que consigue manejar los cambios en cuanto a diccionario y estructura de la base de datos, y la realidad es que a día de hoy esta herramienta funciona realmente bien. Si una actualización está bien diseñada y testeada el proceso de actualización es prácticamente transparente y de hecho nosotros siempre tenemos a todos nuestros clientes actualizados a la última versión sin grandes problemas.

En cuanto a Odoo, el diseño y estructura de la base de datos se maneja a través del ORM, esto significa que si cambiamos el modelo siempre lo tendremos que hacer mediante el ORM. La consecuencia es que no puedes aplicar la nueva estructura de la base de datos mediante este proceso cuando hay muchos cambios porque se empieza a romper todo, primero porque los módulos empiezan a ser incompatibles con el núcleo del sistema, segundo porque el ORM no es muy fino en como realizar esta actualización sin romper entre otras cosas la integridad referencial, etc. Lo que propone entonces Odoo es que contrates un servicio que consiste en que le envías tu base de datos, le dices de que versión a que versión quieres actualizar y ellos te migran la base de datos. Una vez tienes la nueva base de datos la tienes que probar y si encuentras errores vuelves a enviar repitiendo el proceso de forma iterativa hasta que la nueva base está depurada. Al parecer ya funciona también una herramienta de la comunidad que realiza la misma función, pero siempre tiene que tener mucho cuidado con los módulos no oficiales ya que para estos no suelen existir los scripts.

 

A parte del problema técnico tenemos otro problema que es el cambio y adaptación funcional al nuevo sistema. En Openbravo no hay trauma, como he dicho ellos utilizan la base de la 3.0 y la han ido mejorando con lo que no han habido grandes cambios funcionales y los que hay no requieren un gran esfuerzo en cuanto a formación para adaptarse. En cuanto a Odoo si lo ha habido, empezando porque por ejemplo en la versión 7.0 desapareció el cliente de escritorio y únicamente podías utilizar el web o que el cliente web se ha reescrito varias veces. La buena noticia es que desde la versión 6.1 el cliente web aunque ha sufrido bastantes cambios no han sido tan drásticos como los anteriores. Otra cosa que ha pasado es que han refactorizado algunos módulos y rediseñado otros a nivel funcional con la consecuencia que muchas cosas funcionan de forma completamente diferente o que para acceder a una opción seguramente ahora esté en otro sitio diferente. Desde mi punto de vista Odoo en este sentido ha metido bastante la pata y sigue sin haber una solución definitiva ya que su proceso de desarrollo al parecer va a seguir siendo el mismo.

 

En resumen, en cuanto a este apartado desde mi punto de vista Openbravo ERP lo tiene bastante mejor solventado que Odoo, ahora falta esperar como evoluciona OCA, que va a aportar realmente a este proceso y qué va a hacer Odoo a partir de la versión 8.0, si va a empezar a estabilizar el sistema base o va a seguir con sus ciclos tan agresivos de lanzar nuevas versiones disruptivas respecto a la anterior.

 

Cheli

Openbravo ERP vs OpenERP, lo que dice Google

Hace dos años y medio ya hablamos de las tendencias de google con respecto a Openbravo vs OpenERP, entonces ya adivinamos el crecimiento que estaba teniendo OpenERP y como Openbravo ERP empezaba a caer irremediablemente. Me he puesto a revisar esta tendencia y este ha sido el resultado:

 

Openbravo vs OpenERP

Como véis la tendencia se ha acentuado aún más, curiosamente el punto de inflexión ocurrió justo en el momento que Openbravo empezó a cerrar su código. Por lo que parece la gente prefiere lo libre a lo privativo.

Un saludo.

 

 

Openbravo ERP vs OpenERP, Licencia 2 (derivados y módulos)

Al fin Openbravo ha contestado respecto a los derivados de los módulos privativos, o lo que es lo mismo casi cualquier cosa que no sea el core. Lo que dicen es lo siguiente:

 

  • The web POS is a commercial module under the OBCL, which lets licensees access, modify and deploy the code, but it cannot be redistributed
  •  If the third party  wants to build something on WebPOS, then there are two options
    • The new code is derivative of the WebPOS code, then it has to be licensed under a non-free license terms compatible with WebPOS terms
    • The new code is not a derivative work, but extends (separately) the webPOS functionalities, and it can be licensed as they wish. However, if the end-user then needs both modules (to run the new one), then the end-user needs the OBCL for the webPos part, and the GPL3 for the additional bit. This is the way the licensing of incremental modules works

     

 

  • El WebPOS es un módulo comercial bajo la OBCL, que permite al licenciado el acceso, la modificación y el despliegue del código, pero no la distribución
  •  Si se quiere desarrollar algo sobre el WebPOS, entonces hay dos opciones
    • El nuevo código es un derivado del código del WebPOS, en este caso se tiene que licenciar con una licencia privativa  compatible con la del WebPOS
    • El nuevo código no es un derivado, sinó que extiende (de forma separada) las funcionalidades del WebPOS, entonces puede ser licenciado como quieras. Sin embargo, si el usuario final necesita los dos módulos (para ejecutar el nuevo), entonces el usuario final necesita la OBCL para la parte del WebPOS, y la GPL3 para la parte adicional. Así es como funcona el licenciamiento incremental para los módulos

 

Esto significa que almenos si podría desarrollar módulos libres y seguir mi premisa de que todo el código que desarrolle debe ser libre. No me gusta esta opción, como ya comenté en un apunte anterior es parecido a lo que sucedía con la gente que desarrollaba utilizando java cuando no existía ninguna implementación libre y usable, pero bueno, al menos mi código sigue siendo libre.

 

Nota: Hablan de la GPL3 porque es el ejemplo que nosotros pusimos.

 

Cheli

La extorsión de Openbravo versión 2014

Hoy he tenido como un déjà vu, resulta que Openbravo después de varios años me quiere volver a extorsionar en mi trabajo, pero como decía mi padre «Esta vez habéis pinchado en hueso». Parece que a Openbravo no le ha gustado mi crítica sobre el soporte que dan, mi intención es siempre que se la tomen como una crítica constructiva y me hubiera encantado que la reacción y actitud hubiera sido la de «no somos lo suficientemente buenos, no damos un servicio de excelencia, intentaremos mejorar». Al fin y al cabo lo que yo conté fue la verdad, mi propia experiencia contada en primera persona con el servicio de soporte oficial.

Quiero dejar claro que la crítica nunca iba dirigida a los consultores que atienden las incidencias, de hecho como les dije hace poco en un correo-e, en este sentido el servicio ha mejorado mucho, en el 2008 a veces te contestaba gente que sabía menos que uno mismo sobre el problema a resolver. Ahora los consultores que cotestan son muy profesionales (gracias Jon Alegría y gracias Augusto Mauch), pero ellos mismos reconocen que tienen demasiadas incidencias y que prácticamente me olvidara de que resolvieran un issue fuera del soporte (aún dando los parches añadiría yo) porque esos quedan al final de la cola. Es comprensible y lícito que no resuelvan los issues que abre la comunidad si no tienen tiempo o recursos, ellos se dedican entre otras cosas a dar soporte, pero no lo es tanto que pagues y no te atiendan o lo hagan semanas o meses después. La sensación es que Openbravo invierte mucho en la parte comercial y descuida mucho a su equipo técnico y de soporte, la consecuencia es que su soporte tiene muchas deficiencias y una calidad justita en cuanto a atención y tiempos de respuesta aunque al final cuando consigues que te atiendan lo hacen correctamente. La consecuencia de todo esto es que termine por no recomendar su soporte a mis clientes.

 

En lugar de ponerse en contacto conmigo lo que han hecho es lo de siempre, han dado por sentado que mi crítica personal venía de parte de uno de mis clientes, que además es uno de sus socios, y se han puesto en contacto con el gerente general para que me ¿presione?. Por lo que me han contado lo que les ha dolido es que yo no recomiende la versión profesional o que mi cliente no la utilice para algunos de sus proyectos aún siendo socio de Openbravo, lo han considerado como un caso grave, pedían una explicación y que la dirección ya estaba al tanto de todo. Lo extraño es que todo esto viene de un mero comercial, al parecer el enlace a mi bitácora se lo había pasado el CTO. Lo que no entiendo es como teniendo mis datos de contacto que están publicados aquí mismo no se ponga en contacto conmigo para hablar sobre este tema en lugar de hacerlo infundadamente y injustamente con uno de mis clientes para acusarle de cosas de las que nada tiene que ver.

 

Siguen con sus tácticas de siempre pero bueno, no se dan cuenta que desde el 2010 yo no trabajo para nadie, soy mi propio jefe, y que ya no pueden hacer lo que me hicieron en el 2008 y 2009. No soy su socio y no pueden hacer nada para evitar que yo opine lo que considere oportuno en mi bitácora personal sobre su producto y su proyecto. Eso sí, siempre intentaré ser lo más objetivo posible y siempre sin faltar a la verdad.

 

Un saludo.

 

Cheli

Calidad del Soporte de Openbravo 2

Tenía mucha curiosidad por saber cual era la tabla de nivel de soporte de Openbravo y finalmente he tenido acceso a ella. Cómo a Openbravo le gusta mucho compararse con Red Hat me he puesto a mirar una y otra a ver que diferencias había.

 

Red Hat SLA

 

Openbravo SLA

 

A simple vista se ve la influencia de Red Hat, Openbravo copia el mismo esquema pero lamentablemente ahí terminan las similitudes. Mientras que los tiempos de respuesta de Red Hat se miden en horas o días los de Openbravo se miden en días o semanas, y yo puedo dar fe de ello. Y no creais que es porque el soporte de Openbravo es más barato, más bien lo contrario. Por poner un ejemplo, la suscripción de Red Hat Enterprise Linux Server para 2 sockets, 1 nodo físico o 2 virtuales en la modalidad de suscripción estándar cuesta $799 al año. Una suscripción de Openbravo estándar para el back-office cuesta $500 al año por usuario concurrente, si le añades el WebPos privativo entonces son $175 más por terminal y año.

A ver si en una próxima ocasión comparamos los precios de Openbravo con los de OpenERP. Ya os adelanto que en este sentido los dos van muy parejos, eso sí, las propuestas son diferentes, OpenERP ofrece soporte sobre su sistema tanto alojado en su nube como en una instalación en nuestras dependencias mientras que Openbravo sólo ofrece la segunda opción, almenos hasta donde yo se.

 

Cheli

El WebPos privativo de Openbravo

Openbravo tiene una solución de Punto de Venta o POS por sus siglas en ingles, este tipo de software en España se suele conocer como un TPV (Terminal Punto de Venta).

La versión antigua del TPV de Openbravo estaba desarrollada en Java para escritorio y tenía licencia GPL, ahora la nueva versión que utiliza tecnología web tiene la licencia privativa de Openbravo. Hasta ahora no le había hecho mucho caso porque no había tenido la necesidad, pero hace unas semanas me ofrecieron participar en otro proyecto aquí en Ecuador y necesitan el TPV. Lo primero que hice fué releerme la licencia para ver si cabía la posibilidad de poder almenos desarrollar módulos propios bajo una licencia libre de nuestra elección, de hecho es lo que podemos hacer sobre el core de Openbravo ERP gracias a que este está bajo la MPL (Mozilla Public License 1.1). Cuál ha sido mi sorpresa al comprobar que esta licencia especifica que se puede usar, reproducir y modificar el trabajo original, y hacer derivados pero siempre limitado al propósito de tu propio negocio. Por si acaso en otro punto especifican que no se puede redistribuir, sólo en caso de que sea para el propósito del negocio y ponen algunos ejemplos como demos, presentaciones, etc y simpre que tengas bien controlado a quíen se lo cedes.

Una de las premisas que pongo siempre para participar en cualquier proyecto es justamente que todo mi código debe publicarse bajo una licencia libre y con la licencia que tiene el TPV privativo de Openbravo me quedo fuera del proyecto, bueno podré participar en la parte de la trastienda (backoffice) que funciona con Openbravo ERP pero no en la de TPV. En cualquier caso hubiera sido como cuando no existía una implementación de Java libre y usable, tu podías desarrollar tu software en Java y ponerle una licencia libre pero al final tenías que ejecutarlo en la máquina virtual privativa.

 

Es una pena, era un proyecto muy interesante, de hecho aquí en la oficina no paran de preguntarme todos los días si he cambiado de opinión y voy a participar pero ya les he dejado claro que no lo haré mientras Openbravo no cambie su licencia y mi código pueda ser libre. Cómo véis a esto me refería cuando hablaba del caramelo envenenado de Openbravo, mejor prueba que esta no váis a encontrar.

 

Un saludo.

Openbravo ERP vs OpenERP, Licencia

Este es el primero de una serie de artículos en los que voy a explicar el estado actual desde mi conocimiento de las diferencias entre Openbravo ERP y OpenERP. Si queréis ver todos los artículos podéis utilizar la etiqueta Openbravo vs Openerp 2014.

 

En cuanto a licencia nada nuevo bajo el sol, Openbravo sigue tienendo una licencia libre MPL (Mozilla Public License 1.1) para el core y una licencia privativa para la gran mayoría de módulos adicionales, entre ellos algunos de los que la propia Openbravo distribuye en su versión profesional. Como ya dije en su día Openbravo es una empresa de software privativo que dice que hace un ERP libre y eso no ha cambiado. Lo que pretende Openbravo es que la comunidad aporte código y que ellos y sus partners se aprovechen de este código mientras lo único que aportan por su parte como software libre es un core capado que generalmente no es suficiente para una implantación.

 

OpenERP por su parte tiene una licencia AGPL v3 y sólo relicencian con una licencia privativa en ciertas circunstancias muy particulares. Esto quiere decir que tanto el core de producto como todos los módulos que podamos encontrar, generalmente a través de launchpad, son libres. Al utilizar esta licencia OpenERP asegura que cualquier derivado de su producto siga siendo libre y además público.

 

Cheli