Slashdot Mirror
Help Writing an Open Standards Policy?
Cornwallis writes "I'm trying to save money for a local government agency I work for by writing a policy statement to support the idea of adopting open data standards and/or Open Source software in order to contain IT expenses (by reducing licensing costs). I am thinking something along the lines of supporting open standards by not locking in to long term software contracts so that departments could be freed to adopt an alternative OS and/or desktop suite if this would work for the individual department. The idea is to unlock the stranglehold that proprietary software may have on the department IT budget. Have any of you written policy statements along these lines, and would you be willing to share? I'm not saying this would be for everybody, nor replace everything, just be an option to help my beleaguered agency in rough times."
...from the Department of Information Resources (SRRPUB09). A little-known document outside of OSS circles, unfortunately.
A) Having an open standards means more citizens can contact them. If a poor woman with 4 children can't communicate with a city bureau and has her water turned off(for example) it would be a PR nightmare for the elected officials.
B) 2 - Slower upgrade cycle for the computers. I can't think of anything a government office does that can't be done using office 97. Yet they keep buying new computers and new software. I am of course talking about general government business. Clearly the people doing crypto, and designing nuclear planets, etc would benefit from having a faster computer.
Most accountants, management, help desk not so much.
The Kruger Dunning explains most post on
Assuming you can make the case for doing so -- and it looks as though you have plenty of help there -- it might be worth clarifying what an "open standard" means.
For something to be considered an open standard, it must meet the following criteria:
- A comprehensive formal specification. (This should be obvious.)
- At least one reference implementation for which source code is freely available. (It doesn't have to be freely re-usable, so long as it's there.) OR, many very different implementations which can communicate. (There probably isn't a reference HTML/CSS renderer, but there are enough implementations that one isn't needed.)
- No legal issues for either of the above points, or the use of the specification. (Obvious example: No patents allowed, unless they've been turned over to the public domain.)
It should also meet the following criteria:
- A well-written, accessible, comprehensive formal specification. Or, both a formal specification and easier-to-read documentation.
- Both an official open source reference implementation, and several competing implementations.
- Corporate backing -- especially a corporate stake in it. This implies that said corporation has had their lawyers verify that there are no legal issues.
- Simple, clean design, especially relative to other standards providing the same thing. For example, if the choice is between SOAP and XML-RPC, you probably want XML-RPC -- and you might prefer REST to either of those, especially if your data is not XML.
- Popularity. This really matters the least, so long as the others are met -- it's more important that I can hold the ideals of REST in my head, and implement it from scratch in a few lines of code, than that there are probably more SOAP and XML-RPC implementations. But it shouldn't be ignored -- it would be insane to try to replace HTML with something completely different, for instance. (Both HTML5 and XHTML are incremental improvements, and are sane. Trying to replace HTML with a YAML-based format would not be sane.)
I'm not suggesting that policy has to follow these to the letter, but that's what I personally consider an open standard, and especially, what I consider to be a good standard. In the past, when I've called Microsoft's "Open" XML various names -- "Neither open nor standard" comes to mind -- these are the guidelines I was using.
Don't thank God, thank a doctor!