Ian Murdock’s Weblog

Max Spevack: “The Fedora Project is leading the creation of a new community around RPM. One in which the leaders can come from Fedora, from Red Hat, from Novell, from Mandriva, or from anywhere.”

Elizabeth Montalbano and Andy Updegrove write about IBM’s donation of iAccessible2 to the Free Standards Group, which is being formally announced today (see the IBM and FSG press releases). In addition to IBM, the project is backed by Sun, Oracle, SAP and other major vendors.

This is a big deal in and of itself, of course, because it will make applications based on ODF, AJAX, and other emerging open standards more accessible to visually impaired users. But it’s also an important milestone for the FSG, so I thought I should say a few words about that here from my own little pulpit.

The first clue is that iAccessible2 is an accessibility API for Windows. Windows? Yes, the FSG is primarily a Linux organization (our main project is, of course, the Linux Standard Base), so why on earth are we now involved in building APIs for Windows?

First of all, we’ll be moving this project forward as an extension to our existing accessibility projects—which, given the way the FSG is structured, flow into the LSB as they are adopted by the Linux distributions (who, as I’ve already mentioned here, are active participants in the LSB project, so we’re not just hoping the distros adopt our work, we’re proactively trying to drive consensus on these key issues). So, this definitely impacts our Linux work by bringing accessibility features to Linux that not only equal those of Windows but exceed them (iAccessible2 itself came about because Microsoft Active Accessibility has notable shortcomings).

But it’s more than that. Another way to look at this is that the LSB APIs will be taking on a distinctly more cross platform flavor, particularly in the “around the edges” cases such as this. Again, that begs the question: Why is cross platform support important for a Linux organization? That one’s simple. APIs are for application developers. Application developers target multiple platforms. The less Linux specific work an application developer has to do to support Linux, the more cost effective a Linux version will be, the more likely it is to get done. It’s all about more Linux apps.

There’s another dimension to it as well. There are a certain class of features that the vast majority of developers don’t think much about because that vast majority doesn’t need them. There’s no itch to scratch, as it were. Accessibility is a great example of such a feature: I have no idea what it’s like to be blind, nor do most people. If we can provide a set of open, cross platform APIs that allow application developers to easily add such features to their products, more standards based products will support them.

As Massachusetts and ODF brings into sharp focus, these “around the edges” cases developers don’t think much about can turn out to be very important indeed.

InfoWorld: “Initially, Liquid VM will work only with VMware’s ESX Server hypervisor, but BEA plans to support other hypervisors in future including those from XenSource and Microsoft.”

Now this is interesting: BEA is coming out with a version of its application server that runs directly atop VMware.

With this move, VMware takes another step toward becoming a full fledged operating system in its own right. VMware is already promoting the distribution of applications as virtual machine images, and operating systems are first and foremost application platforms. If VMware is an application platform, why not cut out the middle man entirely, particularly given that the middle man adds a few hundred megabytes of largely invisible baggage to the application, not to mention an enormous amount of maintenance burden for the ISVs that make or break an application platform?

For me, the real question is: Why BEA and not VMware? A JavaOS makes a lot of sense, since it builds on one of the world’s largest developer communities—it’s a well known environment among developers, and there are a huge stable of applications that could take advantage of the new platform with minimal porting. Furthermore, applications are increasingly server based, with the browser providing the UI, so this matches well with industry trends and nicely addresses the problem that VMware would have a very hard time building any sort of graphical user interface into its platform, just given the nature of what it is.

That said, VMware should really want to provide the JavaOS directly. With Xen and Virtual Server moving aggressively to bundle their products with widely deployed operating systems, the game’s already afoot, and if virtualization becomes just another operating system feature, VMware is at a distinct disadvantage, as it owns no operating system to bundle its product with. Finally, what about standards? New kind of operating system or operating system feature, there are going to be multiple application platforms if history is any indication (and it usually is), so how do applications take advantage of the new platforms without the inevitable fragmentation?

It’s going to be an interesting space to watch, that’s for sure.