Home >> Publications >> ICT Procurement >> Guide to Open Source Software for Australian Government Agencies >> Appendix B: More about open source software

Guide to Open Source Software for Australian Government Agencies

Appendix B: More about open source software

Open source software or free software?

The name ‘open source’ as a label for a particular class of software has only existed in common usage for a few years. Before this time, such software was generally labelled ‘free software’.

In generic terms, free software denotes software that can be acquired without financial remittance. However the technologists who coined the term free software had a very specific intention in mind. The purveyors of free software, led by an organisation called the Free Software Foundation[11], outline the following attributes for free software programs:

• Freedom to run the program for any purpose
• Freedom to study how the program works and adapt it to a user’s own needs, thus the source must be provided;
• Freedom to redistribute copies of the software; and
• Freedom to improve the program and release improvements to the public, so that the whole community benefits from the distribution of source code.

Source: www.fsf.org/philosophy/free-sw.html []

The term ‘open source’ was introduced because the term free software was seen as overlapping too broadly with the freeware/shareware class of software. While freeware and shareware are free to download, free to redistribute and sometimes free to use, they are not supplied with the source code nor the freedom to modify or improve such source code.

Open source business models

One common question about open source software relates to the rationale for its development and publication. Some people do not see why the individuals and vendors who choose to build and maintain complex software do not charge licence fees.

This question is particularly relevant in situations where an agency is trying to determine the long-term viability of a product. Open source software that is devised for short-term reasons and without a sustainable business or community-participation model may not continue to be maintained. Agencies should seek to identify any such software and include this as a part of their risk analysis.

There is no single response to the question of why people contribute to OSS projects. Reasons for contributions to OSS projects may include:

• Deriving non-financial rewards from writing highly functional and well-crafted software;
• Making money from helping customers implement the software;
• Releasing open source software as part of a larger strategic decision to benefit from the OSS distribution model and the growing market for such software. This may sacrifice potential licence fees for the opportunity of gaining revenue through support contracts, consulting services or training;
• Making products that were previously proprietary available as open source. In such cases, the vendor may consider this move to be good corporate responsibility, to ensure its customers are not left with orphaned technology;
• Reducing the market space available for a competitor’s product; and
• Leveraging the competitive research and development costs of open source software to lower the cost of a bundled solution;

A number of open source software vendors release products under both an open source licence and a proprietary licence. This approach can work well in situations such as subcomponents or libraries. Releasing software under an appropriate open source licence increases the likelihood of broad adoption without expensive marketing. In such situations, other developers may want to build proprietary technology using the library. They generally need to opt for the version licensed on proprietary terms. Such terms generally include a royalty component, which is part of the original vendor’s revenue model.

Source code access: implications for agencies

One of the most marked differences between OSS and proprietary software is that the end user has access to the programming source code that makes the software function. With proprietary software, this source code is normally not available to the user.

In many circumstances, OSS licences (such as the GNU General Public Library) require software developers or product vendors to furnish the client with information about exactly where they can find and retrieve the software source code for any OSS products they supply. Usually this source code is available from an online software repository or sometimes on physical installation media (CD-ROM, DVD-ROM).

For most end users access to source code has little practical impact. End users running an OSS package utilise the software in its machine-readable binary code form, rather than in its human-readable source code form. This situation is exactly the same for both OSS and proprietary software tools.

Nevertheless, access to source code provides a number of benefits for any potential user of OSS. For example, open access to source code means it is usually possible to acquire the same OSS solution from more than one independent software vendor (ISV). It is also possible to receive implementation and maintenance support (including programmatic problem resolution services such as bug fixes, security fixes and service packs) from more than one supplier. Some suppliers may even support competitive product lines.

These attributes are particularly valuable during end-of-contract negotiations with suppliers. They typically offer government agencies additional flexibility in such negotiations. For more information on termination strategy, see ‘Phase II: Decide Sourcing Strategy’ in A Guide to ICT Sourcing.

Assured access to source code also minimises the likelihood that an agency may end up using obsolete or discontinued software, as the source code allows another vendor or even the agency itself to continue maintaining a software platform. In addition, source code access reduces the potential for vendor lock-in, where an agency has no choice but to continue procuring its ICT solutions through a particular supplier. Such situations significantly reduce the agency’s bargaining power and can lead to higher ICT costs.

Open source, open standards and open systems

Three common ICT terms – ‘open source’, ‘open standards’ and ‘open systems’ – are often used interchangeably. However, each term represents quite a different concept, although on some occasions they do overlap. It is important for agencies to differentiate between these ideas when sourcing ICT solutions.

Open source

Open source software is a type of computer software defined by several specific attributes that relate to its licensing and legal framework. Often it also involves a distinctive development and distribution model.

At present, the primary arbiter of what constitutes open source software is the Open Source Initiative[12]. This Initiative sets out various rights and obligations for developers, distributors and users of OSS. These rules define the basic licence conditions under which software must be released to be considered open source.

These licence conditions give the users of OSS the right to:

• Use the software for any purpose;
• Make copies of the software for any purpose;
• Access or modify the source code of the software for any purpose; and
• Without payment of a royalty or other fee, distribute copies of:
  - the software (including distributing the software as part of an aggregate distribution containing software from several different sources);
  - a derived or modified form of the software (either in compiled form or as source code), under the same terms as the licence applying to the software.

Source: www.opensource.org/docs/definition.php []

Open standards

An open standard is a detailed, descriptive overview of a process, protocol or format. It is formulated through stakeholder consensus. It must be openly published and there should also be no legal or intellectual property restrictions.

Open standards are generally defined by focus groups within standards organisations. The most important standards bodies within the ICT industry include:

• American National Standards Institute (ANSI);
• European Computer Manufacturers Association (ECMA);
• Institute of Electrical and Electronic Engineers (IEEE);
• Internet Engineering Taskforce (IETF);
• International Standards Organisation (ISO);
• Open Group; and
• World Wide Web Consortium (W3C).

In addition, many specific fields within ICT have their own industry standards.

Open standards are not unique to the ICT industry. Many standards are defined and certified by bodies such as Standards Australia. Standards benefit industries because they encourage market growth by allaying customer fears about interoperability. They also ensure that competitive economic pressures exist within given markets, producing price benefits for consumers.

Open standards are increasingly important for ensuring interoperability among competing vendors. It is therefore good practice for agencies to analyse and understand which open standards may be applicable to specific ICT solutions. Products that comply with open standards are easier to integrate into environments designed to use the same standards. Open standards also make it easier for an agency to terminate its relationship with one vendor (or product) and adopt another, hence reducing the risk of vendor lock-in or product lock-in.

Establishing a vendor or product’s compliance with open standards often forms part of an agency’s risk assessment and due diligence process. It could also form part of the decision matrix used when identifying prime ICT sourcing options, whether open source or not.

Open source software is largely – but not necessarily – based on applicable open standards. However, agencies or their ICT suppliers should conduct technical analysis to determine whether any given open source product complies with relevant open standards.

As a general rule, demonstrated compliance with open standards should be required when an OSS product needs to:

• Transfer data or documents to/from other applications;
• Store data or documents; and
• Interoperate with external applications via networks or other interfaces.

Industry standards and proprietary standards

Some standards do not strictly qualify as open standards but operate as de facto industry standards owing to widespread usage or broad industry support. The .DOC format of the Microsoft Word word-processing application is a well-known example. Some de facto standards are openly available to all vendors (industry standards) while others are only available under licence from the originating vendor (proprietary standards).

In general, industry standards and proprietary standards differ from open standards in a number of ways:

• Detailed technical specifications for document formats, data formats and communications protocols may not be clearly or openly defined;
• Other industry stakeholders (vendors, users) have minimal influence over the standards; and
• Originating vendors may introduce barriers (software patents or related intellectual property claims) to ensure that competitors are legally encumbered or locked out of the market.

Economic impact of open standards

The overlap between open source and open standards is generally stronger than the overlap between proprietary software and open standards.

Proprietary software vendors do not always adopt open standards for communications, data or document format protocols. By avoiding open standards, the vendor can make the process of switching to alternatives more difficult. To move to an alternative provider, an agency must cover the cost of data and document migration, interoperability testing and re-training.

This is a standard lock-in scenario. In the formulation of vendor termination strategies, agencies should take this cost into account as part of the overall true cost of that ICT purchase.

Open standards can lead to the commoditisation of a particular technology. In such cases, vendors may experience reduced profit margins compared to transactions with clients that use proprietary products. Open standards tend to open competition and accelerate progress within a market segment due to additional competition.

An example of commoditisation can be seen in the personal computer (PC) hardware industry. Over the past decade, PC prices have fallen by 90% in real terms[13]. Over the same period, there was a 100-fold increase in PC power, features and capacity[14]. This price/performance boost came about due to intense price and feature competition among PC vendors and increased economies of scale brought about by standardisation of components. Such competition reflects greater use of open standards and industry standards in PC hardware, allowing all vendors to compete on equal terms.

Government agencies can use such models to identify ICT product segments where standards-based competition is evident. These segments may offer higher levels of product interoperability and greater choice in component procurement, leading to more competitive pricing. This in turn reduces system interoperability risks for the agency.

Open systems

In its formative years, the ICT industry was far less open. There were few mutually agreed standards. Many products lacked any facilities for data transfer or document interchange. Communication between products from disparate vendors was usually impossible because network protocols were all proprietary. As a consequence, users suffered from unnecessarily high prices.

The situation started to change in the 1980s. Computer users recognised that this lack of interoperability came at a cost for their organisations in terms of lost functionality, lost opportunities and maintaining disparate silos of technology. Users began to exert pressure on vendors to create open protocols for data, documents and networking. The aim was to improve interoperability between systems from different vendors.

At the same time, there was a push to encourage vendors to adopt standards-based programming languages and standards-based application programming interfaces (APIs) at the operating system level. The result was increased adoption of open standards. One example was the way operating system vendors embraced the Portable Operating System Interface (POSIX) standard, later known as IEEE 1003.1. POSIX was exemplified by the Unix operating system platform.

Many large organisations, government agencies and research establishments moved their core computing functions onto platforms that complied with these standards. This encouraged more vendors to embrace the same standards. These vendors produced POSIX-compatible systems interconnected on TCP/IP networks. Collectively such technologies were known as ‘open systems’.

The move to open systems encouraged increased competition in the ICT industry. Functionality and the value of computer technology improved, although there were continued impediments to price competition and interoperability. The main problems arose when vendors began to deviate from agreed POSIX specifications. Many created API extensions that were only available on their platform, resulting in increasing platform divergence and incompatible proprietary implementations of Unix. Vendors began using API differentiation as a marketing advantage to encourage users to select their platform over those of their competitors’. Independent software vendors (ISVs) also started to write software enhancements that were unique to specific platforms. This diminished interoperability between so-called open systems platforms.

Part of the original vision of open systems was the ability for a customer to switch from vendor to vendor easily and cost-effectively. However, while the open systems movement achieved significant advances, it never fully delivered the level of user control it originally promised.

One of the repercussions of this sequence of events was the growth of open source software. This came about because open systems failed to deliver a totally open, interoperable universal platform that offered a level playing field. Another factor was the history the Unix operating system. Originally developed by research and education institutions as a platform to train computer scientists, over time Unix moved from an open and freely accessible codebase to one closed off from computer science researchers and programmers.

The General Public Licence (GPL), the most prominent open source licence in use today, was devised as a way to prevent the future closure of product codebases. One impact of the GPL is that it removes the possibility of proprietary extensions to a codebase. Any extensions by one vendor must be legally made available for other vendors to adopt and resell.

While it is not impossible to convert a GPL-licensed product into a non-interoperable version, there is no financial gain for the vendor in doing so. The GPL licence removes the incentive to use product differentiation for financial gain by requiring that any differentiated code must be made available back to the open source community. As a result, vendors need to use quality of service and support to differentiate their value to customers.

[11] Free Software Foundation: www.fsf.org [].

[12] Open Source Initiative: www.opensource.org [].

[13] Based on analysis comparing advertising in Australian Personal Computer magazine from December 1993 and December 2004.

[14] Based on analysis comparing advertising in Australian Personal Computer magazine from December 1993 and December 2004.

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

Back to top