Breaking down barriers between buyers and vendors: Aaron Darcy of Red Hat speaks

I spent an hour today with Aaron Darcy, Director of Product Marketing for Red Hat. Aaron works on the JBoss side of the house and is part of the team that has been transitioning JBoss to a Fedora/RHEL model. Perhaps even more interesting, Aaron was a transplant from UBS' IT team. He came to Red Hat with Joanne Rhode, his boss at UBS.

As such, I was interested to hear how the IT world differs from the Red Hat/open source world, and how the JBoss transition has been.

Question: How does the RHEL/Fedora model work in the JBoss context?

In both the Fedora world and the JBoss Application Server world, there are a lot of moving parts. For example, we have individuals teams and communities building Hibernate, Seam, and Application Server at varying paces. At any given moment, version x.x3 of Hibernate may mesh well with version y.y1 of Seam and z.z4 of Application Server, but not y.y2 of Seam.

We have therefore systematized and certified the interaction between these moving parts. In other words, we provide a reference implementation that removes needless guesswork. In a way, then, this is analogous to the difference between kernel.org (i.e., the "upstream" Linux community development) and RHEL, where we're removing a great deal of complexity and packaging it up for a customer to use.

What about when the integration model doesn't cover a version/feature that the customer needs?

We're in a transition process on this, but we're helping customers to see that they're buying into standards. If 90% of the rest of the industry is running our reference architecture, the customer is probably better off adopting the standard rather than trying to color outside the lines. If you're running your own stack, you're in the minority and hence assume more risk. Economies of scale play into the platform model. We're encouraging customers to adopt the standard and benefit from it.

Question: Have you thought of switching from LGPL to GPL to help drive revenues in the JBoss OEM business?

No, because doing so would adversely affect the community that actively embeds JBoss into their projects. We want the world to embed JBoss. We want ubiquity.

In addition, if we went GPL this might also adversely affect adoption of JBoss sales in the non-OEM context. The interaction between an application server and an application is tight enough that someone might argue that the licensing terms of the application server would impact those of the application. For us it's best to just sell value around the software rather than trying to push people pay for a license.

But will OEMs pay if the license doesn't effectively force them to do so?

Yes, if They want the value of our integration and certification model, or if they want support. Between those two things, we're providing enough value that OEM partners have been willing to pay.

You come from UBS where you were on the "buy side." How has that affected your views on interoperability?

Interoperability is critical, especially in the middleware space. No one wants to get locked in. Interoperability with lock-in is not true interoperability. Interoperability through open standards is the way to go. Interop with lock-in keeps the customer where they're at - maybe it locks them into two vendors instead of just one vendor, but that's not a real choice. I've been on the other side of the table and believe firmly that "open interoperability" is the right strategy for customers.

Given your background in corporate IT, how has the Red Hat experience changed your perspective?

The relationship between vendors and IT buyers is broken. IT buyers pay a lot of money and get very little value. Open source fundamentally changes this, because the customer votes with her dollars every year [at subscription renewal].

Also, while it's true that many customers don't want to view or modify source code, the "lighthouse" customers do. They contribute back code. Everone benefits from their involvement, even if they choose not to directly participate.

Ultimately, however, in open source you're buying into a relationship. Service matters to a huge degree. The customer is back in control. It's not about software anymore. Before, on the IT side, the only way that I could exercise control over vendors was through contracts. You're purchasing a right to use [software] in the traditional software world, but in open source the customer has this right without negotiating a thing. Therefore, in open source you're buying into a relationship, a relationship that must be positive or you simply don't renew. That's real power to the customer.

It's one thing to hear this from a vendor. It's quite another to hear it from someone that spent most of his career buying software and implementing it. We would do well to spend more time listening to customers. Fortunately, open source provides the mechanism to do this, both from a code and business model perspective.