eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Rod Johnson, CEO of SpringSource, created the open-source Spring Framework as a lightweight alternative to the Java 2 Platform, Enterprise Edition. Spring caught on and has become a de facto standard for enterprise Java development. Johnson sat down with eWEEK Senior Editor Darryl K. Taft to talk about the future of the Spring Framework and the SpringSource company, as well as the application server market, open-source licenses and a controversial maintenance plan that stirred uproar in the Spring community.
With your new dm Server as a lead-in and the economy making customers look for alternatives, do you think SpringSource can make some inroads on folks like IBM and Oracle? The combo of Spring + [Apache] Tomcat is a lot cheaper than IBM‘s WebSphere and Oracle’s WebLogic. That said, would you also share your thoughts on the competitive landscape?
In the present economy, customers are looking to control IT budgets. This means taking a close look at costs, including license costs, but also trying to avoid unnecessary complexity in their IT infrastructure. Unnecessary complexity means a lot of unnecessary ongoing costs in development and maintenance. Complexity and bloat are luxuries that no one can afford in lean times. We see Spring and SpringSource technologies in general as major beneficiaries in this environment, because we’ve always helped companies to simplify their enterprise Java development and run-time. It’s in our DNA.
Many companies are adopting Tomcat as their deployment platform for enterprise Java. Many find that it suits their needs better than traditional application servers, as the Java EE [Enterprise Edition] APIs become less used. As the leading contributor to and provider of services around Tomcat, SpringSource is doing well out of this. We don’t really need to promote Tomcat use-just make sure that customers understand that when they need enterprise-grade support for Tomcat, we’re the obvious destination.
Click here to read about SpringSource’s acquisition of G2One, maker of Groovy and Grails.
Dm Server isn’t in quite the same space as Tomcat and the traditional Java EE servers. Sure, it can run Web applications, and that’s the default use of Version 1.0. But the biggest driver to adoption is its modular deployment options, which are way ahead of the competition. Most of the customers we have on dm Server see this modularity as central to their requirements, and more and more companies are experiencing the same compelling business drivers toward modular infrastructures. So it’s not just a cost issue.
Has taking VC money changed your business outlook and philosophy about open source? How?
No. When we took Series A funding, we had been operating for over three years. We had an established culture and vision and an ambitious plan to build dm Server. It was a question of funding our vision and plan, rather than creating a new culture. With funding, we’ve been able to make that plan reality.
I’ve never believed in enterprise open source as charity. I’ve always believed that sustainable, innovative open source requires a viable business model behind it, and I’ve always been vocal about that belief. I think there is a degree of “demonization” of investors in the open-source community that doesn’t make sense. For every dollar that has funded an open-source company, the communities that use the software have derived many times the benefit. All businesses need to make money-businesses without funding are just likely to fail even faster if they don’t make money. The idea that businesses that haven’t taken funding don’t need to worry about revenue and profitability is strange, but strangely prevalent.
Sure, We’ve Made Mistakes
What can you say about SpringSource’s business plan going forward? And, with 20/20 hindsight, are there any decisions or things you wish you or SpringSource might have handled differently?
We are focused on being the leading company in enterprise Java. We’ll be building out our software portfolio and bringing more products to market to help us do that. We’ll be developing more and more software both in open source and in subscription add-ons around it.
Sure, we’ve made mistakes. We probably should have taken funding a year earlier. If we had done, we’d be maybe six months further down the track in building out our vision. But I don’t have any major regrets.
What should we expect from the Covalent integration? Now that SpringSource employs the vast majority of the Tomcat committers, will we start to see tighter Tomcat/Spring Framework integration? Tighter Tomcat/dm Server integration?
Tomcat is used inside dm Server, so Tomcat is central to our server strategy. We’re putting a lot of effort into improving the Tomcat ownership experience for our customers. Spring will remain portable, but certainly Tomcat/Spring is such a popular combination that we’ll be putting a lot of effort there.
The Covalent integration has succeeded far beyond our expectations. Covalent had a great team, and we’ve retained all their permanent employees and have been recruiting into that part of our organization. We’ve gained a lot of deep support expertise, and have grown our involvement in the Apache community and projects such as ActiveMQ.
What was the reaction of your business partners to your new maintenance policy? Were you surprised by the negative reaction of the Spring community to your announcement of your new maintenance policy? Did you make any changes to the new policy based on the feedback from the community?
Our partners understood what we were doing and why, and they felt comfortable with it. I can’t recall any partners who complained to us.
We did modify our initial policy based on feedback from the community, and I think the result is better for it. I don’t think we did a great job initially of explaining to the community exactly what the changes meant to them, and I think that lack of clarity caused some of the reactions. We ended up with a fair solution that has been welcomed by the community, and we remain very community-driven.
In my blog about the maintenance policy one of the points I made was that I wish we could implement a policy that said: “If you are an organization deriving tremendous value from Spring by using it in large production environments, please send SpringSource a check for 1 percent 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.” But in reality, that won’t work. We came up with a fair compromise.
SpringSource Gains Momentum in Enterprise Java
title=SpringSource Plans for the Future}
Enterprise Java will soon be 10 years old, clearly a maturing technology. Put a little more bluntly, why does Spring want to be the next app server if the app server is dying? Moreover, what are you going to be doing to grow beyond this market?
Great question. I agree that the traditional monolithic Java EE application server is a dinosaur. We aren’t in the business of building another one, and I don’t think our users or customers would want us to.
Dm Server is a different animal from the traditional application server. It doesn’t implement the whole grab bag of J2EE APIs-many of which no sane person has used for years-although, it may implement the Java EE Web Profile, depending on whether we feel that output of the Java EE 6 effort is relevant to our customers.
Built on our dm Kernel technology, itself based around OSGi [Open Services Gateway initiative], dm Server is modular from the ground up. It isn’t a one-size-fits-all product. It is able to adapt itself to provide exactly what the user requires for a particular purpose. This is radical new technology. A good analogy is the Terminator. The traditional application server is like Arnold Schwarzenegger’s T-101. It’s big, can usually get the job done, but is a bit clumsy. Dm Server is like the T-1000 in Terminator 2. It can adapt itself as required.
Modular middleware is key to the vision that we have had for years. Darryl, I think the first time we met was when you approached me at a trade show back in 2004, where I was talking about J2EE without EJB. The vision in that book was “a la carte” middleware, and dm Server makes that reality.
The traditional application server may be dying, but there’s still a real need for infrastructure. We believe that the combination of Spring and dm Server is tomorrow’s infrastructure.
Can you comment on which open-source licenses you use at SpringSource and your reasons for choosing each of them?
We’re involved with all the most important open-source communities in enterprise Java. This means that we inevitably work with different licenses.
The key open-source licenses we use are:
Apache License: This is a great license for de facto standard projects such as Spring Framework, which are used by ISVs as well as end users. For example, the Spring Framework is used in the core of Oracle WebLogic, and that’s great. It’s also the de facto standard programming model for enterprise Java, and we want it to be easy to adopt.
Eclipse Public License: We are involved in a number of Eclipse Foundation projects, including AspectJ, which we lead. Those projects are all EPL.
GPL: GPL [General Public License] is the most popular open-source license, industrywide. GPL doesn’t impact end users, but does restrict ISVs in their ability to build closed-source software above open source. That’s a pretty fair restriction. We choose GPL for dm Server, because it solves tough problems that large vendors such as Oracle and IBM have been struggling for years to solve. We think our solutions to those problems are well ahead of the curve, and we don’t see why we should let large companies compete with us with our own code-probably as part of closed-source products that wouldn’t be available to the open-source community.
What are your thoughts regarding cloud computing/SAAS (software as a service)? Cloud computing is about flexibility and simplification, which seems like a natural fit for you guys to go after.
We will be announcing some partnerships in cloud computing at SpringOne Americas in December. Watch this space.
Who do you plan to acquire next?
We don’t have any concrete plans, but we are certainly open to making further acquisitions.
What are the most exciting technologies you see coming for Java, and how could Spring tie into those?
We think OSGi is transforming enterprise Java, and we’ve been heavily involved in bringing it to the server side for years. Spring is becoming the standard component model for OSGi.
We think Grails and Groovy are exciting technologies for the JVM [Java Virtual Machine], hence our acquisition of G2One. Grails is, of course, built on Spring. There’s a lot of potential in dynamic languages on the JVM: It’s not just about Java.