Fortunately JBoss's Marc Fleury arrived on the open source and Java scenes a few years back, willing -- no, eager (and proud of it) -- to buck software development convention, mess up some hair on both sides of the open source aisle, speak freely (at no charge), and demonstrate that viral adoption and low-cost application runtimes can drive innovation ... as well as turn a profit.
JBoss's impact has been huge: Large commercial software vendors profess to love (some) open source as never before, while gleefully seeking ways to "pull a JBoss" on their fast-commoditizing competitors. Services and subscription models are all the rage. Consultants daily try and build (and sell?) a business like JBoss did.
So now that the acquisition of JBoss by Red Hat is nearly complete, it seemed a good idea to see if Marc has mellowed. More importantly, it is time to try and factor how impactful the JBoss-Red Hat associated arsenal will be for the general software industry -- to see if we are emerging from an era of accidental OSS empires, or actually remain on a long trail to disruptive new software economics up and down the SOA stack.
I therefore posed a handful of questions to Fleury via email, and so we have his answers.
DANA GARDNER: The Red Hat-JBoss combined portfolio of Java middleware, stack components, ecology following, communities, and platforms gives you a number of directions to move in now. How do you decide which of these directions is correct for the market, and in what order? What are enterprises calling for stack-wise? What therefore are the top priorities for creating larger integrated solution offerings?
MARC FLEURY: From a strategic point of view, we are focused on augmenting the JEMS [JBoss Enterprise Middleware Suite] stack into the best platform for web development and service-oriented applications. That means filling in core pieces like ESB [enterprise service bus] and integration, which you can expect later this year. But in some aspects we don't have to decide what to do; the market tells us. Our customers tell us what they like, where they want to see improvements, etc. Open source development gives our customers a voice early on in the development cycle. We are for example beefing up our transaction, messaging, portal, mail, and web development offerings. Even as we build out the best possible stack that optimizes the user experience and simplifies development, we ensure that each JEMS product stands on its own and becomes a category leader, such as JBoss Application Server, Hibernate and Apache Tomcat.
2) One of the things that distinguishes an integrated benefit across stacks is management. Do you plan to encourage open source management, is it a community-appropriate endeavor, or do your partnerships with HP mean management remains a commercial, third-party function? Can you then forecast how the HP-RedHat/JBoss relationship will evolve? Why wouldn't HP open source some elements of OpenView?
Good question. Yes, management is a big part of an integrated story. An OSS management offering will emerge. JBoss and Red Hat combined have an integrated story to bring to market here. The largest distribution of agents that can talk to a management back end will win the day. Even if you have ubiquity of the agent, you need to integrate with the legacy NMS systems. Our strategy with JEMS has been one of enablement. Enabling partners like HP to easily leverage JEMS. Enabling customers to plug any complementary offering, open source or proprietary, into the JEMS architecture. You can expect the same from an integrated management strategy.
3) Will JEMS have a development direction that is different now that the Red Hat acquisition is under way? What will be different?
No. The direction will be the same. What will be different is the pace at which we move in that direction. We will have a financial platform we didn't have by ourselves.
4) What are the most important next market-ready open source stack components needed for an open source SOA benefit to emerge for enterprises? What do you expect in the relevance of an open source ESB?
Open source SOA has already emerged in enterprises. JEMS is used to host business services and integration or intermediary components such as JBoss jBPM in an SOA today. JEMS has many of the components to support a SOA in its Application Server with web services and Java components, JBoss Messaging for a high performance and affordable backbone, Portal with WSRP, jBPM with BPEL, and Rules for even greater modularity and agility in a SOA by separating the business policies from logic and presentation. JBoss ESB is next and it will be the mass market SOA platform that further simplifies the integration of JEMS, other middleware, and customer applications in a SOA.
5) Virtualization has many uses and even definitions. How does virtualization make your stack(s) more competitive? How do you see the use of Xen being adopted in the market?
Virtualization at the OS layers makes a lot of sense. There are many scenarios we deal with at the middleware layer that are in fact better handled by the OS layers. Other scenarios, specifically those that include stateful execution, usually demand some context understanding that is held in the middleware layers. Clustering at the middleware layer and virtualization at the OS layers is what we will pursue. There could be places where OS and MW collaborate for better clustering, but we are not aware of these today. It's equally important to remember that JEMS is written in Java so we don't target native APIs.
6) Do you have a preference of an underlying database for greenfield applications? Are open source DBs good enough? Will proprietary DBs be able to charge a premium for much longer?
The dynamics of the DB market are very particular to that market. Oracle is very entrenched in the enterprise market and MySQL is very successful in the Greenfield market. It seems to be a stable ecosystem. Oracle is defensible and MySQL is doing very well. This is a market that is ripe for a subscription business model as both Oracle and MySQL are proving.
7) I was at a Wall Street panel discussion of SOA recently, and almost all of the speakers were concerned short-term about performance given the loads from large XML and services streams. How will you assuage the concerns of the operations side of the house on SOA performance? Will parallelism be a panacea on this front? Are you encountering any use-cases where transactional or application integration integrity is stymied by performance? What is the long-term solution?
JBoss works with its ecosystem of partners to solve these types of problems. For example, JBoss has a partnership with XML appliance vendor Reactivity. Reactivity builds XML accelerators that enhance the performance and security of JEMS SOA deployments. Reactivity has reported superior performance with JEMS over some of the proprietary, expensive SOA platforms. These types of solutions and greater parallelism mitigate some of the heavier XML traffic we are seeing.
8) SOA appears to be the gift that keeps giving when it comes to professional services and support. But the speed bumps to SOA adoption seem to have more to do with culture, organziation, management, and data/XML management transformation than technology choices. How will Red Hat/JBoss offer organizational solutions for SOA to spur adoption, and how will it work with systems integrators and professional services organizations going forward?
For professional services, JBoss works closely with organizations such as HP and Unisys to provide business services for JEMS to overcome these cultural and organizational issues with respect to SOA. We keep these organizations up to speed on our technology and roadmap. Further, JBoss ESB will include affordable transformation technology to ease the acquisition and deployment of this type of integration platform. We see the ability to increase our bandwidth to these types of organizations within Red Hat.
9) Google and Microsoft are moving into new business models whereby monetization of IT resources and services comes not from the code use or support necessarily, but from an advertising or ancillary knowledge-services marketplace. Why wouldn't such monetization approaches work within your stacks, components, services, communities, and ecologies? Do you rule out such business models? Wouldn't Google make an interesting partner in this regard?
JBoss and Red Hat are successful in monetizing the support component of the enterprise software market. It could be that other models are successful. At this time, however, I don't really have an opinion on these models.
10) The calls keep coming for Sun Microsystems to open source Java, with a recent request for them to simply open source the JVM. Is open source Java in any permutation of value to you? Why or why not? What's your take on Harmony?
Harmony doesn't seem to be very active as a community. IBM will need to bail it out if it wants it to succeed. Open sourcing Java would be interesting, if anything so that the industry would stop talking about it. The benefits would be of second order, namely being capable of fixing bugs quickly in the codebase, maybe taking the VMs in experimental directions more quickly. Some of that agility is needed in Java. Other than that, I consider the question mostly rhetorical.
11) As WAMP continues to grow in popularity, do you have a vision of how the arrival of Vista server will affect this market? Is Windows XP good enough for WAMP? Why would a Vista WAMP deployment not make additional functional sense? How will you support WAMP deployments?
We provide subscription support for RHEL and JEMS. MySQL is supported by MySQL, Windows is supported by Microsoft.
12) Traditionally, a large shift like the move to SOA has been lead by vendors, with their R&D resources. Now, it appears that SOA as a new arena for innovation could be led or at least significantly influenced by a community-driven approach, perhaps organized around a single stack ecology. Why would such a community-based approach to SOA be more successful than a "private-source," vendor-driven or best-of-breed commercial approach to SOA maturation?
Our goal with JEMS is to be the "Open Source Platform for SOA" -- the mass-market, interoperable, SOA platform. We welcome all comers to interoperate with and to coexist with JEMS SOA deployments. For example, we are open to partners' MQ platform plugging into our App Server or ESB, if that is what a customer needs. That MQ or other third-party product or component can be open source or proprietary software. We work with Microsoft on web services interoperability to enhance Microsoft-JBoss SOA deployments. It is this openness along with the high-quality, mass-market and zero-license fee software backed with top quality subscription services that open SOA up to a greater number of customers and deployments by lowering price and consumability barriers.
"Private source" and closed room operations create products that are difficult to consume, develop to, and even understand service component models (look at early J2EE technology). Contrast that with JBoss Seam, an open source web application framework and model that takes JEE programming to the next level in simplicity and developer productivity, even beyond EJB3!
13) If IBM and perhaps others encourage and support an alternative open source stack -- formed around Geronimo, Websphere CE, DB2 Express et al -- how would differentiate yourselves to remain a de facto open source stack standard? Wouldn't having competing such stacks be good for the market?
Competition is always good for the market and we thrive on it. However, a lot of what you mention in an "alternative" OSS stack isn't even open source. WebSphere CE lags JBoss AS in many capabilities such as clustering, transactions, and EJB3, and IBM's strategy is not to incorporate all of them at that price point. I don't see how they can afford to with their cost structure and overhead. Further the term "Community Edition" is really laughable. CE is a low end, closed or "private" source product with minimal support for SOA capability including only single server support for basic web services and EJB 2. It's not OSS. What superstar developer would want to be associated with it?!? "CE" has nothing to do with community and is more like a "Children's Edition" of WebSphere AS.
Contrast this with JEMS -- a robust open source SOA platform with both mass-market appeal and high-end application serving and distributed transactions capability. JEMS includes a Portal that has recently won a deal to drive a 1 billion page-view-per-month deployment. The multi-process language JBoss jBPM, which includes support for BPEL, is key to SOA. JBoss Rules enables enterprises to create a more modular and agile SOA by separating frequently changing business policies out from Java and other business logic. JBoss ESB will go beyond the basic ESB definition and be a SOA integration platform for the 21st century. Finally, the Professional Open Source Model delivers high-quality code and services that enable a better SOA development and deployment experience as illustrated in customer satisfaction surveys.
14) IBM says it doesn't want "anyone to own open," in an apparent reference to you. Your response?
Get over it.