Hace muy pocas semanas Spring aunció un cambio en su política de mantenimiento, de manera que sólo se distribuirían los binarios durante una ventana de 3 meses desde la publicación de una versión mayor.
La medida generó un intenso debate en The Server Side, donde participó activamente Rod Johnson explicando, entre otras cosas, que el proyecto seguía siendo de software libre.
Pero esta semana, tras la polémica, Rod anunció nuevos cambios en la política, esta vez recibiendo felicitaciones por parte la comunidad.
La nueva política de distribución
De ahora en más, SpringSource seguirá publicando los binarios de la versión activa de Spring sin la ventana de 3 meses. Cuando se publique una versión mayor, se dejarán de publicar las actualizaciones a la versión anterior. Quienes quieran recibir los binarios resultado del mantenimiento de versiones viejas, deberán subscribirse a SpringSource Enterprise (o bajarse los fuentes y compilarlos por su cuenta).
En el post Una cuestión de balance: mejoras a la política de mantenmiento, Rod explica la polémica medida y cómo fue ajustada. Vemos a continuación las partes más interesantes.
Una cuestión de balance: mejoras a la política de mantenimiento
Llevar adelante un negocio es parecido, en al menos un aspecto, a escribir código: no siempre te sale bien la primera vez, incluso aunque sepamos qué es lo que queremos lograr - pero si se logra un mejor resultado al final si estás dispuesto a retrabajar las cosas cuando sea necesario. En SpringSource teníamos una visión muy clara para la política que anunciamos recientemente: balancear las necesidades de la comunidad de código abierto, de los usuarios empresariales y de los creadores de Spring, para el beneficio de todos. Sin embargo, no logramos ese balance en el primer intento, y es hora de hacer una reestructuración.
En las últimas semanas me hicieron recordar el tamaño de la comunidad de Spring y la pasión que hay acá adentro.
Estuvimos escuchando intensamente a las opiniones de la comunidad - no sólo a aquellos que participan más activamente en los foros, sino también a través de otros tantos canales incluyendo conversaciones privadas y correos electrónicos.
Mientras escuchábamos a la comunidad, había dos temas que se destacaban: la disponibilidad de publicaciones en forma regular de versiones actuales y estables de Spring para la comunidad (expresado a través de pedidos para tags en el código fuente en los repositorios de código si no se proveían los binarios); y el precio para los negocios más pequeños y los pequeños integradores de sistemas. Sabemos que a la gente le encanta el software de Spring y nuestro compromiso para mejorar Java en la empresa; sabemos que quieren que SpringSource tenga éxito y siga innovando. Pero también escuchamos preocupaciones sinceras y nos las llevamos para debatir.
Hoy me gustaría reafirmar nuestro compromiso con la comunidad hacia todos los que pudieran tener cualquier duda, y explicar cómo vamos a realizar cambios significativos en nuestra política de mantenimiento en respuesta a todos los comentarios que recibimos.
Nuestro compromiso con el código abierto
Algunos se preocuparon de que Spring dejaría de ser código abierto. La frase "cambios en la licencia" se llevó por cualquier lado - a pesar de que no estamos cambiando la licencia para el código de Spring. Aunque estas especulaciones eran infundadas, de todas formas es preocupante.
Dejenme usar esta oportunidad para garantizar otra vez que Spring seguirá siendo de código abierto para la comunidad, bajo la licencia actual (Apache). Punto.
Si tuvieron una impresión distinta a esto, mis colegas y yo debimos hacer un mal trabajo en comunicar nuestra política de mantenimiento - o, quizás, escucharon información imprecisa de segunda mano. Todo lo que hace SpringSource se basa en que Spring sea de código abierto, y en un acuerdo positivo con la comunidad. Primero, no haríamos a Spring de código cerrado porque estaría mal. Segundo, comprendemos que dado el rol central que cumple Spring en muchos, sino en la mayoría, de los proyectos Java empresariales y en muchos otros proyetos de código abierto, y como un modelo de programación estándard de facto, el impacto podría dañar de manera significativa al modelo Java empresarial. Tercero, sería una decisión de negocio estúpida.
Nuestro compromiso al código abierto se mantiene tan firme como siempre, y seguirá creciendo. Esperamos con ganas seguir trabajando juntos con nuestra comunidad en los próximos meses y años para construir más software grandioso. Estamos ansiosos sobre Spring Framework 3.0 y otras publicaciones de código abierto próximas, y estamos orgullosos de poder hacer inversiones cada vez mayores en el código abierto.
Publicaciones estables para la comunidad
Nuestra política de mantenimiento original decía que, luego de 3 meses, las publicaciones binarias de cada versión mayor de Spring sólo estaría disponible para los clientes de SpringSource Enterprise, aunque el código fuente siempre estaría disponible (y sin tags).
Así, sólo cambiamos el modelo de distribución luego de los 3 meses para una versión mayor. El código fuente seguía bajo la licencia actual. No había cambios en la licencia.
Sin embargo, algunos en la comunidad expresaron su preocupación sobre el hecho de que pasados los 3 meses no habría tags disponibles en el repositorio. Se preocupaban sobre el riesgo de una ventana de tiempo extendida entre las publicaciones binarias disponibles para la comunidad, y la dificultad de acceder a los arreglos sin contar con los tags. Algunos también se preocupaban sobre una potencial confusión entre las distintas distribuciones de Spring, lo que resultaría en problemas de comunicación entre la comunidad de Spring.
Nos tomamos estas preocupaciones muy en serio, y el resultado de nuestra reflexión es que deseamos dar un paso más allá del pedido de los usuarios, para demostrar nuestro compromiso con la comunidad - quizás la comunidad más importante en Java empresarial - y asegurar que la misma siga creciendo rápidamente.
Arreglamos la política de mantenimiento en base a las opiniones de la comunidad. Para la comunidad vamos a hacer publicaciones regulares de binarios de Spring de la versión actual (del trunk), sin la ventana de 3 meses. Para cada versión de Spring, las publicaciones para la comunidad seguirán disponbiles mientras sigan en el trunk o hasta que que esté estable la próxima versión.
Una vez que hayamos publicado un Release Candidate para una versión nueva del proyecto, no vamos a publicar más tags ni publicaciones de binarios de las versiones anteriores del proyecto para la comunidad de código abierto. Todas estas publicaciones seguirán estando disponibles durante tres años para los clientes de SpringSource Enterprise.
Un objetivo clave de nuestra política de mantenimiento es poder enfocar los recursos en traer características nuevas a Spring, y continuar liderando e innovando la plataforma Java empresarial de código abierto. A medida que aumentamos los recursos de desarrollo buscamos avanzar más rápidamente, con publicaciones de versiones mayores más frecuentes que lleven características y capacidades nuevas para la comunidad.
Por ejemplo, Spring 2.5.x sigue en el trunk, por lo cual bajo esta política mejorada estaríamos publicando Spring 2.5.6 para la comunidad en muy corto tiempo. Spring 3.0M1 va a publicarse poco después y el trunk se usará para el desarrollo de 3.0. Una vez que publiquemos Spring 3.0 RC1 no vamos a proveer tags o publicaciones para la rama 2.5.x. Nos vamos a enfocar en el desarrollo de 3.0 para poder realizar una publicaciones de 3.0 lo más rápido posible luego del primer milestone.
Nuestra política de soporte por 3 años (y SpringSource Enterprise) le brinda seguridad a los clientes empresariales, quienes no pueden o no quieren actualizarse de manera frecuente. Y al enfocar más esfuerzo de la comunidad en el desarrollo de las últimas características beneficiamos a los usuarios de código abierto.
Un balance justo
Es obvio que podríamos haber hecho un mejor trabajo en contactarnos con la comunidad y explicar lo que estábamos haciendo y porqué era necesario.
Si nembargo, es importante comprender que nuestras intenciones de contar con una política de mantenimiento. Primero, nunca tuvimos una política de mantenimiento y no podíamos seguir para siempre sin dejar en claro nuestro compromiso para la comunidad y para nuestros clientes. Como una compania, intentamos ser abiertos con nuestra comunidad, en vez de hacer las cosas de manera oculta. A veces esto involucra comunicar una realidad no muy bienvenida que otras companías inetntarían ocultar. Segundo, esta política intenta ayudarnos a generar ganancias de organizaciones que no se involucran de cerca con la comunidad, no puden o no quieren actualizar regularmente a la última versión ayudante a mejorar la calidad de Spring, y en cambio reciben valor en recibir mantenimiento por versiones viejas. Este tipo de organizaciones quieren estabilidad, soporte de nivel mundial, y valoran el software adicional que brinda nuestra suite de productos Enterprise.
Queremos construir una gran companía, que pueda pagarle a sus talentosos desarrolladores, que pueda generar una ganancia razonable y pueda continuar aumentando nuestra contribución de software de código abierto. Mientras más exito tengamos, más buen código vamos a poder contribuir a la comunidad de Spring. A medida que fuimos creciendo en los últimos 2 años, nuestra habilidad de generar código abierto fue creciendo cada vez más rápido y el resultado habla por si mismo, logrando que en los últimos 12 meses haya más descargas de Spring y pedidos de trabajo con conocimientos de Spring como nunca antes.
Muchas organizaciones van a valorar nuestros productos Enterprise, el soporte técnico y las publicaciones de mantenimiento durante 3 años. También sabemos que muchos usuarios van a decidir no comprar estos productos y servicios. Y eso está bien. Así es como funciona el código abierto comercial. Si podemos seguir aumentando nuestra inversión en software, todos ganan.
Si usted es una organización que genera ganancias gigantescas usando Spring en entornos productivos grandes, por favor envie un cheque a SpringSource por el 1% del valor que recibe por usar Spring. Utilizaremos ese dinero para pagar sueldos, aumentar nuestra inversión en el código abierto y lograr una ganancia.
Sería tan bueno si una política como esta pudiera funcionar en la práctica. No funciona, así que creamos la política de mantenimiento para obtener ganancias de las organizaciones que usan Spring en producción y que quieren garantías de nivel empresarial en su software. A la vez, al mantener el código fuente abierto seguimos brindando a la comunidad con gran software. Las políticdas, por su propia naturaleza, no son perfectas, pero creemos que el camino que estamos recorriendo es el mejor balance entre las necesidades de la comunidad de código abierto de Spring y las necesidades del negocio de código abierto detrás de Spring. Y estamos contentos que sus opiniones nos hayan ayudado a que funcionara mejor para la comunidad.
¿Basta del juego del teléfono?
Me gustaría agradecer sinceramente a quienes hicieron comentarios constructivos en los foros o por correo electrónico. Gracias por preocuparse por Spring lo suficiente para analizar estos temas; gracias por tomarse el tiempo de escribir sus ideas y compatirlas conmigo. Por favor, ¡sigan así!
Otra lección que me gustaría aprender es intentar lograr una comunicación más directa entre SpringSource, el equipo de Spring y la comunidad de Spring. Seguramente jugaron al juego "El teléfono descompuesto", en donde el mensaje se va modificando entre los participantes de acuerdo a cómo lo entienden. La comunicación en los foros y en los blogs es importante, pero no siempre es confiable.
Me gustaría usar esta oportunidad para escuchar sus ideas para mejorar la comunicación. Estoy abierto a sugerencias, como sesiones de chat, conferencias telefónicas abiertas... también es su comunidad, y estoy seguro de que tienen buenas ideas.
