How SpringSource is taking on Java Goliaths
Some argue that open-source software can't innovate. In fact, one of the industry's former executives, Peter Yared, recently argued that "the only successful open-source companies sell commodities."
Yared clearly hasn't heard of SpringSource, an open-source application platform provider that is redefining the J2EE application server and, quite possibly, the future of open source.
Yared isn't alone in his beliefs. A friend recently wrote me to suggest that open source is at its best when disrupting big, profitable markets:
Commercial open source is a (commodity) replacement market. When it is not (i.e., people are building new, never-done-before cool/future-proof apps with open-source technology), then it is a pure-play Internet-based business model, one that is becoming so specific/demanding that people will want full control and (to) develop their own stuff, e.g., Google, Facebook, and others that heavily use open source to build their Web services.
SpringSource and its ubiquitous Spring Framework, however, promise something different. Something much more ambitious. Not only does Spring challenge the status quo in application development, deployment, and management (Hyperic), but SpringSource is proving that commercial open source can peacefully coexist with community involvement.
In a conversation with Spring creator and SpringSource founder Rod Johnson, he clarified SpringSource's competitive differentiation:
The essence of SpringSource is that we're not a commodity play but have a far more ambitious agenda. We're not interested in replicating what closed-source vendors already offer, at lower price: We are providing a superior experience to developers and operations teams--for example, in our integrated approach to unifying the application life cycle from developer desktop to the data center--which doesn't presently exist in Java.
Of course, our offerings are also leaner (more productive and faster), cheaper and more open than those of the old incumbents, and that's a huge selling point in today's market. But we're focused on being the enterprise Java leader--and not merely in open source.
SpringSource's mantra: Managing the full Java life cycle.
(Credit: SpringSource)SpringSource isn't simply replacing IBM WebSphere, Oracle WebLogic, or Red Hat JBoss application servers. It is actually doing much more, and it offers, in my opinion, the best example of just how disruptive an open-source vendor can be precisely because SpringSource isn't seeking to be the open-source leader in Java, but the leader, period.
Gartner estimates that there are currently at least 2 million Spring developers, an impressive number suggesting that the Java community is looking to Spring to help it migrate Java applications onto lighter-weight containers (Tc Server), across highly virtualized environments, and ultimately to the cloud. Given SpringSource's strong financial performance, the company seems to be doing a good job of monetizing a significant percentage of that Spring adoption.
After meeting with the SpringSource executive team at its San Mateo, Calif., offices a few weeks ago to discuss its strategy, I'm convinced that the company is on track to improve that percentage significantly too.
We're at the point when it's not enough to be "the Red Hat of (CRM, ECM, ERP, etc.)." In a bad economy that sees open-source solutions adopted at an ever-increasing pace, now growing at a 22 percent CAGR (compound annual growth rate), according to IDC, it's time for open-source vendors to lead and develop markets, not simply follow in the wake of established proprietary vendors, picking up their crumbs.
SpringSource is demonstrating how it can be done. It's an aggressive company with the finances, management, and product ambition to become a very big player in enterprise IT within just a few short years. It's a company that Microsoft should fear and that Oracle or IBM should buy.
Of course, SpringSource being SpringSource, it might actually be planning to buy Oracle or IBM instead.
Follow me on Twitter @mjasay.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
Of the 2+ million supposed Spring (Framework) developers, virtually ALL use Spring with Websphere, Weblogic, JBoss, etc. Practically NO ONE uses Tc Server in production. Its not "replacing" anything, with an adoption rate around 0% (granted its fairly new). Even those not using full-blown app servers just use plain Tomcat + Apache httpd instead of shelling money for Tc Server.
If anything, Spring Framework is becoming a hated beast in itself. Ironically, the more bloated & complicated Spring becomes, the more support licenses they can sell. I know many Java-based teams which are now looking to dump Spring in favor of alternatives like Guice (from Google).
While Matt's SpringServer review does read somewhat like a SpringSource press release, we're seeing remarkable uptake on this new product offering, and we expect it to really take off over the next 12-18 months. There are a few reasons for this.
The first is that while stand alone Spring is functional, as you noted much of Spring's production adoption has been with JEE app servers. This was because these App Servers offered a wide range of industrial strength, high performance, computing services for Spring to leverage, not to mention production manageability. That's exactly why BEA got in bed with Spring a few years back, to the benefit of both companies (and perhaps why former BEA WLS GM Peter Cooper Ellis is now at Spring). Spring's TC server allows the customer to get a portion of this broader range of computing services and manageability, all without the cost/bloat of a JEE App Server.
The second is that while TC Server (and Spring itself) is showing signs of impending obesity (why is it that every software product insists that all customers get 100% of the potential functionality when what they really want/need is their 10-15% of it???), it is still a far cry from the bloat of a JEE server. In today's deployment architectures, TC server is simply a much better way to utilize Spring that to use a JEE server.
Another reason is that "plain Tomcat + Apache" actually costs IT organizations quite a bit, because they have to invent their own deployment/management solutions or purchase a (bloatware) commercial solution. We don't have a single client using "plain Tomcat" in production applications...every one is using Tomcat + + +. The interestign question is whether SpringSource can come up with the right combination of "the plusses". A manageable version of Tomcat alone is a winner; when you add a suite of plug-able services around it it becomes the platform for deploying the current and next generations of applications.
My other thought is that we know of no IT organization that feels Spring is a "hated beast", although I do know of a number of them that are concerned with the tendency to add features and capabilities into the blob. We've had this conversation with various people at Spring, and they do seem to "get it" (e.g. modular, light weight, pluggable), but the behavior doesn't seem to be reflecting that understanding. This has been an issue for customers for years (decades), because vendors don't seem ready/willing/able to maintain modular products.
Note what has happened to jBoss, the "WLS killer", which enjoyed a high drgree of success entirely because of the micro-kernal plus plug-able services architecture. It's become a bloated blob under RedHat guidance, sacrificing the very characteristics that made it a success in the first place.
tc Server was designed based off of many many conversations with customers/prospects who are deploying/want to deploy Tomcat widely but have to create their own operational management and diagnostic tools to do so effectively. tc Server focuses on providing a consistent set of enterprise capabilities around Tomcat so customers don't have to do that work themselves.
Moreover, it does so in a way that maintains Tomcat compatibility (i.e. it growls just like Tomcat). This means that custom apps and commercial software products certified for Tomcat can benefit from tc Server's Tomcat+++ capabilities if they want to do so. It also means that if they want to step back down to base Tomcat, they can easily do so.
Disclosure: I work at SpringSource. I previously worked at JBoss/Red Hat as well as Bluestone Software (early J2EE days).
- by sanjayb August 3, 2009 7:35 AM PDT
- At the comments actually explain why SpringSource might be better than commercial app servers. The only reason Matt gave ws that SpringSource was open source which doesn't really explain anything unless you are a open source fanboy.
- Like this Reply to this comment
-
(6 Comments)