Guide to Open Source Software for Australian Government Agencies
Risk analysis and risk management
A core requirement in any change management process is to understand and manage risk. Implementation of an ICT solution is a complex change management process that requires careful planning and execution. This is one of the reasons many ICT projects can fail to meet their original business objectives.
Sourcing OSS solutions is a new and less understood area for Government Agencies. As a result, it often seems to involve higher risk. As open source solutions become more mainstream and agencies gain expertise in evaluating and deploying them, this perception of risk should subside.
The process of deploying solutions based on open source software does not necessarily involve a higher or lower level of risk compared with projects based on proprietary software. There is, however, a change in risk profile. This change needs to be well understood and managed by the agency before undertaking any OSS deployment.
Staff responsible for ICT procurement and project implementation within agencies already have experience in deploying proprietary software technologies. To highlight the differences between these traditional projects and open source software, this section reviews some of the risks involved in both types of project. It is intended to help agencies understand the particular areas that may require additional attention when contemplating open source solutions.
Availability of viable competitors
One high-level risk associated with proprietary software technology (particularly software that is only available from a single publisher or supplier) is the financial risk of potentially high termination costs. This risk arises for a number of reasons, but the most important issue is the lack of an alternative supplier for the software in question.
The result is a lock-in scenario where an agency is tied to a particular supplier with little room for negotiation. This stems from the prohibitively high cost of moving away from a particular piece of technology for which there is no functional or interoperable equivalent from an alternative supplier. Such scenarios allow the current vendor to increase future product pricing, support cost structures or other contractual terms. A Guide to ICT Sourcing provides a detailed review of this topic. It suggests that agencies develop a transition/termination strategy during the original procurement process to reduce the risk of future problems for the agency.
While lock-in scenarios are not necessarily eliminated under the open source model, they are easier to avoid. This occurs because of the free redistribution clause of the underlying software licensing. The result is an economic model that encourages competing vendors to enter a particular product space.
No single vendor can obtain a monopoly on the distribution, sale or support of an open source product. Other vendors can adopt a particular software technology for commercial distribution and support if they understand that there is a viable market. As a result, open source products are often available from multiple sources. This provides the possibility of a sideways transition to an alternative vendor that allows the agency to continue using the same open source product. This in turn reduces the costs and risks typically associated with terminating sourcing agreements with proprietary software vendors.
Warranties and indemnities
It is important that purchasers do not overestimate the value of warranties offered with software.
Open source software that is downloaded free generally does not offer warranties for agency users. Purchasers should take care to understand the level of coverage afforded by warranties. Proprietary software warranties normally only offer to use their best efforts to correct defects, or reimburse the software licence fees paid. As OSS products do not require licence fee payments, there is no corresponding offer of reimbursement. Is a matter of judgment whether a particular open source project or a commercial vendor’s best efforts are likely to correct defects in a timely manner.
Where an agency acquires open source software through a vendor, the degree of difference may be even smaller. Vendors in such situations are likely to have the same degree of motivation to correct defects as vendors of proprietary software and the supply in both instances is likely to be covered by similar types of contracts with the agency - for example a GITC contract or other appropriate standard form contract. These contracts typically contain a range of warranties and other contractual protections that apply to all the products and services supplied under the contract. Unless there is agreement to the contrary, these would thus extend to open source software supplied by the vendor under the contract.
Bearing these factors in mind, agencies have a choice of sourcing options.
Agencies may decide, after appropriate due diligence and risk assessment, that the absence of indemnities and warranties is a manageable risk in certain scenarios. If this is the case, the agency can opt to procure an OSS solution through an in-house sourcing process as described in this guide.
However, if an agency deems the risks too high, it should only acquire open source solutions through external service providers. Agencies can stipulate appropriate protection for themselves by ensuring that the vendor has executed an appropriate form of supply contract that covers all products and service provided, including open source products.
In either case it is important for agencies to read and understand all software licences and related legal documents. These provide the necessary context for analysing the risks associated with indemnification and warranties.
Lifecycle of open source products
One area where open source and proprietary software differ substantially is in their development, release and usage lifecycles. This results from the differences in development procedures and licensing between the two. Before making any OSS acquisitions, agencies should understand the process by which OSS products reach functional maturity for production quality deployment.
In general, open source software is released very early in the development cycle and quite often in immature form. These technology previews are intended for technically oriented users or other developers. These groups provide both user feedback and bug fixes to the developer consortium that manages the software product.
Early phase: technology preview
Early-phase OSS products generally have the following attributes:
- A period of rapid change in the technology;
- Testing is available to all, but few have the necessary skills to participate;
- Installation of the software is very complicated;
- New releases may be distributed weekly or more frequently;
- Documentation is minimal;
- There are relatively few users;
- Support is only available via mailing lists; and
- The software is unpolished and lacks many planned features.
In contrast, proprietary software vendors generally do not release software until most of the intended features are in place. They sometimes provide a limited group of testers with ‘beta’ copies of the software for feedback. When finally released, this software is normally far more polished than corresponding OSS products. Proprietary products are almost always distributed with a complete set of documentation and help files.
Middle phase: early adoption
The middle phase marks a period of slower development, wider adoption by mainstream users and the addition of many new features sought by those mainstream users. Many OSS products never reach this phase. Many fall away during the early phase. Users normally begin production usage of open source software in this phase.
Some of the attributes of OSS during this middle phase are:
- A ‘Version 1.0’ release is generally robust;
- The technology becomes increasingly polished, with better manuals and easier (possibly automatic) installation and packaging; and
- Commercial vendors offer production-level support for the product.
This phase can last many years, and can lead to robust and trusted systems.
Maintenance phase: long-term support
When an OSS product has accumulated all the core features its users want, it moves into a mode where the only changes made are to resolve bugs or security faults.
The essential attributes of this phase are:
- Stability and maturity in all aspects of the software;
- Products are trusted as a result of many years of solid performance in their roles;
- Most security and functionality faults have been fixed; and
- The user base drives demand for ongoing support and further development.
OSS applications and products that evolve to the maintenance phase often go on to form the foundation of other OSS projects.
Deciding when to adopt OSS products
Knowing when a particular OSS product is ready for production-grade usage is an important part of any sourcing analysis. Agencies that have appropriate technical
expertise and specific requirements may decide to procure an OSS product earlier in its maturation phase than agencies with limited internal capabilities. The advantage for early adopter agencies is that they may have a better chance of ensuring their functionality and interoperability requirements are introduced into the base OSS product at an earlier stage.
However, adopting OSS products too early may lead to reliance on an immature product or software that is inadequately documented. Either of these scenarios brings additional risks that need to be understood and managed. Trialling OSS products in a long-term pilot project is one suggested mechanism. This approach allows an agency to track (and perhaps influence) the development of the product without taking the risk of deploying immature software in a production role.
Figure 6 offers a model flowchart to help agencies determine when they should consider adoption of OSS products.
Impact of access to source code
Where source code is available, agencies should be aware of the possibility of sourcing products from unauthorised sources. Agencies should only acquire OSS products either directly from a vendor that vouches for the technology or from the primary online repository for a particular product. Many OSS products are also validated with digital signatures to certify that the product was sourced from the originating development group. Agencies should look for such digital signatures to authenticate the product whenever they are downloading the software themselves.
For further detail, see ‘What is source code’, and Appendix B.
Assessing technology risks
The release of a proprietary software product is often accompanied by a significant volume of marketing material such as product data sheets, white papers, brochures and press releases. This material can assist agencies by providing user-friendly information on the functionality and interoperability of the product in question. In addition, industry analysts prepare independent assessments and market intelligence relating to major software releases.
In contrast, OSS software often lacks this technical marketing information. How then can agencies assess that software? How is it possible to gauge fitness for purpose, maturity and interoperability?
This task can be a bit more difficult but need not be impossible. Many popular OSS products have been analysed and positioned in the marketplace by mainstream industry analysts. Analyst reports on these products are available through the usual channels. These reports can give agencies an understanding on the quality and maturity of the software. They also position OSS products within the competitive context of both proprietary and other open source solutions.
CSIRO, the Australian Government research organisation, also conducts analysis in several specific software fields. It produces reports on niche market segments such as the enterprise application server market[3]. Most CSIRO analyses cover open source products and these reports are generally available for agencies.
Sometimes, however, there may be no independent studies on particular open source products of interest to government agencies. In such circumstances, it is still possible for agencies to prepare an informed analysis of the technology risks.
Maturity and fitness for purpose
The first question agencies should ask is whether the software has an established track record. They should also consider how long the product has been available, when it was first released as a production-grade (version 1.0) system and its ongoing development since that release.
If the software has been available for a reasonable time and there appears to be a longstanding community of users, this may support claims that the software performs as advertised.
Take for example an open source database server. In this case, delivering on core functionality would mean:
- Solid performance;
- High levels of interoperability and integration with other system components (application servers, development tools, programming interfaces, etc);
- Extremely high levels of data quality and fidelity;
- High levels of robustness and data availability;
- Solid system recovery facilities; and
- Appropriate data import and export capabilities.
The existence of a sizeable quorum of long-term users generally indicates that the product can be trusted to deliver on such functions. Serious users do not put up with inadequate open source software for long, as there are usually viable alternatives. A low-quality database server quickly gains a poor reputation and users tend to avoid it.
On the other hand, a product may be old but have relatively few users. This is inconclusive evidence of the value of the technology. A small user base may merely reflect the product’s position in a niche market segment. Alternatively, the software may indeed be of poor quality. The 70,000-plus open source packages available are of varying quality.
In cases where the product is solid and meets a market need, open source software can mature rapidly and attain high quality standards in a remarkably short timeframe. However, some project developers and maintainers do a poor job of marketing their product and this can sometimes limit the size of the user base. In such cases, agencies should exercise caution because poor marketing can sometimes cause a project to may falter due to lack of critical mass. Size and momentum are critical success factors for an open source product to ensure it attracts ongoing maintenance and support. These factors are discussed in more detail in the preceding section entitled ‘Lifecycle of open source products’.
Analysis of technology roadmap
A technology roadmap provides users (and other stakeholders) of a software product with information about:
- When new features and improvements are planned;
- When new versions will be released; and
- Strategic positioning of the technology, including interoperability, interfaces and support for standards.
By default, the technology roadmap for a particular OSS product is posted on the project’s website. Sometimes OSS vendors choose to aggregate multiple open source products; in such cases, the vendor usually provides a roadmap that encompasses the aggregate solution as a whole. Roadmap information provides users with an outline of vendor intentions, status of new versions, strategic direction and end-of-life timelines for commercial support.
Roadmaps produced by open source groups differ from those produced by proprietary software vendors. OSS roadmaps focus more on the technical attributes and functional outlines for the forthcoming versions of the product.
In contrast, product roadmaps from proprietary vendors tend to offer more detail about background business objectives. They also emphasise how a particular product will integrate with that vendor’s other products. Proprietary vendors are also more likely to generate roadmaps for overarching platform architecture frameworks and integration methodologies. These are particularly evident if the vendor regards such functions as offering a marketing advantage over rivals.
Agencies are advised to assess architectural frameworks from both open source and proprietary vendors with a critical eye. Many agencies make procurement and strategic decisions based on roadmaps published by vendors, but these often have a limited lifespan and software projects frequently change over time. Agencies should assess a vendor’s past history to determine the efficacy of previous roadmaps and the vendor’s commitment to delivering on a promised vision. For further details on technology roadmaps.
[3] CSIRO Middleware Technology Evaluation Project: www.cmis.csiro.au/adsat/mte.htm [
].
Contact for information on this page: SourceIT@finance.gov.au