open processes

Basic web accessibility is a known commodity now. Web applications can almost be made accessible; eventually web application accessibility will also be a known commodity, too. Those are clear wins.

But nearly ten years after specifications first required it, online captioning still pretty much does not exist. That's probably going to change, and the way it's going to change is by government regulation.

Does that strike you as unthinkable? Do you view the web as a libertarian place where old-media laws barely apply, if at all? Well, prepare for a shock. Legislation is probably coming. And not only should you let it happen, you should get behind it--but only if it's done using open standards.

"ODF has clearly won," said Stuart McKee, referring to Microsoft's recent announcement that it would begin natively supporting ODF in Office next year and join the technical committee overseeing the next version of the format.

"We sell software for a living. The ability to implement ODF in the middle of our ship cycle was just not possible," he said. "We couldn't do that during the release of Office 2007. We're looking forward and committed to doing more than [ODF-to-OOXML] translators."

By owning the "standard" and developing it in secret, without participation from other vendors, in an Ecma rubber-stamp process, Microsoft rigs the system so they can author an ISO standard with which they are effortlessly compatible, while at the same time ensuring that their products maintain an insurmountable head start in implementing these same standards. There is no balance of interests in OOXML. It is entirely dictated by Microsoft, and voted on, in many cases, by their handpicked committees in Ecma and ISO.

...

Remember, standards bring interoperability, the ability to try out new tools and techniques, the ability to migrate, the ability to chose among alternatives, the ability even to run non-Microsoft products. If standards are meaningless and ineffective, then the incumbent' vendor lock-in will win every time. At that point, isn't it convenient for them to have a monopoly in operating systems and productivity applications? This, in my opinion, is the essence of Novell's 2004 complaint, Opera's present complaint, and the ongoing file format debate. Microsoft's monopoly power and the resulting network effects have lead to a relationship with standards where they win by winning, by drawing, or even by cheating so much that they discredit the system.

The reasons that US primary care clinics have not adopted electronic health/medical record applications is because of the economics of doing so. Just the licensing of these applications can run into the tens of thousands of dollars. There are several open source alternatives that carry no license fees. However, the real costs of implementation of these systems include so much more than just licensing. Books such as "Computerization and Going Paperless in Canadian Primary Care" (ISBN-13:978-1857756234) detail these processes and expenses. It can easily take up to 24 months to transition from paper to electronic medical records. This is expensive in terms of not only training but in temporary reduced efficiency.

But, even if a clinic forges ahead with an implementation and they are successfully converting from paper to electronic; who gains? In a 2004 View Point paper by the American College of Medical Informatics (J Am Med Inform Assoc. 2005;12:13–19. DOI 10.1197/jamia.M1669.) they identified some primary reasons for the failure of the health information technology market in the US. Two major ones are:

1) Misaligned incentives. Simply, the people being expected to pay for EHR systems are the ones gaining the smallest percentage of pay back. payors and employers have by far the most incentive to see EHRs implemented.

2) Lack of true interoperability standards. In order for payors and employers to gain their maximum benefits, the systems must be able to communicate semantically correct patient information using open standards. In order to be capable of communicating semantically correct information, they must first be able to STORE semantically correct information. I believe that this is a bigger problem than the health informatics community realizes.

Emphasis on the second one.

Apple Inc. in a new class-action lawsuit is charged with illegally tying iPods to its iTunes Store in order to forge a monopoly over the digital media market so it can inflate prices, exclude competition, and force consumers to continue to buy into its closed ecosystem.

The one thing Apple does really good is integrate all their products seamlessly. If only they published the specs for all of these integrations so it was an open, level playing field.

Note that HTML5 in no way required Ogg (as denoted by the word "should" instead of "must" in the earlier draft). Adding this to the fact that there are widely available patent-free implementations of Ogg technology, there is really no excuse for Apple and Nokia to say that they couldn't in good faith implement HTML5 as previously formulated. Throw your own theory here: DRM, proprietary control, et cetera.

The WHATWG had an opportunity here to eliminate the plugin morass (so 90's) in favor of a baseline format that each browser could implement. Just as HTML specified baseline formats for images (GIF and PNG), this should have been an opportunity to specify baseline free audio and video. And there's still a chance.

Please, please help this issue get more public scrutiny. Use whatever means you deem necessary. Exert pressure on the WHATWG (subscribe now, let your thoughts be read). Don't let special interests kill computing for all — now it’s time to take a stand!

On their mailing list, so far:

• [whatwg] Removal of Ogg is *preposterous*
• [whatwg] Removal off Ogg technology

Though even if the spec were written to reccomend (or even require) Ogg, since when did people actually code their websites to validate? It's been how long since we said "to hell with bad browsers"?

Nobody likes to think about faithful friends dying, but Micah Walter has brought up again a subject that I try not to think about very much: data lock-in. As data-locked-in computer users go, I’m not very locked in. I mostly live in text files, source code, email and the web. I have some confidence that my source control repositories will be readable for some time to come and that any migrations from them will be automatically handled by the next source control system to come along (you can already see that happening with Git-svn).

My photography, however, is another story and it rather scares the pants off me when I think about it too much... all of that is locked into proprietary formats. All of it.

The best thing about being an Apple observer is that even when the company does make a long-awaited announcement, it inevitably leads to new questions regarding what exactly they mean. Apple punditry is the Kremlinology of the tech world.

So it is with this week’s announcement from Steve Jobs1 that, yes, "We want native third party applications on the iPhone, and we plan to have an SDK in developers' hands in February."

Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.

It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones—this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target.

Took long enough.

I wonder if it will be open enough for Amazon to sell mp3s directly to it. I bet not.

The Cactus/Ebay triggers are too unreliable. The PocketWizards are too expensive.

The purpose of this project is to pool resources and create something in between: a wireless flash trigger that is reasonably priced and extremely reliable.

Infancy would be an understatement, but it's something to keep an eye on.