Ian Murdock’s Weblog

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.

Oracle Press Release: “The Free Standards Group (FSG) and Oracle today announced that Oracle has joined the FSG as a platinum member. FSG is a nonprofit organization dedicated to strengthening and promoting Linux as a platform for application development. Oracle plans on contributing to FSG’s Linux Standard Base (LSB) workgroup and providing feedback and guidance on its requirements for developing and supporting enterprise applications for Linux. Oracle’s support of the FSG and LSB is a significant milestone in the development of the standard and highlights the LSB’s success in solving Linux application development issues.”

Last week, the Free Standards Group launched the LSB Developer Network, a community resource for developers building portable Linux applications via the LSB (read the press release and the introduction from LDN editor Martin Streicher).

The LSB Developer Network (or LDN for short) aims to provide a well known starting point for developers looking to target the variety of Linux distributions available today without requiring a separate version for each distribution. It is the perfect complement to the LSB, which already provides a “highest common denominator” across the major distributions; and LSB Certification, which allows ISVs to indicate that their products will work with LSB Certified distributions.

The big themes of LDN are “decentralized” and “bottom up”—to paraphrase Darrin Thompson, it’s a developer network that’s actually a network. In other words, we’re not taking the usual path of hiring a bunch of people to construct a centralized “network” from the top down—after all, Linux is a fundamentally decentralized phenomenon so shouldn’t a developer network for Linux be decentralized as well?

Like the LSB, we see LDN as essential to the ultimate success of the Linux platform, an answer to similar programs for the centralized, proprietary platforms Linux competes with but built using the very techniques that make Linux what it is. Our fundamental belief is that “decentralized” doesn’t have to mean “fragmented”, and LSB and LDN are both key steps toward that end goal.

We’re off to a good start too: LDN has the backing of a broad range of Linux platform stakeholders ranging from distribution vendors (Novell, Red Hat, Ubuntu) to OEMs (HP, IBM) and ISVs (MySQL, RealNetworks) to tools and content providers (O’Reilly, SlickEdit). One upcoming feature I’m particularly excited about is the integration of Safari Books Online. Soon, you’ll be able to type, for example, a function name into the LDN search box and get not just results from the link directory but also results from O’Reilly titles and others you know and love.

We’re moving rapidly to add community content as well, including man pages and canonical reference documentation; and we’ll be hooking LDN into the LSB database, so you’ll be able to query the status of interfaces too, including whether or not those interfaces are in the LSB and what their status is in each of the major Linux distributions, to help make your applications as portable as possible.

If you’re a Linux developer, and particularly if you use del.icio.us to bookmark resources on the web related to software development on Linux, I urge you to contribute to the LSB Developer Network. It’s easy: Simply create an account and link your account to your del.icio.us account (you don’t need to provide your del.icio.us password, just your username), and as you bookmark, tag, and annotate pages, your bookmarks, tags, and annotations will be pulled into the LDN directory. Help us build a developer network for Linux, bottom-up style!

While it’s interesting to debate who’s right and who’s wrong in the Debian/Firefox standoff, it’s doesn’t really get us any closer to a solution. While we were debating, though, “Peter” (sorry, I don’t have a last name) made a practical suggestion:

I think Debian’s stance should have been to distribute epiphany and move Firefox to the appropriate *verse repository.

That’s the best solution I’ve heard yet: Simply move Firefox to non-free (or drop it entirely) and make something else the default browser. That allows Debian to make its point without the destructive side effects of a fork (user confusion, extension incompatibility, fragmenting the userbase of the leading open source browser on the eve of IE 7, etc.). The end result is the same: Mozilla loses out on the additional users (at least until/unless it changes its policy), and Firefox is still there for those Debian users who want it. Best of all, it maximizes freedom—namely, the freedom of users to decide whether or not this is an issue worth switching over.

Jeff Waugh: “I raised concerns about overselling Portland during the first [OSDL Desktop Architects] meeting, as it could harm long-term credibility with ISVs. Such unclear language has resulted in serious miscommunication, and was not rectified in the 1.0.” (Via Stephen O’Grady.)

I agree completely and have raised similar concerns—Portland helps solve an important problem, but it’s being dangerously oversold, and it’s certainly not a complete solution for ISVs by itself. The LSB has been around for a long time, and we’re just now reaching the breadth of features and distribution support that we’re comfortable positioning it as a practical solution for ISVs. Even now, we’re being extremely careful not to oversell (i.e., we consider our ISV certification program to be in the pilot phase). We (the Linux community) are only going to get one chance at this, namely the opportunity to present Linux as a unified ISV platform rather than a fragmented mess, and we can’t afford to blow our one chance with premature proclamations that the problem is finally solved.

Joe ‘Zonker’ Brockmeier: “If the Sun folks are really interested in luring Linux users over to Solaris or OpenSolaris, they should take a cue from Nexenta and adopt APT and dpkg for their package management.”

Eric: My comments weren’t directed at you. That would be shooting the messenger—after all, a quick read of the comments to my post the other day shows that you’re just going along with the community consensus.

My dismay is based on two basic things. First, while the web guys (you know, the ones we used to make fun of as not “real programmers”) are off inventing the future, the Debian community (or some significant subset anyway) sees this as the critical issue, and that makes me wonder how relevant free software is going to be in a few more years. It may be a matter of principle to some, but it paints everyone with the same lunatic fringe brush.

More than anything, though, it’s the, uh, inconsistency that really burns me. As I said in the aforementioned comments, I’ll be the first to agree that Mozilla is being overzealous, just like I thought Debian was being overzealous in its reaction to the Debian Common Core last year. As I said then:

I can say with 100% certainty that a trademark policy more restrictive than the one adopted by Linus Torvalds for Linux isn’t what the founder of this project had in mind.

Yet, now that the shoe is on the other foot, Debian is up in arms because another organization wants to enforce its trademark? Come on. You can’t have it both ways.

Mike Melanson: “What could possibly be so difficult about porting the Flash Player to Linux? I’m glad you asked…”