From June 2004, you have put out 14 stable releases of the server. I nthe same amount of time, the Spring guys have put out 32 stable releases of the software (plus a bunch more RCs, and their RCs are generally high enough quality to actually use).

Anyways, we release less often for JBoss AS, because AS is dependent on a multitude of other JBoss and thirdparty projects including, but not limited to: JBoss Messaging (JMS), Hibernate, Seam, Cache, Tomcat/JBossWeb, Transactions, Web Services, EJB, AOP, etc. So, if you add up all the releases of these projects, plus AS, since 2004 I’m sure the number is much greater than 32.

You are criticizing SpringSource for a maintenance policy that is way more generous than what JBoss does. Look at this statement from your own support policies link:

How is theirs more generous? We both have a public source tree. While they stop doing point releases after 3 months, we continue to provide community point releases. 3 months! Moving to a major version for any piece of software for *most* companies takes more than 3 months! Users usually lag way behind the latest and greatest release, especially in open source, and thus most non-show-stopping bugs won’t rear their ugly head until long after 3 months.

Now if the SS had a policy of, 1 year after a major release, or even, there would be no more point releases after a new major version was released, I don’t think the Spring community would have a beef. But 3 months! This is clearly a money grab.

That’s hilarious. So the official policy says, this community version has no guarantees about anything, and has no defined relationship to the enterprise version.

Of course it has a defined relationship.

The enterprise version is a cut from the community version. Like Fedora, patches go upstream AND downstream. Have you ever worked for a product company? Well, if you don’t draw a line in the sand on what *exactly* you are going to support, you will get killed and lose money. If you don’t provide backward compatibility between point releases (and we were notorious for that for years before the Red Hat acquisition), again you will be screwed. The “Enterprise” version is our line in the sand on what exactly we are going to support. And what we’re going to support for 5 years!. The amount of different projects (see above) that must be integrated into AS is a huge QA effort to ensure that everything works nicely together. Right now, enterprise and community are pretty much the same thing mostly because this RHEL/Fedora-like split is new. Eventually you will see the community version get ahead of the enterprise version. Most large organizations don’t want major releases every three months. They want something stable so that they can train their staff on. This is the RHEL/Fedora split where the Fedora thing can move as fast as the community can drive it, and the RHEL thing is the line in the sand, the slow moving reliable unchanging beast-of-burden that revs once a year or once every 2 years. This doesn’t mean that the Fedora thing isn’t high quality or unusable, it just means that RHT isn’t ready to support it, or unwilling to support every feature within the community release.

So basically your policy is based on coercing people willing to pay the money, to think they’re getting something they’re not.

Actually quite the opposite. Our *paying* customers wanted something stable that we will support for 5 years. So, we gave it to them.

Or maybe they actually are, as at the end of the day, I actually have no way to verify what you’re saying about the stuff being the same. Maybe you’re just saying that.

While this split between community and enterprise is not very pronounced in the application server, you’ll see that many (most) projects that make up the application server have advanced and have had major version releases. Cache, Web Services, Tomcat/JBossWeb, and JBoss Messaging come to mind in this regard.

That’s hilarious. So the official policy says, this community version has no guarantees about anything, and has no defined relationship to the enterprise version. But then, the community is supposed to figure out that “they are really one and the same as it’s too hard to maintain so many branches”. But shhh, don’t tell anybody who’s willing to pay for it.

So basically your policy is based on coercing people willing to pay the money, to think they’re getting something they’re not. Or maybe they actually are, as at the end of the day, I actually have no way to verify what you’re saying about the stuff being the same. Maybe you’re just saying that.

Pardon my language, but what it comes down to, is you are full of shit if the policy is really as stated, and your policy is full of shit if things are as you state it.

I will take the crystal clear SpringSource policy and FAQ, any day.

Jim

Bill,

Please explain to me how you are not completely full of shit with this post?

BB>> WE DO NOT DO THIS AT JBOSS!!! WE CONTINUALLY RELEASE COMMUNITY VERSIONS OF OUR SOFTWARE. And yet, we have are are still growing like crazy

First of all, you don’t actually release that many versions of your software. Look at the JBoss server downloads page:

From June 2004, you have put out 14 stable releases of the server. I nthe same amount of time, the Spring guys

have put out 32 stable releases of the software (plus a bunch more RCs, and their RCs are generally high enough quality to actually use).

Anyway, that is not my main point.

You are criticizing SpringSource for a maintenance policy that is way more generous than what JBoss does. Look at this statement from your own support policies link:
—

“”" Projects on JBoss.org are supported only by the community, with no SLA and have changes or features that may not ultimately make it into the JBoss Enterprise releases. As such, those who are interested in using and/or contributing to bleeding edge technology, do not require support and are willing to integrate and maintain multiple projects themselves should leverage JBoss.org projects. “”"
—

So SpringSource very clearly says that for every major version those versions will be packaged and available for the community, and on those branches there will also be packaging for the community for 3 months further to pick up stability and other fixes. Any subsequent fixes on those branches, that are packaged for support customers, are still going into the one and only publicly publicly visible source repo for that branch. Those subsequent fixes are also visible in the HEAD head version of Spring as well, and are even packaged there for the community.

JBoss on the other hand is saying their community versions are out there, and that’s pretty well it: “are bleeding edge”, “no SLA”, and “have changes or features that may not ultimately make it into the JBoss Enterprise releases”. i.e. there is not necessarily any relationship between community and commercial releases except they use some of the same code, and in fact, you shouldn’t trust our community releases (bleeding edge part). No statement about when and if packaging of community versions may happen.

Sweet, I really get the warm fuzzies when I think about using the JBoss community versions.

Let’s get serious, SpringSource has a clearer and more generous maintenance policy and it is better for the community. I will add a personal note to this that as a user of both products since late 2003, I’ve always found the Spring stuff to be way more stable and bug free than most open source projects out there, including JBoss. During this time I spent many days trying to resolve JBoss bugs (damn you JBoss universal classloader!) while Spring just works.

Based on the above, I wouldn’t go anywhere near the JBoss community version except as a trial, with full expectation that I will have to get in bed with JBoss to get anything usable. Based on the above, I still feel pretty good about using Spring in any fashion, and knowing my client can get quality support and maintenance from SpringSource when they need it.

Jim

Its not half truth. What a RHEL/Fedora like split means is that we take a cut of the community release and productize it. It means certain features in the community release might not be in the productized release because they are unstable or a feature we are just not yet ready to support.

In reality, I guess I shouldn’t be saying this, they are really one and the same as its really too hard to maintain so many branches.

“WE DO NOT DO THIS AT JBOSS!!! WE CONTINUALLY RELEASE COMMUNITY VERSIONS OF OUR SOFTWARE

Yeah, Bill. What half truth baloney. Here’s what the JBoss web site (http://www.jboss.org/projects/community-enterprise.html) says:

“Projects on JBoss.org are supported only by the community, with no SLA and have changes or features that may not ultimately make it into the JBoss Enterprise releases. As such, those who are interested in using and/or contributing to bleeding edge technology, do not require support and are willing to integrate and maintain multiple projects themselves should leverage JBoss.org projects.”

Or, in plainspeak: Hey JBoss community, here is a pile of buggy crap. We clean it up behind closed doors and then you can buy an enterprise version when we are done. Oh, but we continually release the pile of crap.

You just have to avoid the vicious circle problem of growing too fast which requires you to give more away of your company. I was really proud of how Marc ran JBoss, first by self-bootstrapping, then by being frugal with how we used our VC money.