Alex Fletcher has a nice list of hypothetical new year’s resolutions for the open source community.
I started thinking about his first resolution: “Enable ease of integration into enterprise stacks”.
This one is really important, and it’s something we heard from IT managers in customer research into open source options back in early 2005. Saving license fees only to have to spend on integration costs with my ‘legacy’ investments isn’t going to help drive open source adoption.
Today, open source projects need to integrate with related traditional commercial software already installed in the enterprise and with other related (leading) open source projects/products. Such decisions are often made by balancing time/resources with the number of potential customers using the product that is to be integrated with. The decision gets difficult when the open source project/vendor decides to offer a competing product to the one they’re considering integrating with.
I’m going to use the following products to help explain my case. I am not making a judgment of JBoss business practices. They are well within their rights & fiduciary duties to do what is necessary to drive Red Hat/JBoss revenue:
- JBoss Co.: The vendor deciding which 3rd party message queuing products will be integrated with their JBoss App Server product
- WebSphere MQ: The leading traditional message queuing product
- JBoss Messaging: An open source message queuing product from JBoss Co.
- AcitveMQ messaging: An open source message queuing product from a competitor
The “integrate with?” decision around a related, leading, traditional commercial product is often simple for an open source vendor. If the market is already dominated by a traditional software product, (WebSphere MQ), then you’d better make sure your open source product (JBoss App Server) plays nice with said product. JBoss Co. may want to compete against that related, leading, commercial product (WebSphere MQ) in the future as they build out an open source stack. But to begin with, JBoss has to respond to customer demand for WebSphere MQ support in order to drive the adoption of JBoss App Server. Once JBoss AS is a known entity by customers, then JBoss can offer their competing messaging product, JBoss Messaging, as they’ve done 🙂
The “integrate with?” decision gets difficult for open source vendors when faced with integrating with a competing open source related product. Should JBoss Co. spend time/resources offering rock solid integration with ActiveMQ when JBoss Co. markets JBoss Messaging, a competitor to ActiveMQ? In this case, neither ActiveMQ nor JBoss Messaging have the customer base that the leading traditional commercial product (i.e. WebSphere MQ) does. So why would JBoss Co. want to help drive adoption of ActiveMQ? This scenario has played out several times already at JBoss, and other open source vendors are going to be faced with a similar situation.
It will be interesting to see how these “integrate with?” decisions play out in 2007. What’s good for the customer may not always win out in these decisions.(but one could argue that happens to the same degree with traditional commercial products). An open community with a plurality of vendors with competing & joint goals is one way of addressing this situation with the scales weighted towards “what’s good for the customer”.
Tag:
Add to 
Bookmark Murdok:
I am taking a semi-break from IBM life as I return to finish a PhD in Industrial Engineering. I’ve held roles in market intelligence, strategy and product management. I’m ex-product manager of IBM WAS Community Edition, and blog about enterprise open source topics.
