MN Bill Would Require Use of Open Data Formats 176
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."
I hope it passes (Score:5, Insightful)
Blue-state phenomenon? (Score:4, Insightful)
Are the standards ready? (Score:3, Insightful)
Having said that, I think it's high time our public offices stop feeding monopolistic practices by continuing with document format requirements that more or less pre-determine software choice.
Well, (Score:5, Insightful)
More openness is only a good thing. (Score:4, Insightful)
Lock-in isn't the point (Score:5, Insightful)
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.
Not a big story yet (Score:5, Insightful)
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.
NOT! (Score:3, Insightful)
Put simply... (Score:4, Insightful)
Re:I live in MN, stuff open source crap (Score:3, Insightful)
As for "de-facto standards" - even de-facto standards are supposed to be documented and open to competitors. Standards exist for more than one entity to adhere to. Otherwise it's a "de-facto monopoly".
Re:How government procurement works (Score:4, Insightful)
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.
Re:Lock-in isn't the point (Score:5, Insightful)
Re:Lock-in isn't the point (Score:3, Insightful)
Re:Open Standards / Open Source (Score:4, Insightful)
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.
Re:Blue-state phenomenon? (Score:5, Insightful)
Don't get too excited. If it wasn't for Governor Mitt Romney (R) ODF in Massachussets would be dead, and it's primary opponent was state senator Marc Pacheco (D).
Obligatory pessimists view (Score:3, Insightful)
OTOH, might be a way to eventually bleed MS dry, eh?
(Might take 1000 years...must take the long view)
Impossible ? (Score:3, Insightful)
Re:OO and Semi-Permanent Objects (Score:3, Insightful)
One of the ideals of OO revolution was that object would own the data. Taken to extremes that means that one object should own the data through its entire existence [...] It seems to me that OO ushered in proliferation of proprietary formats.
You, sir, are obviously not a programmer.
The object-oriented paradigm is just a programming idea for how a program should be "broken down." An OO programmer would look at a problem and think of how it can be broken down into more logical, programmable parts - like saying a car can be broken down and programmed as an engine object, a steering wheel/gas/brake "interface" object, and 4 wheel objects.
Those objects would then be programmed as "black boxes" for the data, the idea being that whoever uses the objects doesn't have to know how the data is tinkered with and can just use the methods provided by the programmer. For example, you don't have to know what ratio of fuel and air at what pressure has to be achieved for optimal combustion in order to accelerate the engine - the "programmer" left you that nifty gas pedal interface.
Obfuscated, undocumented formats and lazy hacks were around before OO programming, and OO programming doesn't encourage their use. An object "owns" data in the sense that it handles manipulation of the data for the end user - it sure would suck if you had to know how to mix fuel properly to make your car go. In fact, OO programming encourages the opposite - that you'd have one "file object" that would handle saving and loading, so that you could use that same object in future programs to load the same data. (Code re-use is another facet of the OO paradigm.)
Whether or not the lazy programmer actually documents the file format or not has nothing to do with whether or not he adheres to OO programming principles.
Govt is ofter the first (Score:2, Insightful)
Whether building dams in Nevada or sending Americans to the moon, it is the one entity that can face risk of failure and not flinch. In part this is because it represents our collective courage to attempt the impossible.
For this reason it is entirely logical to me that it is a state, in this instance the great state of Minnesota, that would take on the the challenge of ensuring that its technological infrastructure is solid and, if not, fix what needs fixing.
Indeed, what other company or organization in recent memory has challenged itself with so introspective and potentially damaging a question in order to arrive at a better place.
Open Formats are a difficult proposition to be sure. No one denies this. But it is becoming increasingly clear that without the safeguards associated with open formats the State abdicates control of the very information it is suppose to protect.
Regardless of derived the system a solution must be constructed that returns balance and moves control of State information back to those with whom the trust has been placed.
I for one will be writing my representative to support the Bill.
Re:OO and Semi-Permanent Objects (Score:5, Insightful)
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.