|
A question frequently raised is on the maturity of the product - how long has it been in use? This is really a way of asking, how do I know I can rely on this product? Based on experience, a new piece of software is more likely to have bugs, prone to a rapid series of updates to amend detected bugs and likely to have weaknesses which may not have been detected, even by the vendor, when operating in certain environments or at certain loading. Any or all of these factors can reduce confidence in the product and be detrimental to a firm's business activity. Given that the software might be part of mission-critical activities the risks here are considerable. For most vendors questions of maturity are fairly easy to address. Generally the software packaged for universal consumption has had a life as a bespoke product and evolved into a form that is deemed saleable in a wider market. It will be on an advanced version with clearly defined and well-known capabilities. However, the nature and economics of developing open source software is different. Questions on support in use are natural, but there are others that should be asked, more specific to open source.
All open source software is associated with a development community. This is very different for a single product developer. Whilst the developers of the code may be as professional as commercial coders, their binding interest is not monetary, and the drivers are not purely those of market demand. Their interests tend to be driven by curiosity and creative impulses. The degree of organisation and mutual cooperation within the community is open to question, as is their longer-term commitment.So we need to know more about the organisation or organisations behind the code. Along with a list of questions we need indications of where the answers might be found, as in For most open source groups, the communities are large and contain a high proportion of experienced coders with formal academic and business experience. The tendency is to control and manage development according to well-tried systems. A disparate community needs such discipline to produce something durable and worthwhile. It might be the case that the degree of change control and overall discipline in code development is stronger than some commercial software houses, which do have the same level of enthusiasm and have to respond quickly to commercial demands.
These commercial drivers might not be suited to the realities of a truly bug-free and ideal code. Very often, development is seen as a project exercise with well-defined project leaders or managers overseeing the community. There is also a real interest in using and adapting code developed by commercial vendors, where possible, to incorporate the best of the best into the final released product. A principle at work for most of these communities is that the product is a living thing, and since it is not dependent on commercial sales, it is unlikely to die as a product set. The creative impulse is a strong one and should not be underestimated. A feature of open source software is that it offers coders an opportunity to take a copy of the code and manipulate it so that they produce a piece of software that can be operationally distinct from the original.
Normally, access to source code is difficult and it is protected under copyright. This activity is not legally possible without the originator's permission. Open source recognises no such constraint. This process of transforming source code is known as ‘forking'. From our perspective this is not an issue unless a major fork occurs, when the development community sees a group take the code in a very specific direction not mutually sanctioned. This can lead to internal disputes and should be addressed by curtailing further development on the forked code as a ‘standard'version. Forks can present unexpected and unwelcome changes of direction in code for a firm or institution that has adopted and used the original. For this and other related reasons, the firm should ensure it has enough expertise in-house to manage any such change in circumstances. A mitigating factor that can make a difference here is that once committed to using open source software, the firm becomes part of the community and contributes to it.
This means, unlike with most commercial software, the firm can have a direct influence on the direction of the code. While, to an extent, commercial vendors allow customers to influence their product road-maps, the user is a licensee and not a stakeholder in the open source project. However, licenses, although often quite thoroughly specified, do not contain any warranty or indemnification clauses. The Open Source Initiative lists a number of common licenses that can be used in the acquisition process. Sometimes these are supplied by the intellectual owner, sometimes they are negotiated.
The OSI has a License Review Process to ensure that licenses and software labelled as open source conforms to existing community norms and expectations. The review process is public. The process has a specific remit, to: ensure approved licenses conform to the Open Source Definition, help identify appropriate License Proliferation Category, discourage vanity and duplicative licenses, ensure a thorough, transparent and timely review, generally within 60 days and provide the current status of license review requests. The OSI Board offers to help with the formulation of licenses before the formal review. The OSI Open Source addresses the sometimes vexed issue of license proliferation. Its response is a guideline based on a tiered approach; it places approved licenses into a list of recommendations such as:
1. Preferred,
2. Recommended but not preferred and
3. Not recommended.
These licenses have been approved but reflect the OSI's own standards for OSS. There is a license frequently referenced, the General Public License (GPL). Under this license anyone can use the software and change the program code, but the new code cannot be redistributed as a proprietary application. Another well-known license is the Berkley Software Distribution license (BSD). It has similar clauses but with restrictions, such as a copyright notice and a disclaimer which must be included. However, the BSD license does allow products created using BSD-licensed code to be used in proprietary software. The structure and financial terms of many licensees include a base and a per-user license. This enables the number of users to be tracked against the licensed number to ensure additional licenses are taken out as the use of the software grows. OSS does not require license by user. But Value Added Resellers (VARs) of OSS might introduce a limitation on the number of servers accommodated by the license.
These aspects of licensing will be scrutinised as part of the diligence process in procurement; it is especially important to determine the nature of licensing if an OSS is supplied as part of a bigger, integrated solution using proprietary software. Very often the use of the code constitutes a readiness to recognise and abide by the OSS license, and an integrators general terms and conditions might or might not override these. Financial institutions and firms should consider these licensing arrangements under legal advice. The organisation will be used to buying software that has a warranty and an indemnity.
This level of security is absent from OSS. Open source is licensed without warranty or indemnity. However, as open source has been taken up by VARs and vendors, licenses have appeared which add these qualities, often extending them under the umbrella of proprietary software. Other vendors provide dual licensing - based on a BSD or GPL license. One is usually some form of the GPL, and the other might include performance warranties and indemnities. Firms should evaluate any indemnification offered by a VAR. It might be wise to consider third-party insurance as well. Operational risks Operational risks exist within any IT operating environment. A good source for risks, controls and prudent risk management practices are the FFIEC IT Examination Handbook issued by the Federal Financial Institutions Examination Council (FFIEC). The Council was established in 1979, to prescribe principles, standards and report forms for the federal examination of financial institutions.
It was established by the Board of Governors of the Federal Reserve System in the United States. Some of the key operational risk considerations linked to using OSS include the integrity of source code, the management of documentation, contingency planning and product and software support.