lunes, septiembre 22, 2008

Spring cambia el modelo de mantenimiento, ¿y qué?

lunes, septiembre 22, 2008 por Martín


Desde luego, mira que egoistas somos. Tenemos un proyecto que probablemente hoy por hoy el 90% de los desarrolladores Java se está aprovechando de él, directa o indirectamente, y justo cuando el proyecto anuncia una nueva forma de ganar dinero nos lanzamos a criticarlo ferozmente por vendidos.

Claro, al fin de cuentas uno se acostumbra a tener unos cuantos esclavos de primera clase haciendo el trabajo que a nosotros nos llevaría años y sin cobrar ni un céntimo; y ojo con retrasarse en las releases que a nosotros nos gusta estar a la última; y apurando con esa actualización de la versión 1.1.0.2 de hace dos años que tengo un cliente un poco pesadito y necesito que me arregléis un bug que tenéis pendiente. Así que venga, que tenéis capital de riesgo y hay que ganarse el pan.

Estos dos párrafos derrochando ironia vienen a cuento de las reacciones en ese nido de trolls en el que se ha convertido lo que en su día fue una gran comunidad como TheServerSide y en el que no han tardado en despellejar a Spring por el anuncio de su nueva política de mantenimiento. Claro que tampoco es de extrañar ya que el portal ya se dedica sólo a noticias de lanzamientos de productos y rumores.

En InfoQ hacen un resumen mucho más pausado y tranquilo de el nuevo modelo de mantenimiento que básicamente viene a ser:

  • Los usuarios normales (que no pagan) de Spring tendrán acceso a todas las builds de versiones mayores del producto.

  • Los usuarios normales (que no pagan) tendrán acceso a las actualizaciones (bug fixes) de estas versiones durante los tres meses desde su lanzamiento.

  • Los usuarios "enterprise" (de pago) tendrán acceso a todas las builds de todas las versiones incluso tras tres meses después de su lanzamiento.

  • Todo sigue accesible en el repositorio de fuentes del proyecto, así que cualquier usuario puede descargarse un proyecto con los últimos parches y construirlo el mismo.


Teniendo en cuenta el último punto, en mi opinión no hay ninguna razón para protestar. A mi me parece una muy buena idea para monetizar el proyecto y estoy seguro de que muchos clientes decidirán subscribirse al mantenimiento para evitar el engorro de tener que descargarse los fuentes de una determinada versión y poder descargarse directamente una versión que puedan desplegar directamente.

Por lo demás, se supone que esto podría perjudicar a algún proyecto Open Source que necesita indirectamente los últimos parches, pero bueno realmente no creo que a los administradores de proyectos Open Sources les moleste demasiado descargarse Spring para tener los últimos parches; lo último es aplicable a cualquier persona que le guste estar a la última en cuestión de este framework.

Eso sí, ojo porque los chicos de SpringSource ya nos han sorprendido con un servidor de aplicaciones y con un nuevo modelo de mantenimiento más comercial. ¿Qué será lo siguiente?

comments

3 Respuestas a "Spring cambia el modelo de mantenimiento, ¿y qué?"
dfernandez dijo...
11:26

Hola Martín, cuánto tiempo :-)

Desde mi punto de vista, es precisamente el último punto el "malo". Porque sí, lo subirán todo al repositorio de fuentes... pero sin tags.

De hecho, Rod Johnson mismo en este comentario explica que no los habrá, y que el "asesoramiento" para saber si en un determinado momento el trunk de fuentes es suficientemente estable y sus componentes se integran bien es precisamente parte del producto que ofrecen.

En ese caso, no habiendo tags, ese trunk no se puede considerar estable. Así que no se puede usar para producción. De modo que es exactamente como si no lo tuviésemos.

(Creo yo) ;-)

Saludos,
Daniel.


Martín dijo...
13:50

Daniel, gracias por la información sobre los tags porque se me había pasado completamente; de hecho ya he visto tu post en TSS que resalta también buenos puntos.

El no haber tags complica algo más las cosas, pero sinceramente, no cambia demasiado. El escenario que propones en TSS es correcto, pero de producirse el usuario tendría que pensar en:

1) Adquirir soporte, lo cual parece razonable si se trata de una empresa;

2) Corregir uno mismo el error y como comentas en el post, recoger la trunk posteriormente. ¿No es estable? Seguramente desde un punto de vista estricto la respuesta es no, tampoco veo muy probable que a SpringSource le convenga tener un trunk de baja calidad.

3) Utilizar una versión más estable. En una empresa en la que he trabajado la política era siempre no utilizar la primera versión de algo y esperar a que vayan saliendo actualizaciones. Es decir, no usar Spring 2.0 y esperar a Spring 2.1 porque será mucho más estable. ¿Te pierdes cosas? Sí. ¿Funciona? Excepcionalmente, siempre trabajando con lo más estable y lo más usado ya que sólo un porcentaje bajo de usuarios puede estar "a la última".

Dicho todo esto yo creo que ellos ya han pensado todas estas posibilidades y los tres meses parecen razonables como para que los errores más graves e importantes se corrijan.

Saludos.


Jose Manuel Beas dijo...
19:04

Martín, dices:

Eso sí, ojo porque los chicos de SpringSource ya nos han sorprendido con un servidor de aplicaciones y con un nuevo modelo de mantenimiento más comercial. ¿Qué será lo siguiente?


Pues a mi se me ocurre que las certificaciones oficiales podrían ser otra fuente de ingresos "conflictiva"... no estará mal si se tratan de certificaciones llenas de contenido y que no sean fuentes de información privilegiada (sino de experiencia privilegiada).