20 Jun 2012
The Source in Open Source Is Critical
I think Leslie makes a number of very good points as to why we’re starting to see a wave of Open Source projects springing up which directly target the financial services industry:
- Open Source, with good governance and a commercially-friendly license (like the Apache Public License that we release the OpenGamma Platform under), minimizes vendor lock-in for the benefit of customers.
- Widespread adoption of common technologies makes recruitment easier by broadening the pool of candidates with plug-and-play skillsets.
- Both of those factors put together lead to significantly lower overall cost to financial services firms, critical in today’s era of permanently reduced margins.
However, Leslie ends with a statement that I don't agree with:
So in summary, actual access to the source code does not really make a difference to customers.
Until I co-founded OpenGamma, I spent my entire professional career working as a software engineer (the last 7 years of it in financial services), and access to the source was critical to my being able to do my job. And when I worked for software vendors in Silicon Valley, it was critical to my customers and partners as well.
We work in an industry which requires extensive integration efforts on the part of almost every firm. Market data systems, trading systems, risk systems, back-office systems, partner systems, all of these require integration effort. And our end-users, traders, always have some form of custom work that they need, whether it’s custom screens, custom analytic methods, or custom trading models. That requires a lot of integration.
And integration is where access to the source code becomes critical for developers.
I could write about this subject for days, but I just wanted to pull a few anecdotes of where it’s proven critical to me and firms I worked with.
When I worked at WebLogic on the WebLogic Server EJB container, we were the first EJB container (this is all before J2EE actually existed mind) that had third-party support for pluggable container managed persistence (so you could use your favorite ORM system within WebLogic Server). Although I was under instructions to only submit pre-release jar files to our partners for their testing, as these were pre-release, there were inevitably bugs and areas that weren’t documented as well as they could have been. These partners then actually decompiled the source code so that they knew exactly what WLS was doing under the hood in order to be able to make sure their implementation against our SPIs was operating successfully, to speed time on my responses to their support requests. They did this because access to the source code radically sped up their own development efforts, resulting in a significantly faster, cheaper, and better integration effort.
At the last bank I worked for, we were a customer of a commercial MOM system. Although this system supported the open JMS standard, we had a performance problem that only showed up under very certain conditions. Although I had been working with the support engineers from the vendor, the turnaround time was at least 24 hours for each request, and I wasn't getting anywhere. So I decompiled their Java client library, and it turned out that there was an inefficient data structure being used for the message headers. I very rapidly changed our code and achieved a 30% application performance speedup within 12 hours of decompiling. The source code was critical to me to be able to do my job, and resulted in a faster system with significantly less effort.
At said firm we were using a commercial trading system. Like many customers, we had heavily customized the trading system with integration with our custom analytics library, custom security types that the vendor didn’t support, and a host of custom reports. While this was a mature system with very few bugs, we found that once we hit the wall of the Black Box portions of the system, our development speed slowed down. Were we making the right calls? Did we understand the performance-critical nature of the system? What happened when we needed to include a new library? What compiler flags were required? In the end the firm paid over 10 times our initial license cost for access to the source code for the system; I know several other firms that did the same thing. For us, to speed up and harden our integration efforts, we paid 10 times as much for the source code as we did for the binary version.
OpenGamma's customers are already finding that access to our source code is important for integration, even though they’re not modifying our code themselves. One large hedge fund customer in a matter of weeks had connected the OpenGamma Platform to three internal data sources, connected 5 of their internal custom trading and analytic models to our calculation engine, and wrote custom Excel functions connecting to their own proprietary Java libraries. Without being able to step through the whole system in Eclipse, this process would have taken considerably longer, no matter how good the documentation was. Given what programmers at financial services firms cost, this resulted in clear and measurable savings to the firm.
While all of these examples are anecdotal, one only needs to take a look at broad industry trends to see that Open Source systems are the go-to friends of the developer:
- Tomcat and Jetty have more paid-support customers than any commercial but closed-source implementations of the Servlet and JSP specifications;
- JBoss is far and away the most commercially successful J2EE implementation;
- Spring is the dominant application framework today for commercial Java developers;
- Every major NoSQL and NewSQL system is Open Source: MongoDB, Cassandra, Voldemort, Redis, Riak, the list goes on and on.
Developers have moved, and are moving, with their feet.
While open standards, vendor neutrality, and ease of recruitment are undoubtedly important parts of an Open Source ecosystem, to developers, access to the source code really DOES make a difference.