Two months ago (Aug 30, 2009) I alerted readers Europeans: only two weeks left to comment on ICT & standards whitepaper. I am not sure on which dots actually join up, but a Dutch website has what is claimed to be a leaked late draft in English of European Interoperability Framework for European Public Services (EIF) Version 2.0.
Here are some of the general recommendations related to standards and issues raised on this blog (I have added italics where some phrase or nuance interested me):
Recommendation 18. Public administrations should support the establishment of both sector-specific and cross-sectoral communities aimed at facilitating semantic interoperability and should encourage the sharing of results produced by such communities through national and European platforms.
Recommendation 19. Public administrations should agree on the standards and specifications to be used to ensure technical interoperability when establishing European Public Services.
Recommendation 20. Public administrations, when establishing European Public Services, should, as much as possible, base interoperability agreements on existing formalised specifications, or in case such specifications do not exist, collaborate with communities working in the same areas.
Recommendation 21. Public administrations should use a structured, transparent and objective approach to the assessment and selection of formalised specifications.
Recommendation 22. Other things being equal, public administrations should prefer open specifications when establishing European Public Services.
Recommendation 23. Public administrations should actively participate in the standardisation activities that are relevant to their needs.
Looks pretty solid stuff. The impression I get is that the policy is severely biased to the pragmatic rather than the ideological. For example: is ISO dead? Well, not at all:
s4.6 ... technical interoperability should be ensured, whenever possible, via the use of either standards endorsed by recognised standardisation organisations or technical specifications made available by industry consortia or other standardisation fora.
The next pair of paragraphs are very interesting indeed, because they show a more eyes-open approach to standards and plurality. (I'd say the first paragraph is there to direct attention to things like the scope statements of standards, as part of consideration for strategic decisions between alternative technologies...)
s5.1 However, there are many reasons why standards and specifications are produced, besides facilitating interoperability, e.g. efficiency, the creation of new markets or the extension of existing ones.
Furthermore, when trying to map interoperability agreements, at technical or semantic level, on formalised specifications, one may find that there are a number of equivalent, competing specifications from which to choose, all of which may be able to fulfil such agreements.
While public administrations may decide to support multiple formalised specifications or technologies to ease communication with their citizens and businesses, for reasons of efficiency, they may wish to reduce the number of formalised specifications and technologies to support when working together to provide a European Public Services.
So I don't think the last paragraph represents any kind of new policy, it is just a re-statement of the status quo, which some people were...err...not aware of. But readers may see this in the light my point that the voluntary standards (of ISO/IEC JTC1 and the industry consortia) represent a library of technologies and it is the adopter's job to decide which technology (of alternatives) to adopt (and which profile to limits themselves to).
This next one is interesting: it is no use saying how open a committee is or isn't if the thing doesn't work! Functional requirements are an absolute bottom line.
s5.2 When public administrations decide on what formalised specifications or technologies to select to ensure interoperability, they should assess relevant formalised specifications.
While being tailored to the specific interoperability needs of the public administrations in question, such assessment and selection should be based on objective criteria, primarily related to the functional interoperability needs. When several formalised specifications fulfil the functional interoperability needs, additional criteria related to quality of implementation, adoption by the market and the potential for reusability and openness can be used.
The blog I quoted above was pushing that a balance of interests was important consideration for openness. This purported draft goes a different way, setting a quite low bar for openness, but then weighing openness less highly. I guess that is another way to treat the balance of interests issue.
s5.2.1 The possibility of sharing and re-using service components based on formalised specification depends on the openness of the specifications.
If the principle of openness is applied in full:
• All stakeholders can contribute to the elaboration of the specification and public review is organised;
• The specification document is freely available for everybody to study and to share with
• The specification can be implemented under the different software development
It is up to the creators of any particular specification to decide how open they want their specification to be.
Because of their positive effect on interoperability, the use of open specifications, characterised by the three features mentioned above, as well as sharing and re-use, have been promoted in many policy statements and are encouraged in the context of European Public Services delivery.
However, public administrations may decide to use less open specifications, especially in cases where open specifications do not meet the functional interoperability needs or the ones available are not mature and/or sufficiently supported by the market , or where all cooperating organisations already use or agree to use the same technologies.
That last paragraph seems to have alarmed some FOSS activists. What seems to me to be a very interesting development is the third bullet point above: the footnote is For example using Open Source or proprietary software and technologies. ...
Why interesting? One of the strong arguments that the Free software people have been making in recent times is that an Open Specification whose license locks them out is unacceptable. This footnote seems to be saying that specifications must not only not lock Open source developers out, they must also not lock out Microsoft developers. What is really interesting is whether Free software will be treated as an independent tradition or community rather than being lumped in with Open Source. (I tend to think it should be treated as distinct.) I think that would shake things up nicely: especially with relationship to royalty-bearing standards such as some of the MPEGs.
And here is one I really like (emphasis added):
s5.3 Active government participation in the standardisation process mitigates concerns about delays, supports a better alignment of the formalised specifications with the public sector needs and can help governments keep pace with technology innovation.