OpenGamma and Open Core Components

26 July 2010 By Kirk Wylie In Open Source

One of the most common questions about the OpenGamma Open Source strategy has to do with the "commercial components" that we allude to in some of our web site. That obviously implies some degree of Open Core licensing, but what do we mean by that?

I'm studiously going to avoid any of the religious arguments in favor or opposed to an Open Core licensing strategy, and just talk about how we arrived at this decision, and what it means for customers.

What IS Open Core

If you're not a regular part of the Open Source commercial community (which I expect many blog readers aren't), you might not be familiar with the term Open Core. Essentially, Open Core means:

• There is a core product which is released under an Open Source license; and
• The primary vendor/author of that product has additional components, modules, or functionality which are only available under a proprietary license.

There are a number of reasons why vendors who produce primarily Open Source products will pursue an Open Core strategy, and there's a lot of debate about whether a company pursuing such a business strategy is staying true to Open Source principles.

Again, I'm going to ignore all that, and just talk about OpenGamma.

The Trade Secret Conundrum

The OpenGamma Platform is designed for integration: integration with bespoke software you've written; integration with proprietary vendor systems; integration with hardware and software infrastructure; integration with third-party services. Where those services aren't bespoke, it's a useful thing to be able to leverage a single best-of-breed integration module rather than having every customer write their own.

The problem comes in when you consider that financial technology (pre-OpenGamma of course) is a minefield of proprietary technologies, many of which are subject to Trade Secret and Confidentiality agreements. While you may argue that the firms that make these systems should quit being so closed about their APIs, changing these firms will take a while (if they'll ever open up), and in the meantime, the APIs are all proprietary.

What are we talking about in particular? What types of components might you expect to have restrictive enough licenses that OpenGamma would be forced to release its integration under a proprietary license?

• Market data providers like the Bloomberg Server API and Reuters Market Data Services.
• Trading systems for loading position and security data.
• Reference and golden copy database systems.

So where does that leave Open Source solutions? Unfortunately, going nowhere. While OpenGamma can join developer programs and get access to the APIs, we can't actually release any of the code that we write against the APIs under any public release whatsoever (whether Open Source or not). To provide these modules to customers for pre-built integration options, we must release them under proprietary licenses.

Our Commercial Fairness Principle

There's another category of features and modules that we will probably release as proprietary components, and that's covered by what I call our Commercial Fairness Principle. In essence, this boils down to one statement: if a component only exists to facilitate use of an expensive commercial service, it's only fair for OpenGamma to get revenue for the integrating component.

There are a number of examples of technologies and services in the Financial Technology space which may have open APIs, but which cannot be applied except with licenses that cost a lot of money. They simply aren't useful on their own, so firms that would make use of those technologies have already made a significant commitment to financially supporting those technologies. If OpenGamma produces a component whose exclusive use is to facilitate use of a commercial service, we may make that a proprietary component. We certainly won't do it for everything, but we reserve the right to do so.

A Solution True To Our Beliefs

However, a big part of the OpenGamma vision is to enable developers in the financial services industry by giving them access to the source code that they need to do their job. In addition, we believe that we want to have a positive, collaborative relationship with our customers and partners. How can we square that away with our commercial needs and legal requirements to not ship the source code for certain components under an Open Source license?

We've come up with what we believe is a reasonable solution to this. OpenGamma will give perpetual, royalty-free source code licenses to customers of our proprietary components.

What that means to you is that if you sign up as a customer of one of these components, you have the source code for your whole OpenGamma installation. Just as importantly, if you choose to end your commercial relationship with OpenGamma, you can continue to use the components, and extend and self-support the components through the source code you received.

We think this policy satisfies both of the commitments that we're making to our customers and partners: developers will have all the tools that they need to do their jobs (including source code that they can have immediately available when they need it, and not locked away in an escrow system), and customers and partners will be free to choose to maintain a commercial relationship with OpenGamma or not.

Our Commitment To A Usable Core

Where does that leave the open core part of the architecture? Will it be usable, or will it be artificially limited?

We believe that Open Core only works where the Core is usable, and where the extra components really are specialized, or have legal obligations not to open the source. Hopefully my clarification on what will guide our decision making process for whether something will be a proprietary component or not makes this obvious, but let me be extremely clear.

The Open Source parts of the comprehensive OpenGamma offering will be sufficient in quality, scope, and functionality for production use.