We have seen how there are risks associated with code and its manipulation. Institutions are recommended to develop standards and procedures to ensure they acquire code from a trustworthy party. They are also encouraged to check the code for security risks such as malware. These standards should be applied to software updates and patches. There are a number of bodies that can provide assurance on the integrity of code, such as SourceForge and assist in this process, such as the CERT® Coordination Center.
One aspect that sees a great variety in the quality of open source, is the documentation available. It may be less comprehensive than that of proprietary software, or very comprehensive indeed. Minimum standards should be established for documentation and a process dictated for making good any documentary discrepancies.
A degree of contingency planning should be considered, especially for software that has forked and found to be by-passed by the development community. Good practice here is in line with assurances about the longevity of any software and coverage and access to code in the event of a software company failure. Generally software companies don't fail but are absorbed by larger competitors. OSS is not covered in this way.
We have seen how support is also variable but increasingly provided by stable VARs or vendors. Certainly, in evaluating support from the OSS development community, institutions should be astute enough to cover a number of points. They should have enough expertise to be able to spot issues of support in the development community. The shortcomings of a community should be tracked, noted and weighed as part of the assessment. They should contribute to a support group. This can be very productive and enriching since many institutions such as public and government bodies and universities may be members and contributors. Copyright infringement In a litigious world more and more dependent on intellectual capital, copyright is jealously guarded. An institution that uses software runs some form of risk of infringing copyright or patents. While this may normally be low and protected by indemnities, OSS is developed in an open environment where code is shared and modified by numerous bodies and individuals. The appearance of proprietary code in a OSS offering is greater. Institutions should mitigate this risk by exploiting any VAR or vendor arrangement possible over licensing, as discussed earlier. Other prudent methods include: seeking legal counsel to advise the institution on issues, define policies and business rules to ensure licenses are enforced, explore the consequences of combining OSS and proprietary software and exploit existing in-house standards over code development.
A popular and good example of an open source software solution that illustrates a number of the points raised is Linux. Linux is a Unix-like operating system that provides the functionality of Unix across multiple platforms. It is a relatively easy transition for staff with Unix expertise to adopt Linux as an alternative or supplementary platform. It shares the stability of Unix without some of the platform complexities associated with a full Unix implementation. It is an example of open source software much affected by ‘forking', but without any detrimental affect on the market. The varieties of Linux are seen to be complementary rather than competitive and exclusive of each other. SUSE and Red Hat are two well-known versions of Linux that are marketed by vendors. One strength of Linux is the way it can be implemented on relatively simple and low-cost platforms for niche activities and to supplemental existing systems to get the most out of them. Interoperability is also simplified since open source is, by definition, catholic in its lack of preference for a given platform. This is recognised by major vendors and major customers. HSBC, RBS and LloydsTSB and Standard Life have used Linux supplied by Novell. Microsoft have bitten the bullet on open source and seeing the advantages of working with rather than against this trend now distribute certificates for redemption against SUSE Linux Enterprise Server upgrades. For customers who use open source this is seen as beneficial in that it improves interoperability with Microsoft products. For many, the future is not in any form of exclusivity of sources, but in a mixed source computing world.
Linux can be used at the back and front end of business activity; it can host applications for acting as ‘thin' client platforms for users. The use of Linux does vary. For HSBC Linux is primarily used as an operating system (OS) to support servers. Across the industry it is used for online banking to capital market transaction applications. This flexibility casts it in the role of the friendly, always-useful operating system in a fast changing and demanding IT environment. Trading rooms see a wide range of IT solutions. Not surprisingly the ability to run a stripped down and highly functional environment on a Linux platform makes open source very popular. Buying cheap PC-based platforms with a fast and thin open source OS makes this a line of least resistance. In environments where speed matters, open source can have real advantages. The high availability and ease of use makes this a winner. In some instances trading floors have to go the whole way and decide to build integrated systems on open source. Migration at the desktop, as well as back office upgrades, are simplified when open source is involved and the skills are available. As long as support is adequately addressed, the transformation is such that it can often be handled in-house. Although multi-tasking desktops are largely based on Microsoft, once established, open source single-task platforms are feasible, since the costs are low and functionality is good. But adopting open source is still subject to suspicion and concerns. Three frequently expressed concerns have been largely overcome over the last five years:
Support - how do we support the software?
Legal uncertainty - there have been many law suits and disputes about copyright and patent misuse.
Security - how do I know this software is secure?
Support has been addressed by the prevalence of open source solutions from standard vendors. It is claimed that support for Linux in the enterprise is comparable with that of HP-UX, AIX or Solaris, the major Unix brands. Legal uncertainty is perhaps more of a deterrent, since Red Hat Linux has seen some litigation. However, in buying open source from major providers a firm is normally guaranteed against legal issues. Yet, problems of identifying copyright and intellectual property rights, especially for extensions to open source software developed in-house, can be of concern to the riskaverse legal departments of major financial institutions. Policies governing the use of software have to take this into account and so too does risk analysis. When it comes to security, there has been a view that open source software is inherently more secure than many proprietary products, such as Microsoft Windows. Although this is debatable, security is a feature of the way the development of the software is researched and generated. Levels of acceptance, as witnessed in the Actuate report, indicate that there is an increased use of open source by financial sector organisations.
The attraction of downloading and trying out software without any restraints is very strong. Sun Systems' initiative with Java, although not open source, as a freely available product has further primed the market for experimenting in this way. Financial sector companies and firms have a long history of innovating with software to meet their specific needs. This alone is a strong driver for increased interest and use. There is now a body of open source solutions around regulatory compliance that is strengthening this tendency. Given the support proprietary vendors are now giving to the movement, especially for Linux and allied operating systems, this trend is likely to continue for the near future. The risks associated with the use of OSS by financial institutions are fundamentally different from those presented by the use of proprietary or self-developed software. However, this might see the adoption of some distinctive risk management practices with which institutions must be familiar.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Blair C. Murray at 01082010
1. What is benchmarking value
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.