Open Source lesson: SpringSource falling from grace

I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am sure it has bugs, but I am yet to encounter one). The licence, Apache Software License version 2, was right too. I had even been a step away from joining the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.

Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) deciding small and focused is not beautiful after all. In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.

Then, the inevitable happened. The success of Spring became too tempting. Interface21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company in good standing with the community.

My fear, when I heard the news of funding, was the same as Corby's (from the post at InfoQ):

If anyone had the ability to grow organically, I thought Interface21 did. VC don't give you money unless they're going to grow you 20X. I am very concerned about seeing an explosion of Spring subprojects that lack the quality or the relevance of Spring core. And VC don't give you money unless you're going to cash out. I don't see Interface21 operating as a standalone IPO, so that means they will be actively seeking acquisition. I hate to see one of the big guys get ahold of this very independent entity. I wish the Interface21 folks great financial success, but I hope Spring does not turn into a bloated, slow-release monster. I have already heard rumors that Benchmark Capital is pressuring Rod Johnson to change his name to something more kid-friendly.

Things started to go wrong after SpringSource decided to experiment with their licensing choices. They introduced a number of proprietary products and started using other open source licences. Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL essentially allows businesses to retain control of the code base.) The changes made many members of the community feel insecure, and lead to heated exchanges on the forums. Prior to the changes the company was often called a darling of Open Source (it sounds like something I would have said), because they were a rare example of a business (the Interface21 consultancy) built around the restriction-less Apache Software Licence. I can only conclude that, under the changed circumstances, their business was not growing fast enough, and that they felt that they needed to do things differently.

This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts—today—but do you trust them they will continue to do so? SpringSource are saying they are on the same path they have always been. Maybe they believe it, but they are not on the same path, and the users see it. SpringSource are saying they will keep the Spring Framework alive and open source. I actually believe they are being honest when they say that. But I also know that people come and go and that, eventually, the prosperity of the company may matter more at some point in the future. There is no doubt that Rod Johnson cares deeply about the project, but there is also no doubt the VC company behind the funding cares only about the money.

Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It's the change of direction that's making everyone nervous. For many people open source is about freedom and certainty. They don't want to have vendors to depend on. They've chosen to work with Spring Framework on the basis it's vendor-free. So it's not surprising that they are starting to feel twitchy now that they've realised the company behind their favourite project is a vendor too. If SpringSource want to preserve their hard-earned credibility they need to act fast to insulate themselves from the core Spring Framework project. It's certainly a tough thing to do (convincing the VCs, I mean), but it's the only thing that would bring the user trust back and preserve the developer community (as in those developing the framework itself).

Ultimately, it may not matter. Spring Framework has already built a momentum. It is a very good product, so there is no reason to not use it. But there's no help but feel a bit cheated. We are never going to have the same warm feeling about Spring, as we did back in the old days.

Comments

[Rod Johnson]

Ivan

I'm not sure if blockquote will work here, so I'll paste your text between ####. Apologies for the length of this comment, but I want to reply to virtually every paragraph in your blog. Needless to say, I completely disagree.

####
[Ivan] I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am sure it has bugs, but I am yet to encounter one). The licence, Apache Software License version 2, was right too. I had even been a step away from joining the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.
####
I'm glad that you found Spring's quality and leadership to be of such benefit. We're proud of what it's achieved. I'm sorry that it distresses you to see the folk who provided that leadership trying to improve an area which I'm sure you agree leaves much to be desired: the application server. Or are you completely happy with traditional Java EE servers?

####
[Ivan] Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) deciding small and focused is not beautiful after all.
####
What bloat? Spring's design remains modular. It's surprisingly small given its wide scope. The modularity is demonstrated by the fact that in Spring 2.5 Spring's fine-grained JARs are packaged as OSGi modules.

Furthermore, Spring becomes simpler to use with each release. That's not my opinion, but a statement of fact. Compare the version of the same sample applications in each release. Less Java code; less configuration; better productivity; better for developers. Spring 1.0 certainly blew away anything that was out there in 2004, but I wouldn't want to go back to using it today instead of Spring 2.5.

If you're going to much technical assertions, please advance evidence so we can have a proper debate.

####
[Ivan] In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.
####
A note on this: If I had not started a business, and if that business had succeeded. Spring would probably have ground to a halt, as I needed to feed my family. Until last year, "Spring" was a dirty word to my wife, as it caused years of a significant drop in our living standard, not to mention left me working all hours. Spring has always been overwhelmingly written by a smallish team (all founders or employees of SpringSource). Software of that scope and quality requires a huge amount of effort, and there had to be a revenue model to sustain it.

####
[Ivan] Then, the inevitable happened. The success of Spring became too tempting. Interface21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company in good standing with the community
####
We raised money for two reasons: 1. To ensure that we could continue to develop Spring at the pace we wanted. Before raising money, in late 2006, that was tough. We constantly had to make choices between developing software and making people billable. 2. To realize the vision we have always

We *chose* to raise money. We chose the investors. They invested in OUR vision. If I could show you the business plan we pitched in late 2006, it describes exactly the product we just released.

I think my track record shows that I've been (a) remarkably consistent in my vision and what I believe is write for enterprise Java; and (b) not the kind of person who needs anyone else to tell them what to do.

Look at the huge amount of open source we've released recently: Spring Security 2.0, Spring Web Services 2.5, Spring Batch 1.0, Spring Dynamic Modules 1.0 and much more. All well documented. All high quality. The fact that we can do this is a testimony to our business model.

####
[Ivan] Things started to go wrong after SpringSource decided to experiment with their licensing choices. They introduced a number of proprietary products and started using other open source licences
####
SpringSource Enterprise (our subscription products) meets the needs of many of our customers. If you don't want to use it, don't. The money we make from it helps to pay the salaries of developers developing the open source you do use. So your definition of "things going wrong" is a lot different to mine. It is absurd to object to us developing *additional* products under any license we please.

####
Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL essentially allows businesses to retain control of the code base.)
####
GPL was developed to the FSF to help to increase the use of open source. If you want to develop open source software, it's a good license. It's a problem only for those who want to develop and distribute *closed* products on the open source work of others.

Let's suppose that Oracle decided that they can't be bothered figuring out what to do with WebLogic/OC4j (just hypothetical, obvious) and want to base their next generation server platform on SpringSource Application Server? Without paying us anything or making any significant contribution. Do you think that would be fair? Can you see why we chose a license that would prevent that? OTOH the GPL is absolutely fine for end users.

####
[Ivan] This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts—today—but do you trust them they will continue to do so?
####
This speculation is pointless. I've just given evidence of ongoing contribution to open source on a huge scale. Indeed, the SpringSource Application Platform is a significant new product, and all open source.

Furthermore I have repeatedly made it clear elsewhere and reiterate here that we are absolutely committed to keeping the Spring Portfolio moving rapidly and the best choice for enterprise Java programming.

I believe my (and our) track record merits taking that on trust--especially given the overwhelming evidence of our actions.

####
[Ivan] Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It's the change of direction that's making everyone nervous. For many people open source is about freedom and certainty. They don't want to have vendors to depend on. They've chosen to work with Spring Framework on the basis it's vendor-free. So it's not surprising that they are starting to feel twitchy now that they've realised the company behind their favourite project is a vendor too.
####
There is no change of direction. Spring has overwhelmingly been written by the founders and employees of SpringSource. Our business model has helped our open source grow and flourish since 2004. As we grow as a successful software company we can contribute more and more. Again, I've provided evidence of exactly that happening.

Anyway, apologies for the length of the comment. I am very excited about the future of Spring--and SpringSource. And I sleep very well at night, knowing that we have delivered a lot of benefit to the Java community with Spring, and believing that we are about to do the same thing with respect to the problems of the app server space.

Hope we meet some time so we can discuss these issues in person. Will you be at JavaOne?

Rgds
Rod

[Jim Jagielski]

"GPL essentially allows businesses to retain control of the code base."

As someone who's own s/w is GPL, I'm surprised that you are taking SpringSource to task for creating this product which is GPL, while at the same time SpringSource has numerous codebases under AL and is ensuring people time and time again that they will *remain* AL.

Just because SpringSource (we, since I am Chief Architect for the Covalent Division of SpringSource) add a GPL product to our portfolio does not mean that we immediately drop or de-value our AL code. We love and value AL as much as ever.

[John J.]

I want to preface this by saying I don't know much about spring, so I can't speak to how they have changed. It is always sad to see open source projects feeling the need to add closed "crippleware" or promote close source add ons like it seems you are describing. Personally, as a developer, I find software to be a means to an end, not necessarily and end in and of itself.

I do have to agree with the SpringSource commenters here though about the GPL. The GPL, some would argue, is actually more open than any of the other open source licenses in that it enforces openness first and foremost. GPL doesn't give a company any more control over their software than other open licenses - you can still fork the code and use it to your own purposes. The only restriction on the code is that if you do use it in a product, you must provide the source code as well. It is my understanding that once the code is open under GPL, companies lose complete control over that released code; that code will always be open. You, the originator, can release new (or even the same) versions under different licenses, but once it is out, anyone has the right to re-distribute it as long as they follow the terms of the license.

[Ivan Ristic]

Rod,

Thank you for your lengthy response. It is always comforting to see the guy in charge take the time to engage in a discussion with the community. I am hesitant to respond to each of your comments separately, for I fear the may point may get lost once we go into the details. Quoting myself:

"This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play."

Commercialising open source is damn hard. It's a dirty and conflicting business and I have no intention--whatsoever--to pass judgement. (Update: To clarify, I will not pass judgement on those who conduct business ethically. Those who don't are fair game.) Having walked part of that road myself, my desire now is to observe and comment on the social implications of commercial open source.

Your position is a difficult one, as you are torn, and will be, between the requirements of your business and the requirements of the open source projects under the Spring umbrella. The two will not always be aligned. I am sure it's frustrating having to deal with the perception in the community, in addition to all that hard work, but that's part of the job. I am also sure your intentions are good, but at this point you can tell your users only what you _think_ will happen, not what is actually going to happen. I am not being cynical--as I don't know what's going to happen either, and I refuse to speculate--I am just saying that we don't know.

By the way, I experienced the very same thing when ModSecurity was acquired. The best I could do at the time was to acknowledge the uncertainty, and ask the community to watch closely what we did in the following months. I like to think that things went back to normal when it become obvious ModSecurity continued to grow in the same manner as it did before the acquisition.

It would be a pleasure to meet you for a dinner some time, wherever in the world that might be.

[Ivan Ristic]

Jim,

Let me clarify that I don't think there is _anything_ wrong with SpringSource using GPL, or any other licence for that matter. As you note, I chose to use GPLv2 for ModSecurity, and I did it for the exactly same reasons as you did when you chose GPLv3 for your own product. But the reality is that many people from the Spring community have contrasting opinions on the subject, with some people violently opposing GPL and what it stands for.

[Jim Jagielski]

Ivan, I agree that, especially for us Al-aficionados, that the concept of GPL s/w can be "scary". But that is only for those who react first, and think second (if at all). As you mention, the big concern of people was "What does this mean for Spring s/w that is under the AL?" and the answer is "nothing." It will continue to be AL. In fact our involvement, development and usage (and support) of AL code will increase. AL makes sense in a lot of cases, but no one claims that it is always the "best" license; but as long as the licenses are Open Source, then there is much rejoicing :)

We are working to educate people and alleviate any fears they may have, not matter how unjustified they may be (they are *fears* after all ;) )

[Ivan Ristic]

John,

I would argue something else. GPL is great for companies as it allows them to publish open source software that is free for the end users to use, but practically prevents anyone else from creating a competing product--unless they too choose to distribute it under GPL. This makes GPL a great business vehicle but, in this particular scenario, doesn't work as well when it comes to enticing community involvement. The problem lies in the fact that most organisations choose to keep the code base clean, reserving copyright ownership for themselves (as that allows for a dual-licensing business model).

Different licences have different side-effects when it comes to community building, but the implementation is also important. The Linux development model is based around GPLv2, but each developer gets to keep rights to their own contributions, and that removes the ownership asymmetry. Without the feeling of inequality, the development is thriving.