Hace casi un año que escribí sobre que ciclo de vida de soporte sería el recomendable para un producto empresarial. En aquel entonces comenté que 2 años me parecían excesivamente poco tiempo (me refería al ciclo de vida de soporte que tuvo Openbravo 2.35). Ahora Openbravo nos dice que va a tener ciclos de vida de almenos 5.5 años. Es un avance sin duda y es una cosa que mucha gente venía pidiendo desde hace tiempo.
Un día me puse a pensar que versión de las actuales de Openbravo (2.40 y 2.50) le pondría a un cliente nuevo si pudiera tomar yo la decisión. La principal métrica a utilizar sería que número de bugs tiene abiertos y cuantos se cierran en cada actualización. Pues bien, según esta métrica los bugs que se han cerrado en las últimas versiones son:
| 2.40 | 2.50 | |
| 2.40MP12.19/2.50MP24 | 1 | 50 (3 nuevas funcionalidades) |
| 2.40MP12.18/2.50MP23 | 3 | 86 (4 nuevas funcionalidades) |
| 2.40MP12.17/2.50MP22 | 3 | 80 (5 nuevas funcionalidades) |
| 2.40MP12.16/2.50MP21 | 7 | 98 (5 nuevas funcionalidades) |
Esta tabla muestra los datos de las últimas 4 subversiones de Openbravo 2.40 y Openbravo 2.50, si nos vamos moviendo hacia atrás os podéis imaginar que la diferencia se hace mucho más notable. Tampoco os llevéis a error por la numeración, en 2.40 hubo un momento que pensaron que era mejor cambiarla y pasar a versionar con subversión x.y para cambios pequeños y (x+1).0 para cambios grandes, ya que supongo que pensarían que con una numeración muy alta daría la impresión de que habían parcheado mucho. Como veis esto en 2.50 no da lugar porque los cambios siguen siendo tremendos.
Otra diferencia fundamental es que en 2.50 al margen de corregir bugs se introducen en cada versión muchas funcionalidades nuevas, lo que por lógica lleva a tener nuevos bugs y así hasta el infinito. Tampoco penséis que la diferencia es porque salen más paquetes de mantenimiento en una versión que en otra. La periodicidad de las dos versiones sigue un ritmo de más o menos un paquete al mes y ha sido así al menos durante los últimos 10 meses.
Con este panorama no tendríamos ninguna duda de que la versión 2.40 es la mejor opción, pero aún así alguno me dirá «Es que la 2.50 tiene módulos». Si tenemos en cuenta que la mayoría de los módulos que se proporcionan por parte de Openbravo y sus socios tecnológicos en el sistema de gestión de módulos no son libres, y que además yo tengo la política de ofrecer a mis clientes sólo software libre, entonces los módulos existentes no me servirían de nada. Sólo me quedaría el inconveniente de que aplicar actualizaciones y gestionar mis desarrollos es algo más eficiente en 2.50.
El problema es que antes no sabíamos hasta cuando Openbravo iba a soportar la versión 2.40, pero ahora nos aseguran que lo harán hasta septiembre de 2014, lo cual no está mal.
Llegado a este punto pensé, ¿y que hay de la 3.0?. Paolo Juvara dijo que a partir de la versión 3.0rc2 se puede utilizar en producción. Imaginaos el escenario, si yo con lo que os acabo de decir estoy poniendo en duda que la versión 2.50 sea la mejor opción para poner en producción, pues pensad que resultados podría arrojar el mismo análisis sobre una versión que está todavía en desarrollo. Pero no pasa nada, para solventar este problema Openbravo ha llamado a estas versiones RC, que típicamente significa Release Candidate o Versión Candidata, pero que está claro que para Openbravo no significa eso. Estas versiones en cualquier otro proyecto serio se utilizan cuando ya tienes lista la versión final, pero quieres dejar un margen de unos días o una semana para que la gente la pruebe, y en caso de descubrirse un fallo grave se corrige y se lanza la siguiente RC, y así hasta que no hay ningún fallo grave a corregir y se lanza la versión final. La diferencia es que lo que Openbravo llamó 3.0RC1 puede significar perfectamente 3.0 prealfa1 y así sucesivamente hasta tener una beta1 en la MP10 y una versión que podríamos considerar final en una MP30.
Por cierto Paolo Juvara es el nuevo director general y a parte de decir esta insensatez, es el mismo que en su día dijo que un software con licencia MPL (la de Openbravo) no se puede redistribuir. Menudo porvenir tiene Openbravo con esta persona al frente, muy triste.
Y mientras tanto algunos de mis clientes continúan pagando el soporte mientras la versión MP24 sigue sin aparecer en el gestor de actualizaciones, y después de notificárselo el día 2 en soporte, dos después del lanzamiento, a día de hoy todavía no nos han contestado.
Cheli
Sin duda usar una RC en producción es una barbaridad. Una RC es una RC, y se lanza para testear y pulir lo que quede.
Hay que tomarse más en serio lo de las versiones, que los entornos de prueba son una cosa, y el entorno donde se gana el pan el cliente son otra muy muy distinta.
Detalle:
Crees q el hecho de que haya muchas mas 2.50 funcionando sea lanrazon por la que se reporten y corrijan muchos mas bugs en esa versión?
Sabes si se hace backport de cada fix de 2.50 a 2.40?
Si hoy es festivo y es día 6, el día 2 era jueves. Sabes qué día era el viernes? Te has leído el contrato de soporte que tu cliente ha firmado?
Como picata y chico de los recados, tienes pinta de espabilado. Como asesor en el departamento de sistemas de una empresa tienes un poco de peligro…
Sin acritud, eh…
Como comprenderás no tengo ese dato, pero lo que si se es que la versión 2.40 es una versión que se ha puesto en producción en muchos sitios y no creo que el 100% haya migrado a la 2.50, ni siquiera creo que lo haya hecho más del 50 o 60%. Aún así muestras un gran desconocimiento de como se desarrolla y se corrige el código en varias ramas de desarrollo. ¿Qué sentido tiene preguntar si se trasladan todas las correcciones de una versión superior con más funcionalidades a la versión anterior?, la respuesta es obvia y es no. Si corriges un fallo en una nueva funcionalidad no va a afectar nunca a la versión anterior. Lo increíble es que te parezca completamente razonable que a una versión final que lleva más de año y medio publicada se le sigan corrigiendo 80 bugs al mes. Creo que el que tiene peligro como asesor vas a ser tú, háztelo mirar.
En cuanto a las actualizaciones, se perfectamente como se abrió esa incidencia, que prioridad se le puso y cuanto tiempo tiene para contestarme Openbravo. También se perfectamente como funciona el soporte de Openbravo y ese ataque ad-hominem está completamente fuera de lugar. Pero bueno, si te crees un listillo allá tú. Sigue haciendo negocio con software libre escribiendo desde tu ipad.
Sin acritud, ¡eh!.
iPod touch!
Pensaste también continuar asesorando en usar 2.40 a una empresa española teniendo en cuenta que no podría presentar declaraciones a la AEAT?
Si no gustas ser partner, no lo as. Dejamos al resto dar nuestra opinión!
Ese problema es igual en 2.40 que en 2.50 porque si se pretende utilizar software libre los módulos de documentos de la AEAT no lo son en 2.50. La solución en cualquier caso, tanto si utilizas 2.40 como 2.50 es desarrollarte tú mismo los módulos que necesites que gracias a ser una aplicación libre (o parcialmente libre mejor dicho) lo puedes hacer.
Por supuesto que puedes tener tu propia opinión, pero no creo que debas acusar ni insultar a nadie sobretodo cuando no tienes base para ello.
Hola Cheli,
Quisiera añadir información a algunos de los puntos que has tratado:
* 2.50MP24 no está disponible como actualización:
A finales de septiembre anunciamos (Openbravo) el uso de los «Maturity levels», que consiste en una maduración extra para los módulos. La versión 2.50MP24 ha sido publicada de acuerdo con esta política, por lo que ahora está en un nivel de maduración llamado «Controlled release». Permanecerá así durante 40 días, a partir de lo cuál y si no se encuentras issues críticas pasará al nivel llamado «General availability». Puedes leer más sobre esto en el siguiente post:
http://jpabloae.wordpress.com/2010/09/29/introducing-maturity-levels-to-openbravo-erp/
Openbravo por defecto viene configurado para recibir updates de módulos en «General availability». Sin conocer datos concretos de tu caso es posible que esta sea la causa por la que no se ve la actualización de 2.50MP24. El recibir actualizaciones en «General availability» o «Controlled release» para «Core» es una decisión que cada cuál puede ponderar dependiendo de las políticas y necesidades.
Es cierto que la release notes de la 2.50MP24 no hacían mención a este hecho, lo que hace que no fuera obvio. Acabo de añadir una nota aclaratoria en la sección de cómo actualizarse:
http://wiki.openbravo.com/wiki/ERP/2.50/Release_Notes/2.50MP24#Installation.2C_updates_and_upgrades
* Openbravo ha dicho que la versión 3.0rc2 se puede utilizar en producción:
Es verdad en parte. La parte que falta son las siguientes puntualizaciones:
* Si estás en la 2.50 no se recomienda actualizarse aún a la 3.0 (no es posible hacerlo).
* Recomendado para «early adopters», no para todo el mundo. Si estás interesado en comenzar a implantar Openbravo ahora, te puedes plantear si te compensa empezar en 2.50 o en 3.0 directamente (o 2.40). Dependiendo de tu perfil de usuario, requerimientos y fechas.
* El «early adopter» debería testear concienzudamente los flujos del ERP que sea claves para su implantación.
* Como van a salir más versiones antes de la 3.0 el «early adopter» debe ser consciente de que es altamente probable que haya cambios tanto en la interfaz de usuario como en la funcionalidad.
Cada cuál puede evaluar y decidir si encaja en este perfil y acepta estas condiciones o no.
Juan Pablo
La referencia a lo que comentas no la encontré en ningún sitio. No estaba en el panel que añadisteis en la MP23 donde entre otras cosas se anuncia la siguiente actualización, tampoco estaba como ya has comentado en la nota de publicación y ni siquiera vuestro soporte se ha enterado de este cambio porque esta misma mañana nos han comunicado que si no está disponible el problema debe ser que hay fallos de dependencias entre módulos pero no han hecho ninguna mención a este asunto, lo cual no es posible ya que entre otras cosas se probó en una instalación activa en nuestro entorno de pruebas y sin módulos. Que este es otro tema, el sistema de gestión de módulos o no notifica de nada o notifica incorrectamente los errores (el módulo D7E2FF2JC621CDADE79EECADDEECADDE tiene un problema de dependencias con org.openbravo.xxxx no ayuda mucho), pero de eso hablaremos en otra ocasión.
En cuanto a lo que tu llamas «early adopters», o lo que cualquier podría llamar probador. Puedes sugerirle a Pepito que en su casa pruebe una versión alfa del programa de reproducción de audio pero no creo que sea coherente pedirle a una empresa que ponga en producción una versión alfa de su programa de gestión empresarial, por muy probador que sea. Pero bueno, esa es mi opinión.
Un saludo.