Horst, I think this would serve as a good model for government sponsored software projects worldwide.
My comments: 1. Perhaps a BSD-style license will appease both the commmercial for-profit folks and the open-source community rather than dual licensing (though that certainly works too as evidenced by MySQL). 2. I think portability should go beyond the software to include data storage; it should be an open standard such as XML or even plain ASCII. 3. This is just good software design- nothing to add here. 4. Vendor independence is worth "splitting out" from portability in that it is important that freely available tools/languages are used for the software creation. 5. Another thing that I agree with wholeheartedly. Just need to make sure a defacto standard (such as word docs) aren't misconstrued as an open standard. Ron Nath --- Horst Herb <[EMAIL PROTECTED]> wrote: > 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 >
