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

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.

La gran irresponsabilidad de Openbravo, con Paolo Juvara a la cabeza

El 17 de septiembre de 2010 Paolo Juvara anunció Openbravo 3.0RC2, y en dicho anuncio nos dijo.

This is a very exciting milestone for us because, unlike its predecessor RC1, Openbravo 3.0 RC2 supports onwards updates to both future release candidates and generally available releases.

This means that Openbravo 3.0 RC2 is not limited to evaluation or development purposes only and can be considered for production usage by early adopters in new implementations. As such Openbravo 3.0 RC2 is a fully supported release and it is available both as a Community Edition and Professional Edition.

Que viene a ser algo así como (traducción libre)…

Este es un hito excitante para nosotros porque, a diferencia de su predecesora RC1, Openbravo 3.0 RC2 en adelante soporta actualizaciones tanto hacía futuras RC como a versiones finales.

Esto significa que Openbravo 3.0 RC2 no es sólo para evaluación o desarrollo y puede ser  considerada para uso en producción por probadores para nuevas implementaciones. Como tal Openbravo 3.0 RC2 es una versión completamente soportada y está disponible tanto en su versión Comunidad como en la Profesional.

Desde ese momento y según mis cuentas, obviando la versión RC3 de la que no he encontrado datos, se han cerrado hasta la recién salida RC7 un total de 581 bugs y se han añadido 31 nuevas características. No es de extrañar que si sumamos la versión RC3 estemos hablando de entre 750 y 850 bugs. Actualmente y según el mapa de ruta hay abiertas entre MP0, MP1, MP2 y MP3 un total de 297 incidencias.

Esto es lo que Openbravo y concretamente su actual director general Paolo Juvara llama una vesión lista para uso en producción por probadores.

Yo ya dije hace meses que este planteamiento me parecía de locos, ahora no me lo parece, estoy totalmente convencido.

Lo verdaderamente lamentable es que un proyecto que empezó siendo una gran promesa de ERP libre está terminando siendo una total decepción.

Cheli