Opening in the Spring conflict?

On the end of the TSS thread Rod Johnson seems to be willing to consider a compromise with the Spring community.

The suggestion put out by Greg Matthews was that SpringSource would provide tags on maintenance releases only for the most current major version of Spring. So when Spring 3.0 is released, users can use CVS tags to download 3.0.*, up until 3.1 is released.

“e.g. no more tags on the 2.0 branch, continued tags on 2.5 until 3.0 comes out, then no more tags on the 2.5 branch.”

Builds made from these tags could be uploaded to the Maven repos.

Bug fixes for older releases will have to be done manually by patching.

Rod Johnson:

“The idea of tagging the current branch until the next major release comes out is an interesting compromise, and we will consider it.

I would love to have a genuinely collaborative dialog with the community on fine-tuning a fair and balanced outcome, and I’m happy that the discussion now seems to be trending that way.”

I think this is reasonable. It is what I would expect by an Open Srouce project. Normally OSS projects are mostly interested in the newsest version and often not that interested in maintaining old stuff.

I could live with this. But I don’t have the same trust anymore. What will they do next?

To mend the broken confidence, I think SpringSource needs to reach out to the community. Perhaps they should establish a contract with the community, “Community Bill of Rights”.

New Spring policy: maintenance branch to the rescue?

I listened to Alef Arendsen in Stockholm today and he said that the problem for non-customers could be solved by using the maintenance branch.

If you checkout from the maintenance branch you can follow what issues have been fixed by cross referencing with the Jira issues. You will not get unfinished new features - only bug fixes for your release.

We won’t get the official, blessed release, after QA. We will have to trust SpringSource to keep the maintenance branch stable. And we will have to track issues so that our issues are fixed when we build.

On the other hand, the Territory Manager of SpringSource for Europe said that bug fixes might be committed in two batches. You have the risk of checking out in between.

I still have two worries:

* What is the quality of the maintenance branches? I haven’t looked at the Spring CVS for a long time. Will what Alef suggest work?

* Is this just the first step? As Alef said, SpringSource need more money, otherwise Spring will not exist anymore (!). What if this first tough message isn’t resulting in more customers and subscriptions?

What do you think?

Update: Looking at the Spring CVS, it doesn’t seem like they do a lot of maintenance branches? So how is this going to work?

The SpringSource FAQ makes it even worse

Now SpringSource have published an FAQ about the license change (yes, it is a license change). Spring will be dual licensed. The source tree will be using ASF and be considered Open Source. It will not have tags for maintenance releases. There is no way to get bug fixes three months after a release from the Open Source tree.

All maintenance releases will be distributed under a commercial license. You CANNOT distribute them to others, even if you pay for them.

This is really bad.

I was supposed to go to a Spring seminar in Stockholm today. I wonder why I should go. I will not be using Spring in new projects in the future.

Best summary of the problem with SpringSource new policy

I wrote about it here, but Alessandro Santini is explaining it better here.

It’s not about SpringSource making money - I hope they all get stinking rich. It’s not demanding that all software should be free. But it is about blurring the line between closed source and Open Source. And I could do without that.

Open Source culture means making it easy for the community to take part. SpringSource is in fact making the source tree useless for any real work.

Dark clouds over Spring

Rod Johnson writes:

Source code will be published in the source repository. After 3 months SpringSource will continue make maintenance releases as needed to support our customers. There will be no tags in the repository corresponding to those releases.

Rod says in a clarification that the new policy “only affects those who are unwilling to go near source code”. But that is wrong.

The big change is that there will be no more bugfix releases available in binary form after three months AND there will be no tags in CVS. So there is no way to get bugfixes in a secure and maintainable fashion, unless you pay for it.

Here is a scenario from Daniel Fernández:

1. Spring 2.0 is released in Oct 3rd, 2006.

2. I find a bug in 2.0.2 (Jan 8th, 2007) which is important for me, and I report it.

3. Someone at SpringSource (or outside, it doesn’t matter) fixes it for 2.0.3 (Mar 9th, 2007).

4. As 2.0.3 was released more than 3 months after 2.0, I cannot have binaries for it.

5. Of course, I can checkout the source repository trunk, compile, and build but… I don’t have a tag, and I don’t have SpringSource’s “assessment” to know whether all parts will fit together, so I should consider this trunk unstable. This means, of course, that it will not go into my production systems. No bug fix for me.

6. Spring 2.5 is released on Nov 19th, 2007. More than 10 months after the last, buggy version I had the right to have (2.0.2).

You might be able to diff around in the CVS tree, but it will take ages to get to the fixes you need. And there will be no QA, other than the one you do for yourself.

A big change. I’m going to a Spring seminar on Wednesday. I hope there will be time to discuss this.