SpringSource, la empresa fundada por Rod Johnson y que financia el desarrollo de Spring, anunció que entra en implementación la nueva política de mantenimiento de Spring Framework. Con estos cambios, se deberá comprar soporte comercial si se desea acceder a versiones compiladas con arreglos que surjan 3 meses después de una publicación mayor.
Obviamente, es un cambio importante para la distribución de este framework de aplicaciones, convertido en un estandar de facto. Y la polémica no tardó en establecerse, con diversas posturas. Veamos antes los detalles del anuncio, sus motivos y consecuencias.
El anuncio de SpringSource
El anuncio oficial de SpringSource referente a la nueva política de mantenimiento fue publicado el 17 de septiembre:
SAN MATEO, Calif. 17 de Septiembre, 2008 - Spring Source, la empresa detrás de Spring, el estandar de facto en Java, anuncia hoy que la implementación de una nueva política de mantenimiento para Spring. Esta política le brinda a los usuarios de Spring una plataforma de aplicación estable a largo plazo para ejecutar y administrar sus aplicaciones basadas en Spring.
Los clientes que están usando SpringSource Enterprise, disponible bajo suscripción, recibirán publicaciones de mantenimiento durante 3 años desde la disponibilidad general de una revisión mayor. Estos clientes recibirán arreglos continuos y rápidos, junto a publicaciones de mantenimiento regulares para resolver bugs, vulnerabilidades de seguridad y problemas de uso, convirtiendo así a SpringSource Entrprise la mejor opción para los sistemas productivos.
Luego de que se publica una nueva revisión mayor de Spring, se entregarán para la comunidad actualizaciones de mantenimiento durante tres meses para resolver problemas iniciales de estabilidad. Las publicaciones posteriores estarán disponibles para los clientes de SpringSource Enterprise. Los arreglos de bugs estarán en la rama de desarrollo de código abierto y se harán disponibles en la próxima publicación mayor comunitaria de software.
En pocas palabras
- SpringSource realiza una revisión mayor de Spring, que se identifica por ser un cambio en alguno de los dos primeros números de versión (1.0, 1.1, 1.2, 2.0, 2.1, 2.5, etc.).
- Durante los siguientes 3 meses de la revisión mayor, se publicarán todas las revisiones menores (2.5.1, 2.5.2, 2.5.3, etc.) en forma de binarios, como siempre.
- Pasados estos 3 meses, todos los arreglos que se generen en revisiones menores no estarán disponibles en forma de binarios para quienes no sean suscriptores de SpringSource.
- Todos los arreglos que forman parte de cualquier revisión menor (o mayor) estarán siempre disponibles en el código fuente a través del repositorio de código, de libre acceso.
La explicación de SpringSource
Obviamente que esta cambio generó todo tipo de reacciones, y SpringSource salió a aclarar las dudas más frecuentes de esta nueva política.
¿Por qué este cambio?
A medida que avanzan y crecen las tecnologías de SpringSouce para cumplir la demanda de la comunidad, tenemos una inversión importante para el mantenimiento, construcción del producto, aseguramiento y testeo de calidad de Spring. Cada vez hay más organizaciones que están funcionando con publicaciones anteriores de nuestro software, y tenemos que compensar el costo de mantener todas las ramas anteriores del software.
Nuestros clientes pagan para tener una plataforma productiva estable (junto a otros beneficios), mientras que los usuarios de código abierto pueden usar el código fuente para mantener sus versiones. Los clientes de SpringSource Enterprise esperan recibir de nosotros la misma calidad de soporte y mantenimiento que reciben de otros proveedores de software. Esto incluye un compromiso de mantenimiento y actualizaciones para publicaciones antiguas de nuestros productos, que no formaba parte de nuestra política hasta hoy.
¿Spring seguirá siendo de código abierto?
Si, por supuesto. El código fuente continuará estando disponible en el repositorio de fuentes.
¿Se cambia la licencia de los Proyectos de Spring?
No.
¿Cómo hará la comunidad de código abierto para tener acceso a los arreglos de bugs?
La comunidad de código abierto seguirá teniendo acceso a todos los arreglos. Estos arreglos estarán disponibles en el repositorio de código como parte de la rama de desarrollo actual. Además, los arreglos serán llevados a las ramas de mantenimiento de publicaciones anteriores. Los usuarios que trabajen con el último milestone pueden seleccionar una construcción del último milestone. Los usuarios que necesiten un arreglo para una versión anterior de Spring pueden descargar los fuentes de la rama apropiada y crear su propia distribución en cualquier momento.
¿Las versiones comunitarias de Spring más antiguas, luego de los tres meses de la publicación, tendrán arreglos de bugs?
Aunque no habrán más publicaciones de mantenimiento, el código fuente va a permanecer disponible en el repositorio público y contendrá los arreglos que hizo SpringSource. Los usuarios son libres de construir a partir de este repositorio.
¿Van a existir dos fuentes diferentes de Spring, uno para la comunidad y otro para los clientes pagos?
No. Existirá una rama para cada revisión mayor de Spring. Luego de los tres meses de la publicación de la revisión mayor, las publicaciones subsiguientes sólo se se harán para los clientes Enterprise. Los usuarios de la Comunidad tendrán acceso al código fuente.
El punto más crítico: habla Rod Johnson
El tema más criticado y que desató una enorme cantidad de críticas es que SpringSource no publicará tags en el repositorio de código que marquen las distintas revisiones menores.
Dicen SpringSource: "A nuestros clientes le ofrecemos, junto al soporte 24x7, el valor de saber cuándo el código fuente está listo para una publicación y cuándo un grupo de cambios coherentes debe ir junto; esto se basa en pruebas de integración que vayn más allá de los recursos para pruebas disponibles en la comunidad".
De hecho, el mismo Rod Johnson se unió a la discusión en The Server Side, donde aclaró:
No intentamos lastimar a la comunidad de código abierto, o a aquellos que trabajan para organizaciones que no pueden permitirse pagar suscripciones.
Mantenemos el código abierto y quiero ser lo más abierto posible con la comunidad. Sin embargo, supongamos que publicaramos los tags. Estaría feliz si desarrolladores independientes quisieran construir estos tags. Sin embargo, sería una oportunidad para que empresas intenten distribuir estos builds con sus propios fines: hacer dinero o como estrategía de dumping.
¿Por qué sería Una Mala Idea?
- El dinero que podría haber sido destinado al desarrollo de Spring contribuiría en nada en su desarrollo. Un modelo en donde una compania o un grupo de desarrolladores desarrolla código abierto y otra hace dinero, es destructivo en el mediano a largo plazo.
- Los clientes que compren el soporte de estas empresas no recibirían soporte de calidad (que estuviera respaldado por desarrolladores de Spring)
- Algunas empresas obvias podrían involucrarse, que ya mostraron su intención de hacer dinero a costa del trabajo de otros, y que no necesitan ese dinero.
Por supuesto, SpringSource quiere hacer dinero. Pero que SpringSource esté fuerte y saludable es importante para el futuro de Spring - y, yo creo, para el futuro empresarial de Java. Estoy muy orgulloso de nuestro antecedente de crear uno de los desarrollo de código abierto Java más importantes y de más calidad - y estoy comprometido a asegurar más constribuciones para el futuro.
Estamos buscando un buen balance entre las necesidades comerciales de la comunidad.
Encontrando el balance adecuado
En las próximas semanas seguramente habrá más anuncios, en especial referente a los tags. Es posible que se mantengan los tags en la rama principal durante los primeros tres meses, para facilitar la colaboración.
En todo caso, es un debate más que interesante. Como dicen Rod, es necesario encontrar un balance entre las necesidades comerciales y la comunidad. No nos engañemos, Spring hoy es posible, en gran medida, gracias al soporte que brinda SpringSource como empresa.
El cambio en la política de mantenimiento es más bien una comodidad. Quien quiera tener la comodidad de obtener los fuentes compilados, tendrá que suscribirse para acceder a este servicio. El resto podrá seguir accediendo a lo mismo, pero deberá compilarlo por su cuenta.
Les sugiero a todos seguir el debate en The Server Side, donde hay muchísimas opiniones y posturas interesantes.
Y a ustedes, ¿qué les parece este cambio? ¿Los afecta en algo en su empresa? ¿Cuál es su postura?