Guide to Open Source Software for Australian Government Agencies
Typical concerns about open source software
Formal procurement of open source software is a new undertaking for many government agencies. As a result, some agencies have concerns about open source software, including licence costs, support options, reliability and maturity. This section addresses these concerns.
Cost of licences
Most open source software does not have associated licence fees. Vendors generate revenue by providing implementation and support services.
Some vendors sell solutions that use a combination of open source and proprietary software sold in a licensed bundle. These solutions are typically priced on a per-seat or per server basis.
Some vendors bundle open source products with service-level support agreements. Agencies interested in procuring such products need to assess the value of this kind of bundling. It may be more cost effective to acquire the underlying product from one vendor then negotiate ongoing service-level support agreements separately using a selective sourcing process. See Appendix B, for further discussion of these issues.
Availability of support
The most frequent question associated with the procurement of open source software centres on support. Specifically, who will support the agency if there is a problem with the software? Agencies need to understand this issue to conduct an appropriate assessment of the risks involved with various sourcing options.
At the base level, all open source software is maintained and supported by a user community. This support is ad hoc and there are no service-level guarantees. However, experience has shown that one or more vendors quickly moves to support a major OSS product if a market is shown to exist.
Support for OSS products is generally offered in a manner similar to proprietary software. Most vendors and resellers offer service-level agreements, on-call helpdesk services and the purchase of support packages. Australia has several hundred small and mid-sized vendors offering support to industry and government under such commercial terms.
OSS products with widespread usage tend to have a broader choice of support services and providers. Popular technologies like Linux, Apache, MySQL and Samba generally enjoy global support coverage from some of the largest vendors in the ICT industry. Support terms for these products are generally similar to the commercial support terms these vendors offer for proprietary software.
In-house support
An agency may opt to in-source the procurement and support of an OSS solution when its in-house technical staff has the necessary skills to deploy and manage the solution on a day-by-day basis. However, for risk mitigation purposes it is important that the agency be aware of any limitations of its in-house resources. The agency may choose to formulate plans to procure expert external support if needed.
It is important to establish contingency plans before permitting the solution to move to the operational (production) phase. Ensuring such plans are in place can reduce the severity and duration of any problems that might arise. In some circumstances, contingency plans may provide the risk mitigation strategy an agency needs to actually proceed with in-house sourcing.
External support providers are available for most widely used open source products. Agencies should conduct a detailed analysis of the viable vendors offering support for products of interest as part of the initial procurement process.
External support
For agencies that opt to outsource the support of an OSS solution, technical support is normally the responsibility of the selected vendor. The vendor should provide first and second-level support. It should also undertake the necessary collaboration and correspondence with the developer community that created the software to ensure resolution of third-level (bug fix) issues. From the agency’s perspective, the entire process should be similar to engaging proprietary software vendors.
Figure 3 shows the strengths and weakness of different support sourcing options.
Maximising flexibility in support options
Open source software offers considerable flexibility in its support options by virtue of its development, release, distribution and licensing regimes. Many popular OSS products have a broad spectrum of support offerings from a range of competing vendors. Each vendor may offer clients support with helpdesk, troubleshooting and bug-fix services.
This multi-point distribution model is a key difference between open source software and traditional software. Flexible support options can give agencies latitude to achieve better value in the procurement of open source solutions.
Software reliability
Another common question about OSS products relates to the issue of quality. Given that most OSS products are available free of licence costs, some agencies question if the software can be considered reliable.
Just as in the proprietary software world, there is an enormous variety of open source software available. The major online repositories list around 70,000 OSS packages. To date, there have been no definitive studies reviewing this software against quality and reliability metrics. It is therefore difficult to make broad statements about the robustness of open source software.
Most open source software fits into particular categories. Some prominent categories are database engines, scripting languages, application servers, content management systems, office suites and desktop groupware. Within any one category, there are sometimes several hundred products available. Many of these products have not yet matured to desirable levels of quality and reliability and are therefore inappropriate for consideration by Australian Government agencies. Other OSS packages are mature, stable, functional and widely used.
Maturity and longevity
The collaborative model used for most open source projects involves a feedback-based development model where maturity and reliability improve as usage increases. During the initial stages of a product’s lifecycle, open source applications can be less robust and less reliable than released versions of proprietary software. Many open source development communities follow a release philosophy known as ‘release early, release often’. Early versions of these products are normally only intended for limited adoption, so agencies should be cautious about considering such products for important functions.
If properly designed and properly managed, open source applications can develop with remarkable speed. OSS projects that meet market demand tend to accrue additional developers, vendors and early-adopter technologists quite quickly. However, poorly designed or managed projects can wither and make little progress over time. Applications without support from a strong developer community are best avoided.
The more successful projects accumulate a growing community of developers and users. In turn, the software codebase, documentation, website, mailing list support and discussion forums develop. This momentum tends to attract additional attention, resources, developers and users to the project.
During a project’s first dozen or so ‘release early, release often’ iterations, the software may be still too immature for production use. However, at this stage it can reach a state where agencies find enough benefit to warrant further investigation. Properly cultivated, this growth phase could enable the software to mature sufficiently to find mainstream acceptance.
In some ways, the success of one open source software product over another mimics the selection process at work in natural evolution. The strongest, most viable projects accumulate the scarce resources (early adopters, developers, testers) that allow development to further accelerate towards maturity. This in turn attracts additional users, which accelerates the maturation process further.
Users and developers generally benefit from selecting a strong competitor, as this has the greatest chance to become a viable platform with a large user community. This significantly increases the likelihood of product longevity.
This factor has particular importance for government agencies. Selecting a product that may struggle to evolve to maturity involves serious risks. It is therefore important to undertake an analysis of the open source product to determine its current level of maturity and success. Not all OSS products need to be the top of the evolutionary ladder to be viable for selection. However, selecting a product with strong support from developers and users can reduce risk.
In most OSS technology categories, there is generally more than one strong competitor. This is particularly likely in categories that can be broken down into different ecosystems or niches. A computer operating system is the best example: its usage is so diverse that different OSS projects can succeed simultaneously by targeting a specific scale (mobile devices, desktop systems, servers) or a particular technology model (distributed computing, grid computing, monolithic servers).
Another example is SQL database engines, where there are at least a dozen viable open source projects. Many of these projects target specific niches such as embedded devices or enterprise back-end servers. The market also has sufficient size and breadth to support numerous SQL database engines. Within a particular niche, each product may have different strengths and weaknesses, so agencies should evaluate any potential products carefully.
Contact for information on this page: SourceIT@finance.gov.au