Lodestone

May 23, 2012

So it looks like Lodestone is an Open Source project backed by Deutsche Bank, and involving the estimable Martin Thompson of LMAX Disruptor fame. There have been investment bank (IB) backed OSS projects before, notably A+ and OpenAdaptor. And there have been collaborative specification efforts for APIs and message formats, like AMQP, FIX and FpML, which have used OSS like licenses for their intellectual property, and have often adopted reference implementations. However, within the IB vertical none of them have achieved the impact of canonical OSS project like the Linux Kernel, Apache or Mozilla. Why not ?  And why is OSS being touted as a silver bullet for trading systems software again, fifteen years after Eric Raymond’s The Cathedral and The Bazaar first alerted the  mainstream to a different way of doing software ?

My initial answers to the two questions are a little cynical, but when you’ve spent nearly fifteen years working in investment bank technology, cynical has to be your default mindset. As always, let’s follow the money. I suspect a large part of the motivation for open sourcing codebases like A+ and OpenAdaptor is cost driven. As proprietary codebases age inside banks they come to be viewed not as sources of competitive advantage or agility, but as irksome recurring costs preventing investment in other areas. OSS raises the tantalising prospect of getting the much vaunted Open Source “community” to shoulder a lot of the maintenance and testing burden. And at this point in the economic cycle, driving down in house development costs by any means makes sense.

So driving down costs is part of the motivation for OSS. But why didn’t A+ and OpenAdaptor win universal adoption by investment banks ?  Because they don’t provide sufficient incentive to adopt. Take A+, a niche APL based programming language. Why would any bank adopt it if they don’t have a large existing A+ codebase ?  OpenAdaptor is a middleware abstraction layer. It’s raison d’etre is to prevent coupling to underlying commercial vendor ware. Most banks had already built such layers themselves – that’s what IB software architecture teams are for !  Why would they switch from an in house layer that supports all their programming language and OS choices to one that doesn’t, and moreover isn’t controlled by them ?  If there’s no incentive to adopt such codebases, then the originating organisation reaps none of the maintenance and testing benefits that motivated them to open source in the first place. Ergo no cost savings, and a moribund project.

Which leads us to the question of what a bank led OSS project would need to do to incentivise adoption. Let’s bear in mind that the software stack used to build trading applications has  components that range from completely generic, like databases, to highly specific, like quant libraries. IBs won’t open source codebases like quant libraries or algo trading, that stuff really is the special sauce for competitive advantage. And there’s no point them open sourcing very generic stuff like programming languages or middleware abstration layers, where there’s no strong motivator for adoption. But there is a spectrum of code in between that a project like Lodestone should appraise. They need to be codebases where the benefits of cooperation outweigh the competitive edge given up. Those codebases must be vertical specific because the wider OSS world is already addressing truly generic requirements like programming languages and databases, so there’s no significant benefit from open sourcing bank codebases. For examples of IB cooperation we should look to successful consortia efforts. Standards efforts like FpML and FIX meant IBs sharing some of their IP, but that cost is outweighed by the interoperability benefits those standards bring to vendor and proprietary software. Another successful consortium was Tradeweb. The IBs sold their stake to Thomson Reuters, and then realised that they’d lost control of IRS etrading. They launched LiquidityHub in an attempt to shift swap liquidity away from Bloomberg and Tradeweb onto an ECN they controlled. Eventually Tradeweb responded to the LiquidityHub threat by letting the IBs buy back in, and giving them board seats. LiquidityHub was then quietly dropped. IB cooperation had restored dealer control to the swap etrading landscape, and dealers could compete for client inquiries in a trading venue they control.

So we’re looking for codebases that are specific to the IB vertical, that are not special sauce, and where the benefits of cooperation outweigh the cost of any IP give up. My rates etrading background suggests the ECN gateway space as a fruitful one to address. Here there’s an incumbent vendor, ION Trading, with a successful suite of rates etrading software. ION’s suite includes the MarketView gateways that present the same API to all the fixed income ECNs: Bloomberg, Tradeweb, BondVision, MTS, BrokerTec, eSpeed etc. Almost all the leading rates dealers use them. In my experience almost all the leading rates dealers see them as an irksome recurring cost. The time to market and developer headcount savings gained by adopting these gateways has long been discounted, and all the dealers can see are hefty recurring license fees. But the cost of building a set of gateways alone is too high, so nobody does. Why has no third party stepped in and built an OSS competitor to MarketView ?  One reason is the barriers to entry. To build ECN gateways you need access to ECN test systems and APIs. ECNs control that, it’s a cost they want to minimise as they are trading venues not software vendors, so they only give access to IBs.

An IB led OSS consortium like Lodestone could develop open source ECN gateways, sharing the cost of development including ECN test system and API access, and freeing themselves from ION’s license fees. They’d also gain more control: one frequent IB complaint is that new features requested from ION become available to all their competitors a few months later, when they’re rolled into the main codebase. Of course it’s unrealistic to expect anything else from a vendor operating a traditional closed source commercial licensing software model. But this point does highlight another benefit of applying an open source model to the ECN gateway space. Open access to gateway source code means that an individual IB can develop it’s own proprietary extensions, and then choose to give those back to the community, or to keep them secret, and bear the cost of porting and merging going forward. The choice remains with the IB – and that’s a key benefit of free software in the Stallman sense of the word free.

So I believe the Lodestone project should be asking which codebases are IB specific, are not special sauce, and which offer strong cost benefits from cooperation. I’ve  given an example from etrading above. Can you give one from another asset class, or another part of the IB stack, risk management or STP perhaps ?

Advertisements

17 Responses to “Lodestone”


  1. […] The Markets Full blog here: My rates etrading background suggests the ECN gateway space as a fruitful one to address. Here […]

  2. Jim Says:

    Reference data management might be an area to look at; everyone needs to do it but it doesn’t contribute much in the way of ‘special sauce’. Also important to get right in the atmosphere of increased regulatory focus.

    I wonder if the Lodestone effort is a reaction to OpenGamma’s OSS risk platform?

  3. etrading Says:

    Yes, instrument reference data could be a good one, provided as a cloud service through OSS APIs, and covering ISINs, issue dates, quoting and settlement conventions etc. Customer reference data would be tricky one – in my experience every bank has at least two “unique” customer number schemes 😉

    Judging by the Lodestone schematic there’s a big overlap in app infra libs between what OpenGamma has and what Lodestone plan. But I believe OpenGamma is Java, and languages/platforms is still an open question for Lodestone. Another key question is governance and control of the codebase. The Lodestone materials moot the idea of a foundation that has an arms length relationship with sponsors. With OpenGamma the vendor utimately calls the shots for the codebase direction.

    • Kirk Wylie Says:

      One reason why we (OpenGamma) went with the APLv2 is specifically so that if we’re not doing a good job managing the code base, people can fork off in a new direction without hurting their own ability to monetize the results. That being said, whoever is contributing the most code has the most shots I reckon, and we’ve got over 20 people in R&D working on the OpenGamma Platform on a daily basis.

  4. R Jones Says:

    Hi,
    For Risk Management software there is already the excellent OpenGamma FOSS solution.

    What about dropping Cognos that all the Banks use for PentahoBI which is the proper FOSS solution to BI Reporting (BTW a certain noted German bank, spends millions on Cognos every year so, maybe they should listen to their staff which have proposed many solutions to them on FOSS before).

    It seems to me Lodestone should be leveraging existing FOSS solutions to create a Financial IB FOSS Stack and then fill in the gaps that the community has not been able to delivery as in the example you have provided above.

  5. Kirk Wylie Says:

    Hi, I’m the CEO of OpenGamma.

    We view the work of the Lodestone Foundation as collaborative to what we’re doing. Our focus is on analytics and risk, and not trading mechanics. In addition, while we’ve done quite a lot of very low-level work in the mathematics area, if you take a look at the Lodestone Projects list ( http://lodestonefoundation.wordpress.com/projects/ ) you’ll see very little overlap with what OpenGamma has done. And if they’re producing components that we want to use with a license we can use, we’re extremely happy to use and/or improve them!

    The only thing that I’ll say is that I’m looking forward to their first code drops. I absolutely agree with their first principal (“Contribution of quality code should be valued above all else”) and I look forward to seeing that code contribution!

    In the meantime, the OpenGamma Platform (all 750k+ LOC of it) is available on GitHub today.

  6. makis34 Says:

    Is Lodestone still alive? Even the email address seems to be broken and none of the people listed have published Lodestone on their blogs nor do they respond to email.
    I still think it’s a great idea.

  7. ichaib Says:

    I wonder if they would go beyond IB and more into retail banking? We at the Open Bank Project (www.openbankproject.com) might be interested in helping out!
    As someone mentioned earlier, I couldn’t get hold of any of the people on the Lodestone page – let me know if someone can make an intro. Thanks!

  8. etrading Says:

    Yeah – looks like Lodestone is defunct. IIRC DB were main movers behind it – budget must have been cut…

  9. Alastair Blakey Says:

    Good article.

    I think the model of “plumbing+” (in-scope) v.s. “Special sauce” (out-of-scope) is pretty good, and the position that “the Lodestone project should be asking which codebases are IB specific, are not special sauce, and which offer strong cost benefits from cooperation” is a good one.

    But maybe we can usefully invert that question?

    When I’m doing analysis, I like to first determine where the boundaries of the system are (i.e., to half-space the problem: what is “the system” (in-scope), and what is “everything else” (out)). So we get to a set of interfaces, and, uh, contracts, blah..

    Clearly, we have data supplier interfaces… Bloomberg, Markit, et al..

    But, also, we have “special sauce” interfaces. Yield curve models, Duration, convexity, surfaces… Rating equivalencing algorithms.. Optimised Time series database cubes. Algo behaviours for generating trading events…

    – So, instead of asking “what should we include”, which will require everyone to make a sloppy, useless, bucket list…

    – We should ask everyone “what is your special sauce”? What interfaces do you need, to your special sauce components?
    Because every market participant will be able to answer those questions.

    From those answers, we tease things apart, to get discrete interfaces.. (c.f. B-Corp proposes an interface to their secret tricks, and A-Corp proposes an overlapping one, to their tricks. Refactor them apart..)

    When we’ve got all the external interfaces… Then the “plumbing+”, “the system”, is everything that hooks those interfaces together…

    Would be my suggestion.

  10. Alastair Blakey Says:

    Conceivably, Lodestone might become “just” a set of interface specifications. Which would be a huge leap forward.

    Specified in some extensible markup language…


  11. Think it died..
    😦

  12. Nikole Says:

    You share interesting things here. I think that your page can go
    viral easily, but you must give it initial boost and i know how to do it, just search in google for –
    mundillo traffic increase go viral

  13. dendisuhubdy Says:

    Reblogged this on The Conscience of A Libertarian and commented:
    I found it hard to explain why there are no OSS around or low quality OSS. Here is why.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s