Group items matching

in title, tags, annotations or url

ptsefton continues his rant that OpenOffice does not support the Open Web. He's been on this rant for so long, i'm wondering if he really thinks there's a chance the lords of ODF and the OpenOffice source code are listening? In this post he describes how useless it is to submit his findings and frustrations with OOo in a bug report. Pretty funny stuff even if you do end up joining the Michael Meeks trek along this trail of tears. Maybe there's another way?

What would happen if pt moved from targeting the not so open OpenOffice, to target governments and enterprises trying to set future information system requirements?

NY State is next up on this endless list. Most likely they will follow the lessons of exhaustive pilot studies conducted by Massachusetts, California, Belgium, Denmark and England, and end up mandating the use of both open standard "XML" formats, ODF and OOXML.

The pilots concluded that there was a need for both XML formats; depending on the needs of different departments and workgroups. The pilot studies scream out a general rule of thumb; if your department has day-to-day business processes bound to MSOffice workgroups, then it makes sense to use MSOffice OOXML going forward. If there is no legacy MSOffice bound workgroup or workflow, it makes sense to move to OpenOffice ODF.

One thing the pilots make clear is that it is prohibitively costly and disruptive to try to replace MSOffice bound workgroups.

What NY State might consider is that the Web is going to be an important part of their informations systems future. What a surprise. Every pilot recognized and indeed, emphasized this fact. Yet, they fell short of the obvious conclusion; mandating that desktop applications provide native support for Open Web formats, protocols and interfaces!

What's wrong with insisting that desktop applciations and office suites support the rapidly advancing HTML+ technologies as well as the applicat

Replace or Re-Purpose? The Belgian Desktop Pilot Study Here is the summary of the Belgian desktop pilot study. The conclusion echoed the findings of Massachusetts and California; they found that they could not use OpenOffice as a replacement for MSOffice. Although there were many reasons sighted, i think they all fit under the larger framework that MSOffice is the center of what turned out to be a sprawling desktop productivity ecosystem.

I doubt that MSOffice ODF will make a difference. ODF was not designed to be compatible with MSOffice, and conversion from native binary to ODF will result in a serious loss of fidelity and business process markup. If the many ODF pilots are an indication, the real killer is that application specific processing logic will be lost on conversion even if it is Microsoft doing the conversion to ODF. This logic is expressed as scripts, macros, OLE, data binding, media binding, add-on specifics, and security settings. These components are vital to existing business processes. Besides, Microsoft will support ISO 26300, which is not compatible with the many aspects of ODF 1.2 currently implemented by most ODF applications. The most difficult barrier to entry is that of MSOffice bound business processes so vital to workgroups and day-to-day business systems. Maybe the report is right in saying that day-to-day business routines become habit, but not understanding the true nature of these barriers is certain to cloud our way forward. We need to dig deeper, as demonstrated by the many ODF pilot studies.

The race is on. Google will win the consumer Web. Microsoft will win the business Web. Sadly i don't think there is any way for Google to challenge Microsoft with regard for the privilege of transitioning existing MSOffice bound workgroup- workflow business processes to the Web. Even if Google Docs could match MSOffice feature to feature, cracking into existing MSOffice workgroups is impossibly hard. Anyone who doubts this ought to take a second look at the Massachusetts ODF Pilot Study, or the recently released Belgium Pilot results. Replacing MSOffice in a workgroup setting is simply too disruptive and costly because of the shared business process problem.

June 29, 2010 Dear College or University President: We write to express concern on the part of the Department of Justice and the Department of Education that colleges and universities are using electronic book readers that are not accessible to students who are blind or have low vision and to seek your help in ensuring that this emerging technology is used in classroom settings in a manner that is permissible under federal law. A serious problem with some of these devices is that they lack an accessible text-to-speech function. Requiring use of an emerging technology in a classroom environment when the technology is inaccessible to an entire population of individuals with disabilities - individuals with visual disabilities - is discrimination prohibited by the Americans with Disabilities Act of 1990 (ADA) and Section 504 of the Rehabilitation Act of 1973 (Section 504) unless those individuals are provided accommodations or modifications that permit them to receive all the educational benefits provided by the technology in an equally effective and equally integrated manner. ... The Department of Justice recently entered into settlement agreements with colleges and universities that used the Kindle DX, an inaccessible, electronic book reader, in the classroom as part of a pilot study with Amazon.com, Inc. In summary, the universities agreed not to purchase, require, or recommend use of the Kindle DX, or any other dedicated electronic book reader, unless or until the device is fully accessible to individuals who are blind or have low vision, or the universities provide reasonable accommodation or modification so that a student can acquire the same information, engage in the same interactions, and enjoy the same services as sighted students with substantially equivalent ease of use. The texts of these agreements may be viewed on the Department of Justice's ADA Web site, www.ada.gov. (To find these settlements on www.ada.gov, search for "Kindle.") Consisten

Good article from Aaron Ricadela. The focus is on Java, Sun's hardware-Server business, and Oracle's business objectives. No mention of OpenOffice or ODf though. There is however an interesting quote from IBM regarding the battle between Java and Microsoft .NET. Also, no mention of a OpenOffice-Java Foundation that would truly open source these technologies.

When we were involved with the Massachusetts Pilot Study and ODF Plug-in proposals, IBM and Oracle lead the effort to open source the da Vinci plug-in. They put together a group of vendors known as "the benefactors", with the objective of completing work on da Vinci while forming a patent pool - open source foundation for all OpenOffice and da Vinci source. This idea was based on the Eclipse model.

One of the more interesting ideas coming out of the IBM-Oracle led "benefactors", was the idea of breaking OpenOffice into components that could then be re-purposed by the Eclipse community of developers. The da Vinci plug-in was to be the integration bridge between Eclipse and the Microsoft Office productivity environment. Very cool. And no doubt IBM and Oracle were in synch on this in 2006. The problem was that they couldn't convince Sun to go along with the plan.

Sun of course owned both Java and OpenOffice, and thought they could build a better ODF plug-in for OpenOffice (and own that too). A year later, Sun actually did produce an ODF plug-in for MSOffice. It was sent to Massachusetts on July 3rd, 2007, and tested against the same set of 150 critical documents da Vinci had to successfully convert without breaking. The next day, July 4th, Massachusetts announced their decision that they would approve the use of both ODF and OOXML! The much hoped for exclusive ODF requirement failed in Massachusetts exactly because Sun insisted on their way or the highway.

Let's hope Oracle can right the ship and get OpenOffice-ODF-Java back on track.

"......To gain