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
Bueno, parece que empiezas a entender todo el esfuerzo que hay detrás de mantener una versión estable y porque OpenBravo cobra por estas versiones.
¿Y quién ha dicho que no haya que cobrar por dar soporte?. Creo que no has leído ni uno solo de mis apuntes.
Creo que se refiere a que quizá ahora percibes que aunque no estés de acuerdo en que se cobre por estas actualizaciones, hay mucho trabajo detrás de ellas.
Llevo 3 años con openbravo ERP haciendo el mismo tipo de cosas que pongo en este apunto, y muchos más dando soporte a otro tipo de aplicaciones, creo que eso lo percibí hace mucho tiempo y por eso mismo nunca he dicho que no haya que cobrar por ello. Tampoco he dicho nunca que no haya que cobrar por dar soporte con software libre, es más es de lo que vivo yo. Yo he criticado muchísimas cosas de Openbravo como empresa pero cobrar por dar soporte no va a ser una de esas.
Lo que yo digo es que hay cláusulas en los contratos de soporte de Openbravo que son directamente draconianas, como la que dependiendo del número de usuarios haya que cobrar más o menos cuando el soporte es independiente de esta variable. Aplicar las actualizaciones tiene exactamente el mismo coste independientemente del número de usuarios que hayan. Esto es como el ejemplo del autobús que puse en ese apunte, tu compras un autobús y sólo puedes llevar a una persona, si quieres llevar a las 50 que caben entonces tienes que pagar un plus, es absurdo.
¿Quieren vender soporte?, me parece lo lógico pero que no añadan de repente cláusulas abusivas porque no saben hacer negocio con el software libre y no les salen las cuentas.
Un saludo.