Slashdot Mirror
MN Bill Would Require Use of Open Data Formats
Andy Updegrove writes "A bill has been introduced in Minnesota that would require all Executive branch agencies to 'use open standards in situations where the other requirements of a project do not make it technically impossible to do this.' The text of the bill is focused specifically on 'open data formats.' While the amendment does not refer to open source software, the definition of 'open standards' that it contains would be conducive to open source implementations of open standards. The fact that such a bill has been introduced is significant in a number of respects. First, the debate over open formats will now be ongoing in two U.S. states rather than one. Second, if the bill is successful, the Minnesota CIO will be required to enforce a law requiring the use of open formats, rather than be forced to justify his or her authority to do so. Third, the size of the market share that can be won (or lost) depending upon a vendor's compliance with open standards will increase. And finally, if two states successfully adopt and implement open data format policies, other states will be more inclined to follow."
It is not hard to reverse engineer a proprietary format - several word processors can save in competitor's formats. So this is a symbolic gesture, but it will be good in the future when Microsoft and others copyright their file formats to try and extort money from OpenOffice.Org and others.
Does anyone think it's significant that the two efforts are in states with "blue" histories (at least in election years)?
We know a hell of a lot more about ODF than we do about .doc, and that hasn't slowed it down.
I am glad. Open Standards should be, well, the standard. If it passes there, and similar ones in other states, everyone will be able to read important gov't files without surrendering their freedom of choice, and the files will not become locked in an abandoned format. Hopefully the Federal Government will see the light.
The more important point is that governments deal in records that are meant to be more or less permanent, or at minimum long-lived. Proprietary formats exist at the whim of a single supplier -- a software company -- and those suppliers are subject to the whims of the market like any other company.
If I buy some paper from the Bienfang company and write a report on it, that report will still exist and be readable possibly for hundreds of years after Bienfang goes out of business. If Microsoft stops making a word processor or (god forbid) goes out of business, the situation may be different.
"So what," you say, "just reverse engineer it." But what if, in the intervening years, Microsoft has successfully lobbied for laws that make that a criminal offense? We're talking about future-proofing data here; whether it's implausible is not really the point. The point is that using a closed format introduced risk.
Another, more likely scenario: Microsoft subtly changes its format, or changes the way that newer versions of its software interprets the older format files. The government is forced to upgrade because Microsoft stops supporting the older version of the program, but the newer version does weird things to all those old records when it opens them.
There are various reasons to choose true open formats and standards beyond ideological ones.
Breakfast served all day!
Thousands and thousands of bills are introduced in legislatures around the US and worldwide it is probably a million or more. Far fewer pass and even fewer of those make it th erest of the way into becoming a law. (For the civics challenged/non-US readers: In most US states it will also need a sponsor in the other legislative body, passage in both bodies and either signing into law by the Governor or another vote to override a veto.)
It is good that such an idea is starting to bubble up, but it has yet to pass into law ANYWHERE at this point. The political power, wealth and proven tendency to resort to outright illegal measures of the Foe is going to make this a long difficult struggle.
Democrat delenda est
...it is the responsibility of a democratic government to be as open and transparent as possible, whenever possible. Saying that the tool chosen should be "the best tool for the job" must take openness into strong account when that tool is for use by the government.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
This is very true. But there is a reason for this "carefully worded" requirments. All too often, vendors lie about their specs. "Sure, we're section 508 compliant" and in reality all it means is that they have alt tags on their images.
So, what happens, is you specify all your requirements, and in reality, only a few vendors meet those requirements, but a dozen or so "cheaper" vendors who meet the specs on paper end up winning the contract, and then we're stuck with crap.
This has lead to requirements being VERY specific, so that you don't end up with something that barely does what it claims to.
If you need web hosting, you could do worse than here
No, I think you're incorrect.
MS will incorporate ODF, and will do it very badly.
Same as with the web. You'll have to have an OpenOffice.org ODF, and MS Office ODF, and the two will not meet without quirks in OpenOffice.org
It's going to be ugly. MS's resistance is just their first bit of opposition.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
The beautiful flip-side to this is a play on words. They will use open standards unless it's technically impossible to do, which really just means a lot of people will say "It's impossible to do function Y in format Z, I'm sticking with MSWord". It's not so much about impossibility, as it is about ignorance.
-Billco, Fnarg.com
That sounds pretty much like the same insults that were slung in my face umpteen years ago when I was trying to argue for using standardized formats for data in several projects.
Anyway, I find it sad that so few "programmers" actually bother learning anything about the history of what they are doing.
In "legacy programming" people pretty much saw data as separate from the program. In "legacy" programming you would generally go about a project in two steps. You would design the data format in one step and the program in another. In a project you would write and publish both documentation for the format and program.
The problem with this "legacy" design methodology was that you have to keep your published data formats in sync with all programs that access the data. Let's say I had a data store where the lastname was 24 characters. In release 1.17, I change the lastname to 32 characters. If someone else had written a program that was directly accessing and manipulating this data; we would have a crisis.
The bold statement of OO design was that the object owned the data. The object would have complete control of all data from start to finish. You would only publish the interface and not the data format (you would still write both documents, the latter would not be published). This ideal worked well in interface design, but fell flat when dealing with long lived objects saved to disk. Have you ever heard the phrase the "problem of persistence," or are you as ignorant as you are arrogant?
The problem of persistence was this horrible challenge for pure OO design. No matter how you went about it, data needs to be stored, replicated and transferred outside of the control of a single program. Anyway, many of the first OO programmers took the bold statement that the object owned the data to its logical conclusion. They ended up writing programs that saved data in terse, obfuscated, proprietary formats.
I know this happened because I was there with my little hexadecimal editor looking at the data.
OOP was never able to achieve the goal of a single object controlling long lived data. The OO world gradually dropped its bold statement. This is the way history works.
This long post is relevant to today's article because many OO languages still have objectStore methods that save the internal state of the object to disk. I suspect that any OO program using these object store methods are in violation of the MN law. Even though I dislike programs that store their data in bizarre formats, I don't like seeing them legislated out of existence.
Sun and other companies use XML for object persistence. These files are more readable, but still hard to work with.
Please note that I was talking about publication. Publishing a document is different from writing a document. If you hold that the the data should only be accessed through the interface, then you would not publish the file format, now, would you?
I laughed when I read that line. The first OO adopters generally saw themselves as architects. The idea of "breaking things down into procedures" was part of the old "legacy" way of thinking. The OO architects build things up from objects. A person doing OOP isn't a computer programmer. When you think in OOP you are architecting systems, not programming computers.
The really funny thing is that OOP is systematically becoming more like the traditional programming paradigms that it was supposed to transcend.