A chat with David Rosenberg, CEO of MuleSource

By Jeff Gould, CEO & Director of Research, Peerstone Research

Everyone knows that open source is big business. Red Hat, the poster child of commercial open source, is expected to pull in nearly $700 million in sales this year, and Wall Street expects it to be closing in on $1 billion by 2010.

More than any other factor, the financial success of Red Hat has made open source software credible among enterprise buyers. If a company has a market cap of nearly $4 billion, then it must be safe to buy that company's product. By smashing through the credibility barrier in this way, Red Hat has opened doors for other open source companies. If your business can run on RHEL, then maybe it can also run on MySQL, Alfresco and Mule.

To be sure, these up-and-coming open source players are far smaller than Red Hat. When Sun forked out $1 billion for MySQL last January it coyly declined to reveal the database maker's sales, but most analyst estimates put the figure around $50 million per year. When Red Hat paid $350 million for JBoss back in April 2006 (plus a $70 million performance kicker), the open source Java application server was only generating about $25 million a year in sales, though since then that number has probably more than doubled.

But the value of a company is determined by the expectation of future – not current – sales. The valuations investors are putting on these companies imply a strongly bullish forecast about the future willingness of enterprise customers to shell out big bucks for open source software. (That said, if you are a traditional IT vendor, buying one of these rising stars is not guaranteed to fix the rest of your business, witness Sun's loss of a third of its market cap since the MySQL acquisition).

Granting that the open source players are starting out from a small revenue base, simple math tells us that if they keep on growing at their present pace they will sooner or later put some real hurt on the sales of incumbent closed source vendors like IBM and Oracle, who have long dominated enterprise middleware and database sales.

I had a chance to explore that and other issues recently with the CEO of one of these new open source middleware challengers, David Rosenberg of MuleSource, a company best known for its Mule ESB product. Below is a lightly edited transcript of our conversation.

First a note on what exactly we mean by this notoriously slippery term "ESB" which in theory stands for "enterprise services bus" but seems to have widely divergent meanings depending on who you ask. Indeed, according to the Burton Group, the term ESB "has been redefined, overloaded, and diluted to the point where it has no precise meaning" at all. That's probably overstating the case. Most people would agree that an ESB at a minimum is a kind of interpreter which facilitates communications between heterogeneous applications. It acts as an intelligent router of messages between endpoint applications that may be using completely different transport protocols, message formats and message exchange patterns (for example, synchronous and asynchronous). An ESB can decide where to send messages based on their content, and in addition to translating their formats can apply business logic to do useful things to them.

ESB's often serve as on-ramps to high-end reliable message transport software such as IBM's WebSphere MQ or the intriguing open source alternative AMQP. But an ESB can also use plain old http as its transport – it all depends on the circumstances. Beyond message mediation and transport, some vendors – for example, IBM and BEA – go further and say an ESB must also provide a container to host the "service logic" that is applied to messages, making the platform into an application server as well as a mediation server, and thus the foundation for "service oriented architectures" (SOA). Other vendors (like MuleSource) suggest instead that users may prefer to embed their ESB in a third-party application server or a framework like Spring.

Whatever definition you prefer, if money is your criterion the ESB is a software product whose time has come. According to Gartner, ESB sales will exceed $1 billion this year and should approach an amazing $1.5 billion by 2010. In other words, this is a market worth fighting for.

Q: Where is MuleSource today?

A: Ross Mason started the project in 2003. Mule 1.0 was ready by 2005, and that's when Ross and I started the company. We scored our first round of venture capital in 2006, and by that time Mule was starting to get a lot of adoption. We now have somewhere between 2,000 and 3,000 customers, but that translates into a much higher number of installed instances of Mule in commercial environments, that would be in the tens of thousands of servers. We've got 13,000 instances of Mule installed at H & R Block alone.

Q: Who is contributing to Mule?

A: When we started Mule we hired everyone we knew from the community, which was 12 people at the time. Now the community is much larger, we've had 140 contributors over the past year. We now have about 20 developers on our engineering team, plus another dozen or so really significant contributors out in the community.

Q: Why should commercial users consider open source middleware?

A: Before MuleSource I was an IT manager at a user company myself, and I had a lot of experience working with closed source and open source software. As a systems guy, I never understood why I would need an open source database. It didn't seem likely that I would ever want to get involved with the source code of my database. But with application servers and ESBs it's different. These things really need to be open source, because as a user it's a lot more likely that you're going to need to get in there and hack around in order to make them do what you want them to do. Especially in an integration or SOA environment, no two companies ever have exactly the same circumstances. The odds that everything will work exactly the way the vendors anticipated are slim, so you really need the flexibility that open source gives you.

Q: Is Mule ESB ready for prime time in enterprise production environments?

A: If you go back two or three years and look at where JBoss was, they were starting to get a lot of traction in the developer world, but IT architects weren't comfortable putting it into production. You would develop on JBoss, but then you would deploy your application on WebLogic. That's the way it was then, but now things are different. In the last 12 to 18 months people have started to say, why bother with WebLogic, why not just use JBoss in production too? We are seeing exactly the same movement with Mule. The people we talk to about Mule are not just looking at it as some obscure developer tool. They are looking at it as a mission critical platform. They are ready to take an open source ESB all the way to production.

Q: Can an upstart like MuleSource compete successfully against giants like IBM and Oracle?

A: Yes. Customers want best-of-breed, but the big vendors don't want to give it to them. They want to sell big expensive suites. IBM bolts all kinds of other stuff onto its ESB, like MQ [reliable message transport middleware]. Tibco bundles their ESB with a Business Process Management (BPM) server. Products like WebSphere can get the job done, sure. But they are very expensive to buy and very complex to implement. Not everybody wants that.

Q: Do you feel IBM sometimes has a double standard about open source?

A: Yes. They're still pushing the view that open source products like [the Java application server] Geronimo or Mule ESB are just cheap tools for developers, but when users are ready to deploy they should upgrade to expensive IBM stuff like WebSphere. They say they're in favor of open source SOA, but not really. By saying that you have to use WebSphere in production, they're making SOA into a rich man's sport. I think they don't want to talk about open source in production because it's such a big threat to their business. But really I think IBM is missing a big opportunity with Mule. At least half of our customer base is using Mule as a front-end broker and packet shaper for [IBM's MOM middleware] MQ. In other words, there are a lot of IBM customers out there with MQ who prefer to use Mule as their ESB rather than IBM's own ESB. IBM really ought to make friends with us because not all of these customers are going to buy WebSphere ESB.

Q: How does Mule compare to some of the other open source ESBs?

A: There are a couple of answers to that. The first thing is that Mule just works. The other open source ESBs out there don't necessarily work, or at least not in five minutes, like we do. In this day and age, that's something. Another thing is that we've had five years of development, five years of recruiting developers and partners, five years to make our software robust and mature. When you're talking about mission critical systems with a high level of complexity that need high up time, Mule is proven, while the other open source ESBs are not. And it's about more than just technology. It's also about market momentum. Customers don't need ten of everything anymore. In open source there is a real advantage to being the first mover, to being the leader.

Q: What about the open source ESBs based on Java Business Integration (JBI)? For example, there's Sun's OpenESB, and there's Apache ServiceMix, and Iona Fuse, which is a commercial ServiceMix distro. Also, Red Hat has indicated it will support JBI in the JBoss ESB.

A: To tell the truth, I don't think any of the JBI-based ESBs have traction. They've just recently come out with the JBI 2.0 spec, which kind of suggests that JBI 1.0 was pretty rough. I know some people like JBI, but most of the Mule users I talk to are more practical. They don't want to try a science experiment. The fact is we rarely see JBI in the market, it's pretty obscure for a practical IT guy. If you dig down to see why that is, you'll find that JBI puts a lot of restrictions on the way you can do integration. For example, if you're doing data transformation with JBI you have to use XML. But with Mule you don't. If your data is a Cobol copybook or a flat file or just e-mail, you can transform it without going through an XML format stage. JBI adds an extra layer of complexity that is against the idea of Mule. We let you go from system A to system B with one line of code.

Q: What about particular JBI implementations, like Apache ServiceMix?

A: A successful open source project needs a benevolent dictator. The challenge with ServiceMix has been that a lot of hands have been stirring the soup. A project like that really needs a marketing leader, you need someone like a Ross Mason at Mule or a Marc Fleury at JBoss or a Rod Johnson at Spring. But with an Apache project you won't get that. Some companies like Iona have tried to do commercial distributions of ServiceMix with commercial support. But they flopped. ServiceMix is not the most stable piece of software. I know a lot of angry Iona ServiceMix users.

Q: What about other commercial open source ESBs, like JBoss ESB or WSO2's distro of Apache Synapse?

A: The JBoss ESB is based on code that was donated by one of their customers, a Canadian insurance company. At this point I don't think they have much traction. Apache Synapse is in the really early stages, it's a lightweight Java ESB that isn't based on JBI. It's kind of cool, but I don't think it's ready for production at Bank of America or JPMorgan.

Q: How many Mule users are doing EAI as opposed to SOA?

A: There are actually quite a lot of Mule users who are just doing EAI [enterprise application integration] rather than attempting anything like SOA [service oriented architecture]. Mule is very well suited for a wide range of EAI scenarios, ranging from very complex to very simple. When I was on the IT user side of the fence the first EAI product I ever used was Vitria. That was a huge honking beast. It was an enormous ordeal to get it up and running. But with Mule you get the same functionality for far less effort. A lot of people just need to get data from one place to another. They may be doing just ETL [extract, transform, load].

Q: What about users who are actually doing SOA?

A: SOA requires you to think through your whole IT landscape in terms of services. We actually do see a lot of Mule users who are building things now with SOA in mind. In the past 12 to 18 months these design principles have come into play a lot more. We have a Japanese customer who basically built a full-scale SOA without really planning to. They were just trying to use modern design principles. But when they finished they realized it was SOA.

Q: While we're on the subject of SOA, tell us a little about your new repository/registry, Mule Galaxy.

A: Galaxy is an ultra-modern but very easy to use open source SOA governance platform. One administrator can manage thousands of Mule instances with it. It's a browser-based tool that you use to define all your management policies and dependencies. Dan Diephouse wrote it by himself in four months. As far as we know it's the first open source SOA repository/registry out there. Basically until now your only choice has been Systinet [now owned by HP] or Software AG.

Q: How much does Mule cost?

A: Anyone can download the Community Edition for free, of course. We've got well over a million downloads so far. The Enterprise Edition is a superset of that, it has a lot of extra stuff like all the enterprise level tooling and admin tools like Mule HQ. A commercial support subscription for Mule Enterprise Edition essentially bakes out at the annual maintenance fee that IBM or Tibco are charging for their ESBs.

[Note: like most enterprise middleware vendors, MuleSource doesn't publish its prices on its web site. But Larry Dignan and Tom Steinert-Threlkeld over at ZDNet published this very interesting table comparing MuleSource prices to those for closed source ESBs from IBM, Tibco and a few other big-name vendors. The table puts the cost of an annual Mule support contract at $18K, and amply confirms David Rosenberg's claim that Mule is dramatically cheaper than its closed source competitors.]

Q: Is MuleSource for sale?

A: Our goal is to build a big company. You can't be successful if you are just building a company to flip it. The opportunity for open source middleware is getting bigger and bigger. Now that BEA has been swallowed by Oracle, Tibco is the last big independent vendor of closed source middleware. A lot of people think Tibco will get picked off too sooner or later. If that happens, then we will become the biggest independent. We've had a lot of people come sniffing around. But we're here to build a real company. Someone would have to show up with a giant check to make us change our minds.

Interview