Lodestone

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 ?