Ciclo de vida de soporte recomendable para productos empresariales 2

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

Openbravo 2.40MP12.19

Lista de cambios.

2.40MP12.19 md5

2.40MP12.19 (megaupload)

Nota: Estoy teniendo problemas de ancho de banda, por favor intentar primero el enlace de megaupload y si no funciona utilizad el otro.

 

Actualización: Si quieres obtener la última versión de la rama 2.40 ponte en contacto conmigo (cheli en aradaen.com).

 

Cheli

El caramelo envenenado de Openbravo ERP

Cada día que pasa los acontecimientos se van sucediendo. No se desde cuando Openbravo viene utilizando la licencia OBCL, pero lo que si he podido observar es que cada vez más módulos de los que ofrecen directamente en su versión profesional y cuyo autor es la propia Openbravo están licenciados con esta licencia, lo que al final me hace preguntarme ¿es Openbravo ERP realmente libre?.

La pregunta viene porque aunque el módulo core está licenciado con la MPL (OBPL) y por tanto con rigor deberíamos decir que Openbravo ERP si es libre,  OBCL es claramente una licencia no libre. Si miramos la retahíla de módulos con esta licencia sin los cuales la mayoría de proyectos no pueden implementarse entonces podríamos decir que el core es simplemente un caramelo envenenado para poder proclamar que son una empresa de Software Libre (u Open Source como le gusta llamarlo a ellos), pero que en realidad no lo son.

Algunos ejemplos con licencia OBCL:

  • Cuaderno 43
  • Spain AEAT Modelo 347
  • Tax Report: Modelo 303 (Spain)
  • Modelo 349
  • Advanced Payments
  • Apparel Product Technical Specification
  • Facturación Electrónica – Facturae 3.1
  • Camerfactura
  • Condiciones de pago
  • Easy Extensible Attributes
  • Formas de pago
  • Gross Amounts in Invoices and Orders
  • Initial Data Load
  • Incoterms
  • Inter-company Documents
  • Intrastat
  • Invoices Register Book
  • Mass Advanced Paymen

Y no sigo porque la lista sería interminable. Si a esto le sumamos que hace poco anunciaron que iban a eliminar módulos funcionales de la versión comunidad pues creo que está claro hacía donde tira Openbravo con su estrategia comercial. ¿Qué licencia le pondrán finalmente a estos módulos? ¿hacemos apuestas?

Cheli