A Question of Balance: Tuning the Maintenance Policy |
|
Running a business is like writing code in at least one respect: You don’t always get it right the first time, even if you know what you want to achieve—but you do get a better result in the end if you are prepared to rework things when necessary. At SpringSource, we had a clear vision for our recently announced maintenance policy: balancing the needs of the open source community with those of enterprise users and the creators of Spring, for the benefit of all. However, we didn’t get the balance quite right first time, and it’s time for some refactoring.
Over the last couple of weeks, I’ve been reminded of the size of the Spring community and the passion of many within it.
We have been intently listening to community feedback—not just from those who are most vocal in public forums, but through many channels including private conversations and emails.
As we listened to the community, two issues stood out: the availability of regular stable releases of the current version of Spring to the community (expressed through requests for tagging of source code in the Spring open source repositories, if binaries were not provided); and pricing for small business and small system integrators. We know that people feel great about Spring software and our commitment to improving enterprise Java; we know that they want SpringSource to succeed and continue to innovate. But we heard real concern and we took it on board.
Today I’d like to restate our commitment to the community for anyone who may have had any doubt, and explain how we’re making a significant change to our maintenance policy in response to the feedback we’ve received.
Our Open Source Commitment
Some have stated concerns that Spring would cease to be open source. The phrase “license change� kept being bandied around—despite the fact that we were not changing the licenses of any Spring code. While such speculation was unfounded, it’s still concerning.
If you got any different impression than that, my colleagues and I must have done a poor job of communicating our maintenance policy—or, perhaps, you’ve heard inaccurate second-hand information. Everything SpringSource does rests on Spring being open source, and a positive engagement with the community. First, we would not make Spring closed source because it would be the wrong thing to do. Second, we understand that given Spring’s central role to many, if not most, enterprise Java projects and to many other open source projects, and as a de facto standard programming model, the impact would hurt enterprise Java significantly. Third, it would be a stupid business decision.
Our commitment to open source remains as strong as ever and continues to grow. We look forward to working together with our community in the coming months and years to build more great software. We’re excited about Spring Framework 3.0 and other forthcoming open source releases, and are proud that we are able to make a bigger and bigger investment in open source.
Stable Community Releases
Our original maintenance policy stated that after 3 months, binary releases on each major version of Spring would be available only to SpringSource Enterprise customers, although source code would always be available (but without version tags).
Thus, we only changed the distribution model beyond 3 months into a major release. We still kept all the source code under the present license. No license change.
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. Some were also concerned about the potential for confusion between different Spring distributions, making communication difficult among the Spring community.
We took these concerns very seriously, and the result of our reflection is that we want to go a step beyond what users were requesting, to demonstrate our commitment to our community—probably the most important community in enterprise Java—and to ensure that it continues to grow rapidly.
Once we have published a release candidate for a new version of a project, we will typically not release further tags or binary builds of earlier versions of the project to the open source community. Such releases will be available for three years to SpringSource Enterprise customers.
A key goal of our maintenance policy is to focus our resources on driving Spring features forward vigorously and continuing to lead and innovate in enterprise Java open source. As we increase our development resources we aim to move forward more quickly than ever before, with frequent major releases bringing new features and capabilities to the community.
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.
Our 3 year support policy (and SpringSource Enterprise) provides peace of mind to enterprise customers, who cannot or will not upgrade frequently. Focusing more of our community development effort on the latest features benefits open source users.
Small Business Pricing
Due to the large enterprise focus of our commercial products, some small companies drew the impression that SpringSource didn’t care about them or did not want to do business with them. This isn’t the case–we had simply prioritized enterprise scale subscriptions. But I can see how people could have drawn that conclusion, and I apologize that our pricing structure created this impression.
We understand that small businesses are active in the adoption of open source and that they make an important contribution to technological advances overall. Thus, we will be introducing a new product offering that is designed and priced expressly for use in small businesses and small SIs. This blog isn’t the place to describe a specific commercial offering, but we will be publishing information about a new product in the near future.
A Fair Balance
It’s clear that we could have done a better job of reaching out to our community to explain what we were doing and why it was necessary.
However, it is important to understand our intentions for having a maintenance policy. First, we’ve never had a maintenance policy and couldn’t go on forever without making clear our commitment to the community and to our customers. As a company, we’re trying to be open with our community, rather than do anything by stealth. Sometimes that involves communicating unwelcome facts that other companies might try to spin their way around. Second, this policy is intended to help us generate revenue from organizations that will not get closely involved with the community, cannot or will not regularly upgrade to the latest release helping to drive Spring quality, and instead find value in receiving maintenance releases on old versions. These types of organizations want rock solid stability, world class support and value the additional software provided by our Enterprise product suite.
We want to build a great company, which can pay its talented developers, earn a reasonable profit and can continue to grow our contribution of great open source software. The more successful we are, the more great code we can contribute to the Spring community. As we have grown over the past 2 years, our ability to generate open source code has grown even faster and the results speak volumes, with more Spring downloads in the last 12 months and more jobs demanding Spring expertise created than ever before.
Many organizations will find value in our Enterprise products, technical support and three years of regular maintenance releases. We also know that many users will decide not to buy these products and services. And that’s OK. That’s how it works in commercial open source. If we can continue to grow our investment in great software, everyone wins.
Here is the policy I wish we could implement:
If you are an organization deriving tremendous value from Spring by using it in large production environments, please send SpringSource a check for 1% of the value you are receiving by using Spring. We will use this money to pay salaries, grow our investment in open source and return a profit.
It would be nice if such a policy would work in practice. It wouldn’t, so we put our maintenance policy in place to generate revenue from organizations using Spring in production and who require enterprise-grade guarantees in their software stack. Meanwhile, by keeping the source open we are continuing to provide the community with great software. Policies, by their very nature, are not perfect, but we believe that the course we have taken is the best balance between the needs of the Spring open source community and the needs of the open source business behind Spring. And, we’re glad that your feedback has helped us make it work better for the community.
No More Telephone Game?
To those who made constructive comments on the forums or in email to me, I’d like to say a sincere thank you. Thank you for caring about Spring enough to think about these issues; thank you for taking the time to set down your thoughts and share them with me. Please keep it up!
Another lesson I would like to draw from this is to try to achieve a more direct communication between SpringSource and the Spring team and the Spring community. You may have played the party game called Telephone Game, and heard of the famous story about how the message from the field in the British army “Send reinforcements, we’re going to advance� arrived at HQ after multiple transmissions as “Send three and fourpence, we’re going to a dance.� Communication in message boards and the blogosphere is important, but not always reliable.
I’d welcome the opportunity to hear your thoughts on better ways to communicate. I’m open to suggestions such as IRC chat sessions, regular open phone conferences… It’s your community too, and I know you have good ideas…
Similar Posts
- Spring Roo 1.2.1.RELEASE available
- Oracle Adds New Exhibit to Java Technology Museum
- SpringSource tc Server 6.0.20.A Now Available
- A Word About the Election
- SpringSource Enterprise Commercially Available
Pierre-Antoine Grégoire says:
Added on October 7th, 2008 at 3:00 pmThis is indeed the right move to end negative commentaries.
Allowing access to the latest releases to the community (therefore improving feedback on newer functionalities) while providing advanced maintenance releases to enterprise customers seems a coherent way to go, and I guess few will be complaining about that.
Thank you for this!
Dan Diephouse says:
Added on October 7th, 2008 at 3:13 pmI'm very glad to see this! This has a huge positive impact for downstream projects – such as MuleSource's Mule & Galaxy projects. With the previous maintenance policy we never would've received critical updates in the 2.5.x line if it were in affect. In essence, we could not have built open source products using Spring which would've been a shame.
Zvika says:
Added on October 7th, 2008 at 3:54 pmCongrats,
It takes guts to admit a mistake, correct it, and then go public admitting and explaining it. It is also clear that under today's market conditions, open source as a viable financial model takes a new level of creativity in defining and implementing revenue streams, and that SpringSource is no different from any other successful open source project in that aspect; Perhaps you guys are even facing a bigger challenge, without a runtime environment such as JBoss or the possibility for a natural dual license such as MySQL's.
Still, for me and perhaps other Spring users the past couple of weeks weren't easy ones. At times, it felt like waking up into a harsh reality where open source is misused as a glue trap similar to what commercial software vendors have been laying over the past decades. No beating 'round the bush: Trust has been broken, and it will take a long time to mend. I am not sure I know why the until-recent model of being Spring Framework's No. 1 training and consulting provider ceased to suffice, and that is none of my business, too. But please be careful in your future plans and actions, as trust that's lost is ever so hard to regain. There's an old saying where I come from: one who got scorched by boiling (water) will be cautious with the cold.
Good Luck,
Cris Holdorph says:
Added on October 7th, 2008 at 4:13 pmNot enough. I'm sure many of the most hard core spring supporters will hail this as SpringSource finally coming back around. But for large projects with long release/maintenance cycles, they can not support upgrading to the latest stable release. This is simply not enough to help allay the fears that the initial announcement caused.
Mario Arias says:
Added on October 7th, 2008 at 5:19 pmMany thanks.
You are moving in the right path.
Long Live to Spring
Karthikeyan C says:
Added on October 8th, 2008 at 12:21 amThis is indeed right move and will make decision makers and developers to stick with Spring. Else Spring may lose customers to Seam [In our company we preferred Seam over Spring [for 2 projects in the interval between the enterprise maintenance policy and today].
Rod Johnson (blog author) says:
Added on October 8th, 2008 at 2:13 amZvika
I've been very open in the past about why we we changed our model–last year, not recently. For example, in this blog.
It's an obvious question, and you have every right to ask it. Training and consulting is still important to us and obviously we have a competitive advantage in Spring training and consulting, and a large business there with thousands of happy customers, and that's great. However, developing complex, high quality products is hugely expensive and is simply not sustainable based on services revenue. These economics don't affect just SpringSource. There's a reason that few very SIs–even of large scale–produce much worthwhile software and maintain it in the long term. And I can't think of a single successful open source company that has created a long-term model that is services driven, yet allows for investment on the scale of ours.
SpringSource is primarily a software company, and it's that revenue model that allows us to produce so much high quality software for the community.
Rgds
Rod
Gabriel says:
Added on October 8th, 2008 at 2:41 amRod,
This is great news indeed! I was quite shocked when the original maintenance policy was published and seriously considered moving to EJB 3.1 in the near future. But now I see that you really do care and listen to the community so I'll stay with Spring that I love ever since I read "J2EE Development without EJB".
I do have a suggestion regarding communication channels: I suggest opening a forum dedicated to feature requests and getting feedback on Spring products and services. Right now posts in these subjects get swallowed in a sea of technical questions in the other forums, so I think a dedicated forum would provide a place for the community to express their requests and opinions. This wouldn't replace JIRA – it's not intended for bug reports, but for real discussion and sharing of opinions.
@Cris: Think of it this way: Let's say there are 10 developers working on Spring products. If all 10 of them are working on fixing bugs and writing new features, it means SpringSource is committing 100% of its manpower to advance Spring, which is the goal of both the community and commercial customers. If 3 developers were to work on work on porting bug fixes to older releases it would mean that SpringSource is committing 70% of its manpower to advance Spring, which is hurting the community and enterprise customers (mostly the community actually). The only way SpringSource could keep tha pace is to hire more developers to port bug fixes to older versions. So let's say 3 extra developers who cost SpringSource 10000$/month do nothing to advance Spring, and the community gets almost nothing from their work, but they do get salaries from SpringSource, so if your company wants to enjoy their work, why shouldn't you pay for it? The alternative is to hire developers yourself which would be responsible to always upgrade your software to use the latest version of Spring, and do you think you could get anyone to do it for free?
I do agree it will not be easy do fix the damage to the reputation which was caused by the original announcement, but I think we should respect the way Rod admitted the mistake and changed the policy according to community feedback, which is something that not every company would do.
Keep on the good work!
Daniel Fernández says:
Added on October 8th, 2008 at 2:51 amThank you very much Rod (and SpringSource), for listening to our complaints.
This new deal is absolutely fair for me. Now, we the same who spread the bad news of the old version of your maintenance policy, are in charge of spreading the good news of your correction. We are on track again.
Regards,
Daniel.
Rod Johnson (blog author) says:
Added on October 8th, 2008 at 2:55 amGabriel
Thanks for the kind words.
I'd be interested to learn more about how you think this should work. Please feel free to email me and copy Adam Fitzgerald (first.last@springsource).
Rgds
Rod
Karl Moore says:
Added on October 8th, 2008 at 3:20 amIt's great to hear some positive news about Spring today after weeks of negative noise! I echo Daniel's sentiment, and hope that this news is reported in just as much as that of recent weeks. Thanks to Rod and the whole of SpringSource for proving that they do care about the communities views and are willing to take other opinions on board.
Thanks for producing a great product over the years and now ensuring I can continue to use it!
Phil Zoio says:
Added on October 8th, 2008 at 4:07 amRod,
Thanks for listening to the concerns of your open source users and recognising the need for "refactoring" in your maintenance policy.
Personally, I would like to see you go further, by guarranteeing that there will be community maintenance releases for at until a year after the initial final release, regardless of whether that version's code has been branched out of the main trunk or not.
Nevertheless, the changes you are announcing will be very reassuring for users who were questioning whether they should continue to back the Spring framework going forward. This will helpful not only for the future of the Spring Framework, but the many other open source projects out there which depend on Spring.
Phil Zoio
http://impala.googlecode.com/ – Impala dynamic modules for Spring
vijaycr says:
Added on October 8th, 2008 at 4:20 amThats good news and makes a lot of sense .
We have never been backward compatablity issues with spring.
We upgraded a program from 1.2.8 to 2.0 to 2.5 and it didnt break any of the 1.2.8 functionalities (at least ones we were using), so for me 3.0.0 will be as good as the latest fixpacks for 2.5.X.
People have no reason for any noise any more
Király Attila says:
Added on October 8th, 2008 at 4:53 amThese are great news. With this maintenance release I can agree something I couldn't do with the original one (because of the lack of trunk binary/tag releases).
However I think that this fiasco hurt Spring and SpringSource a lot. I also started to elaborate alternatives (like picocontainer ejb3/3.1 struts2).
A D says:
Added on October 8th, 2008 at 5:10 amWell, It's good news but still does not gurantee that SS will not do such "-ups" in future. Seeing the amount of backlash, I hope SS has learnt its lesson.
Personally I think if Spring were to merge in JEE at some point in time as a spec, it would have a far greater adoption as companies would no longer be reluctant to go for Spring. Surely it would not hurt SS revenues as they will still be best-of-breed consultants in this area and maybe even manage to sell some Spring DM licenses.
Rod Johnson (blog author) says:
Added on October 8th, 2008 at 5:16 amKiraly
I'm glad you agree with our final maintenance policy.
Regarding alternative technologies: We're sorry whenever people are unhappy with us, but we're always very happy for people to evaluate Spring on merit. We believe its capabilities and quality speak for themselves vs alternatives, and we're working very hard to make Spring technologies even better.
Rgds
Rod
OtengiM says:
Added on October 8th, 2008 at 6:02 amThanks Rod, This is awesome news. I'm very happy that Spring Source listen to their community.
@A D: I think there will be no more such "-ups" in future, Rod is very open and helpful, he is admitting that in the beginning maybe they up with the communication but he and Spring Source listen to everybody, that is a great Value for the Spring Community and I want to congratulate for it. Me also lost confidence but with this announce and Blog it changed my perspective again.
Regards.
Damien says:
Added on October 8th, 2008 at 9:59 amWell played. I had started looking for alternatives, but now I think I can continue to use Spring with confidence.
Michel says:
Added on October 8th, 2008 at 11:02 amThank you so much! This is great news!!!
Rob says:
Added on October 8th, 2008 at 11:44 amThis makes perfect sense. I am completely OK with charging companies that refuse to migrate to the latest version. Thanks for listening to the community and tweaking the policy.
Russell Healy says:
Added on October 8th, 2008 at 4:42 pmFirst up, I'm a firm believer in Spring. It's an excellent framework, envisioned and built by fantastic developers. As a technology, I wouldn't use Java without it.
However, I believe that the approach of limiting access to tagged versions of minor releases is the wrong decision, and will hurt Spring in the long term. In this respect, the new policy is no different to the last.
I believe that part of the reason developers use free and open source software is the guarantee that their investment of time and energy will continue to pay off regardless of where they work/what they do in future. As Sun and Microsoft both realize, it is imperative to attract developers to their platforms, and keep them: http://www.youtube.com/watch?v=8zEQhhaJsU4
The fact that free and open source software is free removes a significant barrier to introducing/adopting that software wherever developers go. They can introduce the software with good conscience, knowing that the future of their project/organization is safe. Once the software has been adopted, and becomes an essential part of the architecture of an organization's systems (as Spring naturally does), the wise and rich organizations will seek out appropriate levels of support.
The new policy removes the ability for developers to introduce Spring as a free and future-proof option. In the short term, it will increase revenues for Spring Source, as organizations with investments in Spring are forced to pay up to maintain peace of mind. in the long term it puts up a barrier for entry, and as a result, I believe developers will slowly move on.
Just my two cents.
John A says:
Added on October 8th, 2008 at 5:24 pmHaving been so busy coding my first web app in spring i missed this announcement and the noize
that followed, but i whole heartedly support Spring Source has taken rational ACTION to find some
approach to improve their financial stability and increase the funding so they can continue creating
GREAT software. As a self funded developer, developing an application on spec this year, and having
worked at a number of startup over 3 decades, i think the free software model that uses "Open" as
a pseudo form of software "democracy" is marginal at best.
Software engineering is EXPENSIVE and few have the resources to do work on the level of excellence
that the Spring sources contain without stable funding. Large corps normally budget $150K /year
per development engineer ( or more now, that was the late 90's figure) for salary and benefits.
So i think the new maintenance policy is a VERY GOOD approach, and i would suggest that
Spring Source might consider a secondary approach to allow the open source community to put up
its own efforts to maintain old major versions with its own manpower, offline from the work done
by Spring Source. Consider that after a new major release has been made, and after the first bug
fix version has shipped, i.e after 3.0.1 is released, SS would provide a fork (into sourceforge?) of
the last SS released 2.5.X version and specifically select a small set of 5? senior and expert
community members to be the Admin's and commit-ers for the "open" old fork.
If open source is REALLY what the community of small developers need and they can do
high quality work fixing bugs, then the old fork will gather support and active contribution efforts.
If on the other hand, this fork does NOT generate active support and contribution, then that
will show that Spring Source IS using the a valid business model and that the excellence of their
work, especially the maintenance releases of old versions, IS worth buying.
I would also suggest that Spring Source consider selling, at their option, one of their own
maintenance versions of the prior major version, that is not under active development, once
during the first year after a major release, separate from the maintenance contract, but at a
price of about 40% the cost of the 3 year maintenance contract. If it were my decision, i
would only offer such a version for sale IF and ONLY IF, a meaningful improvement needed
in production usage has been added. This option would likely not be needed if my public
fork suggestion above, is taken instead; SS could, at its discretion, just contribute a fix
for a serious bug to the public fork, as their resources and funding could occasionally allow.
It is nice to see the very rational decision making by Rod and Co. Keep it up.
best regards, John
raveman says:
Added on October 9th, 2008 at 4:45 amSo nothing change for most people? you just added enterprise option?
Greg Turnquist says:
Added on October 9th, 2008 at 10:35 amRod,
Excellent fine tuning of your maintenance policy. I still don't understand the people that say "not enough". In my opinion, you have responded quickly and smartly to valid criticism, while keeping things professional in response to "I'm forking Spring now" comments.
Yang says:
Added on October 9th, 2008 at 12:35 pmRod:
You did a good job ant tha's a good news for the community.
"As we increase our development resources we aim to move forward more quickly than ever before, with frequent major releases bringing new features and capabilities to the community."
I am understand that must find balance between maintenance and develop new feature with limited resource.It's will be healthy ecosystem for the open source project.
But I think all of us expect freedom ,the full freedom, open all just as other open source community like apache.So I suggest keeping all as before if there is sufficient resources .
Anyway,you are a honorific man at all times.
Thank you very much.
Regards
Yang
Marcel Overdijk says:
Added on October 9th, 2008 at 3:10 pmGreat news Rod!
Manuel Jordan says:
Added on October 9th, 2008 at 8:16 pmDear Rod
Thanks for this decision, dark rumors gone, Spring itself and SS bring us now a clear light to still believeing in the SS effort.
I hope see in important pages soon "Ride to The Glory With Spring 3.0"
Best Regards
-Manuel Jordan (dr_pompeii)
yo says:
Added on October 10th, 2008 at 2:29 amThank you Rod
Dodrin says:
Added on October 10th, 2008 at 3:52 amHey, Rod, great news! THANK YOU!
You know I'have always run away from J2EE things, because I hate the big containers and the limiting specification…
I know that Spring has been gaining more and more popularity, but I have not invested any time to check what it is.
Shortly I have read a "Spring jump start", tried some "hello world" types of programs and I started to like it more and more… then I have decided to invest in gaining more knowledge of how to build applications with Spring in order to use it in my future projects..
And suddenly I heard about this new policy and I said to me :
"I have just found what I have been searching for so long and it just escaped so fast! It's a pity!"
I know that there would have been some reactions, some rebirth of this knowledge, but who knows how time it would have been needed to…
Now everything changes!
I know that there are many developers out there that may have smilar feelings or the others that haven't researched yet Spring may skip to do it in the future if the things weren't changed…
Thank you!
Regards,
Dodrin
Yang says:
Added on October 10th, 2008 at 12:44 pmGabriel says:
" So let's say 3 extra developers who cost SpringSource 10000$/month do nothing to advance Spring, and the community gets almost nothing from their work, but they do get salaries from SpringSource, so if your company wants to enjoy their work, why shouldn't you pay for it? The alternative is to hire developers yourself which would be responsible to always upgrade your software to use the latest version of Spring, and do you think you could get anyone to do it for free?"
I agree with you .I think the alternative is completely considered in terms of community . It's good and very friendly with the community.But springsource is a business commpany,of course is enefit-oriented,So the foremost is get most profit and then take consider with the community.
Anyway,This refactoring policy is friendly with community and that's exactly a good news.
Thanks
Greg Wilkins says:
Added on October 15th, 2008 at 12:36 amRod,
firstly let me say that I think that this issue has mostly been one of style over substance. I think people have taken exception more to the words used than any actual deeds done by SpringSoft.
However, I do have some concern over the open source business model that you wish you could implement. It's a meme that I've seen a few times now, which I think is a little contrary to the spirit of open source. I've blog about this here: http://blogs.webtide.com/gregw/entry/open_source_is_free_software
Bill VanHorne says:
Added on October 15th, 2008 at 11:26 amRod,
A big "thank you" for listening to the concerns of Spring adopters/supporters; well done. If only other software houses were so attentive to their users …
Now, some constructive criticism. When Rod Johnson speaks, like it or not, the whole open-source world is listening. Your initial announcement of the maintenance policy change was confusing and you know that. However the *real* damage you have done to SI and Spring in general was caused by your initial attempts at clarifying the situation.
You managed to classify every single developer who has ever downloaded a Spring binary release without contributing code to the project as a free-loader whose opinion and business you do not value.
I don't think that was what you meant to do, but I'm willing to be proven wrong. I think you're aware of the fact that your Enterprise sales come from the initial adoption and evangelizing by developers. These same developers don't have the time to contribute to OSS projects but do drive OSS adoption in their companies from the trenches of software development.
Your comments, especially in the TSS forums, infuriated a good many of them, several of whom I manage. Insulting the very people evangelizing the use of your software stack in a large corporation doesn't make much sense. I know from experience that there was an initial rush to Guice and Tapestry just after your first attempts at clarification.
You're no longer "Rod Johnson, developer" or even "Rod Johnson, consultant". You are now "Rod Johnson, CEO of SI and voice of open source". Be very, very careful about what you say and how you say it.
Locally, I have put out this fire but there's now a level of distrust of Spring and of *you* that is not going to go away any time soon.
Rod Johnson (blog author) says:
Added on October 15th, 2008 at 12:53 pmBill
I'm sorry if I offended anyone. I didn't mean to. I certainly didn't mean to classify "every single developer who has ever downloaded a Spring binary release without contributing code" as a "freeloader", and apologize if any of my posts gave that impression. (Btw, I'm pretty sure I didn't use the term "freeloader".) I agree that an army of developers contributes to the spread of open source and helps it to succeed–and that's great. I was thinking more of large *companies* and their relationship with the software they use. I believe that that is a very real issue and it's important to raise it.
If I am one of the voices of open source (thanks for the compliment, btw), I think that talking about the sustainability of open source–where it comes from and how it can be depended on in the long term–is an important contribution. It's an issue I've felt strongly about for years. I realize that my position does offend those who believe that open source is "free software": I just don't believe the data is on their side, and there's not much point being a "voice of open source" and not honestly expressing my opinions. I don't believe that open source can escape economics, and I think it's dangerously short-sighted to think that it can.
The end result is that we have a policy that is fair for developers (taking nothing away from them, and offering the potential for more features, faster, through concentration of effort), but which incents large enterprises to pay. I think that's a perfect solution.
Rgds
Rod
Rasmus Lund says:
Added on January 8th, 2009 at 11:49 amI think the title "A Question of Balance" of Rods post is very well chosen.
On one hand SpringSource must have an income, so that they can invest in new development and keep the owners / investors happy.
On the other hand, SpringSource must not harm the godwill they have amongst the people, who choose technologies like Spring for their projects. I have not done any development on the Spring code – but I like to think, that I have contributed by "spreading the word" (I'm one of those people listen to, when they choose which technologies to use). Having an open source product provides a company with a lot of very effective "free marketing". If Spring had been a commercial product, it would never have gotten much attention (I guess).
Thus SpringSource must strike a balance between earning money and at the same time:
* must not offend the people that help spread Spring (and people don't want to help what the see as greedy companies)
* must not "force" the open source purists to do a fork of the Spring code
* must ensure developers/companies can try out / learn how to us Spring for free in small projects before they decide to use Spring in large projects
I think SpringSource has to be very careful not to harm their image. Spring is not that unique anymore, EJB has gotten a lot better and Seam might be challenger as well. Actually I think it is a lot easier to get started using EJB 3 than it is to get started using Spring (which wasn't the case with EJB 2.x).
fawefw says:
Added on March 11th, 2009 at 6:37 pmspring mvc and related technologies suck. end of story.
Krishnan says:
Added on April 15th, 2009 at 12:50 pmJust saw this post. I apologize if this is late in coming. I use various Spring modules (jdbc, orm, mvc, core) in my projects. When I have issues, I try to look in to the source code (my and spring) first. If I still can not resolve them, I look in the forums for resolution or post my question there.
By just skimming through the forums, you can find that there are many questions that go unanswered. If the questions are answered, it is often not by SpringSource experts involved in the issues, but by people who have encountered the same issues but just logged into the forum because they have issues of their own.
I understand that you have to support your enterprise customers to keep SpringSource viable but greater support and help to the (free) Spring forums would be greatly appreciated.