Consultation: Guide to Open Source Software

Author: 
Glenn Archer - AGIMO
Category: 
The Department of Finance Archive

The content on this page and other Finance archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.

 

In January 2011, the Australian Government released its policy on open source software. Agencies are now required to consider open source software for all software procurements. Details on this revised policy are available on the Finance website. To complement the Open Source Software Policy, we've also updated the Guide to Open Source Software for Australian Government Agencies. The original version was released in 2005. We've updated this Guide to bring it in line with the increased maturity of open source software, as well as the recent shift in the Australian Government's policy on open source software.

We're looking for public input on the draft Guide to Open Source Software. All comments are welcome by either responding to this post or emailing comments to aga@finance.gov.au. The closing date for comments is Friday 15 April 2011. I look forward to your feedback. Glenn Archer First Assistant Secretary, Policy and Planning

Comments (7)

The main thing I see missing is a good description of how it actually affects the procurement process, particularly in situations where the market typically offers off-the-shelf products (e.g. WCMS). By this I mean, how to manage situations where you are comparing open source vs commercial products, how to compare the same open source product offered by different vendors. I realise the detail is there, but I don't think it addresses the process itself.

One of the biggest changes open source (and Web 2.0) has created in the software market is the ability to learn about and try a particular software package/framework before making a commitment to it. How is/should this be addressed in these guidelines?

I would also like to see some advice on the benefits of contributing back to the open source community, along with some views on the impact of factoring this into the TCO.

The Software Licensing Risk Framework has a lot of conceptual knowledge - it would be good to have some concrete examples (good and bad), just to help put the risks into perspective.

It is a credit to AGIMO for preparing this useful, unbiased description of how to make use of Open Source Software.

The European Union have released a similar document, "Guideline for Public administrations on Procurement and Open Source Software", which can be found here: http://www.osor.eu/studies/expert-guidance/guideline-for-public-administrations-on-procurement-and-open-source-software-2010. This EU guide does a better job of explaining the drivers behind purchasing decisions, and I suggest providing similar text in the AU guide.

Government Purchasing Drivers

For instance, the EU guide explains that government purchasing drivers are for "transparency, sustainability, cost effectiveness".

Standards

The EU guide explains the importance of standards, and reasons why:

"...Supporting technologies without considering their degree of openness and their ability to foster a fully competitive market is harmful to competition and net social and economic welfare. It is thus expensive, by definition, over the long term."

"... public agencies should encourage [Open Standards] development, and indicate their preference for open standards to vendors though preferential procurement of software based on open standards wherever it is available."

Exit Costs

The EU guide does a much better job describing what exit costs are, which will help purchasers recognise when they are introducing exit costs into a purchasing decision:

"The exit cost is also an important consideration: the cost incurred in migrating to another IT system, which should properly be accounted for as a cost not of the new system being migrated to, but the old system being migrated from. After all, if the old system were based on open standards, migration would not be as expensive, thus the cost of migration is imposed by the current, old system."

...

"Software is used to create documents, databases and customised applications that, in the public sector, have a life-time that may be well beyond the originally announced life-time of the procurement procedure for the software. If the software originally purchased makes it difficult to use the documents, databanks and customised applications with similar software from other producers, then there is a high cost in terms of changing from the original software to another software - the exit cost."

...

"Buying new software because it is compatible with previously purchased software may seem to save on migration and training costs. But when this software is proprietary, and is not fully based on protocols and standards that are fully and freely supported by other independent vendors, exit costs and associated costs may greatly increase over the long term. The agency's dependence on the proprietary vendor is increased. Thus the apparent short term benefit of compatibility is much reduced when considered over the longer term."

Smaller companies can support Open Source

I suggest also following the EU guide re selecting the financial viability of a company supporting Open Source.

"The main justification for financial sustainability criteria for software [companies] is to ensure that the supplier will be able to provide support as long as the software is being used.
With open source, the availability of the source code assures interoperability, and there is no dependence on the original supplier. If the original supplier goes out of business, the software can still be maintained by others; if others are not maintaining the software, the public agency can hire a third party maintainer. This increased sustainability of open source is justification for lowering the financial sustainability requirements, or lowering their weight in the selection process for tenders for open source software."

The policy is good. But it is a shame AGIMO used Microsoft® Office Word 2007 to create the document in PDF format. Would have been a nice touch to to use open source software to create the document and then distribute as an easy to read Web page.

Also it would have been good to release the document under a creative commons licence in accordance with Australian Government policy. As it is there is no licence stated in the document and so presumably commonwealth copyright applies, prohibiting free use of the document.

It would also be good if AGIMO could use web addresses of less than 75 characters for their documents, so they can be easily used.

swallace said April 11, 2011 at 4:48 pm:

>Hi Tom ... Guide to Open Source Software will be released under a Creative Commons license ...

Okay.

>... easier for people to mark up a .doc or a .rtf version rather than a HTML document.

I suggest just providing a HTML document, as that is easier for everyone than making multiple versions.

It should be easier for people to copy and paste bits of the HTML version into a HTML based forum (like this one) than fiddling around with .DOC files.

If people want to, they could still open the HTML document in MS-Word, mark it up with comments and send it to you, just as they can with an .DOC file.

My other reason for suggesting starting with HTML is that way you are more likely to end up with good HTML. Otherwise the tendency is to format the document for printing and then only later when you are under pressure to release the final, to discover that it is not well formatted. I spend a lot of my time disassembling and reassembling poorly formatted government documents (but admittedly AGIMO ones are better than most).

Some comments on the three core principles - terminology issue.

Principle 1 is a mandatory requirement imposed on agencies with respect to government ICT procurement and not a principle.

Principle 2 appears to be a mandatory requirement imposed on suppliers. That is... "Suppliers must consider all types of available software when dealing with Australian Government agencies." Actually it is a mandatory requirement imposed on agencies who will indirectly require suppliers to comply. Not a principle.

Principle 3 appears to be a statement of intent by the Government through intended actions by AGIMO. Not really a principle.

This is a good start, but "consider" is a low bar, and there are still many barriers inhibiting the adoption of FOSS software. Most of these barriers are quite reasonable from an agency perspective. You only need to trip on one.

From personal experience, just the costs of testing, QA and integration that are usually paid to external providers. Perhaps we need a .gov.au App Store so we can share the cost of this diligence?

Thank you for your input -- comments on this post are now closed. Please contact aga@finance.gov.au if you have any further feedback.

Last updated: 29 July 2016