Views Sought on Annual Review of the Common Operating Environment Policy

John Sheridan - FAS Technology & Procurement

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.

Comments on this post are now closed, thank you to those that provided feedback.  Please let us know if you would like to discuss this post further

Over the past several months the Common Operating Environment (COE) Review Working Group, consisting of representatives from Financial Management and Accountability Act 1997 (FMA Act) Agencies, has undertaken a comprehensive review of the Whole of Government (WofG) COE Policy and accompanying Standard Operating Environment (SOE) Build Guidelines for Windows. Draft versions of both documents showing the proposed changes are available here:

The specific Group Policy configurations detailed within the annexes to the SOE Build Guidelines, are still under review by the Working Group. This review has focussed, in part, on a number of specific issues related to refining and clarifying the intent of the standards set out in the WofG COE Policy. In particular, I would like to highlight that further consideration has been given to the common document format to be supported by office productivity suites in use by Government agencies. The new draft now requires that office productivity suites must provide support for at least version 1.1 of the Open Document Format for Office Applications (ODF) as defined by ISO/IEC 26300:2006/Amd 1:2012. The related standard within the WofG COE Policy has been revised as follows:

Standard Effect
The office productivity suite must support at least version 1.1 of the Open Document Format for Office Applications (ODF) as defined by ISO/IEC 26300:2006/Amd 1:2012. Office productivity suites provide support for a common file format to facilitate the exchange of information between agencies. This does not preclude the use of other file formats.

In evaluating the adoption of ODF as the preferred supported format, consideration was given to a number of factors:

  • The adoption of ODF as the preferred supported format is consistent with a guiding principle of the WofG COE Policy, namely, that the COE will be based on common standards and, where practical, these will be based on open standards.
  • Support for ODF is available from a wide range of office productivity suites across a variety of operating system platforms, in both open-source and proprietary implementations, allowing agencies a great deal of flexibility in selecting a product which conforms to the COE Policy standard.
  • Standardising on a format supported by a wide range of office suites provides for the greatest possible degree of interoperability without mandating the use of a specific product, as well as providing the best basis for reliable interchange of information between agencies deploying differing office productivity suites.
  • While the majority of agencies currently deploy a version of Microsoft Office, this does not limit the adoption of ODF as the commonly supported format, as Microsoft Office provides native support for ODF in versions later than Office 2007 SP2.
  • Support for a format based on an open standard ensures the long-term availability of the data contained in documents produced while eliminating the potential for a vendor ending support for a specific format.
  • ODF is continuously developed and updated, with the latest version (1.2) including additional accessibility features, RDF-based metadata, a spreadsheet formula specification based on OpenFormula and support for digital signatures.  ODF 1.2 has been approved as an OASIS standard and is expected to be submitted to ISO/IEC JTC 1 in the near future.
  • The inclusion of a spreadsheet formula specification in ODF 1.2 addresses one of the key factors limiting interoperability between spreadsheet applications in previous versions. This, coupled with Microsoft Office 2013’s support for the format, means that formulae contained in spreadsheets can be reliably transferred between applications.
  • Defining a common format to be supported by all office productivity suites does not preclude the use of other formats.
  • This format may provide greater support for cloud-hosted office productivity suites, should use of those become more widespread in the future.

Examples of Office Productivity Suites with Support for ODF

Office Productivity Suite Operating Systems
LibreOffice Windows, Linux, Unix-based systems, Mac OS X, Solaris
Microsoft Office (2007 SP2 / 2010 / 2013) Windows
OpenOffice Windows, Linux, Unix-based systems, Mac OS X, Solaris

It is also important to note that while WofG COE Policy will require that office productivity suites support at least ODF 1.1, it does not mandate the use of that format. Having completed the initial review, I would like to invite interested parties to review the documents and provide any comments through this forum. Once your feedback has been received, we will conduct a final review of the documents, referring to the Working Group as necessary. The updated policy will then be taken to the Chief Information Officer Committee (CIOC) for advice and to the Secretaries’ ICT Governance Board (SIGB) for approval.

John Sheridan

Comments (46)

This is a great idea, I highly recommend it! I've worked in computing for 25+ years, and incompatible and orphaned file formats has been a HUGE problem.

Using ODF and similar means that you become free of such issues.


On page 21/37 under Storage.
A major advantage of standards is that they can be implemented at any time as the need arises.
In the past there have been documents / information stored in a proprietary format, which is exclusive to a given vendor. This proprietary format may or may not be supported in 10 years time.

I suggest that any file or document that may need to be read more than 10 years after it is created be stored in a fully documented format, and preferably in a Open Document Standard format.

This will insure that any information or document that is lost due to lack of vendor support can be recovered if need be, even if it needs a new program written to convert the format.
If the format is not fully documented the cost of recovering that information will be much higher, and may not be practical.

Hi Andrew,

Thanks for your comment. This is an important issue and is already covered by policy. The National Archives has developed instructions for agencies on this matter. You can read them here



One factor conspicuously absent from the list of factors evaluated is the following...

As you would be aware, the FMA Act and Commonwealth Procurement Rules require any commitment to spend public money to be an "efficient, effective, economical and ethical" use of resources.

A policy that is not based on an open standard (which can be implemented by a broad range of vendors) is inconsistent with the Commonwealth's financial framework and procurement requirements. The proposed policy should explain and promote to agencies that competitive tension in a tender process cannot be assured unless the broadest range of vendors is able to respond.

In my view, this factor should be given very strong weight as, ultimately, it feeds through to agencies' ability to negotiate favourable pricing on behalf of the Commonwealth from vendors. Given the influence the proposed policy will have on individual agencies' procurement decisions, this policy is important in supporting agencies' ability to negotiate favourable pricing.

I am not aware whether the proposed policy is considered solely on technical grounds or not. However, the impacts of the policy across all agencies' procurement and expenditure of Commonwealth resources should not be ignored.

Standardising on truly open and accessible data exchange formats is a reform that has been a long overdue from the Australian Government, and is a welcome step. (Granted, it has taken a long time for open office productivity formats to mature.)

It would be good to see this kind of reform applied to other areas of Government, such as official support for platforms other than Windows and OS-X by AUSKey and the ATO.

I think this is a great move. I've worked in this industry for decades now and I can say that our reliance on closed document formats is one of the biggest issues we face.

Our ability to read documents in the future is a very important issue.

Thank you for raising this!

Spending currently a few month in "good 'ol Europe", i can say that the step our government in Australie has taken regarding this issue is one of the best moves ever.
Here in Europe NO government has decided to do the same - maybe our move in Australia will give them a "hint"?

In the long run, from a market perspective: Think what may happens if Microsoft may be pushed against the wall by competitors, resulting in bankruptcy?
Sooner or later this step would have been taken, anyway - so, why not now?

Thanks to people who decided this!

See you next year, in 2014, when i'm back!


This a wonderful idea and very much needed. This will make inter-operating with the government vastly simpler. From a business perspective this will significantly lower operational costs as portions of our workflow will be able to be automated.

This should allow more people to apply for government jobs ( software costs are lower, cloud solutions exist etc..). More importantly software like Libreoffice supports excellent version control and advanced authoring capabilities which should allow the government to adopt more agile processes that are currently only found in private companies. Document version issues have affected many of my interactions with government departments.

All in all a wonderful advancement.

Great that this is finally being seriously looked at. I would suggest taking a good look at the UK government criteria for open standards and follow suite.

Not only will this make inter-operating within the government vastly simpler, it will also allow private individuals access to documents in a standard format regardless of the platform they run at home.

Please consider making Open Document Format 1.2 the level or 1.1 with ODF formulars.

Libreoffice and Apache OpenOffice are free to install to achive this. Buying a plugin from Orcale is possible as well to push MS Office upto this.

1.1 with ODF formulars use with MS Office 2003-2010 to achive this.

Issue is 1.1 did not define formulars in spreadsheets in ratified standard. There was a draft standard of how formulars were to be done 2007 and before. So Microsoft did the naughty in all versions of MS Office prior to 2013 and wrote OOXML formulars into a ODF document. Of course these cannot be read by pure ODF programs. would not be required if Microsoft Office 2003-2010 did not write incorrect ODF files.

I would go for 1.1 with ODF Formulars as min with 1.2 prefered. As offices change over to MS Office 2013 and up reading an writing ODF 1.2 will become stable. Problem is reading the old stuffed up not to standard MS Office generated ODF is not ensured.

This is exactly the same issue that we have had with OOXML. You really do need to serousally talk to Microsoft about producing files conforming to standards and providing updates to older programs to fix up where they did wrong. It would be nice to hit them with Descrimination or some other nasty big law over it. Microsoft has a long history of being standard breaking.

It would be possible to push some resources into to fix up MS Office 2003-2010 to write ODF 1.2 properly. The question is it worth it.

Of course it would be better if Microsoft would just down right release a fix.

Please remember RTF was the first common document format Australian governement choose. Microsoft is the one responsable for stuff that up as well. It will be worth yelling in there ear this time so its loud and clear it will not be tollerated and they need to fix there past stuff ups or it could effect future contracts.

This is a great policy and I would like to see more encouragements to the agencies to use this standard in time.

I manage a community technology centre on a rural region with significant poverty. Very few customers who bring their computers in for me to help them, have (or can afford) Office licenses. I generally show them the use of libre office and they are happy. Inability of government and it's affiloated agencies (job network providers etc) to deal with citizens due to format issues, and vica versa is an issue right now, not just for the future.

Of course PDF is heavily used by aus govt to address some of this but it has poor cut/copy abilities, making research and document construction slow. Additionally: can we ban govt from using PDF forms? The interpreter program is vendor specific and the whole experience of using the forms is a nightmarish wander in the dark of what is and isn't allowed, what might work on one adobe reader installation and not another. Dept of immigration is one offender using this format.

When can we find an open format, non Microsoft, for e-forms, so we can have competition and a choice of interpreting software?

Thanks for the great work on odf. This standard will improve user experiences greatly around the world as it begins to flourish.

1: MS Office has pretty poor ODF support, you loose a bunch of ODF features roundtripping with Office. It's supposedly going to get better...who knows, but don't rely on it.

"Why the heck is government worrying about a document standard that frankly less than 5% of the worldwide population uses"

\2: I call BS on this. I worked for a 3 letter multinational tech company as tech writer. We were required to use ODF for all of our documentation unless there was something specific (in which case we still aren't using .doc/.docx or whatever). That was about 2 years ago. We had our own internal office applications written mostly from scratch by our engineers. We had more employees (worldwide) than most australian cities have and the number of documents we would author on a daily basis was insane. We had our own search engine just for documents. There are a bunch more ODF documents than anyone would think, just from my old company alone.

Also, I'm pretty sure I know which teleco @andrewm was talking about ( as I was contracted there for a while ) and they also generate a crapton of documents per day. The documentation team (unlike their service) is very good.

"An interoperable file format that works with every tool equally well is a great goal. It’ll never happen though because it requires companies vendors of the major tools to slow down their innovations to pace consistent with the standardisation effort."
I don't think the storage format really affects innovation so long the format it's self is either capable storing the same information as the "native" format or the format is extensible. ODF is fortunately both. So if for example the idea was to replace it with RTF I could see how that would cause issues. ODF is pretty solid. I also personally consider that supporting ODF *is* innovation. Personally, I would have been happy to live with out the ribbon interface in word if it meant I got ODF support :)

"If you want a healthy vibrant software industry you need to allow companies to innovate. When you set a policy which mandates a specific format you work against that."
I'm not sure I agree with this. Firstly, software is there to solve human problems. It doesn't exist for the sake of it. This is an actual human problem. Secondly, the policy doesn't dictate the softwares internal format. .docx isn't MS Words internal format. It's just it's native export format. That format may ( for simplicity) be a close serialization of it's internals, however with .docx (unlike the old .doc format) for example, i'm fairly certain that's not the case. Even if ODF wasn't able to store the features of the wordprocessor (which isn't the case), I am sure the requirement would only to support the parts of the document that the export format is capable of.

Given ODF's 1.2's extensibility this is not an issue in the real world.

ODF support will cost time and money for a vendor to implement however there are many governments that already mandate the use of ODF (Danish Govt, German, French, EU Council, Netherlands, Spain) in some form. I'm sure between the numerous govt departments and bunch of companies I personally work with, the total development costs would be a made back many times over.

My only concern with this is that the COE lists 1.1 of the Open Document Format. If this is going to go through it really should be 1.2. 1.2 Fixes quite a few issues.

" There isn’t a limitation with MSFT Office. OpenOffice and nacholibre office seem to have the issue. Thats why 95% of business uses Office. "

The issues you specifically linked to are software limitations. The ODF format has provisions for these.

"Despite all the fuss over MSFT licensing everyone still wants to use it (or pirate it) because it meets the needs of business. "

As mentioned before, I am personally involved with large, private corporations which use it internally for very specific reasons. Not all of those uses actually involve a client side office suite at all. There is more to the format than just what an office productivity suite currently provides.

If someone wants to use Office, firstly I hope they would pay for it as that is part of the license agreement. Secondly, that is their choice. I don't believe anyone is forcing someone to use any particular vendors software.

"So then why would MSFT support a “standard” (and I intentionally put that in quotes because with less than 5% market share,"

I am unsure where you got the 5% from however they already do support it to an extent so I presume there is cost / benefit associated with it. Otherwise I see no reason or Microsoft to support it at all.

Furthermore the "standard" is actually a standard. I am unsure what metric you are using to determine it is "inferior" because from a software development perspective it's well defined, simple to implement, extremely flexible, extensible and royalty free to implement. For a document format all of those things are desirable and I haven't seen a document format which is superior in the above points. Can you give an example of a format you think is superior and possibly why you feel that is the case ?

"I am in software and there is no way in hell I would engineer anything for 5% market share…"
Well that's ok for you and I don't think people are forcing you to do anything. I personally prefer to follow the money, so far, even without the government endorsement I've been involved in a number of reasonably profitable projects involving ODF. So long as someone wants to pay me, I'm happy to work with ODF.

“Really good” doesn’t cut it. By government mandating a standard it forces business to comply, its a natural outcome"

Again, no one is forcing anyone.

"Have you ever dealt with government procurement? Collaborated with them on anything?"

Absolutely and on a regular basis. I believe ODF will make this process much more efficient. (See previous comments)

"Then you have the naivety to suggest that because of the short comings of poor software, that we will need to employ people to fix it."

1) this would create jobs, which is a good thing. I would rather my tax go towards an australian person than a large multinational.
2) The software is licensed so it's redistributable so this benefits all Australians. Again I fail to see how this is a bad thing.

"(I refuse to even call it a standard anymore cause its not) "
I don't really see what this achieves.

"IIRC there was a bunch of EU departments that went to OpenOffice like you said too, but then ripped it back out again because the users hated it and it wouldn’t work."

First of all i didn't say they went to OpenOffice. They went to ODF.
It's entirely possible that the the above government were trying to use OpenOffice and use something like a .docx format. Once again, this project isn't forcing anyone to use software they don't want to.

"Take a read of that article and then tell me there won’t be problems."

I'm not saying there won't be issues, but as someone who already has to interface with the government there already _are_ interoperability problems. I believe this project will address most of those. I am sure it will introduce more problems but from my perspective those are also solvable. At the current point in time, the existing problems aren't really solvable with a proprietary and binary format.

"You get what you pay for."
Well that's true to an extent, but no matter how much money you throw at a vendor they aren't guaranteed to fix your issue. Especially if fixing it requires overhauling their document format. It's not reasonable to expect that either.

I personally would rather use tax payers money to fund business innovations around software which can be used by all. I don't see who benefits from the government purchasing software from a large multinational.

The ability to aquire legal low cost software is important to educational consumers and low income families. However there is no reason why you can not purchase commercial software which fits your needs. ODF is accessible to all, commercial, non-commercial, free or proprietary.

Hi Michael

The links you posted in your earlier message are the same as those I posted above.

I'd like to make it absolutely and completely clear that there is no intention to make this a standard for dealing with Government. As I said in an earlier comment, this is about intra-government interoperability, nothing more. It sets a lowest common denominator, that's all. It is not about adopting a different office suite, although that remains an agency choice. Nor is it retrospective. It is about how the next SOE is designed and built and it only applies to SOE designs that start after the policy is formalised.

I'm not sure what an "ABM'er" is so I can't comment on that but this work has been done inside government in consultation with agencies.

Finally, I am also the Australian Government Procurement Coordinator ( If you have comments or complaints about procurement, I'd be happy to address them through that process or on the procurement blog posts.



Andrew, you're making naive statements.

1. There isn't a limitation with MSFT Office. OpenOffice and nacholibre office seem to have the issue. Thats why 95% of business uses Office. No-one in business seems to say to me that theres a problem with their ability to work and collaborate? Despite all the fuss over MSFT licensing everyone still wants to use it (or pirate it) because it meets the needs of business. So then why would MSFT support a "standard" (and I intentionally put that in quotes because with less than 5% market share, I'd hardly call it a a standard) that is inferior? I am in software and there is no way in hell I would engineer anything for 5% market share...

2. I was around 20 years ago. Even when the Lotus/Microsoft wars were in effect, Microsoft supported their document formats. There was migration to handle it and IIRC we had no one from government running round saying hey MSFT has 5 % market share, let's mandate that .doc standard...

3. "Really good" doesn't cut it. By government mandating a standard it forces business to comply, its a natural outcome. Have you ever dealt with government procurement? Collaborated with them on anything? I have. It will be a nightmare to interoperate. Then you have the naivety to suggest that because of the short comings of poor software, that we will need to employ people to fix it. I don't know about you but Im about done with taxes. I want to see government work with business, not duplicate its efforts and waste taxes simply because some ABM'er decides that a niche format (I refuse to even call it a standard anymore cause its not) should take precedence.

Tell you what government, how about you become accountable to the Australian taxpayer and stop wasting everyones time and money with ridiculous mandates like this?

IIRC there was a bunch of EU departments that went to OpenOffice like you said too, but then ripped it back out again because the users hated it and it wouldn't work.

Take a read of that article and then tell me there won't be problems. You get what you pay for.
I will ask, why is government interested in mandating against 95% of Australian business? And don't try and sell me on bogus stuff that this is only internal government use. That essentially says to me that the Australian Government lives in a vacuum. I'm sure thats not true right? ;)

So firstly its important to note those are limitations with the software, not limitations with the format. Future versions of MS office could address this.
Secondly, as mentioned before this is not forcing you as a business to use ODF.
Thirdly, imagine we are 20 years ago and lotus 1-2-3 was the standard. What if we said no one uses office, why are we using that to interoperate?

ODF is a really good format, and I would argue is the correct solution to the above problem. If the tools need work for certain workflows then we can employ local Australian developers to fix the flaws. Most of the mentioned software allows redistribution so I don't see an issue with that.

Its also worth noting that several goverments around the world and the EU as an organisation has already made this change and have reported overall success.

The following submission was received from Microsoft in response to the request for comments on the draft Common Operating Environment Policy.

Microsoft Response to the Common Operating Environment Policy [PDF, 473Kb]

The following submission was received from the Australian Information Industry Association (AIIA) in response to the request for comments on the draft Common Operating Environment Policy.

AIIA response to the Common Operating Environment Policy [PDF, 470Kb]

That's all great Andrew but a tiny, tiny portion of the market uses OpenOffice and Libreoffice (whatever that is...I've never heard of it).
Why the heck is government worrying about a document standard that frankly less than 5% of the worldwide population uses? Its ludicrous! I know I'm probably talking to the noisy OSS minority that seems to have dominated this thread (that obviously won't agree) but as a citizen doing real business I refuse to lie down and have our government continue to make it even harder to do business in Australia simply because someone wants to implement a minority standard. It's no small impact. You can't even interoperate basic collaboration such as track changes! As an explanation on the differences:

.odt versus .docx

.ods versus .xlsx

Web Version:

.odp versus pptx

How about catering to the real world instead of minority groups and standards? FWIW before you think I'm just another MSFT fanboy, I'm typing this on a Mac. But even with my Mac, I use Office. Just doesn't make business/collaboration/productivity/interop sense to use anything else.

" why is the government so focused on supporting such a limiting standard as ODF"

So which portions of ODF specifically do you find limiting?
From my perspective both OpenXML and ODF have their shortcomings ( ODF has addressed most of these in their later versions).

OpenXML, despite the name is not all that open and is somewhat tied to the way Microsoft have done things in their office suite. Furthermore, Microsoft have (according to them) designed OpenXML for archival purposes, so that documents can be read in the future, not as an interchange format.

This also doesn't preclude a company / org from using whatever file format internally. From my understanding it's just a method to ensure that departments can inter-operate with each other.

I think it's important to distinguish the format from the software that supports it however I do acknowledge they are related. Nothing precludes any vendor from supporting ODF 1.2 and that is important. For what it's worth , I don't think there are currently any products ( including Microsoft Office) that support OpenXML as per the standard.

As far as software is concerned, using ODF does have some advantages. Libreoffice / Openoffice have some excellent versioning and collaboration features as well as some very fine grained control over the document authoring (schema validation, docbook support). These are not found in traditional products like Microsoft Office. Being able to round trip between different products allows each group of people to use the tool which best suits them.

I also think you would be surprised at the user base of ODF. It's not typical amongst home users but for very large organisations ( inc govt ) where document consistency can be hard to achieve, it has some very appealing features. Also transforming ODF to other formats, html5,docbook,svg etc is reasonably easy via XSLT. The same is not sure for OpenXML (which to be fair, as an archival format this isn't part of it's design).

Kind regards

Hi Michael,

Thank you for your comment. It gives me a welcome opportunity to address a common misperception about the COE document format policy. This policy does not require any agency to adopt a particular application or suite of applications. It does not require an agency to use only this format. It does not require businesses or citizens or, indeed, anyone to use this format to deal with government.

The policy has one aim only. It is designed to ensure that a public servant, using a government supplied computer, or connecting remotely to a government supplied desktop image, can share (read and write) documents in a format that any other public servant, in any other department, similarly connected can also use.

Previously we have used Microsoft document formats for this purpose. Now, due in some measure at least to Microsoft's work in expanding the compatibility of the Office suite, we are able to use the ODF format. This format can be used by a wider range of suites than the standard OOXML formats. As a consequence, the policy change increases, not limits, interoperability. I think that is a good thing.

Agencies can still exchange OOXML documents if that suits both parties. They will need to be able to read and write ODF documents but, as you point out, the majority using Microsoft Office can already do that.



It is good that Microsoft and an organisation that represents them support the ODF standard, however mandating the additional OOXML standard that has only recent, with Microsoft Office 2013, support from a single vendor, and only available for one operating system, Windows, by default mandates that operating system as well as that Office suite for anybody trying to support that format.
Microsoft Office for Mac does not yet fully support the OOXML standard, and there is no guarantee that it ever will, and no other Office suite for any operating system supports it either.
Because of patent infringement problems OOXML may never be available to users of other Office suites, and as such is not an "Open" standard.
References to a large number of existing .docx files is clearly misleading as the only Office suite that can write to the full OOXML standard is Microsoft Office 2013, and the vast majority of existing .docx files do not comply with the OOXML standard and were written before this Office suite existed.

Tools that have needed to be constantly updated to suit a constantly changing propitiatory format will be much easier to maintain and for this reason changing to an open standard sooner rather than later will save time and money.
ODF is much easier for a third party to implement than OOXML and does not carry the patent infringement burden. Supporting both would be a drain on resources.

Content fidelity is also important, as changing between formats could change the layout of the documents and important information could be lost. Standardizing on a feature rich standard such as ODF would help prevent this data loss.

While we can talk ODF, which in reality a tiny portion of the market uses, it isn't what the vast majority of business uses. The majority of these "productivity" suites I've never even heard of. Additionally why is the government so focused on supporting such a limiting standard as ODF? Why not Open XML (which is also an open standard) that Microsoft Office and the majority of business uses? Has the government factored the impact for over 90% of business in Australia?

Mitch - Firstly, great response. Second, I doubt it will make a difference. FWIW I've stopped commenting as I've realized that this thread isn't truly about views being sought or any sort of public comment for reasonable and rational input. This is simply a bunch of anti-Microsoft fanatics in government forcing their minority views on everyone else and forcing a niche "standard" with horrible interoperability to be adopted and totally ignoring the "tools" aspect of the discussion.
Sad thing will be the impact on business that has to interact with them and the poor people in government that have to deal with this unfortunate mandate.
I welcome the day when the Australian government actually becomes accountable and true public consultation becomes worthwhile.

Hi Andrew,

The reality of building creative tools is that those tools need to be able to persist data in a format that makes sense to the tool. Whether other application scan read that file format is actually a secondary concern.

Provided tools like Microsoft Word can output their contents into a "digital paper" format such as PDF or XPS then I think it is OK for people who prefer to use Office and OOXML to continue to do so. One of the interesting conclusions to be drawn from the figures that Microsoft put up is that the vast majority of documents that are published are in a digital paper format.

So the conversation as to which format is better OOXML or ODF is completely pointless. Just let people use the tools that allow them to express their creativity the best. I don't see too many people trying to convince graphic illustrators to put down Adobe Illustrator and move to saving everything in SVG format.

Hi Steven,
Thanks for your feedback. Here are my responses to the points you raise, in order:

1.In the context of the COE Policy, they are both required. The term “mandatory” is used to identify components of the COE which must be installed, or security configurations in the SOE Build Guidelines which must be applied. The terms “must” and “should” are used to define the compliance requirements for the standards established against each component of the COE. Standards which use the term “must” are mandatory requirements, while those using “should” are strongly recommended.

2.You raise a good point. I agree that “Communications Client” could be used instead.

3 and 4.We definitely aim to keep the terminology used in the COE Policy platform agnostic. The changes in terminology you suggest for “roaming user profiles” and “domain credentials” will be included in our updates.

5.The Working Group considered this exact issue when formulating the standards applicable to “roaming” user profiles and cached credentials. It is the reason both standards contain “should” compliance language.

6.I agree this standard is better suited to the SOE Build Guidelines for Windows. We’ll update the policy accordingly. I’d also note that restricting access to SMB and NetBIOS services is currently ranked 28 in DSD’s TOP 35 Strategies to Mitigate Targeted Cyber Intrusions.

7.We do review the COE Policy annually and the “N or N-1” principle has been looked at every year since the policy’s inception. Where the principles outlined in the policy require updating, to address issues such as shortened vendor release cycles, we’ll ensure they are included for the consideration of the Working Group.

8.As noted in response to Mitch’s comments, the formats used when posting on the blog are consistent with the policy for accessibility on the web.

9.In developing the COE Policy, agency OS usage was surveyed and based on those results a Windows pilot study was conducted to validate whether the COE Policy was able to be implemented across government SOEs. At that time, no agencies were using either Linux or Mac OS. The cost of conducting a pilot to determine if the policy could be implemented in those OSs was, therefore, not justified. We continue to gather data from agencies on a yearly basis in order to inform development of the policy and measure compliance. If that data showed an uptake of other platforms by agencies, we would certainly review the policy to ensure it could be implemented across those platforms.

Your comments are a great example of how open discussions about such matters can improve what we are doing. I really appreciate your support.



Thanks Andrew, they are surprisingly large numbers.


Any chance of including a standard list of commonly used accessible components. I am thinking of two.

1. Speech 2 Text.
2. Text 2 Speech.

Microsofts in-built offerings in Windows are not currently even near the competitive-edge at present, so we cannot assume this is catered for. If we take the huge interest in new mobile input methods as an indication of the future (I am thinking of Siri etc...), then this is the writing on the wall. Once we get used to using them, they will become standard. Remember, they once mocked the mouse.



Specifying a minimum level of compatibility is not going to slow down vendors innovation, instead it will most likely accelerate it.
The ODF format has provisions to include new features by following a few simple rules, without breaking compatibility.

If you want a healthy vibrant software industry you need to allow companies to innovate. Setting a policy which removes incompatible format barriers and allows any vendors tools to work with as many documents as possible will greatly assist in this.

Well I am a FOSS consultant so my clients are not representative but in Adelaide at least I think you would be surprised. A quick investigation of 3 of my larger clients (people wise ) yields just over 3000 Linux workstations. So it's not a lot, but if you were on the outside you wouldn't know about them. I understand a few engineering and 3dfx companies around the city are also heavy users but I presume they are used in more technical manner.

An interoperable file format that works with every tool equally well is a great goal. It'll never happen though because it requires companies vendors of the major tools to slow down their innovations to pace consistent with the standardisation effort.

If you want a healthy vibrant software industry you need to allow companies to innovate. When you set a policy which mandates a specific format you work against that.

Hi all

I have received some useful advice on the differences in the manner in which various versions of Microsoft Office support the odf standard:

- Word
- Word web app
- Excel
- Excel web app
- PowerPoint

Interestingly, the differences between versions aren't that large.

I would welcome any discussion on whether these differences create major issues for users. Remember, of course, that the COE policy sets a 'lowest common denominator' and doesn't preclude the use of any particular format between or within agencies.



Yeh it's probably not appropriate for alot of people. I'm currently contracting with a teleco who have recently migrated to Linux for most of their general business staff and pretty much their entire development team. All of their internal documentation is ODF 1.2 or docbook. I mentioned this article to one of the support staff and apparently they use Calligra. It wasn't on the list so I thought I'd mention it.


Thanks Andrew. Calligra looks interesting but I note it isn't really ready for use on Windows or Mac OS X. That makes it a little less relevant for widespread APS use at the moment. I'll check it out on a Linux machine anyway.



You can add Calligra to that list also.

Thanks Steven

Your comment is a good example of why public consultation is so useful. We'll check this out and amend the list accordingly.



I think the table included in this post needs to be updated somewhat:

1. Google Docs no longer supports ODF and hasn't for over a year: Google Groups and some analysis here.

2. Lotus Symphony was discontinued by IBM in November 2012 with the code supposedly being merged with in a future release.

3. StarOffice was discontinued by Oracle in April 2011.

Therefore, the table should include the following products:

1. LibreOffice

2. Microsoft Office

3. OpenOffice

Microsoft does also offer some support for ODF in Office Web Apps (presumably the same version as the desktop suite).

Can the table be updated to reflect this information?

Hi there,

When this update came out I thought I would pen a few thoughts about the real impact in the industry (from the perspective of a software developer).

Hope that my thoughts can be passed along to the various authors and committee members.

Hi John,

Firstly thanks for posting this COE draft for public comment. Just a few comments:

1) What is the difference between MANDATORY and 'must'? Are they both required or is MANDATORY essential and 'must' if the specific platform supports it?

2) In the Standard Applications -> Email Client section, it states that the client must support shared calendars and contacts. Should the name of this section be changed to 'Communications Client(s)' or 'Communications Application(s)' to better represent the fact that these 3 functions can be separated across different applications?

3) Under The System -> Storage section, 'c' states that 'Roaming user profiles should be used'. Given that this is a Microsoft specific technology should this be changed to 'cached user profiles' to ensure that the policy is platform agnostic?

4) Under The System -> Operating System section, 'o' states that the 'Caching of domain credentials should be disabled'. Given that this is a Microsoft specific terminology, should this be changed to 'Caching of user credentials should be disabled', to ensure that the policy is platform agnostic?

5) Given that the purpose of roaming user profiles is to support working offline, how do you resolve this with the requirement of disabling the caching of credentials? If cached credentials are disabled then what is the point of using roaming profiles, since users would not be able to log in offline as their credentials are not cached?

6) Under The System -> Network, should 'c' be moved to the SOE Build Guidelines for Windows or into the ISM as this is referencing a Microsoft Windows specific setting?

7) Given that most operating system vendors are now moving to a more frequent release cycle for their systems, is the N-1 requirement going to be re-evaluated? For example, when Windows 8.1 is released later this year, N = Windows 8.1, N-1 = Windows 8.

8) Could future documents released on the AGIMO blog and of this policy be in ODF format, given the saying of 'eating one's own dog food'?

9) What assurances can AGIMO provide that adequate consideration was given to the ability for other platforms, such as Linux or OS X to comply with this policy? Has the working group evaluated the platforms to ensure they can meet the requirements prior to placing them in the policy?



That's a relief. I'm sure the departments will just continue as is then with silent agreement that they'll use the native formats of their existing tools.

Thanks Daniel,

Many agency staff may not be able to view Google Docs from within their firewalls so this may not help particularly. But you do raise a good point. People who wish to send something to us can do so via if they don't want to post on the blog.



Hi Mitch

I guess the essence of collaboration would be that those people would already be using such features so the exchange could continue to take place. This policy sets a minimum standard for interoperability between all FMA Act agencies. It doesn't seek to stop bilateral exchanges between agencies that agree to use another format.



Hi John,

Thanks for your quick response. What do you say to those organisations that are using the more advanced features of Office products that will lose the ability to round-trip that data between collaborators if the ODF format is selected?

Too bad?

It wasn't really mentioned how feedback would occur, so while I could give a document with comments back (in ODF format of course), or do lots of comments on the blog here, I thought I'd just put it on google docs and anyone can add comments (but not edit) it there.

It does highlight that document collaboration isn't part of the SOE however.

WofG COE Policy v3.0

SOE Build Guidelines – Windows v3.0 – Official Draft

I'll add my comments soon.

Last updated: 27 June 2014