Slashdot Mirror
Massachusetts Adopts Open Standards Strategy
prostoalex writes "The state of Massachusetts at a meeting of state information officers adopted a broad-based strategy to move to open standards. The strategy does involve Linux among other open standard solutions, while moving away from Microsoft-based platforms is one of the decisions. State Administration and Finance Secretary Eric Kriss insisted that decision was made on technical grounds and had nothing to do with antitrust investigation of Microsoft by the state of Massachusetts."
Interesting that the article focuses on the "cost" issue of Linux while skirting the inherent problems with soverenty and transparency that proprietary software poses to governmental institutions.
Reducing the cost of IT is always a good thing, even for the wealthiest states.
If you can save money on IT, maybe you can redirect it to health care or education or better unemployment benefits or debt reduction or even (*gasp*) lower taxes.
By using free, open standards, they are able to choose the best tool for the job, whether that be open source or closed source.
Instead, consider the antitrust investigation conducted by state officials as "The Education of the Great State of Massachussetts" in all matters of Microsoft business practices.
They have some learning under their belts, and it shows.
The idea of an open standard is an open interface (file format, API, etc.) that allows sw for various vendors to interoperate. This way you don't even need to see the source to write complementary or competing sw, you just need the spec.
I think it takes a little more than that. Win32 and the Excel functions are open standards by that definition, but that's not a huge help to the Wine and Gnumeric projects, who have had to do some reverse engineering to make sure their software conforms to the API as implemented by Windows and Excel where that implementation differs from or is a superset of the APIs as published by Microsoft. Even if Microsoft published absolutely everything and followed all it's own specs, they would still leave other vendors at a perpetual disadvantage, because Microsoft gets to see their own APIs and write software which uses them from the most preliminary design phase, whereas other vendors have to wait until Microsoft makes those APIs public, after enjoying a headstart of it's own choosing. For example, Excel has been cloned adequately, but AFAIK the closest thing to an independent Windows API implementation is Wine, which is now 10 years old and still in need of work.
From an economic standpoint, it's important not just that everyone has access to the standard, but that everyone has the same access. From a practical standpoint it's important not just that multiple conforming implementations are theoretically possible but that multiple conforming implementations (or at least free conforming implementations) actually exist.
I suppose that you can find for me a copy of our 1960 Journey to work survey. It was last seen on an 200 BPI even parity tape. (10.5 inch, reel to reel). The media was so common that we assumed we'd always be able to read it (until we sort of forgot about it). We'd periodically scan the tape to make sure it was still readable, and otherwise ignore it. Come the day we need it, and none of our vendors have a tape drive that will read 200 BPI even parity. Out tape verifier still says it's good, but we can't read it. Well, there's some outfit in (was it Chicago?) that can read it, probably, but they want more than is in the budget for the project. It's an obsolete project, so it doesn't get a line item on the budget. More time passes, and the tape verifier dies. This doesn't matter much. Nobody is using those files anyway (big surprise, since we can't read them anymore). Now we don't even know whether it's good or not, but we've backed the newer stuff up to microfiche. That'll certainly be good forever. You can even read it with a magnifier if you must... more time passes. Now you'd better be willing to read it with a magnifier, because the microfiche readers have all been replaced with other things.
I actually left out most of the intermediate forms. And every time one of them died, it took with it records that weren't important at the time the change was happening.
Guys, this is not good. The formats I'm talking about here have all been open formats, and just by people not paying attention to something that wasn't important at the time, data was irretrievably lost. There are no more copies of the Journey to work data. There are no more copies of the processed & edited for local job counts 1960 Census. They became unreadable. There probably aren't any more predictions made in 1980 to 2000 for what the travel trips would be and where people would be living, and how long commutes would take. But without that, the current models can't be validated. (Not that they would be..it's a differnt group running the models now.)
This is a report on what happened in just one small government agency. We don't yet have a count on how badly the shift to proprietary file formats is going to hurt us, because up until a decade ago we had the ability to move important data from system to system with only the need to write conversion programs. And we still lost a bunch of the data. With the switch to proprietary formats we may see a data loss approaching 100%.
That's one way to keep us from learning the lessons of the past.
I think we've pushed this "anyone can grow up to be president" thing too far.