The Dutch government’s decision to favor the use of open source software over proprietary alternatives has naturally received a lot of press attention over night, and rightly so. The news has overshadowed a similar decision by New Zealand’s Ministry of Justice.

It’s a shame the Ministry of Justice’s decision hasn’t garnered more attention, because it is accompanied with a very interesting document (PDF) that outlines its policies and decision making process.

Available from The New Zealand Open Source Society, the discussion paper addresses come of the common (valid and invalid) objections to open source software, as well as the associated risks and benefits, and concludes that: “OSS was once an extraordinary way of thinking, limited to academia and small guerilla projects in a community of hackers. Increasingly, however, it’s the norm.”

It then presents the Ministry’s policies regarding open source. The most significant of these is that “when evaluating software as part of a technical solution, preference is to be given to OSS alternatives over comparable proprietary solutions.”

While that is the headline news, the real value of the document lies in its discussion of the more mundane policy decisions that need to be made when evaluating and adopting open source software. As such the Open Source Discussion Paper represents a great starting point for any other business or government department considering what decisions must be taken into account when considering open source software.

Another organization’s policies are unlikely to match the MoJ’s exactly, but if the following ten (summarized) policies are taken into account, then the main policy areas will have been considered. Some of these are just common sense, but a gentle reminder of that can never be a bad thing.

Policy 1: Open standards
Choose software that implements open standards wherever possible.

Policy 2: Prefer OSS
When evaluating software as part of a technical solution, preference is to be given to OSS alternatives over comparable proprietary solutions.

Policy 3: Review licences
When considering an OSS product, the licence terms should be identified and reviewed explicitly.

Policy 4: Formal OSS evaluation
When evaluating an OSS product, commit resources to formal evaluation.

Policy 5: Version
Adopt most current versions of any OSS product, and adopt a release lesser than 1.0 only if substantial evidence of stability exists.

Policy 6: Active development
Reject adoption of any OSS product that does not have clear evidence of BOTH current development work AND community support.

Policy 7: Commercial support
Adopt OSS products that have commercial support options available.

Policy 8: Enterprise architecture
Use the EA to guide the process of selecting an OSS product.

Policy 9: Release Code Changes (Integrate, Don’t Build)
Allow both internal and third-party developers to implement and release code changes back to the community.

Policy 10: Documentation
Adopt only OSS that have an ongoing technical documentation effort associated with them.

The complete Ministry of Justice Open Source Discussion Paper can be found here.