Enterprise Integration Zone is brought to you in partnership with:

I'm an engineer for Gigaspaces Technologies. Joseph has posted 6 posts at DZone. View Full User Profile

Q&A with Rod Johnson over Spring's maintenance policy changes

09.24.2008
| 21002 views |
  • submit to reddit

This is the content of a Q&A I did with Rod Johnson, concerning the uproar over Spring's announced changes in their maintenance release publication. Hopefully, this clears up not only what's going on, but why.

  1. Assume I'm a new user of Spring - I'm considering it for a green-field project. What license am I going to see?

    Spring remains licensed under the Apache License. There is no change of license. [Author's note: See "What does it MEAN?", from the ASL 2.0's FAQ page, on what the ASL says, in layman's terms.]

  2. What does the enterprise support license offer me?

    Subscribers get maintenance releases on whichever version of the framework they are running, for up to 3 years. They also get 24x7 support, which isn't available in the community. Subscribers also receive the SpringSource Enterprise package, which consists of three significant value adds above Spring: the SpringSource Tool Suite (comprehensive Eclipse-based solution for optimizing Spring development); SpringSource Application Management Suite (advanced management and monitoring of Spring-based applications in development and production); and advanced connectivity to Oracle RAQ and AQ.

  3. Now, for the more likely scenario: I'm a longtime user of Spring, I've downloaded every release up to 2.5.5. What am I going to see as far as the releases go?

    With each major version (3.0, 3.1, 4.0...) you will see packaged releases during the first 3 months. After that, you can build your own binaries if you wish to remain on that version--the source will remain open--or you can upgrade to the next major version when it's released.

  4. How do I get the latest and greatest revision of Spring?

    Go through SpringFramework.org and download as you always did. [Author's note: this is exactly what the release policy is changing! Basically, if you're don't have the enterprise support license, the publicly available download might not be the same as the version the support license holders will see. The releases won't be the same if: a major release is more than three months old and updates are available for that major release.]

  5. I use Maven - and as an enterprise customer of Spring, I have access to release versions that the community has to build manually. My customers may or may not be enterprise customers - so they might not have access to the same repositories I have access to. What happens to them?

    We are aware of this issue and will be helping our customers to resolve it.

  6. Why did you make this change?

    We need to balance the needs of enterprise class customers with those of the open source community.

    SpringSource makes a huge investment in Spring development--millions of dollars per year. As more and more releases of Spring are used in production, we cannot divert resources for *free* maintenance of all those releases for conservative customers. We want to be able to focus our efforts for the community on adding new features--we can't afford to have conservative enterprises effectively subsidized by the community. The Federal government may subsidize Wall St: I don't think that SpringSource or the Spring community should be doing so.

    We put a lot of thought into how to balance these concerns, and I think we have a very good solution. This change enables us to serve both types of stakeholders. The community still has access to all the source. Enterprise customers are happy paying for enterprise support and maintenance--for them, having the guarantee of 3 year support is a strong reason in favor of using Spring.

    We believe that this will be good for our business. But we shouldn't have to apologize for that. I've always argued strongly that long term success of open source requires a strong revenue model behind it.

  7. What would you say to those community members who've supported you throughout Spring's lifetime, and feel like you're cutting them off?

    We're concerned at any upset among the Spring community. But I do ask people to make a little effort to understand what we're doing and why we're doing it. I think we've earned that right.

    We are not cutting off the community. Our source code remains open. We continue to make a huge investment in providing what is probably the highest quality open source code base in enterprise Java. We've made something like 100 open source releases this year.

    The only people who are affected by this policy are those who won't or can't upgrade to the latest release, or won't compile Spring under any circumstances. Those people can pay to receive maintenance releases and many other benefits. People who won't touch source under any circumstances and won't pay under any circumstances don't believe in open source: They believe in other people doing work for them for free.

  8. There are people suggesting that Spring be forked, basically taking the codebase and storing it elsewhere for patches, retaining the availability of the public revisions. There are some obvious difficulties with this: keeping compatibility for updates in the main Spring repository would necessarily make the forks almost identical to Spring itself, for example, and there's the obvious "sour grapes" feel to such a thing, but what are your opinions of a potential fork?

    Forks historically don’t tend to succeed, and aren’t in the best interests of open source projects, for obvious reasons.

    I think it would make sense to fork Spring if we were doing a poor job of stewardship of Spring. The reality is that we are delivering an enormous amount of new open source software, with a high quality level and a constant stream of innovation and new features. I don’t see anyone doing a better job, or even anything at remotely the same level.

    I think the community would see through it pretty quickly if a third party company attempted to set up a fork without doing the heavy lifting behind Spring. Will we see an Oracle or the like try to do that? I don’t think so, because I think it would backfire with the community while failing to deliver value to enterprise customers, who want support backed by the developers behind the software. I don’t think any credible software company is naïve enough to try something like that, or wants to incur the bad karma it would bring.

    I wouldn’t be surprised if we do see community builds out there, and they may fulfill a useful need for non enterprise-class customers.

    But above all, it’s hard to see a rational case for forking Spring when the Spring source code is available from the main repository.

Basically, the result is this: if you build Spring from the source repositories, you're always going to have the most recent version, with the most recent fixes. As Rod said: "People who won't touch source under any circumstances and won't pay under any circumstances don't believe in open source: They believe in other people doing work for them for free," and it looks like that's driving this decision more than anything else: an intent to leverage something of great value that they've given to the community.

It's hard to fault them for that.

If you want to know more, Spring has a FAQ on the maintenance policy changes online as well.

Published at DZone with permission of its author, Joseph Ottinger.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

David Karr replied on Wed, 2008/09/24 - 10:33am

I wouldn't mind seeing a clarification of the following statement:

The only people who are affected by this policy are those who won't or can't upgrade to the latest release

I've seen this statement in these discussions multiple times, and it seems confusing to me. If the "latest" release is not available because it's only available to enterprise customers, then what does this statement mean?

 

 

Chris Kent replied on Wed, 2008/09/24 - 10:35am

The point isn't that users will have to build Spring from source if they don't buy support.  The point is that SpringSource won't be tagging the releases in the public repository except for the first 3 months.  So if you're building from source you won't be able to build a specific version because you won't have a tag and you won't know what date or revision to use.

I think it's pretty disingenuous of Rod Johnson to say that the norm for users of open source is to track the latest release when SpringSource refuse to make public what the latest release is by tagging it in the repository.  It's definitely not the norm to track the trunk of the repository, and effectively that's what he's expecting people to do if they want any fixes in the time between the 3 month limit of one release and the next release.

John Denver replied on Wed, 2008/09/24 - 11:52am

Say NO more to this, We are not their dummies or what Spring Source think the community are?, Fools?. Try Guice, try EJB and the coming 3.1 it will rock.

This article Rod Johnson said Java EE 6 gets it right:  http://blog.springsource.com/2007/07/03/java-ee-6-gets-it-right/

They could change their license anytime as ExtJS did. Spring Source loves to change everything in the middle of the game.

I will said again move on guys, We don't need Spring, Even really think twice before use their products.

Regards.

Geertjan Wielenga replied on Wed, 2008/09/24 - 12:05pm

What I don't understand is why this is the way that SpringSource is going to be monetizing (their interpretatioon of) open source technology. What happened to 'support and training' as the place where open source should get its money? If SpringSource doesn't believe that that model works anymore, then that's pretty interesting, but I'd be interested to know why, also because this is probably the precursor to other open source companies doing something similar [something that will probably go one small step further, which will provide the space for the next company to go still further, just one step, and so on].

Andrew McVeigh replied on Wed, 2008/09/24 - 12:14pm in response to: Chris Kent

the tagging point is the big one. it's not like it's all in the repository, just waiting to be built. some information will be hidden.

Rod -- i'm all for monetising and stuff; do what you need to do to make the company a success. However, the net effect needs to be a bit more clearly stated. Without the tags, noone without a subscription will be able to reliably reconstruct a maintenance release more than 3 mths old.

Andrew

Gregg Bolinger replied on Wed, 2008/09/24 - 12:22pm

"People who won't touch source under any circumstances and won't pay under any circumstances don't believe in open source: They believe in other people doing work for them for free"

That is a pretty asshat bold thing to say.  I think I downloaded and compiled Spring from source once in the 5 or so years I've been using it.  And I don't really even remember why I did that in the first place.  I don't touch the source code of a lot of open source projects I use.  But I do contribute to the community in many other ways.  And I do believe in other people doing work for me for free.  Isn't that a huge part of Open Source?

If you don't like working on projects that don't pay, then don't work on those projects.  But don't bash the open source community with some negative connotation that we won't pay for open source products so we must be in the wrong.

The whole point of what SpringSource is really trying to do (which I do understand) is getting completely lost because of the politcal responses and antics surrounding the whole thing.

Andrew McVeigh replied on Wed, 2008/09/24 - 12:40pm in response to: Gregg Bolinger

But I do contribute to the community in many other ways.  And I do believe in other people doing work for me for free.  Isn't that a huge part of Open Source?

I agree with you wholeheartedly.  What would be the knock on effect on the stack if every open source project that spring depends upon decided to do the same thing as they have?  If the net effect of the move is to get corporations to pay, then it would be more pleasant if they just stated that clearly. 

Andrew 

Clinton Begin replied on Wed, 2008/09/24 - 12:40pm

Typo correction:  "Oracle RAQ" => "Oracle RAC"

Thomas K. replied on Wed, 2008/09/24 - 1:15pm

So, assuming I am doing an opensource project, even when I am buying I cannot bundle the Spring release with my project.

So it's no use for me buying the enterprise support. I will use the "latest and greatest" to get a fixpoint for the version number. I discover bugs - does SpringSource want me to submit it, or do they want customers to buy support tickets? (This may result in many bugreports for already fixed stuff!)

The other possibility is to use the svn commit revision as a fixpoint - sounds terrible for me, and like "we couldn't care less about the community." It's just about maximizing money.

Dale Wyttenbach replied on Wed, 2008/09/24 - 1:35pm

I'm trying to understand why they did this, and their FAQ doesn't really answer the question.  I'd guess the answer is to increase the incentive of becoming a paying customer.

I'd further guess that this will be looked back on as a mistake, because of the ill will, and potential adopters having to look elsewhere for solutions because they 1. Don't have time/energy/skills to deal with it themselves and 2. Still aren't willing to pay.

 

Andrew McVeigh replied on Wed, 2008/09/24 - 1:38pm in response to: Thomas K.

So, assuming I am doing an opensource project, even when I am buying I cannot bundle the Spring release with my project.

My (admittedly very limited) understanding is you can distribute it, if you can build it. But with missing tags, reconstituting a >3mth old maintenance release is going to be pretty tough.

The other possibility is to use the svn commit revision as a fixpoint - sounds terrible for me, and like "we couldn't care less about the community." It's just about maximizing money.

My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.

Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.

Andrew

John Denver replied on Wed, 2008/09/24 - 1:41pm

Here Im just ranting Java but If Scala is the next thing maybe we don't need Spring or DI or anything like that.

I found this question:

"Is there any way to write code in Scala as in Java+Spring? I. e. with dependency injection of components."

Answer: "Scala's type system and concise syntax help you"

Another answer with this:

"1) No "impedance mismatch" between Java and Scala idioms; you can integrate code that follows different dependency-injection approaches
    (constructor-injection, setter-injection, service lookup, ..., cake pattern, mix of Java and Scala)
2) Stronger typing (no XML or annotations)
3) No additional framework to learn
4) You have the full power of Scala at your disposal so you have more options for the structuring of configuration itself"

I think I will take a look to Scala and maybe we could say to SUN or JCP that take Scala and release it as Java7 or Java8.

Regards.

Gregg Bolinger replied on Wed, 2008/09/24 - 1:45pm

I don't think this constitutes jumping the java ship nor does it mean we have to give up DI.  There are plenty of IoC containers to choose from.  But that's if you are using Spring in this limited fasion.  There is so much to Spring that if you bought (pun intended) into enough of it you are vendor locked.  One thing I like to avoid which is why I stear clear of full stack solutions.

 That said, I'd be willing to bet some of the community wants to just go back to tighter coupling and get away with all these unecessary abstraction layers running in all our projects.  When is the last time you really needed to drop in a completely different implementation that didn't require quite a bit of work.  All this loose coupling is supposed to help avoid the complexity of having to do that.  But I just don't think anyone really does it anymore.

Andrew McVeigh replied on Wed, 2008/09/24 - 1:47pm in response to: Dale Wyttenbach

I'm trying to understand why they did this, and their FAQ doesn't really answer the question. I'd guess the answer is to increase the incentive of becoming a paying customer.

I think you've nailed the motive on the head.

I reckon that announcements like this would be much better received if they were just in plain english. It's a tiny, weeny-version of the double-speak nightmare that was the Ext-JS debacle. In Spring's case, though, the license is still ASL2 and the guys look to be trying to find a reasonable compromise between getting big business users to cough up and still leaving Spring accessible to the little guy.

I do believe though that if they just put out something like "we are doing this to stop big corporations using our software without paying for support. we are sorry for all the other users, but you will still get to use the newest and most maintenance releases. please bear with us while we find the right model to allow us to keep funding our high quality development path".

The trouble with not being explicit is that people are smart and will work the above out anyway. And then resent not being told in plain form.

Andrew

Geertjan Wielenga replied on Wed, 2008/09/24 - 1:48pm in response to: Andrew McVeigh

[quote=andrewm]

My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.

Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.

[/quote]

 

Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.

Andrew McVeigh replied on Wed, 2008/09/24 - 1:53pm in response to: Geertjan Wielenga

If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability)

(Everything i'm saying is a complete guess, these are just my views)

The trouble with training and support is that they are not truly scalable. So, any VCs i've been involved with (and only a bit) have wanted what they called "product plays". The idea of getting a bazillion people to buy your product is very attractive. Also, another strange thing I found is that VCs want your company to either become a huge success or die as quickly as possible. I guess that's the way the game is.

I think there is still a support model there, but big money comes from being bought out by a vendor who gets value from the free product proposition. i.e. Redhat and JBoss.

Andrew

Gregg Bolinger replied on Wed, 2008/09/24 - 1:56pm

I'd like to know how the Grails team is dealing with this and if they see it as a good thing or bad thing or if they just don't care.  I'm sure they are already tweaking Spring's source so that it integrates better with Grails but it would be interesting to hear some feedback from them.

Andrew McVeigh replied on Wed, 2008/09/24 - 2:27pm in response to: Andrew McVeigh

The trouble with training and support is that they are not truly scalable.

I was thinking about what i wrote, and although it isn't wrong, i don't think it applies in this instance.

My guess is that they are after more support revenue, but are having trouble getting some of the big companies that depend on spring to pay up. I've dealt with this a bit at a major bank.

So, SpringSource are perhaps looking for a way to pressure them to cough up (i.e. if you don't, you *might* have a bug you can't get a patch fix for) without closing the sources to all and sundry.

Andrew

Andrew McVeigh replied on Wed, 2008/09/24 - 2:48pm in response to: John Denver

"Is there any way to write code in Scala as in Java+Spring? I. e. with dependency injection of components."

Well, you certainly could construct a very nice DSL-like language in Scala to wire up POJOs (or is that POSOs?). It wouldn't be hard, and that would give you a container. And it could be strongly typed for sure.

However, it would still constitute a framework or sorts -- it's another language more or less. And unfortunately, learning Scala isn't trivial. I doubt it will ever go truly mainstream the way that "simpler Java" has.

It would also still need a compile phase. One of the virtues of spring's XML config is you can change the properties quickly in a text editor, and restart.

Andrew

Raveman Ravemanus replied on Wed, 2008/09/24 - 2:58pm

I understand why they are doing this, the money is not good enough, they have (or will have) their own app server, but who wants to use not free Spring App Server? On one of my job interviews i heard they are still using CVS, because guy that build likes it better than SVN. Here is going to be the same, we have so many Weblogic/JBoss/WebSphere masters than we dont want/need Spring App Server.

The old apps will still use Spring 2(I understand they can do that, but will get no bug fixes) and new apps will go without Spring. EJB3 will become more hot for new apps and i bet guys that cant switch(a lot of companies are still using WebSphere) to not using Spring will buy what SpringSource is selling(they might also get App Server at very good price). After seeing so many lines of Spring XML i wont missed it, but i think it will never go away. I hope it will push other open source projects and race for becoming next Spring will begin. Now I think Seam on the lead. I don't think Spring is about DI, but about Hibernate and JTA support. Plus its like ultimate Util project. It can be fun :)

Rod Johnson replied on Wed, 2008/09/24 - 3:16pm in response to: Geertjan Wielenga

Geertjan

What I don't understand is why this is the way that SpringSource is going to be monetizing (their interpretation of) open source technology. What happened to 'support and training' as the place where open source should get its money? If SpringSource doesn't believe that that model works anymore, then that's pretty interesting, but I'd be interested to know why, also because this is probably the precursor to other open source companies doing something similar.

Support is central to SpringSource's revenue model.Training and consulting are not adequate to fund a software business. It's not a question of not scaling to generate return to shareholders so much as not being able to reliably pay for software development. Back in 2004-2006, Interface21 (as SpringSource used to be called) was largely a training and consulting company. The result: We lived month to month. Key people like myself and Juergen and Colin Sampaleanu went for months at a time without being paid. Spring 2.0 was around 6 months late because we needed people to be billable--that hurt the community as well as the company. There is a reason that consultancies or training companies tend to produce little worthwhile IP. They can't afford to.

And yes, the economic forces at work here don't only apply to Spring and SpringSource.

Rgds

Rod

Andrew McVeigh replied on Wed, 2008/09/24 - 3:33pm in response to: Rod Johnson

And yes, the economic forces at work here don't only apply to Spring and SpringSource.

To be fair to Rod, I know that he's a good guy (we worked together for a while) who tries to do the right thing both by both the community and his company (which produces s/w for the community). Balancing making businesses pay for support versus being fair to the little guy is tough.

So, Spring stays open source (ASL2), but some tags are removed from the repository after 3mths. It could have been a lot worse -- look at what happened with Ext-JS -- it was pushed into a full GPL license.

On that subject, i'm interested if anyone in the forum has any ideas of a way to achieve the same result (getting people to pay for support) with less grief? (Note that i have no influence in these matters, i'm just interested in people's opinons)

Andrew

Geertjan Wielenga replied on Wed, 2008/09/24 - 3:48pm in response to: Andrew McVeigh

[quote=andrewm]

On that subject, i'm interested if anyone in the forum has any ideas of a way to achieve the same result (getting people to pay for support) with less grief? (Note that i have no influence in these matters, i'm just interested in people's opinons)

[/quote]

 

Like I suggested: an enterprise vs. light packaging scenario. Make people pay for the extra pieces, i.e., those pieces that large enterprises would have no problem paying for but which the small dev shops can reasonably afford to do without while not feeling abandoned.

Andrew McVeigh replied on Wed, 2008/09/24 - 3:56pm in response to: Geertjan Wielenga

Like I suggested: an enterprise vs. light packaging scenario.

I think they have moved in this direction with the app server, but from my (admittedly limited) perspective the issues are that (1) spring is very mature now and does pretty much anything you'd need anyway and (2) funding the extra work to make a compelling enterprise proposition against behemoths like IBM/Tivoli etc.

I obviously can't speak for Rod, SS or anyone else. It's just my take on the situation.

Andrew

Steve Hicks replied on Wed, 2008/09/24 - 4:13pm

While I have happily been using Spring for well over a year I have thought that developers need to know both the Spring and Standards stacks.

I used EJB 2.x for years and thought Spring was heaps better (especially for unit testing). However Seam/EJB3 seem much closer to the Spring stack and once you have a JEE5 application server a viable option.

Working for a big telco I expect that if my company does not buy the Spring Enterprise Support package we (the developers) will use the JEE standards instead.

There seems to me a danger that SpringSource is "killing the goose that lays the golden egg" by not releasing the binaries after the initial 3 month period. I have just done a PoC on Spring WebFlow 2.X and while there is no sight of a 2.5 or 3 version of this and the 2.0 release is already over 3 months old and still missing bits (e.g. declarative validation). If this moves scars of people using Spring then training and consultancy revenue streams will fail. 

 I wonder how this will effect Spring 3.0 adoption!

Otengi Miloskov replied on Wed, 2008/09/24 - 10:40pm

I wrote this on TSS:

Rod without the tags you are pointing to the people that use only the DI and are not interested on the Spring Stack or Enteprise offering to use Guice.

You are afraid of competition?, don't be, Spring Source already it is BIG, nobody can challenge the Spring Framework(Stack and portfolio) really.

Anyway Guice is baked by Google and they use it internally, Also as you said Google have not interest in to make money with Guice they make lots of money with other business but I think that is the strong point of Guice they will keep it forever opensource and sometime Google can throw some cash to Guice so it continue its path. Now if Spring DI doesn't give the tags many people will feel is not real open so many people will go with Google Guice offering. But if you give the tags it will be as JBoss Seam, everybody that works with JBoss Seam is happy and there is not competition for them and they have worked that way like 2 or 3 years?.

Also why SS didn't go from day 1 with straight GPL and now they could have the business model as MySQL dual licensing.
I think for opensource projects have to think more carefully which license will use.

For me the Apache license meaning is I give you for free my work and you can do whatever you want with it. GPL it is Total freedom but you can not do proprietary or even commercial it is just to share with the community so you could apply your dual licensing.

Instead of this Enterprise policy I would prefer it that you announce that the Spring Framework will change their license to GPL or LGPL and offering the dual licensing.

That is more Real OpenSource!. 

Otengi Miloskov replied on Wed, 2008/09/24 - 11:38pm

Rod, I know you need to make money, I understand it but also you could get advice from the OSS and Free and GNU and all the gurus to have an idea how to drive your open source community because this as I see it is like a back stab to the Spring open source community.

2c.

Marc Ende replied on Thu, 2008/09/25 - 2:07am

The only point what's wrong with this maintenance policy is the tagging.

There is no one saying that you shouldn't earn money with open source.

But the question is: Why is SpringSource doing it this way?

All other OpenSource-Companies are using support and training. This seems to work. Many have also enterprise-tested releases, which you can buy if you want. For this releases they also have fixes and releases which are NOT released to the community until the next release for the community.

But they're all not stopping releases for the community after the third month!

The only point, I can imaging, is that SpringSource needs money. With this three months you can't really live if you're working seriously. So they try to push many developers in their maintenance-contracts. They way they're doing it seems to me that they need much money (and of course fast).

I've read Rod's comment in the team-blog of springsource where he'd wrote that the platform and spring are distinct. If I see this "evolution" of SpringSource I can say that they're not so distinct. The maintenance contract is a result of starting the platform. So platform and spring aren't so distinct. If I read the other sentence of Rod's comment, that the license wouldn't change from asl. I'm asking myself how much I can trust in these words. In history someone said "Nobody has the intention of building a wall" and later there was build a wall.

Raul Arabaolaza replied on Thu, 2008/09/25 - 3:22am

As long I understand the only diference is that paying customers will have bug fixes faster than no paying ones. And that to get certain bug fixes I will have to wait and upgrade to the next major release. Is this correct?

Best Regards, Raúl

Jose Maria Arranz replied on Thu, 2008/09/25 - 4:07am

Is very hard to say but dual licensing is the best solution for everyone.

SpringSource knows this and is the model already applied on the SpringSource App. Server.

The best way to understand my reasoning is with an analogy.

Today McAfee, the famous antivirus maker, follows a subscription model for everyone, an antivirus is useless without frequent updates. Today one year upgrade of VirusScan is the bargain of $34.99 and for the European 23,08 EUR.

Imaging McAfee, the famous antivirus maker, changes their bussiness model to the following model to gain more users and may be future customers:

A) Any major version (one per year) is free for anyone.

B) Updates between major versions are only for paying customers.

Probably consequence:

1) Many current customers stop paying saying "hey now is free". Now they are in risk of new virus between releases.

2) Remaining customers see how the support cost increases exponentially (forget $34.99).

This is the problem of open source products with very liberal licenses with a business model behind:  

1) Not paying users are unsatisfied and "in risk". 

2) Paying customers affording very expensive licenses.

If the cost of a Spring license is $25 per developer per year and commercial licensing is mandatory for anyone doing commercial software there wouldn't be a problem.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.