|
Terracotta es una herramienta que permite crear aplicaciones Java que pueden escalar a cualquier cantidad de computadoras, sin tener que crear código adicional o usar bases de datos para compartir datos dentro del cluster. En la Introducción veremos los conceptos básicos de Terracotta, para luego seguir con conceptos y ejemplos avanzados donde crearemos un ambiente de alta disponibilidad.
|
| La polémica nueva política de SpringSource |
|
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 SpringSourceEl 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
La explicación de SpringSourceObviamente 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? 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? ¿Se cambia la licencia de los Proyectos de Spring? ¿Cómo hará la comunidad de código abierto para tener acceso a los arreglos de bugs? ¿Las versiones comunitarias de Spring más antiguas, luego de los tres meses de la publicación, tendrán arreglos de bugs? ¿Van a existir dos fuentes diferentes de Spring, uno para la comunidad y otro para los clientes pagos? 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?
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?
Powered by !JoomlaComment 3.26
3.26 Copyright (C) 2008 Compojoom.com / Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved." |