Home >> Publications >> ICT Procurement >> Guide to Open Source Software for Australian Government Agencies >> Sourcing open source software

Guide to Open Source Software for Australian Government Agencies

Sourcing open source software

For most agencies, procurement of open source software is a new endeavour. This means many agencies will approach OSS cautiously. Under most circumstances, however, there is little reason to handle OSS procurement differently to proprietary software. Where differences arise, this guide highlights them and outlines their relationship with the existing procurement framework set out in A Guide to ICT Sourcing. Most of these differences are easily defined and managed.

Sourcing scenarios

There are four principal avenues for the introduction of open source software within government. These mirror equivalent procurement processes that exist for proprietary software, with one addition. These avenues are:

• In-house sourcing: direct procurement of open source software, using in-house skills for sourcing and deployment;
• External sourcing: using one or more external solution providers to deliver and deploy OSS-based solutions;
• Incidental sourcing: deploying open source software as part of a larger sourcing solution, where the open source component is not the primary emphasis; and
• Custom software development: the government agency develops or modifies open source software by itself.

These options are comparable to processes that most agencies already use. For example, many agencies already source ICT solutions through external service providers using either single-source or multiple-source arrangements. Most OSS platforms can be procured in the same way. In-house development using OSS technologies is analogous to customised development initiatives that some agencies currently undertake and the process can be managed similarly. In contrast, direct sourcing is a new option that has no common equivalent in the proprietary software context. Many agencies find it more convenient to source OSS solutions directly using in-house technical expertise. Direct, in-house sourcing is not generally available as an option with proprietary software, which must normally be acquired from the vendor or an authorised distributor or reseller.

Let’s consider these options in greater detail.

In-house sourcing

If an agency has the requisite skills in-house and flexible software procurement policies, it can obtain, install and use a substantial number of OSS products that are directly available from various online repositories. Browsing or searching these repositories allows agencies to find and download OSS products to meet their needs. Appendix A, “Open source software resources”, lists many of these OSS repositories.

Such ad hoc software procurement is not normally available for proprietary software as this type of software is generally not available for free download. Where proprietary software is available for free download, there are often restrictions on its functionality or the duration of its use.

Direct in-house sourcing enables agencies to bypass formal procurement processes, purchase orders and expense requisitions; the principal costs relate to bandwidth usage and staff time. However, agencies still need to follow the standard risk assessment and change management procedures required by each agency’s policy. All directly sourced OSS products should be downloaded, installed and tested by appropriately skilled technical staff before their use is approved.

Figure 4 sets out a model workflow for in-house sourcing of OSS products.

In-house procurement checklist

When undertaking in-house sourcing of open source software, there are a number of broad considerations for agencies to investigate before proceeding with software selection. If a specific open source product appears to meet an agency’s requirements and that agency decides to undertake a more detailed review, the following checklist provides a useful analytical tool to guide the assessment process.

External sourcing

Many agencies may not have the in-house technical capabilities to source OSS products directly. As a result, they may prefer to acquire open source solutions through external service providers.

Most popular open source products can be procured via commercial solution providers. These range from large established vendors through to small-to-medium enterprises offering tailored solutions. However, there is normally a subtle difference between external acquisition of OSS and proprietary software. When an agency acquires an OSS-based solution through an external service provider, it is generally purchasing services and receiving the related software free. This differs from the proprietary model where the agency purchases software licences and receives support as a value-added service.

This difference is potentially confusing for agencies who have become familiar with the existing regime for proprietary software. It is perhaps the core difference between the two forms of software from a procurement perspective, so it is worth taking the time to understand what this difference means.

The first implication is that it is possible to acquire a solution built on open source software from a vendor that is not the originator or creator of the software. However, this vendor usually has the wherewithal to offer the solution as if it were its own. This differs markedly from traditional arrangements where various authorised resellers provide the same proprietary product from one software publisher but face limitations in the way they can support, modify, extend or maintain the product. Agencies often need to acquire these after-market services directly from the software publisher.

In contrast, any particular OSS product may have multiple software publishers that sell essentially the same product through multiple resellers. Each open source vendor should be able to offer the full spectrum of pre-sales and post-sales technical services on that product.

This arrangement has obvious repercussions for risk assessment. While no single software publisher or reseller can claim total ownership of a product (due to the open source licence conditions), each product has multiple independent development and procurement systems to support it. Therefore access to the product is secure and agencies have a strong bargaining position. Vendors and resellers must demonstrate their ability to fulfil the service and support requirements that client agency requires.

Figure 5 shows some of the typical reseller arrangements that can arise with OSS products.

Once an agency has decided that an OSS technology solution fits its needs, the next step is to select an appropriate vendor to undertake implementation and ongoing support of that product. A Guide to ICT Sourcing lists the key criteria by which a vendor can be selected from a group of possible contenders. As part of vendor due diligence, agencies should evaluate the financial strength, stability and technical capability of the shortlisted vendors. In essence, the same due diligence rules apply for vendors and resellers offering either OSS or proprietary software solutions.

In addition, the availability of multiple vendors for any given OSS product reduces the risk of an agency finding itself left with an orphaned product selection. This multiple source attribute offers additional flexibility to agencies mapping out transition strategies for moving from one supplier to another at the end of an agreement.

Open source products and single sourcing agreements

As more open source technology is used in the ICT industry, existing service providers working in the government arena may introduce OSS solutions into client agency environments. This may take place as part of the mix of software used by a single source service provider to fulfil its service level agreements with the client agency. Alternatively, OSS may be deployed as part of a new technical methodology or approach that the service provider may adopt.

In such cases, the vendor and the client agency need to address all matters relating to the proper operation, warranties and indemnities associated with this new software within the existing contractual framework. These contractual issues should be resolved in accordance with the standard contracts and Financial Management and Accountability Act (FMA) and Regulations. See ‘Meeting Australian Government requirements’.

Incidental sourcing

Historically, adoption of open source software within organisations has generally occurred on an ad hoc basis. Often OSS products were used as an incidental part of larger ICT projects. This happened for several reasons. Firstly, most open source software is easily available: it can be downloaded directly with no licence costs or other upfront fees. Many OSS tools are also platform-neutral and designed to be modular in order to increase their usefulness and applicability. These attributes make OSS tools easy to download and deploy for specific functions within larger projects.

Typical ad hoc deployment scenarios include:

• Web-based content management systems for in-house use;
• Edge-of-network infrastructure components;
• Perimeter defence and firewall systems; and
• Specialist technological or scientific uses.

Within government, OSS was often adopted by agencies that had in-house technical expertise. Technical staff were able to research open source software options then download, install and trial the product.

On the other hand, many agencies were not in a position to adopt this type of process, often because they lacked sufficient in-house technical expertise. However, the open source market is maturing quickly and there is now a broad spectrum of vendors offering OSSbased solutions, products and services that enable these agencies to contemplate open source solutions through external sourcing arrangements similar to those used for other technology products.

Custom software development

In-house development using OSS technologies is analogous to customised development initiatives that some agencies currently undertake and the process can be managed similarly. However, there is a significant difference between custom development with OSS tools and customisation of proprietary software. The most important differences relate to the potential to redistribute the OSS-based solution and the rights and obligations imposed on an OSS user with respect to the release of source code for any custom modifications.

Licensing issues are discussed in detail in the chapter on ‘Understanding the legal context’. Redistribution issues are covered in the chapter on ‘Sharing OSS solutions’.

Contact for information on this page: SourceIT@finance.gov.au

Back to top