UPDATE (11 October 2008): SpringSource has tweaked the policy described below to a significant enough extent that I believe it the altered new policy will be palatable to the vast majority of developers using the Spring Framework. More information on this is available in SpringSource Regains Footing with Support Change and A Question of Balance: Tuning the Maintenance Policy.
The recent mini controversy surrounding SpringSource's Enterprise Maintenance Policy announcement provides interesting material for a look at how different people view open source differently. I have talked with professional software developers who still equate "open source" with "free software" rather than recognizing the classic differentiation between "free speech" and "free beer." In fact, I used to be one of these individuals until I attended multiple editions of the Colorado Software Summit in the early 2000s in which Simon Phipps explained each year different ways of looking at what it means to be open source and to be part of an open source community.
The Spring Framework has become wildly successful and widely adopted. There has been some discussion regarding how much "community" participation there is in Spring versus SpringSource direct involvement with Spring. In this blog entry, I intend to examine competing arguments that have been or might be made in this controversy. I can understand the motivations of the principals of both sides of the argument and I want to look at the issue from both points of view. I also intend to look at some possible results of this SpringSource announcement.
This recent announcement by SpringSource and the reactions to the announcement have caused me to reflect on my own participation in the Spring community. I think in may ways I may be representative of the "typical" Spring "community" member. I have never contributed a line of code to Spring and have not even written up a defect or enhancement request (JIRA). However, I feel like I have at least contributed a little to the Spring community by writing an article on Spring for Oracle Technology Network called Add Some Spring to Your Oracle JDBC Access (November 2005) and blogging on Spring occasionally. In addition, as some have stated in their feedback to the recent announcement, I have purchased Spring-related books and told colleagues about Spring. However, these are, in some respects, indirect support rather than direct contributions to the framework itself.
There is no question that we become accustomed to getting what we have regularly received in the past and do not like to hear that this freely given benefit will be removed or have some cost applied to it. For example, when an employer takes away a benefit we have received in the past, few employees will "welcome" that. From this very human perspective, it is natural to not "welcome" the news that SpringSource will not be publishing releases of the Spring Framework to non-Enterprise users after a major release has been out for three months. After all, if I have been enjoying the benefits of polished releases of software for years, why would I welcome extra work on my part or a subscription fee to continue to receive that same benefit?
My understanding is that bug fixes will continue to be available in the repository trunk, but that they will no longer be available in a binary form after the 3-month period following each major release. For many organizations that use Spring, this is a minor new hindrance to using the framework, but probably not enough of a hindrance to stop using the framework altogether unless something else is available for which the benefit-to-cost ratio seems better.
While the Spring Framework's popularity has grown tremendously, there are a growing number of popular alternatives. For example, Java EE 5 (including EJB3) has borrowed heavily from Spring and, in my opinion, is a now a reasonable alternative. Many of the issues that drove developers from EJB 2.x to Spring have now been resolved. There are also other non-standard but popular frameworks like Google's Guice that are available. What developers need to ask themselves is if the added cost of using Spring from here on out (either the cost of the enterprise support or the cost of building Spring releases) is still worth the benefits of using Spring and if the ratio of these benefits to the costs is still better than the ratio of using an alternative to the cost of using that alternative. For example, a developer may choose to use the simplified Java EE 5 on future projects because the extra effort associated with Java EE is so significantly reduced and the ability to write standard code regardless of providers is a desirable advantage. In fact, with a product like GlassFish, that developer can have an open source and standard Java EE 5 implementation.
Developers will likely have some options between becoming SpringSource Enterprise subscribers and ditching Spring altogether for an alternative. Many major vendors already use Spring in their products. As long as these vendors of IDEs (such as NetBeans 6.1 support and Spring Extension for JDeveloper), application servers (such as WebLogic and Oracle Containers for Java EE), other frameworks (such as AppFuse), and other products continue releasing their Spring-based and Spring-supporting products with new versions of Spring, some of the bug fixes and updates may become available to end-user developers via these third-party products. There is always the possibility that these third-party products could drop support for Spring due to this announcement, but the announcement does not seem onerous enough to me to cause that to happen. Finally, there has already been talk of starting a community effort to fill in the relatively small gap being left by this SpringSource announcement. This proposed project would, in theory, be able to take the source code on the publicly exposed repository and build it into a finished distributable like SpringSource does today. There has even been talk of a complete fork off of Spring.
Some developers are feeling trapped. They have tied their products heavily to Spring and so it is not as easy as simply switching to an alternative. Ironically, Spring creator Rod Johnson pointed out in the excellent book J2EE Design and Development that good design includes isolating non-standard and changeable code from standard and stable code. If developers followed this advice with Spring (and in many ways Spring does encourage this isolation), then the migration would be easier than it would have been from proprietary libraries or other third-party frameworks. Even so, the question to ask if if the new cost of using Spring (three year subscription or building Spring on one's own) is enough to justify the certain cost associated with switching to an alternative.
For some larger organizations, this actually might be welcome news because there are still large corporations that prefer professional support. Some clients and some organizations have been reluctant to use any open source products that did not have professional support. They are likely to already be using Spring's Enterprise support and so this won't impact them. Others may have not chosen this option, but do not mind paying the subscription fee and consider it a relatively small cost.
In his blog entry Open Source, Open Strategy: The SpringSource Manifesto, Rod Johnson covers the history of SpringSource (including its days as Interface21) and outlines reasoning behind using a different license for some of the newer products released by SpringSource. He makes valid points such as the fact that many companies sell products using the Spring Framework for significant portions of their functionality. An important and highlighted note in this blog entry is this statement: "We are not changing and will not change the license of any existing project." He goes on to add that this includes the Spring Framework and Spring Security. I think this is significant. The recent Enterprise Maintenance announcement is less of a blow if existing and future Spring Framework code remains open source under the Apache license.
Some have charged that SpringSource is only making this change in support because of their wide adoption and the dependencies people have on the framework. It seems that it is obvious that a move like this is much more likely to be successful after a framework has been evangelized and adopted rather than in its infancy, so I don't think any of us should be too surprised. SpringSource certainly does have some leverage right now and it is certainly greater than it would have been a number of years ago. In fact, in the blog entry Pumping It Dry: $200 a Barrel and $25,000 per CPU, Rod Johnson points out similar tactics in terms of revenue raising implemented by Oracle after their acquiring BEA.
My biggest concern about the recent SpringSource announcement is not the content of the announcement itself. With the assertion in the summer blog about the license for Spring Framework not changing and with Rod Johnson's assertion at TheServerSide's New Spring Maintenance Policy that "SpringSource continues to expose our open source code", I do not see any reason for immediate panic or knee-jerk reactions. Instead, my much bigger concern is worry that this might only be the first in a long series of steps that make Spring less attractive. It will definitely enter my mind when trying to decide how dependent on Spring I want my application to be. In other words, I may choose to use options where I don't need to implement a Spring interface.
It seems obvious that this decision was made to increase SpringSource revenues. I understand that and empathize with the talented individuals who have sacrificed to make Spring what it is today. They definitely deserve some payback for the sacrifice. Making money on open source development is a tricky business model and it is not surprising that it occasionally needs tweaking. That being said, what happens if this move is not enough to garner that payback? Will the license be changed in the future for new versions/releases or will more other much more drastic measures be taken to gain the desired revenue? I like to think that won't happen, but the recent announcement at least reminds one of that possibility.
The long-term implications of this announcement are interesting to ponder. The blog entry SpringSource Will Charge for Updates to Spring, What Comes Next? provides some possible next steps that SpringSource might take in this same direction. While that blog entry focuses on what SpringSource may do, I also wonder how the community will evolve as a result of this announcement.
The following are some questions whose answers we will likely not know for certain until some time has played out.
* Will there be a dramatic decrease in the number of developers and projects using SpringSource products (especially the Spring Framework)?
* Will there be fewer blog entries, articles, and other coverage of Spring Framework due to this policy change?
* Will the developers that stop using Spring be missed by SpringSource if they weren't providing any type of direct monetary benefit to SpringSource?
* Will the developers that stop using Spring be missed by the community if they weren't contributing directly or indirectly to the community?
* What percentage of the developers that stop using Spring or reduce their usage of Spring will be contributors who have performed useful testing and bug and enhancement reporting?
* Will the new policy allow SpringSource to retain and acquire the necessary talent and resources to make the products better for users?
* Will this announcement be the beginning of a bright new era or the beginning of the end of Spring's rapidly growing dominance?
I won't be surprised if this new policy is the subject of some hallway discussion and even some Q&A discussion at the Colorado Software Summit 2008 that occurs four weeks from now. With Matt Raible speaking on What's Coming in Spring 3.0, with Chris Richardson (author of POJOs in Action) speaking, and with a SpringSource employee (Filip Hanik) presenting, it seems likely this will come up.
No product is perfect and the Spring Framework is no different. However, many enterprise Java developers have found it to be extremely useful and helpful and a welcome release from the complications of EJB 2.x. When evaluating a product, I like to look at the entire package including all advantages and disadvantages. The Spring Enterprise Management policy should be considered along with Spring's advantages and disadvantages when deciding whether or not to use Spring. For some, it may be an advantage, for some it may be considered a significant disadvantage, and for many of us it will probably only be a minor disadvantage. The more interesting questions involve the effect it will have on Spring, on the Spring community, and if it is just the first of additional and even more dramatic steps in this direction.
No comments:
Post a Comment