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."

Here are some Texas state guidelines...

[pongo000]

...from the Department of Information Resources (SRRPUB09 [state.tx.us]). A little-known document outside of OSS circles, unfortunately.

2 things

[geekoid]

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.

From the peanut gallery...

[SanityInAnarchy]

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.

Contact your local FOSS user's groups

[markdavis]

You might also want to contact your local Linux/FOSS User's Group for some ideas. For example, our user group ( http://www.twuug.org/ [twuug.org] ) contains people from all walks of life, including people who work for government agencies. You might get a lot of positive feedback and support. Consider it "networking", just not in the computer sense.

Don't be discouraged- there are, unfortunately, a lot of factors that will work against you or at least for the status-quo. But everyone can make a difference. Just do the best you can, keep an open mind, respect others' points of view, and learn from the experience. It can even be enjoyable along the way.

Proprietary isn't bad by default

[Anonymous Coward]

It's all about using the right tool for the job. Sometimes proprietary tools are either:

a) the only tool for the job
b) the best tool for the job

It can be helpful to lock yourself in a contract to secure better pricing and support on proprietary software.

We all know and love the benefits of Free Software, but be careful that you don't shoe-horn people into using specific free, open, yet inferior software. If the traffic signaling hardware can be managed by a superior windows application or a half-supported Linux port, it would be irresponsible to force the DOT to use the Linux version in the name of openness.

I think, what you really need, is to talk to a lawyer. You want to have the best of both worlds: The ability to use open and free software, and the ability to create and break contracts with proprietary software. So you probably want some sort of clause in your contracts that says:

"We're a big client. You want our business. We'll sign a 5 year contract if we have the ability to renegotiate (or even break) our contract every X months"

Problem solved.

not only consume, also create

[reusr1]

I'd really like to see a policy that not only consumes open source projects but at the same time makes sure that all development done for any government is committed as open source (because it belongs to the people that paid for it in the first place, the tax payer). This would in my opinion drastically reduce the cost for local governments because it would allow applications written for one city/state/country to be used and adopted by other entities too. After all, a budgeting software for one county could also be used in the next county... and maybe a state and then some state adds a function that does a sanity check on the budget and maybe we can get them balanced then...

compare models & concentrate on benefits

[darkeye]

I've written a paper on this issue (downloadable from http://kormanybeszerzo.hu/ [kormanybeszerzo.hu] - but in Hungarian), where I found the most compelling approach is to:

• identify the affected stakeholders, such as:
  • the society at large
  • the single citizen
  • the government agency
  • the IT solution provider
  • the IT sector at large
• analyze the different procurement models & analyze the pros / cons in view of the stakeholders. for example, I analyzed the following models:
  • totally closed procumerment (closed source, but the governement agency doesn't even get the source code)
  • closed, the government agency keeps the source closed
  • open standards - closed source, but the components communicate via open standards / open protocols
  • open source - the procured solutions are opened up by the agency as a generic policy
• point out the profound difference in effect to each stakeholder group in the various models. in short:
  • the closed models favour the single IT contractor and the government agency, because the contractor creates a vendor lock in -> thus sells overpriced solutions -> the premium is shared between the contractor and the decision makers at the agency (aka corruption)
  • the closed models are disadvantageous towards society, the citizen and the IT industry at large, because even though a lot of money was spent, the common wealth of the society was not increased, as the solutions can not be reused. (in contrast, a public road can be reused for private or commercial purposes by the community members)
  • the open models favour the society, the citizen and the IT industry at large, because they can re-use the common wealth that was created and financed by their own public money.
  • in the open models the decision makers at the government agency loose their opportunity for 'additional income', because of the lack of being able to specify a privileged supplier - thus they will be against such a change
  • in the open models, the agency's budget is decreased as a result - which means their influence between the agencies themselves is decreased. this can be countered by having them spend the same amount, but actually build on results achieved, not just buy the licenses for the same solutions every year, with no effective advancement in their range of solutions / service - in short: spend the same, achieve more

  in my investigation, I've found that actually their is a shared interest between privileged suppliers and government agencies for using closed solutions - as the privileged supplier can sell overpriced solutions, while the decision makers at the agency get extra treats. this circle is most probably difficult to break.