Etiqueta: Openbravo

Publicado el

Openbravo miente para promocionar la versión 3.0

En esta ocasión ha sido Dmitry Mezentsev, director de desarrollo de producto de Openbravo. Primero os pondré en precedentes.

 

En este hilo del foro un usuario pregunta si puede instalar y dar soporte de Openbravo a sus clientes libremente. Dmitry le contesta básicamente diciéndole que si puede. Entonces yo le contesto advirtiéndole que eso es únicamente para el core, que tenga cuidado con la licencia de otros módulos porque lo más seguro es que necestie alguno con licencia privativa de Openbravo. A partir de ahí Dmitry empieza a manipular estadísticas para defender que no es así, que Openbravo versión comunidad se puede utilizar sin problemas en producción, lo cual es obviamente falso.

 

En este otro hilo un usuario pregunta si es mejor utilizar la versión 2.50 o la 3.0. Yo le contesto que si miramos el histórico de bugs abiertos obviamente la 3MP0 no es estable. Dmitry empieza a desvirtuar el sistema de calidad que llevan a cabo para concluir que con sus datos no sabe decir cual de las dos versiones es más estable. Lo chistoso es que con esas palabras viene a decir que una versión que se acaba de publicar es almenos igual de estable que otra que lleva dos años publicada, lo cual dice muy poco de trabajo de estabilización que ha hecho su empresa.

 

Yo creo que es siempre mejor ir con la verdad por delante, por lo que parece Dmitry siendo director de desarrollo de producto prefiere mentir para justificar su trabajo. Es mejor decir -Oye, tienes razón, la hemos cagado, nuestra versión no es lo suficientemente estable, intentaremos mejorar.- pero teniendo en cuenta que ya la daban por buena para producción desde hace meses, eso si bajo tu propio riesgo, pues era de esperar. De todo esto se entiende que necesitan sacar una nueva versión para vender lo que sea, aunque sea una porquería llena de bugs.

La nueva versión es muy bonita pero uno, es mucho menos libre que la anterior, y dos, como todas las versiones MP0 de Openbravo habrá que esperar meses hasta que sea utilizable en producción, según mis criterios de calidad claro.

 

Cheli

Publicado el

¿Openbravo ERP o Openerp?

Hace poco me solicitaron un presupuesto de una implantación de Openbravo ERP. El cliente al final quedó muy contento con mi oferta, el problema fué que se decantaron finalmente por Openerp.

Openbravo vs Openerp

Google ratifica esta tendencia, y yo lo entiendo. Openbravo es una empresa de software privativo que dice que hace un ERP libre, pero eso es una verdad a medias. Parece que la gente empieza a darse cuenta y busca alternativas, y aunque no conozco mucho el caso de Openerp si que tiene una gran ventaja, y es que su licencia es GPL v3 o AGPL v3 en su última versión, con lo que garantiza totalmente la libertad del software. En contraposición tenemos a Openbravo con una licencia MPL para el core y una licencia privativa para la mayoría de módulos.

Cheli

Publicado el

Los problemas de siempre con merges en Openbravo ERP

Ya hablé en su día de porqué el sistema de módulos no aportaba nada nuevo al desarrollo de Openbravo ERP. Entre otras cosas hablaba del problema de los merges y como se trasladaba el problema del core a los módulos. Esta vez me ha tocado sufrirlo en un módulo de Philanthros ERP, pero hagamos un poco de historia.

Philanthros ERP es un desarrollo que se encargó a Openbravo para la versión 2.40. Openbravo también ha sido el encargado de migrarlo a la versión 2.50 y generar las plantillas y módulos actuales. Aunque digo que es Openbravo el que ha desarrollado Philanthros no os penséis que son los encargados del desarrollo del core, ni mucho menos, los encargados fueron los que pertenecen a lo que Openbravo llama Custom. Esto no es más que tener su propio equipo de consultoría y desarrollo dentro de casa, vamos lo mismo que puede hacer cualquier consultoría al uso de las que ya conocemos. De hecho se nota mucho que han sido estos quién han hecho el desarrollo por algunas chapucillas la baja calidad del código en muchos aspectos. Informes mal internacionalizados, estilo de código caótico y que no sigue la guía de estilo de Openbravo, código insertado a pelo (hard coded), etc.

Estos días se ha abierto una incidencia sobre el proceso de completar factura de compras en Philanthros ERP. Al revisar el código me he dado cuenta que en su día se personalizó el pl/sql que se ejecuta en este proceso y se renombró como CUS_INVOICE_POST (el original se llama C_INVOICE_POST), este a su vez se insertó en un módulo llamado sales. Pues bueno, cada vez que se ha ido actualizando el core se ha ido parcheando progresivamente el pl/sql orginal, pero el que se personalizó como es natural no ha estado afectado por estos cambios. ¿Qué he tenido que hacer? pues revisar los 33 parches que se han aplicado al archivo original desde septiembre de 2009, que es cuando se creó este fork por llamarlo de alguna forma, e ir integrándolos en la versión en uso.

No os podéis ni imaginar el trabajo de chinos que ha supuesto realizar todo este trabajo al estar tan desvirtuado el archivo personalizado que desarrolló Openbravo, pero bueno, parece que al final lo he conseguido.

Este es el problema de siempre, que cuando personalizas un archivo del core tienes que integrar manualmente los cambios que se le hagan.

Cheli