New Spring maintenance policy

[ramilani12]

Saiu na InfoQ a nova política do Spring: http://www.theserverside.com/news/thread.tss?thread_id=50727

Looks like we’ll need to buy support on Spring to get ongoing bug fixes. I just saw that SpringSource formalized a maintenance policy http://www.springsource.com/node/558 for Spring and we’ll now need to buy commercial support if we want maintenance releases after a new release is out for 3 months. I know other open source companies do this, but that’s some big news for Spring.

E como ficará os projetos que utilizam o Spring o Grails por exemplo?
Pelo que entendi vc precisa pagar para pelos novos releases ,patches e etc…

Politica: http://www.springsource.com/node/558

[RaulCarlin]

Na verdade, só precisa pagar pra releases de versões após o período de 3 meses de seu lançamento…

Tipo, saiu a 2.6, durante 3 meses a comunidade vai poder dar pitaco, depois, já era, só os “Enterprise Customers”…

E se depois de 3 meses eu achar um bug daqueles?

Que desanimador…

[mcbarsotti]

aaffffff, primeiro o ext.js e agora o spring… ( de maneiras diferentes, mas no fim da contas, vai acabar dando na mesma )
deveria existir um controle sobre essas mudanças…

[gulira]

Para mim é:

Spring–

[kicolobo]

Nem Spring++ nem Spring–.

Nada de errado com isto, ao contrário, demonstra que não estão conseguindo ganhar o suficiente com o produto e precisam angariar mais clientes. Este vai ser o diferencial que eles precisam.

[louds]

[quote=mcbarsotti]aaffffff, primeiro o ext.js e agora o spring… ( de maneiras diferentes, mas no fim da contas, vai acabar dando na mesma )
deveria existir um controle sobre essas mudanças…

[/quote]

Controle? Como um controle? Você alguma idéia do que está falando?

Uma empresa pode licenciar o software dela como bem entender dado que não viole nenhuma licença e é exatamente isso que está acontecendo.
Que catzo de controle que faça o mínimo sentido poderia ser aplicado aqui?

[kicolobo]

Sabe: existe um comportamento que acho muito engraçado.
Quando ocorre algo como o que está ocorrendo com o Spring (o que é natural, uma vez que a empresa VISA o lucro), uma galera critica.
Mas desta galera que critica, percebe-se que é quase inexistente a quantidade de pessoas que de fato contribuem para o mesmo.

[louds]

[quote=kicolobo]Sabe: existe um comportamento que acho muito engraçado.
Quando ocorre algo como o que está ocorrendo com o Spring (o que é natural, uma vez que a empresa VISA o lucro), uma galera critica.
Mas desta galera que critica, percebe-se que é quase inexistente a quantidade de pessoas que de fato contribuem para o mesmo.[/quote]

Lurkers fazem mais barulho que doers. Sempre foi assim.

[David]

First, I’ve seen several people refer to this as a change in Spring’s licensing. That’s simply not true. Spring will continue to be available under the same licenses as before (Apache License 2.0 for most of the Spring portfolio and GPL for SpringSource dm Server). This change only refers to the maintenance policy, and specifically to binary builds.

My understanding of the new policy (confirmed with SpringSource) is that it means no more binary downloads of maintenance releases of Spring projects after 3 months following a major release, unless you’re a SpringSource Enterprise customer. That’s it.

Spring has been, still is, and shall continue to be open-source–with emphasis on “source”. The license did not change. SpringSource will continue to resolve bugs and place those fixes in the public source code repositories. And, as a member of open-source society, you’ll still be able to check that code out and build it yourself.

SpringSource, however, will no longer be obligated to provide binary builds or any other form of support after 3 months following the major release that those changes were applied to. Come to think of it, I’m not sure that they ever really were obligated to do so–but they did so anyway because they’re nice folks and that’s what seems to be expected of them.

Leia completo em: http://www.jroller.com/habuma/entry/what_the_new_springsource_maintenance

[Kenobi]

A verdade é que estabelecer um modelo coerente de remuneração em cima de projetos OpenSource não é uma tarefa muito simples. Não estou defendendo o pessoal do Spring, pois também não gostei muito da notícia, mas entendo as dificuldades que uma empresa pode enfrentar sem um modelo eficiente de obtenção de receita.

[ricardo.ekm]

Se encontrar um bug fora dos 3 meses, a correção sairá na próxima versão grande que sempre é disponibilizada para a comunidade.
Ex. Bug na 2.5.1, corrigido 2.5.2 (só enterprise) e também liberada na 3.0 (comunidade).

[David]

[quote=ricardo.ekm]Se encontrar um bug fora dos 3 meses, a correção sairá na próxima versão grande que sempre é disponibilizada para a comunidade.
Ex. Bug na 2.5.1, corrigido 2.5.2 (só enterprise) e também liberada na 3.0 (comunidade).[/quote]
Mas, como disse o Craig Walls no post que eu citei acima, nada te impede de baixar os fontes e compilar a versão 2.5.2. Para saber como fazer o build do Spring, ver aqui: http://www.jroller.com/habuma/entry/building_spring_from_the_source

[Alessandro_Lazarotti]

Como foi citado o pessoal que critica é o que menos contribui. Afinal nenhuma empresa sobrevive de vento ela precisa de receita. E como ela ainda vai liberar as atualizações durante 3 meses, não custa nada se for encontrado algum bug depois disso, os desenvolvedores da comunidade contribuirem com a correção, ao invés de ficarem esperando os desenvolvedores da Spring resolverem o problema.

Ninguém é obrigado a contribuir com o software que utiliza. Se eu contribuísse em cada software livre que uso, não sobraria muito tempo pra fazer qualquer outra coisa, além de que me seria privada a LIBERDADE de simplesmente usa-lo, que é uma das diretivas free-software.

[marcosalex]

"

[David]

A SpringSource revisou a sua política de manutenção. Ela irá continuar distribuindo os binários de suas versões mesmo após três meses do lançamento de uma “major version”.

Alguns pontos importantes:

However, some in the community expressed concern about the fact that after 3 months tags would not be available in the repository. They worried about the risk of an extended window between binary releases available to the community, when the absence of tags might make it hard to access bug fixes.
[…]
We are amending our maintenance policy in the light of community feedback. We will make regular binary releases from the Spring trunk available to the community, with no 3 month window. For each version of Spring, community releases will be available while it remains the trunk or until the next version is stable.
[…]
As an example, Spring 2.5.x remains the trunk, so under this policy amendment we will be releasing Spring 2.5.6 to the community very shortly. Spring 3.0M1 will be released shortly afterward and the trunk will be for 3.0 development. Once we release Spring 3.0 RC1 we will no longer provide tags or releases for the 2.5.x branch. We will focus on 3.0 development so that we can release 3.0 as soon as possible after the first milestone.

Maiores detalhes em: http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/

[pcalcado]

Acho que agora as pessoas vão se acalmar mas eu não entendi exatamente o que mudaria para a maioria das empresas. Eu conheço diversas aplicação que lidam com bugs conhecidos em bibliotecas por anos até que a nova versão seja “homologada” pela empresa e quem não paga suporte e precisa do bleeding edge pode muito bem compilar. Acho que o real problema é que não teríamos tags no SVN mas este problema não é tão grande.

Na verdade, pensando pelo lado positivo, isso poderia até ajudar o projeto a fazer seus usuários se aproximarem mais do código.

[gulira]

[…]