Specialized bond calculation libraries are often used in developing financial market software applications and can be found from a few different sources – both commercial and open source. Finding the correct match for your project or organization is an important decision with potential long-term consequences. Qualifying and selecting the right vendor will help to minimize the overhead costs of current operations and avoid costly migrating to a different library.
Due diligence is required up front to ensure that the bond calculation library selected is fully accurate, performant, and compliant with applicable market conventions and regulatory rules. Making a correct choice prior to project start is key since migrating to a different library component later is an expensive and time-consuming task.
Therefore, a review of some of the considerations and concerns with selecting an open-source bond calculation library instead of a commercial library should be reviewed and understood before making a final decision. Many of the considerations for selecting an open-source bond calculation library mirror those for other open source technology components. Important criteria for vendor selection reviewed below include accuracy, support, defects and missing features, security, technical skills and development support, design choices and user-friendliness, and licensing.
Accuracy must be the top criteria for the selection of any mathematical library – including a fixed income bond calculation library. Even if the library produces results that are accurate 99.9% of the time, in many operating environments one exception out of 1,000 calculations represent an enormous number of support cases requiring time and effort to research and resolve. Open source bond calculation solutions just don’t commit the same level of resources to testing that commercial vendors do. Most often, the volunteer resources working with open source alternatives commit their time and efforts primarily to coding. The time – or lack of it – spent testing influences the quality and accuracy of the solution. In contrast, commercial vendors like my firm, Financial Technology Laboratories (FTLabs), spend a significant percentage of resources to building testing tools, test case benchmark databases, and repetitive automated testing procedures that are carried out after any code change.
There are many open-source products that are well supported – either by the community of users or by commercial organizations that choose to offer paid support for open-source products. However, in smaller, vertical-market products like bond math libraries, neither of these is common. One of the most important considerations in the selection of a bond calculation library is the availability of technical support – both during implementation and on an ongoing basis as issues with specific securities arise that require review and research. In the absence of any support option, the responsibility and onus fall to the firm and technical users of the product within the firm. For most companies, the path to profitability and growth is the focus on their own core competencies and distinctive products in the marketplace – not spending time and resources supporting and researching issues with third-party software libraries.
Defects and Missing Features
Due to the reliance of most open-source products on volunteer labor, the release cycle for fixing bugs and adding new features can be long. Some open source projects will have a mechanism for capturing and addressing these concerns – especially if they use best practices for source code control and project management. But, many thousands of open-source projects languish as once active volunteer developers move on to other newer or more interesting projects. They continue their existence as zombies – not quite dead, but not living and growing. Defects remain unfixed. Enhancements are never finished. Community help is rarely available. This is an awful situation to be in – certainly for a bond calculation library that is fundamentally a mathematics library at the core. There are few things more objectionable than a defective or inaccurate math library. Open source projects must maintain an ongoing recruiting effort to attract new developers and overcome the natural turnover in project participants. Another common challenge shared by many open source projects is the lack of sufficient resources to complete regression and performance testing. Business analysis and QA resources are just as important as development resources for producing software that is reliable, robust, scalable, and defect free. But, open source projects rarely receive the same level of QA and testing that commercial products do. This results in unintended consequences and side-effects such as the introduction of new defects when attempting to fix existing defects or add new functionality. Unless the project is extremely well-coordinated and supported, things will be missed that affect the performance, reliability, and results of commercial products incorporating it.
Security can be a difficult issue with open-source software due to the risk of incorporating malware, planned vulnerabilities, and defects in the product through inadequately reviewed contributions, inadequate engineering practices, or casual attitudes towards review and testing. These risks are not limited to open-source software – commercial software can contain these problems also. However, for commercial software, there is a responsible organization that can be held liable for exploits or vulnerabilities that are transferred to a commercial product by the incorporation of tainted or flawed open source software.
Technical Skills and Development
Which brings up another significant issue… where or to whom do you go to fix something that is broken in an open source library? In most cases, corporate users of specialized vertical market open source software products have only internal developers and resources to depend on when things break. This really defeats the whole purpose of acquiring and using a third-party software product. It is expensive to maintain an in-house resource with expert knowledge of bond mathematics to research, maintain, and fix issues. The expense to hire and maintain these experts exceeds the cost of licensing and support of a commercial product. In the case of maintaining bond calculation code internally, it’s not enough to have good developers on staff – it requires good developers with an expert knowledge of bond calculation math and market conventions.
Design and User Friendliness
Many open source products grow organically over time as new functions and features are added. Commercial products go through the same cycle – with a distinction. Commercial product vendors usually have the incentive and resources to refactor and rebalance the design, update the technical and user documentation, and communicate this to clients. Over time, ignoring these tasks can result in incorrect or missing documentation and confusing or difficult to use class structure. These things can exist in commercial software as well – but usually, these products don’t last long in the commercial market.
Licensing is a business consideration that comes along with open-source software. This is not an issue often considered when using open source software for personal use, but can be a concern or even a liability for corporate use or incorporating into a for-profit software system. There is several different free and open source (FOSS) licensing models with different characteristics. Open source software distributed under the GPL (GNU Public License) family of licenses use ‘copyleft’ licensing which requires that derivative works be distributed under the same terms. Richard Stallman and others that developed this concept wanted assurance that their work would remain free and would benefit the whole world without being assimilated and sold for profit by corporations. Linux is the best example of GPL licensed software. Another popular open-source license – the BSD family of license – is less restrictive, but does require attribution and contains other clauses that may conflict with the software license agreement of a commercial product incorporating the BSD-licensed product. Finally, the MIT and related licenses are popular and permissive licenses that are widely used for products like node.js, jQuery, and the X Windows system. Like other licensing models, it requires incorporation of the license and copyright notices. Due to the varied terms and conditions, corporate legal counsel should undertake a license compatibility review before any free or open source software is incorporated into software intended for commercial use.
Open source has an obvious advantage over commercial software – it has no upfront cost. But, that is not the same as not having a cost – the costs are just hidden and are paid throughout the product lifecycle. They include potential licensing liabilities, security vulnerabilities, lack of development and user support, extended periods of known defects and missing features, increased cost of in-house development and support, and increased time and cost to work with poorly designed or documented products. Taken together, these costs often exceed the costs of commercial licensing.
Commercial products on the other hand – have the profit motive to encourage prompt support for security-specific issues, prompt response to defects and enhancement requests, regression and performance testing and tuning, design and documentation updates, and support for new platforms and languages. Clients of commercial fixed income security analytics library vendors like FTLabs receive these benefits along with expert financial technology consulting advice on integration and usage.
When the time to select a bond calculation component comes around, remember these points and select a reputable commercial vendor for your fixed income bond calculator. FTLabs has been in business since 2005 providing excellent components built for use with Microsoft.NET, C++, Java, and Web Services API under the FISA (Fixed Income Security Analytics) product name.