Spring Source: The drug dealer approach to OSS
Posted by billburke on September 23, 2008
Rod and Spring Source continue to make some questionable decisions on the licensing and distribution of the Spring Framework. I’m wondering if Rod is getting some serious pressure to deliver on the more than $25 Million in VC money he’s gotten over the past 2 years, he’s plain getting bad advice, or just had an SMD moment with the OSS freeloaders out there that refuse to buy subscriptions for technology that isn’t much more than an EJB container and Struts.
I told you so!
The latest botched attempt to monetize Spring was the announcment that they would not be releasing community versions 3 months after a major release and further point releases could only be gotten from a subscription. The Spring community was pretty pissed off as noted by this 200 post TSS Thread.
A year ago I warned you VC initiated things like this might happen to Spring when I demanded to Standardize Spring in EE 6. Open source alone doesn’t isolate you from vendor-lockin. Its standards + open source combined that give you true freedom. Its why we standardized Hibernate under JPA and why we’re standardizing Seam under the Web Beans specification.
A Bad Move
The funny thing is, this money grab by Rod and company didn’t need to happen. The move left me scratching my head in wonderment at the stupidity of SS management. This move was stupid for two reasons:
- Spring Source pissed off their community for no good reason. Developers can still get access to the latest and greatest Spring source code, but they have to build it themselves. (And also hope the current branch is stable, but that really shouldn’t be a problem with using SVN and timestamp checkouts). What I bet will happen is some people who haven’t tried EJB3 will try it now. Others will simply look for an alternative like Google’s Guice framework or even JBoss Seam. Others, with more initiative might even fork Spring. Hey, its ASL, it could even live at Apache.org! Actually? No, this isn’t a very big deal. JBoss supposedly pissed off the open source “mainstream” years and years ago (2003) and this didn’t hurt our growth rate, or hinder our dominance. Still, bad PR is bad PR.
- More importantly, Spring Source screwed up their ecosystem. How? Many Java open source projects rely on Spring to bootstrap themselves, or for integration purposes. For example, the Grails projects uses Spring extensively. This move by Spring Source has screwed projects like Grails that have depended on Spring to work. The problem is that 90% of Spring (at least the 90% of what people use Spring for) is the integration it does with other third-party products and projects. What happens to Spring if the third-party projects in their ecosystem stop using Spring to integrate? Rod just endangered the very thing that makes Spring compelling!
A Better Way
What boggles my mind here is that this could have been done very differently. 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. What makes people buy subscriptions is value-add.
The biggest value add is that large organizations want to know that you are going to support versions of your software for years. Let’s say 3-5 years after its released. Spring Source, could have left their announcement at “We will support Spring versions for 3 years” and it would have been a huge win for them. I know it helped our sales when we announced a similar support policy years ago.
Another value-add is what we built with the JBoss Operations Network. JON not only gives you management and monitoring, but also helps with pushing patches and critical security updates to users as quickly as possible. You make distribution a service that people want to pay for.
A third value-add is to give away proprietary add-ons with the subscription. For us, what we did was license or acquire proprietary technology. We licensed the underlying technology of JON, which we later open sourced. We acquired technology from Excedel to help productize our Eclipse tool offering.
The fourth and final, is of course indemnification. Where we protect you legally from lawsuits.
The Drug Dealer Approach
Instead of modeling themselves like other open source businesses, Rod had to take the drug dealer approach to professional open source. Give open source users a free taste of pure open source smack, get them hooked, then charge them big bucks when they need a fix for their Spring addiction. What’s sad, it just didn’t have to be this way.
September 24, 2008 at 12:40 am
[...] REST inspired articles on DZone (Intro. to REST, Putting Java to REST). Bill also provides some sage and hard-earned advice for Rod Johnson - I agree, and said this a while back - monetizing OSS is about more carrot and [...]
September 25, 2008 at 10:53 pm
Totally agree.
VC funding is not necessarily a bad thing, but in this case the motivations are pretty clear…
Silly move from SS (and a boost to EJB3, Guice and Seam adoption…)
Cheers.
September 26, 2008 at 5:43 pm
James. VC funding definitely is not a bad thing. It helped us tremendously to grow, specifically, we could walk the fine line of being cash flow neutral without worrying a lot about making payroll quarter to quarter if something bad happened. And of course it allowed us to make the Arjuna acquisition.
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.
September 27, 2008 at 9:26 pm
Good post. With this new policy, most people instantly ruin their career as a Java developer for building their skills around Spring, including myself.
September 28, 2008 at 6:29 am
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.
September 28, 2008 at 5:05 pm
@Schuman
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.
September 28, 2008 at 11:23 pm
(this is a repost of my post from this morning, which hasn’t appeared yet. I’ve removed the links in it, in case your spam plugin doesn’t like this, although perhaps you just don’t like the content
)
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
September 28, 2008 at 11:34 pm
OK, so let me see if I have understand this all clearly now. When you are trying to look good to the community (e.g. this blog entry), you wrap yourself in OSS righteousness. But your sales and marketing people (oh and Sacha too) tell the community that the community version is unstable, bleeding edge. But the truth is actually that you do not have the time (too many branches) to create separate community and enterprise versions, so you just lie to the community so they’ll buy enterprise. I agree, it’s not a half truth.
September 28, 2008 at 11:35 pm
Just saw your reply to Michael,
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
September 29, 2008 at 1:09 pm
FYI, I approve every comment coming in because wordpress spam filter isn’t that great which is why the delay in your post. I actually don’t go online much on the weekend :), hence the delay in your post.
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.