I have proposed the guidelines below as a suggestion to the Australian "General Practice Computing Group", the peak national body for IT in GP, and arguably the main driving force behind health IT in general in Australia.
As expected, I have got a lot of flak from the industry with predicable (and mostly wrong) arguments. However, I would appreciate comments from the "scene" as well in oder to improve this document (which appears to have reasonable odds of getting accepted now) - your inout migt provide it with that litle extra that might make the difference. ---------------------------------------------------------------- Recommendations On Subsidies For Software Development Software development subsidised directly or indirectly with taxpayers money should fulfill the following requirements that ensure maximum value for money for the taxpayer, 1.Licensing: the license chosen needs to allow the public to inspect and reuse any source code that has been developed with public money. Any GPL compatible license [1] is generally acceptable. Dual licensing (release of the same code under more than one license) allows commercial vendors to reuse code for commercial software without restricting their business model, and allows the authors or project sponsors to recover costs via license fees if this is desired. 2.Portability: any subsidised software has to be written in a portable way: that is, simple recompilation and/or little to no modification should allow the software to run on any platform potentially able to serve the purpose of the developed software. Where program code is not portable for practical constraints, it has to be abstracted and isolated into platform specific modules. Wherever simple use of a different programming language or abstract toolkits would allow portability, non-portable software is not acceptable. Whenever a potential contractor claims portability to be impractical for a particular project, this claim has to be verified by a senior software engineer experienced in portable software development. 3.Component reuse: software to be written with reusability of code as a design requirement. Algorithms and data structures that can serve an independent purpose or might be useful for more than one project should be isolated into modules with as little module interdependency as possible. Available free software components that can fulfill a (partial) task of a project should be given preference above re-implementing the same. The tender process should be preceded by checking for availability of such potentially reusable components. 4.Vendor independence: in order to prevent the costs and built-in obsolescence of vendor lock-in, no vendor specific tools or programming languages should be required to build or maintain the subsidised software unless they can be replaced with free and/or standard compliant alternatives. 5.Standard compliance: wherever standards exist related to one or more task of the subsidised software, these standards must be used instead of development of proprietary solutions. Whenever existing standards appear to suit only partially, preference should be given to the attempt of officially extending the existing standard rather than developing a proprietary extension of the existing standard. ------------------------------------------------------------------------- Horst
