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."
You can use any of a number of already existing policies. For instance, the Open Standards Policy of Massachusetts is very nicely worded:
Commonwealth's Position
--
Interested in exploring a possible business idea with friends?
For some good ideas to start with, see http://en.wikipedia.org/wiki/OpenDocument_adoption and then head over to the Commonwealth of Massachusetts links. You can glean a lot of the policy formulation ides from there. They built a requirement to use open document format (not necessarily open source). http://consortiuminfo.org/standardsblog/ is another good resource to start with.
Bruce
Bruce Perens.
...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!
> ...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 think it might get a better reception if you invert the argument: don't present adopting open source/standards as the target; present saving money as the target, and open source/standards as the method.
> ...supporting open standards by not locking in to long term software contracts [and] to unlock the stranglehold that proprietary software may have on the department IT budget.
Same here. Make the objective to unlock the stranglehold and free up dependencies...by using open source/standards.
In half a life in state-funded IT managment, I have found that most public-service IT managers and local government administrators are woefully undereducated in software selection, and either a) have never heard of FOSS, b) think it has something to do with downloading viruses from bulletin-boards, or c) simply aren't bothered one way or the other unless it saves money or makes life easier. A very, very small number are on kickbacks from suppliers, but you shouldn't work for them.
There are a gazillion other benefits, but try to present them as serendipitous by-products of using open source/standards, not as ends in themselves. The immediate end is saving money (or its equivalent).
However, before you do so, make sure you aren't making a noose for your own neck. Sometimes a department or agency which saves real money finds that this is treated as evidence that they don't need any more resources ever again. It's sometimes better to use the move to FOSS as a way to free up money to do things you said were impossible unless you got extra funding.
Good luck, and please let us know how you got on. Post the document if that is permitted.
I'm extremely impressed that Bruce Perens responds with his phone number and an offer of advice, which I assume we all appreciate is based on a wealth of practical experience and success, and even more impressed that just a few posts later someone suggests that what you really need is a lawyer. What a strange world. Perhaps the anon coward who suggested a lawyer is, in fact, a lawyer?
If you ignore Bruce Perens and opt instead to call a lawyer you should get fired ;-)
btw I'm writing this from my nuclear planet. I made it last week. I have a very fast computer. The planet is OK but a bit hot (I didn't have time to put the air-con in yet).
So you want to encourage open-source adoption? OK, a laudable goal. The two things that you are going to have to deal with from an IT perspective are support and version control.
Who, exactly do departments deal with for support? Will the IT department be the front-line resource and then farm things out as needed? Or are individual departments going to be going it alone? More to the point, is the experience if departments such that they would prefer to "go it alone" today? If the departments are your customers and they have been treatd well, then the probably will expect the IT department to be providing first-line support for them - as well you should.
One big reason for providing first-line support is version control. While some open-source packages have well-defined versions (Ubuntu, for example), many others do not. There are patches here and there and different versions being distributed from different web sites. If you are assuming interoperability of software being used by different departments it is going to be up to someone to ensure that this is actually possible. Having departments select their own versions and installing them will not insure this at all. If it then falls upon you to sort this out at some later date, you are going to wish dearly that you had been proactive about it. Yes, this may mean being ratuer draconian about individual users downloading whatever they want, installing it and counting on IT to pick up the pieces.
I have seen this happen, even within a community of software developers.
There is a substantial manpower requirement for this, and it needs to be in IT, not in individual departments. You are proposing something that will save money, but some of that immediate savings in software licenses needs to be shifted over to an IT function for support and version control. Ignoring this is not a viable option because you will end up with everyone being unhappy and upper management putting an end to this "experiment". No matter how happy they were with the initial savings.
Sure, overall costs can be lower. But some of that apparent savings needs to be funneled back into keeping things sane and managed. Things like Office Update and Microsoft Office web sites for templates, add-ons and tools do this for Office users and it all just works. You will be replacing this with IT resources at a great savings but you can't ignore things like updates, version control and support issues.